Wzorce aktualizacji stanowych obciążeń roboczych dla usługi Azure Kubernetes Service (AKS)

Użyj tych wzorców, aby skoordynować dostępność bazy danych ze stopniową aktualizacją puli węzłów usługi Azure Kubernetes Service (AKS).

Procedury opisane w tym artykule to struktury planowania, brak dostępności ani gwarancje trwałości danych. Wynik zależy od topologii bazy danych, trybu replikacji, magazynu, operatora, ustawień zakłóceń, zachowania ponawiania próby klienta i obciążenia. Przećwicz całą procedurę w reprezentatywnym środowisku i sprawdź, czy pozwala osiągnąć docelowy czas odtworzenia (RTO) oraz docelowy punkt odtworzenia (RPO).

Wzorce uaktualniania bazy danych omówione w tym artykule

Ten artykuł przedstawia wzorce aktualizacji specyficzne dla baz danych dla klastrów AKS z obciążeniami stanowymi, w tym:

• Kontrolowane przełączanie bazy danych PostgreSQL.
• Krocząca aktualizacja klastra Redis, zaczynając od replik.
• Aktualizacja krocząca zestawu replik MongoDB, rozpoczynana od węzłów pomocniczych.
• Listy kontrolne uaktualniania awaryjnego dla odpowiedzi na zabezpieczenia.
• Planowanie walidacji i wycofywania.

W przeciwieństwie do standardowej aktualizacji puli węzłów usługi AKS, te wzorce koordynują kontrole replikacji bazy danych i zmiany ról z wymianą węzłów Kubernetes. Administratorzy baz danych i usługi AKS mogą używać tych wzorców. Użyj udokumentowanych operacji przełączania lub uaktualniania dla operatora bazy danych, który zarządza wdrożeniem. Nie należy zastępować tych wzorców instrukcjami specyficznymi dla operatora.

Aby uzyskać więcej informacji, zobacz następujące powiązane artykuły:

• Aby uaktualnić produkcyjne klastry AKS, zobacz Strategie uaktualniania produkcyjnego usługi AKS.
• Aby porównać metody uaktualniania dla klastra usługi AKS, zobacz Opcje uaktualniania i zalecenia.
• Aby użyć centrum scenariuszy, aby ułatwić wybór odpowiedniego podejścia do uaktualniania usługi AKS, zobacz Scenariusze uaktualniania usługi AKS: Wybierz ścieżkę.

Aby uzyskać szybki start, wybierz wzorzec wdrożonego produktu i topologii:

• Lista kontrolna uaktualniania awaryjnego
• Kontrolowane przełączanie bazy danych PostgreSQL
• Uaktualnianie stopniowe repliki klastra Redis
• Uaktualnianie stopniowe zestawu replik bazy danych MongoDB

Wybieranie wzorca uaktualniania bazy danych

Lista kontrolna uaktualniania awaryjnego

Jeśli potrzebujesz przyspieszonego uaktualnienia w celu rozwiązania problemu z zabezpieczeniami, nie pomijaj kontroli kondycji i odzyskiwania bazy danych.

1. Sprawdź wymagania wstępne dotyczące obciążenia i uaktualnienia usługi AKS:

   # 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}'
   

   Sprawdź również kondycję replikacji przy użyciu polecenia obsługiwanego przez bazę danych lub operatora. Przywróć najnowszą kopię zapasową w izolowanym środowisku i upewnij się, że klienci ponawiają próby po przejściowych błędach połączenia i błędach wyboru lidera.

2. Wybierz tylko wzorzec zgodny z produktem i topologią:

   • PostgreSQL: użyj kontrolowanego przełączania.
   • Klaster Redis: Użyj aktualizacji kroczącej, zaczynając od replik.
   • Zestaw replik bazy danych MongoDB: użyj pomocniczego uaktualnienia stopniowego.

   W przypadku innych produktów baz danych postępuj zgodnie ze wskazówkami dotyczącymi uaktualniania dla tego produktu lub operatora Kubernetes.

3. Działaj z zabezpieczeniem:

   • Zawsze testuj procedury wycofywania z wyprzedzeniem.
   • Monitorowanie metryk aplikacji podczas uaktualniania.
   • Niech zespół ds. baz danych będzie w gotowości.
   • Zatrzymaj aktualizację, jeśli replikacja, kworum, pokrycie slotów lub stan aplikacji ulegną pogorszeniu.

Kontrolowane przełączanie bazy danych PostgreSQL

Użyj tego schematu kontrolowanego przełączenia dla podstawowego serwera PostgreSQL z serwerami rezerwowymi korzystającymi z replikacji strumieniowej. Przykłady pokazują kontrole stanu, ale polecenia służące do promowania, izolowania i ponownego dołączania węzłów zależą od używanego operatora PostgreSQL lub implementacji mechanizmu wysokiej dostępności.

Prerequisites

• Użyj obsługiwanej wersji bazy danych PostgreSQL i obsługiwanego operatora lub implementacji wysokiej dostępności.
• Umieść członków w domenach awarii. Skonfiguruj budżety zakłóceń dla zasobników i ograniczenia rozkładu topologicznego dla swojego wdrożenia.
• Zweryfikuj najnowszą kopię zapasową, przywracając ją w izolowanym środowisku.
• Upewnij się, że aplikacja ponownie łączy się po zmianie podstawowej.
• Zapisz polecenia specyficzne dla danego operatora dotyczące przełączenia, wycofania i ponownego dołączenia przed rozpoczęciem uaktualniania AKS.

Krok 1. Weryfikowanie topologii replikacji

Uruchom następujące zapytanie na bieżącym serwerze podstawowym:

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

Docelowy kandydat do przełączenia musi być w stanie streaming. Jeśli Twoje RPO wymaga replikacji synchronicznej, zweryfikuj również, czy kandydat ma oczekiwane sync_state dla Twojej konfiguracji.

Uruchom następujące zapytanie dotyczące zamierzonego wstrzymania:

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

Potwierdź, że pg_is_in_recovery() zwraca true oraz że lokalizacje odbioru i odtwarzania spełniają przetestowany próg przełączenia. Replikacja strumieniowa PostgreSQL jest domyślnie asynchroniczna, więc sam pod w stanie Ready nie oznacza, że serwer zapasowy nadrobił opóźnienie.

Krok 2. Wstrzymywanie zapisów i przełączanie prawyborów

Jeśli cały ruch aplikacji przechodzi przez narzędzie PgBouncer, połącz się z bazą danych administracji pgBouncer i wstrzymaj bazę danych aplikacji:

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

PAUSE oczekuje na zwolnienie połączeń serwera zgodnie ze skonfigurowanym trybem buforowania. Zanim zaczniesz polegać na tym mechanizmie, sprawdź, czy operacje zapisu aplikacji nie mogą omijać PgBouncera.

Po wstrzymaniu operacji zapisu wykonaj te akcje przy użyciu operatora lub implementacji wysokiej dostępności:

1. Sprawdź ponownie pozycje odbioru i odtwarzania WAL kandydata.
2. Uruchom obsługiwaną operację przełączania.
3. Sprawdź, czy istnieje dokładnie jeden zapisywalny element podstawowy.
4. Sprawdź, czy poprzedni węzeł podstawowy został odizolowany lub ponownie skonfigurowany jako węzeł rezerwowy.
5. Sprawdź, czy usługa zapisywania lub punkt końcowy są rozpoznawane jako nowe podstawowe.

Wznów narzędzie PgBouncer dopiero po wykonaniu tych testów:

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

Krok 3. Weryfikowanie przełączenia

# 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;"

Przetestuj operacje odczytu, zapisu, transakcji i ponownego łączenia aplikacji. Porównaj czas niedostępności zapisów oraz rezultat replikacji z wartościami RTO i RPO, zanim przejdziesz dalej.

Opcjonalna konfiguracja replikacji synchronicznej

Replikacja synchroniczna może zmniejszyć RPO dla potwierdzonych transakcji, ale zwiększa opóźnienie zatwierdzania i może zmniejszyć dostępność operacji zapisu, jeśli wymagane serwery rezerwowe nie są dostępne. Poniższy przykład oczekuje, aż dowolne dwa nazwane, bezpośrednio połączone serwery rezerwowe odtworzą każdą zatwierdzoną transakcję:

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

Wybierz synchronous_standby_names i synchronous_commit na podstawie zmierzonych opóźnień, rozmieszczenia w domenie awarii oraz wymagań dotyczących trwałości. Ta konfiguracja nie gwarantuje określonego czasu trwania przełączania.

Walidacja powodzenia

Aby zweryfikować postęp, użyj następującej listy kontrolnej:

• Nowy element podstawowy akceptuje odczyty i zapisy.
• Wszystkie repliki mają prawidłowy stan replikacji.
• Aplikacja ponownie łączy się automatycznie.
• Kontrole integralności danych i spójności aplikacji zostały pomyślnie zakończone.
• Testy tworzenia kopii zapasowych i przywracania przebiegają pomyślnie na nowym serwerze głównym.

Uaktualnij pulę węzłów usługi AKS

Operacja az aks nodepool upgrade aktualizuje całą pulę węzłów. Usługa AKS dodaje pojemność skoków, kordony i opróżnia stare węzły, odtwarza je i powtarza proces zgodnie z ustawieniami uaktualniania puli węzłów. Nie uruchamiaj polecenia raz dla każdego węzła lub ręcznie opróżnij węzły przed operacją zarządzaną.

1. Wyświetl listę obsługiwanych celów uaktualniania dla klastra:

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

2. Upewnij się, że płaszczyzna sterowania jest już w wybranej wersji docelowej. Skonfiguruj ustawienia stopniowego uaktualniania puli węzłów na podstawie przetestowanego zachowania obciążenia, limitu przydziału i dostępnych adresów podsieci. W poniższym przykładzie użyto zalecanej wartości produkcyjnej maxSurge :

   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. Uruchom jedną zarządzaną aktualizację puli węzłów, używając celu zwróconego przez az aks get-upgrades:

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

4. Monitoruj zdarzenia uaktualniania usługi AKS i kondycję bazy danych podczas całej operacji:

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

   Monitoruj replikację, dostępność bazy danych, błędy aplikacji, opóźnienie i kondycję magazynu w systemie obserwacji. Jeśli Pod Disruption Budget uniemożliwia opróżnienie węzła, rozwiąż problem z dostępnością obciążenia zamiast obchodzić ten budżet.

Weryfikowanie i odzyskiwanie

Po zakończeniu uaktualniania zarządzanego sprawdź wersje węzłów, topologię postgreSQL i zachowanie aplikacji:

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;"

Usługa AKS nie obsługuje obniżania poziomu klastra ani puli węzłów do wcześniejszej wersji platformy Kubernetes. Jeśli baza danych jest w złej kondycji, zatrzymaj zapisywanie aplikacji i użyj obsługiwanej procedury odzyskiwania lub przełączania operatora bazy danych. Nie przekierowuj zapisów do dawnego węzła głównego PostgreSQL, chyba że bezpiecznie dołączył on do bieżącej osi czasu i został awansowany przez mechanizm wysokiej dostępności. Jeśli uaktualnienie platformy Kubernetes powoduje nieodwracalny problem ze zgodnością, przywróć usługę, przenosząc obciążenie do przetestowanego klastra lub puli węzłów i przywracając lub replikując dane zgodnie z planem odzyskiwania.

Uaktualnianie stopniowe repliki klastra Redis

Użyj tego wzorca dla klastra Redis z co najmniej trzema węzłami podstawowymi i co najmniej jedną repliką dla każdego podstawowego. Udokumentowana kolejność uaktualniania węzła klastra Redis polega na pierwszym uaktualnieniu replik, ręcznym przełączeniu w tryb failover poszczególnych replik podstawowych do uaktualnionej repliki, a następnie uaktualnieniu zdegradowanej poprzedniej podstawowej repliki. Klaster Redis może zwracać błędy przejściowe lub przekierowania podczas zmian topologii. Ponieważ klaster Redis używa replikacji asynchronicznej, może utracić potwierdzone zapisy. Zweryfikuj mechanizm ponawiania prób przez klienta oraz akceptowalny poziom RPO przed uaktualnieniem.

Krok 1. Rejestrowanie i weryfikowanie topologii

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

Zapisz identyfikator każdego węzła, jego rolę, przypisanie węzła głównego do repliki oraz zakres slotów skrótu. Nie kontynuuj, chyba że zostaną uwzględnione wszystkie 16 384 gniazda, każdy podstawowy ma replikę w dobrej kondycji w innej domenie awarii, a klaster zgłasza cluster_state:ok.

Krok 2. Uaktualnianie replik

Dla każdej repliki, po jednej na raz:

1. Użyj mechanizmu wdrażania operatora lub obciążenia roboczego, aby zastąpić replikę lub uruchomić ją ponownie na zaktualizowanych zasobach usługi AKS.
2. Poczekaj, aż pod będzie gotowy i aż replikacja nadrobi zaległości.
3. Potwierdź za pomocą CLUSTER NODES, że nadal jest przypisany do oczekiwanego węzła podstawowego.

Nie uruchamiaj CLUSTER FORGET w celu ponownego uruchomienia poda, które zachowuje tożsamość węzła Redis. Jeśli element zastępczy ma nowy identyfikator węzła, użyj redis-cli --cluster add-node z --cluster-master-id i --cluster-slave, aby dodać go jako replikę zamierzonego węzła podstawowego. Poczekaj, aż nowa replika pojawi się w topologii klastra.

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>

Krok 3: Przełączenie awaryjne i uaktualnienie węzłów podstawowych

Dla każdego elementu podstawowego jeden naraz:

1. Wybierz uaktualnioną, przechwyconą replikę tego podstawowego elementu.

2. Uruchom polecenie CLUSTER FAILOVERna replice, którą chcesz awansować, a nie na bieżącym węźle głównym:

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

3. Sprawdzaj ROLE, INFO REPLICATION lub CLUSTER NODES, aż kandydat stanie się węzłem podstawowym, a poprzedni węzeł podstawowy jego repliką. Odpowiedź OK oznacza tylko, że usługa Redis zaakceptowała żądanie trybu failover.

4. Zastąp lub uruchom ponownie zdegradowany były węzeł podstawowy w ramach zaktualizowanej pojemności AKS.

5. Poczekaj, aż ponownie będzie działać jako zsynchronizowana replika, zanim przejdziesz do następnego węzła podstawowego.

Nie należy używać CLUSTER FAILOVER FORCE ani TAKEOVER podczas planowanego uaktualniania. Te opcje pomijają normalną koordynację i wymagają oddzielnych procedur odzyskiwania po awarii.

Krok 4. Weryfikowanie klastra redis

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

Sprawdź pokrycie slotów, przypisania instancji podstawowych do replik, stan replikacji, odczyty i zapisy aplikacji, obsługę przekierowań oraz obserwowany wskaźnik RPO.

Uaktualnianie stopniowe zestawu replik bazy danych MongoDB

Użyj tego wzorca dla zestawu replik bazy danych MongoDB z trzema elementami członkowskimi lub większym zestawem replik, który ma możliwość wyboru pomocniczego. Podczas ustępowania węzła podstawowego i wyboru nowego operacje zapisu kończą się niepowodzeniem, dopóki nie zostanie wybrany nowy węzeł podstawowy. Aplikacje muszą ponowić próby kwalifikujących się operacji zapisu i przejściowych transakcji zgodnie ze wskazówkami dotyczącymi sterowników bazy danych MongoDB.

Krok 1. Weryfikowanie zestawu replik

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

Upewnij się, że wszyscy oczekiwani członkowie działają prawidłowo, zidentyfikuj obecny węzeł podstawowy i sprawdź, czy co najmniej jeden węzeł wtórny, który może zostać wybrany, jest zsynchronizowany. Sprawdź również najnowszą kopię zapasową za pomocą przywracania testowego.

Krok 2: Uaktualnij serwery pomocnicze

Dla każdego drugorzędnego elementu, po jednym na raz:

1. Zastąp lub uruchom ponownie element członkowski w uaktualnionej pojemności usługi AKS przy użyciu mechanizmu wdrażania operatora lub obciążenia.

2. Poczekaj, aż pod będzie gotowy.

3. Sprawdź, czy składnik wraca do stanu SECONDARY i nadrabia zaległości przed zaktualizowaniem innego składnika.

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

Krok 3: Obniż wartość podstawową

Uruchom rs.stepDown() tylko względem bieżącego elementu podstawowego. Pierwszy argument określa, jak długo nie można ponownie wybrać poprzedniego podstawowego. Drugi argument określa, ile czasu wybieralny węzeł pomocniczy ma na nadrobienie zaległości. Wybierz wartości na podstawie przetestowanego zachowania wyborczego.

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

Polecenie może odłączyć lub zwrócić błąd jako podstawowe kroki w dół. Sprawdzaj stan zestawu replikacji z poziomu innego członka, aż zostanie wybrany dokładnie jeden nowy węzeł podstawowy:

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

Jeśli żaden pomocniczy węzeł kwalifikujący się do wyboru nie nadrobi zaległości w skonfigurowanym czasie, węzeł podstawowy nie zrezygnuje ze swojej roli. Rozwiąż problemy ze stanem replikacji przed ponowieniem próby. Nie wymuszaj przełączenia na niższy poziom podczas planowanej aktualizacji.

Krok 4. Uaktualnianie i weryfikowanie poprzedniego podstawowego elementu

Zastąp lub uruchom ponownie poprzedni element podstawowy w uaktualnionej pojemności usługi AKS. Poczekaj, aż powróci jako pomocnicza w dobrej kondycji, a następnie zweryfikuj:

• Dokładnie jeden członek ma wartość PRIMARY.
• Wszystkie inne elementy nośne danych są SECONDARY i są uwikłane.
• Odczyty aplikacji, zapisy aplikacji, operacje zapisu z ponawianiem prób i transakcje zachowują się zgodnie z oczekiwaniami.
• Zmierzony czas elekcji spełnia wymaganie RTO aplikacji.
• Kontrole kopii zapasowej i przywracania zakończyły się pomyślnie.