Поделиться через


Архитектура служб удаленных рабочих столов

Службы удаленных рабочих столов (RDS) предоставляют гибкую платформу для размещения приложений и рабочих столов Windows в облаке или локальной среде. В этой статье описаны распространенные архитектуры развертывания RDS и показано, как интегрировать RDS со службами Azure в соответствии с потребностями вашей организации.

Используйте эти схемы архитектуры, чтобы понять следующее:

  • Как роли RDS работают вместе в разных сценариях развертывания.
  • Параметры базовых и высокодоступных конфигураций RDS.
  • Шаблоны интеграции с предложениями Azure Platform as a Service (PaaS).

Независимо от того, планируете ли вы новое развертывание RDS или модернизируете существующий, эти архитектуры предоставляют проверенные шаблоны для разработки решения, соответствующего вашим требованиям к производительности, доступности и безопасности.

Схемы архитектуры в этой статье показаны с помощью RDS в Azure. Однако, так как службы удаленных рабочих столов являются ролью в Windows Server, ее можно развернуть локально и в других облаках. Эти схемы в первую очередь предназначены для демонстрации того, как роли служб удаленных рабочих столов взаимодействуют и используют другие службы.

Стандартные архитектуры развертывания RDS

Службы удаленных рабочих столов имеют два варианта стандартных архитектур.

  • Basic deployment: contains the minimum number of servers to create a fully effective RDS environment, but with no redundancy.

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

В следующих разделах показаны компоненты каждой архитектуры и их совместная работа. На схемах также показано, как роли службы удалённых рабочих столов соформируются на серверах, что является распространенной практикой для снижения затрат и сложности.

Basic deployment

Эта архитектура иллюстрирует базовое развертывание служб удаленных рабочих столов в Azure, которое обеспечивает удаленный доступ к рабочим столам и приложениям через один регион Azure. Развертывание использует внешнюю подсистему балансировки нагрузки для распределения входящих подключений из общедоступного Интернета в инфраструктуре RDS.

Основные роли RDS распределяются между несколькими виртуальными машинами в одной группе ресурсов. Брокер подключений к удаленным рабочим столам (RDCB) и сервер лицензирования удаленных рабочих столов (RDLS) совместно используют одну виртуальную машину, а компоненты шлюза удаленных рабочих столов (RDGW) и веб-доступа удаленных рабочих столов (RDWeb) развертываются на отдельной виртуальной машине. Поддержка инфраструктуры включает контроллер домена Active Directory и файловый сервер для дисков профилей пользователей и общего хранилища. Сервер узла сеансов удаленных рабочих столов (RDSH), развернутый на собственной виртуальной машине, предоставляет фактические сеансы рабочего стола и размещенные приложения конечным пользователям.

Все виртуальные машины взаимодействуют через виртуальную сеть Azure, которая обеспечивает безопасное сетевое подключение между компонентами RDS при изоляции развертывания от других ресурсов Azure. Эта архитектура обеспечивает экономически эффективную отправную точку для организаций, желающих перенести размещение на рабочем столе в Azure, благодаря гибкости масштабирования отдельных компонентов по мере роста использования.

Схема, показывающая базовое развертывание служб удаленных рабочих столов в Azure с ролями RDS, распределенными между виртуальными машинами, внешним балансировщиком нагрузки, контроллером домена Active Directory, файловым сервером и подключением к виртуальной сети Azure.

Высокодоступное развертывание

Эта архитектура демонстрирует развертывание служб удаленных рабочих столов, которое интегрирует предложения Платформы Azure как услуга (PaaS) для повышения масштабируемости и снижения затрат на управление. Ключевым отличием от базового развертывания RDS является замена традиционной виртуальной машины SQL Server с базой данных SQL Azure для хранения данных конфигурации RDS и пользовательских сеансов.

Роли RDS поддерживают один и тот же шаблон распределения, но с несколькими экземплярами каждого; Брокер подключений к удаленным рабочим столам (RDCB) и сервер лицензирования удаленных рабочих столов (RDLS) совместно используют один набор виртуальных машин, а компоненты шлюза удаленных рабочих столов (RDGW) и веб-доступа удаленных рабочих столов (RDWeb) развертываются в отдельном наборе виртуальных машин. Узлы сеансов удалённого рабочего стола (RDSH) продолжают предоставлять сеансы рабочего стола и приложения из их выделенных виртуальных машин. Поддержка инфраструктуры включает контроллер домена Active Directory и файловый сервер для профилей пользователей и общего хранилища.

С помощью базы данных SQL Azure вместо локального экземпляра SQL Server эта архитектура обеспечивает встроенную высокую доступность, автоматическую архивацию и упрощенное управление базами данных. База данных SQL Azure обрабатывает требования к базе данных брокера подключений RDS, устраняя необходимость в обслуживании, исправлении и мониторинге отдельного сервера базы данных. Этот гибридный подход объединяет гибкость инфраструктуры как службы (IaaS) для ролей RDS с управляемыми преимуществами PaaS для уровня базы данных, что приводит к снижению операционной сложности и повышению надежности.

Схема развертывания служб удаленных рабочих столов в Azure с несколькими экземплярами ролей RDS, Базой данных SQL Azure для обеспечения высокой доступности, контроллером домена Active Directory, файловым сервером и подключением к виртуальной сети Azure.

Архитектуры служб удаленных рабочих столов с уникальными ролями PaaS в Azure

Хотя стандартные архитектуры развертывания служб удаленных рабочих столов охватывают большинство сценариев, Azure продолжает развивать собственные решения PaaS, чтобы приносить клиентам пользу. В следующих архитектурах показано, как они включаются в RDS.

Развертывание RDS с помощью доменных служб Microsoft Entra

Две стандартные схемы архитектуры основаны на традиционном развертывании Active Directory (AD) на виртуальной машине Windows Server. Однако если у вас нет традиционного AD и у вас есть только клиент Microsoft Entra, например через службы Microsoft 365, но по-прежнему хотите использовать RDS, вы можете использовать доменные службы Microsoft Entra для создания полностью управляемого домена в среде IaaS Azure, которая использует те же пользователи, которые существуют в клиенте Microsoft Entra. Этот параметр удаляет сложность ручной синхронизации пользователей и управления дополнительными виртуальными машинами. Доменные службы Microsoft Entra могут работать в любом развертывании: базовые или высокодоступные.

Схема развертывания служб удаленных рабочих столов в Azure с помощью доменных служб Microsoft Entra с ролями RDS, распределенными между виртуальными машинами, управляемыми доменными службами, интеграцией Active Directory и подключением к виртуальной сети Azure.

Развертывание RDS с помощью прокси приложения Microsoft Entra

Две стандартные схемы архитектуры используют серверы RD Web/Gateway в качестве точки входа в систему RDS. В некоторых средах администраторы предпочитают удалять собственные серверы из периметра и использовать технологии, которые также обеспечивают дополнительную безопасность с помощью обратных прокси-технологий. Роль PaaS Microsoft Entra Application Proxy хорошо подходит для этого сценария.

Сведения о поддерживаемых конфигурациях и создании этой установки см. в статье "Публикация удаленного рабочего стола" с помощью прокси приложения Microsoft Entra.

Схема развертывания служб удаленных рабочих столов в Azure с помощью прокси приложения Microsoft Entra с ролями RDS, распределенными между виртуальными машинами, интеграцией прокси приложения и подключением к виртуальной сети Azure.