Comments 30
Есть похожий проэкт, тоже с nginx, но логику на руби перекинули, и пока решили обойтись paperclip.
Делали нечто похожее только при отдаче X-Accel-Redirect :)
а так почти все также NGINX в связке с PHP через fastcgi
великолепный Nginx upload module
без логики при отдаче ой как нелегко, особенно если есть превелигированные юзеры и обычные.
а время ссылки можно ограничить и без вашего трюка ;)
а так почти все также NGINX в связке с PHP через fastcgi
великолепный Nginx upload module
без логики при отдаче ой как нелегко, особенно если есть превелигированные юзеры и обычные.
а время ссылки можно ограничить и без вашего трюка ;)
Трюк в том чтобы обойтись без X-Accel-Redirect
для привилегированных и обычных пользователей локейшены разные.
для привилегированных и обычных пользователей локейшены разные.
У меня от слова «letitbit» одни негативные ассоциации :( Шарашкина контора у них…
imho, лучше сравнить со SkyDrive-ом, Яндекс.Народ-ом, ну или RapidShare
imho, лучше сравнить со SkyDrive-ом, Яндекс.Народ-ом, ну или RapidShare
Ну это весьма примитивно как для летитбита=) Чисто технически намного сложнее будет размазать нагрузки по куче серверов и винтов, желательно равномерно, контроли целостности, дубликатов итд.
этим занимаеться кодег раздающий ссылки. И не так всё и сложно если подумать ;)
Та я просто этим занимаюсь немного, то знаю, что это сложнее, чем кажется на первый взгляд. Одна копия файла все равно ненадежно и неэффективно, как правильно распределить так, чтобы при массовом скачивании на все винты в системе была примерно равная нагрузка это достаточно нетривиальная задача, особенно в условиях существенной нагрузки.
А еще отслеживание и реакция на сбои оборудования, а подбор оптимального метода хранения для файлов, удаление неактуальных файлов (определение, какие именно файлы надо удалять), борьба с ботами, в общем на практике там много еще чего интересного.
Антилич (по сути то, что у вас и есть), это очень простая часть системы на самом деле, даже без модулей к nginx делается достаточно тривиально.
А еще отслеживание и реакция на сбои оборудования, а подбор оптимального метода хранения для файлов, удаление неактуальных файлов (определение, какие именно файлы надо удалять), борьба с ботами, в общем на практике там много еще чего интересного.
Антилич (по сути то, что у вас и есть), это очень простая часть системы на самом деле, даже без модулей к nginx делается достаточно тривиально.
MogileFS?
Оно как минимум не учитывает нагрузку на винты и популярность файла. Один файл можно хранить в 1-2 копиях, другой лучше на 10 винтов на разных серверах разбросать, потому что его очень много клиентов запрашивают.
Ну и остальных проблема не решает (удаление неактуальных, метод хранения (рейды, не рейды), итд)
Ну и остальных проблема не решает (удаление неактуальных, метод хранения (рейды, не рейды), итд)
А все же как вы решаете проблему равномерного распределния нагрузки по винтам? В таких сервисах файлы быстро становятся популярными и быстро забываются… Пока соберешь статистику по популярности файла, и начнешь его по винатам двигать — его уже ни кто и не качает :)
Кеш ОС, тоже не выход если файлы большие.
Кеш ОС, тоже не выход если файлы большие.
Там много параметров.
Например зависит от количество копий файла. Как правило, если точные копии файла заливаются несколько раз, то файл популярный.
Далее смотрится количество обращения в первые пару часов и если достаточно много, то делает еще одна копия, потом если все еще большая нагрузка на каждую копию, то еще одна итд
Удаление файла тоже происходит с учетом того, что существуют копии. Для каждого винчестера создается список самых непопурярных хешей (каждый файл физически хранится под именем своего md5 хеша), дальше выбираются те, у которых есть еще копии или если копий нету, но хеш удовлетворяет определенным критериям (небыло обращения столько-то дней) и удаляются.
Это в общих чертах, там чуть больше условий в алгоритмах, но примерно так работает.
Балансировка нагрузки по винчестерам это тема статьи наверное, а не комментария.
Например зависит от количество копий файла. Как правило, если точные копии файла заливаются несколько раз, то файл популярный.
Далее смотрится количество обращения в первые пару часов и если достаточно много, то делает еще одна копия, потом если все еще большая нагрузка на каждую копию, то еще одна итд
Удаление файла тоже происходит с учетом того, что существуют копии. Для каждого винчестера создается список самых непопурярных хешей (каждый файл физически хранится под именем своего md5 хеша), дальше выбираются те, у которых есть еще копии или если копий нету, но хеш удовлетворяет определенным критериям (небыло обращения столько-то дней) и удаляются.
Это в общих чертах, там чуть больше условий в алгоритмах, но примерно так работает.
Балансировка нагрузки по винчестерам это тема статьи наверное, а не комментария.
Как вариант можно использовать кэш сервера для популярного контента
Ну да, могайл не идеален, но для относительно не больших проектов в качестве управлялки контентом его вполне хватает.
Мы использовали его на видеохостинге. На типичном сторадже был самый простой проц и два винта в gmirror. До двухсот мегабит нода отдавала.
К тому же балансировка в зависимости от загруженности нод там есть.
Имхо, в деле доставки контента не стоит пытаться конструировать велосипеды.
Мы использовали его на видеохостинге. На типичном сторадже был самый простой проц и два винта в gmirror. До двухсот мегабит нода отдавала.
К тому же балансировка в зависимости от загруженности нод там есть.
Имхо, в деле доставки контента не стоит пытаться конструировать велосипеды.
Если речь об относительно небольшом (относительно чего?), то там может и просто на серверах надо хранить в виде одной копии и не переживать.
Под нагрузкой когда все начинает методично ложиться, насчет велосипедов мнение резко меняется. В любом случае без велосипедов большие проекты не делаются, пусть из стандартных компонентов, но все равно конфигуации будут совсем не стандартные и много чего дописывать надо будет.
Под нагрузкой когда все начинает методично ложиться, насчет велосипедов мнение резко меняется. В любом случае без велосипедов большие проекты не делаются, пусть из стандартных компонентов, но все равно конфигуации будут совсем не стандартные и много чего дописывать надо будет.
Спасибо авторам, недавно упустил хороший заказ из за незнания подхода к организации работы nginx, думаю теперь этого не повториться.
Вот изящное решение для IIS7 — www.codeplex.com/FileDenyModule
Раз как летитбит делали, трой не забыли положить? ;)
делал подобный проект. админил с 10-ок серверов. часть из них находилось в москве. Конфа серверов была простой — простейший проц, минимум оперы, кучища винтов + по 2+ сетевые внешние. В ДЦ коннектил несколько внешних 100мегабитных портов на безлимите (кол-во портов==кол-во сетевых) и балансировал нагрузку операционкой (freebsd). Всё было построено на nginx+fast-cgi(php-fpm)+php. Php обрабатывал результат в любой логике, что я захочу. Было до 10 запросов в базу при коннекте к файлу в отдельных случаях, однако X-Accel-Redirect делал своё дело на ура. Даже при минимальных конфах проца и оперы (как на фронт-бэк серверах, так и на сервере-базе) алгоритм отрабатывал на ура, top говорил, что idle сервера 90% в пик.
Отсюда напрашивается вопрос, зачем все эти шаманства с бубном возле конфига, если это дает минимум прироста производительности. Я бы сказал, это дает материальную точку.
P.S. в портах фри уже давно лежит nginx не только с nginx_upload_module, но и с nginx_upload_progress_module, который тоже отлично справляется с желанием пользователя закрыть страницу и избавляет программеров от головной боли.
Отсюда напрашивается вопрос, зачем все эти шаманства с бубном возле конфига, если это дает минимум прироста производительности. Я бы сказал, это дает материальную точку.
P.S. в портах фри уже давно лежит nginx не только с nginx_upload_module, но и с nginx_upload_progress_module, который тоже отлично справляется с желанием пользователя закрыть страницу и избавляет программеров от головной боли.
Посмотрите на переделанный модуль expirelink
forum.nginx.org/read.php?21,17321
Он позволяет делать ограничения как по времени на ссылку, так и по IP адресу, на конкретный файл, а не на «в общем»
forum.nginx.org/read.php?21,17321
Он позволяет делать ограничения как по времени на ссылку, так и по IP адресу, на конкретный файл, а не на «в общем»
я бы построил это на nginx — php-fpm
закачка файла upload + upload_progress_module чтоб видеть прогресс закачки
скачивание защищал бы через access_key_module
не мудрил бы с реврайтами и конфиг сделал бы проще.
а в остальном оценка статьи положительная.
закачка файла upload + upload_progress_module чтоб видеть прогресс закачки
скачивание защищал бы через access_key_module
не мудрил бы с реврайтами и конфиг сделал бы проще.
а в остальном оценка статьи положительная.
Коллеги, извините за такой глупый и несколько не в тему вопрос, но как вы готовите spawn-fcgi?
У меня он постоянно тихо умирает раз в пару дней безо всякой видимой причины.
Причем — не на одном сервере…
У меня он постоянно тихо умирает раз в пару дней безо всякой видимой причины.
Причем — не на одном сервере…
Sign up to leave a comment.
nginx — строим свой letitbit