ПРОЕКТЫ 


  АРХИВ 


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



Я думаю на гугл ровняться не стоит ;-)

В случае, если у человека 3 сервера, вполне возможно, что можно заменить их на 1-N более дорогих (на первое время N=1..2) серверов и это будет даже в перспективе дешевле и надёжнее (стоимость аренды места в датацентре, скорость передачи данных и т.п.).

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

 

Автору исходного письма можно посмотреть в сторону DRDB, SAN, iSCSI, возможность разнесения пользователей и их данных по серверам (если данные слабо связаны и можно их разместить в разных местах).

Относительно аппаратного балнсера... если у вас одна точка входа, то скорее всего ничто не мешает использовать DNS round robin. Возможно, даже, Linux VServer (http://www.linuxvirtualserver.org/).

 

но всё зависит от объёмов... и возможно на гугл ровняться придётся рано или поздно...

 

21.08.07, 21:16, Дмитрий Леоненко (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.