ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SAN organization



скорей всего они что то своё для этого написали ...

21.08.07, Дмитрий Леоненко<dmitry.leonenko@xxxxxxxxx> написал(а):
> Гм, мне кажется, или Google все таки хранит много данных и использует
> обыкновенные ДЕШЕВЫЕ сервера?
> Может дело в том, как организовать так хранение данных, что бы все было
> хорошо, а не вкидать во все большое $$ ?
>
>
> 21.08.07, Alexey Karagodov <karagodov@xxxxxxxxx> написал(а):
> > на хранение данных вам придётся потратить n-дцать кбаксов на систему
> > хранения данных (без всяких апачей, давов, нгинх-ов и пр. на ней) и
> > использовать её по сети. www.sun.com например. (там же и ТТХ различных
> > моделей, кто и чего и сколько может)
> > схема простая: данные - отдельно, их отдача - отдельно, их обработка -
> > отдельно. тогда будет меньше проблем с ростом.
> >
> > 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
> > >
> > >
> >
>
>


 




Copyright © Lexa Software, 1996-2009.