NLB и Powershell


В версии Windows Server 2012 появился модуль Powershell для управления кластером NLB – 38 комендлетов! Все операции на настройке и управлению кластером NLB можно выполнять с помощью Powershell. Но не только.

В составе командлетов есть командлет Get-NlbClusterDriverInfo, который позволяет достаточно удобно выполнять диагностику кластера NLB.

Простой запуск Get-NlbClusterDriverInfo или с параметром Params выводит основные сведения об узле кластера.

Если указать параметр Filter и адреса клиента и сервера, то можно получить ответ на вопрос какой узел кластера будет обрабатывать запрос клиента:

> Get-NlbClusterDriverInfo -Filter TCP -ClientIP 172.16.0.11 -ServerIP 172.16.15.101

Result

——

ACCEPT_DIP

> Get-NlbClusterDriverInfo -Filter TCP -ClientIP 172.16.0.11 -ServerIP 172.16.15.102

Result

——

REJECT_DIP

К сожалению коды возврата не описаны в документации, но они интуитивно понятны в большинстве случаев.

У командлета есть особенность – работает он только относительно локального узла. Для доступа к удаленным узлам нужно использовать WS-Remoting.

Остальные параметры командлета смотрите в документации.

Все командлетв NLB кластера.

NLB – Extended Affinity


Давненько я не настраивал NLB. Оказывается есть в нем кое-что новое. Во времена Windows Server 2003 NLB распределял трафик по узлам кластера в соответствии с таблицей (affinity), которую стоил динамически и обновлял при перестроении кластера. Это создавало проблему с существующими подключениями: клиент подключается к одному узлу, на нем создается сессия приложения (например, в IIS), при перестроении кластера affinity меняется и очередной пакет от клиента отправляется на другой узел кластера, на котором сессии приложения нет, и происходит ошибка клиента.

Начиная с версии Windows Server 2008 R2 (и это работает в Windows Server 2012 R2), кластер NLB получил дополнительную настройку Extended Affinity, которая задается в виде таймаута для существующих подключений: при перестроении кластера существующие подключения сохраняются на указанное время, что позволяет существующим сессиям завершиться нормальным образом.

Подробнее Network Load Balancing in R2: Extended Affinity

Конечно это не избавляет NLB от всех его проблем, но уже кое-что!

Как вылечили NLB в массиве TMG


Интересная все же у TMG логика! Включили в массиве NLB, а он никак не настраивается – узлы друг друга вроде как не видят, NLB кластер не срастается. В консоли управления на закладке мониторинга для NLB обнаружили статус «stopped due to a VPN problem». Какой VPN? Откуда? И какое отношение он имеет к NLB?!

Оказывается при миграции конфигурации с ISA приехала настройка включенного удаленного доступа Remote Access, но без настроенного пула адресов для VPN клиентов. Поэтому возможных решений было два: либо настроить пул адресов, либо отключить Remote Access.

Отключили Remote Access, и в считанные секунды все серверы в массиве TMG сконфигурировали NLB.

Попутно нашлась статья с несколько странным рецептом, но возможно вам пригодится.

Еще в помощь:

Network Load Balancing Integration Concepts for Microsoft Internet Security and Acceleration (ISA) Server 2006

Troubleshooting NLB

Анти NLB в ферме терминальных серверов


Почему «Анти NLB»? Потому что хочется развеять частое заблуждение о возможностях NLB  по балансировке нагрузки и обеспечению отказоустойчивости, в частности относительно терминальной фермы серверов.

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

И так обратимся к документации. Цитата из Network Load Balancing Step-by-Step Guide:

Using NLB with Terminal Services offers the benefits of increased availability, scalability, and load-balancing performance, as well as the ability to distribute a large number of Terminal Services clients over a group of terminal servers.

Думаю без перевода понятно как все круто. Только не все так круто на самом деле.

Давайте посмотрим на конфигурацию, когда несколько терминальных серверов в ферме объединены в NLB-кластер. Чтобы привязать клиента к определенному серверу в ферме, NLB использует affinity – привязку по ip-адресу клиента или по его сети класса C. Обратите внимание – это единственный критерий! – NLB никак не контролирует загрузку сетевых интерфейсов и тем более загрузку ресурсов сервера (процессор, память). Иначе говоря, балансировка нагрузки заключается просто в законе больших чисел: чем больше инициировано подключений из большего количество мест, тем равнее сессии будут разбросаны по серверам фермы. (Но при этом существует вероятность, что на одном сервере окажутся сессии, приложения в которых съедят все ресурсы процессора, на втором окажутся сессии с приложениями, которые займут всю память, а на третьем приложения будут забивать весь сетевой канал.)

У вас есть терминальная ферма, к которой подключаются сотни и тысячи клиентов с большой частотой? Если есть, то вы тоже не будете использовать NLB – вы купите аппаратный балансировщик для такого важного ресурса!

Еще один момент – availability. NLB обеспечивает доступность? Я бы сказал наоборот. NLB в  своих настройках имеет только номер порта, но совершенно ничего не знает о сервисе, который его обеспечивает! И если этот сервис не отвечает, «упал», на одном сервере в ферме, то NLB будет, как и прежде, направлять на этот сервер новые подключения, а клиенты не смогут с ним работать и очень долго (до ручной переконфигурации NLB)! Вот если упадет весь сервер (или хотя бы у него будет недоступен физически сетевой интерфейс), то NLB это обнаружит через несколько секунд, исключит сервер из кластера и не будет направлять на него новые подключения клиентов.

Ручная переконфигурация NLB, упомянутая выше, заключается в том, что нужен механизм (скрипт), который, во-первых, диагностирует отказ сервиса (может оказать очень сложной задачей, например, подключение по RDP-порту есть,  а сессия реально не создается (черный экран)), во-вторых, исключит сервер из кластера NLB (это можно сделать с помощью WMI).

Вот так и получается, что NLB это не совсем network load balancing и не совсем cluster всему, что написано в цитате выше, дословно верить нельзя – надо осознать, что такое NLB на самом деле.

Пойдем дальше и рассмотрим конфигурацию терминальной фермы с Remote Desktop Connection Broker. Для чего же там NLB?

Цитата из документации Network Load Balancing Step-by-Step Guide:

TS Session Broker enables you to load balance sessions between terminal servers in a farm. This functionality is provided by the TS Session Broker Load Balancing feature. However, this session-based load balancing feature requires a front-end load balancing mechanism to distribute the initial connection requests to the terminal server farm. You can use a load balancing mechanism such as DNS round robin, NLB or a hardware load balancer to distribute the initial connection requests.

Ого-го! Оказывается вся необходимость в NLB заключается в том, чтобы распределять между серверами терминальной фермы первичные запросы! А что такое первичный запрос? В ответ от терминального сервера клиент должен получить указание подключиться к брокеру, а уже тот даст клиенту адрес сервера в ферме, где будет создана сессия. Нагрузка, создаваемая первичным запросом, как видно, невелика, но ответ на первичный запрос критически важен.

Как было описано выше, такую работу NLB делает, но не слишком уж надежно, и что самое плохое при падении сервиса NLB не исключает сервер из кластера (нужны внешние средства, чтобы диагностировать ситуацию и исключить сервер из кластера или восстановить сервис). Другое дело DNS round robin с коротким временем жизни записи для имени фермы: клиент, попав на мертвый сервис, через некоторое время (30 секунд) все равно переключится на другой адрес! Получается, что конфигурация с DNS round robin не только проще в настройке, но и надежнее. А если ферма большая и хорошо нагруженная, то напрашивается вариант с аппаратным балансировщиком. (Хотя прежде чем его покупать, можно рассмотреть вариант выделенного редиректора в терминальной ферме: терминального сервера, единственной задачей которого будет прием первичных запросов на подключение от клиентов. Редиректор также можно резервировать не через NLB, а DNS round robin.)

Осталось сравнить обеспечение надежности, которое реализует NLB и сам Connection Broker. Проблемы с NLB мы уже знаем. Connection Broker работает более грамотно. Он контролирует приходящие редиректы от серверов фермы и таким образом понимает, что терминальный север жив и здоров. Если редиректов нет более 60 секунд (параметр TimeServerSilentBeforePing), то Connection Broker начинает пинговать терминальный сервер, и если несколько пингов подряд (параметр NumberFailedPingsBeforePurge) завершаются неудачно, Connection Broker исключает сервер из свой базы. Как видите Connection Broker работает гораздо умнее NLB.

Вместо заключения.

Цитата из документации Remote Desktop Connection Broker:

RD Connection Broker supports load balancing and reconnection to existing sessions on virtual desktops, Remote Desktop sessions, and RemoteApp programs accessed by using RemoteApp and Desktop Connection.

Вот кто на самом деле делает действительно полезную и нужную работу по балансировке – распределению сессий между терминальными серверами в ферме и обеспечению доступности сервиса – reconnect клиентов и вывод из фермы недоступных серверов!

Хорошенько подумайте нужен ли вам NLB в терминальной ферме.

 Дополнение. Попался документ MSIT, в котором описан их опыт применения балансировки в терминальной ферме. Интересно, что они довольны обеими вариантами, но большую часть ферм перевели на Broker. http://technet.microsoft.com/en-us/library/cc304366.aspx