Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Remotedesktopdienste (RDS) bieten eine flexible Plattform zum Hosten von Windows-Anwendungen und -Desktops in der Cloud oder lokal. Dieser Artikel beschreibt allgemeine RDS-Bereitstellungsarchitekturen und zeigt, wie RDS in Azure-Dienste integriert wird, um die Anforderungen Ihrer Organisation zu erfüllen.
Verwenden Sie diese Architekturdiagramme, um Folgendes zu verstehen:
- Wie RDS-Rollen in verschiedenen Bereitstellungsszenarien zusammenarbeiten.
- Optionen für grundlegende und hoch verfügbare RDS-Konfigurationen.
- Integrationsmuster mit Azure Platform as a Service (PaaS)-Angeboten.
Ganz gleich, ob Sie eine neue RDS-Bereitstellung planen oder eine vorhandene bereitstellung modernisieren, diese Architekturen bieten bewährte Muster, die Ihnen beim Entwerfen einer Lösung helfen, die Ihren Anforderungen für Leistung, Verfügbarkeit und Sicherheit entspricht.
Die Architekturdiagramme in diesem Artikel zeigen die Verwendung von RDS in Azure. Da Remotedesktopdienste jedoch eine Rolle in Windows Server sind, können Sie sie lokal und in anderen Clouds bereitstellen. Diese Diagramme sollen in erster Linie die Zusammenstellung der RDS-Rollen und die Verwendung anderer Dienste veranschaulichen.
Standardarchitekturen für die RDS-Bereitstellung
Für die Remotedesktopdienste stehen zwei Standardarchitekturen zur Verfügung:
Grundlegende Bereitstellung: enthält die Mindestanzahl der Server, um eine vollständig effektive RDS-Umgebung zu erstellen, jedoch ohne Redundanz.
Hoch verfügbare Bereitstellung: enthält alle erforderlichen Komponenten, um die höchste garantierte Betriebszeit für Ihre RDS-Umgebung zu haben.
In den folgenden Abschnitten werden die Komponenten der einzelnen Architekturen und deren Zusammenarbeit dargestellt. Die Diagramme zeigen auch, wie die RDS-Rollen auf den Servern kolociert werden, was eine gängige Methode ist, um Kosten und Komplexität zu reduzieren.
Einfache Bereitstellung
Diese Architektur veranschaulicht eine grundlegende Bereitstellung von Remotedesktopdiensten in Azure, die Remotezugriff auf Desktops und Anwendungen über eine einzelne Azure-Region ermöglicht. Die Bereitstellung verwendet einen externen Load Balancer, um eingehende Verbindungen aus dem öffentlichen Internet über die RDS-Infrastruktur zu verteilen.
Die wichtigsten RDS-Rollen werden auf mehrere virtuelle Computer innerhalb einer einzelnen Ressourcengruppe verteilt. Der RD Connection Broker (RDCB) und RD Licensing Server (RDLS) teilen einen virtuellen Computer, während die RDGW-Komponenten (RDGW) und RD Web Access (RDWeb) auf einer separaten VM bereitgestellt werden. Die unterstützende Infrastruktur umfasst einen Active Directory-Domänencontroller und einen Dateiserver für Benutzerprofildatenträger und freigegebenen Speicher. Der RD Session Host (RDSH)-Server, der auf einer eigenen virtuellen Maschine bereitgestellt wird, stellt die eigentlichen Desktop-Sitzungen und gehosteten Anwendungen für die Endbenutzer bereit.
Alle virtuellen Computer kommunizieren über ein virtuelles Azure-Netzwerk, das sichere Netzwerkkonnektivität zwischen den RDS-Komponenten bereitstellt, während die Bereitstellung von anderen Azure-Ressourcen getrennt wird. Diese Architektur bietet einen kostengünstigen Ausgangspunkt für Organisationen, die ihr Desktophosting nach Azure migrieren möchten, mit der Flexibilität, einzelne Komponenten zu skalieren, während die Nutzung wächst.
Hoch verfügbare Bereitstellung
Diese Architektur veranschaulicht eine Bereitstellung von Remotedesktopdiensten, die Azure Platform as a Service (PaaS)-Angebote integriert, um die Skalierbarkeit zu verbessern und den Verwaltungsaufwand zu verringern. Der Hauptunterschied zu einer grundlegenden RDS-Bereitstellung besteht darin, einen herkömmlichen virtuellen SQL Server-Computer durch Azure SQL-Datenbank zum Speichern von RDS-Konfigurations- und Benutzersitzungsdaten zu ersetzen.
Die RDS-Rollen behalten das gleiche Verteilungsmuster bei, jedoch mit mehreren Instanzen von jeder; der RD Connection Broker (RDCB) und der RD Licensing Server (RDLS) teilen sich eine Gruppe von virtuellen Maschinen, während die Komponenten RD Gateway (RDGW) und RD Web Access (RDWeb) auf einer separaten Gruppe von VMs bereitgestellt werden. Die RD Session Hosts (RDSH) stellen weiterhin Desktop-Sitzungen und Anwendungen von ihren dedizierten virtuellen Maschinen aus bereit. Die unterstützende Infrastruktur umfasst einen Active Directory-Domänencontroller und einen Dateiserver für Benutzerprofile und freigegebenen Speicher.
Durch Die Verwendung der Azure SQL-Datenbank anstelle einer selbstverwalteten SQL Server-Instanz bietet diese Architektur integrierte Hochverfügbarkeit, automatische Sicherungen und vereinfachte Datenbankverwaltung. Die Azure SQL-Datenbank behandelt die RDS-Verbindungsbroker-Datenbankanforderungen, ohne dass ein separater Datenbankserver verwaltet, gepatcht und überwacht werden muss. Dieser Hybridansatz kombiniert die Flexibilität von Infrastructure as a Service (IaaS) für die RDS-Rollen mit den verwalteten Vorteilen von PaaS für die Datenbankebene, was zu einer reduzierten Betriebskomplexität und einer verbesserten Zuverlässigkeit führt.
RDS-Architekturen mit eindeutigen Azure-PaaS-Rollen
Die Standardarchitekturen für die RDS-Bereitstellung sind zwar für die meisten Szenarien geeignet, Azure investiert jedoch weiter in PaaS-Erstanbieterlösungen, um den Nutzen für Kunden noch weiter zu erhöhen. Die folgenden Architekturen zeigen, wie sie in RDS integriert werden.
RDS-Bereitstellung mit Microsoft Entra Domain Services
Die beiden Standardarchitekturdiagramme basieren auf einem herkömmlichen Active Directory (AD), das auf einer Windows Server-VM bereitgestellt wird. Wenn Sie jedoch nicht über einen herkömmlichen AD verfügen und nur über einen Microsoft Entra-Mandanten verfügen, z. B. über Dienste wie Microsoft 365, aber dennoch RDS verwenden möchten, können Sie Microsoft Entra Domain Services verwenden, um eine vollständig verwaltete Domäne in Ihrer Azure IaaS-Umgebung zu erstellen, die dieselben Benutzer verwendet, die in Ihrem Microsoft Entra-Mandanten vorhanden sind. Mit dieser Option wird die Komplexität der manuellen Synchronisierung von Benutzern und das Verwalten weiterer virtueller Computer entfernt. Microsoft Entra Domain Services können sowohl in einer einfachen als auch in einer hoch verfügbaren Bereitstellung verwendet werden.
RDS-Bereitstellung mit einem Microsoft Entra-Anwendungsproxy
Die beiden Standardarchitekturdiagramme verwenden die RD-Web-/Gatewayserver als internetgerichteten Einstiegspunkt in das RDS-System. Für einige Umgebungen würden Administratoren lieber ihre eigenen Server aus dem Umkreis entfernen und stattdessen Technologien verwenden, die auch zusätzliche Sicherheit durch Reverseproxytechnologien bieten. Die PaaS-Rolle Microsoft Entra-Anwendungsproxy ist für ein solches Szenario wie geschaffen.
Unterstützte Konfigurationen und anleitungen zum Erstellen dieses Setups finden Sie unter Veröffentlichen von Remotedesktop mit dem Microsoft Entra-Anwendungsproxy.