Tworzenie mechanizmów odzyskiwania po awarii za pomocą Amazon Route 53

W przypadku wielu aplikacji wdrożenie w wielu strefach dostępności w jednym regionie AWS i dostosowanie do AWS Well-Architected Framework zapewnia odpowiednią równowagę dostępności, prostoty i przystępności. Jednak niektórzy klienci mogą mieć wyjątkowe powody, które wymagają rozszerzenia na dodatkowe regiony w konfiguracji typu active-active lub active-standby odzyskiwania po awarii (DR).

W scenariuszu DR potrzebujesz prostego i skutecznego podejścia do łagodzenia awarii, a następnie powrotu do normalnych operacji. Aby być szybkim i niezawodnym, proces ten musi być prosty, wymagający minimalnych kroków i regularnie praktykowany. W celu przełączenia awaryjnego wiele firm zmienia swoje rekordy DNS. W tym artykule przedstawiono, jak używać aktualizacji systemu DNS do skutecznego odzyskiwania po awarii, a także podkreślono zasady i najlepsze sposoby, które należy zastosować, stosując to podejście.

Nowoczesne usługi DNS, takie jak Amazon Route 53, oferują kontrole stanu i rekordy pracy awaryjnej, które można wykorzystać do uproszczenia i wzmocnienia planu DR. Twórcy rozpoczęli od opisania, w jaki sposób usługi AWS zapewniają niezawodność za pomocą płaszczyzn kontroli i płaszczyzn danych, a następnie udostępnili zasady projektowania wysokiego poziomu w celu utworzenia mechanizmu przełączania awaryjnego. Na koniec wyjaśnili cechy Route 53, które mogą sprawić, że podejście DR będzie bardziej efektywne.

Płaszczyzny kontroli i płaszczyzny danych

Większość usług AWS obejmuje płaszczyznę danych, która zapewnia podstawową funkcjonalność usługi oraz płaszczyznę kontroli, która umożliwia tworzenie, aktualizowanie i usuwanie zasobów. Regionalne usługi AWS, takie jak Amazon Elastic Compute Cloud (Amazon EC2), posiadają regionalne punkty końcowe usług, które łączą Cię z płaszczyzną kontroli usługi w określonym regionie AWS. Jednak niektóre usługi AWS są rozmieszczone w wielu lokalizacjach na całym świecie, takich jak Amazon CloudFront, AWS Identity and Access Management (IAM) oraz Route 53. Płaszczyzna kontroli dla tych globalnych usług jest dostępna tylko we wschodnich stanach USA (Płn. Wirginia, Region (us-east-1). Podobnie AWS Global Accelerator i Amazon Route 53 Application Recovery Controller (Route 53 ARC) to usługi globalne z płaszczyznami kontrolnymi zlokalizowanymi w regionie US West (Oregon) (us-west-2). Aby utworzyć i skonfigurować zasoby w tych usługach globalnych, należy użyć punktu końcowego interfejsu API w regionie, w którym znajduje się ich płaszczyzna kontroli.

Płaszczyzny danych Route 53 odpowiadają na zapytania DNS oraz wykonują i oceniają kontrole kondycji. Są one dystrybuowane globalnie i zaprojektowane pod kątem umowy dotyczącej poziomu usług (SLA) o 100% dostępności. Interfejsy API i konsole zarządzania Route 53, w których tworzysz, aktualizujesz i usuwasz zasoby Route 53, działają na płaszczyznach kontroli, które mają na celu nadanie priorytetu silnej spójności i trwałości potrzebnej podczas zarządzania systemem DNS. Aby to osiągnąć, płaszczyzny kontrolne znajdują się w jednym regionie, US East (Płn. Wirginia). Chociaż oba systemy są zbudowane tak, aby były bardzo niezawodne, płaszczyzny sterowania nie są objęte umową SLA. Mogą wystąpić rzadkie zdarzenia, w których elastyczna konstrukcja płaszczyzny danych pozwala na utrzymanie dostępności, podczas gdy płaszczyzny kontrolne nie. Z tego powodu zaleca się, aby mechanizmy odzyskiwania po awarii i pracy awaryjnej wykorzystywały funkcje płaszczyzny danych, aby zapewnić najlepszą możliwą niezawodność.

Aby uzyskać więcej informacji o płaszczyznach danych, płaszczyznach kontroli i sposobie, w jaki AWS buduje usługi, aby spełnić cele wysokiej dostępności, zapoznaj się z artykułem Stabilność statyczna przy użyciu stref dostępności.

Ze względu na to, że Route 53 posiada płaszczyznę danych zaprojektowaną pod kątem umowy SLA o 100% dostępności, dobre mechanizmy przełączania awaryjnego powinny opierać się na płaszczyźnie danych, a nie na płaszczyźnie kontroli. W dalszej części tego artykułu zostaną omówione sposoby wprowadzania ukierunkowanych zmian w Route 53, które nie obejmują płaszczyzny kontrolnej. Najpierw przyjrzyj się kilku najlepszym praktykom, które należy zastosować podczas tworzenia skutecznego mechanizmu przełączania awaryjnego DR.

Projektowanie niezawodnego mechanizmu przełączania awaryjnego

Podczas projektowania planu odzyskiwania po awarii ważne jest, aby zastanowić się, w jaki sposób upewnisz się, że mechanizm przełączania awaryjnego jest odporny i dostępny, gdy jest potrzebny. Mechanizmy te powinny być proste, mieć jak najmniej zależności i być dokładnie przetestowane. Choć może się to wydawać oczywiste, łatwo przeoczyć zależności, które działają podczas testu, ale przechodzą w stan niepowodzenia podczas katastrofy.

Aby stworzyć analogię ze świata fizycznego, potrzebujesz zapasowego generatora energii, gdy zasilanie z sieci nie jest dostępne. Dlatego niezawodny mechanizm przełączania awaryjnego nie może zależeć od zasilania z sieci w celu uruchomienia ani do samodzielnego przełączania awaryjnego. Ponadto, ponieważ zasilanie z sieci jest zwykle dostępne podczas uruchamiania testów z konfiguracją przełączania awaryjnego, należy upewnić się, że nie jest to ukryte uzależnienie od tego zasilania.

Rozważ następujące zasady podczas budowania mechanizmu przełączania awaryjnego. Następnie w kolejnych sekcjach przyjrzysz się rozwiązaniom opartym na Route 53, które uwzględniają te zasady.

• Użyj funkcji płaszczyzny danych. Zaprojektuj mechanizmy przełączania awaryjnego, aby korzystać z funkcji płaszczyzny danych w celu uzyskania największej niezawodności i odporności na uszkodzenia. Na przykład wybierz mechanizmy, które używają kontroli kondycji Route 53 (funkcje płaszczyzny danych), zamiast aktualizować rekordy DNS w strefach hostowanych lub konfiguracje kontroli kondycji (funkcje płaszczyzny kontrolnej).
• Kontroluj przełączanie awaryjne z regionu gotowości. Przełączanie awaryjne na wiele regionów jest potężne, ponieważ budujemy każdy region AWS tak, aby był niezależny i odizolowany od innych regionów. Podczas projektowania mechanizmów przełączania awaryjnego z uszkodzonej aplikacji w jednym regionie, upewnij się, że nie musisz wprowadzać zmian w tym regionie. Zamiast tego zainicjuj przełączanie awaryjne, wprowadzając zmiany w zdrowym regionie gotowości.
• Zrozum i zmniejsz zależności, aby praca awaryjna była bardziej niezawodna. Zaplanuj wszystkie wewnętrzne i zewnętrzne zależności, które będą potrzebne do zainicjowania i koordynowania pomyślnego przełączenia awaryjnego. Minimalizacja liczby zależności w procesie przełączania awaryjnego zmniejsza potencjalne punkty błędów, czyniąc go bardziej niezawodnym. Na przykład użyj wywołań AWS CLI lub SDK w procesie przełączania awaryjnego zamiast konsoli zarządzania AWS, ponieważ konsola jest dodanym składnikiem interfejsu użytkownika, który wprowadza dalsze zależności.
• Przygotuj wstępne elemeny o znaczeniu krytycznym. Unikaj zależności płaszczyzny sterowania podczas tworzenia krytycznych składników podczas zdarzenia, wstępnie udostępniając zasoby do obsługi pełnych lub częściowych obciążeń. Pomaga to osiągnąć cele odzyskiwania po awarii (RTO i RPO), ale wymaga zrównoważenia kosztów z celami odzyskiwania. Jeśli to możliwe, wcześniejsze tworzenie i skalowanie zasobów pomaga również zapobiegać ograniczeniom pojemności w regionie gotowości.
• Przejrzyj metody uwierzytelniania. Zastanów się, jak przeprowadzasz uwierzytelnianie w celu zarządzania usługami AWS. Na przykład organizacja AWS może jednocześnie obsługiwać jednokrotne logowanie AWS (AWS SSO) tylko w jednym regionie. Jeśli logowanie jednokrotne AWS jest uszkodzone w tym regionie, będziesz musiał użyć osobnych poświadczeń, które ominą typowy proces i nie będą polegać na logowaniu jednokrotnym AWS. Użytkownik IAM z rozbiciem szkła spełniłby to wymaganie, ponieważ uwierzytelnianie IAM opiera się na dostępnej na całym świecie płaszczyźnie danych IAM.
• Testuj regularnie. Aby wzmocnić pewność, że mechanizm przełączania awaryjnego będzie działał w przypadku awarii, ważne jest regularne testowanie procesu. Testowanie weryfikuje, czy Twoje plany DR są aktualne i można je pomyślnie przeprowadzić w razie potrzeby.

Pora przyjrzeć się trzem sposobom wykorzystania różnych funkcji Route 53 w celu przestrzegania tych zasad i utworzenia mechanizmu przełączania awaryjnego w ramach planu odzyskiwania po awarii.

Kontrole stanu Route 53

Kontrole stanu Route 53 wysyłają żądania do zasobów z ośmiu różnych regionów AWS, aby zweryfikować ich dostępność. Zintegrowano kontrole stanu z globalnie rozproszoną płaszczyzną danych Route 53, aby zapewnić wyjątkową niezawodność. Kontrola stanu Route 53 może monitorować następujące elementy:

• Punkt końcowy TCP, HTTP lub HTTPS
• Status innych kontroli stanu Route 53
• Stan alarmu Amazon CloudWatch
• Stan kontroli routingu Route 53 Application Recovery Controller

Kontrole kondycji Route 53 są zwracane tak długo, jak co najmniej 18% globalnych kontrolerów kondycji zgłasza, że punkt końcowy odpowiada w dobrej kondycji. Domyślnie co najmniej 3 z 16 kontrolerów (18,75%) musi raportować jako zdrowe, aby Route 53 uznała, że punkt końcowy jest w dobrym stanie.

Te zabezpieczenia pomagają zapobiegać błędnym awariom. Muszą występować spójne, powtarzające się awarie, aby kontrola kondycji była „niezdrowa”. Kontrola kondycji nie zakończy się niepowodzeniem, jeśli waha się między zdrową a niezdrową lub jeśli niewielki podzbiór programów sprawdzających zgłosi złą kondycję, na przykład z powodu problemów z siecią lokalną. Można ustawić zarówno regiony sprawdzania kondycji, jak i progi błędów sprawdzania.

Serwer DNS można skonfigurować tak, aby automatycznie przełączał się w tryb awaryjny, korzystając z zasad routingu awaryjnego z kontrolą kondycji. W tym scenariuszu rekordy pracy awaryjnej Route 53 zwracają zasób podstawowy dla zapytania DNS, gdy zasób jest w dobrej kondycji. Jeśli zasób będzie w złej kondycji, a drugorzędny jest w dobrej kondycji, Route 53 automatycznie aktualizuje i odpowiada rekordem pomocniczym (to znaczy przechodzi w tryb awaryjny). Jeśli zarówno rekord podstawowy, jak i pomocniczy są w złej kondycji, zwraca rekord podstawowy.

Rysunek nr 1 przedstawia konfigurację aktywno-pasywną z przełączaniem awaryjnym DNS Route 53. Problem w regionie podstawowym skutkujący niepowodzeniem kontroli kondycji (HC-Primary) inicjuje automatyczne przełączanie awaryjne do rekordu pomocniczego.

Automatyczne odzyskiwanie poprzez kontrole stanu jest proste w konfiguracji i wysoce niezawodne, bez zależności od płaszczyzny kontrolnej Route 53. Gdy kontrola kondycji zmienia stan, Route 53 aktualizuje rekord skojarzony z kontrolą kondycji przy użyciu płaszczyzny danych Route 53.

Jeśli jednak używasz kontroli kondycji do automatycznego przełączania awaryjnego, nie będziesz w stanie wymusić przełączania awaryjnego, jeśli wystąpią sporadyczne problemy. Ponadto nie należy polegać na interfejsach API kontroli stanu Route 53, aby wymusić przełączanie awaryjne, ponieważ spowodowałoby to dodanie zależności płaszczyzny sterowania.

Opisane tutaj bezpośrednie sprawdzanie kondycji zasobów najlepiej pasuje do architektur typu aktywny-aktywny. W tych scenariuszach zadaniem kontroli kondycji jest po prostu usunięcie jednego wadliwego punktu końcowego z grupy aktywnych punktów końcowych. Jeśli punkt końcowy później zacznie przekazywać kontrole kondycji, automatyczne przywrócenie go do usługi powinno być bezpieczne. W tej konfiguracji przełączanie awaryjne i przywrócenie są automatyczne i nie wymagają interwencji użytkownika.

Jednak w przypadku większości planów odzyskiwania po awarii bardziej powszechna jest architektura aktywnego trybu gotowości. Pomyślne przełączenie awaryjne jest często częścią sekwencji kroków, takich jak przełączenie awaryjne bazy danych i skalowanie pojemności rezerwowej. W wieloetapowym procesie odzyskiwania potrzebna jest większa bezpośrednia kontrola nad przełączaniem awaryjnym i powrotem po awarii niż zapewnia automatyczne sprawdzanie kondycji.

Chociaż kontrole kondycji Route 53 są często używane do bezpośredniego sondowania kondycji zasobów, można ich również używać jako systemu sygnalizacji. Konfigurując kontrole kondycji w celu sprawdzenia innych kontrolowanych usług internetowych, takich jak istnienie plików w zasobnikach S3, możesz niezawodnie sygnalizować płaszczyźnie danych DNS Route 53, aby zainicjować przełączanie awaryjne. Następne dwie sekcje wyjaśniają, jak z tego skorzystać, aby bezpośrednio kontrolować przełączanie awaryjne.

Route 53 Application Recovery Controller

Kontroler odzyskiwania aplikacji Amazon Route 53 (Route 53 ARC) zapewnia pełną kontrolę w przypadku awarii aplikacji o wysokiej dostępności. Gwarantuje dwie funkcje do zarządzania i pomyślnego przełączania awaryjnego: kontrole gotowości i kontrole routingu. Kontrole gotowości pomagają upewnić się, że systemy rezerwowe są gotowe do przełączenia awaryjnego, a kontrolki routingu umożliwiają ręczne lub programowe zainicjowanie przełączania awaryjnego przy użyciu interfejsu API płaszczyzny danych o wysokiej dostępności bez jakiejkolwiek zależności od płaszczyzny kontrolnej Route 53.

Kontrola routingu Route 53 ARC to przełącznik włączania/wyłączania, który zmienia stan kontroli kondycji Route 53, która aktualizuje wpis DNS i przekierowuje ruch, na przykład z wdrożenia podstawowego do gotowości.

Twoje kontrolki routingu są przyjmowane w dedykowanym klastrze, który tworzy płaszczyznę danych w pięciu geograficznie odizolowanych regionach AWS. Klaster działa w modelu kworum, co oznacza, że kontrolki klastra i routingu nadal działają i zapewniają kontrolę pracy awaryjnej, nawet jeśli maksymalnie dwa regionalne punkty końcowe są niedostępne. Każdy klaster zawiera pięć niezależnych punktów końcowych interfejsu API, po jednym w każdym regionie, dzięki czemu można zaktualizować stan kontroli routingu przy użyciu dowolnego z pięciu punktów końcowych.

Kontrolki routingu Route 53 ARC mają najmniejszą liczbę zależności, a każda zależność jest wyjątkowo niezawodna sama w sobie. Wprowadzając zmiany w stanach kontroli routingu, opierasz się na trzech poniższych kryteriach, które z dużym prawdopodobieństwem nie zawiodą:

• Co najmniej trzy z pięciu punktów końcowych są dostępne i biorą udział w kworum.
• Masz działające poświadczenia uprawnień i możesz uwierzytelnić się względem działającego regionalnego punktu końcowego klastra.
• Płaszczyzna danych Route 53 jest w dobrym stanie (ta płaszczyzna danych została zaprojektowana w celu spełnienia umowy SLA o 100% dostępności).

Po zaktualizowaniu stanu kontroli routingu zmiana jest propagowana przez kontrole kondycji Route 53, a następnie do rekordu DNS w Route 53. Ze względu na to, że kontrolki routingu Route 53 ARC są zaprojektowane tak, aby były wysoce dostępne i nie są zaangażowane żadne operacje interfejsu API płaszczyzny kontroli, zmiana jest przeprowadzana w sposób wiarygodny.

Kontrolki routingu obejmują również konfigurowalne reguły bezpieczeństwa, które umożliwiają definiowanie barier ochronnych dla operacji przełączania awaryjnego. Dzięki regułom bezpieczeństwa można jawnie zdefiniować bariery ochronne, aby klaster wymuszał je i odrzucał każdą zmianę stanu, która łamie regułę. Oto kilka przykładów:

• W architekturze aktywnej gotowości może istnieć reguła, zgodnie z którą tylko jeden punkt końcowy (aktywny lub w trybie gotowości) może być jednocześnie włączony i obsługiwany.
• W architekturze aktywny-aktywny może istnieć reguła, która ogranicza liczbę replik aplikacji, które są jednocześnie przełączane w tryb offline. Pomaga to uniemożliwić różnym operatorom lub komponentom automatyki zmniejszenie wydajności poniżej bezpiecznych limitów. Zmiany są przetwarzane w kolejności, w jakiej przychodzą żądania wraz z kontrolą, aby upewnić się, że wymagana liczba replik jest nadal w użyciu.

Kontrole gotowości Route 53 ARC monitorują i weryfikują, czy przydziały zasobów, pojemność i inne konfiguracje są prawidłowo skonfigurowane w replikach aplikacji. Te kontrole pomagają utrzymać aplikację w bezpiecznym stanie, dzięki czemu w razie potrzeby można przełączyć się na replikę. Na przykład w architekturach aktywno-pasywnych może się okazać, że aplikacja podstawowa musi zostać przeskalowana lub zmieniona w inny sposób. Kontrole gotowości zapewniają niezawodny mechanizm, aby upewnić się, że aplikacja w trybie gotowości jest również skalowana w górę.

Rysunek nr 2 ilustruje wdrożenie Route 53 ARC z aplikacją w konfiguracji aktywnego czuwania:

Możesz zauważyć, że region A (podstawowy) i region B (w trybie gotowości) mają identyczne aplikacje z modułem równoważenia obciążenia aplikacji, grupą automatycznego skalowania EC2 i tabelą DynamoDB. Ponadto warto zwrócić uwagę na następujące kwestie:

• Autorzy stworzyli testy gotowości, aby móc monitorować gotowość repliki awaryjnej w regionie gotowości.
• Autorzy stworzyli alarmy CloudWatch, które ostrzegają, gdy poszczególne kontrole gotowości zwracają wartości NOT READY.
• Jeśli wystąpi problem z aplikacją w regionie A, możemy wykonać wywołanie interfejsu API kontroli routingu do dowolnego z pięciu punktów końcowych płaszczyzny danych klastra Route 53 ARC w regionie 1-5. Aktualizacja stanu kontroli routingu powoduje zmianę stanu kontroli stanu rekordu zasobu Route 53 dla Twojej aplikacji i przeniesienie ruchu do regionu B.

Po skonfigurowaniu aplikacji z kontrolkami routingu Route 53 ARC do przełączania awaryjnego, upewnij się, że jesteś gotowy na nieoczekiwane zdarzenie. Aby przygotować się do użycia Route 53 ARC w scenariuszu odzyskiwania po awarii, wykonaj następujące czynności:

• Płaszczyzna danych Route 53 ARC została zaprojektowana tak, aby była wysoce elastyczna, dlatego należy zaplanować korzystanie z operacji interfejsu API kontroli routingu do uzyskiwania i aktualizowania stanów kontroli routingu dla aktualizacji produkcyjnych. Unikaj zależności od płaszczyzn sterowania, takich jak konsola Route 53 ARC lub operacje interfejsu API konfiguracji sterowania odzyskiwaniem, które są dostępne tylko w regionie zachodnich stanów USA (Oregon) (us-west-2).
• Zapisz pięć adresów URL punktów końcowych klastra dla Route 53 ARC w bezpiecznym miejscu, takim jak książka uruchamiania DR lub skrypt, dzięki czemu nie musisz polegać na płaszczyźnie kontrolnej, aby wyszukiwać je podczas zdarzenia.
• Zapisz nazwy zasobów Amazon (ARN) kontroli routingu w bezpiecznym miejscu, takim jak książka uruchamiania DR lub skrypt. Ponownie, ma to na celu uniknięcie zależności od płaszczyzny kontrolnej Route 53 ARC.
• Upewnij się, że będziesz mieć dostęp do danych uwierzytelniających, które będą potrzebne do przełączenia awaryjnego w przypadku katastrofy.

Aby uzyskać więcej informacji, zobacz Najlepsze praktyki w Przewodniku programisty Route 53 ARC.

Route 53 ARC oferuje najbardziej bogate w funkcje rozwiązanie do przełączania awaryjnego spośród tych omówionych w tym artykule. Jednak w niektórych przypadkach konfiguracja może być bardziej skomplikowana, a wieloregionalny klaster Route 53 ARC może okazać się bardziej kosztowny niż inne rozwiązania.

Następnie pora przyjrzeć się prostemu i opłacalnemu sposobowi korzystania z niezależnych kontroli kondycji Route 53 w celu zainicjowania przełączania awaryjnego z regionu gotowości.

Tryb gotowości przejmuje kontrolę nad podstawowym

Trzecie zalecenie dotyczące przełączania awaryjnego przy użyciu funkcji Route 53 to proces, który określa się jako „stan gotowości przejmuje obsługę podstawową” (STOP). Ta strategia zależy od zdrowego regionu gotowości i aplikacji. W tym rozwiązaniu do sterowania przełączaniem awaryjnym używany jest zasób (kontrola kondycji) w regionie gotowości. Pozwala to na zainicjowanie przełączania awaryjnego bez uzależnienia od zasobów w regionie podstawowym.

To rozwiązanie wykorzystuje co najmniej jedną kontrolę kondycji, która sprawdza stan zasobu w regionie gotowości. Spójrzmy na przykład tej architektury.

Zaczynij od kontroli stanu Route 53, HC-Initiate-Disaster-Recovery, która jest skojarzona z rekordem DNS Route 53 dla Twojej aplikacji w regionie podstawowym (Region A). Ta kontrola kondycji wyszukuje warunek, który umożliwia operatorowi (lub automatyzacji) zadeklarowanie podstawowej aplikacji „w złej kondycji” i inicjuje pracę awaryjną. Warunek jest prosty; w Twoim przypadku wykorzystujesz obecność lub brak pliku, który tworzysz lub usuwasz w Regionie gotowości.

W szczególności kontrola kondycji szuka pliku w publicznej witrynie sieci Web S3:

https://.s3..amazonaws.com/initiate-failover.html

Jeśli plik nie istnieje, (odwrócony) wynik kontroli kondycji jest „zdrowy” i nie następuje przełączenie awaryjne.

Użyj odwróconej kontroli kondycji, aby zabezpieczyć się przed przypadkowym zainicjowaniem pracy awaryjnej, jeśli zasób w regionie gotowości ulegnie awarii. Kontrola kondycji jest skojarzona z rekordem DNS w regionie podstawowym (aplikacja), ale konfigurujesz odwróconą kontrolę kondycji, aby sondować kondycję zasobu w regionie gotowości (pliku), którego używasz do kontrolowania stanu kontroli kondycji.

Aby zainicjować przełączanie awaryjne, utwórz plik S3, którego szuka kontrola stanu: „initiate-failover.html”. Informuje to kontrolę stanu, że region podstawowy jest „w złej kondycji”, powodując przełączenie ruchu z regionu podstawowego (Region A) do regionu pomocniczego (Region B).

Rysunek 3 ilustruje konfigurację kontroli stanu Route 53, zasad routingu i rekordów przełączania awaryjnego dla tej strategii:

Kontrola stanu posiada następującą konfigurację:

• Kontrola stanu: HC-Initiate-Disaster-Recovery
• Powiązany z rekordem DNS aplikacji w regionie podstawowym.
• Sprawdza zasób znajdujący się w regionie gotowości.
• Odwrócona kontrola kondycji jest zawsze poprawna, jeśli odpowiedzią jest HTTP 4xx, 5xx lub limit czasu. Dzięki temu ruch będzie nadal kierowany do regionu podstawowego.
• Działanie inicjujące kontrolowane przez operatora (takie jak tworzenie pliku) aktualizuje zasób, aby zwrócić HTTP 2xx lub 3xx w celu zainicjowania przełączenia awaryjnego.

Zaleca się, jeśli to możliwe, wyrównanie aktywności inicjowania pracy awaryjnej z istniejącymi zależnościami dla aplikacji rezerwowej. Na przykład, jeśli aplikacja rezerwowa jest już zależna od dostępu do odczytu/zapisu do S3, nie będziesz dodawać nowej zależności za pomocą działania inicjującego, które umieszcza utworzony plik w zasobniku S3. Alternatywnie, jeśli aplikacja rezerwowa zależy od DynamoDB, możesz utworzyć w aplikacji procedurę obsługi sprawdzania kondycji, która odpowiada na podstawie rekordu aktualizowanego w tabeli DynamoDB.

Możesz łatwo zintegrować aktywność inicjowania przełączania awaryjnego z istniejącą automatyzacją przełączania awaryjnego, jeśli na przykład używasz już dokumentu automatyzacji AWS Systems Manager do przygotowania zasobów do przełączania awaryjnego. Dodaj nową akcję na końcu dokumentu, która wywołuje działanie inicjowania pracy awaryjnej, a następnie operator może uruchomić automatyzację w celu przygotowania zasobów i przełączenia awaryjnego.

Po odzyskaniu podstawowego stosu masz dwie możliwości cofnięcia. Jeśli chcesz wrócić do Regionu podstawowego, cofasz zmianę, której dokonałeś, aby spowodować przełączenie Route 53 z powrotem. Alternatywnie, jeśli wolisz uniknąć wpływu drugiej pracy awaryjnej, możesz zaktualizować zestawy rekordów Route 53, aby zamienić role zestawu rekordów pracy awaryjnej: podstawowy i rezerwowy.

Ze względu na to, że rozwiązanie wykorzystuje kontrole kondycji Route 53 i typ routingu pracy awaryjnej, obejmuje kontrolki i kontrole bezpieczeństwa tych funkcji Route 53. Ponadto stosowanie tej strategii oznacza minimalne koszty, ponieważ opiera się ona głównie na cenach kontroli stanu Route 53. Jeśli musisz regularnie przeprowadzać audyt gotowości do pracy w trybie failover (zalecane), kontrole gotowości Route 53 ARC działają również z tym wzorcem pracy w trybie failover.

Podsumowanie

W tym artykule autorzy przedstawili trzy strategie odzyskiwania po awarii, które można rozważyć, korzystając z funkcji Amazon Route 53, aby szybko i niezawodnie przełączyć się w tryb awaryjny, aby zminimalizować przestoje spowodowane zdarzeniem.

Omówiono możliwe kompromisy związane z każdą strategią. Kontrole kondycji Route 53 są dystrybuowane globalnie i działają niezawodnie nawet podczas ważnych zdarzeń serwisowych. Płaszczyzna danych kontrolera odzyskiwania aplikacji Route 53 jest wieloregionalna i może tolerować awarię maksymalnie dwóch regionalnych punktów końcowych. Wreszcie, podejście „standby takes over primary” zapewnia, że można przejść w tryb awaryjny bez żadnej zależności od regionu podstawowego.

Każda z tych strategii daje opcje do rozważenia podczas tworzenia mechanizmów odzyskiwania po awarii, które są odporne i ograniczają zależności systemów, na których polegasz podczas awarii.

Źródło: AWS