Вопрос по архитектуре фотосайтов

youporn.com 100млн хостов в сутки :)

+картинки на разных сайтах открываются

замечая как эпизодически всякие крупнячки испытывают напряги с отдачей конкретного файла... ТАКИ ДА!

это её полностью изменит.

Борис, а тем временем напоминаю, что у NFS тюненгуемый кэш на уровне блоков... как на самом NFS сервере, так и на его клиенте. Современные админы обычно невкугсе про это. Про NFS мне чисто потроллить реально. Все что я делал на NFS успешно работает, за исключением мест где оно на выделенном сервере... ну там если он падает, то сами понимаете... падает всё. Мне просто неприятно когда кидают камень в старый и добрый NFS. Можно все перевести в плоскость раздачи файлов и системных вызовов. За всю историю юниксов оптимизационных фишек разных было много, но это всё не предназначалось для многогиговых сливов мелких или очень больших файлов. Есть простая оптимизационная задача рандомного чтения с дискового массива. Кстати, в Интернете очень много про алгоритмы работы рейдов написано... занимательное чтиво. Возвращаясь к теме NFS подмечу, что производительности по чтению файлов там предостаточно... оно всё как дополительный кэш-слой-диспетчер по распределению нагрузки.

Обычный программист скажет, что давайте файл быстренько подсосем в память и будем раздавать... самый популярный особенно.... 1% от 500 миллионов файлов будет превышать суммарный объем памяти всего кластера. Не мне Вам объяснять как это всё работает... ну если для других, то чуть чуть можно... во времена динозавров при раздаче большого файла было так: если блоковое чтение для одного клиента, то веб-сервер читает файл последовательно и раздает с учетом скорости скачки... а вот если для 1000 клиентов, то веб-сервер читай файл параллельно 1000 раз последовательно и раздает клиентам с учетом скорости скачки. Поясните мне таки на пальцах что с тех самых пор глобального изменилось?

kostich добавил 03.06.2011 в 02:19

А, забыл добавить... фотохостинг это не соц. сеть... давайте вот сделаем хостинг аватарок... какую эффективность кэша спрогнозируете?

ТС, есть такое вот решение:

/ru/forum/comment/7069575

А для любителей и ценителей NFS поясняю - оно не работает !!! Просто и доступно, имел очень хороший опыт работы с NFS когда обсматривали панельку Interworx , там есть собственная система кластеризации основанная на NFS, полугодичный тест системы всего то из 4х нод показал что 2-3-4-5 раз в неделю стабильно отваливается NFS, и именно он, ни тачка падает, ни каналы рвутся (везде 100Mb/s в приделах одной стойки), а просто теряется связь по NFS с нодами на которых разложен контент. Пример конечно не ярко описывает работу именно самого NFS но проблема в нашем случае были именно с ним ...... так как все остальные сервисы работают на ура, только вот контент не отдают, потому что он за NFS на соседней машине, открестился от использования такого рода системы сразу же .

Что касается альтернатив, куда лучше и проще например сливать через rsync данные даже при условии что изначально они будут попадать на основной сервер а не на тот который предназначен под картинки.... чем использовать NFS....

Андрейкин пример с xFS это конечно прикольно и я бы сказал правильно, но что-то гложет меня сомнение ввиду просмотра одного из его выступлений, где он ссылаясь на каких-то Cisco специалистов утверждает что схема кластеризации будет работать - такой подход я не разделяю :)

Romka_Kharkov добавил 03.06.2011 в 02:35

Процент вывести достаточно сложно, но скажу вам так , что в приделах 200 GB картинок (именно картинок) 3 сервера по 4 GB памяти, справляются с актуальными данным на ура. Т.е задействовано не более 10 GB памяти, естественно остальное подчитывается по требованию. (squid)

Актуальными данными в моем случае принято считать 5-10 % от общей массы, потому как есть скажем так "новые картинки" которые сейчас смотрят тысячи люде на разных сайтах, а есть картинки которые запрашивались полгода назад последний раз или запрашиваются 1 раз в полгода :)) Конечно если ВСЕ положить в память..... епта, не хватит памяти.... :)))) Мне кажется надо правильно оперировать кешом и будет счастье :)

Роман, когда я прошу девушку перерстать жевать устрицу и тупо её проглотить, то мы потом общаемся за вкус устриц. Если тупо проглить, то оно будет условно вкусно конечно... деликатес как никак... а если пожевать, то результат спорный... другое дело лобстеры какие или омары... так вот я NFS под фрей хаваю с 97 года и граждан что-то там поясняющих могу на раз спросить... NFS давно уже не устрица и повара в виде NetApp для неё не надо. Появились жамбафреймы, появились свичи умеющие наманую жамбу.. вы вкугсе зачем в свичах делают поддержку жамбафреймов?

поясните мне, пожалуйста, как нода может отвалиться от нфс сервера и умолчать о причине потери связи? это фантастика.

kostich добавил 03.06.2011 в 02:44

ну вот подсчитайте сколько будут 5% от 20Тб ... а если от 200Тб?

Спрашивайте, я не особый знаток NFS, я рассказал о том, что тестировал.

Джамбофреймы для увеличения производительности сети - угадал ? 🤣D:D

Причем тут одно к другому, я что сказал что он просто отваливается и все ? тишина? Тут тема не об этом, я рассказывал в другой теме на этом же форуме о том, как оно отваливается и почему, ловили Timeout... но пояснить его причины закономерными фактами не удалось, сервера в порядке, связь в порядке (проверено альтернативными тестами, т.е нет потерь, нет ошибок, нет коллизий, так же не падали порты в которые воткнуты ноды и прочее, или думаете я полгода наблюдал и не нашел причины в логах ??? :) ) и при всей вашей любви к джамбофреймам замечу, что таковые настройки не использовались, но простите, если NFS не работает нормально при стандартном размере кадра, то о чем можно говорить ? Вы еще скажите что для его нормальной работы надо пару свичей правильных купить, тогда я вас вовсе зауважаю :))))

P.S: Так же отдельно замечу что надобности в использовании нестандартных кадров не было, так как кластер к нодам передавал че-то около 30-50Mb/s :))) Т.е утилизация была вполне штатной.

Romka_Kharkov добавил 03.06.2011 в 02:48

А это сколько миллиардов*миллиарды аватар ?:))))

джамбо для увеличения производительности сетевых сервисов. вот это всё как форматирование диска. если на диске файлы по 1Гб минимум, то зачем этот диск мелкими кусками форматировать?

ну на дворе и сетевухи уже правильные есть, но это к сбоям вашей тестовой системы мало какого отношения имеет. диагностика штука сложная... источник подобных проблем примерно представляю, но это на живой системе надо проверять.

это к любому сервису относится, т.к. эффективность кэша при массовой раздаче от объема содержимого зависит... это к любому контенту относится.

Таки угадал :D :D, нет , пожалуй я знал! :D :D

(Я искренне надеюсь , что вы ошиблись относя JumboFrame к прикладному уровню OSI или что тогда "сетевой сервис"?)

А я разве сказал обратное? Я просто удостоверил вашу позицию, сказав, что при правильном оперировании кешом - будет счастье, а отдавать 20TRB как вы сказали естественно из памяти мало кто сможет, но думаю это все таки реально :) Не такая уж и заоблачная цифра для памяти что бы разнести это на кластер машинок, другой вопрос сколько это будет стоить и есть ли смысл в этом, так что склоняюсь к своевременной очистке кеша от ненужных данных, однако память то она оперативная.. :) Это ж не ПЗУ вам какое-то :D

И каков же по вашему мнению источник проблем, при условиях описанных выше? Проверки по сетевым интерфейсам никаких аномалий не показали, так же путем банального ICMP ping было проверено что из 10.000 пакетов потери составили 0% .... как еще это можно описать? карма?

А ошибка была как раз из серии "мистика", Timeout и все... куда уж тут конкретнее? глубже не ковыряли, решили просто отказаться... сама по себе скажем так "из коробки" схема не зажила, по этому к NFS у меня родилось ярое отвращение :( Но это субъективно на моем примере, но поверьте после такого теста рекомендовать его использовать я не буду, уж лучше самбу смонтировать или сырой glusterfs поднять чем NFS - IMHO.

Тут вы просто капитан очевидность :) что еще сказать, но вот спросите у ТС , ему надо оперировать 200 TRB данных ? или 20 TRB ? я че-то уверен что там и 1го TRB нету.... по этому земные объемы памяти ему вполне могут помочь.

Кстати из подобных по объему решений тестировал максимально массив ~50 TRB, при ужасно дорогом контролере стоимостью около 1k$ (Adaptec).

нет, не ошибся. жамбу придумывали для ускорения работы сетевых сервисов.

эффективность кэша будет близка к нулю. посмотрите на эффективность раздачи с 2Тб данных... 2Тб тумб в адалте это фигня.

дебаг надо было включать - раз, а сеть проверять большими пакетами - два.

я в контексте линейной массштабируемости и архитектуры... а ТС по ходу хватит и одного сервера.

ну у меня опыт больше с корзинами. а опыт такой, что резервную корзину под руками иметь надо в любом случае.

offtopic: вот читаю иногда SE и поражаюсь "NFS не работает", "ММ репликация в MySQL это миф". вот ведь "А мужики то не знают" ...

Обращайся, решу твою проблему.