Zustandsbehaftete Workload-Upgrademuster für Azure Kubernetes Service (AKS)

Verwenden Sie diese Muster, um die Datenbankverfügbarkeit mit einem rollierenden Upgrade eines Azure Kubernetes Service (AKS)-Knotenpools zu koordinieren.

Die Verfahren in diesem Artikel sind Planungsframeworks, keine Verfügbarkeits- oder Datenbeständigkeitsgarantien. Das Ergebnis hängt von Ihrer Datenbanktopologie, dem Replikationsmodus, Speicher, Operator, Unterbrechungseinstellungen, dem Verhalten des Clientretrys und der Workload ab. Testen Sie das vollständige Verfahren in einer repräsentativen Umgebung, und messen Sie, ob sie Ihr Wiederherstellungszeitziel (RTO) und das Wiederherstellungspunktziel (RPO) erfüllt.

In diesem Artikel behandelte Datenbankupgrademuster

Dieser Artikel beschreibt datenbankspezifische Upgrademuster für AKS-Cluster mit zustandsbehafteten Workloads, einschließlich:

• Kontrollierter Switchover von PostgreSQL.
• Rolling-Upgrade für Redis Cluster mit zuerst aktualisierten Replikaten.
• MongoDB-Replikat-Set-Rolling-Upgrade mit Secondary-First-Strategie.
• Checklisten für Notfall-Upgrades bei Sicherheitsvorfällen.
• Validierungs- und Rollbackplanung.

Im Gegensatz zu einem normalen Upgrade eines AKS-Knotenpools koordinieren diese Muster Datenbankreplikationsprüfungen und Rollenänderungen mit dem Ersetzen von Kubernetes-Knoten. Datenbank- und AKS-Administratoren können diese Muster verwenden. Verwenden Sie den dokumentierten Switchover- oder Upgradevorgang für den Datenbankoperator, der Ihre Bereitstellung verwaltet. Ersetzen Sie diese Muster nicht durch operatorspezifische Anweisungen.

Weitere Informationen finden Sie in den folgenden verwandten Artikeln:

• Informationen zum Upgrade Ihrer Produktions-AKS-Cluster finden Sie unter AKS-Produktionsupgradestrategien.
• Informationen zum Vergleichen von Upgradeansätzen für Ihren AKS-Cluster finden Sie unter Upgradeoptionen und Empfehlungen.
• Um mit dem Szenariohub den richtigen AKS-Upgradeansatz auszuwählen, siehe AKS-Upgradeszenarien: Wählen Sie Ihren Weg.

Für einen schnellen Einstieg wählen Sie das Muster für Ihr bereitgestelltes Produkt und die Topologie aus:

• Checkliste für Notfallupgrades
• kontrollierter PostgreSQL-Switchover
• Rolling-Upgrade des Redis-Clusters mit Replikaten zuerst
• MongoDB-Replikatsatz sekundäres rollierendes Upgrade

Auswählen eines Datenbankupgrademusters

Checkliste für Notfallupgrades

Wenn Sie ein beschleunigtes Upgrade benötigen, um ein Sicherheitsproblem zu beheben, überspringen Sie die Integritäts- und Wiederherstellungsprüfungen der Datenbank nicht.

1. Überprüfen Sie die Voraussetzungen für das Workload- und AKS-Upgrade:

   # Verify the database pods and their node placement.
   kubectl get pods -l tier=database -o wide
   
   # Confirm that the latest backup job completed.
   kubectl get job backup-job -o jsonpath='{.status.completionTime}'
   

   Überprüfen Sie außerdem den Replikationsstatus mithilfe eines Befehls, der von der Datenbank oder dem Operator unterstützt wird. Stellen Sie die neueste Sicherung in einer isolierten Umgebung wieder her, und stellen Sie sicher, dass Clients vorübergehende Verbindungs- und Wahlfehler wiederholen.

2. Wählen Sie nur das Muster aus, das Ihrem Produkt und Ihrer Topologie entspricht:

   • PostgreSQL: Verwenden Sie eine kontrollierte Umschaltung.
   • Redis Cluster: Verwenden Sie das erste rollierende Upgrade des Replikats.
   • MongoDB-Replikatgruppe: Verwenden Sie ein Rolling Upgrade nach dem Secondary-First-Prinzip.

   Folgen Sie für andere Datenbankprodukte den Upgradeleitfaden für dieses Produkt oder seinen Kubernetes-Operator.

3. Ausführen mit einem Sicherheitsnetz:

   • Testen Sie rollback-Verfahren immer im Voraus.
   • Überwachen Sie Anwendungsmetriken während des Upgrades.
   • Halten Sie das Datenbankteam im Standbymodus.
   • Beenden Sie das Upgrade, wenn die Replikation, das Quorum, die Steckplatzabdeckung oder die Anwendungsintegrität beeinträchtigt wird.

kontrollierter PostgreSQL-Switchover

Verwenden Sie dieses kontrollierte Switchovermuster für eine PostgreSQL-Primäre mit Streaming-Standbys. Die Beispiele zeigen Zustandsprüfungen, aber die Befehle zum Hochstufen, Isolieren und Wiederaufnehmen von Mitgliedern hängen von Ihrem PostgreSQL-Operator bzw. Ihrer Hochverfügbarkeitsimplementierung ab.

Prerequisites

• Verwenden Sie eine unterstützte PostgreSQL-Version und eine unterstützte Operator- oder Hochverfügbarkeitsimplementierung.
• Platzieren Sie Mitglieder verteilt über Ausfalldomänen. Konfigurieren Sie Pod Disruption Budgets und Topologieverteilungsbeschränkungen für Ihre Bereitstellung.
• Überprüfen Sie eine aktuelle Sicherung, indem Sie sie in einer isolierten Umgebung wiederherstellen.
• Vergewissern Sie sich, dass die Anwendung nach einer primären Änderung erneut eine Verbindung herstellen kann.
• Notieren Sie vor dem Start des AKS-Upgrades die operatorspezifischen Befehle für Umschaltung, Rollback und Wiedereinbindung.

Schritt 1: Überprüfen der Replikationstopologie

Führen Sie die folgende Abfrage auf dem aktuellen Primärserver aus:

kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;"

Der vorgesehene Switchover-Kandidat muss sich im Zustand streaming befinden. Wenn Ihr RPO eine synchrone Replikation erfordert, überprüfen Sie außerdem, ob der Kandidat über das für Ihre Konfiguration erwartete sync_state verfügt.

Führen Sie die folgende Abfrage im vorgesehenen Standbymodus aus:

kubectl exec <candidate-standby-pod> -- psql -X -c "
SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();"

Vergewissern Sie sich, dass pg_is_in_recovery()true zurückgibt und dass die Empfangs- und Wiedergabeorte Ihren getesteten Umschaltschwellenwert erfüllen. Die PostgreSQL-Streamingreplikation ist standardmäßig asynchron, sodass ein bereiter Pod allein nicht festlegen kann, dass der Standbymodus abgefangen wird.

Schritt 2: Schreibvorgänge anhalten und Primärknoten umschalten

Wenn der gesamte Anwendungsdatenverkehr über PgBouncer durchläuft, stellen Sie eine Verbindung mit der Verwaltungsdatenbank von PgBouncer her, und unterbrechen Sie die Anwendungsdatenbank:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "PAUSE app_db;"

PAUSE wartet auf die Freigabe von Serververbindungen gemäß dem konfigurierten Poolmodus. Stellen Sie sicher, dass Schreibvorgänge von Anwendungen PgBouncer nicht umgehen können, bevor Sie sich auf dieses Steuerelement verlassen.

Bei angehaltenen Schreibvorgängen führen Sie die folgenden Schritte mithilfe Ihres Operators oder Ihrer Hochverfügbarkeitsimplementierung aus:

1. Überprüfen Sie die WAL-Empfangs- und -Wiedergabeposition des Kandidaten erneut.
2. Führen Sie den unterstützten Switchover-Vorgang aus.
3. Überprüfen Sie, ob genau eine schreibbare Primäre vorhanden ist.
4. Stellen Sie sicher, dass der frühere primäre Server isoliert oder als Standby neu konfiguriert wird.
5. Stellen Sie sicher, dass der Writer-Dienst oder -Endpunkt in die neue primäre Lösung aufgelöst wird.

Nehmen Sie PgBouncer erst wieder in Betrieb, nachdem diese Prüfungen erfolgreich abgeschlossen wurden:

kubectl exec <pgbouncer-pod> -- psql -p 6432 -U <admin-user> pgbouncer -c "RESUME app_db;"

Schritt 3: Überprüfen der Umstellung

# Verify the new primary is writable and no longer in recovery.
kubectl exec <new-primary-pod> -- psql -X -c "SELECT pg_is_in_recovery();"

# Verify all expected standbys stream from the new primary.
kubectl exec <new-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

Die Testanwendung liest und schreibt, verarbeitet Transaktionen und zeigt das Wiederverbindungsverhalten. Vergleichen Sie vor dem Fortfahren, wie lange Schreibvorgänge nicht möglich waren und wie das Replikationsergebnis im Verhältnis zu Ihren RTO- und RPO-Werten ausfällt.

Optionale synchrone Replikationskonfiguration

Die synchrone Replikation kann das RPO für bestätigte Transaktionen reduzieren, erhöht jedoch die Commit-Latenz und kann die Schreibverfügbarkeit verringern, wenn die erforderlichen Standby-Server nicht verfügbar sind. Im folgenden Beispiel wird gewartet, bis beliebige zwei benannte, direkt verbundene Standbys jede festgeschriebene Transaktion nachvollzogen haben:

# Use synchronous replication with multiple standbys
# postgresql.conf
synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)'
synchronous_commit = 'remote_apply'

Wählen Sie synchronous_standby_names und synchronous_commit anhand der gemessenen Latenz, der Platzierung in Ausfalldomänen und der Anforderungen an die Dauerhaftigkeit aus. Diese Konfiguration garantiert keine bestimmte Switchoverdauer.

Erfolgsüberprüfung

Verwenden Sie die folgende Checkliste, um Ihren Fortschritt zu überprüfen:

• Der neue Primärknoten akzeptiert Lese- und Schreibvorgänge.
• Alle Replikate zeigen eine fehlerfreie Replikation an.
• Die Anwendung wird automatisch wieder verbunden.
• Prüfungen der Datenintegrität und Anwendungskonsistenz sind erfolgreich.
• Die Sicherungs- und Wiederherstellungstests sind auf dem neuen Primärknoten erfolgreich.

Upgrade des AKS-Knotenpools

Ein az aks nodepool upgrade Vorgang aktualisiert den gesamten Knotenpool. AKS fügt zusätzliche Kapazität hinzu, sperrt alte Knoten und räumt sie leer, erstellt sie neu und wiederholt den Vorgang entsprechend den Upgradeeinstellungen des Knotenpools. Führen Sie den Befehl nicht einmal für jeden Knoten aus, oder entwässern Sie die Knoten vor dem verwalteten Vorgang manuell.

1. Auflisten der unterstützten Upgradeziele für den Cluster:

   az aks get-upgrades \
      --resource-group <resource-group-name> \
      --name <cluster-name> \
      --output table
   

2. Vergewissern Sie sich, dass sich die Steuerungsebene bereits in der ausgewählten Zielversion befindet. Konfigurieren Sie die Einstellungen für das Rolling Upgrade des Knotenpools basierend auf dem getesteten Verhalten der Workloads, dem Kontingent und den verfügbaren Subnetzadressen. Im folgenden Beispiel wird der empfohlene Produktionswert maxSurge verwendet:

   az aks nodepool update \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --max-surge 33% \
      --drain-timeout <minutes> \
      --node-soak-duration <minutes>
   

3. Starten Sie ein verwaltetes Upgrade für den Knotenpool unter Verwendung eines von az aks get-upgrades zurückgegebenen Ziels:

   az aks nodepool upgrade \
      --resource-group <resource-group-name> \
      --cluster-name <cluster-name> \
      --name <node-pool-name> \
      --kubernetes-version <target-version>
   

4. Überwachen von AKS-Upgradeereignissen und Datenbankintegrität während des gesamten Vorgangs:

   kubectl events --all-namespaces
   kubectl get pods -l app=postgres -o wide --watch
   

   Überwachen Sie Replikation, Datenbankverfügbarkeit, Anwendungsfehler, Latenz und Speicherintegrität in Ihrem Observability-System. Wenn ein Pod Disruption Budget einen Abfluss blockiert, korrigieren Sie das Workloadverfügbarkeitsproblem, anstatt das Budget zu umgehen.

Überprüfen und Wiederherstellen

Überprüfen Sie nach Abschluss des verwalteten Upgrades die Knotenversionen, die PostgreSQL-Topologie und das Anwendungsverhalten:

kubectl get nodes
kubectl get pods -l app=postgres -o wide
kubectl exec <current-primary-pod> -- psql -X -c "
SELECT application_name, state, sync_state, replay_lsn
FROM pg_stat_replication;"

AKS unterstützt das Herabstufen eines Cluster- oder Knotenpools auf eine frühere Kubernetes-Version nicht. Wenn die Datenbank fehlerhaft ist, beenden Sie das Schreiben der Anwendung, und verwenden Sie die unterstützte Wiederherstellungs- oder Switchoverprozedur des Datenbankoperators. Leiten Sie Schreibzugriffe nicht an den früheren PostgreSQL-Primärknoten um, es sei denn, er wurde sicher wieder in die aktuelle Timeline aufgenommen und vom Hochverfügbarkeitsmechanismus zum Primärknoten hochgestuft. Wenn das Kubernetes-Upgrade ein nicht behebbares Kompatibilitätsproblem verursacht, stellen Sie den Dienst wiederhergestellt, indem Sie die Workload in einen getesteten Cluster oder Knotenpool verschieben und Daten gemäß Ihrem Wiederherstellungsplan wiederherstellen oder replizieren.

Rolling-Upgrade eines Redis-Clusters mit Replikaten zuerst

Verwenden Sie dieses Muster für einen Redis-Cluster mit mindestens drei primären Knoten und mindestens einem Replikat für jede Primäre. Die dokumentierte Reihenfolge für die Aktualisierung der Redis-Cluster-Knoten besteht darin, zunächst die Replikate zu aktualisieren, dann für jeden Primärknoten ein manuelles Failover auf ein aktualisiertes Replikat durchzuführen und anschließend den herabgestuften ehemaligen Primärknoten zu aktualisieren. Redis Cluster kann vorübergehende Fehler oder Umleitungen während Topologieänderungen zurückgeben. Da Redis Cluster asynchrone Replikation verwendet, können erkannte Schreibvorgänge verloren gehen. Validieren Sie das Verhalten bei Wiederholungsversuchen des Clients und die zulässige RPO vor dem Upgrade.

Schritt 1: Aufzeichnen und Überprüfen der Topologie

kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Notieren Sie die ID jedes Knotens, die Rolle, die Zuordnung von Primär- zu Replikatknoten und den Bereich der Hash-Slots. Fahren Sie nicht fort, es sei denn, alle 16.384 Slots sind abgedeckt, jede Primärinstanz verfügt über ein intaktes Replikat in einer anderen Fehlerdomäne und der Cluster meldet cluster_state:ok.

Schritt 2: Upgrade von Replikaten

Für jedes Replikat einzeln:

1. Verwenden Sie den Bereitstellungsmechanismus für den Operator oder die Workload, um das Replikat bei aktualisierter AKS-Kapazität zu ersetzen oder neu zu starten.
2. Warten Sie, bis der Pod bereit ist und die Replikation aufgeholt hat.
3. CLUSTER NODES Vergewissern Sie sich, dass sie der erwarteten Primären zugewiesen bleibt.

Führen Sie CLUSTER FORGET nicht für den Neustart eines Pods aus, der die Redis-Knotenidentität beibehält. Wenn der Ersatz über eine neue Knotenidentität verfügt, verwenden Sie redis-cli --cluster add-node zusammen mit --cluster-slave und --cluster-master-id, um ihn als Replikat des vorgesehenen Primärknotens hinzuzufügen. Warten Sie, bis das neue Replikat in der Clustertopologie angezeigt wird.

kubectl exec <existing-redis-pod> -- redis-cli --cluster add-node \
   <new-replica-ip>:6379 127.0.0.1:6379 \
   --cluster-slave \
   --cluster-master-id <primary-node-id>

Schritt 3: Failover durchführen und Primärknoten aktualisieren

Für jede primäre Einheit jeweils einzeln:

1. Wählen Sie ein aktualisiertes und synchronisiertes Replikat dieser Primärdatei aus.

2. Führen Sie CLUSTER FAILOVERdies auf dem Replikat aus, das Sie heraufstufen möchten, nicht auf der aktuellen Primärinstanz:

   kubectl exec <candidate-replica-pod> -- redis-cli CLUSTER FAILOVER
   

3. Fragen Sie ROLE, INFO REPLICATION oder CLUSTER NODES ab, bis der Kandidat die Primärinstanz ist und die ehemalige Primärinstanz dessen Replikat ist. Eine OK Antwort bedeutet nur, dass Redis die Failoveranforderung akzeptiert hat.

4. Ersetzen Sie die herabgestufte ehemalige primäre Instanz, oder starten Sie sie mit hochskalierter AKS-Kapazität neu.

5. Warten Sie, bis es wieder ein synchronisiertes Replikat ist, bevor Sie zur nächsten primären Instanz wechseln.

Verwenden Sie nicht CLUSTER FAILOVER FORCE oder TAKEOVER während eines geplanten Upgrades. Diese Optionen umgehen die normale Koordination und erfordern separate Fehlerwiederherstellungsverfahren.

Schritt 4: Überprüfen des Redis-Clusters

kubectl exec <redis-pod> -- redis-cli CLUSTER INFO
kubectl exec <redis-pod> -- redis-cli CLUSTER NODES
kubectl exec <redis-pod> -- redis-cli --cluster check 127.0.0.1:6379

Prüfen Sie die Abdeckung der Slots, die Zuordnungen von Primär- zu Replikatknoten, den Zustand der Replikation, die Lese- und Schreibvorgänge der Anwendung, die Handhabung von Umleitungen und den beobachteten RPO.

MongoDB-Replikatsatz sekundäres rollierendes Upgrade

Verwenden Sie dieses Muster für ein MongoDB-Replica-Set mit drei oder mehr Mitgliedern, das über ein wählbares Sekundärmitglied verfügt. Während des Rücktritts der Primärinstanz und der Wahl schlagen Schreibvorgänge fehl, bis eine neue Primärinstanz gewählt wurde. Anwendungen müssen berechtigte Schreibvorgänge und vorübergehende Transaktionen gemäß der Anleitung des MongoDB-Treibers wiederholen.

Schritt 1: Replikatsatz validieren

kubectl exec <mongodb-pod> -- mongosh --quiet --eval "rs.status()"

Vergewissern Sie sich, dass alle erwarteten Mitglieder fehlerfrei sind, die aktuelle primäre Person identifizieren und überprüfen, ob mindestens eine wahlfähige sekundäre Person abgefangen wird. Überprüfen Sie auch die neueste Sicherung über eine Testwiederherstellung.

Schritt 2: Aktualisieren von Secondärdateien

Für jede Sekundärinstanz jeweils einzeln:

1. Ersetzen Sie das Mitglied oder starten Sie es in der aktualisierten AKS-Kapazität über den Bereitstellungsmechanismus des Operators oder der Workload neu.

2. Warten Sie, bis der Pod bereit ist.

3. Vergewissern Sie sich, dass das Mitglied zum SECONDARY Status zurückkehrt und nachholt, bevor ein anderes Mitglied aktualisiert wird.

   kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
      "rs.status().members.map(member => ({name: member.name, state: member.stateStr, optime: member.optimeDate}))"
   

Schritt 3: Schrittweises Ausführen des primären Schritts

Nur gegen die aktuelle Primärinstanz ausführen rs.stepDown(). Das erste Argument gibt an, wie lange die ehemalige Primäre nicht erneut ausgewählt werden kann. Das zweite Argument gibt an, wie lange eine wahlfähige Sekundäre aufholen muss. Wählen Sie Werte basierend auf Ihrem getesteten Wahlverhalten aus.

kubectl exec <current-primary-pod> -- mongosh --quiet --eval "rs.stepDown(60, 30)"

Der Befehl kann die Verbindung trennen oder einen Fehler zurückgeben, wenn der Primärknoten zurücktritt. Abrufen des Replikatsatzstatus eines anderen Mitglieds, bis genau eine neue primäre Person ausgewählt wird:

kubectl exec <mongodb-pod> -- mongosh --quiet --eval \
   "rs.status().members.map(member => ({name: member.name, state: member.stateStr}))"

Wenn innerhalb des konfigurierten Zeitraums kein zur Wahl berechtigter Sekundärknoten aufschließt, tritt der Primärknoten nicht zurück. Beheben Sie Probleme mit der Replikationsintegrität, bevor Sie es erneut versuchen. Erzwingen Sie das Zurückstufen bei einem geplanten Upgrade nicht.

Schritt 4: Die ehemalige primäre Instanz aktualisieren und validieren

Ersetzen oder neu starten Sie die frühere Primäre bei aktualisierter AKS-Kapazität. Warten Sie, bis sie wieder als fehlerfreie Sekundärinstanz verfügbar ist, und überprüfen Sie dann Folgendes:

• Genau ein Mitglied ist PRIMARY.
• Alle anderen datenführenden Mitglieder sind SECONDARY und auf dem neuesten Stand.
• Anwendungslesevorgänge, -schreibvorgänge, wiederholbare Schreibvorgänge und Transaktionen verhalten sich wie erwartet.
• Das gemessene Wahlintervall entspricht der Anwendung RTO.
• Die Prüfungen für Sicherung und Wiederherstellung wurden erfolgreich abgeschlossen.