Сервер аналогичный "НАРОДУ.РУ"

[vasil-bazil]

Здравствуйте!
=========

Мы вышли на клиентскую базу более 8000 человек.
Предоставляем аналогичные услуги как на "НАРОДЕ". Плюс минус пару сервисов. Мы локализованы в России, но наши клиенты граждане другой страны.

Наше существующее решение просто ОТСТОЙ. Мы создавали его из оборудования, которое было под рукой. Ни о какой безопасности информации, бэкапах и т.д. и т.п. и речи не идёт.

Решение обвешаться нормальными железками уже перезрело.
Вот, обращаемя к специалистам. К сожалению, я даже не знаю, что нам нужно.

Прочитал тему "Система высокой готовности" автора TeRminaToR. Отличная тема. Хотел бы получить похожую консультацию по архитектуре нашего сервера.

По пунктам и не попорядку :
1. Наши клиенты получают доступ к нашему серверу из другой страны.
2. Операционная система - FreeBSD
3. Каждый клинет получает [неограниченное] дисковое пространство. (солянка, ограниченная общей ёмкостью наших дисков)
4. Увеличение клиентской базы, примерно 20-40% в год.
5. Отказы желательно свести к минимуму.
6. Бэкап информации нас устроит раз (два, три) в сутки.

Сейчас у нас несколько серверов, выполняющие разные задачи, объединённые между собой гигабитной сеткой.

Клиенты разделены на "слонов" и "мосек". Все файловые тяжеловесы перемещены на отдельный сервер, мелкота, соответственно, тоже на отдельном сервере. Код программы, тоже на отдельном серваке. Аналогично, мейл и другие сервисы. Под каждый сервис - один сервак. Итого - куча машин, собраных на коленке...

Подскажите пожалуйста, какая железяка будет хороша для нас?

[a_shats]

Ну, во-первых, afaik, на народе.ру не один сервер .
И ОС - FreeBSD - несколько, имхо, не очень приятное ограничение. Дело в том, что "кластерные" ФС (допускающие шаринг на несколько серверов) - SANbolic Melio, Veritas File System - не имеют, afaik, под нее дров.
Я бы сделал примерно так:
FC storage (с дублированными контроллерами, БП) - FC Switch - сервера.
Это как бы "бюджетное" решение. Те FC-контроллеры, что предлагаются у нас (RIO,RIVA) - наращиваются FC JBOD (правда, если у Вас планируется нечто не FC-FC, а FC-SCSI, FC-SATA (не быстрое решение, сразу предупреждаю) - то выбор только из RIVA ).
Для собственно серверов - было б хорошо получить данные о нагрузках на подсистемы (загрузка процессоров, памяти и т.п.).

[vasil-bazil]

У нас тоже несколько серверов. Это нормально. На одной железяке, конечно, далеко не уедешь. Уже давно надо садиться разу на несколько железных коней одновременно.

Все наши системы уже перегружены. Чуть легче себя чувствует файловый сервер со "слонами", так как он держит меньше пользователей нашей системы.

Загрузка системы примерно такая:
в тихий период мы имеем от 2000 до 3000 подключений. Это примерно ночь по загранице. В активное время, до 100000 подключений и более, ресурсов катастрафически нехватает. Под новый год, был пик за час более 180000 подкючений. Сервер с системой сдох. Срочно востановили Standby. Файловые серверы вроде как выжили.

Мы готовы и не на быстрые решения. Пока ограничимся подкупкой новых компов "на коленках".

[setar]

Я вижу решение примерно так:


Некоторые пояснения:
канал (а лучше несколько) приходит от провайдера и через какую нибудь грамотную железяку типа киски превращаются во входной канал, который подаётся на кластер раскидывающий запросы по машинам, обслуживающими данный адрес. В этом же кластере рационально поднять firewall и NAT (если требуется).

Таким образом поток запросов раскидывается по некоторому числу application машинок, которые в свою очередь подключены через fibre channel к массиву и через гигабит к кластеру баз данных.

Как будут распаралеливаться задачи - дело ваше. общие мысли такие:

• Лучше всего все аппликейшн машины связать в кластер, в качестве heartbit используя либо switch связи с BD либо использовать дополнительный. Стандартный софт как я понимаю полностью не подойдёт ни один, нужно писать самим. Пользовательские данные в этом варианте нужно держать на NAS (внешнее хранилище).
• Другой вариант - типа того что у вас есть сейчас - рассаживать пользователей "садками" по машинам. Пользовательские данные при этом храняться на апликейшн машине.
• Есть интересная технология распаралеливания отдаваемую информацию таким образом : картинки идут с одной машины, файлы с другой, готовый html с третьей. но в этом варианте необходима однородность данных у клиентов - чтобы по каталогу можно было определить что за данные льются. Например разбиваем по машинам каталоги /img /html /files.

[aden]

С нагрузкой как у Народа может справиться 1-2 машины.

Естественно, если речь только о сервисе бесплатного хостинга.
И если у кого-то не справляется, то надо переписывать движок, а не плодить кучу железа.
В частности, мой партнер держит хостинг (около 70-80%% от объема Народа) на Dual-P-III + 4 IDE винта по 200.

Бэкапы на таком сервисе три раза в день - это только если некуда деньги потратить.
Потому что под бэкапы нужна отдельная машина рядом в стойке, а еще лучше - на другой площадке.
И гонять по террабайту три раза в день - непонятно для какой цели.
Думаю, у вас глюков и без бэкапов будт достаточно.
А частые бэкапы могут привести к тому, что может не остаться работоспособной копии.

Что имелось в виду под Подключениями? Видимо - открытые коннеты.

Обычно обычный целерон с гигом памяти прекрасно держит до 600 одноврменно запущенных апачей.

Трафик в 180к коннектов в час - не самый маленький.
Но вот например, один из web-раздатчиков (дуал Х-4, 1 гб, 4 SCSI) постоянно обрабатывает по 50 запросов в секунду и не бывает нагружен более чем на 10 %% )
До тех пор пока не пойдет обсчет логов (там бывает нужна эта операция).

Резюме: вам скорее нужен грамотный архитектор сервиса, чем продолжать наращивать железо.

[a_shats]

vasil-basil
Предпосылки к расчету примерно следующие:
1. Нагрузкана дисковую: практически только чтение со случайным доступом и множеством потоков.
2. Требуемые от дисковой подсистемы IOps :
Посмотрите, сколько у Вас на существующем решении уже есть обращений к диску в секунду (IOps ) и очередь (Disk Command Queue) - очередь растет, когда дисковая не успевает обрабатывать запросы.
Для справки: один винт 10К выдает примерно 230-300 IOps, 15K - до 500 IOps. MegaRAID 320-1 и 320-2 из кэша выдают 5-7 тыс. IOps, MegaRAID 320-2X - до 26 тыс. IOps; контроллеры во внешних FC массивах Chaparral (RR-1600-FC, RR-1422-LVD-FC) выдают до 15К IOps, но на них вешается 14-16 винтов; контроллер Chaparral RIVA (R2500) выдает около 100 тыс. IOps.
Вот и посчитайте.
3. Требуемая конфигурация и количество серверов:
Прикиньте на существующей конфигурации количество пользователей, при котором один сервер нагружен (на все подсистемы) не более 60%.
Сообщите здесь конфигурацию. Общее количество пользователей известно.
4. Требуемое активное оборудование: тут исходим из трафика и пропускной способности линии "наружу" - соответственно, подбираем оборудование. Каков будет трафик между серверами - зависит от софтового решения: если это будет кластер - предпочтителен гигабит до каждого сервера. В плане безопасности предпочтительны коммутаторы уровня не менее L3. Это если нет дополнительных сервисов, требующих способностей коммутаторов L4.
Замечу лишь, что любимым оборудованием провайдеров является продукция Cisco .

Плюс ко всем перечисленным пунктам - необходимо предусмотреть резерв. Темпы роста Вашего проекта Вам известны, т.е. по оборудованию необходимо предусмотреть такой резерв, чтобы при существующих темпах роста вся система дожила до планируемого апгрейда.
По сети: обычно при проектировании СКС закладывается резерв 50%.
Для того, чтобы можно было быстро подключить или перенести устройства без реконфигурирования СКС.
По оборудованию: заметим, что та же RIVA очень хорошо масштабируется: у нее 4 хостовых порта, т.е. к ней можно подключить 2 FC-свича без потери отказоустойчивости. В смысле - при откразе любого из ее двух контроллеров ничего страшного не произойдет. Далее - на ту же Риву можно привесить впоследствии до 14 корзин JBOD с винтами - т.е. наращивать массив, просто докупая эти самые корзины и без переконфигурации SAN.
Уфф...Собственно.

[a_shats]

Вдогонку:
aden
Никакой грамотный архитектор сервиса на растущей системе не поможет. А помогут лишь правильное изначальное проектирование, с учетом необходимых резервов и обязательным расчетом на будущее масштабирование...
Имхо.

[aden]

Видите ли: вы говорите об идеальной системе, а я - о реапьно работающей.

[a_shats]

aden
Я говорю не об идеальной, а о правильной системе .
А по поводу реально работающей: у Вас есть 8000 виртуальных хостов ?

[aden]

Вы о каких хостах?
Елли об уникальных посетитяелях сервиса бесплатного хостинга в день - то да, одна машина легко держит более 300 тыс уников в день.

Если еще точнее: на одной машитне лежит несколько десятков тысяч сайтов (домены третьего уровня), к которым обращается ежедневно более 300 тысяч человек.

[a_shats]

Нет. Я именно о хостах, т.е. клиентах.
А трафик и запросы от клиентов... Вы PHP/Perl/CGI/всякое такое прочее на своей этой одной машине поддерживаете ?

[aden]

Все-таки давайте определимся.

Василий писал:
"Мы вышли на клиентскую базу более 8000 человек. "

Применительно к сервису типа НародРу - это всего 8 тыс сайтов.
Такой объем сайтов может привлечь не более 150 тыс уников в день.


"А трафик и запросы от клиентов... Вы PHP/Perl/CGI/всякое такое прочее на своей этой одной машине поддерживаете ?"

Задача не ставилась Василием на счет PHP/Perl/CGI

И на Народе этого нету.

И не будет: потому что массовый БЕСПЛАТНЫЙ сервис со всеми фичами Платного - он НЕ НУЖЕН. Почему не нужне - тема отдельной беседы.

А сейчас: в исходных данных не было ни слова о скриптовой нагрузке, с чего вы взяли что она есть?

[a_shats]

ОК, тогда закрываем спор до выяснения характера нагрузки ?
vasil-basil
Пожалуйста, опишите всё-таки характер нагрузки - в плане наличия тех самых ресурсоемких дополнительных сервисов.

[gs]

Не совсем в тему, но по теме:)
Может быть не стоит ориентироваться на народ.ру? Это как раз пример как не надо делать. Пусть он и бесплатный, но когда страница по несколько минут грузится и закачка 1кБ/с - это издевательство.

[aden]

Сервисы, подобные Народу, виснут чаще по софту, чем по железу.

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

Но в данном случае предложенное решение, увело бы в тупик: кластер громоздился бы на кластер.
А элегантное решение (а с их трафиком им нужна одна машина ) осталось бы за бортом.

Итог неправильной архитектуры проекта (софтовой) в итоге наказывается нарастанием крашей.

Но, с другой стороны, задача Василием поставлена однобоко: он ищет очевидного и быстрого решения за счет наращивания железа. Такое решение, конечно, можно изобрести - и предлоеженное Тринити - не худшее.

Можно и одним скриптом нагрузить машину на 100%%. Но это на значит, что сразу надо разносить нагрузку. Может быть все же посмотреть, почему этот скрипт так грузит?