Заметки о Windows и других программных продуктах Microsoft...

Настройка NLB в Windows Server 2012

Настройка 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

 

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

Install-WindowsFeature -Name NLB -IncludeManagementTools

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

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

запуск оснастки NLB Manager

 

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

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

 

В открывшемся окне указываем имя (или 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-адресов.

задаем 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

создание кластера с помощью PowerShell

 

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

готовый NLB кластер

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

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

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

 

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

изменение\добавление IP адреса кластера

 

На вкладке 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.

 
 
Комментарии

что выбрать для отказоустойчивость клиентских приложений? раз nlb не может.

Смотря каких приложений.
В общем случае — отказоустойчивый кластер (Failover Clustering).

Отказаустойчевый кластер не подходит, так как для него нужно внешнее хранилище. У меня имеется двухузловой кластер с балансировкой нагрузки без внешнего массива данных на котором (AD, DNS, NLB, DFS, IIS). Моя цель что бы при отключении одного из серверов автоматически переключалась на 2.

есть виртуальный ip 192.168.0.3 через что работает сайт iis. node1 c ip 192.168.0.1 node2 с ip 192.168.0.2. При отключении node1 сайт должен автоматически переключится на node2

Нельзя мешать все в одну кучу, надо разделять разные типы нагрузок.
Для IIS как раз подойдет балансировка с помощью NLB, хотя можно и Failover Cluster организовать без общего хранилища. Здесь все зависит от типа приложения.
А вот AD, DNS и DFS вообще не нуждаются в дополнительных механизмах для обеспечения отказоустойчивости.

как это реализовать?

Я бы поднял на серверах роль Hyper-V и создал бы для каждой нагрузки отдельную виртуалку.

Добрый день! Подскажите, как реализовать NLB не только для внутренних интерфейсов, но и для внешних? И будут ли при этом корректно отрабатываться сервисы? Насколько я понял необходимо создать два кластера один на внешние интерфейсы серверов, другой кластер на внутренние интерфейсы?

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