алгоритм балансировки

[Andrew Kopeyko]

On Mon, 22 Jan 2007, Mykola Zubach wrote:

> Насколько я вижу, сейчас применяется балансировка по кол-ву запросов.
> В связи с этим возникают следующие проблемы:
> 1. Неполная и неравномерная загруженность серверов.
>  Если в пуле один сервер - бенчмарк загружает его полностью.
>  Если добавить в пул ещё один сервер - загрузка будет составлять
> 80-100% в зависимости от условий.
> 2. Страдает отказоустовчивость.
>  В примере пула балансировки с двумя серверами если на одном из них
> ляжет апач например, нагрузка на второй сервер пойдет только если стоит
> net.inet.tcp.blackhole=0
>  Иначе nginx будет пытаться приконнектиться к лежащему серверу и в
> течении таймаута коннекта входящие запросы вообще не будут никуда
> форвардиться - так работает алгоритм балансировки.
>  Разумеется, net.inet.tcp.blackhole не помогает если один из серверов
> физически выключен - nginx будет время от времени его опрашивать и в
> это время продолжительный период запросы никуда не форвардятся.
>
>  Эти проблемы отпадают если перейти от балансировки по кол-ву запросов

Эта проблема отпадает при увеличении числа бэкендов хотя бы до трёх.
Падает один - продолжаем балансировать между двумя оставшимися.

А балансировать между единственным оставшимся бэкендом - да, это тяжело.

> к балансировке по кол-ву активных соединений с бек-ендами. То есть
> слать запрос на тот бек-енд, который обслуживает в данный момент
> наименьшее кол-во запросов.
>
>  Например, если на первый бек-енд пришло и отрабатывается 10
> тяжелых запросов по генерации контента, nginx может все остальные
> запросы слать на другой бек-енд, который занимается обработкой меньшего
> кол-ва запросов, до тех пор, пока не нагрузит его настолько, что кол-во
> обрабатываемых запросов сравняется с первым бек-ендом.
>
>  Алгоритм прост,

Ну, не скажите - вы же сами абзацем выше говорите о "тяжелых" и 
"нетяжелых" запросах. Значит, помимо числа обрабатываемых запросов нужно 
иметь ещё одну метрику - "тяжесть" каждого запроса. Это знает только 
бэкенд да Вы - как это тайное знание передать nginx'у? Разложить по URI 
- не получится ;-((

> но надо учитывать, что пока к какому-то бек-енду есть
> соединения в состоянии "Устанавливается" - этот бек-енд считается
> нерабочим (неподвержденная работоспособность) и новые запросы на него
> слаться не должны, разве что других бек-ендов с подтвержденной
> работоспособностью вообще нет в наличии. Суть в том что к каждому
> бек-енду не должно быть много устанавливающихся, но не
> установившихся (SYN-SENT) tcp-сессий, на случай если этот бек-енд
> действительно испытывает проблемы.

Таким образом вы насильно понизите максимальное число обрабатываемых одним 
бэкендом запросов до величины порядка
   1/(время_установления_соединения)

Не лучше ли добавить бэкендов? Заодно и проблему "балансировки между 
единственным оставшимся бэкендом" решите.

>

-- 
Best regards,
Andrew Kopeyko <kaa at zvuki.ru>
http://www.zvuki.ru/ sysadmin