VMware aktualisiert regelmäßig die Softwarekomponenten von Horizon Cloud, um neue Funktionen einzubinden und Fehler zu beheben. In der Regel aktualisiert VMware wöchentlich die Verwaltungsumgebung in der Cloud und etwa vierteljährlich die in einem bereitgestellten Pod verwendeten Softwarekomponenten. Der normale Aktualisierungsvorgang wird durchgeführt, ohne dass Systemausfallzeiten entstehen.

Wichtig: Wenn der Pod bereits mit dem in der Cloud gehosteten VMware Identity Manager™ integriert ist und Sie den Linux Connector Version 2017.12.1.0 verwenden, empfiehlt es sich, dass Sie den Connector auf die neuste Version aktualisieren, bevor Sie den Pod aktualisieren. Informationen zur 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 die Schritte unter Vorbereiten des Upgrades von VMware Identity Manager Connector aus. Führen Sie dann ein Upgrade des Pods durch.

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-VM 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 auf einen Blick zu sehen, für welche Pods Updates zur Verfügung stehen. Navigieren Sie zu Einstellungen > Kapazität. Ein visueller Indikator erscheint neben den Pods, für die Updates verfügbar sind. Wenn Sie den Mauszeiger über die Statusanzeige bewegen, zeigt ein Popup-Fenster zusätzliche Details an.

Der folgende Screenshot zeigt die Platzierung des verfügbaren Update-Indikators, wenn er in der Ansicht „Speicherort“ der Seite „Kapazität“ angezeigt wird.


Horizon Cloud auf Microsoft Azure: Screenshot der Seite „Kapazität“ mit einem Pod, für den ein Update verfügbar ist. Der grüne Pfeil zeigt auf den visuellen Indikator.

Sie können die Update-Details für einen bestimmten Pod anzeigen, indem Sie Einstellungen > Kapazität auswählen und auf den Pod klicken, um die Übersichtsseite zu öffnen. Wenn ein Update verfügbar ist, erscheint eine Meldung auf dem Bildschirm, die im Eintrag Versionsnr. das Update beschreibt. Die angezeigte Versionsnummer entspricht der Version des Software-Manifests des Pods.


Horizon Cloud auf Microsoft Azure: Screenshot der Detailseite des Pods mit Update-Nachrichten und grünen Pfeilen, die darauf zeigen.

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, 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 Upgrade-Vorgang für Horizon Cloud-Pods entspricht in seinem Muster einer Technik aus der Software-Branche, die als Blue-Green Deployment (also Blau-Grün-Bereitstellung) bezeichnet wird. Die vorhandenen Pod-Komponenten, für die ein Upgrade durchzuführen ist, werden als „Blue“-Komponenten bezeichnet. Kurz nachdem VMware ein neues Pod-Manifest veröffentlicht hat, führt das VMware Operations-Team 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, das Upgrade für den Wechsel zur neuen Pod-Software zu planen, sobald das Benachrichtigungs-Banner angezeigt wird, das besagt, dass das Upgrade für den Wechsel bereit ist, und den Tag und die Uhrzeit eher früher als später anzusetzen.

    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 Pod in Microsoft Azure erforderliche Kerne und Abhilfemaßnahmen für typische Pod-Upgrade-Fehler. 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. In der Verwaltungskonsole wird ein Benachrichtigungs-Banner angezeigt, das Ihnen mitteilt, dass ein Upgrade verfügbar ist. Sie können den Tag und die Uhrzeit für den Umstieg planen. Der folgende Screenshot ist ein Beispiel dafür, was auf der Seite „Kapazität“ angezeigt wird.
    Kapazitätsseite mit Hinweis, dass eine aktualisierte Version für einen Pod verfügbar ist

  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 Aktualisieren > Zeitplan 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, zeigt die Verwaltungskonsole den geplanten Zeitpunkt in einem Banner oben an. 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 dem Upgrade

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 dieser Version wird die Pod-Architektur aktualisiert, um die Hochverfügbarkeit zu unterstützen. Nachdem Sie Ihren Pod auf Manifestversion 1600 aktualisiert und anschließend die Hochverfügbarkeit aktiviert haben, sollten Sie Ihre DNS-Einstellungen neu zuordnen, um auf die neue IP-Adresse der Mandanten-Appliance zu verweisen, die auf der Detailseite des aktualisierten Pod angezeigt wird. Bis Sie die DNS-Zuordnung aktualisieren, funktionieren die direkten Benutzerverbindungen zwar weiterhin, aber es wird kein Hochverfügbarkeits-Failover 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 der Mandanten-Appliance einen FQDN zu, der auf der Detailseite des Pods angezeigt wird, wie in Hochladen von SSL-Zertifikaten auf einen Horizon Cloud-Pod für direkte Verbindungen beschrieben. Vor dieser Version war diese IP diejenige, die der Netzwerkkarte der Manager-VM des Pods im Mandanten-Subnetz zugewiesen wurde. Ab dieser Version ist für Pods auf Manifest-Version 1600 oder höher die IP-Adresse der Mandanten-Appliance des Pods die private IP-Adresse des Lastausgleich des Pods. Wenn Sie 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 für vorhandene Pods, die auf die dieser Version entsprechende Manifestversion aktualisiert wurden, Ihre DNS-Einstellungen neu zuordnen, um auf die IP-Adresse der neuen Mandanten-Appliance zu verweisen, die auf der Detailseite des aktualisierten Pod angezeigt wird.