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