Planowanie i przechodzenie w tryb failover w usłudze Azure Storage po awarii
Firma Microsoft stara się zapewnić, że usługi platformy Azure są zawsze dostępne. Jednak nieplanowane przerwy w działaniu usługi mogą wystąpić od czasu do czasu. Kluczowe składniki dobrego planu odzyskiwania po awarii obejmują strategie:
- Ochrona danych
- Tworzenie kopii zapasowej i przywracanie
- Nadmiarowość danych
- Tryb failover
- Projektowanie aplikacji pod kątem wysokiej dostępności
W tym artykule opisano opcje dostępne dla kont magazynu geograficznie nadmiarowego oraz przedstawiono zalecenia dotyczące tworzenia aplikacji o wysokiej dostępności i testowania planu odzyskiwania po awarii.
Wybieranie odpowiedniej opcji nadmiarowości
Usługa Azure Storage obsługuje wiele kopii konta magazynu, aby zapewnić spełnienie celów dostępności i trwałości, nawet w przypadku awarii. Sposób, w jaki dane są replikowane, zapewnia różne poziomy ochrony. Każda opcja oferuje własne korzyści, więc wybrana opcja zależy od stopnia odporności wymaganych przez aplikacje.
Magazyn lokalnie nadmiarowy (LRS), opcja najniższego kosztu nadmiarowości, automatycznie przechowuje i replikuje trzy kopie konta magazynu w jednym centrum danych. Mimo że magazyn LRS chroni dane przed awariami stojaka serwera i dysku, nie uwzględnia awarii, takich jak pożar lub powodzie w centrum danych. W obliczu takich awarii wszystkie repliki konta magazynu skonfigurowanego do korzystania z magazynu LRS mogą zostać utracone lub nieodwracalne.
Dla porównania magazyn strefowo nadmiarowy (ZRS) zachowuje kopię konta magazynu i replikuje je w każdej z trzech oddzielnych stref dostępności w tym samym regionie. Aby uzyskać więcej informacji na temat stref dostępności, zobacz Strefy dostępności platformy Azure.
Magazyn geograficznie nadmiarowy i tryb failover
Magazyn geograficznie nadmiarowy (GRS), magazyn geograficznie nadmiarowy (GZRS) i magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GZRS) to przykłady opcji magazynu geograficznie nadmiarowego. Po skonfigurowaniu do używania magazynu geograficznie nadmiarowego (GRS, GZRS i RA-GZRS) platforma Azure kopiuje dane asynchronicznie do pomocniczego regionu geograficznego. Te regiony znajdują się setki, a nawet tysiące kilometrów dalej. Ten poziom nadmiarowości umożliwia odzyskanie danych w przypadku awarii w całym regionie podstawowym.
W przeciwieństwie do magazynów LRS i ZRS magazyn geograficznie nadmiarowy zapewnia również obsługę nieplanowanego przejścia w tryb failover do regionu pomocniczego, jeśli wystąpi awaria w regionie podstawowym. Podczas procesu trybu failover wpisy DNS (system nazw domen) dla punktów końcowych usługi konta magazynu są automatycznie aktualizowane, tak aby punkty końcowe regionu pomocniczego stały się nowymi podstawowymi punktami końcowymi. Po zakończeniu nieplanowanego przejścia w tryb failover klienci mogą rozpocząć zapisywanie w nowych podstawowych punktach końcowych.
Magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GRS) i magazyn geograficznie nadmiarowy z dostępem do odczytu (RA-GZRS) zapewnia również magazyn geograficznie nadmiarowy, ale oferuje dodatkową korzyść dostępu do odczytu do pomocniczego punktu końcowego. Te opcje są idealne dla aplikacji zaprojektowanych pod kątem wysokiej dostępności aplikacji krytycznych dla działania firmy. Jeśli podstawowy punkt końcowy ulegnie awarii, aplikacje skonfigurowane pod kątem dostępu do odczytu do regionu pomocniczego mogą nadal działać. Firma Microsoft zaleca ra-GZRS w celu zapewnienia maksymalnej dostępności i trwałości kont magazynu.
Aby uzyskać więcej informacji na temat nadmiarowości usługi Azure Storage, zobacz Nadmiarowość usługi Azure Storage.
Planowanie przejścia w tryb failover
Konta usługi Azure Storage obsługują trzy typy trybu failover:
- Planowana praca w trybie failover przez klienta (wersja zapoznawcza) — klienci mogą zarządzać trybem failover konta magazynu w celu przetestowania planu odzyskiwania po awarii.
- Tryb failover zarządzany przez klienta (nieplanowany) — klienci mogą zarządzać trybem failover konta magazynu, jeśli wystąpi nieoczekiwana awaria usługi.
- Tryb failover zarządzany przez firmę Microsoft — potencjalnie zainicjowany przez firmę Microsoft z powodu poważnej awarii w regionie podstawowym. 1,2
1 Nie można zainicjować trybu failover zarządzanego przez firmę Microsoft dla poszczególnych kont magazynu, subskrypcji ani dzierżaw. Aby uzyskać więcej informacji, zobacz Tryb failover zarządzany przez firmę Microsoft.
2 Użyj opcji trybu failover zarządzanego przez klienta, aby opracowywać, testować i implementować plany odzyskiwania po awarii. Nie należy polegać na trybie failover zarządzanym przez firmę Microsoft, który byłby używany tylko w ekstremalnych okolicznościach.
Każdy typ trybu failover ma unikatowy zestaw przypadków użycia, odpowiednie oczekiwania dotyczące utraty danych i obsługę kont z włączoną hierarchiczną przestrzenią nazw (Azure Data Lake Storage). W tej tabeli podsumowano te aspekty każdego typu trybu failover:
| Typ | Zakres trybu failover | Przypadek użycia | Oczekiwana utrata danych | Obsługiwana hierarchiczna przestrzeń nazw (HNS) |
|---|---|---|---|---|
| Planowana praca w trybie failover zarządzana przez klienta (wersja zapoznawcza) | Konto magazynu | Punkty końcowe usługi magazynu dla regionów podstawowych i pomocniczych są dostępne i chcesz przeprowadzić testowanie odzyskiwania po awarii. Punkty końcowe usługi magazynu dla regionu podstawowego są dostępne, ale inna usługa uniemożliwia prawidłowe działanie obciążeń. Aby aktywnie przygotować się do awarii na dużą skalę, takich jak huragan, który może mieć wpływ na region. |
Nie | Tak (W wersji zapoznawczej) |
| Tryb failover zarządzany przez klienta (nieplanowany) | Konto magazynu | Punkty końcowe usługi magazynu dla regionu podstawowego stają się niedostępne, ale region pomocniczy jest dostępny. Otrzymano poradę platformy Azure, w której firma Microsoft zaleca wykonanie operacji trybu failover kont magazynu potencjalnie dotkniętych awarią. |
Tak | Tak (W wersji zapoznawczej) |
| Zarządzane przez firmę Microsoft | Cały region | Region podstawowy staje się niedostępny z powodu znacznej awarii, ale region pomocniczy jest dostępny. | Tak | Tak |
W poniższej tabeli porównaliśmy stan nadmiarowości konta magazynu po każdym typie trybu failover:
| Wynik przejścia w tryb failover... | Planowana praca w trybie failover zarządzana przez klienta (wersja zapoznawcza) | Tryb failover zarządzany przez klienta (nieplanowany) |
|---|---|---|
| ... region pomocniczy | Region pomocniczy staje się nowym podstawowym | Region pomocniczy staje się nowym podstawowym |
| ... oryginalny region podstawowy | Oryginalny region podstawowy staje się nowym pomocniczym | Kopia danych w oryginalnym regionie podstawowym jest usuwana |
| ... konfiguracja nadmiarowości konta | Konto magazynu jest konwertowane na magazyn GRS | Konto magazynu jest konwertowane na magazyn LRS |
| ... konfiguracja nadmiarowości geograficznej | Nadmiarowość geograficzna jest zachowywana | Nadmiarowość geograficzna jest utracona |
Poniższa tabela zawiera podsumowanie wynikowej konfiguracji nadmiarowości na każdym etapie procesu przechodzenia w tryb failover i powrotu po awarii dla każdego typu trybu failover:
| Oryginał konfiguracja |
Po tryb failover |
Po ponownym włączeniu nadmiarowość geograficzna |
Po powrót po awarii |
Po ponownym włączeniu nadmiarowość geograficzna |
|---|---|---|---|---|
| Planowana praca w trybie failover zarządzana przez klienta | ||||
| GRS | GRS | n/a 1 | GRS | n/a 1 |
| GZRS | GRS | n/a 1 | GZRS | n/a 1 |
| Tryb failover zarządzany przez klienta (nieplanowany) | ||||
| GRS | LRS | GRS | LRS | GRS |
| GZRS | LRS | GRS | ZRS | GZRS |
1 Nadmiarowość geograficzna jest zachowywana podczas planowanego przejścia w tryb failover i nie musi być ręcznie ponownie skonfigurowana.
Planowana praca w trybie failover zarządzana przez klienta (wersja zapoznawcza)
Planowane przejście w tryb failover można wykorzystać w wielu scenariuszach, w tym w przypadku planowanych testów odzyskiwania po awarii, proaktywnego podejścia do awarii na dużą skalę lub odzyskiwania po awarii związanych z magazynem.
Podczas planowanego procesu pracy w trybie failover są zamieniane regiony podstawowe i pomocnicze. Oryginalny region podstawowy jest obniżany i staje się nowym regionem pomocniczym. Jednocześnie jest promowany oryginalny region pomocniczy i staje się nowym podstawowym. Po zakończeniu pracy w trybie failover użytkownicy mogą przejść do danych w nowym regionie podstawowym, a administratorzy mogą zweryfikować swój plan odzyskiwania po awarii. Konto magazynu musi być dostępne zarówno w regionach podstawowych, jak i pomocniczych przed zainicjowaniem planowanego przejścia w tryb failover.
Utrata danych nie jest oczekiwana podczas planowanego przejścia w tryb failover i powrotu po awarii, o ile regiony podstawowe i pomocnicze są dostępne w całym procesie. Aby uzyskać więcej informacji, zobacz sekcję Przewidywanie utraty i niespójności danych.
Aby zrozumieć wpływ tego typu trybu failover na użytkowników i aplikacje, warto wiedzieć, co dzieje się w każdym kroku planowanych procesów pracy w trybie failover i powrotu po awarii. Aby uzyskać szczegółowe informacje na temat działania tego procesu, zobacz Jak działa tryb failover zarządzany przez klienta (planowany).
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.
Tryb failover zarządzany przez klienta (nieplanowany)
Jeśli punkty końcowe danych dla usług magazynu na koncie magazynu staną się niedostępne w regionie podstawowym, możesz zainicjować nieplanowany tryb failover w regionie pomocniczym. Po zakończeniu pracy w trybie failover region pomocniczy staje się nowym podstawowym, a użytkownicy mogą przejść do danych.
Aby zrozumieć wpływ tego typu trybu failover na użytkowników i aplikacje, warto wiedzieć, co dzieje się w każdym kroku nieplanowanego trybu failover i procesu powrotu po awarii. Aby uzyskać szczegółowe informacje o sposobie działania procesu, zobacz Jak działa tryb failover zarządzany przez klienta (nieplanowany).
Tryb failover zarządzany przez firmę Microsoft
Firma Microsoft może zainicjować regionalną pracę w trybie failover w ekstremalnych okolicznościach, takich jak katastrofalna awaria, która ma wpływ na cały region geograficzny. Podczas tych zdarzeń nie jest wymagana żadna akcja w Twojej części. Jeśli konto magazynu jest skonfigurowane dla magazynu RA-GRS lub RA-GZRS, aplikacje mogą odczytywać dane z regionu pomocniczego podczas pracy w trybie failover zarządzanym przez firmę Microsoft. Nie masz jednak dostępu do zapisu na koncie magazynu, dopóki proces trybu failover nie zostanie ukończony.
Ważne
Użyj opcji trybu failover zarządzanego przez klienta, aby opracowywać, testować i implementować plany odzyskiwania po awarii. Nie należy polegać na trybie failover zarządzanym przez firmę Microsoft, który może być używany tylko w ekstremalnych okolicznościach. Tryb failover zarządzany przez firmę Microsoft zostanie zainicjowany dla całej jednostki fizycznej, takiej jak region lub centrum danych. Nie można go zainicjować dla poszczególnych kont magazynu, subskrypcji ani dzierżaw. Jeśli potrzebujesz możliwości selektywnego przejścia w tryb failover poszczególnych kont magazynu, użyj planowanego trybu failover zarządzanego przez klienta.
Przewidywanie utraty i niespójności danych
Uwaga
Nieplanowane przejście w tryb failover zarządzane przez klienta zwykle wiąże się z pewną ilością danych, a także potencjalnie może powodować niespójności plików i danych. W planie odzyskiwania po awarii należy wziąć pod uwagę wpływ przejścia konta w tryb failover na dane przed zainicjowaniem.
Ponieważ dane są zapisywane asynchronicznie z regionu podstawowego do regionu pomocniczego, zawsze istnieje opóźnienie, zanim zapis w regionie podstawowym zostanie skopiowany do pomocniczego. Jeśli region podstawowy stanie się niedostępny, możliwe, że najnowsze zapisy mogą nie zostać jeszcze skopiowane do pomocniczej.
W przypadku nieplanowanego przejścia w tryb failover wszystkie dane w regionie podstawowym zostaną utracone, ponieważ region pomocniczy staje się nowym podstawowym. Wszystkie dane skopiowane do regionu pomocniczego są zachowywane po przejściu w tryb failover. Jednak wszystkie dane zapisane w regionie podstawowym, które jeszcze nie istnieją w regionie pomocniczym, zostaną trwale utracone.
Nowy region podstawowy jest skonfigurowany jako lokalnie nadmiarowy (LRS) po przejściu w tryb failover.
Może również wystąpić niespójność plików lub danych, jeśli konta magazynu mają co najmniej jedną z następujących opcji:
- Hierarchiczna przestrzeń nazw (Azure Data Lake Storage)
- Zestawienie zmian
- Przywracanie do punktu w czasie dla blokowych obiektów blob
Czas ostatniej synchronizacji
Właściwość Czas ostatniej synchronizacji wskazuje ostatni czas, w którym dane z regionu podstawowego zostały również zapisane w regionie pomocniczym. W przypadku kont, które mają hierarchiczną przestrzeń nazw, ta sama właściwość Czas ostatniej synchronizacji ma również zastosowanie do metadanych zarządzanych przez hierarchiczną przestrzeń nazw, w tym list kontroli dostępu (ACL). Wszystkie dane i metadane zapisane przed ostatnim czasem synchronizacji są dostępne w pomocniczym. Z kolei dane i metadane zapisane po ostatniej synchronizacji mogą nie zostać jeszcze skopiowane do pomocniczej i potencjalnie mogą zostać utracone. Podczas awarii użyj tej właściwości, aby oszacować ilość utraty danych, którą można ponieść podczas inicjowania trybu failover konta.
Najlepszym rozwiązaniem jest zaprojektowanie aplikacji tak, aby umożliwić ocenę oczekiwanej utraty danych przy użyciu czasu ostatniej synchronizacji. Na przykład rejestrowanie wszystkich operacji zapisu umożliwia porównywanie czasów ostatniej operacji zapisu z czasem ostatniej synchronizacji. Ta metoda umożliwia określenie, które zapisy nie zostały jeszcze zsynchronizowane z pomocniczym elementem i są zagrożone utratą.
Aby uzyskać więcej informacji na temat sprawdzania właściwości Czas ostatniej synchronizacji, zobacz Sprawdzanie właściwości Czas ostatniej synchronizacji dla konta magazynu.
Spójność plików dla usługi Azure Data Lake Storage
Replikacja kont magazynu z włączoną hierarchiczną przestrzenią nazw (Azure Data Lake Storage) odbywa się na poziomie pliku. Ponieważ replikacja występuje na tym poziomie, awaria w regionie podstawowym może uniemożliwić pomyślne replikowanie niektórych plików w kontenerze lub katalogu do regionu pomocniczego. Spójność dla wszystkich plików w kontenerze lub katalogu po przejściu konta magazynu w tryb failover nie jest gwarantowana.
Niespójności zestawienia zmian i danych obiektów blob
Tryb failover kont magazynu zarządzany przez klienta (nieplanowany) z włączonym zestawieniem zmian może spowodować niespójności między dziennikami zestawienia zmian a danymi obiektów blob i/lub metadanymi. Takie niespójności mogą wynikać z asynchronicznego charakteru aktualizacji dziennika zmian i replikacji danych między regionami podstawowymi i pomocniczymi. Można uniknąć niespójności, stosując następujące środki ostrożności:
- Upewnij się, że wszystkie rekordy dziennika są opróżniane do plików dziennika.
- Upewnij się, że wszystkie dane magazynu są replikowane z regionu podstawowego do regionu pomocniczego.
Aby uzyskać więcej informacji na temat zestawienia zmian, zobacz Jak działa zestawienie zmian.
Należy pamiętać, że inne funkcje konta magazynu również wymagają włączenia zestawienia zmian. Te funkcje obejmują operacyjną kopię zapasową usługi Azure Blob Storage, replikację obiektów i przywracanie do punktu w czasie dla blokowych obiektów blob.
Niespójności przywracania do punktu w czasie
Tryb failover zarządzany przez klienta jest obsługiwany w przypadku kont magazynu w warstwie Standardowa ogólnego przeznaczenia w wersji 2, które obejmują blokowe obiekty blob. Jednak wykonanie trybu failover zarządzanego przez klienta na koncie magazynu resetuje najwcześniejszy możliwy punkt przywracania dla konta. Dane dotyczące przywracania do punktu w czasie dla blokowych obiektów blob są spójne tylko do czasu ukończenia pracy w trybie failover. W związku z tym można przywrócić tylko blokowe obiekty blob do punktu w czasie nie wcześniej niż czas ukończenia pracy w trybie failover. Możesz sprawdzić czas ukończenia pracy w trybie failover na karcie nadmiarowości konta magazynu w witrynie Azure Portal.
Czas i koszt pracy w trybie failover
Czas potrzebny na ukończenie pracy w trybie failover zarządzanym przez klienta po zainicjowaniu może się różnić, chociaż zazwyczaj trwa to mniej niż jedną godzinę.
Planowana praca w trybie failover zarządzana przez klienta nie traci nadmiarowości geograficznej po przejściu w tryb failover i kolejnym przejściu w tryb failover, ale nieplanowana praca w trybie failover zarządzana przez klienta.
Inicjowanie nieplanowanego trybu failover zarządzanego przez klienta automatycznie konwertuje konto magazynu na magazyn lokalnie nadmiarowy (LRS) w nowym regionie podstawowym i usuwa konto magazynu w oryginalnym regionie podstawowym.
Możesz ponownie włączyć magazyn geograficznie nadmiarowy (GRS) lub magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GRS) dla konta, ale ponowne replikowanie danych do nowego regionu pomocniczego powoduje naliczanie opłat. Ponadto wszystkie zarchiwizowane obiekty blob muszą zostać ponownie przywrócone do warstwy online, zanim konto będzie można ponownie skonfigurować pod kątem nadmiarowości geograficznej. To ponowne wypełnianie wiąże się również z dodatkową opłatą. Aby uzyskać więcej informacji na temat cen, zobacz:
Po ponownym włączeniu magazynu GRS dla konta magazynu firma Microsoft rozpocznie replikowanie danych na koncie do nowego regionu pomocniczego. Czas potrzebny na ukończenie replikacji zależy od kilku czynników. Te czynniki obejmują:
- Liczba i rozmiar obiektów na koncie magazynu. Replikowanie wielu małych obiektów może trwać dłużej niż replikowanie mniejszych i większych obiektów.
- Dostępne zasoby na potrzeby replikacji w tle, takie jak procesor CPU, pamięć, dysk i pojemność sieci WAN. Ruch na żywo ma pierwszeństwo przed replikacją geograficzną.
- Liczba migawek na obiekt blob, jeśli ma to zastosowanie.
- Strategia partycjonowania danych, jeśli konto magazynu zawiera tabele. Proces replikacji nie może skalować się poza liczbę używanych kluczy partycji.
Obsługiwane typy kont magazynu
Wszystkie oferty geograficznie nadmiarowe obsługują tryb failover zarządzany przez firmę Microsoft. Ponadto niektóre typy kont obsługują tryb failover konta zarządzanego przez klienta, jak pokazano w poniższej tabeli:
| Typ trybu failover | GRS/RA-GRS | GZRS/RA-GZRS |
|---|---|---|
| Planowana praca w trybie failover zarządzana przez klienta (wersja zapoznawcza) | Konta ogólnego przeznaczenia w wersji 2 Konta ogólnego przeznaczenia w wersji 1 — starsze konta usługi Blob Storage |
Konta ogólnego przeznaczenia, wersja 2 |
| Tryb failover zarządzany przez klienta (nieplanowany) | Konta ogólnego przeznaczenia w wersji 2 Konta ogólnego przeznaczenia w wersji 1 — starsze konta usługi Blob Storage |
Konta ogólnego przeznaczenia, wersja 2 |
| Tryb failover zarządzany przez firmę Microsoft | Wszystkie typy kont | Konta ogólnego przeznaczenia, wersja 2 |
Klasyczne konta magazynu
Ważne
Tryb failover zarządzany przez klienta jest obsługiwany tylko w przypadku kont magazynu wdrożonych przy użyciu modelu wdrażania usługi Azure Resource Manager (ARM). Model wdrażania programu Azure Service Manager (ASM), znany również jako model klasyczny , nie jest obsługiwany. Aby klasyczne konta magazynu kwalifikowały się do trybu failover konta zarządzanego przez klienta, należy najpierw przeprowadzić migrację do modelu usługi ARM. Aby przeprowadzić uaktualnienie, konto magazynu musi być dostępne, więc region podstawowy nie może być w stanie niepowodzenia.
Podczas awarii, która ma wpływ na region podstawowy, firma Microsoft będzie zarządzać trybem failover dla klasycznych kont magazynu. Aby uzyskać więcej informacji, zobacz Tryb failover zarządzany przez firmę Microsoft.
Hierarchiczna przestrzeń nazw (HNS)
Ważne
Tryb failover zarządzany przez klienta (nieplanowany) dla kont z włączoną usługą Azure Data Lake Storage Gen2 jest obecnie w wersji zapoznawczej i obsługiwany we wszystkich regionach publicznych GRS/GZRS.
Aby wyrazić zgodę na korzystanie z wersji zapoznawczej, zobacz Konfigurowanie funkcji w wersji zapoznawczej w subskrypcji platformy Azure i określanie AllowHNSAccountFailover jej jako nazwy funkcji.
Ważne
Tryb failover zarządzany przez klienta (nieplanowany) dla kont z włączonym protokołem SSH File Transfer Protocol (SFTP) jest obecnie w wersji zapoznawczej i obsługiwany tylko w następujących regionach:
- (Azja i Pacyfik) Indie Środkowe
- (Azja i Pacyfik) Azja Południowo-Wschodnia
- (Europa) Europa Północna
- (Europa) Szwajcaria Północna
- (Europa) Szwajcaria Zachodnia
- (Europa) Europa Zachodnia
- (Ameryka Północna) Kanada Środkowa
- (Ameryka Północna) Wschodnie stany USA 2
- (Ameryka Północna) Południowo-środkowe stany USA
Aby wyrazić zgodę na korzystanie z wersji zapoznawczej, zobacz Konfigurowanie funkcji w wersji zapoznawczej w subskrypcji platformy Azure i określanie AllowHNSAccountFailover jej jako nazwy funkcji.
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.
W przypadku znacznej awarii, która ma wpływ na region podstawowy, firma Microsoft będzie zarządzać trybem failover dla kont z hierarchiczną przestrzenią nazw. Aby uzyskać więcej informacji, zobacz Tryb failover zarządzany przez firmę Microsoft.
Nieobsługiwane funkcje i usługi
Następujące funkcje i usługi nie są obsługiwane w przypadku trybu failover zarządzanego przez klienta:
- Usługa Azure File Sync nie obsługuje trybu failover konta zarządzanego przez klienta. Konta magazynu używane jako punkty końcowe w chmurze dla usługi Azure File Sync nie powinny być przenoszone w tryb failover. Tryb failover zakłóca synchronizację plików i może spowodować nieoczekiwaną utratę danych nowo warstwowych plików. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące odzyskiwania po awarii za pomocą usługi Azure File Sync , aby uzyskać szczegółowe informacje.
- Nie można przejąć trybu failover konta magazynu zawierającego blokowe obiekty blob w warstwie Premium. Konta magazynu, które obsługują blokowe obiekty blob w warstwie Premium, nie obsługują obecnie nadmiarowości geograficznej.
- Tryb failover zarządzany przez klienta nie jest obsługiwany dla źródłowego lub docelowego konta w zasadach replikacji obiektów.
- System plików sieciowych (NFS) 3.0 (NFSv3) nie jest obsługiwany w przypadku trybu failover konta magazynu. Nie można utworzyć konta magazynu skonfigurowanego na potrzeby nadmiarowości geograficznej z włączonym systemem plików NFSv3.
Poniższa tabela może służyć do odwołowania się do obsługi funkcji.
| Planowane przejście w tryb failover | Nieplanowany tryb failover | |
|---|---|---|
| Azure Data Lake Storage | Obsługiwane (wersja zapoznawcza) | Obsługiwane (wersja zapoznawcza) |
| Zestawienie zmian | Nieobsługiwane | Obsługiwane |
| Replikacja obiektów | Nieobsługiwane | Nieobsługiwane |
| SFTP | Obsługiwane (wersja zapoznawcza) | Obsługiwane (wersja zapoznawcza) |
| NFSv3 | Magazyn GRS nie jest obsługiwany | Magazyn GRS nie jest obsługiwany |
| Akcje magazynu | Nieobsługiwane | Nieobsługiwane |
| Przywracanie do punktu w czasie (PITR) | Nieobsługiwane | Obsługiwane |
Tryb failover nie jest przeznaczony do migracji konta
Tryb failover konta magazynu to tymczasowe rozwiązanie, które może służyć do planowania i testowania planów odzyskiwania po awarii lub odzyskiwania po awarii usługi. Tryb failover nie powinien być używany w ramach strategii migracji danych. Aby uzyskać informacje na temat migrowania kont magazynu, zobacz Omówienie migracji usługi Azure Storage.
Konta magazynu zawierające zarchiwizowane obiekty blob
Konta magazynu zawierające zarchiwizowane obiekty blob obsługują tryb failover konta. Jednak po zakończeniu pracy w trybie failover zarządzanego przez klienta wszystkie zarchiwizowane obiekty blob muszą zostać ponownie przywrócone do warstwy online, zanim będzie można skonfigurować konto na potrzeby nadmiarowości geograficznej.
Dostawca zasobów magazynu
Firma Microsoft udostępnia dwa interfejsy API REST do pracy z zasobami usługi Azure Storage. Te interfejsy API stanowią podstawę wszystkich akcji, które można wykonać w usłudze Azure Storage. Interfejs API REST usługi Azure Storage umożliwia pracę z danymi na koncie magazynu, w tym z danymi obiektów blob, kolejki, plików i tabel. Interfejs API REST dostawcy zasobów usługi Azure Storage umożliwia zarządzanie kontem magazynu i powiązanymi zasobami.
Po zakończeniu pracy w trybie failover klienci mogą ponownie odczytywać i zapisywać dane usługi Azure Storage w nowym regionie podstawowym. Jednak dostawca zasobów usługi Azure Storage nie przełączy się w tryb failover, więc operacje zarządzania zasobami muszą być nadal wykonywane w regionie podstawowym. Jeśli region podstawowy jest niedostępny, nie będzie można wykonywać operacji zarządzania na koncie magazynu.
Ponieważ dostawca zasobów usługi Azure Storage nie przejdzie w tryb failover, właściwość Location zwróci oryginalną lokalizację podstawową po zakończeniu pracy w trybie failover.
Maszyny wirtualne platformy Azure
Maszyny wirtualne platformy Azure nie są w trybie failover w ramach trybu failover konta magazynu. Wszystkie maszyny wirtualne, które przełączyły się w tryb failover do regionu pomocniczego w odpowiedzi na awarię, muszą zostać ponownie utworzone po zakończeniu pracy w trybie failover. Tryb failover konta może potencjalnie spowodować utratę danych przechowywanych na dysku tymczasowym po zamknięciu maszyny wirtualnej. Firma Microsoft zaleca przestrzeganie wskazówek dotyczących wysokiej dostępności i odzyskiwania po awarii specyficznych dla maszyn wirtualnych na platformie Azure.
Dyski niezarządzane platformy Azure
Dyski niezarządzane są przechowywane jako stronicowe obiekty blob w usłudze Azure Storage. Gdy maszyna wirtualna jest uruchomiona na platformie Azure, wszystkie niezarządzane dyski dołączone do maszyny wirtualnej są dzierżawione. Tryb failover konta nie może być kontynuowany, gdy istnieje dzierżawa obiektu blob. Aby można było zainicjować tryb failover na koncie zawierającym dyski niezarządzane dołączone do maszyn wirtualnych platformy Azure, należy zamknąć dyski. Z tego powodu zalecane przez firmę Microsoft najlepsze rozwiązania obejmują konwertowanie wszystkich dysków niezarządzanych na dyski zarządzane.
Aby wykonać tryb failover na koncie zawierającym dyski niezarządzane, wykonaj następujące kroki:
- Przed rozpoczęciem zanotuj nazwy wszystkich dysków niezarządzanych, ich numerów jednostek logicznych (LUN) i maszyny wirtualnej, do której są dołączone. Dzięki temu łatwiej będzie ponownie dołączyć dyski po przejściu w tryb failover.
- Zamknij maszynę wirtualną.
- Usuń maszynę wirtualną, ale zachowaj pliki wirtualnego dysku twardego (VHD) dla dysków niezarządzanych. Zanotuj czas usunięcia maszyny wirtualnej.
- Poczekaj na zaktualizowanie czasu ostatniej synchronizacji i upewnij się, że jest on późniejszy niż czas usunięcia maszyny wirtualnej. Ten krok gwarantuje, że pomocniczy punkt końcowy zostanie w pełni zaktualizowany przy użyciu plików VHD, gdy nastąpi przejście w tryb failover, oraz że maszyna wirtualna działa prawidłowo w nowym regionie podstawowym.
- Zainicjuj tryb failover konta.
- Poczekaj na ukończenie trybu failover konta, a region pomocniczy stanie się nowym regionem podstawowym.
- Utwórz maszynę wirtualną w nowym regionie podstawowym i dołącz ponownie dyski VHD.
- Uruchom nową maszynę wirtualną.
Pamiętaj, że wszystkie dane przechowywane na dysku tymczasowym zostaną utracone po zamknięciu maszyny wirtualnej.
Kopiowanie danych jako alternatywy trybu failover
Jak wspomniano wcześniej, można zachować wysoką dostępność, konfigurując aplikacje do używania konta magazynu skonfigurowanego pod kątem dostępu do odczytu do regionu pomocniczego. Jeśli jednak wolisz nie przejść w tryb failover podczas awarii w regionie podstawowym, możesz ręcznie skopiować dane jako alternatywę. Narzędzia takie jak AzCopy i Azure PowerShell umożliwiają kopiowanie danych z konta magazynu w danym regionie do innego konta magazynu w nieobjętym regionie. Po zakończeniu operacji kopiowania możesz ponownie skonfigurować aplikacje tak, aby korzystały z konta magazynu w nieobjętym regionie pod kątem dostępności odczytu i zapisu.
Projektowanie na potrzeby wysokiej dostępności
Od samego początku ważne jest zaprojektowanie aplikacji pod kątem wysokiej dostępności. Zapoznaj się z tymi zasobami platformy Azure, aby uzyskać wskazówki dotyczące projektowania aplikacji i planowania odzyskiwania po awarii:
- Projektowanie odpornych aplikacji dla platformy Azure: omówienie kluczowych pojęć związanych z tworzeniem architektury aplikacji o wysokiej dostępności na platformie Azure.
- Lista kontrolna dotycząca odporności: lista kontrolna umożliwiająca sprawdzenie, czy aplikacja implementuje najlepsze rozwiązania projektowe dotyczące wysokiej dostępności.
- Nadmiarowość geograficzna umożliwia projektowanie aplikacji o wysokiej dostępności: wskazówki dotyczące projektowania tworzenia aplikacji w celu korzystania z magazynu geograficznie nadmiarowego.
- Samouczek: tworzenie aplikacji o wysokiej dostępności za pomocą usługi Blob Storage: samouczek pokazujący, jak utworzyć aplikację o wysokiej dostępności, która automatycznie przełącza się między punktami końcowymi w miarę symulowania awarii i odzyskiwania.
Zapoznaj się z tymi najlepszymi rozwiązaniami, aby zachować wysoką dostępność danych usługi Azure Storage:
- Dyski: użyj usługi Azure Backup, aby utworzyć kopię zapasową dysków maszyn wirtualnych używanych przez maszyny wirtualne platformy Azure. Rozważ również użycie usługi Azure Site Recovery do ochrony maszyn wirtualnych przed awarią regionalną.
- Blokowe obiekty blob: włącz usuwanie nietrwałe, aby chronić przed usuwaniem na poziomie obiektu i zastępowaniem lub kopiowanie blokowych obiektów blob na inne konto magazynu w innym regionie przy użyciu narzędzia AzCopy, programu Azure PowerShell lub biblioteki usługi Azure Data Movement.
- Pliki: użyj usługi Azure Backup, aby utworzyć kopię zapasową udziałów plików. Włącz również usuwanie nietrwałe, aby chronić przed przypadkowym usunięciem udziału plików. W przypadku nadmiarowości geograficznej, gdy magazyn GRS nie jest dostępny, użyj narzędzia AzCopy lub programu Azure PowerShell , aby skopiować pliki na inne konto magazynu w innym regionie.
- Tabele: użyj narzędzia AzCopy , aby wyeksportować dane tabeli do innego konta magazynu w innym regionie.
Śledzenie awarii
Klienci mogą subskrybować pulpit nawigacyjny usługi Azure Service Health, aby śledzić kondycję i stan usługi Azure Storage i innych usług platformy Azure.
Firma Microsoft zaleca również projektowanie aplikacji z uwzględnieniem możliwości wystąpienia błędów zapisu. Aplikacja powinna ujawniać błędy zapisu w sposób, który ostrzega o możliwości wystąpienia awarii w regionie podstawowym.
Zobacz też
- Używanie nadmiarowości geograficznej do projektowania aplikacji o wysokiej dostępności
- Samouczek: tworzenie aplikacji o wysokiej dostępności za pomocą usługi Blob Storage
- Nadmiarowość usługi Azure Storage
- Jak działa planowane przejście w tryb failover zarządzane przez klienta (wersja zapoznawcza)
- Jak działa tryb failover zarządzany przez klienta (nieplanowany)