Jak działa nieplanowane przełączenie awaryjne zarządzane przez klienta

Tryb failover zarządzany przez klienta (nieplanowany) umożliwia przełączenie całego konta magazynu geograficznie nadmiarowego w tryb failover do regionu pomocniczego, jeśli punkty końcowe usługi magazynu dla regionu podstawowego staną się niedostępne. Podczas pracy w trybie failover oryginalny region pomocniczy staje się nowym regionem podstawowym. Wszystkie punkty końcowe usługi magazynu są następnie przekierowywane do nowego regionu podstawowego. Po rozwiązaniu awarii punktu końcowego usługi magazynu można przeprowadzić kolejną operację failover, aby powrócić do oryginalnego regionu podstawowego.

W tym artykule opisano, co się dzieje podczas nieplanowanego (zarządzanego przez klienta) zdarzenia failover i powrotu po awarii na każdym etapie procesu.

Zarządzanie nadmiarowością podczas nieplanowanego przejścia w tryb failover i powrotu po awarii

Napiwek

Aby szczegółowo zrozumieć różne stany nadmiarowości podczas nieplanowanego procesu failover i failback, zobacz Azure Storage redundancy dla definicji każdego z nich.

Gdy konto magazynu jest skonfigurowane do georedundantnego magazynu (GRS) lub georedundantnego magazynu z dostępem do odczytu (RA-GRS), dane są replikowane trzykrotnie zarówno w regionie podstawowym, jak i pomocniczym magazynu lokalnie nadmiarowego (LRS). Gdy konto magazynu jest skonfigurowane na potrzeby magazynu geograficznie nadmiarowego (GZRS) lub replikacji magazynu geograficznie nadmiarowego z dostępem do odczytu (RA-GZRS), dane są strefowo nadmiarowe w regionie podstawowym magazynu strefowo nadmiarowego (ZRS) i replikowane trzy razy w regionie pomocniczym LRS. Jeśli konto jest skonfigurowane do dostępu do odczytu (RA), możesz odczytywać dane z regionu zapasowego, o ile punkty końcowe usług magazynowania do tego regionu są dostępne.

Podczas procesu failover zarządzanego przez klienta (nieplanowanego) wpisy systemu nazw domen (DNS) dla punktów końcowych usługi przechowywania są przełączane. Pomocnicze punkty końcowe konta magazynu stają się nowymi podstawowymi punktami końcowymi, a oryginalne podstawowe punkty końcowe stają się nowymi pomocniczymi punktami końcowymi. Po przejściu w tryb failover kopia konta magazynu w oryginalnym regionie podstawowym zostanie usunięta, a konto magazynu będzie replikowane trzy razy lokalnie w nowym regionie podstawowym. W tym momencie konto magazynowe staje się lokalnie zduplikowane i korzysta z LRS (Lokalnie Zduplikowanej Pamięci).

Oryginalne i bieżące konfiguracje nadmiarowości są przechowywane we właściwościach konta magazynowego. Ta funkcja umożliwia powrót do oryginalnej konfiguracji po powrocie po awarii. Aby uzyskać pełną listę wynikowych konfiguracji nadmiarowości, przeczytaj sekcję Planowanie odzyskiwania i przełączanie awaryjne.

Aby odzyskać nadmiarowość geograficzną po przełączeniu w tryb awaryjny, należy ponownie skonfigurować konto jako GRS. Po ponownym skonfigurowaniu konta na potrzeby nadmiarowości geograficznej platforma Azure natychmiast rozpoczyna kopiowanie danych z nowego regionu podstawowego do nowego pomocniczego. Jeśli skonfigurujesz konto magazynu pod kątem dostępu do odczytu do regionu pomocniczego, ten dostęp jest dostępny. Jednak ukończenie replikacji z regionu podstawowego do regionu pomocniczego może zająć trochę czasu.

Ostrzeżenie

Po ponownym skonfigurowaniu konta na potrzeby nadmiarowości geograficznej może upłynąć dużo czasu, zanim istniejące dane dla nowego regionu podstawowego będą w pełni kopiowane do nowego regionu pomocniczego.

Aby uniknąć poważnej utraty danych, sprawdź wartość właściwości Czas ostatniej synchronizacji przed powrotem po awarii. Aby ocenić potencjalną utratę danych, porównaj czas ostatniej synchronizacji z ostatnim czasem, kiedy dane zostały zapisane na nowym serwerze głównym.

Proces powrotu po awarii jest zasadniczo taki sam jak proces przełączenia awaryjnego, z tą różnicą, że konfiguracja replikacji jest przywracana do oryginalnego stanu sprzed przełączenia awaryjnego.

Po powrotu po awarii możesz ponownie skonfigurować konto magazynu, aby korzystać z nadmiarowości geograficznej. Jeśli oryginalny podstawowy został skonfigurowany jako magazyn ZRS, można skonfigurować go tak, aby był GZRS lub RA-GZRS. Aby uzyskać więcej opcji, zobacz Zmiana sposobu replikacji konta magazynowania.

Jak zainicjować nieplanowane awaryjne przełączenie

Aby dowiedzieć się, jak zainicjować nieplanowane awaryjne przełączenie, zobacz Zainicjowanie awaryjnego przełączenia konta.

Uwaga

Nieplanowane przejście w tryb failover zwykle wiąże się z utratą danych i potencjalnie niespójnościami plików i danych. Przed zainicjowaniem tego typu trybu failover konta ważne jest, aby zrozumieć wpływ przejścia w tryb failover na dane.

Aby uzyskać szczegółowe informacje na temat potencjalnej utraty i niespójności danych, zobacz Przewidywanie utraty i niespójności danych.

Proces nieplanowanego przełączenia awaryjnego i powrotu do normalnego trybu

Ta sekcja zawiera podsumowanie procesu awaryjnego przełączenia zarządzanego przez klienta (nieplanowanego).

Podsumowanie nieplanowanego przełączenia awaryjnego

Po nieplanowanym przełączeniu awaryjnym zarządzanym przez klienta:

• Region pomocniczy staje się nowym podstawowym
• Kopia danych w oryginalnym regionie podstawowym jest usuwana
• Konto magazynowe jest konwertowane na LRS
• Nadmiarowość geograficzna jest utracona

Ta tabela zawiera podsumowanie konfiguracji nadmiarowości na każdym etapie awarii failover zarządzanej przez klienta (nieplanowanej) oraz powrotu do stanu sprzed awarii.

Oryginał konfiguracja	Po przełączenie awaryjne	Po ponownym włączeniu nadmiarowość geograficzna	Po przywrócenie działania po awarii	Po ponownym włączeniu nadmiarowość geograficzna
GRS	LRS	GRS 1	LRS	GRS 1
GZRS	LRS	GRS 1	ZRS	GZRS 1

¹ Geograficzna redundancja zostaje utracona podczas nieplanowanego przełączenia awaryjnego zarządzanego przez klienta i musi zostać ręcznie ponownie skonfigurowana.

Szczegóły nieplanowanego przełączenia awaryjnego

Na poniższych diagramach przedstawiono proces trybu failover i powrotu po awarii zarządzany przez klienta (nieplanowany) dla konta magazynu skonfigurowanego na potrzeby nadmiarowości geograficznej. Szczegóły przejścia dla GZRS i RA-GZRS są nieco inne niż GRS i RA-GRS.

GRS/RA-GRS

Normalne działanie (GRS/RA-GRS)

W normalnych okolicznościach użytkownik zapisuje dane na konto magazynu w regionie podstawowym za pośrednictwem punktów końcowych usługi magazynu (1). Dane są następnie kopiowane asynchronicznie z regionu podstawowego do regionu pomocniczego (2). Na poniższej ilustracji przedstawiono normalny stan konta magazynu skonfigurowanego jako GRS, gdy są dostępne podstawowe punkty końcowe:

Punkty końcowe usługi przechowywania stają się niedostępne w regionie głównym (GRS/RA-GRS)

Jeśli podstawowe punkty końcowe usługi magazynu staną się niedostępne z jakiegokolwiek powodu (1), klient nie może już zapisywać danych na koncie magazynu. W zależności od podstawowej przyczyny awarii replikacja do regionu pomocniczego może już nie działać (2), więc należy się spodziewać utraty danych. Na poniższej ilustracji przedstawiono scenariusz, w którym podstawowe punkty końcowe stają się niedostępne, ale przed rozpoczęciem odzyskiwania:

Nieplanowany proces przełączenia awaryjnego (GRS/RA-GRS)

Aby przywrócić dostęp do zapisu do danych, możesz zainicjować procedurę failover. Identyfikatory URI punktu końcowego usługi magazynu dla obiektów blob, tabel, kolejek i plików pozostają niezmienione, ale ich wpisy DNS są zmieniane tak, aby wskazywały region pomocniczy, jak pokazano poniżej:

Nieplanowany failover zarządzany przez klienta zwykle trwa około godziny.

Po zakończeniu pracy w trybie failover oryginalny pomocniczy staje się nowym podstawowym (1), a kopia konta magazynu w oryginalnym podstawowym stanie się usunięta (2). Konto magazynowe jest skonfigurowane jako LRS w nowym regionie podstawowym i nie jest już z nadmiarowością geograficzną. Użytkownicy mogą wznowić zapisywanie danych w koncie magazynowym (3), jak pokazano na poniższej ilustracji:

Aby wznowić replikację do nowego regionu pomocniczego, skonfiguruj ponownie konto pod kątem nadmiarowości geograficznej.

Ważne

Należy pamiętać, że konwertowanie konta magazynu lokalnie nadmiarowego na użycie nadmiarowości geograficznej wiąże się zarówno z kosztami, jak i czasem. Aby uzyskać więcej informacji, zobacz Czas i koszty awaryjnego przełączenia.

Po ponownym skonfigurowaniu konta w celu korzystania z magazynu GRS platforma Azure rozpoczyna asynchronicznie kopiowanie danych do nowego regionu pomocniczego (1), jak pokazano na poniższej ilustracji:

Dostęp do odczytu do nowego regionu pomocniczego nie jest ponownie dostępny do momentu rozwiązania problemu powodującego oryginalną awarię.

Nieplanowany proces powrotu po awarii (GRS/RA-GRS)

Ostrzeżenie

Po ponownym skonfigurowaniu konta na potrzeby nadmiarowości geograficznej może upłynąć znaczna ilość czasu, zanim dane w nowym głównym regionie będą w pełni skopiowane do nowego pomocniczego.

Aby uniknąć poważnej utraty danych, sprawdź wartość właściwości Czas ostatniej synchronizacji przed powrotem po awarii. Porównaj czas ostatniej synchronizacji z czasem ostatniego zapisu danych na nowym serwerze podstawowym, aby ocenić potencjalną utratę danych.

Po rozwiązaniu problemu powodującego oryginalną awarię można zainicjować przywracanie do pierwotnego regionu podstawowego. Proces powrotu po awarii jest taki sam jak wcześniej wyjaśniony proces przełączania awaryjnego.

Ważne rzeczy, na które należy zwrócić uwagę:

1. W przypadku inicjowanego przez klienta przejścia w tryb awaryjny i powrotu po awarii, podczas procesu powrotu dane nie mogą zostać ukończone do replikacji w regionie pomocniczym. Dlatego ważne jest, aby sprawdzić wartość czasu ostatniej synchronizacji przed przełączeniem z powrotem.
2. Wpisy DNS dla punktów końcowych usługi przechowywania są przełączane. Punkty końcowe w regionie pomocniczym stają się nowymi podstawowymi punktami końcowymi dla konta magazynowego.

Po zakończeniu powrotu po awarii oryginalny region podstawowy stanie się aktualnym ponownie (1), a kopia konta magazynu w oryginalnym regionie drugorzędnym jest usuwana (2). Konto storage jest ustawione jako lokalnie zapasowe w regionie podstawowym, a nie jest już geograficznie zapasowe. Użytkownicy mogą wznowić przechowywanie danych na koncie przechowywania (3), jak pokazano na poniższej ilustracji.

Aby wznowić replikację do oryginalnego regionu pomocniczego, ponownie skonfiguruj konto pod kątem georedundancji.

Ważne

Należy pamiętać, że konwertowanie konta magazynu lokalnie nadmiarowego na użycie nadmiarowości geograficznej wiąże się zarówno z kosztami, jak i czasem. Aby uzyskać więcej informacji, zobacz Czas i koszt przełączania awaryjnego.

Po ponownym skonfigurowaniu konta jako GRS replikacja do oryginalnego regionu pomocniczego zostanie wznowiona, jak pokazano na poniższej ilustracji.

GZRS/RA-GZRS

Praca normalna (GZRS/RA-GZRS)

W normalnych okolicznościach klient zapisuje dane na koncie pamięci masowej w regionie podstawowym za pośrednictwem punktów końcowych usługi pamięci masowej (1). Dane są następnie kopiowane asynchronicznie z regionu podstawowego do regionu pomocniczego (2). Na poniższym obrazie pokazano normalny stan konta magazynu skonfigurowanego jako GZRS, gdy podstawowe punkty końcowe są dostępne:

Punkty końcowe usługi magazynu stają się niedostępne w regionie głównym (GZRS/RA-GZRS)

Jeśli podstawowe punkty końcowe usługi magazynu staną się niedostępne z jakiegokolwiek powodu (1), klient nie może już zapisywać danych na koncie magazynu. W zależności od podstawowej przyczyny awarii replikacja do regionu pomocniczego może już nie mieć miejsca (2), więc należy oczekiwać utraty danych. Na poniższej ilustracji przedstawiono scenariusz, w którym podstawowe punkty końcowe są niedostępne, ale zanim nastąpi odzysk.

Nieplanowana procedura przełączenia awaryjnego (GZRS/RA-GZRS)

Aby przywrócić możliwość zapisu danych, możesz zainicjować przełączenie awaryjne. Identyfikatory URI punktu końcowego usługi magazynu dla obiektów blob, tabel, kolejek i plików pozostają takie same, ale ich wpisy DNS są zmieniane tak, aby wskazywały na region pomocniczy (1), jak pokazano na poniższej grafice.

Przejście w tryb failover zwykle trwa około godziny.

Po zakończeniu procesu failover oryginalny węzeł pomocniczy staje się nowym podstawowym (1), a kopia konta magazynu w oryginalnym podstawowym zostaje usunięta (2). Konto magazynu jest skonfigurowane jako LRS w nowym regionie podstawowym i nie jest już geo-redundantne. Użytkownicy mogą wznowić zapisywanie danych na koncie magazynowym (3), jak pokazano na diagramie poniżej:

Aby wznowić replikację do nowego regionu pomocniczego, skonfiguruj ponownie konto pod kątem nadmiarowości geograficznej.

Ponieważ konto zostało pierwotnie skonfigurowane jako GZRS, po przełączeniu powodującym awarię ponowna konfiguracja nadmiarowości geograficznej prowadzi do zachowania oryginalnej nadmiarowości ZRS w nowym regionie pomocniczym (który wcześniej był podstawowym). Jednak konfiguracja nadmiarowości w bieżącym głównym zawsze określa efektywną nadmiarowość geograficzną konta pamięci masowej. Ponieważ obecna jednostka główna w tym przypadku to LRS, efektywna nadmiarowość geograficzna to w tym momencie GRS, a nie GZRS.

Ważne

Należy pamiętać, że konwertowanie konta magazynu lokalnie nadmiarowego na użycie nadmiarowości geograficznej wiąże się zarówno z kosztami, jak i czasem. Aby uzyskać więcej informacji, zobacz Czas i koszt przełączenia awaryjnego.

Po ponownym skonfigurowaniu konta jako GRS platforma Azure rozpoczyna asynchronicznie kopiowanie danych do nowego regionu pomocniczego (1), jak pokazano na poniższej ilustracji:

Dostęp do odczytu do nowego regionu pomocniczego nie jest ponownie dostępny, dopóki oryginalna awaria nie zostanie rozwiązana.

Nieplanowany proces powrotu po awarii (GZRS/RA-GZRS)

Ostrzeżenie

Po ponownym skonfigurowaniu konta na potrzeby nadmiarowości geograficznej może upłynąć dużo czasu, zanim dane w nowym regionie podstawowym zostaną w pełni skopiowane do nowego regionu pomocniczego.

Aby uniknąć poważnej utraty danych, sprawdź wartość właściwości Ostatni czas synchronizacji przed powrotem po awarii. Porównaj czas ostatniej synchronizacji z czasem ostatniego zapisu danych w nowej bazie głównej, aby ocenić potencjalną utratę danych.

Po rozwiązaniu problemu powodującego awarię, można zainicjować powrót do oryginalnego regionu podstawowego. Proces przełączenia z powrotem jest taki sam jak wcześniej opisany oryginalny proces przełączenia awaryjnego.

Ważne rzeczy, na które należy zwrócić uwagę:

1. W przypadku przejścia w tryb failover zainicjowanego przez klienta i powrotu po awarii dane nie mogą zakończyć replikacji do regionu pomocniczego podczas procesu powrotu po awarii. Dlatego ważne jest, aby sprawdzić wartość właściwości czasu ostatniej synchronizacji przed powrotem po awarii systemu.
2. Wpisy DNS dla punktów końcowych usługi magazynowania są przełączane. Punkty końcowe w regionie pomocniczym stają się nowymi głównymi punktami końcowymi dla konta usługi magazynowej.

Po zakończeniu powrotu po awarii oryginalny region podstawowy ponownie staje się bieżącym (1), a kopia konta magazynu w oryginalnym pomocniczym zostanie usunięta (2). Konto magazynowe jest skonfigurowane jako ZRS w regionie podstawowym i nie jest już georedundantne. Użytkownicy mogą wznowić zapisywanie danych na koncie magazynu (3), jak pokazano na poniższym obrazku.

Aby wznowić replikację do oryginalnego regionu pomocniczego, skonfiguruj ponownie konto pod kątem nadmiarowości geograficznej.

Ważne

Należy pamiętać, że konwertowanie konta magazynu ZRS na użycie nadmiarowości geograficznej wiąże się zarówno z kosztami, jak i czasem. Aby uzyskać więcej informacji, zobacz Czas i koszt przełączania awaryjnego.

Po ponownym skonfigurowaniu konta jako GZRS, replikacja do oryginalnego regionu sekundarnego zostaje wznowiona, jak pokazano na tym obrazku.

Zobacz też

• Planowanie odzyskiwania po awarii i przełączanie awaryjne
• Nadmiarowość usługi Azure Storage
• Inicjowanie trybu failover konta