Jak działa planowane przejście w tryb failover zarządzane przez klienta (wersja zapoznawcza)
Planowane przejście w tryb failover zarządzane przez klienta może być przydatne w scenariuszach, takich jak planowanie i testowanie po awarii i odzyskiwania po awarii, proaktywne korygowanie przewidywanych awarii na dużą skalę oraz awarie związane z brakiem obsługi.
Podczas planowanego procesu pracy w trybie failover są zamieniane podstawowe i pomocnicze regiony konta magazynu. Oryginalny region podstawowy jest obniżany i staje się nowym pomocniczym, a oryginalny region pomocniczy jest promowany i staje się nowym podstawowym. Konto magazynu musi być dostępne zarówno w regionach podstawowych, jak i pomocniczych przed zainicjowaniem planowanego przejścia w tryb failover.
W tym artykule opisano, co się dzieje podczas planowanego przejścia klienta w tryb failover i powrotu po awarii na każdym etapie procesu. Aby dowiedzieć się, jak działa tryb failover z powodu nieoczekiwanej awarii punktu końcowego magazynu, zobacz Jak działa tryb failover zarządzany przez klienta (nieplanowany).
Ważne
Planowana praca w trybie failover zarządzana przez klienta jest obecnie dostępna w wersji zapoznawczej i jest ograniczona do następujących regionów:
- Francja Środkowa
- Francja Południowa
- Indie Środkowe
- Indie Zachodnie
- Azja Wschodnia
- Southeast Asia
Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.
Aby wyrazić zgodę na korzystanie z wersji zapoznawczej, zobacz Konfigurowanie funkcji w wersji zapoznawczej w subskrypcji platformy Azure i określanie AllowSoftFailover jej jako nazwy funkcji. Nazwa dostawcy dla tej funkcji w wersji zapoznawczej to Microsoft.Storage.
Ważne
Po zaplanowanym przejściu w tryb failover wartość czasu ostatniej synchronizacji (LST) konta magazynu może być nieaktualna lub być zgłaszana jako null, gdy dane usługi Azure Files są obecne.
Migawki systemu są okresowo tworzone w regionie pomocniczym konta magazynu w celu zachowania spójnych punktów odzyskiwania używanych podczas pracy w trybie failover i powrotu po awarii. Inicjowanie planowanego trybu failover zarządzanego przez klienta powoduje, że oryginalny region podstawowy stanie się nowym pomocniczym. W niektórych przypadkach nie ma żadnych migawek systemowych dostępnych w nowej lekcji pomocniczej po zakończeniu planowanego przejścia w tryb failover, co powoduje, że ogólna wartość LST konta będzie przestarzała lub będzie wyświetlana jako Null.
Ponieważ działania użytkownika, takie jak tworzenie, modyfikowanie lub usuwanie obiektów, mogą wyzwalać tworzenie migawki, każde konto, na którym te działania występują po zaplanowanym przejściu w tryb failover, nie będzie wymagać dodatkowej uwagi. Jednak konta bez migawek ani aktywności użytkownika mogą nadal wyświetlać Null wartość LST do momentu wyzwolenia tworzenia migawki systemu.
W razie potrzeby wykonaj jedną z następujących czynności dla każdego udziału na koncie magazynu, aby wyzwolić tworzenie migawki. Po zakończeniu konto powinno wyświetlić prawidłową wartość LST w ciągu 30 minut.
- Zainstaluj udział, a następnie otwórz dowolny plik do odczytu.
- Przekaż testowy lub przykładowy plik do udziału.
Zarządzanie nadmiarowością podczas planowanego przejścia w tryb failover i powrotu po awarii
Napiwek
Aby szczegółowo zrozumieć różne stany nadmiarowości podczas procesu pracy w trybie failover i powrotu po awarii zarządzanego przez klienta, zobacz Nadmiarowość usługi Azure Storage dla definicji każdego z nich.
Podczas planowanego procesu trybu failover punkty końcowe usługi magazynu w regionie podstawowym stają się tylko do odczytu, a pozostałe aktualizacje zakończą replikację do regionu pomocniczego. Następnie wszystkie wpisy usługi dns (domain name service) punktu końcowego usługi magazynu są przełączane. Pomocnicze punkty końcowe konta magazynu stają się nowymi podstawowymi punktami końcowymi, a oryginalne podstawowe punkty końcowe stają się nowym pomocniczym punktem końcowym. Replikacja danych w każdym regionie pozostaje niezmieniona, mimo że regiony podstawowe i pomocnicze są przełączane.
Proces planowanego powrotu po awarii jest zasadniczo taki sam jak planowany proces trybu failover, ale z jednym wyjątkiem. Podczas planowanego powrotu po awarii platforma Azure przechowuje oryginalną konfigurację nadmiarowości konta magazynu i przywraca ją do pierwotnego stanu po przejściu po awarii. Jeśli na przykład konto magazynu zostało pierwotnie skonfigurowane jako GZRS, konto magazynu będzie GZRS po powrotu po awarii.
Uwaga
W przeciwieństwie do trybu failover zarządzanego przez klienta (nieplanowanego) podczas planowanego przejścia w tryb failover replikacja z regionu podstawowego do pomocniczego musi zostać ukończona przed zmianą wpisów DNS dla punktów końcowych na nową pomocniczą. W związku z tym utrata danych nie jest oczekiwana podczas planowanego przejścia w tryb failover lub powrotu po awarii, o ile zarówno regiony podstawowe, jak i pomocnicze są dostępne w całym procesie.
Jak zainicjować tryb failover
Aby dowiedzieć się, jak zainicjować tryb failover, zobacz Inicjowanie trybu failover konta.
Proces planowanego przejścia w tryb failover i powrotu po awarii
Na poniższych diagramach przedstawiono, co się dzieje podczas planowanego przejścia w tryb failover zarządzanego przez klienta i powrotu po awarii konta magazynu.
W normalnych okolicznościach klient zapisuje dane na koncie 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:
Planowany proces trybu failover (GRS/RA-GRS)
Rozpocznij testowanie odzyskiwania po awarii, inicjując tryb failover konta magazynu w regionie pomocniczym. Poniższe kroki opisują proces pracy w trybie failover, a kolejny obraz przedstawia ilustrację:
- Oryginalny region podstawowy staje się tylko do odczytu.
- Ukończono replikację wszystkich danych z regionu podstawowego do regionu pomocniczego.
- Wpisy DNS dla punktów końcowych usługi magazynu w regionie pomocniczym są promowane i stają się nowymi podstawowymi punktami końcowymi dla konta magazynu.
Przejście w tryb failover zwykle trwa około godziny.
Po zakończeniu pracy w trybie failover oryginalny region podstawowy staje się nowym pomocniczym (1), a oryginalny region pomocniczy staje się nowym podstawowym (2). Identyfikatory URI punktów końcowych 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 nowy region podstawowy (3). Użytkownicy mogą wznowić zapisywanie danych na koncie magazynu w nowym regionie podstawowym, a dane są następnie kopiowane asynchronicznie do nowego pomocniczego (4), jak pokazano na poniższej ilustracji:
Podczas pracy w trybie failover wykonaj testy odzyskiwania po awarii.
Planowany proces powrotu po awarii (GRS/RA-GRS)
Po zakończeniu testowania wykonaj kolejny tryb failover w celu powrotu po awarii do oryginalnego regionu podstawowego. Podczas procesu trybu failover, jak pokazano na poniższej ilustracji:
- Oryginalny region podstawowy staje się tylko do odczytu.
- Wszystkie dane kończą replikację z bieżącego regionu podstawowego do bieżącego regionu pomocniczego.
- Wpisy DNS dla punktów końcowych usługi magazynu są zmieniane tak, aby wskazywały region podstawowy przed rozpoczęciem pracy w trybie failover.
Powrót po awarii zwykle trwa około godziny.
Po zakończeniu powrotu po awarii konto magazynu zostanie przywrócone do oryginalnej konfiguracji nadmiarowości. Użytkownicy mogą wznowić zapisywanie danych na koncie magazynu w oryginalnym regionie podstawowym (1), podczas gdy replikacja do oryginalnego pomocniczego (2) będzie kontynuowana tak jak przed przejściem w tryb failover:
