Pod-Bereitstellung, Bereitstellungen der Konfigurationen des Pod-Gateways und Standardvorgänge erfordern bestimmte Arten und Größen von virtuellen Maschinen (VMs) in Ihrer Microsoft Azure-Cloudkapazität. Ihr Abonnement muss die entsprechenden Kontingente und die erforderliche Konfiguration aufweisen, um diese VMs zu unterstützen. Wenn Sie die Option zum Bereitstellen des externen Gateways des Pods in einem eigenen Abonnement verwenden, benötigt dieses Abonnement das Kontingent und die Konfiguration, um die Konfiguration des externen Gateways zu unterstützen.
In den nachfolgenden Tabellen enthält die Spalte „VM-Spezifikation“ folgende Informationen:
- Seriennamen, die in der Dokumentation zu Microsoft Azure verwendet werden
- Familiennamen der vCPUs, die in den im Microsoft Azure-Portal angezeigten Kontingenten verwendet werden
- Spezifischer Name für den VM-Typ aus dieser Familie
Um die aktuellen Kontingente eines Abonnements im Microsoft Azure-Portal anzuzeigen, navigieren Sie zu , klicken Sie auf das Abonnement und dann auf Verwendung + Kontingente. Weitere Informationen zu Größen für virtuelle Microsoft Windows-Maschinen in Microsoft Azure finden Sie in diesem Thema und den dazugehörigen Unterthemen in der Dokumentation zu Microsoft Azure: https://docs.microsoft.com/de-de/azure/virtual-machines/windows/sizes.
Pod-Manager-VMs
Diese VMs werden allgemein als Herzstück eines Pods angesehen. Die Pod-Manager-VMs sind für die Vereinfachung der Verbindung der Endbenutzer-Clients mit der Horizon Agent-Software verantwortlich, die in den vom Pod bereitgestellten virtuellen Desktops ausgeführt wird.
Ab der Dienstversion v2204 werden neue Horizon Cloud on Microsoft Azure-Bereitstellungen mit standardmäßig konfigurierter Hochverfügbarkeit bereitgestellt. Die Bereitstellung verfügt über zwei Pod-Manager-VMs.
| VM | Microsoft Azure-VM-Spezifikation | Anzahl | Beschreibung |
|---|---|---|---|
| Pod-Manager-Instanzen | Linux-Standard-Dv3-Familie: Standard_D4_v3 (4 Kerne, 16 GB Arbeitsspeicher) Betriebssystemlaufwerk: Herkömmliche Festplatte mit 30 GiB
Hinweis: Wenn der Standard_D4_v3-Typ in Ihrer Microsoft Azure-Region nicht verfügbar ist, verwendet der Pod-Bereitsteller stattdessen Standard_D3_v2 (4 Kerne, 14 GB Arbeitsspeicher) aus der Standard-Dv2-Familie.
|
2 pro Pod während Steady-State-Vorgängen 4 pro Pod während der End-to-End-Phase des Blue-Green-Aktualisierungsvorgangs des Pods. |
Bei Steady-State-Vorgängen sind zwei VMs vorhanden, die eingeschaltet werden und den Pod ausführen. Wenn Ihnen von VMware Operations ein neues Pod-Manifest zur Verfügung gestellt wird und das System beginnt, die „Green“-Komponenten des Blue-Green-Aktualisierungsvorgangs für den Pod zu erstellen, wird eine zweite Instanz pro Pod-Manager-VM erstellt und aktiviert. Zu diesem Zeitpunkt beläuft sich die gesamte Anzahl der ausgeführten Pod-Manager-VMs auf vier (4). Im Rahmen des End-to-End-Aktualisierungsvorgangs legen Sie die Uhrzeit fest, zu der das System zur Verwendung der „Green“-Komponenten wechselt. Nach Fertigstellung des Switches verwendet der Pod die beiden neu erstellten VMs für Steady-State-Vorgänge und die bisher verwendeten beiden VMs für die „Blue“-Komponenten des Upgrades werden angehalten und dann gelöscht. Die Größe Ihrer Umgebung muss für die vier Pod-Manager-Instanzen ausreichen, die parallel für den End-to-End-Aktualisierungszeitraum ausgeführt werden, und zwar von dem Zeitpunkt, zu dem das System mit dem Aufbau der „Green“-Komponenten des Pods für den Blue-Green-Aktualisierungsvorgang beginnt, und bis zu dem Moment, zu dem die Aktualisierungsaktivitäten abgeschlossen ist und der Pod zur Verwendung der neuen „Green“-Komponenten wechselt. Eine Beschreibung des Blue-Green-Aktualisierungsvorgangs des Pods finden Sie unter Horizon Cloud Pods – Wartung und Updates. |
Gateway-bezogene VMs
Die folgenden Instanzen fallen in diese Kategorie von Gateway-bezogenen VMs:
- Die Unified Access Gateway-Instanzen, die als sichere Gateways für die Endbenutzer-Clients konfiguriert sind, die auf die vom Pod bereitgestellten Ressourcen zugreifen.
- Die Gateway-Connector-VM, die in dem Szenario erstellt wird, in dem Sie sich für die Bereitstellung des externen Gateways in einem vom VNet des Pods getrennten VNet entscheiden. Dieser Gateway-Konnektor verarbeitet die Cloud-Verwaltungsvorgänge in diesem Szenario.
Bei Softwareaktualisierungen werden die VM-Modelle der Gateway-Instanzen beibehalten. Gateway-Instanzen besitzen nach einer Aktualisierung des Pods weiterhin das VM-Modell, das sie vor der Aktualisierung besaßen.
| VM | Microsoft Azure-VM-Spezifikation | Anzahl | Beschreibung |
|---|---|---|---|
| Unified Access Gateway-Instanzen | Ab dieser Version können Sie für Bereitstellungen neuer Gateways aus den folgenden VM-Modellen auswählen.
|
Unterschiedlich je nachdem, ob Sie sich für eine externe oder interne Unified Access Gateway-Konfiguration entscheiden oder für die Verwendung beider Typen auf demselben Pod.
Für eine ausschließlich externe oder eine ausschließlich interne Konfiguration:
Für einen Pod mit einer externen und einer internen
Unified Access Gateway-Konfiguration:
|
Unified Access Gateway ist eine optionale Funktion, die für Ihren Pod bereitgestellt wird, wenn Sie die Gateway-Einstellungen im Bereitstellungsassistenten konfigurieren. Wenn Sie Unified Access Gateway-Instanzen für den Pod verwenden, muss Ihre Umgebung diese Instanzen, die während der End-to-End-Phase des Blue-Green-Aktualisierungsvorgangs ausgeführt werden, unterstützen. Die Anzahl der Steady-State-Instanzen hängt davon ab, ob Sie sowohl die externen als auch die internen Unified Access Gateway-Konfigurationen verwenden. Wenn Sie nur eine externe oder nur eine interne Unified Access Gateway-Konfiguration verwenden, sind während Steady-State-Vorgängen zwei Instanzen vorhanden, die eingeschaltet sind und die Unified Access Gateway-Funktionen bereitstellen. Während eines Aktualisierungsvorgangs werden zwei zusätzliche Instanzen erstellt und eingeschaltet, um die Softwareupdates auf Unified Access Gateway auszuführen. Nach Fertigstellung der Aktualisierung migriert der Pod zur Verwendung der neu erstellten VMs, und die bisher verwendeten VMs für die „Blue“-Komponenten werden angehalten und dann gelöscht. Wenn Sie sowohl eine externe als auch eine interne Unified Access Gateway-Konfiguration verwenden, sind während Steady-State-Vorgängen vier Instanzen vorhanden, die eingeschaltet sind und die Unified Access Gateway-Funktionen bereitstellen. Zwei Instanzen bieten die Funktionen für die externe Konfiguration und zwei Instanzen die Funktionen für die interne Konfiguration. Während eines Aktualisierungsvorgangs werden zwei zusätzliche Instanzen pro Konfiguration erstellt und eingeschaltet, um die Softwareupdates auf Unified Access Gateway auszuführen. Nach Fertigstellung der Aktualisierung migriert der Pod zur Verwendung der neu erstellten VMs, und die bisher verwendeten VMs für die „Blue“-Komponenten werden angehalten und dann gelöscht. Die Größe Ihrer Umgebung muss für die angegebenen Unified Access Gateway-Instanzen ausreichen, die parallel für den End-to-End-Aktualisierungszeitraum ausgeführt werden, und zwar von dem Zeitpunkt, zu dem das System mit dem Aufbau der „Green“-Komponenten des Pods für den Blue-Green-Aktualisierungsvorgang beginnt, und bis zu dem Moment, zu dem die Aktualisierungsaktivitäten abgeschlossen sind und der Pod zur Verwendung der neuen „Green“-Komponenten wechselt. Eine Beschreibung des Blue-Green-Aktualisierungsvorgangs des Pods finden Sie unter Horizon Cloud Pods – Wartung und Updates. |
| VM | Microsoft Azure-VM-Spezifikation | Anzahl | Beschreibung |
|---|---|---|---|
| Connector-Instanz des Gateways | Linux-Standard-Av2-Familie: Standard_A1_v2 (1 Kern, 2 GB Arbeitsspeicher) Betriebssystemlaufwerk: Herkömmliche Festplatte mit 10 GiB |
1 für diesen externen Gateway-Typ während Steady-State-Vorgängen 2 für diesen externen Gateway-Typ während der End-to-End-Zeit für Pod-bezogene Blue-Green-Aktualisierungsaktivitäten. |
Wenn das externe Gateway in einem eigenen VNet bereitgestellt wird, wird diese VM erstellt und für die Cloud-Verwaltungsvorgänge in dieser Konfiguration des externen Gateways verwendet. Während eines Aktualisierungsvorgangs wird eine zusätzliche-Instanz erstellt und eingeschaltet, um die Software-Updates auf dem Unified Access Gateway in der Konfiguration des externen Gateways auszuführen. Nach Abschluss der Aktualisierung erfolgt die Migration auf die neu erstellte VM und die zuvor verwendete VM wird angehalten und dann gelöscht. Wenn Sie sich für die Verwendung dieser optionalen Konfiguration entscheiden, muss Ihre Umgebung diese Instanzen unterstützen, die während der Pod-bezogenen Blue-Green-Aktualisierungsaktivitäten End-to-End ausgeführt werden. |
Golden Images – Allgemein
Ein Golden Image ist eine VM mit Microsoft Windows-Betriebssystem, die so konfiguriert ist, dass Horizon Cloud sie in ein veröffentlichtes Image konvertieren kann. Diese VMs werden teilweise auch als Goldmuster bezeichnet.
Golden Images sind entweder GPU-fähig oder nicht. Dies ist von den Einstellungen abhängig, die Sie bei deren Erstellung ausgewählt haben.
In Horizon Cloud können Sie sowohl Einzel-Pod-Golden-Images als auch Multi-Pod-Golden-Images erstellen. Die Erstellung beider Typen erfolgt mithilfe des automatisierten Assistenten zum Importieren von VMs aus Marketplace der Konsole.
Der automatisierte Assistent verwendet standardmäßig automatisch eine bestimmte VM-Größe. Diese Standardeinstellung basiert auf ihren internen Einstellungen und auf Ihren Optionen im Assistenten für das jeweilige Betriebssystem (OS) und ob GPU enthalten sein soll.
Golden Image-VMs
Ab der Dienstversion v2207 gelten für Einzel-Pod-Images und Multi-Pod-Images dieselben VM-Modellanforderungen. Einzel-Pod-Images werden über die Seite „Importierte VMs“ der Konsole importiert. Multi-Pod-Images werden über die Seite Multi-Pod-Images der Konsole importiert.
| VM | Microsoft Azure-VM-Spezifikation | Anzahl | Beschreibung |
|---|---|---|---|
| Golden Images | Für GPU-fähige Golden Images verwendet das System:
|
Variiert je nach Ihren Anforderungen |
Ein Golden Image ist eine VM mit Microsoft Windows-Betriebssystem, die so konfiguriert ist, dass Horizon Cloud sie in ein veröffentlichtes Image konvertieren kann. Eine Windows-Betriebssystem-VM für Einzelsitzungen stellt die Basis zum Erstellen der VDI-Desktops bereit. Eine RDS-fähige Windows-Betriebssystem-VM bietet die Basis, um die VMs in Farmen zu erstellen, die Sitzung-basierte Desktops und Remoteanwendungen für Ihre Endbenutzer bereitstellen. Diese RDS-fähige Kategorie umfasst sowohl Windows Server-Betriebssysteme als auch Windows Enterprise-Betriebssysteme für Mehrfachsitzungen. Jedes Golden Image ist eine Kombination aus Microsoft Windows-Betriebssystem und vorhandener oder nicht vorhandener GPU-Fähigkeit. Wenn Sie möchten, dass Ihr Pod Folgendes bereitstellt:
Dann benötigen Sie mindestens 2 Golden Image-VMs. Der Vorgang zum Konvertieren von Golden Images in veröffentlichte Images wird manchmal auch als Veröffentlichen oder Versiegeln des Images bezeichnet. Das resultierende veröffentlichte Image wird manchmal versiegeltes oder zuweisbares Image genannt, da es sich in einem abgeschlossenen Zustand befindet und in Zuweisungen verwendet werden kann. Das System schaltet das Golden Image nach Abschluss des Veröffentlichungsworkflows automatisch aus. Wenn Sie ein veröffentlichtes Image aktualisieren, wird die VM erneut eingeschaltet.
Hinweis: Wenn Sie ein Einzel-Pod-Image mit der Aktion
Duplizieren der Konsole duplizieren, schaltet das System die Golden Image-VM vorübergehend ein, um dessen Konfiguration für das Duplikat zu erhalten, und schaltet sie dann wieder aus.
Informationen zum Erstellen eines Einzel-Pod-Golden Image finden Sie im Thema Erstellen von Desktop-Images und Ihren Horizon Cloud-Pods. |
| Für nicht-GPU-fähige Golden Images, die Nicht-Windows 11-Betriebssysteme verwenden, verwendet das System Folgendes:
|
|||
| Für Nicht-GPU-fähige Golden Images mit Microsoft Windows 11-Betriebssystem oder einem Windows 11 Enterprise-Betriebssystem für Mehrfachsitzungen verwendet das System:
|
Farm-VMs
RDSH-Farm-VMs sind die RDS-fähigen Instanzen, die sitzungsbasierte Desktops und Remoteanwendungen für Ihre Endbenutzer bereitstellen. Sie benötigen mindestens eine RDSH-Farm für die Bereitstellung von Sitzungs-Desktops und eine RDSH-Farm für die Bereitstellung von Remoteanwendungen. Sie können zusätzliche Farmen bereitstellen, um Administrator- oder Endbenutzeranforderungen zu erfüllen.
| VM | Microsoft Azure-VM-Spezifikation | Anzahl | Beschreibung |
|---|---|---|---|
| RDSH-Farm | Sie können den Satz der Microsoft Azure-VM-Typen anpassen, die bei der Erstellung von Farmen in Ihrem Pod zur Auswahl stehen sollen. Sie können Ihre eigene Liste aus dem Satz der Microsoft Azure-VM-Größen anpassen, die in den standardmäßigen Microsoft Azure-Regionen generell verfügbar sind. Weitere Informationen zum Anpassen des Satzes der VM-Typen, die für die Verwendung in Ihren Farmen verfügbar sind, finden Sie im Horizon Cloud-Administratorhandbuch. Beim Erstellen oder Bearbeiten einer Farm können Sie die Größe der Betriebssystemfestplatte der RDSH-Instanzen der Farm anpassen, um sie gegenüber dem Systemstandardwert zu ändern. Spezifische Details zu den Windows-VM-Größen, die in den standardmäßigen Microsoft Azure-Regionen generell verfügbar sind, finden Sie in der Microsoft-Dokumentation unter https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.
Hinweis: Stellen Sie für Produktionsumgebungen sicher, dass die VM-Typen, die Sie für Ihre Farmen verwenden, über mindestens zwei (2) CPUs verfügen. Wenn Sie diese Kriterien erfüllen, werden unerwartete Probleme bei der Endbenutzer-Verbindung vermieden. Diese Kriterien sind das Ergebnis der Horizon Agent-Empfehlungen, über mindestens 2 CPUs für die Installation oder ein Update von Horizon Agent von Version 7.x oder höher zu verfügen. Diese Horizon Agent-Kriterien werden in der Horizon-Produktdokumentation ab Version 7.8 angegeben (die Verweise auf mindestens 2 CPUs beginnen mit dieser
-Version 7.8 zum Installieren von Horizon Agent auf einer virtuellen Maschine ).
|
Variiert je nach Ihren Anforderungen und wie Sie die VM-Größen in Ihrer Horizon Cloud-Umgebung angepasst haben. | Der Betriebszustand dieser VMs variiert je nach den Farm-Konfigurationseinstellungen und dem Endbenutzerbedarf. |
VDI-Desktop-VMs
VDI-Desktop-VMs sind die Instanzen, die VDI-Desktops für Ihre Endbenutzer bereitstellen.
| VM | Microsoft Azure-VM-Spezifikation | Anzahl | Beschreibung |
|---|---|---|---|
| VDI-Desktops | Sie können den Satz der Microsoft Azure-VM-Typen anpassen, die bei der Erstellung von VDI-Desktop-Zuweisungen in Ihrem Pod zur Auswahl stehen sollen. Sie können Ihre eigene Liste aus dem Satz der Microsoft Azure-VM-Größen anpassen, die in den standardmäßigen Microsoft Azure-Regionen generell verfügbar sind. Weitere Informationen zum Anpassen des Satzes der VM-Typen, die für die Verwendung in Ihren VDI-Desktop-Zuweisungen verfügbar sind, finden Sie im Horizon Cloud-Administratorhandbuch.
Hinweis: Einige wenige Microsoft Azure-VM-Größen, die von Microsoft für VDI-Anwendungsfälle als ungeeignet eingestuft wurden, werden automatisch aus der Verwendung ausgeschlossen, z. B Standard_B2ls und Standard_B1s.
Beim Erstellen oder Bearbeiten einer VDI-Desktop-Zuweisung können Sie die Größe der Betriebssystemfestplatte der VDI-Desktop-Instanzen anpassen, um sie gegenüber dem Systemstandard zu ändern. Nähere Informationen zu diesen Windows-VM-Größen finden Sie in der Microsoft-Dokumentation unter https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.
Hinweis: Stellen Sie für Produktionsumgebungen sicher, dass die VM-Typen, die Sie für Ihre VDI-Desktopzuweisungen verwenden, über mindestens zwei (2) CPUs verfügen. Wenn Sie diese Kriterien erfüllen, werden unerwartete Probleme bei der Endbenutzer-Verbindung vermieden. Diese Kriterien sind das Ergebnis der Horizon Agent-Empfehlungen, über mindestens 2 CPUs für die Installation oder ein Update von Horizon Agent von Version 7.x oder höher zu verfügen. Diese Horizon Agent-Kriterien werden in der Horizon-Produktdokumentation ab Version 7.8 angegeben (die Verweise auf mindestens 2 CPUs beginnen mit dieser
-Version 7.8 zum Installieren von Horizon Agent auf einer virtuellen Maschine ).
|
Variiert je nach Ihren Anforderungen und wie Sie die VM-Größen in Ihrer Horizon Cloud-Umgebung angepasst haben. | Der Betriebszustand dieser VMs variiert je nach den Einstellungen für VDI-Desktop-Zuweisung und dem Endbenutzerbedarf. |
Sonderfall – Supportbezogene Jumpbox-VM
Wenn Sie eine Support-Anfrage an VMware stellen und das Supportteam feststellt, dass die Bearbeitung dieser Anfrage die Bereitstellung einer temporären Jumpbox-VM für die Kommunikation mit den von VMware verwalteten Appliances erfordert, müssen Ihre Abonnement-Cores und Ihr Kontingent zu diesem Zeitpunkt für diese Bereitstellung ausreichen. Für eine supportbezogene Jumpbox-Bereitstellung werden Sie um Erlaubnis gefragt.
Diese Jumpbox wird unter der Aufsicht des VMware-Supportteams bereitgestellt und anschließend unter der Aufsicht des VMware-Supportteams gelöscht, wenn die VM nicht mehr zur Bearbeitung Ihrer Support-Anfrage benötigt wird.
| VM | Microsoft Azure-VM-Spezifikation | Anzahl | Beschreibung |
|---|---|---|---|
| Supportbezogene Jumpbox | Linux-Standard-F-Familie: Standard_F2 (2 Kerne, 4 GB Arbeitsspeicher) Betriebssystemlaufwerk: Herkömmliche Festplatte mit 30 GiB |
1 | Diese supportbezogene Jumpbox-VM ist für die sichere Kommunikation mit den von VMware verwalteten Appliances im Rahmen Ihrer Support-Anfrage an den VMware Support vorgesehen. |
