Есть ли в Linux механизмы репликации TCP сессий?

на уровне tcp соединения - тяжело. Это нужно запрос дублировать на 2 или более бекендов, сравнивать результат и отдавать клиенту. А оно нужно ?

Для http/nginx вроде есть рецепт

Как-то я себе слабо представляю как это можно реализовать без ведома бэкэндов. Как именно это делает Cisco ASA?

Например:

• клиент делает TCP-соединение
• девайс перекидывает его на один из бэкэндов
• бэкэнд отправляет часть данных
• бэкэнд падает
• ??? <- что делается тут?

Нене, бэкенды не причем особо, они это отдельная тема.

Допустим, что у нас есть 3-4 лоадбалансера (для кворума), один активен, другие отдыхают.

У них есть свои постоянные IP-адреса и некий общий кластерный, который они биндят через ip_nonlocal_bind все сразу, а перебрасывается он каким-нибудь keepalived или pacemaker при отказе главного.

Так вот, клиенты коннектятся на этот общий адрес и балансер с него же коннектится на бэкенды (ну или там два плавающих адреса, внешний и внутренний, в зависимости от архитектуры).

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

На ASA реализовано так: на каждом интерфейсе есть IP-адрес активный и standby, если асашка в данный момент главная, то она поднимает у себя активный IP, если у нее второстепенная роль - то standby.

Standby девайс в реальном времени реплицирует по выделенному линку состояния всех TCP-сессий, IPSEC-каналов, трансляции, изменения конфига и прочая прочая.

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

Так что такое, в принципе, вполне возможно, вот только как это сделать на линухах...

Всё, понял. Я сначала подумал, что ты хочешь прозрачно «переносить» TCP-сессии с одного бэкэнда на другой. А ты отказывается про перенос сессий между разными балансировщиками, но с одним и тем же бэкэндом.

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

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

http://conntrack-tools.netfilter.org/

The userspace daemon conntrackd can be used to enable high availability of cluster-based stateful firewalls and to collect statistics of the stateful firewall use

http://conntrack-tools.netfilter.org/manual.html#settingup

The daemon conntrackd supports two working modes:

State table synchronization: the daemon can be used to synchronize the connection tracking state table between several firewall replicas. This can be used to deploy fault-tolerant stateful firewalls. This is the main feature of the daemon.

Flow-based statistics collection: the daemon can be used to collect flow-based statistics. This feature is similar to what ulogd-2.x provides.

Да, про коннтрек демона я знаю, но это всё же немножко не то. Он синхронизирует только NAT-трансляции, насколько я осознал.

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

Он синхронизирует только NAT-трансляции, насколько я осознал.

Нет. Таблица /proc/net/nf_conntrack содержит состояние всех соединений, как локальных, так и транзитных. При этом conntrackd, естественно, не выбирает из нее только NAT, а синхронизирует всю.

См., например, выхлоп

cat /proc/net/nf_conntrack | grep 127.0.0.1

127.0.0.1 — это ведь явно не NAT.

Хотя, сейчас посмотрел… а ведь не на каждом хосте есть локальные соединения. Так что лучше посмотреть глазками, что там не только NAT.

Я это понимаю, но вот будет ли оно работать, например, с балансировщиком в ядре Linux Virtual Server.

В данный момент я балансирую в юзерспейсе через haproxy и с ним, ессесно, коннтрек никак не поможет т.к. сам демон на соседнем хосте про эти коннекты ничего не знает. Да и вообще у меня коннекшен трекинг в ядре выключен совсем за ненадобностью :)

Надо будет почитать про LVS и conntrackd.

Похоже болт:

IPVS uses its own simple and fast connection tracking for performance reasons, instead of using netfilter connection tracking. So, if you don't use firewalling feature at load balancer and you need an extremely fast load balancer, do not load netfilter conntrack modules into you system, because there is no need to do double tracking. Note that LVS/NAT should work too without the conntrack modules.

Но у них, судя по всему, есть аналог для синхронизации состояний: http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.server_state_sync_demo...

Надо будет пощупать.