У меня есть небольшая ферма Terminal Server 2008 с балансировкой нагрузки (с использованием Session Broker) за сервером шлюза, доступ к которому осуществляется из Интернета. У меня проблема в том, что существует задержка в 20–30 секунд, если брокер сеанса переключает пользователя на другой сервер во время входа в систему. Я думаю, это связано с тем, что я устанавливаю уровень безопасности RDP, а не SSL.
альтернативный текст http://www.lytzen.name/blogimages/tsstructure.png
Фон
Сервер шлюза имеет общедоступный маршрутизируемый IP-адрес и DNS-имя, поэтому к нему можно получить доступ из Интернета, и все пользователи входят через этот маршрут (система используется для предоставления доступа к размещенным приложениям для внешних клиентов). Фактические серверы терминалов имеют только внутренние IP-адреса. Это работает действительно хорошо, за исключением того, что с клиентом Vista или Windows 7 клиент удаленного рабочего стола будет согласовывать с сервером использование SSL для уровня безопасности. Затем открывается автоматически сгенерированный сертификат, который есть у TS1 или TS2, но поскольку они являются внутренними, автоматически сгенерированными сертификатами, клиент получит строгое предупреждение о том, что сертификат недействителен. Я не могу предоставить серверам правильно авторизованный сертификат, поскольку у серверов нет общедоступного маршрутизируемого IP-адреса или DNS-имени. Вместо этого я использую групповую политику, чтобы принудительно устанавливать соединения через RDP вместо SSL.
\Computer Configuration\Policies\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security\Require use of specific security layer for remote (RDP) connections
Пользователь Windows 7 теперь получает гораздо менее строгое предупреждение о том, что «идентичность сервера не может быть подтверждена», с чем я могу жить.
У меня недостаточно контроля над машинами конечных пользователей, чтобы попросить их установить новый корневой сертификат.
TS1 и TS2 также балансируются по нагрузке с помощью Session Broker, который установлен на сервере шлюза. Я использую циклический DNS, поэтому первоначальное соединение пользователя будет проходить через Gateway1 либо к TS1, либо к TS2. TS1 / TS2 затем поговорит с брокером сеанса и может передать пользователя другому серверу. Т.е. пользователь может подключиться к TS2, но после разговора с брокером сеанса пользователь может быть передан в TS1, где он будет запускать свой сеанс.
Когда происходит это переключение серверов, в моих настройках на экране отображается слово «Добро пожаловать» в течение 20–30 секунд, после чего оно мигает, снова отображается «Добро пожаловать», а затем мигают обычные экраны входа в систему (например, «дождитесь диспетчера профилей пользователей. " и т.д). Проведя некоторое исследование, я думаю, что происходит то, что пользователь полностью входит в систему TS2 (пока отображается «Добро пожаловать») перед тем, как перейти в TS1, где он затем снова входит в систему. Интересно, что обычно, когда вы видите слово «Добро пожаловать», маленький кружок слева вращается. Однако он не вращается во время этой задержки - экран просто застывает.
Это сообщение в блоге заставляет меня думать, что это потому, что CredSSP не используется, вероятно, потому, что я запрещаю SSL и принудительно использую RDP.
Что я пробовал
Я снова включил SSL, что убирает задержку приветствия. Однако, похоже, что это приводит к новой задержке намного раньше в процессе. В частности, когда клиент RDP говорит «инициализация соединения» - теперь это происходит намного медленнее. Не говоря уже о том, что проблема с сертификатом не позволяет мне без особых трудностей использовать это решение.
Я попытался отключить балансировку нагрузки (просто удалите серверы из фермы брокера сеансов), и соединения не имеют задержки.
Проблема также носит временный характер в том смысле, что только происходит, когда пользователя переводят с одного сервера на другой. Я проверил это, попытавшись подключиться напрямую к TS1 (через шлюз, конечно), а затем проверив, какой сервер я фактически подключился к.
Чтобы быть уверенным, я также обошел циклический DNS, чтобы увидеть, повлиял ли он как-то, а это не так. Настройка в основном соответствует рекомендациям MS здесь: Пошаговое руководство по балансировке нагрузки брокера сеансов TS
Я попытался перейти на специальный перенаправитель. По сути, вместо того, чтобы использовать DNS с циклическим перебором, я направил свой DNS на сервер шлюза и настроил его как выделенный перенаправитель (запретить вход в систему, добавить его в ферму). Увы, та же проблема.
Любые идеи или предложения с благодарностью получены.
Для внешнего доступа rdweb к шлюзу используйте сертификат с зарегистрированными внешними DNS и внутренними понятными именами. Таким образом, его можно использовать как на сервере шлюза, так и на серверах терминалов в ферме. В моем сценарии у нас есть внешний адрес, зарегистрированный rdweb для шлюза. который затем указывает на брокера соединений. внутренний доступ осуществляется через зарегистрированный внутри dns псевдоним xyzrdweb, который зарегистрирован на обоих терминальных серверах в ферме, фактически используя xyzrdweb, возвращает, какая запись была получена первой через dns. Внутренние пользователи обходят шлюз. К сожалению, внешние пользователи в этом сценарии имеют начальное медленное соединение до полутора минут до полной аутентификации, но после полной аутентификации приложения запускаются мгновенно, а запуск таких приложений, как Adobe Photoshop и т. Д., Занимает около 3-4 секунд.
Может быть, немного поздно для другого типа ответа, но я все равно добавлю его сюда. У меня также есть еще одна ошибка в моей настройке.
Я просто столкнулся с той же проблемой и следил за хлебными крошками журналов на всех четырех серверах (rdgw, ts01, ts02 и rdbroker). Я также использую самостоятельно выданные сертификаты на всех серверах, но RDGW и строгие предупреждения на самом деле предоставляют средства для оценки задержки, помимо просмотра журналов. Мой сценарий - это оригинальный плакат о том, что при перенаправлении происходит огромная задержка. Запросы сертификатов показывают, что клиент быстро подключается к начальному TS / перенаправителю. Если это TS, где находится сеанс, все в порядке. Если клиент перенаправлен, подключение к правильному TS занимает ровно 23 секунды. Каждый раз!
Глядя на пошаговое объяснение от Microsoft (http://technet.microsoft.com/en-us/library/cc772418%28WS.10%29.aspx) на шаге 6 TS начального соединения выдает клиенту команду перенаправления и предоставляет IP адрес правильного ТС. Вот в чем проблема, как я ее вижу. Первоначальное подключение через RDGW выполняется с использованием внутреннего FQDN исходного TS / перенаправителя. Перенаправленное соединение выполняется с использованием внутреннего IP-адреса правильного TS, а не FQDN. Я действительно могу воспроизвести эту задержку, используя внутренний IP-адрес исходного TS / перенаправителя. Или любой другой автономный TS в моем домене и дочерних доменах. В этом случае я также получаю 23-секундную задержку при первоначальном подключении.
Я считаю, что по этому поводу
редактировать; Но да, «Обход сервера шлюза удаленных рабочих столов для локальных адресов» сделал свое дело. Вид глупо, поскольку возвращенный IP-адрес находится далеко не в какой-либо локальной подсети на моих клиентах. К счастью, я создаю RDP-файлы со сценарием для своих клиентов, поэтому я смогу легко обойти эту проблему.
Типа ответа;
Когда мы начали запускать эту настройку в производственной среде, проблема, казалось, уменьшилась или исчезла, так что похоже, что это происходит только при небольшой пользовательской нагрузке. В этом есть смысл.
В самом клиенте RDP на вкладке «Дополнительно» в настройках «Подключиться из любого места» есть безобидный маленький флажок «Обход сервера шлюза удаленных рабочих столов для локальных адресов», который по умолчанию установлен. Теперь, в своей настройке, я просто указал "хостинг" в качестве имени сервера, к которому нужно попытаться подключиться, поэтому клиент RDP пытается найти этот сервер локально. перед пытается подключиться через сервер шлюза, вызывает долгую задержку. Простое снятие отметки с этого поля значительно ускорило подключение, по крайней мере, на тот момент, когда вы действительно подключитесь к серверу шлюза.
По сути, у вас есть два конкурирующих друг с другом механизма балансировки нагрузки. Вы описали проблему именно так, как я вижу ее. DNS Round Robin отправляет входящее соединение на один сервер, а затем брокер сеанса отправляет его на другой сервер, вызывая задержку в установлении сеанса.
Я предлагаю использовать DNS Round Robin или Session Broker, но не то и другое вместе.
Лично я бы использовал Session Broker. Я бы создал единую общедоступную запись DNS, которая указывает на сервер Session Broker, и позволила бы ему обрабатывать балансировку нагрузки входящих соединений между TS1 и TS2.