Настройка nlb в windows server 2012

Компонент балансировки сетевой нагрузки  (Network Load Balancing, NLB) в Windows Server 2012 распределяет сетевой трафик по нескольким серверам с помощью протокола TCP/IP. Группируя два и более сервера в единый виртуальный кластер, NLB повышает доступность и масштабируемость серверных приложений.

NLB умеет выполнять балансировку нагрузки любых приложений и служб, использующих сетевой протокол TCP/IP и связанных с определенным TCP- или UDP-портом. Использовать балансировку сетевой нагрузки целесообразно для обеспечения работы приложений, выполняемых без учета состояния, например для веб-, FTP- или служб удаленных рабочих столов (Remote Desktop).

Также NLB может пригодиться и в менее очевидных ситуациях. К примеру, с помощью этого механизма можно обеспечить повышенную избыточность веб-серверов front-end на базе SharePoint 2010, а при использовании Exchange 2010 выравнивание сетевой нагрузки можно применять в целях создания CAS-массивов для роли сервера клиентского доступа (Client Access Server).

Принцип работы

Кластер NLB представляет из себя группу серверов, называемых узлами кластера. На каждом узле выполняется собственная копия приложения. Механизм NLB занимается тем, что распределяет входящие запросы между узлами в соответствии с заданными правилами. При этом можно настроить нагрузку для каждого узла, а если нужно обработать дополнительную нагрузку, узлы можно добавлять к кластеру динамически. Кроме того, технология балансировки сетевой нагрузки может направлять весь трафик на один определенный узел, называемый узлом по умолчанию.

NLB дает возможность обращаться ко всем серверам в кластере по единому IP-адресу, а также поддерживает набор уникальных IP-адресов для каждого узла. При сбое на узле или его отключении нагрузка автоматически перераспределяется между работающими серверами. При внезапном отключении все активные подключения к такому серверу будут потеряны, однако если работа узла завершается намеренно, есть возможность обслужить все активные подключения до отключения компьютера. В любом случае отключенный компьютер, когда он будет готов к работе, может снова присоединиться к кластеру в рабочем режиме и взять на себя часть нагрузки, что позволит снизить объем данных, приходящийся на другие узлы кластера.

Все узлы NLB кластера обмениваются сообщениями пульса (heartbeat) для согласования данных о членстве в кластере. По умолчанию, если узел не отправляет сообщений пульса в течение пяти секунд, это считается сбоем. При сбое на узле остальные узлы кластера начинают процесс схождения (converging):

• выявляют узлы, оставшиеся активными членами кластера;
• назначают узел с наивысшим приоритетом узлом по умолчанию;
• обеспечивают обработку новых запросов клиентов работающими узлами.

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

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

Установка

NLB устанавливается как стандартный компонент Windows и не требует для запуска и работы каких-либо изменений в оборудовании. Тем не менее при планировании NLB кластера необходимо учесть некоторый моменты:

• В кластер может входить до 32 узлов;
• Все узлы кластера должны располагаться в одной подсети;
• Количество сетевых адаптеров на каждом узле не ограничено, при этом различные узлы могут иметь разное число адаптеров;
• Все сетевые адаптеры в одном кластере необходимо использовать либо в одноадресном (Unicast), либо в многоадресном (Multicast) режиме. Балансировка сетевой нагрузки не поддерживает смешанную среду одноадресной и многоадресной рассылки внутри одного кластера;
• При использовании одноадресного режима сетевой адаптер, задействованный для нужд кластера, должен поддерживать программное изменение MAC-адреса;
• Сетевой адаптер, на котором включается NLB, может использовать только протокол TCP/IP. Нельзя добавлять для этого адаптера другие протоколы (например IPX);
• IP-адреса серверов в составе кластера должны назначаться статически. NLB не поддерживает протокол DHCP и отключает его на каждом настраиваемом интерфейсе;
• NLB не работает совместно со службой Failover Clustering. Если сервер является частью отказоустойчивого кластера, то задействовать на нем балансировку сетевой нагрузки не получится.

Если все условия соблюдены, то приступаем к развертыванию кластера. Первым делом необходимо установить сам компонент балансировки сетевой нагрузки. Для этого открываем Server Manager и запускаем мастер установки ролей и компонентов. Переходим на вкладку Features и отмечаем компонент Network Load Balancing.

Также NLB можно установить с помощью PowerShell, следующей командой:

Install-WindowsFeature -Name NLB -IncludeManagementTools

Создание нового NLB кластера

Установив компонент NLB приступим к созданию кластера, для чего воспользуемся оснасткой Network Load Balancing Manager. Открыть ее можно из Server Manager, кликнув по кнопке Tools и выбрав соответствующий пункт меню. Как вариант, можно нажать Win+R и ввести команду nlbmgr.

Для создания нового кластера в NLB Manager выбираем пункт Cluster -> New.

В открывшемся окне указываем имя (или IP-адрес) компьютера, которому предстоит стать первым узлом кластера и жмем «Connect». Выбираем сетевой интерфейс, который будет задействован для нужд кластера.

Примечание. Балансировка сетевой нагрузки может быть привязана к нескольким сетевым адаптерам, что позволяет настроить несколько независимых NLB-кластеров на каждом узле. Поддержка нескольких сетевых адаптеров — это не то же самое, что виртуальные кластеры, в которых можно настраивать несколько кластеров на одном сетевом адаптере.

Дальше идут настройки узла:

• Задаем уникальный идентификатор узла (unique host identifier). Это очень важный параметр, с помощью которого устанавливается приоритет при обработке трафика. Узел с наименьшим host ID среди членов кластера на данный момент обрабатывает весь сетевой трафик кластера, не предусмотренный правилами для порта;
• Указываем выделенный IP-адрес (Dedicated IP, DIP) — уникальный адрес узла, по которому он будет доступен в сети;
• Определяем дефолтное состояние (Default state) узла — запущен (Started), остановлен (Stopped) или приостановлен (Suspended) и указываем, должен ли узел сохранять это состояние при перезагрузке.

Задаем виртуальный IP-адрес кластера (Virtual IP, VIP) — адрес, который будет совместно использоваться всеми узлами в кластере. NLB добавит этот IP-адрес в стек протоколов TCP/IP на выбранном интерфейсе всех узлов, вводимых в состав кластера. При необходимости для одного сетевого интерфейса можно указать несколько IP-адресов.

Идем дальше.

Задаем имя кластера (Full Internet name) соответствующее указанному IP-адресу. В принципе это имя ни на что не влияет, но правильнее будет вписать сюда FQDN-имя, по которому клиенты будут обращаться к кластеру. Также не забудьте создать в DNS соответствующую запись.

Указываем режим работы кластера, который определяет, будет ли для операций кластера использоваться встроенный MAC-адрес адаптера:

Одноадресный (Unicast) — В этом режиме встроенный MAC-адрес физического сетевого адаптера отключается и заменяется МАС-адресом виртуального адаптера кластера. Оба IP-адреса сервера (выделеный IP-адрес сервера и IP-адрес кластера) разрешаются в один единственный МАС-адрес кластера.

При использовании одноадресного режима всем узлам кластера назначается один и тот же IP и MAC-адрес. Поскольку все узлы кластера разделяют один MAC-адрес, а оригинальный MAC-адрес адаптера не используется, использовать адаптер кластера для других целей кроме кластерных (например для управления сервером) становится проблематично. Эту проблему можно обойти, используя несколько сетевых адаптеров: один для кластерного трафика, второй для управления.

Многоадресный (Multicast) — В этом режиме NLB преобразует MAC-адрес кластерного адаптера в адрес группы. IP-адрес кластера разрешается в этот адрес групповой рассылки, а выделенный IP-адрес сервера — в оригинальный MAC-адрес адаптера.

При этом у адаптера остается оригинальный, встроенный MAC-адрес, что дает возможность использовать оба IP-адреса: кластера для трафика клиент-кластер, а выделенный для остального сетевого трафика, специфичного для компьютера. Обратите внимание, что режим Multicast обязательно должен поддерживаться сетевым оборудованием, кроме того может потребоваться дополнительная настройка на коммутаторе.

Многоадресный IGMP (IGMP Multicast) — Многоадресный режим с поддержкой протокола групповой передачи данных (Internet Group Management Protocol, IGMP). Включение поддержки IGMP дает возможность ограничить широковещательный трафик, т.е. обеспечить прохождение трафика к NLB-кластеру только через порты, обслуживающие узлы кластера, а не через все порты коммутатора. Для обеспечения этого режима необходимо включить поддержку IGMP на сетевом оборудовании.

Примечание. Все узлы кластера должны работать в одном режиме — либо в одноадресном, либо в многоадресном. NLB не поддерживает смешанную среду одноадресной и многоадресной рассылки внутри одного кластера.

Переходим к следующему экрану. Настройку правил портов (Port Rules) сейчас производить не будем, поэтому просто жмем «Finish». Первый этап создания NLB кластера завершен.

Добавление узла в кластер

Итак, мы имеем NLB кластер, состоящий из одного узла. Добавим остальные. Kликаем на имени кластера правой клавишей и выбираем пункт «Add Host To Cluster».

Процедура добавления практически аналогична предыдущей. Указываем имя сервера, жмем «Connect» и выбираем сетевой интерфейс, который будет использоваться кластером.

Задаем host ID и указываем выделенный IP-адрес узла, а также состояние узла по умолчанию.

И жмем «Finish». Таким же образом добавляем остальные сервера в кластер.

Создать кластер и добавить в него узлы можно и с помощью PowerShell. Команда для создания кластера:

New-NlbCluster -ClusterName nlb.contoso.com -InterfaseName ″Ethernet″
-ClusterPrimaryIP 192.168.0.10 -SubnetMask 255.255.255.0
-OperationMode Unicast -Force

Для добавления узла в кластер:

Get-NlbCluster | Add-NlbClusterNode SRV5.contoso.com -NewNodeInterface ″Ethernet″ -Force

В результате у нас получился NLB кластер, состоящий из трех узлов.

Настройка параметров кластера

После добавления всех узлов можно приступать к настройке кластера. Кликаем правой клавишей на имени кластера и переходим на пункт «ClusterProperties».

На вкладке Cluster IP Addresses можно изменить существующий адрес кластера или добавить новый. Балансировки сетевой нагрузки  позволяет настроить для одного кластера несколько IP-адресов, для каждого адреса назначить собственное имя и настроить правила обработки трафика. Для этого не требуется выделять отдельный адаптер, так что можно настраивать несколько виртуальных NLB кластеров на одном сетевом адаптере.

На вкладке Cluster Parameters можно настроить соответствие имени и IP-адреса кластера и изменить режим его работы.

И на вкладке Port Rules настраиваются правила обработки трафика всеми узлами кластера. При создании кластера создается правило по умолчанию, которое надо изменить, поэтому выделяем его и жмем «Edit».

Правило порта включает в себя следующие настройки:

Cluster IP Addresses —  IP-адрес кластера, для которого будет действовать это правило. По умолчанию отмечен чекбокс All, что означает воздействие данного правила на все адреса в кластере.

Port Range — диапазон портов, на которых будет обрабатываться трафик кластера. По умолчанию указаны все порты, что не очень правильно. Например, если у вас кластеризовано веб-приложение, использующее для клиентского доступа порт 80 TCP, то указываем этот порт как начало и конец диапазона. Если нужно указать несколько портов, то для каждого придется создать отдельное правило.

Protocols — протоколы, к которым будет применяться данное правило: TCP, UDP или оба.

Filtering Mode — режим фильтрации. Здесь мы указываем, как именно будет обрабатываться трафик кластера. Можно выбрать из двух режимов:

1) Multiple host — трафик по указанным портам будет распределяться среди всех узлов кластера. В этом случае нужно выбрать режим сходства (affinity), который определяет привязку клиента к определенному узлу кластера:

• None — привязка не используется. Все новые соединения распределяются по разным узлам в зависимости от нагрузки;
• Single — привязка осуществляется по IP-адресу клиента. После того, как клиент осуществил подключение к определенному узлу кластера, в течение установленного сеанса все новые соединения с его IP будут направлены на тот же узел кластера;
• Network — привязка основана на принадлежности клиента к определенной частной подсети. Когда один клиент устанавливает соединение к некоторому узлу, все соединения из этой подсети будут направлены на тот же узел.

Также обратите внимание на чекбокс Timeout minutes. Установка галки включает режим расширенного сходства (Extended Affinity), который обеспечивает привязку в отсутствие активных текущих подключений от клиента к узлу, а также позволяет клиентам сохранять соответствие с узлом при изменении конфигурации кластера. Здесь мы можем указать время, в течение которого клиент будет привязан к определенному узлу при отсутствии активного текущего подключения с его стороны.

2) Single host — весь трафик  по указанным портам будет обрабатываться одним узлом кластера, а если этот узел недоступен — то направлен на следующий узел, вычисляемый по номеру Handling Priority (приоритет обработки). Приоритет присваивается узлу при добавлении сервера в кластер и может быть изменен в свойствах узла.

Disable this Port Range — отметив этот пункт, мы запретим обработку трафика на указанных портах. Как я уже говорил, весь сетевой трафик, не подпадающий под действие правил портов, обрабатывается действующим узлом кластера с минимальным идентификатором хоста. Чтобы избежать ненужной нагрузки, весь нецелевой трафик можно запретить. Так в случае с 80 портом достаточно создать 2 правила и запретить весь трафик на портах 0-79 и 81-65535.

При создании правил порта нужно учесть, что:

• Правила на всех узлах кластера должны быть идентичны. При попытке присоединить к кластеру узел с иными правилами или с другим числом правил он не будет принят в кластер;
• Чтобы балансировка сетевой нагрузки корректно обрабатывала IP-фрагменты, не следует использовать значение None для сходства, если выбран протокол UDP или Both;
• Если NLB используется для балансировки нагрузки трафика VPN (напр. PPTP/GRE или IPSEC/L2TP), то для правил порта используйте режим сходства Single или Network.

Настройка параметров отдельного узла

Кроме настройки всего кластера есть возможность настраивать параметры отдельных его узлов. Для этого выбираем узел, кликаем на нем правой клавишей и выбираем «Host Properties».

В окне Host Parameters мы сможем:

• Изменить идентификатор узла, изменив тем самым его приоритет при обработке нецелевого трафика;
• Поиздеваться над его выделенным IP — изменить, удалить или добавить новый. Кстати, выделенный IP-адрес для работы NLB вовсе не обязателен, и при желании его можно вообще не использовать;
• Изменить дефолтное состояние узла. Так по умолчанию после перезагрузки узел сразу стартует и начинает обрабатывать клиентские подключения. Изменив дефолтное состояние узла на Stopped и указав хранить это состояние, тем самым мы предотвратим автоматический старт и начало обработку клиентских подключений сервером после перезагрузки. Это может понадобиться для проверки корректности работы сервера, например после установки обновлений.

Также заглянем в правила портов. Здесь нас интересуют два пункта:

Load Weight — процент нагрузки. В режиме фильтрации Multiple Hosts параметр Load Weight используется для того, чтобы задать процент трафика, который должен обрабатываться этим узлом по соответствующему правилу. По умолчанию используется вариант Equal, при котором происходит равномерное распределение нагрузки между всеми узлами кластера. Чтобы задать для узла определенный процент, нужно убрать галку и указать значение от 1 до 100. Значение 0 вообще исключает данный узел из обработки трафика.

Обратите внимание, что сумма значений Load Weight для каждого узла параметра не обязательно должна составлять 100 процентов. Реальная часть трафика для каждого узла рассчитывается динамически как частное от деления процента, заданного для узла, на суммарный процент для всего кластера.

Handling Priority — приоритет обработки трафика в режиме фильтрации Single host. Этот параметр указывает приоритет узла для трафика по данному правилу. Узел с наиболее высоким приоритетом будет обрабатывать весь трафик для этого правила, а при его недоступности трафик будет перенаправлен на следующий по приоритетности узел. Чем меньше значение Handling Priority, тем выше приоритет, значение 1 соответствует наиболее высокому приоритету.

Управление кластером

И немного об управлении кластером NLB. Управление можно осуществлять как на уровне отдельного узла, так и на уровне всего кластера. Для управления узлом кликаем на нем и выбираем «Control Host». Дальше на выбор, можно:

• Start — запустить обработку трафика на данном узле;
• Stop — остановить обработку трафика на данном узле. При этом все текущие соединения будут закрыты;
• Drainstop — остановить обработку трафика на узле, предварительно обработав все текущие подключения. В этом варианте остановки узел обрабатывает текущие клиентские подключения, но не принимает новых;
• Suspend — приостановить обработку трафика на данном узле;
• Resume — соответственно возобновить приостановленную работу.

Для того, чтобы совсем удалить узел из кластера, надо выбрать пункт «Delete Host».

Выбрав пункт «Control Ports» можно управлять действием правил: включить (Enable), отключить (Disable) или приостановить обработку новых подключений (Drain). Это может потребоваться для того, чтобы временно исключить узел из обработки трафика кластера, например в целях диагностики.

Все то же на уровне кластера — кликаем на имени кластера и выбираем «Control Hosts». Здесь изменения применяются уже ко всем узлам.

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

1) Не смотря на название, NLB не отслеживает реальную загрузку (потребление процессорного времени, памяти, дисковой подсистемы и т.д.) на каждом узле. Под нагрузкой в NLB подразумевается только количество активных подключений к узлу. Учитывайте этот момент при настройке распределения нагрузки.
2) NLB не обеспечивает отказоустойчивость клиентских приложений. Механизм NLB отслеживает только наличие сигналов heartbeat между узлами, мониторинг отдельных служб он не осуществляет. Проще говоря, если на одном узле кластера отвалится клиентский сервис, а сетевой интерфейс останется доступен, то NLB этого не заметит и продолжит отправлять клиентов на неработоспособный узел.
3) Как в режиме Unicast, так и в Multicast (за исключением IGMP) трафик кластера распространяется по всем портам коммутатора. Чтобы изолировать этот широковещательный трафик, все IP адреса кластера желательно вынести в отдельную подсеть.
4) Вопреки расхожему мнению режим Unicast можно использовать даже при наличии одного сетевого адаптера на узле. При этом узлы вполне нормально могут общаться между собой, так как NLB преобразует ARP-таблицу внутри каждого узла, назначая каждому узлу уникальный MAC-адрес. А вот снаружи подключиться к узлу кластера не получится, для управления узлом к нему необходим физический доступ либо механизм удаленного управления типа iLo от HP.

Overview

For those on a budget or with simple needs, Microsoft’s server operating system includes a built-in network load balancer feature. Windows NLB, as it is typically called, is a fully functional layer 4 balancer, meaning it is only capable of inspecting the destination IP address of an incoming packet and forwarding it to another server using round-robin.

The figure below depicts an incoming request hitting a layer 4 load balancer. The request is then forwarded to one of three web servers in the cluster.

With most load balancers, the service sits on an external appliance, as seen in the figure above. With Microsoft’s NLB, however, the web servers in the cluster are also the network load balancer. Each web server in the cluster hosts the floating IP address – known as the NLB cluster IP address.

Network Infrastructure Scenario

I will be using the following infrastructure to create a load balanced web server using Microsoft’s NLB feature.

The server will have two network interfaces and will be multi-homed. This allows us to dedicate one NIC to server management and the other to our website’s Internet traffic. The servers will also reside inside of a DMZ to protect our Internal network.

Both network interfaces have been renamed, as can see in the figure above, to make it easier to identiy their functions. The Management interface is for internal remote connections, and the NLB is used by the cluster and accessed by users of the web site.

Web Servers

The two web servers will have the following configuration.

Hostname	Mangement NIC	NLB NIC	Role	Cluster	Cluster IP
WSWEB01	172.30.0.100	172.30.1.21	IIS	contoso.com	17.30.1.20
WSWEB02	172.30.0.101	172.30.1.22	IIS

Multi-homed Network Routing

Our servers are all multi-homed, which means they each connect to two different networks. Since a default gateway can be configured on only one network interface, we need to create custom routes for the other. We’ll assign the default gateway to the Internet facing network interface and create custom routes for our internal network.

Without the custom routes, remote connections from the internal network, such as RDP, will find their way to our web servers; however, connections back to our client computer initiating the RDP session will not be able to find their way back. This, of course, prevents you from logging onto the server or managing it from the Internal network.

1. Open a Command prompt.
2. Run the route command to get the interface index value of the management network interface.

   route print

3. At the beginning of the route command’s output, you will see an interface list.

   Microsoft Windows [Version 6.3.9600]
   (c) 2013 Microsoft Corporation. All rights reserved.
   
   C:UsersAdministrator>route print
   ===========================================================================
   Interface List
    25...02 bf ac 1e 00 82 ......Intel(R) 82574L Gigabit Network Connection #2
    12...00 0c 29 16 8c 1a ......Intel(R) 82574L Gigabit Network Connection
     1...........................Software Loopback Interface 1
    13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
    14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
    29...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
   ===========================================================================

4. By knowing the MAC address of our management network interface, which is 00 0c 29 16 8c 1a, I’ve determined the interface index to be 12.

   12...00 0c 29 16 8c 1a ......Intel(R) 82574L Gigabit Network Connection

5. In my lab environment, there are three internal subnets that this server may receive a connection from on the management interface. I need to create a route for each of the following subnets.
   

   Subnet	10.4.0.0 /24	10.5.0.0 /24	10.6.0.0 /24
   Gateway	172.30.0.1

   Each route must be assigned to interface index 12 – our management interface in this tutorial. All routes must go through our gateway at 172.30.0.1. Use the route command to create the routes.

   route -p add 10.4.0.0 mask 255.255.255.0 172.30.0.1 metric 1 if 12

   route -p add 10.5.0.0 mask 255.255.255.0 172.30.0.1 metric 1 if 12

   route -p add 10.6.0.0 mask 255.255.255.0 172.30.0.1 metric 1 if 12

   The -p argument makes the route persistent, which means it’s permanent and will survive a reboot. The metric value of 11 for each route is their routing cost. The lower the cost the more preferred the route is, which ensures communications back to those three subnets are not attempted over our Internet facing network interface.

Install the NLB Feature

This step needs to be followed on all servers that will be added to the cluster. Log onto each using an account with administrative rights and follow the instructions below.

1. Launch Server Manager.
2. Click Manage.
   
3. Click Add New Roles and Features.
4. On the Before you begin screen, click Next.
5. On the Select installation type screen, select the Role-based or Feature-based installation radio button, and then click Next.
6. On the Select destination server screen, ensure the Select a server from the server pool radio is selected. Now ensure the current server is selected in the Server Pool.
   
7. Click Next.
8. On the Select server roles screen, click Next.
9. On the Select features screen, scroll down the feature list and check the Network Load Balancing checkbox.
10. Click Next.
11. On the Confirmation screen, click Install.

Create an NLB Cluster

1. Launch the Network Load Balancing Manager. This can be done by clicking the Tools menu in the Server Manager.
2. From the top menu of the Network Load Balancing Manager, click Cluster, and then click New.
   
3. In the Host text field of the New Cluster : Connect dialog box, enter an IP address of the server you are currently logged onto.
4. The Interfaces available for configuring a new cluster table will then populate with the network interfaces of the server. Select the NLB interface and then click the Next button.
   
5. In the New Cluster : Host Parameters dialog box, click Next.
6. In the New Cluster : Cluster IP Addresses dialog box, click Add…
7. Enter the IP address and the subnet mask you want to assign to the web server cluster. When done, click OK.
   
8. Click Next.
9. In the New Cluster : Cluster Parameters dialog box, enter the FQDN you are going to assign to the cluster. When done, click Next.
   
10. We are only serving web content over port 80. Let’s narrow the port rules down to only accept connections to the cluster over that port. Select the default rule and then click Edit.
11. In the Add/Edit Port Rule dialog box, uncheck All under Cluster IP address. Ensure the IP address we’ve assign to the cluster is selected in the drop-down menu.
12. Under Port Range of the Add/Edit Port Rule dialog box, enter 80 in both the From and To text fields.
13. Under Protocols, select TCP. For this web balance cluster, we will not need UDP.
    
14. Keep the remaining default settings and then click OK.
15. Click Finish.
16. The NLB cluster will now be created with a single node (WSWEB01).
    

Add the Second Web Server

Load balance clusters typically have two or more nodes, and ours is no exception. It’s time we add the second web server to the cluster we just created.

1. In the left tree-view panel of the Network Load Balancing Manager, select the name of the cluster we just created (contoso.com). If you don’t see it, expand the Network Load Balancing Clusters tree node.
2. Right-click the cluster name and click Add Host to Cluster.
   
3. In the Add Host to Cluster : Connect dialog box, enter the IP address of the second web server.
4. When populated, select the Internet facing network interface in the Interfaces available for configuring the cluster list of interfaces. Like the first node, ours is named NLB. When done, click Next.
   
5. In the Add Host to Cluster : Host Parameters dialog box, use the default values and click Next.
6. In the Add Host to Cluster : Port Rules dialog box, use the default values and click Finish. We’ve already defined everything when we created the cluster.
7. Our cluster is complete. After a few seconds, ours servers will be converged and be able to server our web application.
   

Conclusion

In practice, Microsoft’s load balancing feature is handy in development or staging areas, or for those who are just learning about load balancing in general.  It can also be used comfortably in production with web application that do not require enterprise features found in other, more expensive balancers.

Network Load Balancing (NLB) is a feature available to computers that run the Windows Server operating system. NLB uses a distributed algorithm to balance an IP traffic load across multiple hosts. It helps to improve the scalability and availability of business-critical, IP-based services. NLB also provides high availability, because it detects host failures and automatically redistributes traffic to surviving hosts.

Before you deploy NLB, you need to have a firm understanding of the types of server workloads for which this high availability technology is appropriate. If you do not understand NLB functionality, you might deploy it in a manner that does not accomplish your overall objectives. For example, you need to understand why NLB is appropriate for web applications, but not for Microsoft SQL Server databases.

For more information : Please log in to : http://technet.microsoft.com/en-us/library/cc732855(v=ws.10).aspx

For this NLB demo this time, i will be using 3 Server, which is 1 Domain Server and 2 Member Server.

1st – In the 1st step lets implementing an NLB Cluster

1 – Before we continue with the deployment, we need to verify our website functionality…

2 – To verify our website functionality, log in to SVR01 server, open iis file (which is in the format of .bmp), the file suppose to be located in c:inetpubwwwroot.

3 – To simulate this demo, please make some adjustment to the iis.bmp file (Refer to pic), and then save the iis file.

4 – Now switch to Domain Server (DC01), open IE and type the address http://LON-SVR1.

** Verify that the webpage displays the IIS logo with the yellow color mark that you added…

5 – Still in the IE, enter the address http://LON-SVR2, and then press Enter. Verify that the webpage does not display the marked IIS logo.

2nd  – Our next step is to Install NLB services

1 – Now switch to LON-SVR1 server and open Windows PowerShell ISE…

2 – In the Windows PowerShell ISE type :

Invoke-Command -Computername LON-SVR1,LON-SVR2 -command {Install-WindowsFeature NLB,RSAT-NLB}

3 – Once the process complete, open Server Manager, click Tools and verify that Network Load Balancing Manager is installed…

4 – Now switch to SVR2,  open Server Manager, click Tools and verify also that Network Load Balancing Manager is installed…

3rd – Create a new Windows Server 2012 NLB cluster

1 – On SVR1 server, in the Windows PowerShell ISE, type :

New-NlbCluster -InterfaceName “Ethernet” -OperationMode Multicast -ClusterPrimaryIP 172.16.0.42 -ClusterName MCT-NLB

2 – Once the command complete, still in the Windows PowerShell ISE, type :

Invoke-Command -Computername LON-DC1 -command {Add-DNSServerResourceRecordA – zonename adatum.com –name MCT-NLB –Ipv4Address 172.16.0.42}

3 – Now to add add a second host to the cluster, still in Windows PowerShell ISE, type :

Add-NlbClusterNode -InterfaceName “Ethernet” -NewNodeName “LON-SVR2” – NewNodeInterface “Ethernet”

4th – Its time to validate the NLB cluster…

1 – On the SVR1 Server, open Server Manager, click the Tools, and then click Network Load Balancing Manager…

2 – In the Network Load Balancing Manager console, verify that nodes LON-SVR1 and LON-SVR2 display with the status of Converged for the MCT-NLB cluster.

3 – Next, right-click the MCT-NLB cluster, and then click Cluster properties…

4 – In the MCT-NLB(172.16.0.42), on the Cluster Parameters tab, verify that the cluster is set to use the Multicast operations mode…

5 – On the Port Rules tab, verify that there is a single port rule named All that starts at port 0 and ends at port 65535 for both TCP and UDP protocols, and that it uses Single affinity…

4th – Configuring and Managing the NLB Cluster

1 – Before we start configure and manage the NLB Cluster, log on to SVR2 server, and create 1 folder named porttest in C:

2 – then copy all c:inetpubwwwroot to c:porttest folder

3 – Open PowerShell and type :

New-Website –Name PortTest –PhysicalPath “C:porttest” –Port 5678

New-NetFirewallRule –DisplayName PortTest –Protocol TCP –LocalPort 5678

4 – Next, open porttest folder, and then double-click iis file…

5 – Make some modification to mark the IIS logo and save the file…

6 – Now switch to Domain Server and in the IE type http://LON-SVR2:5678…

** Verify that the IIS Start page with the IIS logo distinctively marked with RED displays.

7 – Now switch back to SVR1 server and open Network Load Balancing Manager, in the Network Load Balancing Manager console, right-click MCT-NLB, and then click Cluster Properties…

** In the MCT-NLB(172.16.0.42), on the Port Rules tab, select the All port rule, and then click Remove…

8 – On the Port Rules tab, click Add…

9 – In the Add/Edit Port Rule box, enter the following information, and then click OK:
• Port range: 80 to 80
• Protocols: Both
• Filtering mode: Multiple Host
• Affinity: None

10 – On the Port Rules tab, click Add again….

** In the Add/Edit Port Rule box, enter the following information, and then click OK:
• Port range: 5678 to 5678
• Protocols: Both
• Filtering mode: Single Host

11 – Click OK to close the MCT-NLB(172.16.0.42)…

12 – In the Network Load Balancing Manager console, right-click LON-SVR1, and then click Host Properties…

13 – On the Port Rules tab, click the port rule that has 5678 as the Start and End value, and then click Edit…

14 – Click the Handling priority value, and change it to 10 and click OK twice to close…

5th – Validate port rules

1 – To validate port rules, switch to DC01 Server, in IE type http://mct-nlb, and then Refresh the site few times and verify that you see web pages with and without the distinctive Yellow marking.

2 – Next, still in IE enter the address http://mct-nlb:5678 and and then Refresh the site few times and verify that you see web site with the RED marking…

6th : Manage host availability in the NLB cluster

1 – Switch to SVR1 server, in the Network Load Balancing Manager console, right-click LON-SVR1, click Control Host, and then click Suspend…

2 – Click the MCT-NLB node.

** Verify that node LON-SVR1 displays as Suspended, and that node LONSVR2 displays as Converged.

3 – Right-click LON-SVR1, click Control Host, and then click Resume…

4 – Right-click LON-SVR1, click Control Host, and then click Start…

5 – Click the LON-NLB node.

** Verify that both nodes LON-SVR1 and LON-SVR2 now display as Converged. You might have to refresh the view…

6th : Validate website availability when the host is unavailable

1 – Restart SVR1 server and then switch to DC01 server and in the IE type http://mct-nlb..

** Refresh the website few times.

** Verify that the website is available while SVR1 reboots, but that it does not display the distinctive YELLOW mark on the IIS logo until SVR1 has restarted.

While SVR1 restarted..

After SVR1 restarted…

2 – Once the SVR1 restarted, log in and open Network Load Balancing Manager, in the Network Load Balancing Manager console, right-click LON-SVR2, click Control Host, and then click Drainstop…

** Then switch back to DC01 and refresh the website few times and verify that in the website YELLOW IIS logo displays

** The Drainstop action blocks all new connections without terminating existing sessions

I’ve been wanting to play with a load balanced IIS cluster for a while. Microsoft Network Load Balancing is included as a component of Windows Server 2012. NLB uses a hearbeat to check if nodes are still online, but it is not application aware. My environment is as follows:

• A domain controller hosting the contoso.local domain
• A database server running SQL 2012
• A load balancing cluster host
• Two web servers, WEB1 and WEB2

Setting up NLB

Nodes in an NLB cluster should be dual-honed, with 1 NIC for management and the other for NLB. The NLB NIC will take on the MAC of the cluster IP, so you’ll lose control over that interface. I disabled Client for Microsoft Networks on that interface as well. You can also use the registry and turn off automatic DNS registration for that interface. All nodes need to have the NLB feature installed, which is done through server manager.

When the nodes are setup, configure the cluster host:

1. Install the NLB feature and open the NLB manager (nlbmgr.exe)
2. Right click on Network Load Balancing Clusters and pick New Cluster
3. Enter the management IP for the first node in the cluster. Click Connect
4. NLB manager will connect to that node and bring up a list of interfaces. Select the interface to be used for NLB binding
5. Click next past host parameters
6. Set a cluster IP address
7. Click next past cluster parameters
8. Setup port rules for HTTP (80) and HTTPS (443)
9. Finish

If you’re using VirtualBox there are a few possible gotchas:

• You need to enable promiscuous mode for the NICs in the VBox config
• NLB had to be set for Multicast, which doesn’t make sense, but it worked

Thanks to Bearrito on pastebin for this help.

Some links about NLB and unicast

• Microsoft Network Load Balancing Multicast and Unicast operation modes (1006580)
• Microsoft NLB not working properly in Unicast Mode (1556)
• Unicast NLB nodes cannot communicate over an NLB-enabled network adaptor in Windows Server 2003

Configure Kiosk Mode – Microsoft Intune on Windows 10 Devices

Kiosk mode is a most wanted setting from customers which allowed users to use an only specific application on Windows 10 devices, We can achieve that using the attended access in windows settings which requires a lot of efforts and steps, the other way is using Microsoft Intune so let’s get started:- Requirements:- Microsoft Intune […]

Azure File Sync Deployment

Working with Azure file sync enables us to centralize our organization’s file shares in Azure Files while keeping the flexibility, performance, and compatibility of an on-premises file server. for more details about the file sync >> Planning for an Azure File Sync deployment Requirments: Azure Subscription Storage Account File Share File Sync Service Servers Endpoints [WS […]

Active Directory Recycle Bin

The Active Directory Recycle Bin can be enabled to provide a process for restoring deleted objects. This feature overcomes problems with authoritative restore or tombstone reanimation. The Active Directory Recycle Bin enables admins to restore deleted objects without having to restore AD DS data NTSD from backups, and then restart AD DS or reboot domain […]

Configuration Manager cannot connect to the site [Error]

Once you upgrade your SCCM environment from 2012 R2 to 2012 R2 SP1 the following error occurs Solution  upgrading to SP1/SP2 won’t upgrade the management console so… You have to Reinstall the configuration manager console separately from the Splash.hta once you install it, the console will successfully reconnect to the site database.  

Microsoft Azure Virtual Networks | Part 3

Source: Microsoft Azure Virtual Networks | Part 3

Microsoft Azure Virtual Networks | Part 2

Source: Microsoft Azure Virtual Networks | Part 2

Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
— Среда исполнения
— Подготавливаем виртуальные сервера
— Создаём кластер NLB
— Подготавливаем SQL Server
— Устанавливаем роли Remote Desktop Services
— Создаём высоко-доступный RD Connection Broker
— Добавляем сервера в высоко-доступный RD Connection Broker
— Добавляем на сервера роль RD Web Access
— Создаём коллекцию сеансов – Session Collection
— Настраиваем цифровые сертификаты
— Настраиваем веб-узлы RD Web Access
— Настраиваем Roaming User Profiles и Folder Redirection
— Публикуем приложения RemoteApp
— Устанавливаем языковой пакет
— Настраиваем перенаправление печати

Среда исполнения

В рассматриваемом примере мы будем строить ферму RDCB из 5 виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На всех виртуальных серверах устанавливается Windows Server 2012 Standard EN.

Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее.

Серверам присвоены имена – KOM-AD01-RDS21 , KOM-AD01-RDS22 , KOM-AD01-RDS23 , KOM-AD01-RDS24 , KOM-AD01-RDS25

Создаваемый в процессе описания высоко-доступный экземпляр RD Connection Broker а также NLB-кластер RD Web Access будут использовать общее виртуальное имя KOM-AD01-RDSNLB.

База данных высоко-доступного экземпляра RDCB будет расположена на отдельном кластере SQL Server c именем KOM-SQLCL 

С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть следующим образом:

Подготавливаем виртуальные сервера

Итак, у каждого виртуального сервера создадим по 2 сетевых адаптера. Назовём их условно на каждом сервере таким образом, чтобы было понятно за что отвечает этот интерфейс — NIC1 (Management) и NIC2 (NLB Cluster).

При создании второго сетевого адаптера NIC2, который будет использоваться для построения NLB в свойствах виртуальной машины Hyper-V необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses)

Согласно нашей схемы, выделим и распределим статические IP адреса на серверах следующим образом:

Имя сервера	Настройки IP NIC1	Настройки IP NIC2 (NLB Cluster)
KOM-AD01-RDS21	IP 10.160.0.151/24	IP 10.160.0.141/24
KOM-AD01-RDS22	IP 10.160.0.152/24	IP 10.160.0.142/24
KOM-AD01-RDS23	IP 10.160.0.153/24	IP 10.160.0.143/24
KOM-AD01-RDS24	IP 10.160.0.154/24	IP 10.160.0.144/24
KOM-AD01-RDS25	IP 10.160.0.155/24	IP 10.160.0.145/24

На всех интерфейсах используются одинаковые настройки адреса шлюза по умолчанию -10.160.0.254 и адресов DNS — 10.160.0.253, 10.160.1.253. Причина использования именно такой сетевой конфигурации для построения NLB на базе Windows Server 2012 была ранее изложена в заметке App-V 5 for RDS — Разворачиваем инфраструктуру повышенной доступности

Интерфейс NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера), а NIC2 (для которого включён спуфинг MAC адресов) будет участником NLB кластера. Выполним настройку сетевых интерфейсов на каждом из серверов согласно вышеприведённой таблицы на примере сервера KOM-AD01-RDS21

Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).

NIC1 должен иметь приоритет над NIC2.

В свойствах сетевого подключения, которое будет использоваться для подключения к NLB кластеру (NIC2) можно отключить все компоненты, за исключением TCP/IPv4 и Client for Microsoft Networks:

В свойствах компонента TCP/IPv4 зададим настройки согласно приведённой ранее таблицы и по кнопке Advanced откроем окно дополнительных настроек

В окне дополнительных настроек TCP/IP на закладке DNS отключим механизм регистрации в DNS:

Интерфейс NIC1 настроим согласно вышеприведённой таблицы аналогичным образом, за исключением того, что на нём может быть включена опция регистрации в DNS и обязательно должны быть включены компоненты TCP/IPv4 , Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks

После того как описанным способом настроены сетевые интерфейсы на всех серверах, зарегистрируем их имена в доменной зоне прямого просмотра DNS (если запрещена динамическая регистрация в DNS и/или отключена опция регистрации в свойствах интерфейсов NIC1). Для пакетной регистрации A-записей в DNS можно воспользоваться скриптом описанным в заметке DNS – Пакетное создание А-записей с помощью WMI и Powershell 

Дополнительно сразу же создаём статическую А-запись для будущего NLB кластера.

RD Connection Broker использует для хранения БД сессий общий экземпляр SQL Server, поэтому все сервера RDCB должны иметь «на борту» клиентские компоненты SQL Server, а также привилегии доступа к SQL Server. Настройку доступа к SQL Server выполним позже, а пока установим на каждый сервер, где планируется развертывание RD Connection Broker, свежую версию пакета Microsoft SQL Server 2012 Native Client (в нашем случае установка нужна на всех пяти виртуальных серверах). Скачать его можно со страницы загрузки Microsoft SQL Server 2012 SP1 Feature Pack (файл sqlncli.msi)

После установки клиента SQL Server создадим на каждом сервере SQL-Alias, который будем в дальнейшем использовать для подключения серверов RDCB к серверу SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (C:windowssystem32cliconfg.exe) и добавим два новых алиаса – с коротким именем сервера и FQDN

Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра HKLMSOFTWAREMicrosoftMSSQLServerClientConnectTo

Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection

Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.

***

Далее, с помощью PowerShell установим на каждый сервер исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

Создаём кластер NLB

На первом виртуальном сервере (KOM-AD01-RDS21) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот который хотим сделать участником кластера:

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее в DNS зарегистрировали А-запись.

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. Режим работы кластера – режим одноадресной рассылки – Unicast.

На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 443 – для подключения клиентов к RD Web Access;
TCP/UDP 3389 – для подключения клиентов к RD Connection Broker/Session Host;

Все необходимые параметры кластера заданы, создаем его по нажатию кнопки Finish и после первоначальной инициализации, если в конфигурации не допущены ошибки, NLB кластер запуститься в конфигурации с одним узлом

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго и последующих серверов в кластер.

В конечном итоге после добавления (по аналогии с первым узлом) всех серверов мы получим работоспособный Windows NLB кластер

С помощью Ping -t проверяем из клиентской подсети доступность кластерного интерфейса по очереди перезагружая узлы кластера, а затем друг за другом выключая их до тех пор пока в кластере не останется один живой узел. 

Подготавливаем SQL Server

Создадим в AD группу безопасности, например KOM-AD01-RDS-Connection-Broker-Computers, и включим в нее учетные записи наших виртуальных серверов.

После этого подключимся к экземпляру SQL Server на котором будет размещаться БД RDCB (в нашем случае это отдельный кластер SQL Server из двух серверов), создадим новый SQL Login с привязкой к указанной доменной группе. При создании SQL-логина ему будет присвоена серверная роль SQL Server – public, которая даст право подключаться к экземпляру SQL Server. Включим ещё одну серверную роль – dbcreator. Эта роль понадобится нам лишь на время первоначальной инициализации БД RDCB для того, чтобы учетная запись сервера, на котором мы будем запускать процесс создания отказоустойчивого RDCB, смогла выполнить операцию создания новой БД.

Дополнительно на SQL сервере создадим каталог для файлов базы данных RDCB. В нашем случае это будет каталог U:SQLData_SQL01_RDCB на кластерном диске SQL сервера.

Устанавливаем роли Remote Desktop Services

Так как консоль Server Manager в Windows Server 2012 поддерживает групповую настройку сразу нескольких серверов, перед тем как разворачивать на наши виртуальные сервера роли RDS, объединим их в логическую группу. На любом из виртуальных серверов, например на KOM-AD01-RDS21, откроем консоль Server Manager и выберем пункт меню Manage > Create Server Group

добавим пять наших виртуальных серверов в группу и дадим ей название, например RDS-FARM.

После этого выберем пункт меню Manage > Add Roles and Features Wizard

В открывшемся мастере добавления ролей выберем режим установки служб RDS — Remote Desktop Services installation

 

  Тип развёртывания — Standard deployment

Сценарий развертывания выбираем Session-based desktop deployment, так как планируется развертывание серверов сеансов, а не серверов инфраструктуры VDI 

На этапе выбора ролей RDS нас предупредят о том, что будет выполняться развертывание сразу трёх ролей —  RD Connection Broker, RD Session Host, RD Web Access, не оставляя при этом нам никакого выбора…

На этапе выбора серверов для роли RD Connection Broker выбираем один сервер, ибо мастер не даст нам выбрать более одного сервера. Так как всю первоначальную настройку мы выполняем на сервере KOM-AD01-RDS21, то соответственно и выберем его для этой роли…

На этапе выбора серверов для роли RD Web Access включим опцию Install the RD Web Access role on the RD Connection Broker server для того чтобы эта роль была установлена на тот же сервер, который был выбран для роли RDCB. Выбирать какой-то другой сервер в нашей ситуации особого смысла нет, да и потом мастер опять таки не даст нам выбрать для установки этой роли более чем один сервер…

На этапе выбора серверов для роли RD Session Host мы сможем выбрать все сервера…

 
На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Включим опцию автоматической перезагрузки серверов — Restart the destination server automatically if required и запустим процесс развёртывания..

В процессе установки ролей первым будет автоматически перезагружен сервер, с которого мы запустили весь этот процесс, поэтому мы отвалимся от его консоли. Пугаться не надо… После того, как система поднимется из перезагрузки, снова залогинимся и запустим консоль Server Manager, где через несколько секунд автоматически запустится мастер развертывания ролей RDS и мы сможем убедиться в том, что процесс развертывания успешно прошёл до конца на всех серверах.

В нашем примере мастер сообщил о том, что на двух серверах из пяти не удалось установить службу RDSH, хотя последующая проверка этих серверов свидетельствовала об обратном. В системном журнале Applications and Services Logs > Microsoft > Windows > ServerManager-DeploymentProvider > Operational было зарегистрировано событие говорящее об успешной установке компонент…

Ну и соответственно PS-запрос состояния компонент RDS показывал что роль RDSH установлена..

В любом случае если Server Manager упорно будет говорить вам о том, что роль RD Session Host не установлена на каких-то серверах, то для того чтобы заставить её «прокашляться», можно повторить процедуру установки через мастер добавления ролей RDS на вкладке управления службами Remote Desktop Services > Overview

Создаём высоко-доступный RD Connection Broker

После окончания процесса установки ролей в консоли Server Manager и перейдём на вкладку управления службами Remote Desktop Services > Overview, чтобы приступить к созданию отказоустойчивой конфигурации RD Connection Broker.

На схеме инфраструктуры RDS выберем изображение роли RD Connection Broker и правой кнопкой мыши вызовем меню, в котором выберем пункт Configure High Availability.

Запустится мастер создания высоко-доступного экземпляра RDCB, где нас предупредят о необходимых условиях, которые мы уже предварительно выполнили, за исключением последнего пункта, который предполагает создание в DNS A-записей c одинаковым FQDN именем RDCB и IP адресами всех серверов (для работы механизма Round Robin). Откажемся от концепции использования DNS Round Robin для получения клиентами имени точки подключения к ферме RDCB. Вместо этого мы будем использовать имя созданного ранее NLB кластера.

На следующем шаге мастера Configure High Availability заполняем значения трёх полей:

Database connection string – строка подключения к БД SQL Server. Значение должно иметь вид: DRIVER=SQL Server Native Client 11.0 (10.50 для SQL Server 2008 R2);SERVER=<FQDN-Имя или SQL-Alias сервера SQL Server>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<Имя БД>

В нашем случае это значение будет иметь следующий вид:

DRIVER=SQL Server Native Client 11.0;SERVER=KOM-AD01-SQL-RDCB.holding.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDS_ConnectionBroker

Folder to store database files — путь ранее подготовленного каталога U:SQLData_SQL01_RDCB на кластерном диске SQL сервера. В этом каталоге будут размещены файл данных и лога транзакций SQL Server при создании БД RDCB.

DNS round robin name – имя точки подключения клиентов. Как я уже сказал, здесь предполагается ввод значения FQDN-имени созданного в DNS с несколькими A-записями. В нашем примере, в качестве такого имени, мы будем использовать имя созданного ранее NLB кластера – KOM-AD01-RDSNLB.holding.com

Далее мы получим предупреждение о том, что указанное нами имя DNS RR имеет отличный IP адрес от того, для которого выполняется установка HA RDCB. Мы идём на этот шаг намеренно и поэтому соглашаемся…

Дожидаемся успешного окончания процесса конфигурирования высокой доступности.

В ходе этого процесса на SQL-сервере будет создана БД высоко-доступного экземпляра RDCB.

***

Переключимся на наш SQL Server с только что созданной БД и выполним пару настроек…

В обязательном порядке для SQL-логина, который мы создавали на подготовительном этапе (KOM-AD01-RDS-Connection-Broker-Computers), нужно дать роль db_owner для созданной базы RDS_ConnectionBroker

Помимо этого, для данного SQL-логина можно отключить добавленную ранее серверную роль dbcreator, так как БД уже создана и больше данная привилегия этому SQL-логину не потребуется.

Если резервное копирование баз данных SQL Server выполняется такими инструментами как например SC 2012 DPM, то при желании мы можем поменять модель восстановления созданной БД (Recovery Model) c Full на Simple.

***

Вернёмся на наш сервер KOM-AD01-RDS21 и обратим внимание на то, что в консоли Server Manager в схеме инфраструктуры RDS статус роли RDCB поменялся на High Availability Mode

Теперь для того чтобы задуманная нами связка NLB + RDCB работала так как нужно, нам необходимо до-установить роль RD Connection Broker на оставшиеся четыре сервера.

Добавляем сервера в высоко-доступный RD Connection Broker

Добавление серверов к высоко-доступной конфигурации RDCB делается через то же самое контекстное меню в схеме развертывания RDS на странице Overview.

В открывшемся мастере добавляем следующий сервер (мастер также не даст добавить более одного сервера)

После успешного добавления роли на выбранный сервер и подключение этого сервера к БД HA RDCB мы получим предупреждение о необходимости настройки сертификатов, которое пока можем проигнорировать, так как займёмся сертификатами позже.

Аналогичным образом мы по одному серверу должны добавить роль HA RDCB на все оставшиеся сервера, те. KOM-AD01-RDS23, KOM-AD01-RDS24 и KOM-AD01-RDS25.

Добавляем на сервера роль RD Web Access

Так как мы хотим иметь отказоустойчивую конфигурацию роли RD Web Access, нам нужно до-установить эту роль на оставшиеся четыре сервера (на KOM-AD01-RDS21 эта роль уже установлена). Делаем это в уже знакомом нам месте через мастер добавления ролей

Здесь уже мы сможем выбрать сразу все серверы и выполнить установку роли RDWA оптом…

Создаём коллекцию сеансов – Session Collection

Все наши сервера с ролью RD Session Host мы должны объединить в логическую единицу – коллекцию сеансов (Session Collection). Делаем это в оснастке Server Manager на вкладке Remote Desktop Services > Collections выбрав задачу Create Session Collection в таблице перечисления коллекций.

В открывшемся мастере создания коллекции зададим имя коллекции и при желании описание

Затем выбираем все сервера, которые хотим сделать членами коллекции…

Далее мы должны определить доменную группу безопасности которой будет разрешено подключаться к коллекции сеансов. Убираем выбранную по умолчанию группу доступа Domain Users и добавляем специально созданную группу доступа, в нашем случае KOM-AD01-RDS-AllUsers, ограничив тем самым круг пользователей которые смогут подключаться к серверам коллекции.

На следующем шаге определяемся с тем, хотим ли мы использовать новую технологию Windows Server 2012 – User profile disks (UPD), которая, как я понял, предлагается в качестве альтернативы механизму перемещаемых профилей — Roaming User Profiles. Новая технология подразумевает централизованное хранение файлов пользователя в отдельных VHD дисках, которые располагаются где-то на выделенном файловом ресурсе. В силу того, что на данный момент нет уверенности в стабильности работы данного механизма из-за полученной информации в обсуждении Windows Server 2012 RDS — [User Profile Disk] VS [Roaming Profiles + Folder Redirection] я решил пока не использовать данный функционал и поэтому он не будет рассмотрен в данной заметке.

А пока не будут разрешены имеющиеся на данный момент проблемы с UPD будем использовать связку технологий Roaming User Profiles и Folder Redirection, настройка которых рассматривалась ранее в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки 

В результате работы мастера все наши сервера успешно добавляются в коллекцию с предупреждениями о том, что желательна настройка групповых политик для задания параметров RDP на этих серверах…

Настраиваем цифровые сертификаты

При попытке подключения к ферме RD Connection Broker по FQDN-имени кластера NLB клиенты могут получать предупреждение безопасности, говорящее о том, что нет доверия сертификату того сервера сеансов, на который он был перенаправлен. Если открыть свойства этого сертификата, мы увидим, что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным. Чтобы избежать таких предупреждений нам нужно создать для развёртывания RDS сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС. Этот сертификат после создания мы развернём на всех серверах фермы.

При создании запроса на сертификат нужно использовать как минимум 2 политики применения:

Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

Хотя в нашей ситуации альтернативные имена в сертификате Subject Alternative Name (SAN) иметь вовсе необязательно, я всё-таки рассмотрю вариант создания именно такого сертификата, то есть чтобы помимо имени NLB кластера в сертификате содержались имена отдельных серверов.

Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. О том как это сделать можно прочитать в заметке Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker

Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf

Содержимое этого файла в нашем примере выглядит так:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-RDSNLB.holding.com" ; 
Exportable = TRUE; Private key is exportable 
KeyLength = 2048 
KeySpec = 1; Key Exchange – Required for encryption 
KeyUsage = 0xA0; Digital Signature, Key Encipherment 
MachineKeySet = TRUE 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication 
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication 
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-RDSNLB.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS21.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS22.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS23.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS24.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS25.holding.com&" 
_continue_ = "dns=KOM-AD01-RDSNLB&" 
_continue_ = "dns=KOM-AD01-RDS21&" 
_continue_ = "dns=KOM-AD01-RDS22&" 
_continue_ = "dns=KOM-AD01-RDS23&" 
_continue_ = "dns=KOM-AD01-RDS24&" 
_continue_ = "dns=KOM-AD01-RDS25&"

С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:

cd /d C:Temp
CertReq –New RequestPolicy.inf RequestFile.req

Выполнять эту команду надо локально на сервере RDS. В нашем случае команда выполняется на сервере KOM-AD01-RDS21. После выполнения команды откроем консоль управления локальными сертификатами (mmc.exe > Add/Remove snap-in > Certificates > Add > Computer account) для хранилища Local Computer и убедимся в появлении ожидающего запроса в разделе Certificate Enrollment Request

Полученный файл запроса RequestFile.req добавляем в локальный центр сертификации через консоль управления Certification Authority (certsrv.msc) (All Tasks > Submit new request)

Затем в этой же консоли в разделе Pending Requests проверяем наш добавленный запрос и разрешаем выдачу сертификата по нему (Выбираем запрос > All Tasks > Issue )

Переходим в раздел выданных сертификатов — Issued Certificates, находим сертификат, открываем его свойства и на закладке Details вызываем мастер экспорта сертификата (Copy to File)

В открывшемся мастере выбираем формат экспорта DER X.509 и сохраняем файл например с именем NLBCert.cer

Скопируем полученный файл NLBCert.cer на сервер RDS, где мы создавали запрос на сертификат (KOM-AD01-RDS21) и вернёмся в консоль управления локальными сертификатами этого сервера. Выберем хранилище Personal > Certificates и вызовем мастер импорта сертификатов (All Tasks > Import)

В мастере импорта автоматически будет выбрано хранилище Local Machine

Далее выберем импортируемый файл сертификата NLBCert.cer и укажем раздел хранилища PersonalRegistry. Чтобы этот раздел был доступен для выбора, нужно включить опцию Show physical stores.

После того как импорт сертификата выполнен, убеждаемся что он появился в соответствующем хранилище и с ним связан его закрытый ключ (присутствует значок ключика на иконке). При этом в разделе Certificate Enrollment Request информация о запросе должна исчезнуть.

Далее выбираем установленный сертификат и вызываем мастер экспорта (All Task > Export). В мастере экспорта выбираем опцию экспорта закрытого ключа при экспорте сертификата – Yes, export the private key

В качестве формата экспорта используем единственно возможный и нужный нам формат .PFX

Далее задаем пароль (он потребуется нам в дальнейшем для назначения этого сертификата в развёртывании RDS)

После того как сертификат экспортирован, переходим в консоль Server ManagerRemote Desktop ServicesOverview и на схеме развёртывания в списке задач выбираем пункт редактирования развёртывания (TASKS > Edit Deployment Properties)

На вкладке Certificates используем кнопку Select existing cerificates для того чтобы назначить сделанный нами сертификат для той или иной роли RDS…

В окне выбора сертификата определяем, что мы хотим использовать файл PFX полученный нами ранее и задаём пароль с которым этот сертификат был экспортирован. Хотя опция Allow the certificate to be added to the Trusted Root CA нам по сути не нужна, так как созданный нами сертификат сделан в ЦС, которому предположительно все наши сервера уже доверяют, её всё таки придётся отметить, так как если она не отмечена, кнопка OK недоступна…

После закрытия этого окна по ОК, мы увидим что в таблице статус сертификата изменился на Ready to apply..Нажмём кнопку Apply и через несколько секунд наш сертификат будет назначен роли соответствующей RDS. Описанным методом мы выполним привязку сертификатов ко всем развёрнутым у нас ролям и в конечном итоге получим примерно следующий вид:

Назначенные нами сертификаты будут автоматически установлены на все сервера, которые участвуют в нашем RDS развёртывании.

Настраиваем веб-узлы RD Web Access

По умолчанию при обращении в стартовой веб-странице RDWA от пользователя в явном виде требуется ввод учетной записи и пароля. Если мы используем RDWA для доменных пользователей внутри локальной сети, то для удобства нам нужно будет задействовать механизм прозрачного входа Single sign-on (SSO) при обращении к веб-узлу RDWA. Для этого на каждом сервере с установленной ролью RDWA в оснастке IIS Manager откроем свойства веб-приложения RDWeb > Pages выберем в разделе настроек пункт Authentication…выключим анонимную аутентификацию (Anonymous Authentication), аутентификацию на основе формы (Forms Authentication) и включим Windows Authentication:

***

После входа на веб-страницу RDWA можно обнаружить уже знакомый нам по предыдущей версии опцию I am using a private computer that complies with my organization’s security policy (в русском варианте — Я использую личный компьютер, соответствующий политике безопасности моей организации).

Ранее, в заметке RDS Web Access – Опция «Я использую личный компьютер…», я писал о том, как выставить эту опцию во включенное состояние по умолчанию, чтобы избежать повторного запроса аутентификации при подключении к опубликованным приложениям RemoteApp в Windows Server 2008 R2. Это рецепт работает и для Windows Server 2012.

***

Верхняя часть страниц RDWA по умолчанию оформлена в виде заголовочной надписи Work Resources и изображения размером 48*48 пикселей.

Для того чтобы заменить заголовочную надпись можно использовать командлет PowerShell (один раз для всей коллекции серверов):

Set-RDWorkspace -Name "Приложения RemoteApp" -ConnectionBroker KOM-AD01-RDS21.holding.com

 

Для того чтобы заменить имеющееся изображение на другое, например с корпоративной символикой, можно внести корректировки в файл %windir%WebRDWebPagesSite.xsl – найти секцию с комментарием «Replaceable Company Logo Image«…

… и заменить ссылку на файл изображения, указав собственный файл размещённый в соответствующем подкаталоге %windir%WebRDWebPagesimages

В результате мы получим примерно следующий вид верхней части страниц RDWA:

Настраиваем Roaming User Profiles и Folder Redirection

Так как пользователи нашей фермы RDS от сеанса к сеансу могут попадать на разные сервера, нам необходимо обеспечить идентичность пользовательской среды на всех этих серверах. Для этого мы будем использовать механизмы перемещаемых профилей (Roaming User Profiles ) и перенаправления папок (Folder Redirection). Для настройки этих механизмов настраиваем групповую политику применяемую к серверам нашей фермы RDS. Здесь мы не будем рассматривать эту процедуру, так как она уже была ранее описана мной в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки

Публикуем приложения RemoteApp

Чтобы опубликовать в ферме RDS приложения RemoteApp переходим в консоль Server Manager в раздел Remote Desktop Services > Collections > выбираем нашу коллекцию KOM-AD01-RDSH-COLL и публикуем необходимые приложения в окне REMOTEAPP PROGRAMS. В меню задач выбираем пункт публикации TASKS > Publish RemoteApp Programs

Для примера опубликуем два простых приложения Calculator и WordPad

 
Опубликованные приложения доступны клиентам нашей фермы RDS двумя основными способами – через веб-интерфейс RD Web Access и через непосредственную доставку ярлыков запуска на клиентские компьютеры. С первым способом, полагаю, всё итак понятно, рассмотрим второй. Для того чтобы ярлыки опубликованных приложений RemoteApp стали доступны на клиенте с Windows 7/8, нужно выполнить подписку на узел RDWA в Панели управления (апплет Подключения к удаленным рабочим столам и приложениям RemoteApp). Щелкнув по ссылке Доступ к удалённым приложениям RemoteApp и рабочим столам мы вызовем мастер подключения, где в адресной строке укажем URL RDWA в формате http://KOM-AD01-RDSNLB.holding.com/RDWeb/Feed/WebFeed.aspx

В примерах описанных в окне подключения можно заметить вариант с указанием адреса, похожего на адрес электронной почты —  alexeyo@contoso.com. На самом деле такой метод указания адреса не столько имеет отношение к электронной почте, сколько относится к методу автоматического обнаружения сервера публикации RemoteApp с помощью специальных записей в зоне прямого просмотра DNS. То есть мастеру подключения важно лишь то, что указано после символа @ – имя зоны DNS. До символа @ можно написать любую ерунду. Например, в нашем примере в DNS используется зона holding.com и в качестве адреса мы можем указать например blablabla@holding.com

В зоне DNS соответственно при использовании такого метода должна быть создана специальная запись формата TXT c именем _msradc и текстовым значением в формате https://rds.domain.com/rdweb/feed 
Соответственно в нашем примере запись будет иметь следующий вид:

После того как запись создана, проверим то, что DNS сервер возвращает нам значение этой записи с помощью утилиты nslookup в режиме set querytype=TXT и если всё в порядке, то теперь в качестве адреса подключения можем указать соответствующее значение

При этом из DNS будет возвращён URL-адрес подключения…

После этого может последовать запрос на ввод учетных данных пользователя, чтобы узел RDWA выполнил идентификацию пользователя и определил какие ярлыки на приложения RemoteApp можно показать пользователю согласно доменных групп безопасности, включенных в правилах публикации. В нашем примере будет отображена информация об успешном подключении и количестве доступных пользователю программ

При этом в меню “Пуск” для Windows 7 и в стартовом экране для Windows 8 в отдельной группе появятся ярлыки на запуск приложений RemoteApp

Если вам потребуется каким-то альтернативным способом распространять ярлыки на приложения RemoteApp, то их можно будет найти на клиентской машине подключённой вышеописанным способом к точке публикации RDWA в каталоге
%APPDATA%MicrosoftWorkspaces{GUID}Resource

Нововведением Windows 8 стал ещё один способ подключения клиентов к точке публикации – с помощью групповых политик (GPO). За это отвечает параметр
Specify default connection URL в разделе User Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/RemoteApp and Desktop Connections. Для настройки клиентов нужно включить этот параметр и указать значение URL-адреса подключения в формате:
https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx

Как я уже сказал, этот параметр поможет нам настроить только клиентов Windows 8, но если у вас есть сильное желание раздать через GPO настройку и для клиентов Windows 7 – читайте статью Concurrency Blog — How to deliver RemoteApps from Windows Server 2012 RDS. Метод заключается в применении на клиентских машинах PowerShell скрипта Configure RemoteApp and Desktop Connection on Windows 7 Clients с передачей ему в виде параметра файла настроек в следующем формате:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<workspace name="Enterprise Remote Access" xmlns="http://schemas.microsoft.com/ts/2008/09/tswcx" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<defaultFeed url="https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx" />
</workspace>

Устанавливаем языковой пакет

Так как в нашем примере на серверах фермы RDS используется англоязычная система, нам потребуется установка языкового пакета для локализации интерфейса пользователя. Чтобы получить файлы русского языкового пакета распаковываем образ содержащий все языковые пакеты для Windows Server 2012 RTM SW_DVD5_NTRL_Win_Svr_Language_Pack_2012_64Bit_MultiLang_FPP_VL_OEM_X18-27741.ISO

Извлекаем файл langpacksru-rulp.cab из состава образа и вызываем на сервере RDS мастер установки языковых пакетов командой lpksetup

Помимо этого установку языкового пакета можно выполнить командой:

Dism /online /Add-Package /PackagePath:"C:DistributivesWS2012RTMLanguagePacklp.cab"

Практика показывает, что после выполнения этой команды, для того чтобы в панели управления появилась информация о том, что языковой пакет действительно установлен, – необходима перезагрузка системы. После перезагрузки сервера RDS переходим в панель управления в раздел Language и выделив русский язык кнопкой Move Up поднимаем его на первую позицию, сделав его таким образом приоритетным языком интерфейса.

Далее открываем апплет панели управления Control Panel > Region (intl.cpl) , проверяем и при необходимости настраиваем параметры на родной язык на закладках Formats и Locations , а затем на закладке Administrative нажимаем Copy settings, чтобы скопировать языковые предпочтения текущего пользователя для всех пользователей которые будут первый раз входить в эту систему.

Убедимся что у текущего пользователя установлены такие настройки, которые мы хотим иметь у всех пользователей сервера RDS и включим галочку New user accounts

Не рекомендую использовать опцию копирования русских настроек в системный профиль (галка Welcome screen and system accounts), так как это в перспективе может привести к невменяемой работе некоторых “буржуйских” программ, проблемы в которых возникают чаще всего из-за знака разделителя целой и дробной части.

Настраиваем перенаправление печати

Для того чтобы пользователи служб удалённых рабочих столов смогли выполнять печать на перенаправленные с их клиентских мест устройств печати, выполним ряд нехитрых манипуляций.
Установим на сервера RDS консоль управления службой печати – Print Management, например с помощью PowerShell:

Add-WindowsFeature RSAT-Print-Services

Если есть сильное желание управлять службой печати на всех серверах например с рабочей станции Администратора, то для того, чтобы можно было удалённо подключаться к службе печати, на серверах необходимо включить параметр групповой политики Allow Print Spooler to accept client connections в разделе Computer ConfigurationPoliciesAdministrative TemplatesPrinters. После применения политики на серверах нужно перезапустить службу очереди печати — Print Spooler.
На мой взгляд использовать локально установленную на серверах консоль – более предпочтительно.

После установки открываем консоль, добавляем в неё наши сервера, и в свойствах сервера печати для каждого сервера выполняем необходимые изменения настроек, например на закладке Advanced отключаем включённые по умолчанию оповещения сетевых и локальных принтеров…

К слову об использовании именно локальной консоли…эти две опции недоступны для изменения (попросту не видны) если вы подключаетесь консолью удалённо.

На закладке Drivers добавляем драйвера принтеров, которые используются для печати на клиентских компьютерах. Драйвера принтеров нужно добавлять исходя из принципа разумного минимума. Например вместо того чтобы для принтеров Hewlett-Packard добавлять несколько драйверов для конкретных моделей лучше добавить один универсальный драйвер HP Universal Print Driver (UPD), в случае если принтеры поддерживают работу на данном драйвере. В нашем примере используется текущая версия (на момент написания этой заметки) UPD совместимая с Windows Server 2012 — 5.6.5.15717. Разумеется добавлять драйвера производителей оборудования вообще имеет резон только в том случае если тесты показывают, что принтер не выполняет поставленные задачи печати на драйвере Remote Desktop Easy Print.

В конфигурации по умолчанию для принтеров перенаправляемых с пользовательских компьютеров система будет использовать драйвер Remote Desktop Easy Print. Если мы загружаем на сервера RDS драйвера производителей принтеров, как например тот же HP UPD, то возможно нам стоит переопределить такое поведение, то есть, чтобы приоритетным для использования считался драйвер вендора железки, а уж если его не удалось найти – использовать RD Easy Print. Задаётся это параметром групповой политики Use Remote Desktop Easy Print printer driver first = Disabled в разделе Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostPrinter Redirection

После применения GPO в пользовательской терминальной сессии проверяем какой драйвер был назначен для перенаправленного принтера…

На этом, в целом, можно считать, что мы выполнили основные этапы создания и настройки отказоустойчивой фермы RD Connection Broker на базе Windows Server 2012. В отдельной следующей заметке мы рассмотрим пример настройки пользовательского интерфейса на сервера RD Session Host.

Полезные ссылки по теме:

Remote Desktop Services Blog — RD Connection Broker High Availability in Windows Server 2012
VirtualizationAdmin.com — Taking a closer look at RD Connection Broker High Availability in Windows Server 2012
TechNet Articles  —  RD Connection Broker HA – SQL Permissions
Freek Berson Blog — RD Connection Broker HA and the RDP properties on the client
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 1)
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 2)

To know and see the issues we are dealing with in this demo, you need to read this blog post first: Windows NLB Nodes “Misconfigured” after Simultaneous Live Migration on Windows Server 2012 (R2).

We were dealing with some issues on on several WNLB clusters running on a Windows Server 2012 R2 Hyper-V cluster after a migration from an older cluster. So go read that and come back .

Are you back? Good.

Let’s look at the situation we’ll use to show case one possible solution to the issues. If you have  a 2 node Hyper-V cluster, are using NIC Teaming for the switch and depending on how teaming is set up you’ll might run into these issues. Here we’ll use a single switch to mimic a stacked one (the model available to me is non stackable and I have only one anyway).

• Make sure you enable MAC Spoofing on the appropriate vNIC or vNICs in the advanced settings

• Note that there is no need to use a static MAC address or copy your VIP mac into the settings of your VM  with Windows Server 2012 (R2) Hyper-V
• Set up WNLB with IGMP multicast as option. While chancing this there will be some advice warnings thrown at you

I’m not going in to the fact that since W2K8 the network default configurations are all about security. You might have to do some configuration work to get the network flow to do what it needs to do. Lots on this  weak host/strong host model behavior on the internet . Even wild messy ramblings by myself here.

On to the switch itself!

Why IGMP multicast? Unicast isn’t the best option and multicast might not cut it or be the best option for your environment and IGMP is less talked about yet it’s a nice solution with Windows NLB, bar replacing into with a hardware load balancer. For this demo I have a DELL PowerConnect 5424 at my disposal. Great little switch, many of them are still serving us well after 6 years on the job.

What MAC address do I feed my switch configurations?

Ah! You are a smart cookie, aren’t you. A mere ipconfig reveals only the unicast MAC address of the NIC. The GUI on WNLB shows you the MAC address of the VIP. Is that the correct one for my chosen option, unicast, multicast or IGMP multicast?  No worries, the GUI indeed shows the one you need based on the WNLB option you configure. Also, take a peak at nlb.exe /? and you’ll find a very useful option called ip2mac.

Let’s run that against our VIP:

And compare it to what we see in the GUI, you’ll notice that show the MAC to use with IGMP multicast as well.

You might want to get the MAC address before you configure WNLB from unicast to IGMP multicast. That’s where the ip2mac option comes in handy.

Configuring your switch(es)

We have a multicast IP address that we’ll convert into the one we need to use. Most switches like the PowerConnect 5424 in the example will do that for you by the way.

I’m not letting the joining of the members to the Bridge Multicast Group happen automatically so I need to configure this. I actually have to VLANs, each Hyper-V host has 2 LACP NIC team with Dynamic load balancing connected to an LACP LAGs on this switch (it’s a demo, yes, I know no switch redundancy).  I have tow as some WNLB nodes have multiple clusters and some of these are on another VLAN.

I create a Bridge Multicast Group. For this I need the VLAN, the IGMP multicast MAC address and cluster IP address

When I specify the IGMP multicast MAC I take care to format it correctly with “:” instead of “–“ or similar.

You can type in the VIP IP address or convert is per this KB yourself. If you don’t the switch will sort you out.

The address range of the multicast group that is used is 239.255.x.y, where x.y corresponds to the last two octets of the Network Load Balancing virtual IP address.

For us this means that our VIP of 172.31.3.232 becomes 239.255.3.232. The switch handles typing in either the VIP or the converted VIP equally well.

This is what is looks like, here there are two WNLB clusters in ICMP multicast mode configured. There are more on the other VLAN.

We leave Bridge Multicast Forwarding here for what it is, no need in this small setup. Same for IGMP Snooping. It’s enable globally and we’ve set the members statically.

We make unregistered multicast is set to forwarding (default).

Basically, we’re good to go now. Looking at the counters of the interfaces & LAGs you should see that the multicast traffic is targeted at the members of the LAGs/LAGs and not all interfaces of the switch. The difference should be clear when you compare the counters adding up before and after you configured IGMP.

The Results

No over the top switch flooding, I can simultaneously live migrate multiple WLNB nodes and have them land on the same switch without duplicate IP address warning. Will this work for you. I don’t know. There are some many permutations that I can’t tell you what you should do in your particular situation to make it work well. I’ll just quote myself from my previous blog post on this subject:

“»If you insist you want my support on this I’ll charge a least a thousand Euro per hour, effort based only. Really. And chances are I’ll spend 10 hours on it for you. Which means you could have bought 2 (redundancy) KEMP hardware NLB appliances and still have money left to fly business class to the USA and tour some national parks. Get the message?”

But you have seen some examples on how to address issues & get a decent configuration to keep WNLB humming along for a few more years. I really hope it helps out some of you struggling with it.

Wait, you forgot the duplicate IP Address Warning!

No, I didn’t. We’ll address that here. There are some causes for this:

• There is a duplicate IP address. If so, you need to address this.
• A duplicate IP address warning is to be expected when you switch between unicast and multicast NLB cluster modes (http://support.microsoft.com/kb/264645). Follow the advice in the KB article and clearing the ARP tables on the switches can help and you should get rid of it, it’s transient.
• There are other cause that are described here Troubleshooting Network Load Balancing Clusters. All come down to the fact that somehow you’re getting multiple MAC address associated with the same IP address. One possible cause can be that you migrated form an old cluster to a new cluster, meaning that the pool of dynamic IP addresses is different and hence the generated VIP MAC … aha!
• Another reason, and again associated multiple MAC address associated with the same IP address is that you have an old static ARP entry for that IP address somewhere on your switches. Do some house cleaning.
• If all the above is perfectly fine and you’re certain this is due to some Hyper-V live migration, vSwitch, firmware, driver bug you can get rid of the warning by disabling ARP checks on the cluster members. Under HKLMSYSTEMCurrentControlSetServicesTcpipParameters, create a DWORD value with as name “ArpRetryCount” and set the value to 0. Reboot the server for this to take effect. In general this is not a great idea to do. But if you manage your IP addresses well and are sure no static entries are set on the switch it can help avoid this issue. But please, don’t just disable “ArpRetryCount” and ignore the root causes.

Conclusion

You can still get WNLB to work for you properly, even today in 2014. But it’s time to start saying goodbye to Windows NLB. The way the advanced networking features are moving towards layer 3 means that “useful hacks” like MAC spoofing for Windows NLB are going no longer going to work.  But until you have implement hardware load balancing I hope this blog has given you some ideas & tips to keep Windows NLB running smoothly for now. I’ve done quite few and while it takes some detective work & testing, so far I have come out victorious. Eat that Windows NLB! I have always enjoyed making it work where people said it couldn’t be done. But with the growing important of network virtualization and layer 3 in our networks, this nice hack, has had it’s time.

For some reasons developers like Windows NLB as  “it’s easy and they are in control as it runs on their servers”. Well … as you have seen nothing comes free and perhaps our time is better spend in some advanced health checking and failover in hardware load balancing. DevOps anyone?