По какой-то причине ipvsadm, похоже, не одинаково балансирует соединения между моими реальными серверами при использовании планировщиков wlc или lc. Один реальный сервер полностью забивается запросами, в то время как другие получают относительно мало соединений.
Мой файл ldirectord.cf выглядит так:
quiescent = yes
autoreload = yes
checktimeout = 10
checkinterval = 10
# *.example.com http
virtual = 192.0.2.111:http
real = 10.10.10.1:http ipip 10
real = 10.10.10.2:http ipip 10
real = 10.10.10.3:http ipip 10
real = 10.10.10.4:http ipip 10
real = 10.10.10.5:http ipip 10
scheduler = lc
protocol = tcp
service = http
checktype = negotiate
request = "/lb"
receive = "Up and running"
virtualhost = "site.com"
fallback = 127.0.0.1:http
Странная вещь, которая, как мне кажется, может вызывать проблему (но я действительно не уверен), заключается в том, что ipvsadm, похоже, не отслеживает активные соединения должным образом, все они выглядят как неактивные соединения
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.0.2.111:http lc
-> 10.10.10.1:http Tunnel 10 0 10
-> 10.10.10.2:http Tunnel 10 0 18
-> 10.10.10.3:http Tunnel 10 0 3
-> 10.10.10.4:http Tunnel 10 0 10
-> 10.10.10.5:http Tunnel 10 0 5
Если я сделаю ipvsadm -Lnc то я вижу много соединений, но только в состояниях ESTABLISHED и FIN_WAIT.
Раньше я использовал ldirectord на балансировщике нагрузки на основе Gentoo, и activeconn был точным, поскольку при переходе на Ubuntu 10.4 LTS что-то вроде бы изменилось.
# ipvsadm -v
ipvsadm v1.25 2008/5/15 (compiled with popt and IPVS v1.2.1)
Итак, ipvsadm не отслеживает активные соединения должным образом и, таким образом, приводит к некорректной работе балансировки нагрузки, и если да, то как мне заставить его снова работать правильно?
Редактировать: Становится еще более странным, если я cat /proc/net/ip_vs тогда похоже, что там есть правильные activeconns:
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP C000026F:0050 rr
-> 0AB42453:0050 Tunnel 10 1 24
-> 0AB4321D:0050 Tunnel 10 0 23
-> 0AB426B2:0050 Tunnel 10 2 25
-> 0AB4244C:0050 Tunnel 10 2 22
-> 0AB42024:0050 Tunnel 10 2 23
С lc (наименьшее соединение), если все серверы имеют одинаковое количество подключений, он всегда будет предоставлять новое подключение к первому серверу в списке. Это может означать, что если у вас очень низкая загрузка и только время от времени соединение, это соединение всегда будет переходить к первому хосту в списке.
Выходные данные команды Дэвида указывают, что он использует режим туннеля (IPIP), который обычно настраивается как вариант DR. Нам нужно увидеть некоторые таблицы маршрутизации или диаграммы, чтобы лучше понять его настройку.
Но я согласен, что, вероятно, отслеживание соединений в LVS сбивает с толку, поскольку оно не видит пакеты TCP FIN.
ipvsadm имеет некоторые настройки для более быстрого тайм-аута истекших соединений. Например, следующая команда отключит неактивные соединения через 1 час:
/sbin/ipvsadm --set 3600 120 300
Необходимо дважды проверить источник клиентов. По умолчанию LVS устанавливает постоянные соединения по клиентскому IP. Таким образом, при стресс-тестировании с помощью wget или ab с одного и того же IP-адреса тестового клиента все соединения будут отправлены на один и тот же реальный сервер.
Haproxy - это более интеллектуальный балансировщик нагрузки, но он должен находиться на пути возврата пакетов, чтобы работать полностью прозрачно.
Судя по вашему количеству подключений, это, вероятно, не проблема для вас, но вы можете получить неравномерное распределение с наименьшим количеством подключений, если один из реальных серверов отвечает медленнее, чем другие, тогда он будет получать меньше новых подключений за раз, чем другие, поскольку он быстрее накапливает соединения.
Мой фаворит - wrr (круговое взвешивание). Правильно ли я предполагаю, что вы используете DR-подход (прямая маршрутизация)?
В этом случае ipvsadm не видит соединение как таковое, поскольку ответ от RS (реального сервера) будет идти непосредственно клиенту, а не обратно через LB.