Czym są failover i failback?

Ten artykuł zawiera ogólne omówienie funkcjonowania zarówno trybu failover, jak i przełączenia powrotnego 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ą utrzymywania nadmiarowych kopii aplikacji i replik danych jest umożliwienie awaryjnego przełączenia. W przypadku trybu failover można przekierowywać ruch i żądania z niesprawnych wystąpień do sprawnych. Następnie, gdy oryginalne instancje znów będą w pełni sprawne, można wykonać przywrócenie po awarii, 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 tworzących implementację usługi w regionie. W całym rozwiązaniu możesz aktywować tryb awaryjnego przełączania dla różnych części tego rozwiązania na różne sposoby i w różnych sytuacjach.

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

• Podstawowe lub aktywne wystąpienia aktywnie działają, takie jak obsługa żądań przychodzących od klientów. Zazwyczaj istnieje jedno podstawowe wystąpienie jednocześnie.
• Wystąpienia drugorzędne lub pasywne są nieaktywne, ale są gotowe do przełączenia, aby stać się głównym, jeśli jest to wymagane. Może istnieć kilka instancji pomocniczych.

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.
• Gotowe rezerwy, które zostały zaprojektowane tak, aby były niemal gotowe do przyjmowania ruchu produkcyjnego, ale może to wymagać pewnych zmian w konfiguracji lub operacji skalowania, zanim będą mogły zaakceptować ruch.
• Awaryjne tryby czuwania pilotów, które są częściowo wdrażane w minimalnej konfiguracji i wymagają znacznego przygotowania, aby zostać ukończone, zanim będą mogły akceptować ruch produkcyjny.
• Zimne rezerwy, które mogą w ogóle nie być wdrożone, polegają na konieczności wdrożenia składników, zanim będą mogły obsługiwać ruch produkcyjny.

Wskazówka

Niektóre rozwiązania są tworzone w celu użycia podejścia aktywne-aktywne, co oznacza, że wiele wystąpień obsługuje żądania. System aktywny-aktywny nie wymaga przełączenia awaryjnego, ponieważ wszystkie wystąpienia aktywnie obsługują żądania przez cały czas.

Zakresy trybu failover

Różne sytuacje wymagają różnych strategii failover. 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ść strefowa przez umieszczenie kopii i replik w różnych strefach dostępności w regionie Azure.
• Redundancja geograficzna poprzez użycie 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 failover 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:

• Przełączenie repliki bazy danych może wystąpić, gdy aktywna replika bazy danych stanie się niedostępna. Pasywna replika jest awansowana 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 przekierowania całego ruchu do serwera internetowego w pozostałej strefie i zapewnia, że replika bazy danych w strefie ocalałej stanie się aktywną, jeżeli jeszcze nią nie jest.

  

• Przejście na tryb failover dla regionu może wystąpić, jeśli nastąpi katastrofalna utrata całego podstawowego regionu Azure.

  

Chociaż każdy z tych zakresów zapewnia rodzaj przełączania awaryjnego, mogą mieć różne wymagania i procesy przełączania awaryjnego. Ponadto firma Microsoft może być odpowiedzialna za niektóre zakresy trybu failover, na przykład podczas korzystania z usług nadmiarowych w strefach, natomiast Ty możesz być odpowiedzialny za przełączanie w tryb failover w szerszych zakresach, takich jak przełączanie między regionami Azure.

Planowanie trybu failover i ciągłości działania

Częścią planowania ciągłości działania jest projektowanie strategii trybu failover, w tym różnych zakresów, w których można przejść w tryb failover.

Ogólnie rzecz biorąc, plany ciągłości działania powinny obejmować zautomatyzowane procedury awaryjnego przełączania w strefach dostępności lub między nimi. Ten rodzaj przełączania 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 stosowane są różne procedury przełączania awaryjnego, takie jak w mało prawdopodobnym przypadku awarii całego regionu. W przypadku awarii regionu można przełączyć przychodzące żądania internetowe do drugiego regionu, a także uruchomić przełączenie awaryjne bazy danych do repliki w regionie zapasowym.

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 failovery

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 przełączenia awaryjne wymagają mechanizmu do wykrywania awarii i podejmowania decyzji o momencie uruchomienia przełączenia awaryjnego.

Z kolei planowane przejścia w tryb failover to te, które aktywnie wyzwalasz. Możesz to zrobić w oczekiwaniu na jakieś wydarzenia, jak na przykład w przypadku maszyny wirtualnej, która będzie aktualizowana 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

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

1. Wykryj awarię (nieplanowane przełączenia awaryjne). Automatyczne przełączenie w tryb awaryjny wymaga, aby mechanizm wykrył, gdy wystąpienie jest niedostępne, co jest zwykle oparte na określonym sposobie sprawdzania kondycji. 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 próbkowania każdego wystąpienia w regularnych odstępach czasu. Często zajmuje trochę czasu, aby monitory zdrowia systemu wykryły, że wystąpienie zakończyło działanie, i często ważne jest, aby zapewnić okres karencji na wypadek, gdyby wystąpienie było po prostu zajęte i nie mogło 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. Jedno z pozostałych wystąpień powinno stać się nowym głównym.

   W niektórych sytuacjach może być z góry określone, które wystąpienie powinno stać się nowym podstawowym, albo może istnieć tylko jedno wystąpienie, do którego można się przełączyć.

   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 poinformowane o nowej replice podstawowej, dlatego wyniki wyboru są automatycznie ogłaszane każdej replice.

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 w celu wykluczenia niesprawnej instancji. 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 procesu przełączenia awaryjnego zazwyczaj należy zaktualizować rekordy DNS, aby żądania były kierowane do nowego podstawowego wystąpienia. 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 wartość TTL jest ustawiona na długą, klienci mogą potrzebować czasu, aby otrzymać informacje o przełączeniu awaryjnym (failover) i mogą nadal wysyłać żądania do starego serwera głównego.

Ponieważ procesy przełączania awaryjnego mogą obejmować opóźnienia, ważne jest zaplanowanie procedur przełączania awaryjnego w celu spełnienia wymagań dotyczących przestojów (cel czasu odzyskiwania, czyli RTO) oraz utraty danych (celu punktu odzyskiwania, czyli RPO). Aby dowiedzieć się więcej, zobacz Co to jest ciągłość działalności biznesowej, wysoka dostępność i odzyskiwanie po awarii?.

Failback

Failback to proces przywrócenia i przekierowania ruchu z powrotem do oryginalnego wystąpienia podstawowego.

W niektórych sytuacjach nie jest konieczne powrót po awarii, ponieważ każde wystąpienie jest równie zdolne do działania jako podstawowe. Istnieją jednak sytuacje, w których ważne jest przywrócenie działania, na przykład gdy konieczne jest uruchomienie aplikacji z określonego regionu Azure, a tymczasowo dokonano przełączenia awaryjnego do innego regionu podczas awarii regionalnej.

Czasami failback jest obsługiwany w taki sam sposób jak failover. Jednak przywrócenie działania po awarii może być również bardziej złożone niż przełączenie awaryjne z kilku powodów:

• Problemy z synchronizacją danych. W trakcie, a nawet po regularnym przełączeniu awaryjnym, poprzednia instancja podstawowa mogła nadal wykonywać pewne obliczenia 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 inne ustawienia.

• Kroki korygowania. Jeśli próbowano wykonać jakiekolwiek kroki korygowania na instancji pierwotnej przed wystąpieniem przełączenia awaryjnego, mogły one pozostawić instancję pierwotną w nieznanym stanie.

  Jeśli istnieje ryzyko, że podstawowe wystąpienie jest w stanie niespójnym, może być konieczne zniszczenie i ponowne wdrożenie podstawowego wystąpienia, aby było w znanym, dobrym stanie przed przywróceniem po awarii.

• 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 wystąpiło z powodu awarii, tolerancja przestoju lub innych zagrożeń podczas powrotu po awarii w organizacji może być niższa.

  Osoby biorące udział w projekcie powinny być informowane o sytuacji w całym procesie i powinny być w pełni świadome potrzeby powrotu po awarii oraz konsekwencji procedur powrotu po awarii. Możesz wynegocjować odpowiedni czas, aby wprowadzić zmiany.

Przechodzenie w tryb failover i powrót do działania po awarii 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 w przypadku korzystania z usług platformy Azure, które są skonfigurowane z redundantnością strefową, firma Microsoft automatycznie wykonuje przełączanie awaryjne pomię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 przeprowadzić 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 usługa obsługuje monitorowanie kondycji każdego regionalnego wystąpienia aplikacji i można ją skonfigurować tak, aby automatycznie przekierowywała ruch do sprawnego wystąpienia.

Dalsze 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 dla wielu regionów w Azure Well-Architected Framework.