Ihre Horizon Cloud on Microsoft Azure-Bereitstellungen

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 Horizon Cloud zu koppeln. Sie verwenden die Horizon Universal Console, um die Bereitstellung in diesem Abonnement zu sichern und Golden Images zu erstellen. Von diesen Images aus stellen Sie Remoteanwendungen sowie Einzelsitzungs- und Mehrfachsitzungs-Desktops für Ihre Endbenutzer für den sicheren Zugriff von jedem Gerät aus bereit.

Die Bereitstellung erstellt einen so genannten Horizon Cloud-Pod. Die Remoteanwendungen und Einzelsitzungs- und Mehrfachsitzungs-Desktops werden von diesem Pod mithilfe der Kapazität in Ihrem Microsoft Azure-Abonnement bereitgestellt. Sie wählen den Speicherort für die Desktops und Anwendungen basierend auf dem Speicherort des bereitgestellten Pods aus.

Eine allgemeine Einführung in Horizon Cloud finden Sie unter First-Gen-Mandanten – Grundlegende Horizon-Mandantenkonzepte. Informationen zum vorgeschlagenen Workflow der Aktivitäten für Ihre erste Horizon Cloud-Pod-Bereitstellung finden Sie unter Horizon Cloud Pod – Onboarding des ersten Pods – Allgemeiner Workflow.

Der bereitgestellte Horizon Cloud-Pod

Der von Horizon Cloud in Microsoft Azure bereitgestellte Pod verfügt über einen physischen regionalen Speicherort in einer Microsoft Azure-Cloud. Im Pod-Bereitstellungsassistenten wählen Sie aus, wo der Pod platziert werden soll, entsprechend den für Ihr Microsoft Azure-Abonnement verfügbaren Regionen. Sie können auch ein vorhandenes virtuelles Netzwerk (VNet) auswählen, das der Pod in Ihrer ausgewählten Region verwendet. 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 oder in einem separaten VNet bereitgestellt werden, das mit dem VNet des Pods als Peer verbunden ist.

Hinweis: Sie konfigurieren Ihre Microsoft Azure-Umgebung mit dem Pod-VNet (und mit dem VNet des externen Gateways, wenn Sie diese Konfigurationsoption verwenden). Sie können entweder im Voraus die Subnetze erstellen, die für die Konfiguration des Pods und des externen Gateways erforderlich sind, oder die Subnetze während der Bereitstellung durch den Pod-Bereitsteller erstellen lassen. Wenn Sie die Subnetze nicht vorab erstellen, erstellt der Pod-Bereitsteller die Subnetze während 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 vor der Pod-Bereitstellung die erforderlichen Subnetze des Horizon Cloud-Pods in Ihrem VNet in Microsoft Azure und First-Gen-Mandanten – Bei Verwendung vorhandener Subnetze für einen Horizon Cloud-Pod in Microsoft Azure.

Wichtig: Dieser Pod in Microsoft Azure ist kein Mandant. Dieser Pod hat nicht genau die gleichen Merkmale, die einen Mandanten definieren 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-Kundenkontodatensatz 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 Mehrmandantenfähigkeit richten Sie mehrere Horizon Cloud-Kundenkontodatensätze ein. Der Horizon Cloud-Kundenkontodatensatz, der erstellt wird, wenn Sie sich für Horizon Cloud anmelden, und der mit Ihren Customer Connect-Anmeldedaten verknüpft ist, verhält sich eher wie ein Mandant. Ein Horizon Cloud-Kundenkontodatensatz ist von anderen Horizon Cloud-Kundenkontodatensä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-Bereitstellungsprozess erstellt automatisch eine Reihe von Ressourcengruppen in Ihrer Microsoft Azure-Kapazität. Ressourcengruppen werden verwendet, um die Assets 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 getrennten 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-Bereitstellungsprozess kann die erforderlichen virtuellen Subnetze auch mit den von Ihnen im Bereitstellungsassistenten angegebenen Werten erstellen.

Alle Ressourcengruppen, die von Horizon Cloud in Ihrer Microsoft Azure-Umgebung erstellt wurden, haben Namen, die das Muster hcs-enthalten.

VORSICHT:

Ändern oder löschen Sie die Pod-bezogenen Ressourcen nicht manuell über das Microsoft Azure-Portal, außer in folgenden Fällen:

• Manuelle Erstellung von Golden Images.
• Anpassung der Netzwerksicherheitsgruppen für Farmen und VDI-Desktop-Zuweisungen zur Konfiguration von Ports für Ihre geschäftlichen Gegebenheiten.

Erstellen Sie keine zusätzlichen Ressourcen manuell innerhalb von Horizon-verwalteten Ressourcengruppen, einschließlich Pod- und Unified Access Gateway-Ressourcengruppen.

• Löschen Sie die benutzerdefinierten Ressourcen in Pod- oder Unified Access Gateway-Ressourcengruppen, bevor der Wartungsplan für das Pod-Upgrade erstellt wird.

Horizon Cloud konfiguriert automatisch die Pod-bezogenen Ressourcen, um sicherzustellen, dass der Pod wie geplant funktioniert. Ändern Sie die Einstellungen für die Ressourcen, die Horizon Cloud während Workflows automatisch erstellt und bereitstellt, nie manuell, einschließlich zugewiesener IP-Adressen oder Namen usw. Schalten Sie VM-Instanzen niemals manuell aus oder löschen Sie sie direkt über das Microsoft Azure-Portal. Löschen Sie die Manager-VM oder Unified Access Gateway-VMs nie manuell. Löschen Sie Netzwerkkarten nie manuell aus den Ressourcengruppen, insbesondere nicht aus den Unified Access Gateway-Ressourcengruppen. Wenn Sie die generierten Einstellungen ändern, VMs manuell ausschalten oder VMs bzw. Netzwerkkarten manuell löschen, die über den Pod-Bereitsteller erstellt wurden, können unvorhersehbare Ergebnisse auftreten und Pod-Vorgänge, Pod-Aktualisierungen und Pod-Löschvorgänge können fehlschlagen.

Das folgende Diagramm veranschaulicht einen bereitgestellten Pod, der sowohl über externe als auch interne Gateway-Konfigurationen verfügt und bei dem sich das externe Gateway in demselben VNet befindet wie der Pod. In diesem Diagramm RG steht für Ressourcengruppe.

Die Unified Access Gateway-Instanzen in der externen Gateway-Konfiguration verfügen über Netzwerkkarten im demilitarisierten Netzwerk (DMZ-Netzwerk). Mit einer externen Gateway-Konfiguration 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 einer internen Gateway-Konfiguration 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 gar keiner 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.

Das folgende Diagramm veranschaulicht die Ressourcen, die bereitgestellt werden, wenn Sie die Option auswählen, dass 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 mithilfe eines Microsoft Azure-Abonnements bereitgestellt werden, das sich von dem für den Pod verwendeten Abonnement unterscheidet. Da VNets nicht abonnementübergreifend sind, ist die Bereitstellung des externen Gateways in einem eigenen Abonnement eine Teilmenge der Bereitstellung des externen Gateways in einem eigenen VNet.

Tipp: Durch die Bereitstellung der externen Gateway-Konfiguration 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.

Abonnements und Anzahl der Pods

Legen Sie die Anzahl der in einem einzelnen Abonnement bereitgestellten Pods sorgfältig fest, vor allem dann, wenn jeder Pod in einem großen Umfang ausgeführt werden soll. Auch wenn in einem einzelnen Microsoft Azure-Abonnement mehrere Pods bereitgestellt werden können, sei es in einer Region oder über mehrere Regionen verteilt, gelten für Microsoft Azure bestimmte Grenzwerte für ein einzelnes Abonnement. Aufgrund dieser Microsoft Azure-Grenzwerte erhöht eine große Anzahl von Pods in einem einzelnen Abonnement die Wahrscheinlichkeit, dass diese Grenzwerte erreicht werden. Zum Erreichen dieser Grenzwerte tragen eine Vielzahl von Variablen und Kombinationen dieser Variablen bei, wie z. B. die Anzahl Pods, die Anzahl Farmen und Zuweisungen innerhalb jedes Pods, die Anzahl Farm-RDSH-VMs in jedem Pod, die Anzahl Desktops in jeder Zuweisung usw.

Wenn Pods in einem großen Umfang ausgeführt werden sollen, sollten Sie mehrere Abonnements unter einem Microsoft Azure-Konto verwenden. Microsoft Azure-Kunden verwenden diesen Ansatz und bevorzugen ihn oft, da er einige Vorteile für die fortlaufende Verwaltung der Abonnements bietet. Bei diesem Ansatz würden Sie einen einzelnen Pod pro Abonnement bereitstellen, diese Abonnements in einem einzelnen primären Konto zusammenfassen und die Wahrscheinlichkeit vermeiden, dass die Microsoft Azure-Grenzwerte für ein einzelnes Abonnement erreicht werden.

Wenn Sie über vorhandene Pods verfügen, die vor dieser aktuellen Horizon Cloud-Version bereitgestellt wurden

Wie in Horizon Cloud Pods – Wartung und Updates beschrieben, aktualisieren wir die Horizon Cloud-Softwarekomponenten regelmäßig, um neue Funktionen und Fehlerbehebungen einzubinden. Die Verwaltungsumgebung in der Cloud wird wöchentlich aktualisiert, und die Binärdateien, die die Grundlage der Pod-Softwarekomponenten bilden, werden in der Regel ungefähr vierteljährlich aktualisiert. Die First-Gen-Horizon Cloud-Dokumentationsseite bietet Zugriff auf die Seite "Versionshinweise", auf der Listen mit den Neuigkeiten für jeden Kalenderzeitpunkt bereitgestellt werden, an dem substanzielle, für Kunden sichtbare Funktionen eingeführt werden.

Wenn Sie einen neuen Pod bereitstellen, wird dieser Pod immer in der Manifestversion erstellt, die die neueste für die aktuelle in der Entwicklung befindliche Dienstumgebung ist. Wenn Sie beispielsweise im August 2019 einen neuen Pod erstellt haben, wurde dieser Pod mit Softwarekomponenten bereitgestellt, die für Horizon Cloud ab diesem Datum aktuell waren. Je nachdem, wie lange Sie Ihre Horizon Cloud-Umgebung verwendet haben, kann Ihre gesamte Horizon Cloud-Umgebung an einem bestimmten Kalenderdatum einige Pods enthalten, die sich auf der neuesten veröffentlichten Version befinden, und einige, die sich in einer früheren Version befinden, die noch nicht auf das neueste Manifest aktualisiert wurden.

Wichtig: Im Allgemeinen werden im Inhalt dieses Administratorhandbuchs Funktionen, Workflows und Verhaltensweisen beschrieben, die in der aktuell in der Entwicklung befindlichen Version verfügbar sind und die anwendbar sind, wenn sich Ihr Pod auf der neuesten Pod-Manifestversion befindet, die in dieser aktuellen Version zur Verfügung gestellt wurde. Die cloudbasierte Konsole, in der Sie Verwaltungs- und Verwaltungsaufgaben ausführen, ist dynamisch. Die webbasierte Schnittstelle der Konsole zeigt in der Regel Meldungen an, wenn für einen Bereich oder eine Aktion in der Konsole ein Upgrade des Pods erforderlich ist, um diese Funktion verwenden zu können. Für einen Pod, der vor dieser Version vorhanden war, sind für einige Workflows möglicherweise andere Schritte erforderlich als in diesem Administratorhandbuch beschrieben. Eine Liste der Workflows in dieser Version, die sich jetzt für Pods mit der neuesten Manifestversion unterscheiden, finden Sie ggf. im Dokumentationsthema Für aktuelle Kunden mit vorhandenen cloudverbundenen Pods – Informationen zu Horizon Cloud-Versionen und den darin enthaltenen Abschnitten.

Microsoft Azure-Terminologie und Referenzen

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

Hinweis: Die Groß-/Kleinschreibung und Rechtschreibung in den folgenden Zitaten entspricht der Groß-/Kleinschreibung und Rechtschreibung, die in den verknüpften Artikeln in der Microsoft Azure-Dokumentation selbst zu finden ist.

Nützliche Microsoft Azure-Referenzen	Beschreibung
Microsoft Azure-Glossar: Ein Wörterbuch der Cloudterminologie auf der Azure-Plattform	In diesem Glossar erfahren Sie mehr über die Bedeutung der Begriffe, die im Kontext der Microsoft Azure-Cloud verwendet werden, z. B. Lastausgleichsdienst, Region, Ressourcengruppe, Abonnement, virtuelle Maschine 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 verwenden. Die Anwendungsregistrierung und der zugehörige Dienstprinzipal ermöglichen, dass der Horizon Cloud Cloud Service als Anwendung auf Ressourcen in Ihrem Microsoft Azure-Abonnement zugreifen kann. Verwenden Sie die nächste Referenz unten, um mehr über Anwendungen und Dienstprinzipale zu erfahren, die auf Ressourcen in Microsoft Azure zugreifen können.
Verwenden des Portals zum Erstellen einer Azure Active Directory-Anwendung und eines Dienstprinzipals, der auf Ressourcen zugreifen kann	In diesem Artikel erfahren Sie mehr über die Beziehung zwischen einer Anwendung und einem Dienstprinzipal in einer Microsoft Azure-Cloud.
Übersicht über Azure Resource Manager	In diesem Artikel erfahren Sie mehr über die Beziehungen zwischen Ressourcen, Ressourcengruppen und dem Ressourcenmanager in Microsoft Azure.
Azure-VNet	In diesem Artikel erfahren Sie mehr über den Dienst "Azure Virtual Network" (VNet) in Microsoft Azure. Weitere Informationen finden Sie auch in den häufig gestellten Fragen zu Azure Virtual Network.
Azure VNet Peering	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 erfahren Sie mehr über Microsoft Azure ExpressRoute und wie Sie damit Verbindungen zwischen Ihren lokalen Netzwerken, Microsoft Azure und Ihren Horizon Cloud-Pods herstellen können.
Informationen zu VPN-Gateway Planung und Design für VPN-Gateway Erstellen einer Site-To-Site-Verbindung im Azure-Portal	In diesen Artikeln erfahren Sie, wie Sie VPNs in Microsoft Azure konfigurieren.
Was ist der Azure-Lastausgleich?	In diesem Artikel erfahren Sie mehr über die Azure-Lastausgleichsdienste, die für einen Pod bereitgestellt werden: den Lastausgleichsdienst für die Pod-Manager-VMs und die Lastausgleichsdienste für die Gateway-Konfigurationen.
Was ist eine Azure-Datenbank für PostgreSQL?	In diesem Artikel finden Sie Informationen zur 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 mit erweiterten Sicherheitsupdates. Wenn Ihr Horizon Cloud-Mandantenkonto über die Konfiguration für Horizon Cloud on Microsoft Azure verfügt, die Microsoft Azure Virtual Desktop erweitert, wird die Verwendung von Microsoft Windows 10 Enterprise für Mehrfachsitzungen und Microsoft Windows 7 Enterprise mit Ihren in Microsoft Azure bereitgestellten Pods unterstützt.