Citrix ADC VPX: добавляем второй узел и настраиваем GSLB под постоянную нагрузку

В марте мы прикидывали capacity на VPN-шлюзах и предупреждали: пик пройдёт, но нагрузка не вернётся на прежний уровень. Так и вышло. К июлю ситуация выровнялась - но «выровнялась» означает примерно вдвое больше постоянных сессий, чем было до февраля. Один VPX, который раньше справлялся с запасом, теперь живёт на 70-80% CPU в рабочие часы. Это не авария, но и не комфортное состояние для продакшна.

У клиента - два офиса с разными интернет-каналами и SD-WAN между ними. Citrix ADC (он же NetScaler, наименование которого Citrix периодически меняет, создавая путаницу в документации) стоял только на основной площадке. Запрос: добавить второй VPX на резервную площадку, настроить GSLB, разгрузить основной узел.

Почему именно GSLB, а не простое active-standby

Первый вопрос, который всегда возникает: зачем GSLB, если достаточно поднять standby-ноду через HA? Ответ - в географии. Два офиса, у каждого свой интернет-провайдер, разные точки выхода. HA в классической схеме NetScaler предполагает, что primary и secondary в одной L2-сети или хотя бы с хорошим L3-линком. Здесь этого нет - SD-WAN между площадками добавляет задержку и нестабильность, которая в момент failover будет ощущаться.

GSLB решает другую задачу: он не переключает между нодами при падении одной, он с самого начала распределяет трафик по DNS - разные пользователи получают разные IP-адреса в зависимости от того, к какой площадке они географически ближе, или по round-robin, или по текущей нагрузке. Каждая нода работает самостоятельно. Если одна падает - DNS перестаёт возвращать её адрес, трафик перетекает на живую ноду.

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

Что пришлось сделать с SD-WAN-политиками

Здесь был неожиданный сюрприз. SD-WAN-контроллер был настроен с политиками, которые часть трафика по определённым портам маршрутизировала через конкретный MPLS-канал. Когда мы добавили второй VPX с другим публичным IP и начали отдавать его через GSLB, обнаружилось: ответный трафик с некоторых VPN-сессий шёл обратно не тем путём. Асимметричная маршрутизация в NetScaler, мягко говоря, не приветствуется - ADC теряет контекст сессии.

Пришлось пройтись по SD-WAN-политикам и явно добавить правила для диапазонов IP обоих VPX, чтобы трафик к каждому узлу и от него шёл через один и тот же канал. Звучит очевидно, но при первоначальной настройке SD-WAN об этом не думали - тогда был один шлюз, и проблемы не было.

Урок простой: при добавлении второго шлюза в существующую SD-WAN-инфраструктуру всегда проверяй симметрию пути явно, не надейся что политики по умолчанию справятся.

SSL offload: шаблон политик

Одна из причин высокой загрузки CPU на первом VPX - SSL offload для нескольких десятков виртуальных серверов. NetScaler берёт на себя терминацию TLS, и при большом числе сессий это ощутимо. Заодно при настройке второго узла мы привели политики в порядок - часть виртуальных серверов жила с настройками «как было при первоначальной установке» и использовала устаревшие шифронаборы.

Базовый шаблон SSL-политики, который мы применяем сейчас:

# Профиль SSL для публичных виртуальных серверов
set ssl profile ns_default_ssl_profile_frontend \
    -ssl3 DISABLED \
    -tls1 DISABLED \
    -tls11 DISABLED \
    -tls12 ENABLED \
    -tls13 ENABLED \
    -denySSLReneg NONSECURE \
    -sessReuse ENABLED -sessTimeout 300

# Шифронаборы - убираем слабые, оставляем AES-GCM и ChaCha20
add ssl cipher ADG_CIPHER_2020
bind ssl cipher ADG_CIPHER_2020 -cipherName TLS1.3-AES256-GCM-SHA384
bind ssl cipher ADG_CIPHER_2020 -cipherName TLS1.3-AES128-GCM-SHA256
bind ssl cipher ADG_CIPHER_2020 -cipherName TLS1.3-CHACHA20-POLY1305-SHA256
bind ssl cipher ADG_CIPHER_2020 -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
bind ssl cipher ADG_CIPHER_2020 -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
bind ssl cipher ADG_CIPHER_2020 -cipherName TLS1.2-ECDHE-RSA-CHACHA20-POLY1305

# HSTS через Rewrite-политику
add rewrite action act_insert_hsts insert_http_header Strict-Transport-Security \
    "\"max-age=31536000; includeSubDomains\""
add rewrite policy pol_insert_hsts TRUE act_insert_hsts

Отключение TLS 1.0 и 1.1 - это не перестраховка ради перестраховки. Часть браузеров на удалённых рабочих местах клиента была откровенно древней, и первый разговор про «выключить TLS 1.0» случился ещё в апреле. Тогда не дошли руки. Сейчас, пока всё равно трогаем конфигурацию - сделали.

На клиентских устройствах проблем не возникло: Windows 7 с IE в продакшне у этого клиента нет, а это обычно единственное место где TLS 1.0 ещё нужен по-настоящему.

GSLB: как настраивали

Схема GSLB в NetScaler строится вокруг нескольких объектов: GSLB site (описание площадки), GSLB service (локальный или удалённый виртуальный сервер), GSLB virtual server (точка входа через DNS).

# Площадки
add gslb site site-primary -publicIP <ip-primary> -publicPort 3011
add gslb site site-secondary -publicIP <ip-secondary> -publicPort 3011

# GSLB-сервисы на основной ноде
add gslb service svc-primary-https <vip-primary> SSL 443 \
    -siteName site-primary \
    -maxClient 0 -healthMonitor YES

add gslb service svc-secondary-https <vip-secondary> SSL 443 \
    -siteName site-secondary \
    -maxClient 0 -healthMonitor YES

# Виртуальный сервер с приоритетом на основную площадку
add gslb vserver vs-gslb-https SSL -domainName access.example.ru \
    -lbMethod STATICPROXIMITY -backupLBMethod ROUNDROBIN

bind gslb vserver vs-gslb-https -serviceName svc-primary-https -weight 70
bind gslb vserver vs-gslb-https -serviceName svc-secondary-https -weight 30

STATICPROXIMITY использует базу геолокации для направления пользователей на ближайшую площадку - для двух российских офисов это даёт разумное распределение. ROUNDROBIN как backup работает когда геолокация не срабатывает.

Метрик обмена между нодами в GSLB-режиме (в отличие от HA) нет - ноды не знают о состоянии сессий друг друга. Это нормально для stateless-протоколов, но для Citrix Gateway с ICA-сессиями важно понимать: пользователь, направленный на другую ноду, начнёт новую сессию. При плановом переключении - это предупреждение заранее. При аварии - неизбежный реконнект.

Где сейчас

Второй VPX запущен, GSLB работает вторую неделю. Нагрузка на основную ноду с 70-80% опустилась до 40-50% в пиковые часы - это уже приемлемо. Резервная площадка держит около 30% сессий.

SD-WAN-политики поправили, асимметрия ушла. SSL-профили приведены к единому шаблону на обоих узлах.

В рамках managed-сопровождения мы сейчас мониторим распределение через Zabbix - добавили item-ы на SNMP-счётчики GSLB-сервисов. Если одна нода начнёт забирать значительно больше положенного - хочется видеть это на графике, а не узнавать по жалобам пользователей.

Открытый вопрос - лицензирование. Citrix VPX лицензируется по пропускной способности, и при текущих темпах роста нагрузки через полгода нужно будет пересматривать лицензионный тир. Это разговор с клиентом, который мы пока только обозначили.