Organisationen, die höchste Anforderungen an die Verfügbarkeit stellen, müssen in der Lage sein, auch größere Ausfälle zu überstehen, wie z. B. den Verlust einer ganzen Verfügbarkeitszone (Availability Zone, AZ). Die Bereitstellung eines Kubernetes-Clusters, der sich über mehrere Verfügbarkeitszonen erstreckt, ist bei Managed-Cloud-Anbietern eine einfache Aufgabe. Für die Bereitstellungs-, Konfigurations- und Betriebsphase der ArcGIS Enterprise on Kubernetes-Software müssen dagegen zusätzliche administrative Anforderungen berücksichtigt werden.
In den folgenden Abschnitten werden die Überlegungen und Anforderungen vor dem Konfigurieren der Organisation beschrieben, die voraussichtlichen Auswirkungen des Verlusts der Funktionalität innerhalb einer Verfügbarkeitszone und wie ein Administrator den Zustand des zugrunde liegenden Systems nach der Wiederherstellung der Funktionalität in dieser Verfügbarkeitszone überprüfen kann.
Der Kubernetes-Cluster, in dem die Anwendung bereitgestellt wird, muss mindestens die folgenden Anforderungen erfüllen:
- Worker-Knoten-Gruppen umspannen mindestens drei Verfügbarkeitszonen
- Adäquate Worker-Knoten-Kapazitäten zum Neuausgleich aller Arbeitslasten in zwei Verfügbarkeitszonen während eines Ausfalls
Bereitstellung und Konfiguration
Bei der Bereitstellung von ArcGIS Enterprise on Kubernetes in einem Multi-AZ-Cluster bedeutet das Vorhandensein von zustandsbehafteten Arbeitslasten, dass bei der Verwendung von Blockspeichergeräten eine Verfügbarkeitszonenabhängigkeit der zugehörigen Festplatten besteht.
Um sicherzustellen, dass die zugehörigen Replikate jedes StatefulSets über die entsprechende Topologie verteilt werden, wurde eine neue Eigenschaft in die Bereitstellungseigenschaftendatei (K8S_TOPOLOGY_AVAILABILITY_KEY) aufgenommen, die vor der Ausführung des Bereitstellungsskripts aktualisiert werden muss. Die Aktualisierung dieser Eigenschaft auf einen anderen Wert als kubernetes.io/hostname aktiviert eine topologySpreadConstraint-Spezifikation in den StatefulSets, die garantiert, dass es in keiner Verfügbarkeitszone zu einer ungleichen Verteilung der Replikate kommt.
Um die höchste Verfügbarkeit zu gewährleisten, sollten Sie die Organisation mit dem Architekturprofil für erweiterte Verfügbarkeit konfigurieren. Dies ist das einzige Profil, das bei einem Ausfall der Verfügbarkeitszone eine angemessene Abdeckung aller zustandsbehafteten Arbeitslasten garantiert.
Selbst bei Verwendung des erweiterten Verfügbarkeitsarchitekturprofils gibt es eine Reihe von Bereitstellungen, die nur ein einziges Replikat aufweisen, da sie je nach den Anforderungen der jeweiligen Organisation sehr unterschiedlich sind. Für die Skalierung über ein einzelnes Replikat hinaus sollten die folgenden Bereitstellungen in Betracht gezogen werden, um die Ausfallzeiten zusätzlich zu reduzieren:
- arcgis-enterprise-apps
- arcgis-enterprise-manager
- arcgis-enterprise-portal
- arcgis-enterprise-web-style-app
- arcgis-help
- arcgis-javascript-api
- arcgis-service-api
- arcgis-service-lifecycle-manager
- arcgis-featureserver-webhook-processor
- arcgis-gpserver-webhook-processor
Jede der oben aufgeführten Bereitstellungen außer "arcgis-enterprise-web-style-app" benötigt im Vergleich zum Failover-Prozess des Data Stores vom Typ "relational" weniger Zeit für den Neustart nach einem AZ-Ausfall. Die Skalierung auf ein zusätzliches Replikat aller aufgelisteten Bereitstellungen führt zu ungefähr 1 CPU und 0,5 GiB RAM zusätzlich zu den gesamten Namespace-Anforderungen und 5 CPUs und 2,5 GiB RAM zusätzlich zu den gesamten Namespace-Limits.
Bei der Veröffentlichung von Services sollten alle dedizierten Services so eingestellt werden, dass mindestens zwei Pods laufen, um sicherzustellen, dass es bei einer Umplanung keine Unterbrechung gibt. Die Bereitstellungen von geteilten Instanzen sollten zu diesem Zweck ebenfalls auf mindestens zwei Replikate skaliert werden.
Auswirkungen eines AZ-Verlusts
Die Bedeutung und die Auswirkungen des Verlusts einer Verfügbarkeitszone hängen davon ab, welche Cloud-Services betroffen sind. Der Ausfall eines bestimmten Services, z. B. eines Rechen- oder Speichersystems, kann erhebliche Auswirkungen auf die laufenden Arbeitslasten haben, während andere netzwerkbasierte Ausfälle, z. B. bei der DNS-Auflösung oder starke Anstiege der Latenzzeiten, die Kommunikation zwischen Microservices beeinträchtigen können.
Bei einem Failover eines Data Stores vom Typ "relational" können bestimmte Funktionen wie die Anmeldung, die Bearbeitung von gehosteten Feature-Services und das Laden von gehosteten Layern für kurze Zeit beeinträchtigt sein. Wenn die Standby-Instanz in eine primäre Instanz umgewandelt wurde, sollten alle Funktionen der Organisation in einem stabilen Zustand sein.
Überprüfung des Organisationszustands
Administratoren können die integrierten Zustandsprüfberichte nutzen, um den Zustand ihrer Site zu beurteilen. Sie können auch die Arbeitslasten des Namespace auf Probleme beim Pod-Start und andere Herausforderungen überprüfen, die auftreten können.
Während eines AZ-Ausfalls
Wenn bei der Verwendung von Blockspeicher für PVs eine Verfügbarkeitszone verloren geht, können die StatefulSet-Pods aufgrund der Volume-Affinitätsanforderungen nicht in andere Verfügbarkeitszonen umgeplant werden.
Für die Data Stores, die dies erfordern, wird ein Quorum aufrechterhalten, damit die zugehörigen Services auch in einem heruntergestuften Zustand funktionieren können. Da es sich bei dem Data Store vom Typ "relational" um eine Kernkomponente handelt, von der mehrere andere Services abhängig sind, gibt es die Möglichkeit, die Standby-Instanz über die Admin-API zurückzusetzen. Dadurch werden das StatefulSet und der zugehörige Anspruch auf ein persistentes Volume (Persistent Volume Claim, PVC) entfernt, und es wird ein neues StatefulSet erstellt. Auf diese Weise kann die Standby-Instanz erneut mit der primären Instanz synchronisiert werden, nachdem sie in einer der verbleibenden Verfügbarkeitszonen erstellt wurde.
Nach einem AZ-Ausfall
Wenn die Services in der ausgefallenen Verfügbarkeitszone wiederhergestellt werden, sollten die zugehörigen Arbeitslasten, die sich in einem ausstehenden Zustand befanden, gestartet werden, was über die Kubernetes-API bestätigt werden kann.
Wenn die Services in der bestehenden Verfügbarkeitszone nicht wiederhergestellt werden können, stellen Sie sicher, dass Ihr Cluster über mindestens drei verbleibende Verfügbarkeitszonen verfügt, und wenn dies nicht der Fall ist, erweitern Sie Ihren Cluster um eine zusätzliche Verfügbarkeitszone. Sobald dies abgeschlossen ist, erstellen Sie eine Sicherungskopie, heben die Bereitstellung auf und führen sie erneut durch und führen dann eine Wiederherstellung aus der Sicherungskopie durch.