Minimalizowanie zależności w Planie Odzyskiwania po Awarii

Oficjalny dokument Availability and Beyond omawia koncepcję stabilności statycznej w celu poprawy odporności. Co oznacza stabilność statyczna w odniesieniu do wieloregionalnego planu odzyskiwania po awarii (DR)? Co się stanie, jeśli na same narzędzia, na których polegamy w celu przełączenia awaryjnego, ma wpływ zdarzenie DR?

Z tego artykułu dowiesz się, jak zmniejszyć zależności w planie DR i ręcznie kontrolować przełączanie awaryjne, nawet jeśli krytyczne usługi AWS zostaną zakłócone. Jako bonus zobaczysz, jak używać zasad kontroli usług (SCP) do symulacji awarii regionalnej, dzięki czemu możesz w bardziej realistyczny sposób testować scenariusze przełączania awaryjnego.

Zależności i względy planu awaryjnego

Pora przyjrzeć się bardziej szczegółowo scenariuszowi DR. Używanie Amazon Route 53 do regionalnego routingu awaryjnego jest powszechnym wzorcem zdarzeń DR. W najprostszym przypadku wdrożono aplikację w Regionie podstawowym i Regionie zapasowym. Dostępny jest zestaw rekordów DNS Route 53 z rekordami dla obu regionów, a cały ruch jest kierowany do regionu podstawowego. W przypadku uruchomienia planu DR ręcznie lub automatycznie przełącza się rekordy DNS, aby skierować cały ruch do regionu kopii zapasowej.

Poleganie na automatycznej kontroli kondycji w celu kontrolowania regionalnego przełączania awaryjnego może być trudne. Kontrola kondycji może nie być całkowicie wiarygodna, jeśli region doświadcza pewnego rodzaju degradacji. Często wolimy zainicjować nasz plan DR ręcznie, który następnie inicjuje się wraz z automatyzacją.

Jakie zależności umieszczono w tym planie przełączania awaryjnego? Po pierwsze, musi być dostępna Route 53, nasza usługa DNS. Musi nadal obsługiwać zapytania DNS i mieć możliwość ręcznej zmiany rekordów DNS. Po drugie, jeśli nie posiadasz pełnego zestawu zasobów już wdrożonych w regionie kopii zapasowej, musisz mieć możliwość wdrożenia w nim zasobów.

Obie zależności mogą naruszać stabilność statyczną, ponieważ polegasz na zasobach w swoim planie DR, na które może mieć wpływ obserwowana awaria. W idealnym przypadku nie chcesz polegać na uruchomionych innych usługach, dzięki czemu możesz przełączyć się w tryb awaryjny i nadal obsługiwać swój własny ruch. Jak zredukować dodatkowe zależności?

Stabilność statyczna

Przyjrzyjmy się pierwszej zależności Route 53 – płaszczyznom kontrolnym i płaszczyznom danych. Krótko mówiąc, płaszczyzna kontroli służy do konfigurowania zasobów, a płaszczyzna danych dostarcza usługi (zobacz: Opis potrzeb w zakresie dostępności, aby uzyskać pełniejszą definicję).

Płaszczyzna danych Route 53, która odpowiada na zapytania DNS, jest wysoce odporna na wszystkie regiony. Możesz na niej śmiało polegać podczas niepowodzenia jakiegokolwiek Regionu. Załóżmy jednak, że z jakiegoś powodu nie jesteś w stanie wezwać płaszczyzny sterowania Route 53.

Kontroler odzyskiwania aplikacji Amazon Route 53 (Route 53 ARC) został stworzony do obsługi tego scenariusza. Zapewnia kontrolę stanu Route 53, którą możemy ręcznie kontrolować za pomocą kontroli routingu Route 53 ARC i jest operacją na płaszczyźnie danych. Płaszczyzna danych Route 53 ARC jest wysoce elastyczna, wykorzystując klaster pięciu regionalnych punktów końcowych. Możesz skorygować „test wydajności”, jeśli dostępne są trzy z pięciu regionów.

Druga zależność, możliwość wdrażania zasobów w drugim regionie, nie stanowi problemu, jeśli uruchomisz w pełni skalowany zestaw zasobów. Musisz upewnić się, że mechanizm wdrażania nie opiera się tylko na Regionie podstawowym. Większość usług AWS ma regionalne płaszczyzny kontrolne, więc nie stanowi to problemu.

Płaszczyzna danych AWS Identity and Access Management (IAM) jest wysoce dostępna w każdym regionie, więc możesz autoryzować tworzenie nowych zasobów, o ile już zdefiniowałeś role. Uwaga: W przypadku korzystania z uwierzytelniania federacyjnego za pośrednictwem dostawcy tożsamości należy sprawdzić, czy sam dostawca tożsamości nie jest zależny od innego regionu.

Testowanie planu odzyskiwania po awarii

Po zidentyfikowaniu naszych zależności musisz zdecydować, jak zasymulować scenariusz katastrofy. Dwa mechanizmy, których możesz do tego użyć, to listy kontroli dostępu do sieci (NACL) i SCP. Pierwsza z nich umożliwia ograniczenie ruchu sieciowego do punktów końcowych naszych usług. Druga natomiast umożliwia zdefiniowanie polityk, które określają maksymalne uprawnienia dla kont docelowych. Pozwala również symulować awarię płaszczyzny kontrolnej Route 53 lub IAM poprzez ograniczenie dostępu do usługi.

Na potrzeby kompleksowej symulacji DR opublikowano repozytorium próbek AWS na GitHub, którego możesz użyć do wdrożenia. Ocenia to możliwości Route 53 ARC, jeśli zarówno płaszczyzny kontrolne Route 53, jak i IAM nie są dostępne.

Wdrażając aplikacje testowe w regionach AWS us-east-1 i us-west-1, możesz symulować rzeczywisty scenariusz, który określa wpływ na ciągłość biznesową, czas przełączania awaryjnego i procedury wymagane do pomyślnego przełączania awaryjnego z niedostępnymi płaszczyznami kontrolnymi.

Przed przeprowadzeniem testu opisanego w scenariuszu twórcy zdecydowanie zalecają utworzenie dedykowanego środowiska testowego AWS z konfiguracją AWS Organizations. Upewnij się, że nie dołączasz SCP do katalogu głównego organizacji, ale zamiast tego tworzysz dedykowaną jednostkę organizacyjną (OU). Możesz użyć tego wzorca, aby przetestować SCP i upewnić się, że nie zablokujesz przypadkowo użytkowników z kluczowych usług.

Inżynieria chaosu

Inżynieria chaosu to dyscyplina polegająca na eksperymentowaniu na systemie w celu zbudowania pewności co do jego zdolności do wytrzymania niespokojnych warunków produkcji. Inżynieria chaosu i jej zasady są ważnymi narzędziami podczas planowania odzyskiwania po awarii. Nawet prosty system rozproszony może być zbyt złożony, aby działać niezawodnie. Zaplanowanie każdego scenariusza awarii w nietrywialnych systemach rozproszonych może być trudne lub niemożliwe ze względu na liczbę permutacji awarii. Eksperymenty Chaosu sprawdzają te niewiadome, wprowadzając awarie (na przykład wyłączanie instancji EC2) lub przemijające anomalie (na przykład niezwykle wysokie opóźnienie w sieci).

W kontekście wieloregionalnego DR techniki te mogą pomóc w podważeniu założeń i ujawnieniu słabych punktów. Na przykład, co się stanie, jeśli kontrola zakończy się pomyślnie, ale sam system jest w złej kondycji lub na odwrót? Co zrobisz, jeśli cały system monitorowania jest w trybie offline w Twoim regionie podstawowym lub jest zbyt wolny, aby był użyteczny? Czy istnieją operacje samolotów kontrolnych, na których polegasz, które same zależą od kondycji pojedynczego regionu AWS, takiego jak Amazon Route 53? Jak reaguje Twoje obciążenie, gdy tracone jest 25% pakietów sieciowych? Czy Twoja aplikacja ustawia rozsądne limity czasu lub zawiesza się w nieskończoność, gdy doświadcza dużych opóźnień w sieci?

Takie pytania mogą wydawać się przytłaczające, więc zacznij od kilku, a następnie testuj i powtarzaj. Możesz dowiedzieć się, że Twój system może działać w sposób zadowalający w trybie awaryjnym. Alternatywnie możesz się dowiedzieć, że musisz mieć możliwość szybkiego przełączenia w tryb awaryjny. Niezależnie od wyników, wykonywanie eksperymentów z chaosem i ambitnych założeń ma kluczowe znaczenie przy opracowywaniu solidnego wieloregionalnego planu DR.

Wnioski

Za pośrednictwem tego artykułu dowiedziałeś się o zmniejszaniu zależności w swoim planie DR. Twórcy pokazali, jak można użyć kontrolera odzyskiwania aplikacji Amazon Route 53, aby zmniejszyć zależność od płaszczyzny kontrolnej Route 53 i jak symulować awarię regionalną za pomocą punktów SCP. Oceniając własny plan DR, korzystaj z praktyk inżynierii chaosu. Sformułuj pytania i przetestuj swoje założenia dotyczące stabilności statycznej. I oczywiście możesz włączyć te pytania do niestandardowego obiektywu, gdy uruchomisz recenzję za pomocą narzędzia właściwie zbudowanej architektury AWS.

źródło: AWS