Remote Desktop Connection Broker (RDCB) – это один из компонентов роли терминального сервера (Remote Desktop Services, RDS) в Windows Server. RD Connection Broker позволяет равномерно распределить нагрузку между хостами в ферме RDS (при подключении к RDS ферме пользователя перенаправляет на наименее загруженный сервер), обеспечить доступ пользователям к VDI и RemoteApp, управляет конфигурацией RDS хостов в ферме. Также RDCB позволяет пользователям переподключаться к своим сессиям: при подключении к RDS, RDCB проверяет наличие незавершенной сессии на других серверах фермы, и перенаправляет его в старую сессию.
В этой статье мы рассмотрим процесс настройки отказоустойчивого высоко-доступного экземпляра RD Connection Broker, обеспечивающего свой функционал при выходе из строя одного из серверов с ролью RDCB. Для хранения данных RDCB используется БД на MS SQL Server 2019. В целях ухода от одной точки отказа, SQL базу данных RDCB также нужно развернуть в отказоустойчивой конфигурации. В этом примере мы будем использовать два SQL сервера с настроенной группой высокой доступности SQL Always On.
Требования для внедрения отказоустойчивого RDCB:
- Как минимум 2 сервера с ролью RDCB с Windows Server 2019/2022;
- Если вы хотите использовать высокую доступность для SQL базы RDCB, вам понадобится минимум 2 сервера с установленным SQL Server 2014 или выше (с редакцией Standard или Enterprise). В нашем примере на каждый из серверов мы установили standalone экземпляр MS SQL Server 2019 Enterprise. Если вы не планируете создать HA для SQL базы, достаточно одного сервера с SQL Express;
- На серверах с ролями RD Connection Broker нужно установить SQL Server Native Client;
- Предоставить полные права для серверов RD Connection Broker на БД SQL и каталог установки SQL;
- Минимум один сервер с ролью Remote Desktop Session Host в ферме;
Мы создадим отказоустойчивую конфигурацию RDCB их двух серверов. На каждом из них будет установлена роль RD Connection и SQL Server. Высокая доступность базы SQL Server будет достигаться за счет создания группы высокой доступности Always On.
Подготовка инфраструктуры для Remote Desktop Connection Broker
Всем серверам, на которых будут установлены роли RD Connection Broker необходимо назначить статические ip-адреса и добавить в домен Active Directory.
- Srv-rds1.winitpro.loc — 192.168.13.20
- Srv-rds2.winitpro.loc — 192.168.13.21
Создайте в Active Directory новую группу безопасности HQ RDS Connection Brokers, и добавьте в нее все сервера RDCB. Можно создать группу из оснастки ADUC (dsa.msc) или с помощью PowerShell:
New-ADGroup "HQ RDS Connection Brokers" -path 'OU=Groups,OU=SPB,OU=RU,DC=winitpro,DC=loc' -GroupScope Global -PassThru –Verbose
Добавьте в группу два сервера:
Add-AdGroupMember -Identity "HQ RDS Connection Brokers" -Members srv-rds1$,srv-rds2$
Создайте в DNS A записи для вашей кластерного имени RDS фермы (в нашем примере это HQRDCB). Все записи должны указывать на IP адреса всех серверов RDCB. Это необходимо для балансировки нагрузки (Round Robin) между серверами RD Connection Broker. Я создал такие записи:
- A — HQRDCB.winitpro.loc 192.168.13.20 (ip адрес первого сервера RDCB — Srv-rds1.domain.ru)
- A — HQRDCB. winitpro.loc 192.168.13.21 (ip адрес второго сервера RDCB — Srv-rds2.domain.ru)
Можно создать A записи в DNS с помощью PowerShell:
Add-DnsServerResourceRecordA -Name HQRDCB -IPv4Address 192.168.13.20 -ZoneName winitpro.loc
Add-DnsServerResourceRecordA -Name HQRDCB -IPv4Address 192.168.13.21 -ZoneName winitpro.loc
Установите SQL Server Native Client на всех серверах, на которых будет работать роль RDCB. SQL Server Native Client для вашей версии SQL Server можно скачать с сайта Microsoft или скопировать из установочного образа SQL Server (
D:\1033_ENU_LP\x64\Setup\x64\sqlncli.msi
)
Теперь запустите SQL Server Management Studio и подключитесь к вашему первому SQL серверу, на котором будет создана общая база данных Connection Broker (позже мы перенесем ее в группу высокой доступности Always On).
Перейдите в раздел Security -> Logins и добавьте новый login. Нажмите на кнопку Search, в Locations выберите свой домен, установите Object Types = Groups и найдите доменную группу HQ RDS Connection Brokers.
Назначьте этой группе роли
dbcreator
и
sysadmin
.
Откройте необходимые порты в Windows Firewall (по умолчанию для подключения к SQL Server используется
TCP 1433
).
Установка ролей Remote Desktop Services
Теперь нам нужно установить RDS роли на ваших серверах. Запустите консоль Server Manager, выберите Manage -> Add roles and Features -> Remote Desktop Services Installation.
Выберите Standard deployment -> Session-based desktop deployment.
Выберите один сервер, на который вы хотите установить роль RD Connection Broker. Сейчас не нужно ставить роль RDCB на второй сервер.
Установите роль RD Web Access на тот же сервер, что и RDCB (если эта роль не нужна, ее потом можно удалить). Установите роль RD Session Host на оба сервера.
Дождитесь окончания установки ролей RDS.
После окончания установки ролей, добавьте в локальную группу RDS Management Servers на обоих серверах учетные записи хостов RDCB и ‘NT AUTHORITY\NETWORK SERVICE’.
При установке роли RD Connection Broker на первый сервер в ферме он создаст локальную база SQL, хранящаяся на локальном диске сервера RD Connection Broker в каталоге C:\Windows\rdcbDb\.
В этой базе хранится информация о ферме и терминальный сессиях пользователей. Так как она расположена на локальной машине, другие сервера RDCB не смогут ее использовать. Для создания HA для RDCB нужно перенести ее на выделенный SQL сервер, на котором она будет доступна другим серверам.
Настройка высокой доступности для RDS Connection Broker
Прежде чем добавить в ферму второй хост с ролью RD Connection Broker, нужно перенести локальную базу RDCB на внешний SQL сервер.
Для переноса БД Connection Broker из локальной базы на выделенный SQL Server нужно перейти в Server Manager -> Remote Desktop Services -> Overview. Чтобы запустить мастер создания отказоустойчивой конфигурации RD Connection Broker, щёлкните по изображению роли RD Connection Broker и выберите пункт Configure High Availability.
Выберите Dedicated Database Server. Затем нужно указать параметры подключения к SQL Server, на который будет перенесена локальная база RDCB.
Нужно заполнить три поля:
- DNS name for the RD Connection Broker Cluster: FQDN имя фермы RDCB, для которой мы создавали записи в DNS для Round Robin (в нашем примере это
HQRDCB.winitpro.loc). Именно по этому адресу будут обращаться RDP клиенты при подключении к серверам RD Connection Broker; - Database Connection String – здесь нужно указать строку подключения с базе на SQL сервере. Формат строки такой:
DRIVER=SQL Server Native Client 11.0;SERVER=<SQL Server Name>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<DB Name>В данном примере SQL Server Name – имя SQL сервера, где нужно создать базу, а DB Name – имя новой базы данных:DRIVER=SQL Server Native Client 11.0;SERVER=srv-rds2.resource.loc;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB
На следующем этапе нажмите Configure.
Затем подключитесь к SQL Server с помощью SQL Management Studio и проверьте, что была создана новая база данных RDCB_DB.
Вам нужно предоставить обоим серверам RD Connection Broker права на запись в эту базу. Перейдите в Database -> RDCB_DB -> Security -> Users -> New user.
Создайте двух новых пользователей
BUILTIN\RDS Management Servers
и
winitpro\HQ RDS Connection Brokers
. Предоставьте этим группам права db_owner и public.
Для обеспечения высокой доступности на случай выхода из строя первого сервера, необходимо в текущую конфигурацию добавить второй сервер RD Connection Broker.
Щелкните по иконке RD Connection Broker, и выберите пункт Add RD Connection Broker Server.
Укажите имя второго сервера, на котором нужно установить роль Connection Broker и нажмите Next. Теперь в списке хостов фермы RDS появится два сервера с ролью RDCB. Также появится надпись RD Connection Broker (High Available Mode).
На этом настройка High Availability конфигурации Connection Broker завершена.
Настройка отказоустойчивой конфигурации SQL Server для RD Connection Broker HA
Теперь нужно обеспечить отказоустойчивую конфигурацию для базы данных SQL. Пока она запущена только на одном сервере. Базу данных RD Connection Broker нужно разместить в кластере SQL. Это может быть, как классический Failover Cluster, так и группа высокой доступности SQL Always On.
Базовая настройка Always On в SQL Server 2019 рассмотрена в отдельной статье. Здесь мы только вкратце опишем основные особенности:
- Установите роль Failover Clustering и соберите кластер SQL-RDS из двух хостов RDCB со свидетелем с кворумом на любом файловом сервере (описано в статье про Always On кластер чуть выше);
- Включите опцию Enable Always On Availability Groups в настройках SQL Server Configuration Manage на обоих серверах;
- Запустите New Availability Group Wizard;
- Задайте имя Availability Group (SQL-RDS);
- Выберите базу, которую вы хотите поместить в группу высокой доступности (RDCB_DB);
- Добавьте второй сервер SQL в группу высокой доступности, включите опцию Automatic Failover;
- На вкладке Listener задайте имя и IP адрес, которое будет использоваться клиентами для подключения к базе данных в группе Always on (SQL-RDSDB-liste);
- Запустите консоль Failover Cluster Manager (
FailoverClusters.SnapInHelper.msc) и проверьте, что в ролях появился новый ресурс.
Теперь нужно изменить строку подключения к SQL серверу с базой данных RDCB в настройках Connection Broker. Изменить строку подключения можно только из PowerShell.
Set-RDDatabaseConnectionString [-DatabaseConnectionString] <String> [[-ConnectionBroker] <String>] [ <CommonParameters>]
В нашем примере команда для переключения фермы RDCB на SQL базу данных в группе высокой доступности выглядит так:
Set-RDDatabaseConnectionString -ConnectionBroker srv-rds1.winitpro.loc -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=SQL-RDSDB-liste;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB"
Если команда не вернула ошибки, значит все OK. И теперь ваш кластер RDS Connection Broker настроен на использование SQL в группе высокой доступности Always On.
Откройте настройки ферму RDS и убедитесь, что теперь для HA используется новая строка подключения (Tasks -> Edit Deployment Properties).
Итак, мы создали высоко доступный сервис RDS Connection Broker на Windows Server 2022/2019. Вы можете протестировать доступность RDCB, отключив один из серверов фермы RDS. После этого вы можете продолжить настройку фермы RDS, создать сервер лицензирования RDS, добавить RDSH сервера, настроить коллекции, опубликовать приложения, HTML5 веб клиент RDS и т.д.
А никак нельзя использовать SQL Express? Я когда разворачивал WDS столкнулся, что для того, чтобы разворачиваемые машинки смогли брать параметры из этой базы надо было открыть своеобразный доступ к этой базе из сети, а не только с локально машинки. Разве так нельзя сделать? Эти манипуляции описаны в разделе «Настройка сервера SQL Server 2008 Express» статьи «http://www.oszone.net/11530/Windows-7-install-15».
Я к тому, что неужели требуется покупаться дорогущий SQL Server для такой малозатратной с точки зрения ресурсов задачи?
Требования в SQL Server Standart есть в спецификации, но думаю для этих целей подойдет и SQL Express.
Естественно к SQL Express нужно открыть сетевой доступ:
1) Включить прослушивание TCP/IP порта 1433 и службу SQL Server Browser
2) Открыть порт 1433 во входящих соединениях Брандмауэра Windows
3) В настройках экземпляра базы в разделе Connections поставить флажок «Allow remote connections to this server»
4) Насколько я помню, инстанс SQL Express как-то особенно назывался, так вот в строке подключения нужно правильно его указать.
«На SQL сервере с помощью SQL Server Management Studio в разделе Security нужно создать новый login и предоставить доменной группе RDCB права с возможностью создания и редактирования баз данных. Также этой группе нужно предоставить полные права на каталог установки SQL.»
Вот все понятно, кроме того как привязать созданную группу к этому SQL логину (я так понимаю в результате все запросы с брокеров будут обрабатываться от лица этого логина), ну вот хоть тресни не выходит у меня. Если несложно просветите нуба подробнее по этому пункту
Открываете SQL Server Management Studio. В разделе Security->Logins добавляете новый логин (в качестве Login Name находите свою доменную группу RDCB) c правами dbcreator и sysadmin (после создания БД права можно уменьшить, ограничив их только базой RDCB)
Я вот тоже тормозил минут 20, очень не ясно описывается в статье. Во первых не сказано что тип пользователя — пользователь Windows. Во вторых там два поля — имя пользователя и имя для входа. Вообще ни слова где что как указывать. Вроде бы подробная инструкция, а тут автор просто пропустил да еще и замазал все. Сиди гадай что имеется в виду
а в чем отказоустойчивость при роунд робине? если 1 сервер не доступен днс продолжит туду слать запросы. нужен nlb
Роунд робин + неотказоустойчивая SQL-база — аляповатая кластеризация от мягкотелых. Брр.. Придется оставаться на 2008-й
есть НА RDCB (2 шт) и 4 штуки RDSH
Если выключить 1й RDSH то все активные на нем юзеры не могут переподключиться к остальным RDSH 5 и более минут.
Как уменьшить задержку ??
Вот похожая проблема и решение.
Цитата с https://blog.it-kb.ru/2013/09/05/remote-desktop-services-rds-rd-session-host-and-web-access-in-farm-high-availability-rd-connection-broker-in-nlb-cluster-on-windows-server-2012/
Леонид / 01.04.2016 14:19
Коллеги, способ есть. Как правильно заметил AlektroNik, необходимо лезть в SQL базу CB. Нужно дать ему (брокеру) понять, что одного из серверов больше нет. В случае возникновения вышеописанной ситуации мне помогает небольшой скрипт. Здесь Servername — имя «упавшего» сервера.
delete from EnvironmentProperty where EnvironmentId in (select id from Environment where name=’Servername’);
delete from Environment where name=’Servername ‘;
delete from TargetProperty where targetid in (select id from target where name=’Servername ‘);
delete from TargetIp where targetid in (select id from target where name=’ Servername’);
delete from session where targetid in (select id from target where name=’ Servername’)
delete from target where name=’Servername ‘;
Используйте на свой страх и риск. Я проверял 3 раза, помогало.
Развернул точно такую схему, в итоге, при подключении через dns запись циклического перебора, которая ссылается на посредника пользователь подключается к посреднику, а не к хосту. ЧЯДНТ?
Вы не совсем правильно подключаетесь.
Для начала вам нужно через веб интерфейс хотя бы сохранить файлик подключения к коллекции. Если Вы его откроете в блокноте то там будет строчка с именем Вашей коллекции.
Например, loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.Collections-RDS
Простите может я что не понимаю, но если нужна отказоустойчивость то можно просто путем перебора адресов, без брокера. Весь этот огород только ради балансировки нагрузки? В начале статьи написано (и совершенно верно) что брокер нужен для балансировки. И тут же пишут что статья будет не про балансировку, а про отказоустойчивость. Отказоустойчивость можно сделать перебором адресов, первый который ответит и эта функция брокера где то там вторая с конца. Очень разочаровала статья, самое главное как задать параметры нагрузки и перераспределения сеансов — не описано
Спасибо! Добавил эту строчку в реестр посредника подключений — всё отлично работает, но столкнулся с большой проблемой: на RDP, начиная с win2008 и выше всё работает, на 2003 и тонких клиентах редирект перестаёт работать и продолжает кидать на сервер посредника. Возможно ли решить эту проблему?
Добрый день, пытаюсь настроить Настройка высокой доступности Посредника подключений (Connection Broker High Availability) по вашей инструкции, но у меня так и появляется сообщение о не возможности создать базу, хотя в sql сервере подключения я вижу, права группе дал максимальные, sqlncli одинаковой версии с сервером (я использую 2008 r2 sp3)
Может подскажете, где я мог накосячить?
Доброе время суток.
Посмотрите вот здесь: https://dailysysadmin.com/KB/Article/4071/how-to-build-an-rds-farm-in-with-windows-2019-using-rds-broker-ha-and-rds-session-hosts/
В SQL configuration manager проверьте, что указан порт. У меня не было и тоже получал сообщение об ошибке.
Здравствуйте!
Ваша статья заканчивается очень интересным предложением: «Отказоустойчивость SQL сервера можно реализовать с помощью HA SQL кластера или зеркалирования базы SQL.» А не могли бы Вы поподробнее осветить данный момент. В частности, в нашей сети юыл развернут кластер терминальных серверов (RDCB), БД которого была размещена на отдельном SQL сервере, сейчас развернули у себя группу доступности AlwaysOn из двух серверов БД, и соответственно хотим изменить действующее подключение к базе RDCB с отдельного сервера БД, на группу доступности. То, что это делается через командлет Powershell нам известно, единственное, что смущает это параметр DataBasePath (путь к файлу БД), который на серверах группы доступности разный. И вопрос: какой путь к файлу БД необходимо указывать, в случае если БД развернута на 2-х серверах группы доступности?
Придется переместить БД RDCB так, чтобы на обоих узлах кластера AlwaysOn путь к базе был одинаковым. Посмотрите эту статью: там довольно подробно описан такой вариант конфигурации: _https://ryanmangansitblog.com/2014/02/24/rds-2012-sql-alwayson-considerations/
Здравствуйте!
Прошу сразу не кидаться тапками. Но немного, видимо, отстал от жизни. Есть различные варианты реализации: Как в статье (два выделенных RDSH и n-ное количество RDSH), объединенные на одном сервере роли RDSH и RSCB (при этом все серверы RDSH они же RDCB)..
Есть ли рекомендация по совмещению ролей RDSH и RDCB? В каких случаях рекомендуется их разносить на разные серверы, есть ли в этом смысл если, скажем, планируется ферма на 8-10 терминальных серверов (не проще на все серверы установить роли RDSH и RDCB и настроить ферму посредством DNS RR)?
При использовании DNS Round-robin, понимает ли RDP клиент, что нужно обращаться к следующему серверу из списка если первый недоступен?
Заранее благодарен за ответы.
Я тоже не нашел этого в статье. Нашел грубый перевод иностранных статей, жутко урезанный, где местами поменяли абзацы (так как искал ответы на вопросы в других ресурсах). Брокеры это вообще не ради отказоустойчивости, это скорее сопутствующий бонус
Здравствуйте.
Проделал все эти операции. Всё получилось хорошо, но не могу остановить встроенный сервер sql express.
При его остановки останавливаются все службы удаленных рабочих столов. И запускаться без него не хотят. Мне необходимо, чтоб эти службы стали работать с базой расположенной на MSSQL, а не получается.
Нужно сначала изменить используемую SQL базу в настройках RDCB. А потом отказываться от локальной SQL Express, подозревая брокер сейчас завязан на ней.
Добрый день, большое спасибо за статью. Помогите пожалуйста разобраться. Настроил 2 CB в DNS RR в HA и 2 Terminal. Пока оба CB online, все работает нормально — сессии разбрасываются корректно.
Вопросы:
1. Однако, в логах видно, что сессии может разбрасывать не активный management server (MS). Те, активным указан, скажем CB1, а записи о редиректе в логах только на CB2 и кол-во редиректов не соответствует RR DNS, те, на CB2 их в разы больше. DNS отрабатывает нормально. Это нормальное поведение, почему так?
2. Основной вопрос: если оставить в дисконнекте 1 сессию на Term1, после чего выключить CB1 (активный MS) и подождать, пока ферма поймет, что CB1 оттопырился и сделает активным CB2 (минут 5), то после этого, при соединении уже на Term2, все равно бросит на Term1, где есть дисксессия. Это ожидаемое поведение. Однако, если после выключения CB1 не ждать,а подключиться сразу к Term2, то соединение пройдет уже на Term2, при этом в таблице БД и ServerManager появляется две сессии, одна в дисклнекте, а вторая активная. Это так и должно быть или я что-то не правильно настроил?
Спасибо.
Уточните редакцию Windows Server, на которой вы строите свою терминальную инфраструктуру.
1. Диспропорция в активных сесиях пользовтелях при этом есть? Что происходит при отключеннии одного из CB?
2. Если я правильно вас понял, у вас по сути могут быть две сессии для одного пользователя на двух разнных RDS серверах — так не должно быть.
Уважаемый автор, подскажите пож-ста, насколько схема описанная в сабже актуальна на конец 2019 года. Есть решения более эффективные или нет. Есть потребность пересобрать терминальные сервера на 2016 лицензии, а новых веяний не нахожу в поисковиках
В RDS 2016 мало что изменились. Microsoft уже давно буксует на месте в том числе в RDSH.
Роль Connection Broker осталась, так что можете пользоваться этой статьей. Изменений будет минимум.
Самое полезное — тепер все RDCB могут быть в режиме active-active.
Поправьте, пожалуйста, Database Connection String для SQL2012 — там двоеточие как часть строки запроса. Это сбивает с толку. Спасибо!
Исправлено
Приветствую!
Имею 2 Windows Server 2016, на которых настроены слубы удаленных рабочих столов.
Делаю по статье, буксанул на создании отказоустойчивой кластеризации.
Делаю по шагам.
1. Настроил на обоих серверам коллекции сеансов + nativeclient 2012
2. Установил на выделенный сервер MSSQL Express 2012.
3. На первом терминальнике запускаю создание отказоустойчивого кластера, где ввожу:
а. Имя Round Robin
б. Строка подключения к базе (как я понял, базы быть не должно, при подключении она должна создаться)
в. Путь к каталогу с базой (путь локальный для сиквела)
Правильно ли я понял?
В итоге получаю ошибку
Что база недоступна или сервак недоступен, в общем стандартный отбойник.
Что делаю не так?
win 2012 R2.
Веб доступ к удаленным рабочим столам,
Шлюз удаленных рабочих столов,
Посредник подключений к удаленному рабочему столу,
Коллекция из двух узлов удаленных рабочих столов.
Все работает, пользователи распределяются между двумя узлами равномерно.
Как сделать, чтобы один пользователь, допустим «Vasia» всегда попадал на первый узел, а на второй ни когда. При этом остальные пользователи балансировались как обычно?
Присоединяюсь к вопросу.
Сделать разные rds коллекции с разными RDS серверами и группами доступа. Вася должен состоять только в группе доступа, привязанной к коллекции с одним сервером.
Это и было сделано, а вопрос остался.
Добрый день. Есть ферма терминальных серверов RDCB, RDLC и несколько RDSH. Возникла потребность в обновление ОС до server 2019. Сервера RDSH обновились поверх из под ОС без проблем. После обновления RDCB возникла проблема (служба MSSQL$MICROSOFT##WID не удалось выполнить вход как NT SERVICE\MSSQL$MICROSOFT##WID) Речь идет о нескольких службах. Беглый осмотр ничего не дал. Откатились по снапшоту.
Подскажите где можно найти информацию, может ссылка есть. Что происходит в моем случае с RDCB? Получится ли обновить ОС поверх и какие нюансы необходимо учесть? Исходная ОС 2012 R2.
И ещё один вопрос тогда. Как правильно убрать режим HA на win2019?
Хотя, сам же отвечу, после недолгих поисков.
https://ryanmangansitblog.com/2013/04/14/troubles-with-removing-rd-connection-broker-high-availability/
«Once a RD Connection Broker HA configuration is installed, you cannot revert back to the windows internal Database with out decommissioning the whole RDS configuration.»
«Once a HA is configured, you are stuck with it unless you want to rebuild everything.»
Вот так вот(((
А принцип работы этого HA в боевой практике кто-то применял?
Например ложится один брокер,второй сам сможет закидывать соединения, или надо вручную указать?
а если бд mssql?
Рассмотренный сценарий описывает полностью отказоустойчивый вариант.
Вы можете потерять любой из mssql серверов или один из RDCB и rds пользователи будут по прежнему подключаться к своим сессиям.
хорошо, ложится один брокер, он сможет продолжать раскидывать пользователей, или ему надо это принудительно указать?
А у данного балансировщика есть опция помимо весовой, указывать балансировку ресурсов?(например RAM/CPU )
Это регулируется весом RDSH хостов в коллекции RDS. Условно у вас два хоста, один из них в два раза мощнее. Ставите относительный вес 50 для слабого и 100 для более мощного.
В рещультате сессии будут балансироваться на основании весов. На хост с более высоким весом будет прилетать больше rdp сессий.
https://winitpro.ru/wp-content/uploads/2022/02/load-balancing-nastrojka-vesov-serverov-rdsh.png
А если мне нужно более гибкая балансировка,чтобы объемный процесс у одного пользователя не заставлял виснуть весь терминальный сервер?
Нет, Connection Broker балансирует только по количеству сессий. Если нужно ограничить использование CPU одним пользователем (монополизацию) можно попробовать использовать Fair Share на RDS.
Можно ограничивать исопльзование CPU, дисков и сети, но не памяти.
https://docs.microsoft.com/en-us/troubleshoot/windows-server/remote/fair-share-enabled-by-default-in-rds
но как я понял с описания это опция в новых ос включена по умолчанию…
И нашел лишь одну похожую политику: Отключить планирование ЦП со справедливым разделением(что активировать естественно неразумно)
А если на примете иный балансировщики для MS терминалов которые позволяют условно задавать значение сколько ресурсов может использовать тот или иной пользователь/процесс?
У меня два интернет-канала. Два маршрутизатора.
Будет ли кошерной такая конфигурация:
Два шлюза рабочих столов, подключённых каждый к своему маршрутизатору заведённых на отказоустойчивый брокер. На шлюзах в свойство «Ферма серверов» я должен указать адреса обоих брокеров?
Можно ли разместить SQL сервера на тех же машинах, что и брокеры?
1) Я не совсем понял, зачем вам привязывать RDS шлюзы к конкретному маршрутизатору? Вы хотите обеспечить некую отказоустойчивую конфигурацию RDGW?
Продумали как будете переключать пользователей на новый шлюз при падении одного из каналов?
2) Да, размещение SQL на серверах с брокерами допустимо.
1) Я хочу сделать две A-записи с одщинаковым именем и адресами от двух провайдеров. Здесь у меня как раз и есть сомнения: клиент получит один адрес и будел ломиться по нему вне зависимости от того работает шлюз или нет или попробует на другой IP.
Все верно, поэтому нужно перед вашими серверами ставить некий балансировщик с проверкой keepalive или реверс прокси
Нашёл что решение не пойдёт: https://social.technet.microsoft.com/Forums/ru-RU/f8fe58f0-3552-404f-8275-61ad48756ee4/10861090108210721079108610911089109010861081109510801074?forum=WS8ru
Тогда не понятно как настроить отказоустойчивость шлюза на двух провайдерах.
И ещё воросик:
Я так понимаю, что в 2008 R2 отказоустойчивый брокер строили на Windows Failover Clustering, в 2012
строили на Windows NLB.
Это вроде новый вариант. Чем он лучше?
Начиная с 2012 Connection broker не нужен failover cluser или nlb. Он из коробки обеспечивает модель active-active.
В вашем случае, нужно решить вопрос с отказоустойчивостью RDGW. Вроде он поддерживает развертывание в NLB, но я не пробовал.
Поднял у себя 2 RDCB+WA и объединил в HA, добавил DNS RR, 2 RDSH объединил в коллекцию.
Всё гудит и работает как по шаблону.
Решил проверить работу при отказе узла и понял, что брокер не сразу срабатывает, а в течении 10 минут.
То есть при отказе одного из узлов брокер пытается отправить пользователя на недоступный хост, и только через некоторое время до него доходит, что он не доступен и кидает на другой.
Хотелось, чтобы брокер чуть быстрее соображал. Это возможно сделать?
Как я понял вы описываете сценарий с недоступностью одного их хостов RDSH?
Посмотрите статью «RD Connection broker and it’s polling intervals »
_https://microsoftplatform.blogspot.com/2011/01/rd-connection-broker-and-its-polling.html
К сожалению — не помогает.
По какой-то неведомой причине сервер RDCB отказывается считать упавший сервер потерянным и упорно редиректит для реконнекта на уже «мертвый» RDHS. Тайминги из ссылки выше, такое ощущение, что полностью игнорируются, так как я выкрутил их значения в реестре в минимум, но ситуация не изменилась.
В логах RDCB мы можем найти вот такой стаус:
RD Connection Broker successfully processed the connection request for user ####. Redirection info:
Target Name = server-2
Target IP Address = 192.168.1.2
Target Netbios = server-2
Target FQDN = server-2.domainame
Disconnected Session Found = 0x1
И вот пока последний параметр, а именно Disconnected Session Found = 0x1 не поменяет свое знание с 1 на 0, реконнекта не произойдет.
В результате отказоустойчивый терминальный кластер таковым является только номинально. А в случае реального выхода из строя одной из нод, приводит к обрыву текущих сессий (что в целом не так критично) и даунтайму около 10 минут, прежде чем «упавший» пользователь сможет возобновить свою работу. А вот это уже очень плохо.
Пока найти вразумительного решения по данной ситуации не удалось.
Добрый день. Есть ферма терминальных серверов RDCB, RDLC и несколько RDSH. Возникла потребность в обновление ОС до server 2019. Сервера RDSH обновились поверх из под ОС без проблем. После обновления RDCB возникла проблема (служба MSSQL$MICROSOFT##WID не удалось выполнить вход как NT SERVICE\MSSQL$MICROSOFT##WID) Речь идет о нескольких службах. Беглый осмотр ничего не дал. Откатились по снапшоту.
Подскажите где можно найти информацию, может ссылка есть. Что происходит в моем случае с RDCB? Получится ли обновить ОС поверх и какие нюансы необходимо учесть? Исходная ОС 2012 R2.
Если RDCB на отдельном хосте, можно просто поднять новый сервера с WS2019 и перенести на него настройки как описано тут:
https://winitpro.ru/index.php/2022/01/26/perenos-rds-connection-broker-web-access/
Если апгрейд на месте, да еще через версию, не зашел, так думаю будет проще, чем дебажить.
Спасибо, изучу.
Привет! Возможно кто-то сталкивался с такой проблемой. Есть ферма из 3х rdsh серверов, одного брокера. Профили UPD. Выкинули один сервер rdsh. Добавили новый. Теперь проблема. на новом, профили upd не подключаются, даже ошибок по этому поводу не нахожу, только то что не может подключить профиль пользователя и будет использован временный. Папки в USERS создаются TEMP.USR.001 и тд. В коллекции выключил и включил UPD не влияет ни как. на двух других все ок профили подключает.
ЗЫ: Там где лежит шара на профили для этого сервера доступ есть.
ЗЫ2: Для пользователей так же есть доступ.
а) Версия Windows Server на RDS не поменялась?
б) Все 3 хоста добавлены в одну коллекцию?
в) В логах Event Viewer -> Application ( с фильтром по User Profile Service) и в Applications and Services Logs -> -Microsoft -> Windows -> User Profile Service -> Operational что то есть?
Привет. В случае отказа и недоступности одного RDSH, появляется проблема.
Пользователи чьи сессии были на недоступном хосте не могут зайти.
Завершить сессии штатно нет возможности.
Нашел решение ручное
delete from rds.Session where TargetId = '$RDSHID'Позволяет убрать зависшие сессии и пользователи вновь могут зайти на другой RDSH в коллекции .
Хотелось бы найти решение как правильно организовать отказоустойчивость именно сервисов RDSH в автоматическом режиме.
Так он и не будет выкидывать зависшие сесии. Условно RD connect broker распределяет только сессии при подключении. Если пользователь уже зашел на сервер, брокер будет считать что его сессия и должна быть там.
Добрый день. А можете описать более подробно про этот метод? Это нужно делать запрос в MSSQL на db брокера ?
Вот тут описано, как подключиться к MSSQL базе Connection Broker через SQL Management Studio.:
https://winitpro.ru/index.php/2022/01/31/udalit-server-iz-rds/
Здравствуйте. Почему-то никто не задал самый главный вопрос, на мой взгляд новичка) А сам прослушиватель группы AlwaysOn на каком сервере должен находиться? И если этот единственный сервер упадет, то вся отказоустойчивая махина перестанет работать?
Листенер это ресурс кластера always on. AlwaysOn обеспечивает отказустойчивость базы SQL и имени/IP листенера за счет того, что несколько нод живут в кластере. Вы указываете в строке подключение имя прослушивателя(
SERVER=SQL-RDSDB-liste), а не конкретной ноды SQL.Спасибо за ответ. Да, эту часть статьи я понял. Но листенеру должен быть присвоен какой-то IP-адрес. Этот адрес должен быть присвоен какой-то сетевой карте, а эта сетевая карта, неважно настоящая или виртуальная, должна находиться в какой-то операционной системе. Так вот эта самая операционная система может являться самим брокером кластера? или же лучше вынести эту операционную систему за рамки кластера?
Листенер со стороны AD это — Failover cluster virtual network name account.
Подробнее про него можно почитать тут: https://learn.microsoft.com/en-us/windows-server/failover-clustering/configure-ad-accounts
Выглядит как объект типа Computer в AD, но факту только в AD эта сущность и существует. Реальной ОС или физической/виртуальной машины за ней нет.
> А сам прослушиватель группы AlwaysOn на каком сервере должен находиться?
Если упросить, то листенер это виртуальная сущность, а не физическая. По сути это просто А запись внутри которой не один IP, а несколько. Поэтому можно сказать, что листенер живет у вас на DNSе.
При настройке режима высокой доступности вылетает сообщение:
«база данных указанная в строке подключений недоступна с сервера посредника подключений к удаленному рабочему столу»
в логах SQL сервера ошибка: Login failed for user «Domain\Имя одного из коннекшн брокера»
Reason:Could not find a login matching the name provided