Чому «Анти NLB»? Тому що хочеться розвіяти часта помилка про можливості NLB по балансуванню навантаження і забезпечення відмовостійкості, зокрема щодо термінальної ферми серверів.
Помилка мабуть походить від невдалого назви сервісу: не говоритиму за англійський, але російською назва і суть сервісу слабо пов'язані.
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 - ви купите апаратний балансувальник для такого важливого ресурсу!
Ще один момент - availability. NLB забезпечує доступність? Я б сказав навпаки. NLB в своїх настройках має тільки номер порту, але абсолютно нічого не знає про сервіс, який його забезпечує! І якщо цей сервіс не відповідає, «впав», на одному сервері в фермі, то NLB буде, як і раніше, направляти на цей сервер нові підключення, а клієнти не зможуть з ним працювати і дуже довго (до ручної переконфігурації NLB)! Ось якби вони впали весь сервер (або хоча б у нього буде недоступний фізично мережевий інтерфейс), тоNLB це виявить через кілька секунд, виключить сервер з кластера і не направлятиме на нього нові підключення клієнтів.
Ручна переконфігурація NLB, згадана вище, полягає в тому, що потрібен механізм (скрипт), який, по-перше, діагностує відмова сервісу (може надати дуже складним завданням, наприклад, підключення по RDP-порту є, а сесія реально не створюється (чорний екран)), по-друге, виключить сервер з кластера NLB (це можна зробити за допомогою WMI).
Ось так і виходить, що NLB це не зовсім network load balancing і не зовсім cluster - всьому, що написано в цитаті вище, дослівно вірити не можна - треба усвідомити, що таке NLB насправді.
Підемо далі і розглянемо конфігурацію термінальної ферми з Remote Desktop Connection Broker. Для чого ж там NLB?
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 і сам Connection Broker. Проблеми з NLB ми вже знаємо. Connection Broker працює більш грамотно. Він контролює приходять редіректи від серверів ферми і таким чином розуміє, що термінальний північ живий і здоровий. Якщо редиректів немає більше 60 секунд (параметр TimeServerSilentBeforePing), то Connection Broker починає пінгувати термінальний сервер, і якщо кілька пінгів поспіль (параметр NumberFailedPingsBeforePurge) виявляться невдалими, Connection Broker виключає сервер з свій бази. Як бачите Connection Broker працює набагато розумніші NLB.
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 клієнтів і висновок з ферми недоступних серверів!