Wzorce Multi-AZ dla usług stanowych

Usługi stanowe — bazy danych, pamięci podręczne i systemy plików — są najtrudniejszymi komponentami do zapewnienia wysokiej dostępności, ponieważ przechowują dane, które muszą przetrwać awarie. Jeśli baza danych działająca w jednej strefie AZ ulegnie awarii, cała aplikacja traci swój magazyn danych. Odpowiedzią AWS są wdrożenia Multi-AZ, w których usługa utrzymuje synchroniczną lub niemal synchroniczną replikę w drugiej strefie dostępności, która może szybko przejąć działanie po awarii węzła głównego.

RDS Multi-AZ utrzymuje synchroniczną replikę zapasową w innej strefie AZ. Każdy zapis w węźle głównym jest replikowany synchronicznie przed potwierdzeniem powodzenia operacji — oznacza to brak utraty danych (RPO=0), ale niewielki wzrost opóźnienia zapisu. Gdy węzeł główny ulegnie awarii, RDS automatycznie aktualizuje punkt końcowy DNS, aby wskazywał replikę zapasową; trwa to 60–120 sekund. Aplikacja musi jedynie ponownie połączyć się z tym samym punktem końcowym — nie są wymagane żadne zmiany w kodzie.

Amazon Aurora idzie o krok dalej niż Multi-AZ dzięki współdzielonej rozproszonej warstwie pamięci masowej, która automatycznie replikuje dane między trzema strefami AZ, tworząc sześć kopii. Instancje Aurora są bezstanowe — odczytują dane z tej współdzielonej pamięci masowej i zapisują je w niej. Gdy główna instancja Aurora obsługująca zapis ulegnie awarii, replika odczytu w innej strefie AZ zostaje awansowana do roli instancji zapisującej w czasie krótszym niż 30 sekund. Jest to szybsze niż przełączanie awaryjne RDS Multi-AZ, a dane są zawsze spójne między strefami AZ bez konieczności jawnej replikacji do instancji zapasowej.

ElastiCache for Redis obsługuje Multi-AZ za pomocą grup replikacji. Węzeł główny przyjmuje operacje zapisu i asynchronicznie replikuje dane do replik odczytu w innych strefach AZ. Gdy węzeł główny ulegnie awarii, ElastiCache automatycznie awansuje jedną z replik do roli węzła głównego. W przypadku funkcji Redis cluster mode enabled dane są dzielone na fragmenty między wiele grup węzłów, z których każda ma własny węzeł główny i repliki rozmieszczone w różnych strefach AZ — zapewnia to zarówno wysoką dostępność, jak i skalowanie poziome.

Amazon Elastic File System (EFS) natywnie obsługuje Multi-AZ — jest usługą regionalną, która przechowuje dane nadmiarowo w wielu strefach AZ w obrębie regionu. Należy utworzyć cele montowania w podsieci każdej strefy AZ, a instancje EC2 w dowolnej strefie AZ mogą zamontować system plików za pośrednictwem lokalnego celu montowania. Nie jest wymagana ręczna konfiguracja Multi-AZ. EFS zapewnia współdzieloną pamięć plikową POSIX, do której wiele instancji w różnych strefach AZ może uzyskiwać jednoczesny dostęp.

Elastic Load Balancers same obsługują Multi-AZ — ALB i NLB wdrażają węzły load balancera w każdej określonej strefie AZ. Przy włączonej funkcji cross-zone load balancing (domyślnej dla ALB) każdy węzeł load balancera rozdziela ruch równomiernie między wszystkie zarejestrowane cele we wszystkich strefach AZ, a nie tylko w swojej strefie. Dzięki temu nawet jeśli wszystkie instancje w jednej strefie AZ ulegną awarii, load balancer nadal obsługuje ruch za pośrednictwem instancji w pozostałych strefach AZ.

Częstym błędem jest wdrożenie pojedynczego NAT Gateway w jednej strefie AZ, gdy podsieci prywatne w innych strefach AZ kierują przez niego ruch. Jeśli ta strefa AZ ulegnie awarii, wszystkie instancje prywatne tracą dostęp do Internetu. Prawidłowy wzorzec Multi-AZ polega na wdrożeniu jednej bramy NAT na strefę AZ i skonfigurowaniu prywatnej tablicy routingu każdej strefy AZ tak, aby kierowała trasę 0.0.0.0/0 przez własną bramę NAT. Eliminuje to bramę NAT jako pojedynczy punkt awarii między strefami AZ i zmniejsza koszty transferu danych między strefami AZ.

DynamoDB to w pełni zarządzana usługa, która automatycznie replikuje dane między trzema strefami AZ w obrębie regionu — nie trzeba ręcznie konfigurować Multi-AZ. Każdy zapis jest trwale przechowywany we wszystkich trzech strefach AZ, zanim zostanie zwrócony wynik powodzenia. DynamoDB od razu zapewnia faktyczną odporność na awarie na poziomie strefy AZ. Dlatego DynamoDB jest często zalecaną bazą danych, gdy pytanie egzaminacyjne kładzie nacisk na wysoką dostępność przy minimalnym nakładzie pracy operacyjnej.

Podczas przełączania awaryjnego RDS Multi-AZ aplikacje utrzymujące trwałe połączenia z bazą danych mogą napotykać błędy, ponieważ zmienia się punkt końcowy. RDS Proxy działa między aplikacją a RDS i utrzymuje pulę połączeń z bazą danych. Podczas przełączania awaryjnego RDS Proxy automatycznie kieruje połączenia do nowej instancji głównej — zmniejszając wpływ przełączenia z 60–120 sekund do mniej niż 30 sekund w aplikacjach korzystających z punktu końcowego proxy. RDS Proxy pomaga także funkcjom Lambda, które tworzą wiele krótkotrwałych połączeń.

Zrozumienie trybów replikacji ma kluczowe znaczenie przy wyborze wzorców Multi-AZ. Replikacja synchroniczna (RDS Multi-AZ, EFS) zapewnia RPO=0, ponieważ każdy zapis jest potwierdzany w obu strefach AZ, zanim zostanie zwrócony wynik powodzenia. Kompromisem jest nieco większe opóźnienie zapisu. Replikacja asynchroniczna (repliki ElastiCache Redis, repliki odczytu RDS) zapewnia mniejsze opóźnienie zapisu, ale dopuszcza niewielkie opóźnienie replikacji — oznacza to, że w przypadku awarii instancji głównej przed ukończeniem replikacji część danych może zostać utracona.

Należy regularnie testować przełączanie awaryjne Multi-AZ, aby zweryfikować założenia dotyczące RTO. W przypadku RDS można wywołać przełączenie awaryjne za pomocą opcji Reboot with failover w konsoli lub interfejsu CLI. Należy monitorować w CloudWatch metrykę FailedSQLServerAgentJobsCount oraz obserwować dzienniki aplikacji, aby sprawdzić, czy aplikacja pomyślnie nawiązuje połączenie ponownie. Należy udokumentować rzeczywisty czas przełączenia awaryjnego — może on różnić się od wartości podanych w dokumentacji AWS w zależności od klasy instancji i obciążenia.

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) z tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: RDS Multi-AZ korzysta z replikacji synchronicznej i automatycznego przełączania DNS, Aurora korzysta ze współdzielonej warstwy pamięci masowej w trzech strefach AZ, co przyspiesza przełączanie awaryjne, a EFS i DynamoDB natywnie obsługują Multi-AZ bez ręcznej konfiguracji. Należy wdrożyć jedną bramę NAT na strefę AZ, aby uniknąć pojedynczych punktów awarii między strefami AZ. W następnej części omówimy wzorce multi-region active-active i active-passive.