HAProxy корректная перезагрузка с нулевой потерей пакетов

Edit: Мой ответ предполагает, что кернел посылает трафик только на самый последний порт, который будет открыт с помощью SO_REUSEPORT, в то время как на самом деле он посылает трафик всем процессам, как описано в одном из комментариев. Другими словами, танец iptables все еще необходим. :(

Если вы находитесь на ядре, которое поддерживает SO_REUSEPORT, то этой проблемы не должно быть.

Процесс, который принимает хапрокси при перезапуске:

1) Попробуйте установить SO_REUSEPORT при открытии порта. (https://github.com/haproxy/haproxy/blob/3cd0ae963e958d5d5fb838e120f1b0e9361a92f8/src/proto_tcp.c#L792-L798)

2) Попробуйте открыть порт (получится с SO_REUSEPORT)

3) Если не получилось, сообщите старому процессу о закрытии порта, подождите 10 мс и попробуйте все заново. (https://github.com/haproxy/haproxy/blob/3cd0ae963e958d5d5fb838e120f1b0e9361a92f8/src/haproxy.c#L1554-L1577)

Впервые он поддерживался в ядре Linux 3.9, но некоторые дистрибутивы сообщили об этом обратно. Например, ядра EL6 из 2.6.32-417.el6 поддерживают его.

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

True Zero Downtime HAProxy Reloads

tl; dr использует Linux tc (управление трафиком) и iptables для временной постановки в очередь SYN-пакетов, пока HAProxy работает. перезагружается и к одному и тому же порту прикреплены два pid ( SO_REUSEPORT ).

Мне неудобно повторно публиковать всю статью о ServerFault; тем не менее, вот несколько отрывков, которые вызовут ваш интерес:

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

# plug_manipulation.sh
nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug --buffer
service haproxy reload
nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug --release-indefinite

# setup_iptables.sh
iptables -t mangle -I OUTPUT -p tcp -s 169.254.255.254 --syn -j MARK --set-mark 1

# setup_qdisc.sh
## Set up the queuing discipline
tc qdisc add dev lo root handle 1: prio bands 4
tc qdisc add dev lo parent 1:1 handle 10: pfifo limit 1000
tc qdisc add dev lo parent 1:2 handle 20: pfifo limit 1000
tc qdisc add dev lo parent 1:3 handle 30: pfifo limit 1000

## Create a plug qdisc with 1 meg of buffer
nl-qdisc-add --dev=lo --parent=1:4 --id=40: plug --limit 1048576
## Release the plug
nl-qdisc-add --dev=lo --parent=1:4 --id=40: --update plug --release-indefinite

## Set up the filter, any packet marked with “1” will be
## directed to the plug
tc filter add dev lo protocol ip parent 1:0 prio 1 handle 1 fw classid 1:4

Сводка: https://gist.github.com/jolynch/97e3505a1e92e35de2c0

Приветствуем Yelp за то, что они поделились такой потрясающей информацией.

Есть еще один гораздо более простой способ перезагрузить haproxy с истиной нулевое время простоя - это называется iptables flipping (на самом деле статья представляет собой ответ Unbounce на решение Yelp). Это чище, чем принятый ответ, поскольку нет необходимости отбрасывать какие-либо пакеты, что может вызвать проблемы при длительной перезагрузке.

Вкратце, решение состоит из следующих шагов:

1. Давайте иметь пару экземпляров haproxy - первый активный, который получает трафик, а второй в режиме ожидания, который не получает никакого трафика.
2. Вы перенастраиваете (перезагружаете) ) резервный экземпляр в любое время.
3. Когда резервный готов с новой конфигурацией, вы перенаправляете все НОВЫЕ соединения на резервный узел, который становится новым активным . Unbounce предоставляет сценарий bash, который выполняет переключение с помощью нескольких простых команд iptable .
4. На данный момент у вас есть два активных экземпляра. Вам нужно подождать, пока не прекратятся открытые соединения с старым активным . Время зависит от вашего поведения службы и настроек поддержания активности.
5. Прекращается трафик на старый активный , который становится новым резервным - вы снова возвращаетесь к шагу 1.

Кроме того, Решение может быть адаптировано к любому типу службы (nginx, apache и т. д.) и более отказоустойчиво, так как вы можете протестировать резервную конфигурацию до того, как она перейдет в оперативный режим.

Я объясню свою настройку и то, как я решил плавную перезагрузку:

У меня типичная настройка с 2 узлами, на которых запущен HAproxy и поддерживается активность. Keepalived отслеживает интерфейс dummy0, поэтому я могу выполнить «ifconfig dummy0 down», чтобы принудительно переключиться.

Настоящая проблема в том, что, я не знаю почему, «перезагрузка haproxy» по-прежнему отбрасывает все УСТАНОВЛЕННЫЕ соединения :( Я попробовал "iptables flipping", предложенный gertas, но я обнаружил некоторые проблемы, потому что он выполняет NAT на IP-адресе назначения, что не является подходящим решением в некоторых сценариях.

Вместо этого я решил использовать грязный хак CONNMARK для пометить пакеты, принадлежащие НОВЫМ соединениям, а затем перенаправить эти помеченные пакеты на другой узел.

Вот набор правил iptables:

iptables -t mangle -A PREROUTING -i eth1 -d 123.123.123.123/32 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i eth1 -p tcp --tcp-flags FIN FIN -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i eth1 -p tcp --tcp-flags RST RST -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i eth1 -m mark ! --mark 0 -j TEE --gateway 192.168.0.2
iptables -t mangle -A PREROUTING -i eth1 -m mark --mark 1 -j DROP

Первые два правила отмечают пакеты, принадлежащие новым потокам (123.123.123.123 - это поддерживаемый VIP-адрес, используемый на haproxy для привязки внешних интерфейсов).

Третье и четвертое правила маркируют пакеты FIN / RST-пакеты (я не знаю, почему цель TEE «игнорирует» FIN / RST-пакеты).

Пятое правило отправляет дубликат всех помеченных пакетов на другой прокси-сервер HA (192.168.0.2).

Шестое правило отбрасывает пакеты, принадлежащие новому flo ws, чтобы предотвратить достижение исходного пункта назначения.

Не забудьте отключить rp_filter на интерфейсах, иначе ядро ​​отбросит эти марсианские пакеты.

И последнее, но не менее важное: обратите внимание на возвращаемые пакеты! В моем случае есть асимметричная маршрутизация (запросы поступают на клиент -> haproxy1 -> haproxy2 -> веб-сервер, а ответы идут с веб-сервера -> haproxy1 -> клиент), но это не влияет. Он работает нормально.

Я знаю, что самым элегантным решением было бы использовать iproute2 для перенаправления, но это сработало только для первого пакета SYN. Когда он получил ACK (3-й пакет трехстороннего рукопожатия), он не пометил его :( Я не мог тратить много времени на исследование, как только я увидел, что он работает с целью TEE, он оставил его там. Конечно, вы можете попробовать это с iproute2.

В основном, "изящная перезагрузка" работает следующим образом:

1. Я включаю набор правил iptables и сразу вижу, что новые соединения идут к другому HAproxy.
2. Я сохраняю следите за "netstat -an | grep ESTABLISHED | wc -l" для наблюдения за процессом "осушения".
3. Если имеется всего несколько (или ноль) соединений, "ifconfig dummy0 down" заставит keepalived переключиться на отказ, поэтому весь трафик будет идти на другой прокси-сервер HA.
4. Я удаляю набор правил iptables
5. (только для «не вытесняющей» конфигурации keepalive) «ifconfig dummy0 up».

Набор правил IPtables может быть легко интегрирован в начало / stop script:

#!/bin/sh

case $1 in
start)
        echo Redirection for new sessions is enabled

#       echo 0 > /proc/sys/net/ipv4/tcp_fwmark_accept
        for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f; done
        iptables -t mangle -A PREROUTING -i eth1 ! -d 123.123.123.123 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1
        iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
        iptables -t mangle -A PREROUTING -i eth1 -p tcp --tcp-flags FIN FIN -j MARK --set-mark 2
        iptables -t mangle -A PREROUTING -i eth1 -p tcp --tcp-flags RST RST -j MARK --set-mark 2
        iptables -t mangle -A PREROUTING -i eth1 -m mark ! --mark 0 -j TEE --gateway 192.168.0.2
        iptables -t mangle -A PREROUTING -i eth1 -m mark --mark 1 -j DROP
        ;;
stop)
        iptables -t mangle -D PREROUTING -i eth1 -m mark --mark 1 -j DROP
        iptables -t mangle -D PREROUTING -i eth1 -m mark ! --mark 0 -j TEE --gateway 192.168.0.2
        iptables -t mangle -D PREROUTING -i eth1 -p tcp --tcp-flags RST RST -j MARK --set-mark 2
        iptables -t mangle -D PREROUTING -i eth1 -p tcp --tcp-flags FIN FIN -j MARK --set-mark 2
        iptables -t mangle -D PREROUTING -j CONNMARK --restore-mark
        iptables -t mangle -D PREROUTING -i eth1 ! -d 123.123.123.123 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1

        echo Redirection for new sessions is disabled
        ;;
esac