Horizon Cloud Pods – Wartung und Updates

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

Einführung

Die Wartungsaktivitäten des Systems umfassen eine automatische Aktualisierung der Softwarekomponenten des Pods, um neue Funktionen, Fehlerbehebungen und Verbesserungen für die Unterstützung von Diensten 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. Das System verwendet die Anzahl der Sitzungen, um den optimalen Zeitpunkt für den Abschluss der Aktualisierung zu bestimmen, wenn nur eine geringe Anzahl von Benutzern mit aktiven Sitzungen mit der Umgebung verbunden ist.

Die Wartungsaktivität, mit 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 das Horizon Cloud-Team jederzeit nach Belieben 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 Angebote, die wir im Azure Marketplace bereitstellen, programmgesteuert verwendet werden. Wenn die Upgrade-Vorabprüfungen ergeben, dass die programmgesteuerte Verwendung unserer -Angebote im Abonnement verhindert wird, müssen Sie die auf dieser Dokumentationsseite beschriebenen Aktionen ausführen, um die Fehler zu beheben, die die Aktualisierung blockieren.

Wenn beispielsweise der Horizon Cloud-Dienstprinzipal, der mit den Abonnements verknüpft ist, die für den Pod und seine Gateway-Konfigurationen verwendet werden, eine benutzerdefinierte Rolle verwendet (atypisch), stellen Sie 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 abzurufen und unsere Angebote zu erhalten. Wenn die benutzerdefinierte Rolle diese beiden Berechtigungen noch nicht enthält, fügen Sie sie der 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 und den Supportbetrieb von Pods als wichtig erachtet werden, können Sie ein neues Manifest erstellen, bei dem es sich um eine Punktversion handelt, 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 für die Pod-Manager-VMs demselben Infrastrukturentwurfsmuster 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 weiterhin die ihnen zugewiesenen IP-Adressen für die 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 Aktualisierungsvorgang 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-Aktualisierungen verwendet werden. Dieses Design entspricht dem Muster, 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

  • Verwaltungssubnetz – 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 bezogen werden.
  • Mandantensubnetz – Nur die spezifischen Netzwerkkarten und Lastausgleichsdienste 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 den vom Pod verwendeten Subnetzen außer den Ressourcen der Pod-Bereitstellung keine zusätzlichen Ressourcen angefügt werden 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 die Pod-Aktualisierung ausgeführt wird. Andernfalls schlägt die Pod-Aktualisierung fehl und erfordert Horizon Cloud-Unterstützung.

• Stellen Sie nach dem Aktualisieren des Pods sicher, dass Sie alle IP-Adressen, die von den vom Bereitsteller erstellten Netzwerkkarten in der Ressourcengruppe des Pods reserviert wurden, zu den Firewallregeln hinzufügen, die Sie vor der Aktualisierung eingerichtet haben

  Möglicherweise verfügen Sie über bestehende Firewallregeln, die den Datenverkehr von den IP-Adressen der Netzwerkkarten der Pod Manager-VMs steuern. 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 Firewallregeln berücksichtigt werden.

Wissenswertes zur Pod-Wartung

Die Wartung unserer 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, die von diesem Pod bereitgestellt werden, aufrechtzuerhalten. Wie im KB-Artikel Horizon Cloud – Additional Service Details (87894) beschrieben, sind wir für die Softwarekomponenten verantwortlich, die sich auf dem Pod befinden und von der Steuerungsebene auf diesen Pod heruntergeladen werden. In der PDF-Datei Horizon Cloud – Additional Service Details , die diesem KB-Artikel angefügt ist, wird Folgendes beschrieben:

• Unsere (Omnissa) Rolle und Verantwortlichkeiten in Bezug auf die Änderungsmanagementverfahren zur Aufrechterhaltung des Zustands der Softwarekomponenten, die in den Pod heruntergeladen werden. Zu den Wartungsaktivitäten gehört die Aktualisierung der Softwarekomponenten des Pods.
• Die Rolle und Verantwortlichkeiten des Kunden (Ihres) in Bezug auf die Change-Management-Verfahren, einschließlich der Zusammenarbeit mit uns, wenn eine geplante oder Notfallwartung erforderlich ist.

Das Dokument Horizon Cloud – Additional Service Details enthält eine Definition der geplanten Wartung, der Wartungsfenster und der Notfallwartung. Weitere Informationen finden Sie in diesem Dokument. Bei Widersprüchen zwischen dem Inhalt dieser Dokumentationsseite und dem Inhalt des Dokuments Horizon Cloud – Additional Service Details hat das Dokument Horizon Cloud – 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, werden nach der Pod-Aktualisierung möglicherweise inkompatible Agentenversionen ausgeführt, 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. Weitere Informationen finden Sie unter Horizon Cloud Pod-Updates – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung.

Angeben des bevorzugten Wartungsfensters des Pods

Um anzugeben, dass Sie es vorziehen, dass alle Wartungsaktivitäten auf Ihrem Pod zu einer bestimmten Stunde und an einem bestimmten Wochentag beginnen, geben Sie über die Konsole das so genannte 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 Bevorzugte Wartungszeit 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 Standardwerten auswä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 uns erlauben, 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, gibt es keine Garantie dafür, dass das System in der Lage ist, diese bevorzugte Wartungsstartzeit für einen bestimmten Aktualisierungsvorgang zu berücksichtigen.

Zum Zeitpunkt der Erstellung dieses Dokuments weist der Scheduler des Systems vier (4) Stunden für die Dauer der Wartungsaktivität zu. Die typische Pod-Aktualisierung dauert weniger als diese zugewiesene Dauer.

Wartungswarnungen und -benachrichtigungen

Das System warnt 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.

    

  • Auf der Registerkarte "Überwachungsprotokolle" des Pods und in der Konsole unter Aktivität > Überwachungsprotokolle wird in einem Überwachungsprotokoll angegeben, dass ein Upgrade des Pods von Operations geplant wurde. Die Überwachungsprotokollzeile 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 im Bereich "Konten" der Benutzeroberfläche " Allgemeine Einstellungen " der Konsole angegeben sind. Eine E-Mail 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 Wartungsuhrzeit verschieben möchten, müssen Sie sich an den Horizon Cloud Support wenden.

Systemvorabprü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 Anweisungen auf dem Bildschirm 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 ausführen. Weitere Informationen zu Abhilfemaßnahmen bei typischen Pod-Aktualisierungsfehlern finden Sie unter Horizon Cloud Pods – Abhilfemaßnahmen bei häufigen Vorabprüfungsfehlern.

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

• Sie erhalten eine Benachrichtigungs-E-Mail, die Sie auf diesen Umstand hinweist und Details zu den erforderlichen Aktionen zur Behebung des Fehlers enthält.
• Die Konsole zeigt eine visuelle Warnung mit dem Hinweis an, dass Sie Maßnahmen ergreifen müssen, um die Vorabprüfungsfehler für diesen Pod zu korrigieren.

Wichtig: Wenn Sie Benachrichtigungen über Pod-Upgrade-Fehler erhalten, führen Sie die angegebenen Aktionen durch, um die Fehler rechtzeitig zu beheben. Die Zeit drängt. Wenn diese Fehler nicht in der von uns geforderten Zeit behoben werden, geht der Pod in einen nicht unterstützten Zustand über, da der Pod-Aktualisierungsprozess nicht eingeleitet werden kann.

Pod-Updates – Allgemeine Übersicht

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 Softwarebranche, die als Blue-Green Deployment (also Blau-Grün-Bereitstellung) bezeichnet wird. Die vorhandenen zu aktualisierenden Pod-Komponenten werden als "Blue"-Komponenten bezeichnet.

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 Netzwerkkarten für die Unified Access Gateway-Instanzen. Ein weiterer Unterschied besteht darin, dass beim Pod-Aktualisierungsvorgang die neueren Instanzen neben den vorhandenen erstellt werden, die neueren eingeschaltet werden und weiterhin ausgeführt werden, bis die Migration des Pods zu den neuen Instanzen abgeschlossen ist. 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, werden die älteren blauen VMs aus der Ressourcengruppe gelöscht. (Ein kanonisches Blau-Grün-Update würde in der Regel 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 Unified Access Gateway-VMs – werden als die blauen Komponenten betrachtet.
• Der Dienst erstellt automatisch die erforderlichen grünen 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 Wartungsaktivitäten auf einem Pod plant, wurde in den vorangegangenen Abschnitten behandelt.
• Diese grünen VMs werden gestartet und laufen weiter, bis die geplante Wartungsaktivität abgeschlossen ist. Dabei handelt es sich um die Wartungsaktivität, die die blauen VMs 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. Netzwerkkarten für die Unified Access Gateway-Instanzen, werden nicht gelöscht, um Konfigurationswerte beizubehalten, die bei der nächsten Pod-Aktualisierung benötigt werden.

Hinweis: Sie müssen vermeiden, Änderungen im Microsoft Azure-Portal und im Abonnement des Pods vorzunehmen, die sich auf den Aufbau der "Green"-Komponenten des Systems oder auf die Aktualisierungs- und Wartungsprozesse des Pods auswirken.

Reihenfolge der Wartungsaktivitäten

Diese Sequenz beschreibt die Migration zum grünen Build-Out – den Wechsel von Blau zu Grün bei 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 für die Wartung aus. Wie in den vorangegangenen Abschnitten beschrieben, zeigt die Konsole das geplante Datum und die Uhrzeit visuell an, und es wird eine E-Mail an die Administratoren des Mandanten gesendet.
3. Wichtig: Bevor die geplante Wartung ausgeführt wird:

• 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. Weitere Informationen finden Sie unter Horizon Cloud-Pod-Updates – Schritte für fortgesetzte Agentenkompatibilität und Unterstützung.

• Entfernen Sie alle Verwaltungssperren in Microsoft Azure, die Sie möglicherweise für die virtuellen Maschinen (VMs) des Pods festgelegt haben. Alle VMs mit Namen, die eine Zeichenfolge wie hcs-podID enthalten, 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 ihnen 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 wird der Aktualisierungsvorgang nicht erfolgreich abgeschlossen. 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 Horizon Cloud 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 in der Regel zwischen 20 und 30 Minuten von Anfang bis Ende für Pods, die sowohl eine externe als auch eine interne Unified Access Gateway-Konfiguration aufweisen.

   Hinweis: Während der 20- bis 30-minütigen Dauer des Vorgangs verhindert die Konsole, dass Sie administrative Aufgaben auf dem Pod durchführen, der aktualisiert wird. Beispiel: Bis die Pod-Manager-Appliances die Cloud-Ebene benachrichtigen, dass die Aktualisierung abgeschlossen ist, ist die Aktion Bearbeiten auf der Pod-Detailseite nicht verfügbar, um die Eigenschaften dieses Pods zu ändern.

   • Informationen 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 den Abschluss der Aktualisierung dieser Appliances zu bestimmen.

     Der Zeitpunkt der Fertigstellung ist 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 nahezu bei Null liegt, werden die Sitzungen von Endbenutzern 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 festgelegt 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 jegliche laufende 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.

     Auch während dieses nahezu Null-Zeitfensters, wenn ein Endbenutzer, der noch keine Verbindung zu seinem virtuellen Desktop oder seiner Remoteanwendung aus dem Pod hat und versucht, eine Verbindung herzustellen, erst nach Abschluss des Vorgangs eine Verbindung herstellen kann.

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, um Konfigurationswerte beizubehalten, die für die nächste Wartung erforderlich sind.

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 zugehörige Übersichtsseite zu öffnen. Auf der Seite wird die derzeit ausgeführte Softwareversion 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 in der Konsole blaue Punkte für Ihre Images oder Zuweisungen angezeigt werden, bedeutet dies, dass die Agenten aktualisiert werden müssen. Horizon Cloud-Pod-Updates – Schritte für eine fortgesetzte Kompatibilität und Unterstützung von Agenten.
• Wenn dieses Update von einem Manifest vor Manifest 3328 stammt, stellen Sie nach dem Aktualisieren 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 verfügen Sie über bestehende Firewallregeln, die den Datenverkehr von den IP-Adressen der Netzwerkkarten der Pod Manager-VMs steuern. 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 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 das erste Update 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, um die Möglichkeit der Hochverfügbarkeit (HA) zu unterstützen. Selbst wenn die Hochverfügbarkeitsfunktion nicht aktiviert ist, enthält die neue HA-fähige Architektur einen Microsoft Azure-Lastausgleichsdienst vor der Pod-Manager-VM. Nachdem Sie Ihren Pod auf Manifest 1600 aktualisiert haben, sollten Sie, wenn Ihr Pod für direkte Verbindungen konfiguriert war, Ihre DNS-Einstellungen neu zuordnen, um auf die IP-Adresse des Azure Load Balancer des Pod-Managers zu verweisen, die neu auf der Detailseite des aktualisierten Pods angezeigt wird. Bis zur Aktualisierung der DNS-Zuordnung – auch wenn diese direkten Benutzerverbindungen weiterhin funktionieren – verfügen diese Verbindungen bei einem Ausfall der aktiven Pod-Manager-VM nicht über das Hochverfügbarkeits-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 , das auf der Detailseite des Pods angezeigt wird, einen FQDN zu, wie unter Konfigurieren von SSL-Zertifikaten direkt auf den Pod Manager-VMs beschrieben, z. B. bei der Integration der Access Connector-Appliance in den Horizon Cloud-Pod in Microsoft Azure, Damit Connector Verbindungen mit den Pod-Manager-VMs als vertrauenswürdig einstufen kann. Vor Pod-Manifest 1600 war diese IP diejenige, die der Netzwerkkarte der Manager-VM des Pods im Mandantensubnetz zugewiesen wurde. Ab Pod-Manifest 1600 oder höher ist die zuzuordnende IP-Adresse des Pods die private IP-Adresse des Microsoft Azure-Lastausgleichsdiensts, 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, um auf die IP-Adresse zu verweisen, die für die Bezeichnung 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 Ihre 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 Zeitsynchronisierung haben (clockSkew > 4 minutes), wird diese Systemvalidierung auf diesem 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 Zeitversatz beheben, und die fehlerhafte Erkennung wirkt sich auf die Desktop-Verbindungsanforderungen des Endbenutzers zu diesem Pod aus.