ha-cluster + iptables + wtware

[smart32]

Добрый вечер. Возникла следующая проблема.
У нас терминальный сервер (W2K8) находится в университетской сети, клиенты подключаются к нему через NAT.
NAT поднят на iptables в двухузловом кластере активный-пассивный (heartbeat на openSUSE)... Также кластеризован dhcp,tftp d и другие службы...

Все клиенты подключаются к ТС под одной учетной записью (для этого отключен лимит одного пользователя на сессию)

Все прекрасно работает, пока не происходит failover (до 20 секунд), т.е. переход группы служб на другой узел... Приходится заново запускать терминалы после этого... А люди, которые за ними работали очень пугаются

Думал дело в разных ip на внешнем интерфейсе (университетская сеть)
т.е. у серваков внешние (внешние для кафедры) адреса 192.168.15.2 и 192.168.15.3

Если просто выдернуть кабель из терминала, отключения от сессии не происходит... А при файловере происходит...

Сначала был маскарадинг на внешнем интерфейсе, попробовал кластеризовать ип во внешней подсети (192.168.15.5 к примеру) и заменить маскарадинг на Source NAT на кластеризованный адрес...

Есть одна особенность кластеров общего ип-адреса на heartbeat - кластеризованный адрес поднимается как алиас на существующем интерфейсе с тем же MAC...
Указав в качестве шлюза 192.168.0.5 (кластеризованный адрес) при выполнении трассировки будет указан адрес 192.168.0.2 (активного узла кластера) и в arp будет две записи с одним маком...
Вот думаю,не в этом ли причина?
P.S. увеличивать таймаут пробовали,дело точно не в нем...

[aka]

Ничего не понял То есть вообще ничего. И без картинки не пойму.

Терминальный сервер один, а кластеризирован маршрутизатор на пути к нему? Нафига кластеризировать маршрутизатор?

PS: а в логах терминалов ничего интересного не появляется?

[smart32]

Кластеризован маршрутизатор на предмет исключения единой точки отказа...
Кроме iptables в этом кластере еще dhcp, dns, squid, apache и tftp

Заваливание хоть одного из указанных сервисов будет определено heartbeat, он попытается его запустить, если не получится - передаст кворум другому узлу... В случае отказа аппаратной части произойдет то же самое...
Мотивация - посчитали данный вариант наиболее экономичным, т.к. 2 сервера все равно есть, да и ресурсы их используются в данном случае довольно оптимально (пассивный узел является виртуалкой на другом физ. серваке)... Там кроме терминалов еще куча рабстанций и людей которые тут же начинают вопить если что-то не работает...

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

Ну здесь то вопрос не об этом... При изменении фактического маршрута до терминального сервера происходит отключение терминала (со всеми вытекающими)

Рисунок и лог приложу позже

[smart32]

Все работает, работает, потом раз и вот
Это происходит при переходе кворума... (failover и failback)

Код: Выделить всё

init: Close TCP connection while receiving data, errno 104.
init: RDP session is over, deactivated: false, ext_disc_reason 00000000,
errormsg ""
Turn power off.

Главное на ТС сессия ваще активной остается...

[aka]

Кластеризован маршрутизатор на предмет исключения единой точки отказа...

Паранойю лечат этажом выше! Прошу прощения, случайно вырвалось...

Ну здесь то вопрос не об этом... При изменении фактического маршрута до терминального сервера происходит отключение терминала (со всеми вытекающими)

Какого такого "маршрута"?

Тут кроме рисования рисунка еще надо подумать, как работает NAT. У него же внутрях есть таблицы, верно? И в эти таблицы каким-то образом добавляются новые записи. Таки я бы предположил, что записи добавляются только когда маршрутизатор видит начало соединения (SYN-ACK и все такое). А когда маршрутизатору валятся пакеты уже установившегося соединения, начала которого он не видел (потому, что только что поднялся), он его порежет нафиг. Порежет даже не со зла, а просто потому, что не будет знать - во что его НАТить надо. У вас же не тупая замена адреса источника, у вас целая сеть за одним IP прячется. Соответственно, меняется не только адрес отправителя, но еще и порт отправителя. Прежний маршрутизатор помнил, что траффик, который валится ему на порт 12345, надо послать клиенту 10.2.3.4 на порт 1234. А траффик, который валится ему на порт 12346, надо послать клиенту 10.2.3.5 на порт 2345. Новый маршрутизатор этого знать не может. Поэтому и рубит все установившиеся соединения.