First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellungen

Auf dieser Dokumentationsseite werden die wichtigsten Merkmale von First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellungen vorgestellt. Diese Bereitstellungen werden auch als Horizon Cloud-Pods bezeichnet.

Wichtig: Diese Informationen gelten nur, wenn Sie auf eine First-Gen-Mandantenumgebung in der First-Gen-Steuerungsebene zugreifen können. Wie im KB-Artikel 92424 beschrieben, hat die First-Gen-Steuerungsebene das Ende der Verfügbarkeit (End of Availability, EOA) erreicht. Weitere Informationen finden Sie in diesem Artikel.

Kurze Einführung

Horizon Cloud-Pods basieren auf der Horizon Cloud-Pod-Manager-Technologie. Diese Pod-Manager-Technologie wird ausschließlich in einem Microsoft Azure-Abonnement ausgeführt und erfordert kein VMware SDDC.

Die Horizon Cloud on Microsoft Azure-Bereitstellung unterscheidet sich von anderen Horizon-Bereitstellungstypen, die Horizon Connection Server-Softwarekomponenten umfassen.

Siehe auch:

Horizon Service-Bereitstellungen und Onboarding von Pods für eine allgemeine Einführung in die Vorgehensweise bei der Neuerstellung Ihres Mandantenkontos, die Tag-0-Aufgaben vor der Bereitstellung Ihres ersten Pods und die Tag-1-Aufgaben beim Onboarding des Pods.
Eine Illustration einer vereinfachten Proof-of-Concept-First-Gen-Bereitstellung.

Bereitstellungen

Stellen Sie First-Gen-Horizon Cloud on Microsoft Azure bereit, indem Sie einen Pod-Manager-basierten Pod mithilfe des automatisierten Pod-Bereitstellungsassistenten bereitstellen. Sie müssen über ein Abonnement für Cloud-Kapazität in Microsoft Azure verfügen und diese Abonnementinformationen dann verwenden, um diese Cloud-Kapazität mit Ihrem Horizon Cloud-Mandanten zu koppeln.

Der Assistent stellt die erforderlichen VMware-Softwarekomponenten in Ihrem Microsoft Azure-Cloud-Abonnement bereit und erstellt die Bereitstellung.

Die bereitgestellte VMware-Software erstellt eine entsprechend konfigurierte Einheit, einen so genannten Pod, der mit der Steuerungsebene gekoppelt wird.

Nachdem der Pod bereitgestellt wurde, verwenden Sie die Steuerungsebene, um VDI-Desktops und RDSHs bereitzustellen und Ihren Endbenutzern Zugriff auf Desktops und Remoteanwendungen zu gewähren.

Der von Horizon Cloud in Microsoft Azure bereitgestellte Pod verfügt über einen physischen regionalen Standort in einer Microsoft Azure-Cloud. Im Pod-Bereitstellungsassistenten legen Sie fest, wo der Pod platziert werden soll, gemäß den für Ihr Microsoft Azure-Abonnement verfügbaren Regionen. Sie wählen auch ein vorhandenes virtuelles Netzwerk (VNet) aus, das der Pod in Ihrer ausgewählten Region nutzt. Sie haben die Möglichkeit, eine externe Gateway-Konfiguration mit dem Pod bereitzustellen, wobei die Ressourcen dieses externen Gateways entweder in demselben VNet wie der Pod bereitgestellt werden oder in einem eigenen VNet, das mit dem VNet des Pods als Peer verbunden ist.

Hinweis: Sie konfigurieren Ihre Microsoft Azure-Umgebung mit dem VNet des Pods (und mit dem VNet des externen Gateways, sofern Sie diese Konfigurationsoption verwenden). Sie können entweder im Voraus die Subnetze erstellen, die vom Pod und von der Konfiguration des externen Gateways benötigt werden, oder die Subnetze während der Bereitstellung vom Pod-Bereitsteller erstellen lassen. Wenn Sie die Subnetze nicht vorab erstellen, erstellt der Pod-Bereitsteller die Subnetze bei der Bereitstellung der erforderlichen VMs und Ressourcen in Ihrer Umgebung. Wenn Sie festlegen, dass der Pod-Bereitsteller die erforderlichen Subnetze erstellt, müssen Sie wissen, welche IP-Adressbereiche Sie für die Subnetze des Pods verwenden möchten, bevor Sie den Bereitstellungsassistenten starten. Wenn Sie die Subnetze im Voraus erstellen, müssen Sie sicherstellen, dass Sie bestimmte Anforderungen erfüllen, bevor Sie den Bereitstellungsvorgang starten. Weitere Informationen zu den Anforderungen beim Erstellen der Subnetze im Voraus finden Sie unter First-Gen-Mandanten – Erstellen Sie im Vorfeld der Pod-Bereitstellung die erforderlichen Subnetze des Horizon Cloud-Pods in Ihrem VNet in Microsoft Azure. und First-Gen-Mandanten – Verwendung vorhandener Subnetze für einen Horizon Cloud-Pod in Microsoft Azure.

Sie können mehrere Pods in Microsoft Azure bereitstellen und sie alle mit derselben Verwaltungskonsole verwalten. Die Pods, die Sie nach dem ersten Pod bereitstellen, können dasselbe VNet wie der erste Pod oder andere VNets verwenden. Außerdem kann sich jeder Pod in einer anderen Microsoft Azure-Region befinden, wobei in jeder Region ein VNet verwendet wird.

Wichtig: Dieser Pod in Microsoft Azure ist kein Mandant. Dieser Pod hat nicht genau die gleichen Merkmale, die einen Mandanten ausmachen und die Sie von einem Mandanten erwarten würden. Obwohl ein Mandant beispielsweise eine Eins-zu-Eins-Zuordnung zu einer Active Directory-Domäne hat und von anderen Mandanten isoliert ist, müssen alle Horizon Cloud-Pods in Microsoft Azure, die mit demselben Horizon Cloud-Kundenkonto-Datensatz bereitgestellt werden, in der Lage sein, dieselben Active Directory-Server zu erreichen, und die DNS-Konfiguration muss alle diese Active Directory-Domänen auflösen.

Für die Mandantenfähigkeit würden Sie mehrere Horizon Cloud-Kundenkonto-Datensätze einrichten. Der Horizon Cloud-Kundenkonto-Datensatz, der erstellt wird, wenn Sie sich bei VMware für die Nutzung von Horizon Cloud Service registrieren, und der mit Ihren VMware Customer Connect-Anmeldedaten verknüpft ist, verhält sich eher wie ein Mandant. Ein Horizon Cloud-Kundenkonto-Datensatz ist von anderen Horizon Cloud-Kundenkonto-Datensätzen isoliert. Ein einzelner Kundenkonto-Datensatz wird mehreren Pods zugeordnet und wenn sich jemand mit einem der mit diesem Kundenkonto-Datensatz verknüpften Anmeldeinformationen bei der Verwaltungskonsole anmeldet, zeigt die Konsole alle Pods an, die diesem Kundenkonto-Datensatz zugeordnet sind.

Der Pod-Bereitstellungsvorgang erstellt automatisch einen Satz von Ressourcengruppen in Ihrer Microsoft Azure-Kapazität. Ressourcengruppen werden verwendet, um die Ressourcen zu organisieren, die die Umgebung benötigt und erstellt, wie z. B.:

VMs für die Pod-Manager-Instanzen.
VMs für die Unified Access Gateway-Instanzen und ihre Lastausgleichsdienste
VM für die Connector-VM in der Konfiguration des externen Gateways, wenn Sie diese Konfiguration in einem vom VNet des Pods verschiedenen VNet bereitstellen
VMs für die RDSH-fähigen Golden Images
VMs für die VDI-Desktop-Golden Images
VMs für die zuweisbaren (veröffentlichten, versiegelten) Images, die aus den Golden Images erstellt werden
VMs für die RDSH-Farmen, die die RDSH-Desktops und Remoteanwendungen bereitstellen
VMs für die VDI-Desktops
Zusätzliche Assets, die die VMs und die Umgebung für unterstützte Vorgänge benötigen, wie Netzwerkschnittstellen, IP-Adressen, Festplatten, Schlüsseltresore, Microsoft Azure-Datenbank für PostgreSQL-Serverressource und verschiedene ähnliche Elemente. Der Pod-Bereitstellungsvorgang kann die erforderlichen virtuellen Subnetze auch mit den von Ihnen im Bereitstellungsassistenten angegebenen Werten erstellen.

Das folgende Diagramm veranschaulicht einen bereitgestellten Pod, der für Hochverfügbarkeit aktiviert ist, für den sowohl externe als auch interne Gateway-Typen konfiguriert sind und bei dem sich das externe Gateway in demselben VNet befindet wie der Pod. In diesem Diagramm steht RG für Ressourcengruppe.

Die Unified Access Gateway-Instanzen in der externen Gateway-Konfiguration verfügen über Netzwerkkarten im demilitarisierten Netzwerk (DMZ-Netzwerk). Mit der Konfiguration eines externen Gateways können Endbenutzer, die sich außerhalb Ihres Unternehmensnetzwerks im Internet befinden, über diese Konfiguration auf ihre vom Pod bereitgestellten virtuellen Desktops und Anwendungen zugreifen. Mit der Konfiguration eines internen Gateways können Endbenutzer, die sich innerhalb Ihres Unternehmensnetzwerks im Intranet befinden, über dieses Gateway vertrauenswürdige Verbindungen zu den vom Pod bereitgestellten virtuellen Desktops und Anwendungen herstellen.

Der Pod-Bereitsteller bietet die Option, den Pod mit beiden Konfigurationen im Voraus bereitzustellen. Alternativ können Sie den Pod mit nur einer oder völlig ohne Gateway-Konfiguration bereitstellen und den bereitgestellten Pod bearbeiten, um die nicht ausgewählte Gateway-Konfiguration später hinzuzufügen. Sie können den Pod auch anfänglich ohne einen der beiden Typen bereitstellen und später hinzufügen.

Das System stellt den Pod mit Hochverfügbarkeit bereit, wobei standardmäßig zwei Pod-Manager-VMs vorhanden sind.

Darstellung der Architektur der Ressourcengruppen, VMs und Subnetze für einen Pod, bei dem beide Arten von Unified Access Gateway-Konfigurationen aktiviert sind und bei dem sich das externe Gateway in demselben VNet befindet wie der Pod. — Abbildung 1. Abbildung der Horizon-Cloud-Pod-Architektur, bei der der Pod sowohl über externe als auch über interne Gateway-Konfigurationen verfügt, wobei das externe Gateways in demselben VNet bereitgestellt wird wie der Pod, drei Netzwerkkarten auf den externen Gateway-VMs, zwei Netzwerkkarten auf den internen Gateway-VMs und eine öffentliche IP-Adresse, die für den Lastausgleichsdienst des externen Gateways aktiviert ist

Das folgende Diagramm veranschaulicht die Ressourcen, die bereitgestellt werden, wenn Sie die Option auswählen, bei der sich das externe Gateway in einem eigenen, vom VNet des Pods getrennten VNet befindet. Die beiden VNets müssen als Peers miteinander verbunden sein. Dieses Diagramm gilt auch, wenn Sie die Option auswählen, bei der die Ressourcen des externen Gateways mit einem Microsoft Azure-Abonnement bereitgestellt werden, das sich von dem für den Pod verwendeten Abonnement unterscheidet. Da VNets immer an ein bestimmtes Abonnement gebunden sind, ist Bereitstellung des externen Gateways in einem eigenen Abonnement ein Sonderfall der Bereitstellung des externen Gateways in einem eigenen VNet.

Tipp: Durch die Bereitstellung der Konfiguration des externen Gateways in einem eigenen VNet haben Sie die Möglichkeit, diese Horizon Cloud-Pods in komplexen Microsoft Azure-Umgebungen bereitzustellen, die eine Hub-Spoke-Netzwerktopologie in Microsoft Azure verwenden.

Architekturdarstellung der Elemente eines externen Gateways, wenn das externe Gateway in seinem eigenen VNet eingesetzt wird. In diesem Fall gibt es eine Connector-VM mit einer Netzwerkkarte zum VNet-Management-Subnetz, zusammen mit den Standardelementen für das externe Gateway selbst. — Abbildung 2. Veranschaulichung der Elemente der Architektur des externen Gateways, wenn das externe Gateway in einem eigenen, vom VNet des Pods getrennten VNet bereitgestellt wird

Microsoft Azure-Terminologie und Referenzen

Die VMware Horizon Cloud Service on Microsoft Azure-Produktdokumentation verwendet die entsprechende Microsoft Azure-Terminologie in den Beschreibungen und Aufgabenschritten der VMware Horizon Cloud Service on Microsoft Azure-Abläufe. Wenn Ihnen die Microsoft Azure-Terminologie nicht geläufig ist, können Sie in den folgenden Referenzen in der Microsoft Azure-Produktdokumentation mehr erfahren.

Hinweis: Die Groß-/Kleinschreibung und Rechtschreibung in der folgenden Liste entspricht der Groß-/Kleinschreibung und Schreibweise in den verknüpften Artikeln der Microsoft Azure-Dokumentation.

Nützliche Microsoft Azure-Referenzen	Beschreibung
Microsoft Azure-Glossar: Ein Wörterbuch der Cloudterminologie auf der Azure Plattform	Dieses Glossar enthält Definitionen der Begriffe, die im Zusammenhang mit der Microsoft Azure-Cloud verwendet werden, z. B. Lastausgleich, Region, Ressourcengruppe, Abonnement, virtueller Computer und virtuelles Netzwerk (Vnet). Hinweis: Das Microsoft Azure-Glossar enthält nicht den Begriff „Dienstprinzipal“, da der Dienstprinzipal eine Ressource ist, die automatisch in Microsoft Azure erstellt wird, wenn eine Anwendungsregistrierung in Microsoft Azure erstellt wird. Der Grund, warum Sie eine Anwendungsregistrierung in Ihrem Microsoft Azure-Abonnement erstellen, ist die Art und Weise, wie Sie Horizon Cloud als Anwendung autorisieren, Ihre Microsoft Azure-Kapazität zu nutzen. Die Anwendungsregistrierung und der zugehörige Dienstprinzipal ermöglichen, dass der Horizon Cloud-Clouddienst als Anwendung auf Ressourcen in Ihrem Microsoft Azure-Abonnement zugreifen kann. Verwenden Sie die nächste Referenz, um mehr über Anwendungen und Dienstprinzipale mit Zugriff auf Ressourcen in Microsoft Azure zu erfahren.
Erstellen einer Azure Active Directory-Anwendung und eines Dienstprinzipals mit Ressourcenzugriff mithilfe des Portals	In diesem Artikel erfahren Sie mehr über die Beziehung zwischen einer Anwendung und einem Dienstprinzipal in einer Microsoft Azure-Cloud.
Übersicht über den Azure-Ressourcen-Manager	In diesem Artikel erfahren Sie mehr über die Beziehungen zwischen Ressourcen, Ressourcengruppen und Ressourcenmanager in Microsoft Azure.
Virtuelles Azure-Netzwerk	In diesem Artikel finden Sie Informationen zum Dienst für das virtuelle Azure-Netzwerk (VNet) in Microsoft Azure. Siehe auch Azure Virtual Network – häufig gestellte Fragen.
Peering in virtuellen Netzwerken	In diesem Artikel finden Sie Informationen zum Peering virtueller Netzwerke in Microsoft Azure.
Hub-Spoke-Netzwerktopologie in Azure	In diesem Artikel finden Sie Informationen zur Hub-Spoke-Netzwerktopologie in Microsoft Azure.
Übersicht über Microsoft Azure ExpressRoute	In diesem Artikel finden Sie Informationen zu Microsoft Azure ExpressRoute sowie zur Verwendung der Lösung für den Aufbau von Verbindungen zwischen Ihren lokalen Netzwerken, Microsoft Azure und Ihren Horizon Cloud-Pods.
Info zu VPN-Gateway Planung und Design für VPN-Gateway Erstellen einer Site-To-Site-Verbindung im Azure-Portal	In diesem Artikel finden Sie Informationen zur Konfiguration von VPNs in Microsoft Azure.
Was ist Azure Lastausgleich?	In diesem Artikel erfahren Sie mehr über die Azure-Lastausgleich, die für einen Pod bereitgestellt werden: den Lastausgleich für die Pod Manager-VMs und die Lastausgleich für die Gateway-Konfigurationen.
Was ist die Azure-Datenbank für PostgreSQL?	In diesem Artikel erfahren Sie mehr über die Microsoft Azure-Datenbank für den PostgreSQL-Dienst.
Was ist Azure Virtual Desktop?	In diesem Artikel erfahren Sie mehr über Microsoft Azure Virtual Desktop und über den Zusammenhang mit Microsoft Windows 10 Enterprise für Mehrfachsitzungen und Microsoft Windows 7 Enterprise erweiterten Sicherheitsupdates. Wenn Ihr Horizon Cloud-Mandantenkonto über die Konfiguration für Horizon Cloud Service on Microsoft Azure zur Erweiterung von Microsoft Azure Virtual Desktop verfügt, wird die Verwendung von Microsoft Windows 10 Enterprise für Mehrfachsitzungen und Microsoft Windows 7 Enterprise mit den in Microsoft Azure bereitgestellten Pods unterstützt.

Zusätzliche VMware-Ressourcen

Die folgenden Ressourcen liefern detaillierte technische Details über den Service.

Zusätzliche technische Ressourcen von VMware	Beschreibung
Anforderungs-Checkliste – First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellungen	Diese Liste bietet Informationen über die Assets, die Sie im Vorfeld des Pod-Bereitstellungsprozesses ermitteln und konfigurieren müssen.
Tech Zone – Netzwerkdesign – Horizon Cloud on Microsoft Azure – First-Gen-Architektur	Dieser Abschnitt zum Netzwerkdesign in der VMware Digital Workspace Tech Zone, Horizon Cloud on Microsoft Azure –First-Gen-Architektur, beschreibt das Netzwerkdesign für diese First-Gen-Bereitstellungen.
Horizon Cloud Service on Microsoft Azure – Sicherheitserwägungen	Verwenden Sie diesen Artikel, um Informationen über die Sicherheitsdetails der Umgebung und die Art der gespeicherten Daten zu erhalten.
Tech Zone – Energieverwaltung in VMware Horizon Cloud on Azure	In diesem Artikel erfahren Sie mehr über die Funktionen, mit denen Sie Ihre Desktops und Remoteanwendungen richtig dimensionieren und Ihre Workloads für die First-Gen-Horizon Cloud on Microsoft Azure-Bereitstellungen effizient verwalten können.