Co to są failover i failback?

Ten artykuł zawiera ogólne omówienie działania zarówno failover, jak i failback w środowisku chmury. Jednak aby zrozumieć failover, należy najpierw zrozumieć nadmiarowość i replikację. Aby dowiedzieć się więcej o tych pojęciach przed kontynuowaniem pracy z tym artykułem, zobacz Nadmiarowość, replikacja i tworzenie kopii zapasowych.

Częstą przyczyną utrzymania nadmiarowych kopii aplikacji i replik danych jest możliwość wykonania przełączenia awaryjnego. W przypadku trybu failover można przekierowywać ruch i żądania z niesprawnych wystąpień do sprawnych. Następnie, gdy tylko oryginalne wystąpienia zostaną przywrócone do dobrego stanu, można wykonać powrót, aby powrócić do oryginalnej konfiguracji.

Aktywne i pasywne role instancji

W kontekście przełączania awaryjnego wystąpienie może być pojedynczym składnikiem, takim jak baza danych, lub zbiorem wielu składników stanowiących wdrożenie usługi w regionie. W całym rozwiązaniu możesz zastosować różne elementy tego rozwiązania w trybie failover na różne sposoby i w różnych sytuacjach.

Składnik lub zestaw składników skonfigurowanych do pracy w trybie failover i failback wymaga wielu instancji. Każde z tych wystąpień przyjmuje określoną rolę:

• Podstawowe lub aktywne wystąpienia aktywnie wykonują pracę, np. obsługując żądania przychodzące od klientów. Zazwyczaj istnieje jedno główne wystąpienie w tym samym czasie.
• Wystąpienia zapasowe lub pasywne są nieaktywne, ale są gotowe do przełączenia, aby stać się pierwotnymi, jeśli jest to wymagane. Może istnieć kilka wystąpień wtórnych.

Istnieje wiele sposobów konfigurowania wystąpień pasywnych. Każdy sposób obejmuje kompromisy między czasem odzyskiwania a innymi czynnikami, takimi jak koszt i złożoność operacyjna:

• Rezerwy dynamiczne, które mają być gotowe do akceptowania ruchu produkcyjnego w dowolnym momencie.
• Ciepłe rezerwy, które zostały zaprojektowane tak, aby były niemal gotowe do akceptowania ruchu produkcyjnego, ale może to wymagać pewnych zmian konfiguracji lub operacji skalowania do ukończenia przed zaakceptowaniem ruchu.
• Światła sygnalizacyjne, które są częściowo wdrażane w wersji minimalnej i wymagają znacznego przygotowania przed przejęciem ruchu produkcyjnego.
• Zimne rezerwy, które mogą nie zostać wdrożone w ogóle, i polegają na wcześniej wdrożonych komponentach, zanim będą mogły akceptować ruch produkcyjny.

Zakresy trybu failover

Różne sytuacje wymagają różnych strategii awaryjnego przełączania. Aby zilustrować te możliwe strategie, rozważ przykładowe rozwiązanie składające się z aplikacji, która uzyskuje dostęp do danych z bazy danych. Rozwiązanie do pracy w trybie failover można skonfigurować, tworząc nadmiarowe kopie serwera aplikacji i wiele replik bazy danych. Następnie skonfigurujesz:

• Nadmiarowość strefy przez umieszczenie kopii i replik w różnych strefach dostępności w regionie świadczenia usługi Azure.
• Redundancja geograficzna z użyciem globalnego modułu równoważenia obciążenia do przełączania awaryjnego między regionami.

Oto uproszczony diagram ilustrujący ogólną architekturę w normalnych operacjach:

Różne sytuacje mogą wyzwalać różne zdarzenia awaryjnego przełączania w tym rozwiązaniu. Każdy z tych elementów odpowiada zakresowi trybu failover, który reprezentuje stopień szczegółowości składników, które przejdą w tryb failover:

• Przejście na replikę awaryjną bazy danych może nastąpić, gdy aktywna replika bazy danych przestanie być dostępna. Replika pasywna jest promowana na aktywną replikę. Zazwyczaj aplikacje mogą szybko przekierowywać żądania do nowej aktywnej repliki:

  

• Przejście strefy dostępności w tryb failover może wystąpić, jeśli w całej strefie dostępności wystąpi awaria. Ten typ awarii wymaga, aby cały ruch był kierowany do serwera internetowego w pozostałej strefie, a także zapewnia, że replika bazy danych w przetrwałej strefie stanie się aktywną repliką, jeżeli jeszcze nią nie jest.

  

• Przejście w tryb failover w regionie może wystąpić, jeśli wystąpi katastrofalna utrata całego podstawowego regionu świadczenia usługi Azure.

  

Chociaż każdy z tych zakresów zapewnia typ trybu failover, mogą mieć różne wymagania i procesy trybu failover. Ponadto firma Microsoft może być odpowiedzialna za niektóre zakresy trybu failover, na przykład podczas korzystania z usług z nadmiarowością strefową, podczas gdy Ty możesz być odpowiedzialny za failover w szerszym zakresie, takim jak przełączanie między regionami platformy Azure.

Planowanie awaryjne i ciągłość działania

Częścią planowania ciągłości działania jest projektowanie strategii awaryjnych, w tym różnych zakresów, w których można przełączyć się na tryb awaryjny.

Ogólnie rzecz biorąc, plany ciągłości działania powinny obejmować zautomatyzowane procedury trybu failover w strefach dostępności lub między nimi. Ten typ przełączenia awaryjnego stanowi część strategii wysokiej dostępności. Jeśli na przykład aktywna replika bazy danych ulegnie awarii, zautomatyzowany proces może podwyższyć poziom pasywnej repliki, aby stać się aktywną repliką. Następnie serwery internetowe komunikują się z nową aktywną repliką. Podobnie, jeśli strefa dostępności ulegnie awarii, wiele rozwiązań jest tworzonych w celu automatycznego odzyskania przy użyciu pozostałych stref.

W scenariuszach awarii są stosowane różne procedury trybu failover, takie jak w mało prawdopodobnym przypadku awarii pełnego regionu. W przypadku awarii regionu można przełączyć przychodzące żądania internetowe, aby używać drugiego regionu, a także wyzwolić tryb failover bazy danych do repliki w regionie pomocniczym.

Należy pamiętać, że uwzględnienie procedur trybu failover w planowaniu ciągłości działania wymaga wykonania bardziej szczegółowego projektowania i testowania. Aby uzyskać więcej informacji, zobacz Co to jest ciągłość działalności biznesowej, wysoka dostępność i odzyskiwanie po awarii?.

Planowane i nieplanowane przejścia w tryb failover

Nieplanowane przejścia w tryb failover to te, które są wykonywane podczas awarii składnika, dzięki czemu można przywrócić usługę przy użyciu innego wystąpienia. Nieplanowane przechodzenie w tryb failover czasami powoduje przestoje lub utratę danych w zależności od sposobu projektowania rozwiązania. Nieplanowane przejścia w tryb failover wymagają czegoś, aby wykryć błąd i podjąć decyzję o tym, kiedy należy wyzwolić tryb failover.

Z kolei planowane przejścia w tryb failover to te, które aktywnie wyzwalasz. Możesz to zrobić w oczekiwaniu na coś się dzieje, na przykład maszynę wirtualną, która zostanie poprawiona i ponownie uruchomiona. Planowane przejścia w tryb failover mogą mieć niższą tolerancję przestojów i utraty danych, ponieważ są one częścią regularnych procedur konserwacji.

Jak działa tryb failover

Tryb failover zazwyczaj składa się z następujących kroków, które można wykonać ręcznie lub przez zautomatyzowany system. Szczegółowe informacje dotyczące każdego z tych kroków zależą od konkretnego systemu.

1. Wykrywanie awarii (tylko nieplanowane przejścia w tryb failover). Automatyczne przełączenie awaryjne wymaga, aby system wykrył, gdy wystąpienie jest niedostępne, co zazwyczaj opiera się na jakimś mechanizmie monitorowania stanu. Różne usługi definiują kondycję na różne sposoby. Na przykład niektóre usługi aktywnie wysyłają zdarzenia heartbeat między wystąpieniami. Inne wymagają oddzielnego składnika do sondowania każdego wystąpienia w regularnych odstępach czasu. Często potrzeba trochę czasu, zanim monitory kondycji wykryją awarię instancji, i często ważne jest, aby nadać okres karencji w przypadku, gdy instancja była po prostu zajęta i nie mogła odpowiedzieć.

2. Wybierz tryb failover. W pewnym momencie zostanie podjęta decyzja o przejściu w tryb failover. Decyzja może być podjęta przez zautomatyzowane narzędzie lub ręcznie. Tolerancja ryzyka organizacji może mieć wpływ na szybkość podejmowania tej decyzji. Jeśli masz niską tolerancję na ryzyko, możesz zdecydować się na szybkie przełączenie w tryb failover, jeśli istnieje jakiekolwiek wskazanie problemu. Jeśli masz większą tolerancję ryzyka, możesz poczekać, aby sprawdzić, czy problem można rozwiązać przed przełączeniem w tryb failover.

3. Wybierz nowe wystąpienie podstawowe. Jedna z pozostałych instancji powinna stać się nową główną.

   W niektórych sytuacjach, możesz mieć uprzednio zdefiniowane, która instancja powinna stać się nową instancją podstawową, lub możesz mieć tylko jedną instancję do przełączenia.

   W innych sytuacjach istnieje zautomatyzowany proces, za pomocą którego system wybiera nowe wystąpienie podstawowe. Istnieje wiele algorytmów konsensusu używanych w przetwarzaniu rozproszonym, w tym w wyborach liderów. Te algorytmy są implementowane w odpowiednich usługach, takich jak bazy danych. W niektórych systemach ważne jest, aby każde wystąpienie było świadome nowej repliki podstawowej, dlatego wyniki wyboru są ogłaszane automatycznie dla każdej repliki.

4. Żądania przekierowania. Skonfiguruj środowisko tak, aby żądania zostały skierowane do wystąpień w dobrej kondycji lub do nowego wystąpienia podstawowego.

   Aby to osiągnąć, może być konieczne zaktualizowanie innych systemów, aby wiedzieć, gdzie wysyłać żądania. Może to obejmować zaktualizowanie systemu równoważenia obciążenia, aby wykluczyć niedziałającą instancję. W innych sytuacjach system nazw domen (DNS) jest często używany jako sposób wysyłania żądań do aktywnego wystąpienia systemu. W ramach procedury przełączania awaryjnego zazwyczaj należy zaktualizować rekordy DNS, aby żądania były kierowane do nowej instancji podstawowej. System DNS ma pojęcie czasu wygaśnięcia (TTL), który instruuje klientów, jak często powinni sprawdzać zaktualizowane rekordy DNS. Jeśli czas wygaśnięcia jest ustawiony na długi, może upłynąć trochę czasu, zanim klienci otrzymają informacje o przełączeniu awaryjnym i mogą nadal wysyłać żądania do starego serwera głównego.

Ponieważ procesy przełączania awaryjnego mogą wiązać się z opóźnieniami, ważne jest zaplanowanie procedur przełączania awaryjnego w taki sposób, aby spełniały one wymagania dotyczące maksymalnego czasu przestoju (cel czasu odzyskiwania, RTO) oraz utraty danych (cel punktu odzyskiwania danych, RPO). Aby dowiedzieć się więcej, zobacz Co to jest ciągłość działalności biznesowej, wysoka dostępność i odzyskiwanie po awarii?.

Powrót po awarii

Powrót po awarii to proces ponownego przywrócenia i przekierowania ruchu z powrotem do oryginalnego wystąpienia podstawowego.

W niektórych sytuacjach nie jest konieczne powracanie po awarii, ponieważ każda instancja jest równie zdolna do działania jako instancja podstawowa. Istnieją jednak sytuacje, w których ważne jest powrót po awarii, na przykład w przypadku konieczności uruchomienia aplikacji z określonego regionu świadczenia usługi Azure i tymczasowego przełączenie w tryb failover do innego regionu podczas awarii regionalnej.

Czasami powrót po awarii jest obsługiwany w taki sam sposób jak tryb failover. Jednak powrót po awarii może być również bardziej złożony niż tryb failover z kilku powodów:

• Problemy z synchronizacją danych. W trakcie, a nawet po regularnym przejściu w tryb failover, poprzednie wystąpienie podstawowe mogło nadal wykonywać pewną pracę lub zapisywać dane w magazynie danych. Częścią procesu powrotu po awarii jest zapewnienie spójności i integralności danych w rozwiązaniu, w tym zarządzanie konfliktami lub duplikacjami między wystąpieniami podstawowymi i pomocniczymi.

  Często występują problemy z synchronizacją danych, które wymagają interwencji ręcznej. Jeśli nie potrzebujesz danych powodujących konflikt, możesz zresetować bazę danych lub przywrócić inne ustawienia.

• Kroki korygowania. Jeśli przed wystąpieniem przełączenia awaryjnego próbowano wykonać jakiekolwiek kroki naprawcze na serwerze podstawowym, mogły one pozostawić serwer podstawowy w stanie niepewności.

  Jeśli istnieje ryzyko, że podstawowe wystąpienie jest w stanie niespójnym, może być konieczne zniszczenie i ponowne wdrożenie tego wystąpienia, aby znajdowało się w znanym, dobrym stanie przed przełączeniem wstecz.

• Dodatkowy przestój. Przestój podczas procesu powrotu po awarii może być dłuższy niż podczas pracy w trybie failover z powodu ponownej konfiguracji wymaganej lub operacji w celu przywrócenia spójności danych.

  Ten problem można rozwiązać, uruchamiając procesy powrotu po awarii w oknie obsługi lub doradzając użytkownikom zmiany z wyprzedzeniem. Ponadto może być możliwe wykonanie niektórych operacji przygotowawczych, gdy system jest w trybie online, i zminimalizować wymagany przestój.

• Tolerancja ryzyka. Jeśli przejście w tryb failover nastąpiło z powodu awarii, organizacja może mieć niższą tolerancję na przestoje lub inne ryzyka podczas powrotu do normalnego działania.

  Interesariusze biznesowi powinni być informowani o sytuacji przez cały proces i powinni być w pełni świadomi potrzeby przywrócenia oraz konsekwencji procedur przywrócenia. Możesz wynegocjować odpowiedni czas, aby wprowadzić zmiany.

Przechodzenie w tryb failover i failback w usługach platformy Azure

Chociaż ważne jest, aby zrozumieć, jak działa tryb failover, należy pamiętać, że każda usługa platformy Azure może podejść do trybu failover i powrotu po awarii inaczej. Aby uzyskać informacje o sposobie działania określonych usług platformy Azure z perspektywy niezawodności, zobacz przewodnik po niezawodności poszczególnych usług.

Wiele usług platformy Azure automatycznie obsługuje niektóre typy trybu failover. Na przykład, gdy korzystasz z usług platformy Azure, które są skonfigurowane z nadmiarowością strefową, firma Microsoft automatycznie wykonuje przełączenie awaryjne między strefami dostępności. Aby dowiedzieć się więcej, zobacz Co to są strefy dostępności? i przewodniki dotyczące niezawodności usługi platformy Azure.

Jeśli używasz maszyn wirtualnych, usługa Azure Site Recovery replikuje maszyny wirtualne i ich dyski między strefami dostępności lub do innego regionu Azure, i może wykonać przełączenie awaryjne.

Podczas projektowania własnego rozwiązania, które łączy ze sobą wiele usług platformy Azure, wymagania dotyczące trybu failover mogą stać się bardziej złożone. Załóżmy, że projektujesz rozwiązanie z warstwą aplikacji i bazą danych i chcesz utworzyć architekturę aktywną/pasywną w wielu regionach. Podczas awarii w regionie podstawowym ważne jest, aby aplikacja i baza danych przejdą w tryb failover do regionu pomocniczego. W zależności od dokładnie używanych usług może być konieczne zaplanowanie własnego podejścia do trybu failover, aby przełączać się między wdrożeniami w każdym regionie. Platforma Azure zapewnia globalny routing ruchu i równoważenie obciążenia za pośrednictwem usług Azure Front Door i Azure Traffic Manager. Możesz wybrać technologię spełniającą wymagania dotyczące trybu failover. Każda z usług obsługuje monitorowanie kondycji poszczególnych regionalnych wystąpień twojej aplikacji i można ją skonfigurować tak, aby automatycznie przekierowywać ruch do zdrowego wystąpienia.

Następne kroki

• Dowiedz się więcej o wspólnej odpowiedzialności za niezawodność.
• Dowiedz się więcej o zaleceniach dotyczących projektowania o wysokiej dostępności w wielu regionach w strukturze Azure Well-Architected Framework.