высоко нагруженный проект. 10млн. запросов в сутки. балансировка.

[440hz]

высоко нагруженный проект. 10млн. запросов в сутки. балансировка.

стоит задача распределить наргузку 10млн. запросов в сутки (обмен трафиком) между несколькими серверами. никогда такого еще не делал.

как грамотнее разделить нагрузку между несколькими (много-много) серверами-зеркалами?

на уровне железа? чем именно? какие решения?

на уровне front-server? какие связки? apache не выдержит такого? тогда FastCGI? nginx+FastCGI? есть что-то еще более легкое?

на уровне DNS отдачи? когда DNS возвращает различные IP?

кто как делал?

 

[MiksIr]

[ балансер 1 (актив)      ] --- LVS --- [ front-end nginx1 ] -.  .- [ back-end (fast-cgi or apache+mod_php) ]
    ^                              \----[ front-end nginx2 ] -|--|- [ back-end (fast-cgi or apache+mod_php) ]
   carp or heartbeat                \---[ front-end nginx3 ] -`  `- [ back-end (fast-cgi or apache+mod_php) ]
    v                                \-- ....
[ балансер 2 (неактив)  ]

-~{}~ 20.08.08 02:16:

Уффф...
В общем, по существу... нужно знать сколько в пиках запросов в секунду и что это за запросы (т.е. это запросы в динамику, в статику и т.д.)
Например, 10 млн запросов в сутки сделанным по нескольким статическим файлам можно отбить 1-2 серверами.
Далее, DNS балансинг ацтой с точки зрения доступности - ибо очень большое для клиента время перехода клиентов на запасную ноду при падении (за счет кеширования DNS). С точки зрения балансинга тоже не ахти, ибо очень сложно равномерно грузить ноды - может случится перекос и перегрузка одной из нод.
Т.е. клиент должен приходить на одну железку. Для HA эту железку стоит продублировать, конечно же.
Далее так - если затык в раздаче динамики и никак ее не закешировать, то балансим на уровне http обычным nginx. Статику отдаем прям с этой же машины.
Далее, если не хватает отдавать статику (затык в дисках) - балансим и ее тожа.
Дальше уже, если и этого не хватает, т.е. не хватает ресурсов одной машинки для балансинга на http уровне, то смотрим в сторону или специальных железок или линукса с LVS - т.е. по сути начинаем балансить уже на уровне IP. Там тоже есть много интересных схем, но вряд ли это пригодится для поставленной выше задачи =)

-~{}~ 20.08.08 02:19:

Далее, бекенд может быть или php в режиме fastcgi или apache+mod_php. В общем, что лучше - это holy war. Одни по старинке с апачем, те, кто помоложе и за новыми течениями - те с fastcgi =))

-~{}~ 20.08.08 02:20:

Фронт-енд однозначно nginx =) ну или lighttpd если уж очень привычнее =)

-~{}~ 20.08.08 02:21:

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

 

[440hz]

спасибо. так и сделаем.

 

[Wicked]

MiksIr
а зачем одновременно и балансер, и lvs ?
разве это не взаимозаменяемые вещи?

440hz
для балансинга можно еще пощупать http://www.danga.com/perlbal/ , который используется (-ался?) в ЖЖ.
сам сталкивался с ним только в рамках MogileFS, балансинг в нем не использовал.

 

[fixxxer]

та фигня, на самом деле, как нибудь балансить, и работать будет, а вот есть ли там mysql?

 

[MiksIr]

Wicked, на картинке балансер и есть LVS, просто неудачно нарисовал

 

[440hz]

fixxxer

mysql в проекте есть. ооочень думаю как все будет жить....

по сути будет так. балансер раскидывает все на ноды. на нодах mysql слейвами к основной базе только на чтение. сама база отдельный сервер тока на запись/изменение. так же будет еще один mysql сервер который будет писать все транзакции ( те самые 10 лямов в сутки) и по часам (статистика нужна только на часы) их обрабатывать и пистаь уже в основную базу готовую статистику.

узкое место только БД. как это разрулить уже не знаю... 10 лямов в сутки второй сервер выдержит. это проверено. статистику пересчитает и на 1-ый скинет. то ж не проблема. вот как основной сервер БД разрулить ума пока не приложу.

-~{}~ 25.08.08 16:20:

fixxxer

при добавлении новой ноды (сервера) надо будет делать репликацию слейва с мастера. не возникнет проблем? просто указать там слейв с новым номером и по идее репликация все пройдет нормально?

-~{}~ 25.08.08 16:43:

тут еще есть идея на нодах поднять mysql-кластер. как он в обслуживании? кто юзал?

 

[fixxxer]

репликация спасет только на некоторое время - пока не станет много IUD операций
советую задуматься о горизонтальном масштабировании - но это конечно требует достаточно больших изменений в коде.

 

[440hz]

оветую задуматься о горизонтальном масштабировании

пару слов об этом или как решить? в проект пока можно внести изменения на таком уровне.

 

[MiksIr]

Эффективно при наличии нескольких равнонагруженных таблиц (групп таблиц). В этом случае выделяешь несколько кластеров БД, каждый из которых занимается своей таблицей.

 

[440hz]

читаю про кластер. собрать вроде не проблема. но правильно ли я понимаю что там все хранится в оперативке или это меня глючит?

 

[флоппик]

правильно ли я понимаю что там все хранится в оперативке

там табличка должна помещатся в память целиком.

 

[fixxxer]

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

если типичный веб-два-ноль - то шардинг по user_id.

кластер... ну хрен его знает, я его боюсь пока. шардинг ятд надежнее из общих соображений.

-~{}~ 25.08.08 18:26:

>>там табличка должна помещатся в память целиком.
вроде как уже нет?

 

[Wicked]

мне кажется, MiksIr под кластером имел в виду не тот самый MySQL Cluster, за изучение которого принялся 440hz

кластер... ну хрен его знает, я его боюсь пока

+1

-~{}~ 25.08.08 21:36:

(обмен трафиком)

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

 

[флоппик]

10млн. запросов в сутки. балансировка.

Кластер:
Throughput of 10,000+ replicated transactions/sec on a 2 Node Cluster, with 1 CPU Per Node (minimal configuration)

>>там табличка должна помещатся в память целиком.
вроде как уже нет?

ну... в принципе, да: Cluster is primarily an in-memory database, but _provides_ optional disk-based data all available via a SQL interface or optionally via a Java or high-performance native C++ interface using the Carrier Grade Edition.

 

[MiksIr]

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

 

[флоппик]

при добавлении новой ноды (сервера) надо будет делать репликацию слейва с мастера. не возникнет проблем? просто указать там слейв с новым номером и по идее репликация все пройдет нормально?

по идее, лучше ему скормить бекап и указать смещение в бинарном логе, иначе он месяц реплицироваться будет...

 

[440hz]

ну ты намекни что за проек

собственно я никогда не скрывал ничего из того, что делал... =)
=========
проект - продажа трафика, т.е. кликов/переходов. узкое место БД. вот думаю о решении.

- балансер FreeBSD+nginx (тут все понятно)

- ноды - обычные стоечные сервера. 2 проца, 4 ядра, 4Г памяти. быстрые винты. суть в том, что нода должна быть стандартной. нужно новая нода. воткнул обычный сервер. поствил софтинку и все зажило с новой нодой.

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

нод будет много. на старапе 3-5. мастер + 2-4 слейв. это только под скрипты. далее при возрастании нагрузок ноды будут просто втыкаться. тут все понятно. воткнул ноду. засинхронил с мастер по rsync или как еще. указал в балансировщике новую ноду и все.

с БД думал на нодах иметь слейвы с мастераДБ и локально оттуда селекить. с кластером пока непонятно. вроде все красиво. отказоустойчивость на ура. в случае слейвов при выходе мастерДБ всем пипец.

с учетом того что будет примерно 10 лямов записей в сутки. даже при их обработке на уровень часа все равно массивы данных зашкалят. кластер такое выдержит? сейчас на похожем проекте база 20Г. проект дохнет и умирает из-за не возможности масштабирования. железо по максимуму, но все равно в пиках все жохнет. но не это суть. просто там хоть есть примерные цифры и объемы.

вот и упираюсь который день в архитектуру проекта на уровне БД, а завтра заказывать серваки надоть уже... и если с www решением все просто (балансер+ноды), то с базой вот сижу, читаю, пью пиво, думаю. жду ваших, хоть намеков на пути решения данной ситуевины.

репликация vs кластер. холивар?

 

[флоппик]

в случае слейвов при выходе мастерДБ всем пипец.

необязательно, можно и одного из слейвов настроить на подхват. Но Сluster это автоматизирует и так.

а с у четом того, что я пока знаю, то БД в кластере должна умесчаться в память не катит.

Не вся БД, а любая табица в БД.

 

[440hz]

Не вся БД, а любая табица в БД.

грубо говоря любая табица должна весить примерно 1-2Г максимум? ну тут уже есть чем поиграть. пережелдать структуру базы. разбить большие таблицы на составляющие... уже полегче.

очень хочется попробовать кластер. репликации делал. ставил на боевые сервера. се пашет.

кластер не пробовал, но вот склоняюсь к нему...

посмотрел старые таблицы. в общем ни одна таблица за 1Г не вылезает. это за 3 года работы системы. это радует.