Vorbereiten des Upgrades

Durch ein Upgrade auf eine neue ArcGIS Enterprise on Kubernetes-Version erhält Ihre Organisation Zugang zu neuen Features und verbesserten Funktionen. Informieren Sie sich vor dem Upgrade über die neuen Features, und identifizieren Sie Änderungen, die die Benutzer in der Organisation betreffen können.

Sie müssen ein Upgrade von ArcGIS Enterprise on Kubernetes durchführen, bevor Sie ein Upgrade von Kubernetes auf eine unterstützte Version durchführen.

Vorsicht:

Vor der Durchführung eines Upgrades sollten Sie eine Sicherung Ihrer Organisation anlegen.

Tipp:

Sie können die Knotenaffinität und Toleranzen für die Pods festlegen, die bei Aktualisierungen oder Upgrades verwendet werden. Sobald eine Platzierungsrichtlinie erstellt wurde, wird diese bei jeder Erstellung eines Upgrade-Auftrags angewendet. Die festgelegten Werte werden für alle zukünftigen Aktualisierungen und Upgrades beibehalten, bis sie zurückgesetzt werden. Weitere Informationen finden Sie unter Update (Upgrades configuration).

Upgrade-Anforderungen

Vor der Durchführung des Upgrades müssen die folgenden Anforderungen erfüllt sein:

• Wenn eine erforderliche Aktualisierung verfügbar ist, müssen Sie diese anwenden, bevor Sie ein Upgrade auf diese Version durchführen. In den Versionshinweisen finden Sie Informationen zur letzten erforderlichen Aktualisierung.
• Sie benötigen eine einheitliche ArcGIS Enterprise on Kubernetes-Lizenz für diese Version.
• Sie müssen die Werte von Ressourcenkontingenten in Ihrem Namespace gemäß den aktuellen Anforderungen aktualisieren.
• Ihre Umgebung erfüllt die Pod-Sicherheitsstandards, wie z. B. die Pod-Sicherheitszugangsstandards, bevor Sie das Upgrade durchführen.
• Wenn Ihre Umgebung sich in Red Hat OpenShift befindet, stellen Sie sicher, dass sie die aktuellen Sicherheitskontextbeschränkungen einhält.
• Die Volume-Größen der Speicher müssen die Mindestanforderungen für die Version erfüllen, auf die Sie durch ein Upgrade durchführen möchten. Wenn für den von der Speicherklasse verwendeten Provisioner keine Volume-Erweiterung verfügbar ist, stellen Sie eine Sicherung in einer neuen Organisation wieder her, die mit größeren Volumes konfiguriert ist. Werden die Mindestanforderungen an den Speicher nicht erfüllt, kann dies zu Problemen beim Laden der Elemente Ihrer Organisation und beim Start der Services führen.
• Wenn Sie statische persistente Volumes (PVs) bereitgestellt haben, müssen Sie zusätzlichen Speicher bereitstellen, um die Upgrade-Anforderungen zu erfüllen. Weitere Informationen finden Sie im folgenden Abschnitt.
• Wenn Ihr bereitgestellter Speicher dynamische PVs enthält, muss ausreichend Speicher für das zusätzliche item-packages-volume, das object-volume und das queue-volume vorhanden sein.
• Um ein Upgrade für einen Data Store vom Typ "relational" durchzuführen, wird eine Sicherung im selben persistenten Volume wie die Instanz des Data Store vom Typ "relational" erstellt. Für diese Sicherung müssen mindestens 50 Prozent der Datenbankgröße verfügbar sein. Wenn der Data Store vom Typ "relational" derzeit 100 GB Speicher verwendet, muss das zugehörige PV vor dem Upgrade über mindestens 50 GB verfügen, sodass die erforderliche Gesamtgröße des Volumes 150 GB oder mehr beträgt. Anweisungen zum Erhöhen der Volume-Größe finden Sie unter Verwalten des erforderlichen Speichers.
• Der Speicherlimitwert für den ReportingTools-Service muss auf mindestens 3 GiB festgelegt sein. Weitere Informationen zur Aktualisierung dieses Wertes finden Sie unter Verwalten von Systembereitstellungen.
• Führen Sie das Preupgrade-Skript aus. Mit diesem Skript stellen Sie sicher, dass die Funktionsanforderungen den Anforderungen der aktuellen Softwareversion gerecht werden.
• Wenn Sie in Ihrer Organisation über einen konfigurierten Web Adaptor verfügen, dann lesen Sie die Anforderungen für Installation und Aktualisierung.
• Wenn für die Bereitstellung von ArcGIS Enterprise on Kubernetes die Containerregistrierung Ihrer Organisation verwendet wurde oder die Bereitstellung in einer nicht verbundenen Umgebung erfolgt ist, müssen Sie die erforderlichen Container-Images aus dem Esri Repository in die Registrierung der Organisation kopieren, bevor Sie die Aktualisierung oder das Upgrade ausführen.
• Werden bei der Bereitstellung mehrere Verfügbarkeitszonen verwendet, muss jede Verfügbarkeitszone über die entsprechende Kapazität verfügen, um zusätzliche Replikate der zustandsbehafteten Workloads zu unterstützen. Dazu kann es erforderlich sein, die Knotengruppe während Aktualisierungen oder Upgrades vorübergehend zu verkleinern.
• Wenn Sie benutzerdefinierte Dashboards mit der Grafana-Metrik-Viewer-App in einer niedrigeren Version als 11.2 erstellt haben, müssen Sie die Dashboards exportieren, bevor Sie ein Upgrade durchführen. Grafana ist in ArcGIS Enterprise on Kubernetes nicht mehr enthalten, sie können jedoch weiter damit oder mit einer anderen Drittanbieter-App Statistiken innerhalb oder außerhalb des Clusters anzeigen.

  Weitere Informationen zum Migrieren vorhandener Dashboards in eine externe Instanz

• Es müssen alle ArcGIS Pro-Offline-Lizenzen von den Organisationsmitgliedern eingecheckt werden. Sie können die Lizenzaktivität anzeigen, um zu ermitteln, welche Mitglieder ihre ArcGIS Pro-Lizenz zur Offline-Verwendung ausgecheckt haben. Informationen zum Einchecken einer Offline-Lizenz finden Sie unter Einchecken einer Offline-Lizenz.
• Wenn Sie einen Cloud-Data-Store vom Typ "relational" verwenden, muss die Datenbankversion unterstützt werden. Dies gilt sowohl für die aktuelle Version von ArcGIS Enterprise on Kubernetes als auch für die Version, auf die das Upgrade durchführt wird. Dazu kann ein Upgrade der Datenbankinstanz des Cloud-Data-Store vom Typ "relational" erforderlich sein.

Anpassen statischer PVs für Upgrades

Vor einem Upgrade muss Folgendes mit einem zusätzlichen PV konfiguriert werden:

• Jeder Pod in der Portal-API-Bereitstellung der Organisation muss mit einem zusätzlichen item-packages-volume konfiguriert werden.
• Jeder Pod im In-Memory-Systemspeicher der Organisation muss mit einem zusätzlichen in-memory-volume konfiguriert werden.
• Jeder Pod im Warteschlangen-Systemspeicher der Organisation muss mit einem zusätzlichen queue-volume konfiguriert werden.

Nachfolgend finden Sie einige Beispiele:

• Wenn die Portal-API-Bereitstellung mit drei ausgeführten Pods konfiguriert ist, müssen Sie drei zusätzliche item-packages-volumes bereitstellen.
• Wenn das in-memory-volume mit einem ausgeführten Pod konfiguriert ist, müssen Sie ein zusätzliches in-memory-volume bereitstellen.
• Wenn das queue-volume mit einem ausgeführten Pod konfiguriert ist, müssen Sie ein zusätzliches queue-volume bereitstellen.

In jedem Fall müssen Sie die zusätzlichen PVs mit Spezifikationen konfigurieren, die den während der Bereitstellung angegebenen Spezifikationen entsprechen.

Nachdem das Upgrade abgeschlossen ist, werden die neu bereitgestellten PVs und Persistent Volume Claims (PVC) in der Portal-API-Bereitstellung, im In-Memory-Speicher und im Warteschlangenspeicher verwendet. Die ursprünglichen Volumes können anschließend entfernt werden. Es wird dringend empfohlen, alle PVs zu entfernen, die mit dem Warteschlangenspeicher verknüpft sind. PVs aus früheren Upgrades oder Aktualisierungen dürfen niemals wiederverwendet werden.