VMware aktualisiert die Horizon Cloud-Softwarekomponenten regelmäßig, um neue Funktionen, Verbesserungen für die Unterstützung von Diensten und Ausfallsicherheit, Verbesserungen bei der Benutzererfahrung und Fehlerkorrekturen zu berücksichtigen. In der Regel aktualisiert VMware wöchentlich die Verwaltungsumgebung in der Cloud und etwa vierteljährlich die in einem bereitgestellten Pod verwendeten Softwarekomponenten. Wenn VMware die in einem bereitgestellten Pod verwendeten Softwarekomponenten aktualisiert, erhöht sich die Manifestnummer für die Software des Pods um eine Zahl. Wenn es Verbesserungen gibt, die für Pod-Wartungs- und Supportvorgänge wichtig sind, stellt VMware ein neues Manifest zur Verfügung, selbst wenn der Zeitpunkt innerhalb des Quartals der vorherigen Manifestversion liegt. Der normale Aktualisierungsvorgang wird durchgeführt, ohne dass Systemausfallzeiten entstehen.

Wichtig: Wenn der Pod bereits in den in der Cloud gehosteten Workspace ONE Access integriert ist und dabei die Linux Connector-Version 2017.12.1.0 verwendet wird, sollten Sie den Connector auf die neuste Version aktualisieren, bevor Sie den Pod aktualisieren. Informationen zur Wahl der Connector-Version, die von dieser Horizon Cloud-Version unterstützt wird, finden Sie in den VMware Product Interoperability Matrixes unter https://www.vmware.com/resources/compatibility/sim/interop_matrix.php. Führen Sie anschließend eine Aktualisierung Ihres vorhandenen Connectors durch, indem Sie die Schritte für die ausgewählte Connector-Version in der VMware Workspace ONE Access-Dokumentation befolgen. Nachdem Sie die Aktualisierung Ihres Connectors abgeschlossen haben, aktualisieren Sie Ihren Pod.

Das Aktualisieren des bereitgestellten Pods bedeutet, dass die aktuellen Infrastrukturkomponenten Ihres Pods entsprechend auf eine höhere Software-Manifest-Ebene verschoben werden. 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.

Sie können die Seite „Kapazität“ verwenden, um zu überprüfen, für welche Pods Aktualisierungen zur Verfügung stehen. Navigieren Sie zu Einstellungen > Kapazität. In der Spalte „Status“ des Pods wird das ausstehende Symbol anstelle des grünen Punktes angezeigt. Die Versionsnummer des Pods ist ein Hyperlink anstatt eines statischen Textes. Wenn sich der Cursor über diese Versionsnummer bewegt, wird eine QuickInfo mit dem Hinweis angezeigt, dass eine Aktualisierung verfügbar ist. Der folgende Screenshot veranschaulicht das im vorhergehenden Satz beschriebene Verhalten.


Horizon Cloud on Microsoft Azure: Screenshot der Seite „Kapazität“ mit einem Pod, für den eine Aktualisierung verfügbar ist. Der grüne Pfeil zeigt auf die angezeigte QuickInfo.

Sie können die Aktualisierungsdetails für einen bestimmten Pod auf der zugehörigen Detailseite sehen. Wenn eine Aktualisierung verfügbar ist, wird auf dem Bildschirm eine Meldung mit einer Beschreibung der Aktualisierung angezeigt.


Horizon Cloud on Microsoft Azure: Screenshot der Detailseite des Pods mit Update-Nachrichten.

Hinweis: Nachdem Sie einen Pod von älteren auf neuere Versionen aktualisiert haben, können Sie die Agent-bezogene Software in den bereits veröffentlichten Images, Farmen und VDI-Desktop-Zuweisungen des Pods auf die gleiche Agent-Versionsebene aktualisieren, die mit der aktualisierten Pod-Version geliefert wird. Die Agent-bezogene Aktualisierung erfolgt in einem von der Pod-Aktualisierung getrennten Prozess. Die Schritte zum Aktualisieren der Agent-bezogenen Software nach dem Aktualisieren des Pods finden Sie unter Aktualisieren der Agent-Software für RDSH-Images in Horizon Cloud, Aktualisieren der Agent-Software für dedizierte VDI-Desktop-Zuweisungen und Aktualisieren der Agent-Software für Images, die von Floating VDI-Desktop-Zuweisungen verwendet werden..

Dieser Horizon Cloud-Pod-Aktualisierungsvorgang entspricht in seinem Muster einer Technik aus der Software-Branchen, die als Blue-Green Deployment (also Blau-Grün-Bereitstellung) bezeichnet wird.


Konzeptionelle Darstellung des Blau-Grün-Aktualisierungsvorgangs.

Die vorhandenen zu aktualisierenden Pod-Komponenten werden als „Blue“-Komponenten bezeichnet. Kurz nachdem VMware ein neues Pod-Manifest veröffentlicht hat, führt das Horizon Service Operations-Team von VMware einige Vorabprüfungen durch und legt dann Ihr Horizon Cloud-Kundenkonto als für die Verwendung der neuen Manifestversion verfügbar fest. Zu dem Zeitpunkt, für den die Einführung dieser neue Manifestversion für Ihr Kundenkonto geplant ist, erstellt der Dienst einen Satz „Green“-Komponenten für den Pod in Ihrem Microsoft Azure-Abonnement. Diese „Green“-Komponenten stellen eine parallele Umgebung zu den vorhandenen „Blue“-Komponenten dar.

Hinweis: Es hält sich nicht der gesamte Pod-Aktualisierungsvorgang exakt an das Blue-Green Deployment-Muster der Softwarebranche. Werden beim Pod-Aktualisierungsvorgang beispielsweise die neueren Instanzen neben den vorhandenen erstellt, dann werden die neueren Instanzen aktiviert und weiterhin ausgeführt, bis die Migration des Pods zu den neueren Instanzen abgeschlossen ist. Nachdem der Bereitsteller validiert hat, dass der Pod erfolgreich auf den neueren Komponenten ausgeführt wird, werden die älteren VMs gelöscht, anstatt im Leerlauf zu bleiben.

End-to-End-Vorgang

Ab dem Zeitpunkt, den das VMware Operations-Team für den Beginn der Verwendung der neuen Manifestversion in Ihrem Kundenkonto festlegt, lautet die End-to-End-Reihenfolge:

  1. Der Dienst erstellt eine Jump-Box-Ressourcengruppe im Pod-Abonnement und stellt eine Jump-Box-VM bereit. Diese Jump-Box-VM koordiniert die Erstellung der „Green“-Komponenten.
  2. Diese „Green“-Komponenten werden neben den „Blue“-Komponenten in denselben Ressourcengruppen erstellt. In der Pod-Management-Ressourcengruppe werden die „Green“-Pod-Manager-VMs und die zugehörigen Artefakte wie Netzwerkkarten und Festplatten erstellt. In den Gateway-bezogenen Ressourcengruppen des Pods werden die „Green“-Unified Access Gateway-VMs und die zugehörigen Artefakte erstellt. Diese „Green“-VMs werden gestartet und weiterhin ausgeführt, bis die gesamte End-to-End-Sequenz abgeschlossen ist. Die Jump-Box-VM und ihre Ressourcengruppe werden gelöscht, wenn die „Green“-Komponenten erfolgreich erstellt und ausgeführt werden.
    Wichtig: Ab diesem Sequenzpunkt wird bis zum letzten Schritt der Sequenz die doppelte Anzahl von VMs ausgeführt: sowohl die „Blue“-VMs als auch die „Green“-VMs. Aus diesem Grund ist es ratsam, den Aktualisierungs-Workflow für den Wechsel zur neuen Pod-Software zu planen, sobald das Benachrichtigungsbanner mit dem Hinweis angezeigt wird, dass eine Aktualisierung verfügbar ist. Zudem sollten Sie den Tag und die Uhrzeit eher früher als später ansetzen.

    Dieser Vorgang verursacht keine Ausfallzeiten, und die parallelen VMs wirken sich nicht auf die Vorgänge des Pods aus. Sofern das System keine Fehler erkennt, die nur in Ihrer Microsoft Azure-Umgebung aufgelöst werden können, sind an dieser Stelle keine Aktionen erforderlich. Wenn der Dienst bei der Bereitstellung der „Green“-Komponenten auf Probleme stößt, erkennt er, ob Sie diese Probleme selbsttätig beheben können. Wenn der Dienst feststellt, dass Sie die Probleme beheben können, wird eine Benachrichtigung in der Verwaltungskonsole angezeigt. 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 erhalten, und sich anschließend an den VMware Support wenden, um den Pod-Aktualisierungsvorgang fortzusetzen. Weitere Informationen zu den Arten von Problemen, die Sie selber beheben können, finden Sie unter Für das Upgrade eines Horizon Cloud-Pods in Microsoft Azure erforderliche Kerne und Abhilfemaßnahmen für typische Pod-Aktualisierungsfehler. Wenn der Dienst feststellt, dass ein Problem durch das VMware Operations-Team behoben werden muss, wird das VMware Operations-Team auf das Problem aufmerksam gemacht. Das Problem wird dann behoben, ohne dass von Ihrer Seite Schritte erforderlich sind.

  3. Auf der Detailseite des Pods wird ein Banner mit dem Hinweis angezeigt, dass eine Aktualisierung verfügbar ist und Sie können den Tag und die Uhrzeit für die Umstellung planen.
    Horizon Cloud on Microsoft Azure: Screenshot der Detailseite des Pods mit Update-Nachrichten.

  4. Als Nächstes müssen Sie das Update planen, damit der Pod von den aktuell aktiven „Blue“-VMs und -Komponenten zu den „Green“-VMs und -Komponenten wechseln kann. Sie planen diese Aktualisierung über die Übersichtsseite des Pods, indem Sie Aktualisierung > Aktualisierungen planen auswählen. Sie legen einen Tag und eine Uhrzeit fest, zu der der Dienst den Wechsel des Pods zu den neuen „Green“-Komponenten durchführen soll. Der Dienst stellt eine Jump-Box-VM bereit, um die Terminplanung im Pod zu konfigurieren, und löscht dann die Jump-Box-VM bis zum geplanten Zeitpunkt des Wechsels.
    Wichtig: Entfernen Sie vor der Aktualisierung 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“.

    Sie bestimmen einen geeigneten Zeitpunkt für die Aktualisierung. In der Regel dauert die Aktualisierung selbst oder die Migration von der vorhandenen Version zur neuen Version etwa zehn Minuten. Dabei hat es sich bewährt, die Aktualisierung für einen Zeitpunkt zu planen, an dem die Umgebung am wenigsten ausgelastet ist. Wenn die Aktualisierung geplant ist, wird oben in der Verwaltungskonsole der geplante Zeitpunkt in einem Banner angezeigt. Sie können die Uhrzeit für die Aktualisierung jederzeit vor dem geplanten Zeitpunkt neu einstellen, wenn die Bedürfnisse Ihres Unternehmens dies erforderlich machen.

    Wichtig: Wenn Sie die Aktualisierung auf der Detailseite des Pods planen, werden Sie nach Datum und Uhrzeit gefragt. Diese Zeit bezieht sich auf die lokale Zeitzone Ihres Browsers.

    Horizon Cloud on Microsoft Azure: Screenshot der Seite „Kapazität“ mit oberem Banner, das die Uhrzeit der geplanten Pod-Aktualisierung anzeigt.

  5. Am festgelegten Tag zur festgelegten Uhrzeit stellt der Dienst erneut eine Jump-Box-VM bereit, um den Wechsel zur Verwendung der „Green“-VMs und -Komponenten für den Pod zu koordinieren. Die „Green“-Komponenten werden zu den aktuellen „Blue“-Komponenten. Der Vorgang dauert zwischen fünf und fünfzehn Minuten, wobei die Durchführung bei Pods länger dauert, die sowohl eine externe als auch eine interne Unified Access Gateway-Konfiguration aufweisen. Der Prozess migriert die Daten und die Konfiguration von der Infrastruktur Ihres vorhandenen und zu aktualisierenden Pods zum neuen Pod.

    Während der Migration finden folgende Einschränkungen Anwendung:

    • Sie können keine Verwaltungsaufgaben auf dem Pod ausführen, auf dem das Update ausgeführt wird.
    • Endbenutzer, die keine Verbindung zu ihren virtuellen Desktops oder Remoteanwendungen haben, die vom aktualisierten Pod bereitgestellt werden, und versuchen, eine Verbindung herzustellen, können dies nicht tun.
    • Endbenutzer mit über den Pod verbundenen Sitzungen werden von ihren aktiven Sitzungen getrennt. Nachdem die Migration abgeschlossen ist, können diese Benutzer erneut eine Verbindung herstellen. Es kommt zu keinem Datenverlust, es sei denn, Sie haben die Option Sofort für das Timeout-Handling in den Farmen und VDI-Desktop-Zuweisungen verwendet.
    Vorsicht: Benutzer mit verbundenen Sitzungen auf Desktops oder Remoteanwendungen, die von Farmen und VDI-Desktop-Zuweisungen bedient werden, die die Einstellung Getrennte Sitzungen abmelden auf Sofort gesetzt haben, werden sofort abgemeldet und diese abgemeldeten Sitzungen werden ebenfalls sofort abgemeldet. Unter diesen Bedingungen geht jede noch nicht abgeschlossene Arbeit des Benutzers verloren.

    Um den Verlust laufender Endbenutzerdaten für dieses Szenario zu vermeiden, passen Sie vor Beginn des Migrationsprozesses 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.

  6. Nachdem alles in die neue Umgebung migriert wurde und der Pod auf den neuen Instanzen erfolgreich ausgeführt wird, löscht das System die „Blue“-VMs aus den Ressourcengruppen des Pods sowie die Jump-Box-Ressourcengruppe und deren Inhalt. Einige Artefakte, 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.

Nach Abschluss des End-to-End-Prozesses

Wenn die Migration zu den „Green“-Komponenten abgeschlossen ist, können Sie Verwaltungsaufgaben auf dem Pod ausfü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. Klicken Sie auf die Nummer der Softwareversion, um die damit verbundenen Versionsinformationen anzuzeigen.

Nach der Aktualisierung

Wichtig: Wenn Ihr konfigurierter Radius-Server im selben VNet bereitgestellt wird, müssen Sie nach der Migration zu den neuen Infrastruktur-Elementen auch die Einstellungen auf Ihrem Radius-Server 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.
Wichtig: 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 Sie die DNS-Zuordnung aktualisieren, funktionieren diese direkten Benutzerverbindungen zwar weiterhin, aber es wird kein Hochverfügbarkeits-Failover für einen hochverfügbarkeitsfähigen Pod durchgeführt, wenn die als aktiver Broker fungierende Manager-VM ausfällt. 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.