Pilot light i warm standby

Gdy wymagania dotyczące RTO są bardziej rygorystyczne niż kilka godzin, strategia Backup and Restore jest niewystarczająca. Dwa kolejne poziomy DR — Pilot Light i Warm Standby — przez cały czas utrzymują część lub całość infrastruktury uruchomioną w regionie DR, znacznie skracając czas odzyskiwania. Obie strategie wymagają ciągłego utrzymywania środowiska DR oraz użycia mechanizmu przełączania Route 53 opartego na kontroli kondycji w celu przekierowania ruchu podczas awarii. Różnią się zakresem aktywnie działającego środowiska DR.

W strategii Pilot Light w regionie DR działa tylko krytyczny rdzeń systemu — zazwyczaj sama warstwa bazy danych z ciągłą replikacją. Serwery aplikacji NIE są uruchomione; zamiast tego utrzymywane są gotowe obrazy AMI, szablony uruchamiania lub infrastruktura opisana jako kod, które pozwalają szybko je uruchomić. Można to porównać do płomyka pilota w instalacji gazowej, który jest bardzo mały, ale w razie potrzeby może w ciągu kilku minut rozpalić pełny płomień. RTO wynosi zwykle 30–60 minut.

Gdy region podstawowy ulegnie awarii i zostanie uruchomione przełączanie awaryjne Pilot Light: Krok 1 — należy przekształcić replikę tylko do odczytu RDS w regionie DR w samodzielną podstawową bazę danych. Krok 2 — należy uruchomić instancje EC2 z wcześniej przygotowanego obrazu AMI lub szablonu uruchamiania. Krok 3 — należy utworzyć lub aktywować Application Load Balancer i zarejestrować nowe instancje EC2. Krok 4 — należy zaktualizować konfigurację aplikacji tak, aby wskazywała punkt końcowy promowanej bazy danych. Krok 5 — przełączanie awaryjne kontroli kondycji Route 53 kończy zmianę obsługi DNS. Łączny czas: 30–60 minut.

W strategii Warm Standby w regionie DR stale działa kompletna, ale zmniejszona wersja środowiska produkcyjnego. Aktywne są wszystkie warstwy aplikacji — serwery WWW, serwery aplikacji i baza danych — lecz z ograniczoną przepustowością (na przykład 2 instancje zamiast 20). Podczas przełączania awaryjnego środowisko DR jest skalowane w górę, aby obsłużyć obciążenie produkcyjne. Route 53 automatycznie przełącza ruch za pomocą przełączania awaryjnego opartego na kontroli kondycji. RTO wynosi zwykle mniej niż 15 minut. Warm Standby to najpopularniejszy poziom DR dla aplikacji o znaczeniu krytycznym dla działalności.

Aurora Global Database to idealna technologia baz danych dla DR w modelu Warm Standby. Klaster w regionie dodatkowym jest stale uruchomiony, stale otrzymuje replikowane dane (opóźnienie <1 sekundy) i można go promować do roli podstawowej w czasie krótszym niż 1 minuta — znacznie szybciej niż replikę tylko do odczytu RDS, w przypadku której trzeba zatrzymać replikację i zastosować pozostałe opóźnione dane. Dzięki temu Aurora Global Database jest zalecanym wyborem, gdy wymagane RTO wynosi minuty, a nie kilkadziesiąt minut.

Zarówno Pilot Light, jak i Warm Standby korzystają z routingu przełączania awaryjnego Route 53 do automatycznego przekierowywania ruchu. Należy skonfigurować rekord Primary wskazujący ALB lub punkt końcowy w regionie produkcyjnym i powiązać go z kontrolą kondycji. Następnie należy skonfigurować rekord Secondary wskazujący punkt końcowy w regionie DR. Gdy Route 53 wykryje, że kontrola kondycji podstawowego rekordu nie powiodła się przez skonfigurowany czas, przestaje zwracać podstawowy rekord i obsługuje wyłącznie rekord dodatkowy — wszystko w ramach czasu TTL DNS.

Aby Warm Standby osiągnął docelowe RTO, środowisko DR musi być wstępnie rozgrzane — w pełni skonfigurowane i przetestowane, tak aby podczas przełączania awaryjnego konieczne było tylko skalowanie w górę. Oznacza to, że połączenia z bazą danych są ustanowione i zapisane w pamięci podręcznej, pliki konfiguracji aplikacji wskazują punkty końcowe w regionie DR, instancje EC2 działają za ALB (nawet w niewielkiej liczbie), a kontrole kondycji przechodzą pomyślnie. Należy co miesiąc przeprowadzać ćwiczenia DR, podczas których symuluje się przełączanie awaryjne, aby upewnić się, że środowisko pozostaje zgodne z bieżącą konfiguracją produkcyjną.

Utrzymywanie środowiska DR w synchronizacji ze środowiskiem produkcyjnym jest najtrudniejszym wyzwaniem operacyjnym. Jeśli środowisko produkcyjne zostanie skonfigurowane ręcznie, a aktualizacja DR zostanie pominięta, środowisko DR może nie działać poprawnie podczas rzeczywistej awarii. Rozwiązaniem jest Infrastructure as Code (IaC) z użyciem tych samych szablonów wdrażanych w obu regionach. Należy użyć AWS CloudFormation StackSets lub Terraform with multiple workspaces, aby wdrażać identyczną infrastrukturę w obu regionach z jednej bazy kodu. Eliminuje to rozbieżności konfiguracji.

Różnica kosztów między tymi strategiami jest znaczna. Pilot Light obejmuje koszt wyłącznie repliki bazy danych (zwykle 50–100% kosztu podstawowej bazy danych) oraz minimalnych zasobów sieciowych w regionie DR. Serwery aplikacji są wyłączone, więc nie generują kosztów EC2. Warm Standby wiąże się dodatkowo z kosztem uruchomienia zmniejszonej liczby instancji EC2, ALB i potencjalnie mniejszego klastra pamięci podręcznej — zwykle jest to 15–30% całkowitego kosztu środowiska produkcyjnego. Należy rozważyć, czy krótsze RTO strategii Warm Standby uzasadnia wyższy bieżący koszt.

Po przywróceniu regionu podstawowego potrzebują Państwo planu failback, aby do niego powrócić. Failback jest często najtrudniejszym elementem DR: podczas awarii w regionie DR mogły zostać przetworzone nowe dane, które trzeba zsynchronizować z regionem podstawowym. W przypadku baz danych może być konieczne skonfigurowanie replikacji odwrotnej lub ponowna synchronizacja z DR do regionu podstawowego. W Route 53 należy ponownie włączyć rekord podstawowy wraz z jego kontrolą stanu. Procedurę failback należy zawsze planować i testować równie dokładnie jak samo przełączenie awaryjne.

Proszę wybrać Pilot Light, gdy Państwa RTO wynosi 30–60 minut i chcą Państwo ograniczyć koszty DR. Główne ryzyko stanowi czas potrzebny na uruchomienie i skonfigurowanie serwerów aplikacji podczas awarii, gdy presja jest największa. Proszę wybrać Warm Standby, gdy Państwa RTO wymaga odtworzenia działania w ciągu 15 minut, aplikacja jest na tyle złożona, że jej uruchamianie od podstaw podczas awarii byłoby ryzykowne, lub zobowiązania SLA wobec klientów wymagają szybszego odtworzenia działania. W przypadku większości produkcyjnych obciążeń o średnim znaczeniu krytycznym Warm Standby zapewnia właściwy kompromis.

Proszę sprawdzić swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji dowiedzieli się Państwo, że: Pilot Light utrzymuje w DR uruchomioną wyłącznie bazę danych, a serwery aplikacji uruchamia podczas przełączenia awaryjnego, Warm Standby uruchamia kompletną, zmniejszoną środowiskowo wersję systemu, która jest skalowana podczas przełączenia awaryjnego, a Infrastructure as Code zapobiega rozbieżnościom konfiguracji między środowiskiem podstawowym a środowiskiem DR. Procedury failback należy zawsze planować i testować tak samo jak procedury przełączenia awaryjnego. W następnej części omówimy architekturę multi-site active-active z użyciem DynamoDB Global Tables i Route 53.