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 AZs 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 notwendigen Überlegungen und zu erfüllenden Anforderungen vor dem Konfigurieren der Organisation beschrieben, die voraussichtlichen Auswirkungen des Verlusts der Funktionalität innerhalb einer AZ und wie ein Administrator den Zustand des zugrunde liegenden Systems nach der Wiederherstellung der Funktionalität in dieser AZ ü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 AZs.
- Es sind adäquate Worker-Knoten-Kapazitäten zum Neuausgleich aller Arbeitslasten in zwei AZs während eines Ausfalls vorhanden.
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 AZ-Abhängigkeit der zugehörigen Festplatten besteht.
Um sicherzustellen, dass die zugehörigen Replikate jedes StatefulSets über die entsprechende Topologie verteilt werden, wurde die neue Eigenschaft K8S_AVAILABILITY_TOPOLOGY_KEY in die Bereitstellungseigenschaftendatei 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 AZ zu einer ungleichen Verteilung der Replikate kommt. Der Schlüssel für die AZ-Knotenbeschriftung lautet bei den meisten Cloud-Anbietern topology.kubernetes.io/zone.
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 AZ 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. Ziehen Sie für die Skalierung über ein einzelnes Replikat hinaus die folgenden Bereitstellungen in Betracht, 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.
Stellen Sie bei der Veröffentlichung von Services alle dedizierten Services so ein, dass mindestens zwei Pods ausgeführt werden, um sicherzustellen, dass es bei einer Umplanung keine Unterbrechung gibt. Skalieren Sie die Bereitstellungen von geteilten Instanzen zu diesem Zweck ebenfalls auf mindestens zwei Replikate.
Auswirkungen eines AZ-Verlusts
Die Bedeutung und die Auswirkungen des Verlusts einer AZ hängen davon ab, welche Cloud-Services betroffen sind. Der Ausfall eines bestimmten Service, 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 wieder 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 AZ verloren geht, können die StatefulSet-Pods aufgrund der Volume-Affinitätsanforderungen nicht in andere AZs 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, kann die Standby-Instanz über die Admin-API zurückgesetzt werden. 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 mit der primären Instanz synchronisiert werden, nachdem sie in einer der verbleibenden AZs erstellt wurde.
Nach einem AZ-Ausfall
Wenn die Services in der ausgefallenen AZ wiederhergestellt werden, starten Sie die zugehörigen Arbeitslasten mit dem Status "Ausstehend" neu, was über die Kubernetes-API bestätigt werden kann.
Wenn die Services in der vorhandenen AZ nicht wiederhergestellt werden können, stellen Sie sicher, dass der Cluster über mindestens drei verbleibende AZs verfügt. Ist dies nicht der Fall, erweitern Sie den Cluster um eine zusätzliche AZ. 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.