Architecture de Services Bureau à distance

Services Bureau à distance (RDS) fournit une plateforme flexible pour héberger des applications et des bureaux Windows dans le cloud ou en local. Cet article décrit les architectures de déploiement RDS les plus courantes et montre comment intégrer RDS aux services Azure pour répondre aux besoins de votre organisation.

Utilisez ces schémas d'architecture pour comprendre les points suivants :

• Fonctionnement et interaction des rôles RDS dans différents scénarios de déploiement.
• Options pour les configurations RDS de base et hautement disponibles.
• Modèles d'intégration avec les offres de plateforme en tant que service (PaaS) d'Azure.

Que vous planifiez un nouveau déploiement RDS ou que vous modernisiez une configuration existante, ces architectures proposent des modèles éprouvés pour concevoir une solution répondant à vos exigences de performance, de disponibilité et de sécurité.

Les schémas d'architecture de cet article illustrent l'utilisation de RDS dans Azure. Cependant, comme Services Bureau à distance est un rôle de Windows Server, vous pouvez aussi le déployer en local ou dans d'autres clouds. Ces schémas sont principalement destinés à illustrer la façon dont les rôles Services Bureau à distance sont colocalisés et utilisent d’autres services.

Architectures de déploiement de Services de Bureau à distance standard

La fonctionnalité Services Bureau à distance a deux architectures standard :

• Déploiement de base : contient le nombre minimal de serveurs pour créer un environnement RDS entièrement efficace, mais sans redondance.

• Déploiement à haute disponibilité : contient tous les composants nécessaires pour que votre environnement Services Bureau à distance puisse bénéficier du temps de disponibilité maximal garanti.

Les sections suivantes décrivent les composants de chaque architecture et leur mode d'interaction. Les schémas montrent aussi comment les rôles RDS sont regroupés sur les serveurs, une pratique courante pour réduire les coûts et la complexité.

Déploiement de base

Cette architecture illustre un déploiement fondamental des Services Bureau à distance dans Azure, offrant un accès à distance aux bureaux et applications via une seule région Azure. Le déploiement utilise un équilibreur de charge externe pour répartir les connexions entrantes depuis Internet sur l'infrastructure RDS.

Les rôles RDS principaux sont répartis sur plusieurs machines virtuelles au sein d'un même groupe de ressources. Le RD Connection Broker (RDCB) et le RD Licensing Server (RDLS) partagent une machine virtuelle, tandis que les composants RD Gateway (RDGW) et RD Web Access (RDWeb) sont déployés sur une autre machine virtuelle. L'infrastructure de support comprend un contrôleur de domaine Active Directory et un serveur de fichiers pour les disques de profil utilisateur et le stockage partagé. Le serveur RD Session Host (RDSH), déployé sur sa propre machine virtuelle, fournit les sessions de bureau et les applications hébergées aux utilisateurs finaux.

Toutes les machines virtuelles communiquent via un réseau virtuel Azure (Azure Virtual Network), qui assure une connectivité réseau sécurisée entre les composants RDS tout en isolant le déploiement des autres ressources Azure. Cette architecture constitue un point de départ économique pour les organisations souhaitant migrer l'hébergement de leurs postes de travail vers Azure, avec la possibilité de faire évoluer chaque composant à mesure que l'usage augmente.

Déploiement à haute disponibilité

Cette architecture montre un déploiement des Services Bureau à distance intégrant des offres PaaS d'Azure pour améliorer l'évolutivité et réduire la charge de gestion. La principale différence par rapport à un déploiement RDS de base est le remplacement d'une machine virtuelle SQL Server classique par une base de données Azure SQL pour stocker les données de configuration RDS et les sessions utilisateur.

Les rôles RDS conservent le même schéma de répartition, mais avec plusieurs instances de chaque rôle : le RD Connection Broker (RDCB) et le RD Licensing Server (RDLS) partagent un ensemble de machines virtuelles (VM), tandis que les composants RD Gateway (RDGW) et RD Web Access (RDWeb) sont déployés sur un autre ensemble de VM. Les hôtes de session RD (RDSH) continuent de fournir des sessions de bureau et des applications à partir de leurs machines virtuelles dédiées. L'infrastructure de support comprend un contrôleur de domaine Active Directory et un serveur de fichiers pour les profils utilisateur et le stockage partagé.

En utilisant Azure SQL Database à la place d'un SQL Server autogéré, cette architecture fournit une haute disponibilité intégrée, des sauvegardes automatiques et une gestion de base de données simplifiée. La base de données Azure SQL prend en charge les besoins de la base de données du RD Connection Broker, éliminant la nécessité de maintenir, corriger et surveiller un serveur SQL distinct. Cette approche hybride combine la flexibilité de l'IaaS pour les rôles RDS et les avantages gérés du PaaS pour la couche base de données, ce qui réduit la complexité opérationnelle et améliore la fiabilité.

Architectures de Services Bureau à distance avec des rôles Azure PaaS uniques

Bien que les architectures de déploiement Services Bureau à distance standard s’adaptent à la plupart des scénarios, Azure continue à investir dans des solutions PaaS internes qui génèrent de la valeur pour le client. Les architectures suivantes illustrent comment elles s'intègrent à RDS.

Déploiement RDS avec Microsoft Entra Domain Services

Les deux schémas d'architecture standard reposent sur un répertoire Active Directory (AD) classique, déployé sur une machine virtuelle Windows Server. Cependant, si vous n'avez pas de répertoire AD traditionnel et que vous n'avez qu'un locataire Microsoft Entra, par exemple via des services comme Microsoft 365, mais que vous voulez quand même tirer parti de RDS, vous pouvez utiliser Microsoft Entra Domain Services pour créer un domaine entièrement géré dans votre environnement Azure IaaS qui utilise les mêmes utilisateurs que ceux qui existent dans votre locataire Microsoft Entra. Cette option supprime la complexité de la synchronisation des utilisateurs, ainsi que de la gestion de davantage de machines virtuelles. Microsoft Entra Domain Services peut fonctionner dans un déploiement de base ou hautement disponible.

Déploiement RDS avec le proxy d'application Microsoft Entra

Les deux schémas d'architecture standard utilisent les serveurs de passerelle/web Bureau à distance en tant que points d'entrée côté Internet dans le système RDS. Pour certains environnements, les administrateurs préféreront supprimer leurs propres serveurs du périmètre et utiliser à la place des technologies qui fournissent également une sécurité supplémentaire via des technologies de proxy inverse. Le rôle PaaS du proxy d'application Microsoft Entra convient parfaitement à ce scénario.

Pour connaître les configurations prises en charge et la façon de créer cette configuration, consultez Publier le Bureau à distance avec le proxy d’application Microsoft Entra.