In diesem Thema werden die Abhilfemaßnahmen beschrieben, die bei häufigen Vorabprüfungsfehlern zu ergreifen sind. Wenn die Vorabprüfungen des Systems Bedingungen aufzeigen, die Wartungsaktivitäten an einem Pod blockieren würden, werden diese Fehler auf Horizon Universal Console angezeigt, damit Sie die erforderlichen Maßnahmen zur Behebung ergreifen können.

Wichtig: Wenn Sie Benachrichtigungen über Pod-Aktualisierungsfehler erhalten, führen Sie die angegebenen Maßnahmen durch, um die Fehler rechtzeitig zu beheben. Die Zeit ist von entscheidender Bedeutung. Wenn diese Fehler nicht in der von VMware geforderten Zeit behoben werden, geht der Pod in einen nicht unterstützten Zustand über, da der Pod-Aktualisierungsprozess nicht eingeleitet werden kann.

Wie unter Horizon Cloud-Pods – Wartung und Updates beschrieben, benachrichtigt Sie das System über die wartungshemmenden Bedingungen, die in Ihrer Microsoft Azure-Umgebung unter Ihrer Kontrolle stehen. Da die Abhilfemethode in Ihrem Einflussbereich liegt und nicht von VMware behoben werden kann, müssen Sie, wenn Sie eine Benachrichtigung über Aktualisierungsfehler in der Konsole sehen oder eine Benachrichtigungs-E-Mail über solche Fehler erhalten, die Aktionen zur Behebung der Fehler abschließen und sich dann an den VMware Support wenden, um die Wartungsaktivität fortzusetzen.

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 Jumpbox-VM im Pod-Abonnement zu instanziieren, wenn Sie den Planer zum Festlegen der Aktualisierung verwenden, wenn das System die „Green“-Komponenten erstellt und wenn der geplante Zeitpunkt für die Koordination der Migration von „Blue“- zu „Green“-Komponenten eintritt. Diese Jumpbox-VM orchestriert die Arbeit, um die grünen 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 Kontingentanforderungen gelten zusätzlich zu den VM-Typen und -Kernen, die für das Erstellen der parallelen einzurichtenden 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 parallel einzurichtenden 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 der Migration 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, einzurichtenden 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.
Die Berechtigung zum Erstellen oder Löschen von Ressourcengruppen ist für dieses Microsoft Azure-Abonnement nicht aktiviert.
Die Systemvorprüfung überprüft, ob der mit diesem Pod verknüpfte Dienstprinzipal über die erforderlichen Berechtigungen verfügt, die der Dienst benötigt. Wie bereits in diesem Dokumentationsthema beschrieben, erfordert der Dienst die automatische Erstellung einer temporären Jumpbox in seiner eigenen Ressourcengruppe, um Aktualisierungsvorgänge zu orchestrieren, und das automatische Löschen dieser temporären Jumpbox und der Ressourcengruppe, wenn diese Arbeit abgeschlossen ist. Wenn die Berechtigung zum Erstellen oder Löschen von Ressourcengruppen im Abonnement des Pods nicht aktiviert ist, ist diese Automatisierung blockiert. Um diese Situation zu beheben, folgen Sie der Anleitung der Validierung, wie Sie die erforderlichen Berechtigungen über das Microsoft Azure-Portal aktivieren können. Weitere Informationen zu den Berechtigungen, die der Dienst für den Dienstprinzipal benötigt, um die vom Dienst benötigten Vorgänge durchzuführen, finden Sie unter Von Horizon Cloud benötigte Operationen in Ihrem Microsoft Azure-Abonnement.

Für die Zeit von der Bereitstellung der grünen VMs bis zum Abschluss der Migration von blauen VMs 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 gegenwärtigen 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 der Migration zum grünen Build-Out 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 vorgesehene 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 8 Kerne der bestehenden (blauen) Manager-VMs (2 VMs mit je 4 Kernen) plus weitere 8 Kerne für die parallelen zukünftigen Manager-VMs berücksichtigen. 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 Sollkomponenten 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 Sollkomponenten 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 Sollkomponenten 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.