ПРОЕКТЫ 


  АРХИВ 


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]

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



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

  Эти проблемы отпадают если перейти от балансировки по кол-ву запросов
к балансировке по кол-ву активных соединений с бек-ендами. То есть
слать запрос на тот бек-енд, который обслуживает в данный момент
наименьшее кол-во запросов.

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

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



 




Copyright © Lexa Software, 1996-2009.