Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Planowane przejście w tryb failover zarządzane przez klienta może być przydatne w scenariuszach, takich jak planowanie i testowanie na wypadek awarii i odzyskiwania, proaktywne działanie naprawcze w przypadku przewidywanych awarii na dużą skalę oraz awarie niezwiązane z magazynowaniem.
W trakcie planowanego procesu przełączania awaryjnego, główny i zapasowy region twojego konta magazynowania zostają zamienione miejscami. Oryginalny region podstawowy jest obniżany i staje się nowym pomocniczym, a oryginalny region pomocniczy jest promowany i staje się nowym podstawowym. Konto magazynowe musi być dostępne zarówno w regionie podstawowym, jak i pomocniczym przed zainicjowaniem planowanego przełączenia awaryjnego.
W tym artykule opisano, co się dzieje podczas planowanego, zarządzanego przez klienta przejścia w tryb awaryjny i powrotu do normalności na każdym etapie procesu. Aby dowiedzieć się, jak działa przełączenie awaryjne spowodowane nieoczekiwaną awarią punktu końcowego magazynu, zobacz Jak zarządzany przez klienta (nieplanowany) tryb failover działa.
Zarządzanie redundancją podczas planowanego przejścia w tryb awaryjny (failover) i powrotu do normalnej pracy (failback)
Wskazówka
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 przełączenia awaryjnego punkty końcowe usługi przechowywania w regionie podstawowym stają się tylko do odczytu, podczas gdy bieżące aktualizacje nadal są replikowane do regionu zapasowego. Następnie wszystkie wpisy DNS punktu końcowego usługi magazynowej 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. Replikacja danych w każdym regionie pozostaje niezmieniona, mimo że regiony podstawowe i pomocnicze są przełączane.
Planowany proces powrotu jest zasadniczo taki sam jak planowany proces przełączenia, 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. Jeśli na przykład konto magazynu zostało pierwotnie skonfigurowane jako GZRS, konto magazynu będzie GZRS po przywróceniu 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ć proces przełączenia awaryjnego
Aby dowiedzieć się, jak zainicjować przełączenie awaryjne konta, zobacz Inicjowanie przełączenia awaryjnego konta.
Planowany proces przełączania awaryjnego i przywracania po awarii
Na poniższych diagramach przedstawiono, co się dzieje podczas planowanego przełączenia w tryb failover zarządzanego przez klienta i powrotu po awarii konta przechowywania.
W normalnych okolicznościach klient zapisuje dane do konta magazynu w głównym regionie za pośrednictwem punktów końcowych usługi magazynowej (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 przełączenia awaryjnego (GRS/RA-GRS)
Rozpocznij testowanie odzyskiwania po awarii, inicjując przełączenie awaryjne konta przechowywania w regionie wtórnym. Poniżej opisano kroki w ramach planowanego procesu failover, a kolejna ilustracja przedstawia:
Konto magazynowe w regionie podstawowym i pomocniczym doświadczy tymczasowej utraty dostępu zarówno do odczytu, jak i zapisu.
Ukończono replikację wszystkich danych z regionu podstawowego do regionu pomocniczego.
Wpisy DNS dla punktów końcowych usługi przechowywania w regionie pomocniczym są promowane i stają się nowymi podstawowymi punktami końcowymi dla konta przechowywania.
Przejście w tryb failover zwykle trwa około godziny.
Po zakończeniu przełączenia awaryjnego oryginalny region podstawowy staje się nowym pomocniczym (1), a oryginalny region pomocniczy staje się nowym podstawowym (2). URI końcówek usług przechowywania dla obiektów blob, tabel, kolejek i plików pozostają takie same, ale ich wpisy DNS zostały zmienione, aby wskazywały na nowy podstawowy region (3). Użytkownicy mogą wznowić zapisywanie danych na konto magazynowe 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 przywracania (GRS/RA-GRS)
Po zakończeniu testowania wykonaj kolejne przełączenie awaryjne, aby przywrócić działanie w pierwotnym regionie głównym. Podczas procesu przełączenia awaryjnego, co pokazano na poniższej ilustracji:
Konto magazynowe w regionie podstawowym i pomocniczym doświadczy tymczasowej utraty dostępu zarówno do odczytu, jak i zapisu.
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, który był podstawowy, zanim wykonano pierwsze przełączenie awaryjne.
Powrót po awarii zwykle trwa około godziny.
Po zakończeniu przywracania konto magazynowe zostanie przywrócone do pierwotnej konfiguracji nadmiarowości. Użytkownicy mogą wznowić zapisywanie danych na koncie magazynowym w oryginalnym, podstawowym regionie (1), podczas gdy replikacja do oryginalnego, pomocniczego regionu (2) będzie kontynuowana tak jak przed awarią przełącznika.
