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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реклама

комментариев 9

  1. Вобщем, маркетинг нужно делить надвое?

    • Я бы сформулирвал это иначе: акценты в официальной документации расставлены неудачно, что приводит к неверному пониманию сути NLB и, как следствие, его неправильному применению.

  2. у меня есть вопрос.
    допустим есть 3 терминальных сервера (т1 т2 т3)
    и на т4 стоит конекш брокер.
    если я один раз попал на т1, то как мне обновить т2 и т3?
    как попасть на них если брокер меня всё время заруливает на т1?

    • Если речь идет об администраторе, то все достаточно просто: надо выполнить консольное подключение с ключем /admin — в этом случае переадресация брокером не выполняется.

      • мне кажется я проверял этот вариант и пролетел как фанера, но сегодня ещё раз гляну повнимательнее.
        спасибо

  3. […] Посидев с коллегой на обеде и порассуждав о сетевой балансировки мы решили, что потребности в NLB на текущий момент нет. Поиск в интернете выдал замечательную статью Ильи Сазонова “Анти NLB в ферме терминальных серверов“. […]

  4. […] Анти NLB в ферме терминальных серверов […]

  5. При использовании,DNS Round Robin, если сервер упал, и dns выдал ip упавшего сервера то в зависимости от времени кэширования возникает задержка с подключением к терминальным службам при использовании NLB такого эфекта не наблюдается. Можно конечно время кэширования dns записи поставить в 0, это конечно скрашивает ситуацию, за исключением того что пользователю надо догадаться не ждать установления соединения с терминалом и переподключиться. А в остальном согласен, NLB должен обязательно работать ВМЕСТЕ сonnection brocker и только для распределения и организации отказоустойчивости первичных подключений. Не понимаю что вам не понравилось в этой фразе «Using NLB with Terminal Services offers the benefits of increased availability, scalability, and load-balancing performance, as well as the ability to distribute a large number of Terminal Services clients over a group of terminal servers». Всё так и происходит. Моё мнение что NLB лучше использовать чем DNS round robin для распределения первичных подключений.

    • Все имеет свои плюсы и минусы, и эти плюсы и минусы могут менять свой знак в зависимости от конретной ситуации и точки зрения. Моей целью как раз и было развернуть ситуацию на 180 градусов и показать обратную сторону. Все это с акцентом на небольшие фермы терминальных серверов.
      В скором времени я предполагаю опубликовать статью или несколько статей на тему больших ферм терминальных серверов RDH. И там будут обсуждаться свойственные им проблемы.

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: