Гм, мне кажется, или Google все таки хранит много данных и использует обыкновенные ДЕШЕВЫЕ сервера? Может дело в том, как организовать так хранение данных, что бы все было хорошо, а не вкидать во все большое $$ ?
на хранение данных вам придётся потратить n-дцать кбаксов на систему хранения данных (без всяких апачей, давов, нгинх-ов и пр. на ней) и использовать её по сети. например. (там же и ТТХ различных
моделей, кто и чего и сколько может) схема простая: данные - отдельно, их отдача - отдельно, их обработка - отдельно. тогда будет меньше проблем с ростом.
21.08.07, Goncharov Yuri<
neo@xxxxxxxxxx> написал(а): > Hi all. Простите, если немножко не в тему, возможно просто используя тот же nginx я смогу решить свою задачу. > > Есть достаточно большой проэкт. > 5Тб трафика в месяц, 15 миллионов хитов в день.
> > > На данный момент проэкт расположен на 3-х серверах. Далее планируется масштабируемость за счёт наращивания числа бекендов при необходимости. > Во фронтенде всё "встречает" nginx - напрямую отдаёт статику, динамика уходит с ip hash на 2 upstreamа (apache+mod_php)
> Для того чтобы обеспечить единый source организовано NFS-connectivity, где весь контент уложен на фронтенд (т.к графические файлы > занимают 90% всего проэкта) - это NFS-server, и два бекенда - NFS-клиенты.
> На данный момент проблем нет, но я не уверен в стабильности такого NFS-connectivity ввиду того, что нагрузка постоянно растёт и боюсь, что > в определённый момент начнут происходить затыки именно в NFS-схеме. Как минимум,я не имею понятия об инструменте как такую NFS-схему мониторить.
> > Какие ещё есть варианты с организацией SAN при условии что: > > 1) Над проэктом периодически работают девелоперы и заливать исправленный контент сейчас на 3 сервера, далее на n - слишком накладно.
> 2) В проэкте предусмотрена заливка файлов (медиа) через веб, где данные должны быть сохранены в виде файла на диске. Различные варианты в стиле > в блоб и в базу не подходят в виду огромного кол-ва таких файлов. Приблиз порядка миллионов файлов с общим весом в 100Гб.
> 3) Сохранить отказоустойчивость в случае выхода одного из серверов из строя. Тут имеет ввиду что несколько позже вместо одного фронта будет два > и перед ними поставится аппаратный балансер, то есть недостатки в данной схеме отказоустойчивости ещё на уровне точки входа просьба не учитывать.
> 4) В случае выведения из строя одного из участников SAN-схемы происходит синхронизация после возвращения такого участника в "жизнь". > > Допустим варианты с rsync не пробовал, но очень верю в том, что при миллионе файлов такое работать не будет.
> Про MogileFS только читал, но есть много и нехороших отзывов на предмет п.4 указанного выше. > > Жду любые советы, рекомендации, линки. Спасибо огромное заранее.. > > -- > Best regards
> > Phone +380 44 426 8812 > CTO KNtelecom Ukraine Ltd. > ---------------------------- > NEO83-RIPE > >
