Wenn Horizon Cloud auf Fehler mit dem Pod-Aktualisierungsvorgang stößt, die den Fortschritt blockieren und die Sie beheben können, werden diese Fehler in der Verwaltungskonsole angezeigt, sodass Sie die erforderlichen Aktionen zur Behebung durchführen können. Die aufgetretenen Fehler, die die erfolgreiche Ausführung verhindern, unterliegen in Ihrer Microsoft Azure-Umgebung Ihrer Kontrolle. Da die Abhilfemethode Ihrer Kontrolle unterliegt und der Fehler nicht von VMware behoben werden kann, müssen Sie die Schritte zur Fehlerbehebung durchführen, wenn Sie eine Benachrichtigung zu Aktualisierungsfehlern in der Konsole sehen, und sich anschließend an den VMware Support wenden, um den Pod-Aktualisierungsvorgang fortzusetzen.

Unter Aktualisieren Ihres Horizon Cloud-Pods wird beschrieben, wie der Aktualisierungsvorgang für einen in Microsoft Azure bereitgestellten Pod funktioniert. Im Allgemeinen folgt der Aktualisierungsvorgang einem Blue-Green-Schema, wobei die vorhandenen zu aktualisierenden Pod-Ressourcen in den Hauptressourcengruppen des Pods und die Gateway-bezogenen Ressourcengruppen die „Blue“-Komponenten sind. Der erste Schritt des Vorgangs umfasst das Erstellen einer Jump-Box-Ressourcengruppe in Ihrem Abonnement und das Bereitstellen einer Jump-Box-VM in dieser Ressourcengruppe. Diese Jump-Box-VM koordiniert dann die Erstellung eines parallelen Satzes von Pod-VMs in Ihrem Abonnement innerhalb der vorhandenen Ressourcengruppen des Pods. Diese parallele Gruppe umfasst die „Green“-Komponenten im Blue-Green-Schema. Zu den „Green“-Komponenten zählen VMs, die parallel zu den in der Hauptressourcengruppe des Pods und in Gateway-bezogenen Ressourcengruppen vorhanden sind, wie z. B. Pod-Manager-VMs und Unified Access Gateway-VMs. Diese VMs werden gestartet und parallel zu den VMs des zu aktualisierenden Pods (die VMs, die „Blue“-Komponenten umfassen) ausgeführt, bis der End-to-End-Aktualisierungsvorgang abgeschlossen ist. Der End-to-End-Aktualisierungsvorgang wird erst abgeschlossen, nachdem Sie die Konsole verwendet haben, um die Aktualisierung zu planen, und diese geplante Aktivität ausgeführt wird sowie der Wechsel des Pods von der Verwendung der „Blue“-VMs zu den „Green“-VMs abgeschlossen ist. Wenn der Pod die „Green“-VMs verwendet, werden die „Blue“-VMs angehalten und entfernt, und die Jump-Box-VM und ihre Ressourcen werden gelöscht.

Das Erstellen der „Green“-VMs kann nicht erfolgreich abgeschlossen werden, wenn Ihre Microsoft Azure-Umgebung die Erstellung dieser parallelen „Green“-VMs neben den vorhandenen Pod-VMs nicht unterstützen kann. Ein typischer Hauptgrund dafür ist, dass das zugewiesene Microsoft Azure-Abonnement des Pods nicht über ein ausreichendes Kontingent verfügt, um die Jump-Box-VM und die „Green“-VMs zu instanziieren. Ein weiterer Grund dafür, dass bei der Einrichtung der „Green“-VMs Fehler auftreten können, besteht darin, dass Ihr Pod aktuell offline ist. Zu dem Zeitpunkt, für den Sie das Update in der Konsole planen, stellt Horizon Cloud die Jump-Box-VM bereit, damit diese den Zeitplan verfolgen und zur Verfügung stehen kann, um zum geplanten Zeitpunkt die Migration des Pods zu den neueren Komponenten zu starten. Wenn das zugeordnete Microsoft Azure-Abonnement des Pods nicht über ein ausreichendes Kontingent verfügt, um die Jump-Box-VM zu instantiieren und die Ausführung über den Zeitraum zwischen dem von Ihnen geplanten Zeitpunkt und dem Abschluss des Wechsels zu den „Green“-VMs zu gewährleisten, wird ein Aktualisierungsfehler als Benachrichtigung in der Konsole angezeigt.

Eine Beschreibung der diversen Systemaktivitäten im End-to-End-Pod-Aktualisierungsvorgang finden Sie unter Aktualisieren Ihres Horizon Cloud-Pods.

Die Aktualisierung verhindernde Fehler, die in der Regel auftreten können

Dabei handelt es sich um Fehler, die die Aktualisierung verhindern können, die häufig auftreten können und die Sie selbst in Ihrer Microsoft Azure-Umgebung beheben können.

Das Abonnement verfügt nicht über die erforderliche Kapazität für das Instanziieren der Jump-Box-VM.
Der Aktualisierungsvorgang dient dazu, eine Jump-Box-VM im Pod-Abonnement zu instanziieren, wenn Sie den Planer zum Festlegen des Updates verwenden, wenn das System die „Green“-Komponenten erstellt und wenn der geplante Zeitpunkt für die Koordination des Wechsels von „Blue“- zu „Green“-Komponenten eintritt. Diese Jump-Box-VM orchestriert die Arbeit, um die neuen Komponenten bereitzustellen und den eigentlichen Migrationsvorgang auszuführen. Zusammen mit Ihrer aktuellen Kontingentnutzung durch die VMs Ihrer vorhandenen Pods, die dasselbe Abonnement verwenden, muss das Kontingent Ihres Abonnements eine zusätzliche VM der Standard_F2 VM-Spezifikation mit 2 Kernen (vCPUs) zulassen. Diese Kontingentanforderung gelten zusätzlich zu den VM-Typen und -Kernen, die für das Erstellen der parallelen „Green“-VMS erforderlich sind.
Das Abonnement verfügt nicht über die entsprechenden Kerne (vCPUs) oder VM-Größen, die für die Instanziierung aller VMs für die „Green“-VMs verfügbar sind.
Wenn die „Green“-Komponenten erstellt wurden, wird für jede VM in Ihrem aktuellen Pod eine andere VM erstellt. Infolgedessen verfügen Sie in dem Zeitraum zwischen dem Aufbau der „Green“-Komponenten und dem Wechsel von den „Blue“- zu den „Green“-Komponenten zum in der Konsole festgelegten Zeitpunkt über eine doppelte Anzahl von Pod-Manager-VMs und Unified Access Gateway-VMs. Um das Erstellen dieser „Green“-VMs unterstützen zu können, müssen die Kontingentebenen Ihres Abonnements für Kerne (vCPUs) aus den entsprechenden Microsoft-VM-Familien ausreichen, um die parallel ausgeführten „Green“-VMs über das Kontingent hinaus zu ermöglichen, das Sie bereits von diesem Abonnement für die vorhandenen zugeordneten Pods verwendet haben. finden Sie die erforderlichen Kerne für die verschiedenen VM-Typen und -Nutzungen.
Der Pod ist derzeit offline oder kann derzeit nicht mit Horizon Cloud kommunizieren.
Stellen Sie auf der Seite „Kapazität“ sicher, dass der zu aktualisierende Pod den Status „Online“ anzeigt. Melden Sie sich beim Microsoft Azure-Portal an und prüfen Sie, ob die Pod-Manager-VM und deren Unified Access Gateway-VMs (sofern Ihr Pod diese enthält) aktiv sind. Wenn eine VM nicht läuft, aktivieren Sie diese. Weitere Informationen zu den Ressourcengruppen, in denen sich diese VMs befinden, finden Sie unter Für einen in Microsoft Azure bereitgestellten Pod erstellte Ressourcengruppen.

Für die Zeit von der Bereitstellung der grünen VMs bis zum Abschluss des Wechsels zum grünen Pod benötigte Kontingente und Kerne

Wenn Sie über einen Aktualisierungsfehler aufgrund fehlender verfügbarer Kerne benachrichtigt werden, verwenden Sie die folgende Tabelle, um das zusätzliche Kontingent zu sehen, das Sie benötigen. Für die verschiedenen VM-Typen, die im aktuellen blauen Pod verwendet werden, wird in der Tabelle am Ende dieses Themas das von diesen Typen verwendete Kontingent, das zusätzliche Kontingent, das bei der Erstellung der grünen Pod-VMs benötigt wird, und das Gesamtkontingent beschrieben, das für die Ausführung von blauen und grünen VMs von der Erstellung der grünen VMs bis zum Abschluss des Wechsels zu den grünen VMs erforderlich ist. Details zu den VM-Familientypen und -Kernen, die von einem Pod verwendet werden, finden Sie im Dokumentationsthema zu VM-Anforderungen für einen Pod im Bereitstellungshandbuch.

VM-Typen und ihre Kerne Beschreibung Gesamtkontingent zum Ausführen von blauen VMs und grünen VMs bis zum Abschluss des Wechsels zu grünen VMs
VM-Typ „Standard_D4_v3“, jeweils 4 Kerne
Hinweis: Wenn der Typ „Standard_D4_v3“ in Ihrer Microsoft Azure-Region nicht verfügbar ist, verwendet Ihr Pod in der Regel den Typ „Standard_D3_v2 VM“. Dieser Typ verwendet ebenfalls 4 Kerne.
Dieser VM-Typ wird für die Pod-Manager-VMs verwendet.
Für einen Pod mit einer einzelnen Manager-VM
Ihr Kontingent muss die Verwendung der 4 Kerne der vorhandenen („Blue“-)Manager-VM sowie 4 zusätzlicher Kerne für die parallel ausgeführte „Green“-Manager-VM ermöglichen. Acht (8) Kerne zur Abdeckung dieser Nutzung.
Für einen Pod mit aktivierter Hochverfügbarkeit, der über zwei Manager-VMs verfügt
Ihr Kontingent muss die Verwendung der 8 Kerne der vorhandenen („Blue“-)Manager-VMs (2 VMs mit je 4 Kernen) sowie 8 zusätzlicher Kerne für die parallel ausgeführten „Green“-Manager-VMs ermöglichen. Sechzehn (16) Kerne zur Abdeckung dieser Nutzung.
Je nachdem, was Sie bei der Bereitstellung des Pods ausgewählt haben:
  • Standard_A4_v2 VM (hat 4 Kerne)
  • Standard_F8s_v2 (hat 8 Kerne)
Dieser VM-Typ wird für die Unified Access Gateway-VMs in den Gateway-Konfigurationen Ihres Pod verwendet. Die Anzahl der Kerne, die Ihr Abonnement unterstützen muss, hängt davon ab, welche Gateway-Typen auf Ihrem Pod konfiguriert sind.
Für einen Pod mit nur einem externen Gateway
Dieses externe Gateway verfügt über zwei Unified Access Gateway-VMs, also zweimal so viele VMs, wie die Anzahl Kerne, die sie jeweils haben. Für die „Green“-Komponenten muss Ihr Kontingent die Verwendung der gesamten Kerne der vorhandenen („Blue“-) Unified Access Gateway-VMs und zusätzlich zweimal so viele Kerne für die parallel ausgeführten „Green“-Unified Access Gateway-VMs ermöglichen.
  • Wenn Ihre VMs z. B. dem Standard_A4_v2 mit jeweils 4 Kernen entsprechen, benötigen Sie 2 * 4 * 2 * = 16 Kerne, um diese Nutzung abzudecken.
  • Wenn es sich bei Ihren VMs um eine virtuelle Maschine mit jeweils 8 Kernen handelt, benötigen Sie 2 * 8 * 2 = 32 Kerne, um diese Nutzung abzudecken.
Für einen Pod mit nur einem internen Gateway
Dieses Gateway verfügt über zwei Unified Access Gateway-VMs, also zweimal so viele VMs wie die Anzahl Kerne, die sie jeweils haben. Für die „Green“-Komponenten muss Ihr Kontingent die Verwendung der gesamten Kerne der vorhandenen („Blue“-) Unified Access Gateway-VMs und zusätzlich zweimal so viele Kerne für die parallel ausgeführten „Green“-Unified Access Gateway-VMs ermöglichen.
  • Wenn Ihre VMs z. B. dem Standard_A4_v2 mit jeweils 4 Kernen entsprechen, benötigen Sie 2 * 4 * 2 * = 16 Kerne, um diese Nutzung abzudecken.
  • Wenn es sich bei ihren VMs um eine virtuelle Maschine mit jeweils 8 Kernen handelt, benötigen Sie 2 * 8 * 2 = 32 Kerne, um diese Nutzung abzudecken.
Für einen Pod mit beiden Gateway-Typen
Dieses Gateway verfügt über vier Unified Access Gateway-VMs, also 4 VMs mal der Anzahl Kerne, die sie jeweils haben. Für die „Green“-Komponenten muss Ihr Kontingent die vierfache Anzahl Kerne der vorhandenen („Blue“-)Unified Access Gateway-VMs sowie zwei zusätzliche Kerne für die parallel ausgeführten „Green“-Unified Access Gateway-VMs ermöglichen.
  • Wenn Ihre VMs z. B. dem Standard_A4_v2 mit jeweils 4 Kernen entsprechen, benötigen Sie 4 * 4 * 2 * = 32 Kerne, um diese Nutzung abzudecken.
  • Wenn es sich bei Ihren VMs um eine virtuelle Maschine mit jeweils 8 Kernen handelt, benötigen Sie 4 * 8 * 2 = 64 Kerne, um diese Nutzung abzudecken.
VM-Typ „Standard_F2“, 2 Kerne Diese VM wird für die Jump-Box-VM verwendet. Ihr Kontingent muss die Bereitstellung und Ausführung dieser 2 Kerne für die Jump Box-VM ermöglichen, während die „Green“-Komponenten erstellt und die Pod-Aktualisierungsvorgänge koordiniert werden.