Auf dieser Dokumentationsseite werden die wichtigsten Informationen zur Wartung der VMware-Softwarekomponenten beschrieben, aus denen der bereitgestellte Horizon Cloud-Pod besteht.

Kurze Einführung

Die Wartungsaktivitäten des Systems umfassen ein automatisches Update der Softwarekomponenten des Pods, um neue Funktionen, Fixes und Verbesserungen für die Serviceunterstützung und Ausfallsicherheit einzubeziehen.

Um eine Aktualisierung des Pods und der Gateway-Appliances mit einer Ausfallzeit von nahezu Null abzuschließen, verwendet das System die Anzahl der Endbenutzersitzungen. Anhand der Sitzungsanzahl bestimmt das System den optimalen Zeitpunkt für den Abschluss der Aktualisierung, wenn nur eine geringe Anzahl von Benutzern mit aktiven Sitzungen mit der Umgebung verbunden ist.

Die Wartungsaktivität, bei der ein vorhandener Pod auf ein neueres Manifest aktualisiert wird, wird vom System von der Cloud-Ebene aus initiiert und erfolgt an einem vom System festgelegten Tag und zu einer bestimmten Uhrzeit.

Um Ihre Präferenz anzugeben, dass eine solche Systemwartungsaktivität zu einer bestimmten Stunde und an einem bestimmten Wochentag beginnen soll, geben Sie über die Konsole das bevorzugte Wartungsfenster für jeden Pod an.

Ein Pod, für den in der Konsole kein bevorzugtes Wartungsfenster angegeben ist, bedeutet, dass VMware jederzeit eine Wartung für diesen Pod planen kann.

Hinweis: Wie auf dieser Dokumentationsseite beschrieben, hat der Dienst ab Anfang des Kalenderjahres 2022 den Upgrade-Code so erweitert, dass VMware-Angebote, die VMware im Azure Marketplace bereitstellt, programmgesteuert verwendet werden. Wenn bei den Upgrade-Vorabprüfungen festgestellt wird, dass die programmgesteuerte Verwendung dieser VMware-Angebote im Abonnement verhindert wird, müssen Sie die auf dieser Dokumentationsseite beschriebenen Aktionen ausführen.

Wenn beispielsweise der Horizon Cloud-Dienstprinzipal, der mit den für den Pod und seine Gateway-Konfigurationen verwendeten Abonnements verbunden ist, eine benutzerdefinierte Rolle (atypisch) verwendet, stellen Sie bitte sicher, dass diese benutzerdefinierte Rolle diese beiden Berechtigungen enthält. Der API-Code für erweiterte Upgrades basiert auf diesen Berechtigungen, um die Angebotsliste aus dem Marketplace sowie die VMware-Angebote abzurufen. Wenn die benutzerdefinierte Rolle diese beiden Berechtigungen noch nicht enthält, fügen Sie sie zur benutzerdefinierten Rolle hinzu, bevor das Pod- und Gateway-Upgrade durchgeführt wird.

Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/read
Microsoft.MarketplaceOrdering/offertypes/publishers/offers/plans/agreements/write

Wenn die in einem bereitgestellten Pod verwendeten Softwarekomponenten auf eine neue Version aktualisiert werden, erhöht sich die Manifestnummer für den Pod auf eine höhere Versionsnummer, z. B. 2632.0. Wenn es Verbesserungen gibt, die für die Wartbarkeit des Pods und den Supportbetrieb als wichtig erachtet werden, kann VMware ein neues Manifest erstellen, das eine Punktversion ist, z. B. 2632.1. Die Konsole zeigt das Manifest eines Pods auf der Seite „Kapazität“ an.

Wichtige Informationen zum Aktualisieren eines Pods aus Manifesten vor 3328

Ab Februar 2022 folgen die Netzwerkkarten (NICs) für die Pod-Manager-VMs demselben Infrastruktur-Designmuster wie die Netzwerkkarten für die Unified Access Gateway-VMs.

Bei neuen Pod-Bereitstellungen, die zu diesem Zeitpunkt beginnen, und bei Pod-Aktualisierungen aus Manifesten vor Manifest 3328 instanziiert der Bereitsteller alle erforderlichen Netzwerke, die für die Ausführung des Pods und für nachfolgende Aktualisierungen im Laufe der Zeit erforderlich sind. Die Ressourcengruppe des Pods verfügt jetzt über 8 Netzwerkkarten:

  • 4 Netzwerkkarten, die 4 IP-Adressen aus dem Management-Subnetz des Pods reservieren
  • 4 Netzwerkkarten, die 4 IP-Adressen aus dem primären VM-Subnetz (früher als Mandantensubnetz bezeichnet) des Pods reservieren.

Diese 8 Pod-Netzwerkkarten bleiben bestehen und reservieren die ihnen zugewiesenen IP-Adressen während der gesamten Lebensdauer des Pods.

Dieses Design unterstützt schnellere und widerstandsfähigere Pod-Updates. Vor diesem Design mussten für eine Pod-Aktualisierung neue Netzwerkkarten als Teil des grünen Pod-Build-Outs erstellt und IP-Adressen für diese Netzwerkkarten aus den Subnetzen des Pods zum Zeitpunkt der Aktualisierung abgerufen werden. Bei diesem Design konnten Zeitüberschreitungen in Azure auftreten und den Updatevorgang unterbrechen.

Bei diesem Design, bei dem der Bereitsteller alle erforderlichen Netzwerke im Voraus instanziiert, bleiben die Netzwerkkarten und ihre IP-Adressen aus den Management- und VM-Subnetzen (Mandanten) erhalten und können bei nachfolgenden Pod-Updates verwendet werden. Dieses Design stimmt mit dem Muster überein, das für die Unified Access Gateway -Instanzen verwendet wird.

Wenn Ihr Pod noch nicht über die 8 Netzwerkkarten in der Ressourcengruppe des Pods verfügt und die Aktualisierung des Pods auf Manifest 3328 oder höher geplant ist, müssen Sie diese Aktionen durchführen.

Bevor Sie diesen Pod aktualisieren, stellen Sie sicher, dass die IP-Adressen des Management-Subnetzes des Pods und die IP-Adressen des primären VM-Subnetzes (Mandanten) nur von Elementen übernommen werden, die von Horizon Cloud on Microsoft Azure erstellt und konfiguriert werden
  • Management-Subnetz – Nur die spezifischen Netzwerkkarten der Horizon Cloud on Microsoft Azure-Bereitstellung, die der Pod-Bereitsteller erstellt und konfiguriert hat, sollten IP-Adressen aus dem Management-Subnetz des Pods verwenden. Bei diesen Netzwerkkarten handelt es sich um die Netzwerkkarten des Pod-Managers und die Netzwerkkarten der Unified Access Gateway-Instanz des Pods. An das Management-Subnetz des Pods dürfen keine Ressourcen oder Elemente angehängt sein, die nicht vom Pod bereitgestellt werden, und es dürfen keine IP-Adressen aus diesem Subnetz verwendet werden.
  • Mandantensubnetz – Nur die spezifischen Netzwerkkarten und Load Balancer der Horizon Cloud on Microsoft Azure-Bereitstellung, die der Pod-Bereitsteller erstellt und konfiguriert, sollten IP-Adressen aus dem Mandantensubnetz des Pods verwenden. An das Mandantensubnetz des Pods dürfen keine Ressourcen oder Elemente angehängt sein, die nicht zur Bereitstellung gehören, und es dürfen keine IP-Adressen aus diesem Subnetz bezogen werden.

Im Bereitstellungshandbuch wird genau angegeben, dass an die vom Pod verwendeten Subnetze außer den Ressourcen der Pod-Bereitstellung keine weiteren Ressourcen angehängt sein sollten. Wenn Sie manuell Ressourcen erstellt und diesen zusätzlichen Ressourcen IP-Adressen aus dem Management- oder Mandantensubnetz des Pods zugewiesen haben, müssen Sie diese IP-Adressen aus diesen Ressourcen entfernen, bevor das Pod-Update ausgeführt wird. Andernfalls schlägt das Pod-Update fehl und Sie müssen den VMware Support anfordern.

Stellen Sie sicher, dass Sie nach dem Pod-Update alle IP-Adressen, die von den vom Bereitsteller erstellten Netzwerkkarten in der Ressourcengruppe des Pods reserviert wurden, zu den Firewall-Regeln hinzufügen, die Sie vor dem Update eingerichtet haben
Möglicherweise haben Sie bereits Firewall-Regeln, die den Datenverkehr von den IP-Adressen der Netzwerkkarten der Pod-Manager-VMs regeln. Damit die Verkehrskommunikation nach dem Pod-Update genauso funktioniert wie vor dem Update, müssen Sie sicherstellen, dass alle 8 IP-Adressen, die von den Netzwerkkarten in der Ressourcengruppe des Pods reserviert wurden, nach dem Update in Ihren Firewall-Regeln berücksichtigt werden.

Wissenswertes zur Pod-Wartung

Die Wartung der VMware-Softwarekomponenten, aus denen der bereitgestellte Horizon Cloud-Pod besteht, ist ein notwendiger und erforderlicher Vorgang, um den Zustand und die Stabilität der virtuellen Desktops und Anwendungen zu erhalten, die von diesem Pod bereitgestellt werden. Wie im KB-Artikel VMware Horizon Cloud Service – Additional Service Details (87894) beschrieben, ist VMware für die Softwarekomponenten verantwortlich, die sich auf dem Pod befinden und von der Steuerungsebene auf diesen Pod heruntergeladen werden. In der PDF-Datei VMware Horizon Cloud Service – Additional Service Details, die diesem KB-Artikel beigefügt ist, wird Folgendes beschrieben:

  • Die Rollen und Verantwortlichkeiten von VMware in Bezug auf die Änderungsmanagementverfahren zur Aufrechterhaltung des Zustands der Softwarekomponenten, die in den Pod heruntergeladen werden. Zu den Wartungsaktivitäten gehört das Aktualisieren der Softwarekomponenten des Pods.
  • Die Rolle und die Verantwortlichkeiten des (Ihres) Kunden in Bezug auf die Änderungsmanagementverfahren, einschließlich der Zusammenarbeit mit VMware, wenn eine geplante oder Notfallwartung erforderlich ist.

Das Dokument VMware Horizon Cloud Service – Additional Service Details enthält eine Definition der geplanten Wartung, der Wartungsfenster und der Notfallwartung. Weitere Informationen dazu finden Sie im Dokument. Bei Widersprüchen zwischen dem Inhalt dieser Dokumentationsseite und dem Inhalt des Dokuments VMware Horizon Cloud Service – Additional Service Details hat das Dokument VMware Horizon Cloud Service – Additional Service Details Vorrang.

Achtung: Bevor der Pod aktualisiert wird, müssen Sie sicherstellen, dass die Image-VMs, Farm-VMs und VDI-Desktop-VMs des Pods alle über den neuesten Agenten verfügen, der für den Pod verfügbar ist. Wenn Sie sie vor der Pod-Aktualisierung nicht auf den neuesten Agenten aktualisieren, laufen auf ihnen nach der Pod-Aktualisierung möglicherweise inkompatible Agentenversionen, wodurch der Pod in einen nicht unterstützten Zustand versetzt wird. Wie können Sie feststellen, ob Sie einen der Agenten aktualisieren müssen? Prüfen Sie in der Konsole, ob neben einem Image oder einer Zuweisung blaue Punkte zu sehen sind. Wenn Sie blaue Punkte sehen, müssen Sie dafür sorgen, dass alle blauen Punkte vor der Pod-Aktualisierung von der Konsole verschwinden. Siehe Horizon Cloud-Pod-Aktualisierungen – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung.

Festlegen des bevorzugten Wartungsfensters des Pods

Um anzugeben, dass Sie es vorziehen, dass jede Wartungsaktivität auf Ihrem Pod zu einer bestimmten Uhrzeit und an einem bestimmten Wochentag beginnt, geben Sie in der Konsole das sogenannte bevorzugte Wartungsfenster für diesen Pod an. Navigieren Sie auf der Seite „Kapazität“ zur Registerkarte Wartung auf der Detailseite des Pods. Suchen Sie nach der Beschriftung Bevorzugter Wartungszeitpunkt und folgen Sie dann den Bedienelementen auf dem Bildschirm, um einen Wochentagsnamen und eine Uhrzeit (UTC) an diesem Tag auszuwählen. Sie können nur aus den angezeigten, vom System vordefinierten Voreinstellungen wählen.

Geben Sie die bevorzugte Wartungszeit für jeden Pod separat auf der Detailseite jedes Pods in der Konsole an.

Hinweis: Ein Pod, für den in der Konsole kein bevorzugtes Wartungsfenster angegeben ist, bedeutet, dass Sie VMware berechtigen, jederzeit eine Wartung für diesen Pod zu planen.

Das System liest den Wochentag und die Uhrzeit, die Sie in der Konsole angeben, und bezieht diese Daten in seinen Planungsalgorithmus ein. Wenn ein neues Pod-Manifest als Standard in der Cloud-Ebene festgelegt wird, berechnet der Scheduler des Systems den tatsächlichen Aktualisierungstag und die Uhrzeit, zu der die Aktualisierung auf jedem Pod in Ihrer Pod-Flotte erfolgen kann. Obwohl das System sein Bestes tut, um die bevorzugten Wartungsstartzeiten, die auf der Registerkarte Wartung des Pods angegeben sind, zu berücksichtigen, kann nicht garantiert werden, dass das System in der Lage ist, diese bevorzugte Wartungsstartzeit für einen bestimmten Aktualisierungsvorgang zu berücksichtigen.

Zu diesem Zeitpunkt weist der Scheduler des Systems vier (4) Stunden für die Dauer der Wartungstätigkeit zu. Die typische Pod-Aktualisierung dauert weniger als diese zugewiesene Zeitspanne.

Wartungswarnungen und -benachrichtigungen

Das System alarmiert und benachrichtigt die Administratoren Ihrer Mandantenumgebung, wenn das System ein bestimmtes Kalenderdatum und eine bestimmte Uhrzeit für die Wartung eines bestimmten Pods eingeplant hat. Zu diesen Warnungen und Benachrichtigungen gehören die folgenden:

Innerhalb der Konsole
  • Ein dauerhaftes Banner am oberen Rand der Konsole. Die Zeit im Banner ist die lokale Wartungszeit in der Zeitzone Ihres Browsers, in der Sie die Konsole anzeigen. Der folgende Screenshot zeigt ein Beispiel, bei dem die Aktualisierung des Pods für den 7. Juli 2020 um 16 Uhr Eastern Time in den USA geplant ist. Verwenden Sie die Schaltfläche Ansicht, um auf die Detailseite des Pods zu klicken und weitere Informationen über die geplante Wartung auf der Registerkarte Wartung des Pods anzuzeigen.
    Screenshot-Beispiel des Banners in der Konsole, das Informationen über die geplante Wartung eines Pods liefert
  • Auf der Registerkarte Überwachungsprotokolle des Pods und auf der Konsole Aktivität > Überwachungsprotokoll wird in einem Überwachungsprotokoll angegeben, dass ein Upgrade des Pods von VMware Operations geplant ist. Die Audit-Protokollzeile enthält die UUID des Pods.
  • Auf der Registerkarte Wartung des Pods werden im Abschnitt Geplante Wartung Informationen über die geplante Wartung angezeigt.
E-Mails
Das System sendet E-Mails über die Wartung des Pods an die Administratoren Ihrer Mandantenumgebung, die in den Einstellungen der Konsole Allgemeine Einstellungen > My VMware-Konten angegeben sind. Eine der E-Mails wird versendet, wenn das System das spezifische Kalenderdatum und die Uhrzeit für die geplante Wartung festgelegt hat. Beispiele für solche E-Mails sind regelmäßige Erinnerungen in den Tagen und Wochen vor dem geplanten Datum und der geplanten Uhrzeit, sowie wenn die Wartungsaktivität begonnen hat und wenn sie abgeschlossen ist.
Hinweis: Wenn Sie ein geplantes Wartungsdatum und eine geplante Wartungszeit verschieben möchten, müssen Sie sich an den VMware Support wenden.

System-Vorabprüfungen vor der Durchführung der Pod-Wartung

Wenn Sie eine Benachrichtigungs-E-Mail erhalten, die besagt, dass ein Pod Fehler bei der Pod-Aktualisierung aufweist, oder Sie sehen, dass die Konsole Fehler bei der Pod-Aktualisierung für einen Pod meldet, müssen Sie Maßnahmen ergreifen, um die Situation zu beheben. Befolgen Sie in diesem Fall die Bildschirmanweisungen der Konsole oder die Anweisungen in der E-Mail. Die übliche Lösung für solche Fehler besteht darin, dass Sie im Microsoft Azure-Portal im dortigen Abonnement des Pods Schritte durchführen. Weitere Informationen zu Abhilfemaßnahmen bei typischen Pod-Aktualisierungsfehlern finden Sie unter Horizon Cloud-Pods – Abhilfe bei häufigen Vorabprüfungsfehlern.

Was ist der Zweck dieser Vorabkontrollen? Die Wartungsaktivität für eine Pod-Aktualisierung findet in den Microsoft Azure-Abonnement- und Ressourcengruppen des Pods statt. Kurz bevor das System ein bestimmtes Kalenderdatum und eine bestimmte Uhrzeit für eine bestimmte Aktualisierung auf einem bestimmten Pod einplant, führt das System eine Vorabprüfung durch, um festzustellen, ob Bedingungen vorliegen, die eine erfolgreiche Aktualisierung bei einem Pod verhindern würden. Das System prüft dabei beispielsweise, ob Ihr Microsoft Azure-Abonnement über genügend vCores der entsprechenden VM-Serie verfügt, um die Anforderungen der Aktualisierung zu erfüllen. Wenn eine der Vorabprüfungen fehlschlägt und die Behebung des dabei festgestellten Fehlers Ihr Eingreifen erfordert, tritt Folgendes ein:

  • Sie erhalten eine Benachrichtigungs-E-Mail, die Sie auf diesen Umstand hinweist und Details zu den erforderlichen Maßnahmen zur Behebung des Fehlers enthält.
  • Die Konsole zeigt eine visuelle Warnung an, dass Ihre Maßnahmen zur Behebung der Vorabprüfungsfehler für diesen Pod erforderlich sind.
Wichtig: Wenn Sie Benachrichtigungen über Pod-Upgrade-Fehler 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.

Pod-Aktualisierungen – Überblick

Wenn es sich bei der Wartungsaktivität um die Aktualisierung eines Pods auf eine neuere Manifestversion handelt, verschiebt das System die aktuellen Infrastrukturkomponenten des Pods entsprechend auf eine höhere Software-Manifeststufe. Die Infrastrukturkomponenten sind in erster Linie die Pod-Manager-VMs und alle Unified Access Gateway-VMs, die für den Pod konfiguriert sind. Beispielsweise kann ein Pod-Update Aktualisierungen für die Pod-Verwaltungssoftware oder für die Unified Access Gateway-Software oder für beides enthalten.

Der Pod-Aktualisierungsvorgang entspricht in seinem Muster einer Technik aus der Software-Branche, die als Blue-Green Deployment (also Blau-Grün-Bereitstellung) bezeichnet wird. Die vorhandenen zu aktualisierenden Pod-Komponenten werden als „Blue“-Komponenten bezeichnet.


Konzeptionelle Darstellung des Blau-Grün-Aktualisierungsvorgangs.

Obwohl die Pod-Aktualisierung in den meisten Punkten einem branchenüblichen blau-grünen Muster folgt, gibt es einige kleinere Unterschiede zu einer kanonischen blau-grünen Aktualisierung. Die Pod-Aktualisierung dupliziert nicht zu 100 % jede einzelne blaue Ressource im grünen Build-Out. Einige der vorhandenen blauen Ressourcen werden im neuen grünen Build-Out wiederverwendet, z. B. die NICs für die Unified Access Gateway-Instanzen. Ein weiterer Unterschied besteht darin, dass beim Pod-Aktualisierungsvorgang beispielsweise die neueren Instanzen neben den vorhandenen erstellt werden. Dann werden die neueren Instanzen aktiviert und weiterhin ausgeführt, bis die Migration des Pods zu den neueren Instanzen abgeschlossen ist. Außerdem werden die älteren blauen VMs aus der Ressourcengruppe gelöscht, nachdem das System den Pod auf den grünen Build-Out migriert und überprüft hat, dass der Pod erfolgreich mit der neuen Manifestversion ausgeführt wird. (Ein kanonisches Blau-Grün-Update würde typischerweise die älteren blauen Artefakte nach dem Wechsel zu Grün beibehalten und die älteren in einem Ruhezustand halten.)

  • Die vorhandenen, zu aktualisierenden Pod-Komponenten – wie die Pod-Manager-VMs und die Unified Access Gateway-VMs – werden als die blauen Komponenten betrachtet.
  • Der Dienst erstellt automatisch den erforderlichen grünen Satz von Komponenten für den Pod in Ihrem Microsoft Azure-Abonnement – neue grüne Pod-Manager-VMs, Unified Access Gateway-VMs und die Gateway-Connector-VM (wenn Ihr externes Gateway in einem eigenen VNet bereitgestellt wird).
  • Die neu erstellten Komponenten im grünen Build-Out werden neben den blauen Komponenten in denselben Ressourcengruppen erstellt.
  • Der Prozess der Erstellung des grünen Build-Outs verursacht keine Ausfallzeiten oder Datenverluste, und die parallelen VMs beeinträchtigen den Betrieb des Pods nicht.
  • Das grüne Set ist eine parallele Umgebung, die auf die geplante Wartungsaktivität wartet, die den Wechsel von der blauen zur grünen Umgebung ermöglicht. Die Art und Weise, wie das System die Wartungstätigkeit an einem Pod terminiert, wurde in den vorangegangenen Abschnitten behandelt.
  • Diese grünen VMs werden gestartet und laufen weiter, bis die geplante Wartungsaktivität abgeschlossen ist, also die Wartungsaktivität, die die blauen zu den grünen VMs migriert.
  • Nachdem die geplante Wartungsaktivität für die Migration zum grünen Build-Out abgeschlossen ist und der Pod erfolgreich auf den neuen Instanzen ausgeführt wird, löscht das System die blauen VMs aus den Ressourcengruppen des Pods. Einige Ressourcen, wie z. B. die Netzwerkkarten für die vorherigen Unified Access Gateway-Instanzen, werden nicht gelöscht, damit Konfigurationswerte erhalten bleiben können, die für das nächste Pod-Update erforderlich sind.
Hinweis: Sie müssen vermeiden, im Microsoft Azure-Portal und im Abonnement des Pods Änderungen vorzunehmen, die sich auf den Aufbau der grünen Komponenten des Systems oder auf die Pod-Aktualisierungs- und Wartungsprozesse des Systems auswirken.

Reihenfolge der Wartungsaktivitäten

Diese Sequenz beschreibt die Migration zum grünen Build-Out – den Wechsel von Blau zu Grün in der Pod-Aktualisierung.

  1. Das System prüft das bevorzugte Wartungsfenster des Pods, das Sie in der Konsole angegeben haben, um diese Informationen im Algorithmus des Zeitplaners zu verwenden und das tatsächliche Kalenderdatum und die Uhrzeit für die Wartungsaktivität des Pods zu planen.
  2. Der Zeitplaner des Systems wählt das tatsächliche Kalenderdatum und die Uhrzeit, zu der die Wartung stattfinden soll. Wie in den vorangegangenen Abschnitten beschrieben, zeigt die Konsole das geplante Datum und die Uhrzeit an und es wird eine E-Mail an die Administratoren des Mandanten gesendet.
  3. Wichtig: Bevor die geplante Wartung läuft:
    • Stellen Sie sicher, dass die Image-VMs, Farm-VMs und VDI-Desktop-VMs des Pods alle über den neuesten Agenten verfügen, der für den Pod verfügbar ist. Wenn Sie blaue Punkte in der Konsole sehen, ist es das Ziel, alle blauen Punkte vor der Pod-Aktualisierung von der Konsole verschwinden zu lassen. Siehe Horizon Cloud-Pod-Aktualisierungen – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung
    • Entfernen Sie alle gegebenenfalls in Microsoft Azure festgelegten Verwaltungssperren für die virtuellen Maschinen (VMs) des Pods. Alle VMs mit Namen, die einen Teil wie vmw-hcs-podID aufweisen, wobei podID der ID-Wert des Pods ist, gehören zum Pod. Microsoft Azure bietet die Möglichkeit, das Microsoft Azure-Portal zum Sperren von Ressourcen zu verwenden, um Änderungen an diesen zu verhindern. Solche Verwaltungssperren können auf eine gesamte Ressourcengruppe oder auf einzelne Ressourcen angewendet werden. Wenn Sie oder Ihre Organisation Verwaltungssperren für die VMs des Pods festgelegt haben, müssen diese Sperren vor der Aktualisierung entfernt werden. Andernfalls kann die Aktualisierung nicht erfolgreich abgeschlossen werden. Sie finden den ID-Wert des Pods auf der Detailseite des Pods auf der Seite „Kapazität“.

    Wenn es die Anforderungen Ihres Unternehmens erfordern, können Sie ein anderes geplantes Datum für die Wartung anfordern, indem Sie sich jederzeit vor der geplanten Wartungszeit an den VMware Support wenden.

    Wichtig: Die geplante Zeit, die in der Konsole angezeigt wird, entspricht der lokalen Zeitzone Ihres Browsers.
  4. Zum geplanten Wartungszeitpunkt startet der Dienst die Aktualisierungsaktivität. Der vollständige Vorgang dauert bei Pods mit externer und interner Unified Access Gateway-Konfiguration in der Regel zwischen 20 und 30 Minuten von Anfang bis Ende.
    Hinweis: Während der 20- bis 30-minütigen Dauer des Vorgangs verhindert die Konsole, dass Sie auf dem Pod, der aktualisiert wird, administrative Aufgaben durchführen. So ist beispielsweise die Aktion Bearbeite auf der Pod-Detailseite zum Ändern der Eigenschaften dieses Pods nicht verfügbar, bis die Pod-Manager-Appliances die Cloudebene benachrichtigen, dass die Aktualisierung abgeschlossen ist.
    Hinweise zu Endbenutzersitzungen und zur Aktualisierungsaktivität auf den Unified Access Gateway-Appliances
    Um eine Ausfallzeit von nahezu Null für Endbenutzersitzungen innerhalb der Gesamtdauer der Wartungsaktivität zu erreichen, verwendet das System die Anzahl der Endbenutzersitzungen auf den Appliances, um den optimalen Zeitpunkt für die Fertigstellung der Aktualisierung dieser Appliances zu bestimmen.

    Der Zeitpunkt der Fertigstellung wird so optimiert, dass er zu einem Zeitpunkt liegt, zu dem nur eine geringe Anzahl von Benutzern mit aktiven Sitzungen mit der Umgebung verbunden ist.

    In diesem Zeitfenster, das fast bei Null liegt, werden die Sitzungen der Endbenutzer mit aktiven Sitzungen getrennt. Nach einigen Minuten können diese Benutzer die Verbindung dann wieder herstellen.

    Es kommt zu keinem Datenverlust, außer in dem Szenario, in dem Sie die Option Sofort für die Behandlung der Zeitüberschreitung in den Farmen und VDI-Desktop-Zuweisungen eingestellt haben. In diesem Szenario werden Benutzer mit aktiven Sitzungen, bei denen Sie die Option Sofort für die Behandlung der Zeitüberschreitung verwendet haben, sofort getrennt, und diese Sitzungen werden entsprechend dieser Einstellung ebenfalls sofort abgemeldet. Unter diesen Bedingungen geht jede noch nicht abgeschlossene Arbeit des Benutzers verloren. Um den Verlust laufender Endbenutzerdaten in diesem Szenario zu vermeiden, passen Sie vor Beginn der Wartungsaktivität die Einstellung Getrennte Sitzungen abmelden in den Farmen und VDI-Desktop-Zuweisungen auf einen Zeitwert an, der diesen Benutzern Zeit gibt, ihre Arbeit zu speichern. Nachdem das Update abgeschlossen ist, können Sie die Einstellung wieder ändern.

    Wenn ein Endbenutzer, der noch nicht mit seinem virtuellen Desktop oder einer Remoteanwendung des Pods verbunden ist und versucht, eine Verbindung herzustellen, kann er dies auch während dieses nahezu Null-Zeitfensters nicht tun, bis der Vorgang abgeschlossen ist.

  5. Nach Abschluss der Wartungsaktivität löscht das System die nicht mehr benötigten Komponenten, z. B. die blauen Komponenten, die im grünen Build-Out nicht wiederverwendet werden, wie z. B. die Pod-Manager-VMs und Unified Access Gateway-VMs. Einige Artefakte, wie z. B. bestimmte Netzwerkkarten für die Pod-Manager-Instanzen und Unified Access Gateway-Instanzen, werden nicht gelöscht, damit Konfigurationswerte erhalten bleiben können, die für die nächste Wartung benötigt werden.

Nach der Wartungsaktivität

Wenn die Wartungsaktivität beendet ist, können Sie administrative Aufgaben auf dem Pod durchführen. Um die Softwareversion anzuzeigen, die ein Pod derzeit ausführt, wählen Sie Einstellungen > Kapazität aus und klicken Sie auf den Pod, um die Seite „Übersicht“ zu öffnen. Auf der Seite wird die derzeit ausgeführte Software-Version angezeigt.

  • Stellen Sie nach einer Pod-Aktualisierung sicher, dass die Agenten in allen vorhandenen Images, Farmen und VDI-Zuweisungen auf die neueste verfügbare Version aktualisiert werden. Wenn die installierten Agenten dieser VMs nicht aktualisiert werden, befindet sich der Pod in einer nicht unterstützten Konfiguration. Der Wartungsprozess aktualisiert diese installierten Agenten nicht automatisch. Wenn Sie in der Konsole blaue Punkte für Ihre Images oder Zuweisungen sehen, bedeutet dies, dass die Agenten aktualisiert werden müssen. Horizon Cloud-Pod-Aktualisierungen – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung.
  • Wenn dieses Update von einem Manifest vor Manifest 3328 stammt, stellen Sie nach der Aktualisierung des Pods sicher, dass Sie alle IP-Adressen der vom Bereitsteller erstellten Netzwerkkarten, die sich in der Ressourcengruppe des Pods befinden, zu Ihren Firewallregeln hinzufügen. Möglicherweise haben Sie bereits Firewall-Regeln, die den Datenverkehr von den IP-Adressen der Netzwerkkarten der Pod-Manager-VMs regeln. Damit die Verkehrskommunikation nach diesem Pod-Update und nachfolgenden Updates genauso funktioniert wie vor diesem Update, müssen Sie sicherstellen, dass alle 8 IP-Adressen, die von den Netzwerkkarten in der Ressourcengruppe des Pods reserviert wurden, nach diesem Update in Ihren Firewallregeln berücksichtigt werden.
  • Wenn Ihr konfigurierter Zwei-Faktor-Authentifizierungsserver im selben VNet bereitgestellt wird, müssen Sie nach der Wartungsaktivität auch die Einstellungen auf Ihrem Zwei-Faktor-Authentifizierungsserver aktualisieren, damit die neuen privaten IP-Adressen für die neuen internen Unified Access Gateway-VMs akzeptiert werden. Dies ist eine einmalige Anforderung für die erste Aktualisierung auf dem Pod und muss für zukünftige Aktualisierungen dieses Pods nicht wiederholt werden. Weitere Informationen finden Sie unter Aktualisieren Ihres Zwei-Faktor-Authentifizierungssystems mit den erforderlichen Gateway-Informationen.
  • Ab der vierteljährlichen Dienstversion vom September 2019 wird die Pod-Architektur aktualisiert, sodass die Hochverfügbarkeit unterstützt wird. Selbst wenn die Hochverfügbarkeitsfunktion nicht aktiviert ist, enthält die neue, hochverfügbarkeitsfähige Architektur einen Lastenausgleichsdienst („Load Balancer“) von Microsoft Azure vor der Manager VM des Pods. Nachdem Sie Ihren Pod auf Manifestversion 1600 aktualisiert und anschließend für Direktverbindungen konfiguriert haben, sollten Sie Ihre DNS-Einstellungen neu zuordnen, sodass sie auf die Azure Load Balancer-IP-Adresse von Pod Manager verweisen, die von nun an auf der Detailseite des aktualisierten Pods angezeigt wird. Bis zur Aktualisierung der DNS-Zuordnung – selbst wenn diese direkten Benutzerverbindungen weiterhin funktionieren – verfügen diese Verbindungen bei einem Ausfall der aktiven Pod-Manager-VM nicht über HA-Failover, für das ein HA-fähiger Pod ausgelegt ist. Für diesen Anwendungsfall ordnen Sie der IP-Adresse im Feld IP-Adresse des Lastenausgleichsdienstes für den Pod Manager einen FQDN zu, der auf der Detailseite des Pods angezeigt wird, wie unter Konfigurieren von SSL-Zertifikaten direkt auf den Pod-Manager-VMs, z. B. beim Integrieren der Workspace ONE Access Connector Appliance mit dem Horizon Cloud-Pod in Microsoft Azure, damit der Connector Verbindungen mit den Pod-Manager-VMs vertrauen kann beschrieben. Vor der Pod-Manifestversion 1600 war diese IP-Adresse diejenige, die der Netzwerkkarte der Manager-VM des Pods im Mandantensubnetz zugewiesen wurde. Ab Pod-Manifestversion 1600 oder höher ist die zuzuordnende IP-Adresse des Pods die die private IP-Adresse des Microsoft Azure Load Balancers, der für die Manager-VMs des Pods verwendet wird. Wenn Sie für vorhandene Pods, die auf die Manifestversion dieser Version aktualisiert werden, einen DNS-Namen so konfiguriert hatten, dass er auf die IP-Adresse der Mandanten-Appliance für einen Pod des Manifests 1493.1 oder früher verweist, sollten Sie Ihre DNS-Einstellungen neu zuordnen, sodass sie auf die IP-Adresse verweisen, die unter IP-Adresse des Lastenausgleichsdienstes für den Pod Manager auf der Detailseite des aktualisierten Pods angezeigt wird.
  • Vor dem Manifest 2474.x überprüfte das System die registrierten Active Directory-Server nicht auf Zeitversatz. Mit 2474.x wurde eine Überprüfung des Zeitversatzes eingeführt. Wenn Ihre registrierten Active Directory-Server jetzt Probleme mit der Zeitsynchronisation haben (clockSkew > 4 minutes), wird diese Systemvalidierung auf dem Pod gestartet, wenn der Pod auf 2474.x oder höher aktualisiert wird. Dies führt dazu, dass die Active Directory-Servererkennung möglicherweise fehlschlägt, bis Sie das Problem mit dem Abweichung der Uhr beheben, und die fehlerhafte Erkennung wirkt sich auf die Desktop-Verbindungsanforderungen des Endbenutzers zu diesem Pod aus.