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. Wenn Sie die Funktion Horizon-Infrastrukturüberwachung für einen Pod in Microsoft Azure aktivieren, muss das Abonnement für Ihren Pod über das entsprechende Kontingent und die entsprechende Konfiguration verfügen, um die Bereitstellung der Virtuelle Horizon Edge-Appliance im Rahmen dieses Abonnements zu unterstützen.

Wichtig: Der Assistent für die Pod-Bereitstellung überprüft, ob das Kontingent an Kernen in Ihrer Microsoft Azure-Umgebung ausreicht, um den Pod und gegebenenfalls die von Ihnen angegebene Gateway-Konfiguration zu erstellen. Wenn der Assistent feststellt, dass aufgrund der im Assistenten angegebenen Abonnementinformationen nicht genügend Kontingent vorhanden ist, wird eine Meldung auf dem Bildschirm angezeigt und der Assistent fährt nicht mit dem nächsten Schritt fort.

Ab der in der Version vom September 2019 eingeführten Pod-Manifestversion verfügt jeder Pod über einen Microsoft Azure Load Balancer und eine Microsoft Azure-Datenbank für PostgreSQL-Server. Dies gilt sowohl für in dieser Version neu bereitgestellte Pods als auch für Pods, die auf diese Version aktualisiert wurden. Wenn ein Pod auf das Manifest vom September 2019 oder höhere Versionen aktualisiert wird, enthält der aktualisierte Pod einen Microsoft Azure Load Balancer und eine Microsoft Azure-Datenbank für PostgreSQL-Server. Die Bereitstellung der Microsoft Azure-Datenbank für den PostgreSQL-Server erfolgt über die Bereitstellung eines einzelnen Servers.

Hinweis: GPU-fähige VMs sind nur in einigen Microsoft Azure-Regionen verfügbar. Details finden Sie unter Microsoft Azure-Produkte nach Region.

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 Alle Dienste > Abonnements, 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.

Jumpbox-VMs

Jumpbox-VMs werden für die unten in den Tabellen beschriebenen Zwecke vorübergehend in Ihren Microsoft Azure-Abonnements erstellt.

Tabelle 1. Jumpbox-VM-Anforderungen für Pods
VM Microsoft Azure-VM-Spezifikation Menge Beschreibung
Jumpbox Linux-Standard-F-Familie:

Standard_F2 (2 Kerne, 4 GB Arbeitsspeicher)

Betriebssystemlaufwerk: Herkömmliche Festplatte mit 30 GiB

1 pro Pod Eine VM, die in Ihrer Microsoft Azure-Umgebung erstellt und bei der Erstellung des ersten Pods sowie bei nachfolgenden Softwareupdates in der Umgebung verwendet wird. Eine Jumpbox-VM für jeden Pod, den Sie bereitstellen. Diese Jumpbox-VM wird automatisch gelöscht, wenn der Pod-Erstellungs- oder Aktualisierungsprozess beendet ist und die VM nicht mehr benötigt wird.
Hinweis: Eine Jumpbox-VM wird neu bereitgestellt, um einen Pod zu erstellen, um die „Green“-Komponenten eines Updates zu erstellen, wenn die nächste Version der Pod-Software verfügbar ist, um den Blue-Green-Aktualisierungsvorgang auf dem Pod zu steuern und um einem vorhandenen Pod eine Gateway-Konfiguration hinzuzufügen.
Tabelle 2. Bei externem Gateway in einem eigenen VNet: Anforderungen an die Jumpbox-VMs
VM Microsoft Azure-VM-Spezifikation Menge Beschreibung
Jumpbox Linux-Standard-F-Familie:

Standard_F2 (2 Kerne, 4 GB Arbeitsspeicher)

Betriebssystemlaufwerk: Herkömmliche Festplatte mit 30 GiB

1 pro Pod Wenn Sie das externe Gateway optional in einem eigenen VNet oder einem eigenen Abonnement bereitstellen, benötigt es eine Jumpbox-VM. Diese muss von der in den eigenen Kernressourcen des Pods verwendeten Jumpbox-VM getrennt sein. Diese Jump-Box-VM wird in Ihrer Microsoft Azure-Umgebung in einer separaten Ressourcengruppe aus der Jumpbox-VM des Pods erstellt und während der ersten Bereitstellung der Konfiguration des externen Gateways und bei nachfolgenden Software-Updates auf diesem externen Gateway verwendet. Eine Jumpbox-VM für jedes externe Gateway in einem eigenen VNet oder einem von Ihnen bereitgestellten Abonnement. Diese Jumpbox-VM wird automatisch gelöscht, wenn der Bereitstellungs- oder Aktualisierungsvorgang für das externe Gateway beendet ist und die VM nicht mehr benötigt wird.
Hinweis: Eine Jumpbox-VM wird neu bereitgestellt, um eines dieser externen Gateways in einem eigenen VNet oder einem eigenen Abonnement zu erstellen (während der Pod-Erstellung oder wenn Sie den Workflow „Pod bearbeiten“ verwenden, um das externe Gateway zu einem vorhandenen Pod hinzuzufügen), für die Erstellung der „Green“-Komponenten eines Updades für dieses externe Gateway, wenn Ihnen die nächste Version der Software des externen Gateways oder Pods zur Verfügung gestellt wird, um den Blue-Green-Aktualisierungsvorgang auf diesem externen Gateway zu orchestrieren.

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.

Tabelle 3. VM-Anforderungen für die Pod-Verwaltung – für die Kern-VMs des Pods ohne Gateway-Konfigurationen
VM Microsoft Azure-VM-Spezifikation Menge Beschreibung
Pod ohne aktivierte Hochverfügbarkeit: Pod-Verwaltungsinstanzen 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 Bereitsteller stattdessen Standard_D3_v2 (4 Kerne, 14 GB Arbeitsspeicher) aus der Standard-Dv2-Familie.
1 pro Pod während Steady-State-Vorgängen

2 pro Pod während der End-to-End-Phase des Blue-/Green-Aktualisierungsvorgangs des Pods.

Bei einem Pod ohne aktivierte Hochverfügbarkeit ist bei Steady-State-Vorgängen eine VM vorhanden, die eingeschaltet wird und den Pod ausführt. 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 erstellt und aktiviert. 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 neu erstellte VM für Steady-State-Vorgänge und die bisher verwendete VM für die „Blue“-Komponenten des Upgrades wird angehalten und dann gelöscht.

Die Größe Ihrer Umgebung muss für die beiden Pod-Manager-Instanzen ausreichen, die parallel für den End-to-End-Updade-Zeitraum 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 Upgrade-Aktivitä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.

Pod mit aktivierter Hochverfügbarkeit: Pod-Verwaltungsinstanzen 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 einem Pod mit aktivierter Hochverfügbarkeit ist bei Steady-State-Vorgängen eine VM vorhanden, die eingeschaltet wird und den Pod ausführt. 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

Gateway-bezogene VMs sind:

  • Die Unified Access Gateway-Instanzen, die als sichere Gateways für die Endbenutzer-Clients konfiguriert sind, die auf die vom Pod bereitgestellten Ressourcen zugreifen.
  • Wenn Sie das externe Gateway in einem separaten VNet bereitstellen: Die Gateway-Connector-VM, die die Cloud Management-Vorgänge für diese externe Gateway-Konfiguration verarbeitet.
Hinweis: Ab der vierteljährlichen Version vom Juli 2020 können Sie in einer Liste der für Unified Access Gateway-Instanzen unterstützten VM-Modelle eine Auswahl treffen, wenn Sie ein ganz neues Gateway bereitstellen – entweder zum Zeitpunkt der Bereitstellung des gesamten Pods oder wenn Sie ein neues Gateway hinzufügen. Vor der Version vom Juli 2020 mussten die Gateway-Instanzen das VM-Modell Standard_A4_v2 verwenden. Welche unterstützten VM-Modelle in der Liste auf dem Bildschirm des Assistenten zur Auswahl stehen, hängt davon ab, welche VM-Modelle in der Microsoft Azure-Region verfügbar sind, in der Sie die Gateway-Instanzen bereitstellen. Die angezeigten Auswahlmöglichkeiten hängen außerdem von Ihrem VM-Kontingent im Microsoft Azure-Abonnement ab, das Sie für die Gateway-Bereitstellung verwenden. Das Menü VM-Modell des Assistenten für die Pod-Bereitstellung zeigt dynamisch die VM-Modelle an, die diese Anforderungen erfüllen.

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.

Tabelle 4. Unified Access Gateway-VM-Anforderungen
VM Microsoft Azure-VM-Spezifikation Menge Beschreibung
Unified Access Gateway-Instanzen Ab dieser Version können Sie für Bereitstellungen neuer Gateways aus den folgenden VM-Modellen auswählen.
  • Linux-Standard-Av2-Familie: Standard_A4_v2 (4 Kerne, 8 GB Arbeitsspeicher), Betriebssystem-Festplatte: Standard-HDD 20 GiB
  • Linux-Standard-FSv2-Familie:
    • Standard_F8s_v2 (8 Kerne, 16 GB Arbeitsspeicher), Betriebssystem-Festplatte: SSD 32 GiB

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:
  • 2 pro Pod während Steady-State-Vorgängen
  • 4 pro Pod während der End-to-End-Phase der Blue-Green-Aktualisierungsaktivitäten des Pods.
Für einen Pod mit einer externen und einer internen Unified Access Gateway-Konfiguration:
  • 4 pro Pod während Steady-State-Vorgängen
  • 8 pro Pod während der End-to-End-Phase der Blue-Green-Aktualisierungsaktivitäten des Pods.
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.

Tabelle 5. Bei externem Gateway in einem eigenen VNet: Anforderungen an die Connector-VM des Gateways
VM Microsoft Azure-VM-Spezifikation Menge 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 Image-VMs

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.

Tabelle 6. Image-VM-Anforderungen
VM Microsoft Azure-VM-Spezifikation Menge Beschreibung
Golden Images

Golden Images sind entweder GPU-fähig oder nicht. Dies ist von den Einstellungen abhängig, die Sie bei deren Erstellung ausgewählt haben.

Für GPU-fähige Golden Images verwendet das System:

  • NV6 Standard der NV-Serie (von den vCPUs der Standard NV-Familie)
  • Betriebssystemlaufwerk: Herkömmliche Festplatte mit 127 GiB

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 RDSH-fähige VM mit Windows-Betriebssystem bietet die Basis, um die RDSHs in Farmen zu erstellen, die Sitzung-basierte Desktops und Remoteanwendungen für Ihre Endbenutzer bereitstellen. Eine Windows-Clientbetriebssystem-VM stellt die Basis zum Erstellen der VDI-Desktops bereit. 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:

  • RDSH-Desktops mit Microsoft Windows 2016 Datacenter, ohne GPU
  • RDSH-Desktops mit Microsoft Windows 2016 Datacenter, mit GPU

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 Golden Image wird automatisch deaktiviert, nachdem es veröffentlicht wurde (wenn Sie die Aktion In Image konvertieren für das Golden Image in der Verwaltungskonsole ausführen). Wenn Sie ein veröffentlichtes Image aktualisieren, wird die VM erneut eingeschaltet.

Hinweis: Wenn Sie ein Image mithilfe der Konsole duplizieren, schaltet das System die VM des Golden Images vorübergehend ein, um dessen Konfiguration für das Duplikat zu erhalten, und schaltet es dann wieder aus.

Informationen zum Erstellen eines Golden Image finden Sie im Thema Erstellen von Desktop-Images und Ihren Horizon Cloud-Pods.

Für nicht GPU-fähige Golden Images und Microsoft Windows-Clientbetriebssysteme verwendet das System Folgendes:

  • Standard_D4_v3 (von den vCPUs der Standard-Dv3-Familie)
  • Betriebssystemlaufwerk: Herkömmliche Festplatte mit 127 GiB

Wenn Microsoft die Standard-Dv3-Familie in der Microsoft Azure-Region, in der Sie den Pod bereitgestellt haben, nicht anbietet, verwendet das System stattdessen Standard_D3_v2 aus der Standard-Dv2-Familie.

Für nicht GPU-fähige Golden Images und RDSH-fähige Microsoft Windows-Betriebssysteme verwendet das System Folgendes:

  • Standard_D2_v3 (von den vCPUs der Standard-Dv3-Familie)
  • Betriebssystemlaufwerk: Herkömmliche Festplatte mit 127 GiB

Wenn Microsoft die Dv3-Serie in der Microsoft Azure-Region, in der Sie den Pod bereitgestellt haben, nicht anbietet, verwendet das System stattdessen Standard_D2_v2 aus der Standard-Dv2-Familie.

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.

Hinweis: In der aktuellen Dienstversion können Sie nicht sowohl sitzungsbasierte Desktops als auch Remoteanwendungen von derselben Farm aus bereitstellen.
Tabelle 7. Farm-VM-Anforderungen
VM Microsoft Azure-VM-Spezifikation Menge 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.

Hinweis: Neu in der vierteljährlichen Dienstversion vom Juli 2020 ist die Verwendung von App Volumes-Funktionen mit Pods in Microsoft Azure. Wenn Sie den App Volumes-Erfassungsvorgang der Konsole nutzen, um native Anwendungen zu Ihrem Horizon Cloud-Bestand hinzuzufügen, erstellt das System eine VDI-Desktop-Zuweisung von zwei VMs, um den Erfassungsvorgang zu unterstützen. Der für diese vom System generierte Zuweisung verwendete VM-Typ entspricht dem Modell, das für das veröffentlichte Image verwendet wird, das Sie in der Konsole für den Anwendungserfassungsvorgang ausgewählt haben.
Tabelle 8. VDI-Desktop-VM-Anforderungen
VM Microsoft Azure-VM-Spezifikation Menge 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.

Virtuelle Horizon Edge-Appliance

Wenn Sie die Horizon Universal Console verwenden, um Horizon-Infrastrukturüberwachung auf einem Pod zu aktivieren, wird diese Appliance in einem Microsoft Azure-Abonnement dieses Pods erstellt.

Tabelle 9. Virtuelle Horizon Edge-Appliance-Anforderungen
VM Microsoft Azure-VM-Spezifikation Menge Beschreibung
Virtuelle Horizon Edge-Appliance Linux-Standard-Dv3-Familie:

Standard_D4_v3 (4 Kerne, 16 GB Arbeitsspeicher)

Betriebssystemlaufwerk: Herkömmliche Festplatte mit 30 GiB

1 pro Pod Wenn die Funktion Horizon-Infrastrukturüberwachung auf einem Pod aktiviert ist, wird diese VM erstellt und für die Erfassung der Überwachungsdaten und deren Übermittlung an Cloud Monitoring Service (CMS) verwendet.