Udostępnij za pośrednictwem

Odzyskiwanie po awarii i tryb failover dla usługi Azure Files

  • Artykuł

Firma Microsoft stara się zapewnić, że usługi platformy Azure są zawsze dostępne. Jednak mogą wystąpić nieplanowane awarie usług i należy mieć plan odzyskiwania po awarii (DR) na potrzeby obsługi awarii usługi regionalnej. Ważną częścią planu odzyskiwania po awarii jest przygotowanie do przejścia w tryb failover do pomocniczego punktu końcowego w przypadku niedostępności podstawowego punktu końcowego. W tym artykule opisano pojęcia i procesy związane z odzyskiwaniem po awarii i trybem failover konta magazynu.

Ważne

Usługa Azure File Sync obsługuje tryb failover konta magazynu tylko wtedy, gdy usługa synchronizacji magazynu również zostanie przełączona w tryb failover. Dzieje się tak, ponieważ usługa Azure File Sync wymaga, aby konto magazynu i usługa synchronizacji magazynu znajdowały się w tym samym regionie świadczenia usługi Azure. Jeśli tylko konto magazynu zostanie przełączone w tryb failover, operacje synchronizacji i obsługi warstw w chmurze zakończy się niepowodzeniem, dopóki usługa synchronizacji magazynu nie zostanie przełączona w tryb failover do regionu pomocniczego. Jeśli chcesz przełączyć konto magazynu w tryb failover zawierające udziały plików platformy Azure, które są używane jako punkty końcowe w chmurze w usłudze Azure File Sync, zobacz Najlepsze rozwiązania dotyczące odzyskiwania po awarii usługi Azure File Sync i odzyskiwanie serwera usługi Azure File Sync.

Planowana praca w trybie failover zarządzana przez klienta (wersja zapoznawcza)

Planowane przejście w tryb failover zarządzane przez klienta może być również używane 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.

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.

Metryki i koszty odzyskiwania

Aby sformułować skuteczną strategię odzyskiwania po awarii, organizacja musi zrozumieć:

  • Ile danych może pozwolić sobie na utratę w przypadku zakłóceń (cel punktu odzyskiwania lub cel punktu odzyskiwania)
  • Jak szybko musi być w stanie przywrócić funkcje biznesowe i dane (cel czasu odzyskiwania lub cel czasu odzyskiwania)

Koszt odzyskiwania po awarii zwykle zwiększa się o niższy lub zerowy cel punktu odzyskiwania/cel punktu odzyskiwania. Firmy, które muszą być uruchomione w ciągu kilku sekund po awarii i nie mogą utrzymać żadnej utraty danych, będą płacić więcej za odzyskiwanie po awarii, podczas gdy osoby z wyższymi numerami RPO/RTO będą płacić mniej. Platforma Azure udostępnia rozwiązania, które mogą współdziałać z różnymi wymaganiami celu punktu odzyskiwania i celu odzyskiwania.

Wybieranie odpowiedniej opcji nadmiarowości

Usługa Azure Files oferuje różne opcje nadmiarowości, aby chronić dane przed zaplanowanymi i nieplanowanymi zdarzeniami, od przejściowych awarii sprzętu, awarii sieci i zasilania po klęski żywiołowe. Wszystkie udziały plików platformy Azure mogą używać magazynu lokalnie nadmiarowego (LRS) lub magazynu strefowo nadmiarowego (ZRS). Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Files.

Usługa Azure Files obsługuje tryb failover kont magazynu w warstwie Standardowa skonfigurowanych z magazynem geograficznie nadmiarowym (GRS) i magazynem geograficznie nadmiarowym (GZRS) w celu ochrony przed awariami regionalnymi. Dzięki trybowi failover konta możesz zainicjować proces przełączania w tryb failover dla konta magazynu, jeśli podstawowy punkt końcowy stanie się niedostępny. Tryb failover aktualizuje pomocniczy punkt końcowy, aby stał się podstawowym punktem końcowym konta magazynu. Po zakończeniu przełączania w tryb failover klienci mogą rozpocząć zapisywanie w nowym podstawowym punkcie końcowym.

Magazyn GRS i magazyn GZRS nadal niesie ze sobą ryzyko utraty danych, ponieważ dane są kopiowane do regionu pomocniczego asynchronicznie, co oznacza, że istnieje opóźnienie przed skopiowanie zapisu do regionu podstawowego do regionu pomocniczego. W przypadku awarii operacje zapisu w podstawowym punkcie końcowym, który nie został jeszcze skopiowany do pomocniczego punktu końcowego, zostaną utracone. Oznacza to, że awaria, która ma wpływ na region podstawowy, może spowodować utratę danych, jeśli nie można odzyskać regionu podstawowego. Interwał między najnowszymi zapisami w regionie podstawowym a ostatnim zapisem w regionie pomocniczym jest cel punktu odzyskiwania. Usługa Azure Files zwykle ma cel punktu odzyskiwania 15 minut lub mniej, chociaż obecnie nie ma umowy SLA dotyczącej czasu replikacji danych do regionu pomocniczego.

Ważne

Magazyn GRS/GZRS nie jest obsługiwany w przypadku udziałów plików platformy Azure w warstwie Premium. Można jednak zsynchronizować między dwoma udziałami plików platformy Azure, aby uzyskać nadmiarowość geograficzną.

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:

Zalecamy również zaprojektowanie aplikacji w celu przygotowania się do 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.

Najlepszym rozwiązaniem jest zaprojektowanie aplikacji w celu sprawdzenia właściwości Czas ostatniej synchronizacji w celu oceny oczekiwanej utraty danych. Jeśli na przykład rejestrujesz wszystkie operacje zapisu, możesz porównać czas ostatnich operacji zapisu z godziną ostatniej synchronizacji, aby określić, które zapisy nie zostały zsynchronizowane z pomocniczym.

Śledzenie awarii

Możesz subskrybować pulpit nawigacyjny usługi Azure Service Health, aby śledzić kondycję i stan usługi Azure Files i innych usług platformy Azure.

Informacje na temat procesu przełączania konta w tryb failover

Tryb failover konta zarządzanego przez klienta umożliwia przełączenie całego konta magazynu w tryb failover do regionu pomocniczego, jeśli z jakiegokolwiek powodu podstawowa stanie się niedostępna. Gdy wymusisz przejście w tryb failover do regionu pomocniczego, klienci mogą rozpocząć zapisywanie danych w pomocniczym punkcie końcowym po zakończeniu pracy w trybie failover. Przejście w tryb failover zwykle trwa około godziny. Zalecamy wstrzymanie obciążenia tak bardzo, jak to możliwe przed zainicjowaniem trybu failover konta.

Aby dowiedzieć się, jak zainicjować tryb failover konta, zobacz Inicjowanie trybu failover konta.

Jak działa praca w trybie failover dla konta

W normalnych okolicznościach klient zapisuje dane na koncie magazynu w regionie podstawowym i dane są kopiowane asynchronicznie do regionu pomocniczego. Na poniższej ilustracji przedstawiono scenariusz, w którym region podstawowy jest dostępny:

Diagram przedstawiający sposób zapisywania danych przez klientów na koncie magazynu w regionie podstawowym.

Jeśli podstawowy punkt końcowy stanie się niedostępny z jakiegokolwiek powodu, klient nie może już zapisywać danych na koncie magazynu. Na poniższej ilustracji przedstawiono scenariusz, w którym podstawowy stał się niedostępny, ale nie nastąpiło jeszcze żadne odzyskiwanie:

Diagram przedstawiający podstawowy jest niedostępny, więc klienci nie mogą zapisywać danych.

Klient inicjuje przejście konta w tryb failover do pomocniczego punktu końcowego. Proces trybu failover aktualizuje wpis DNS udostępniany przez usługę Azure Storage, aby pomocniczy punkt końcowy stał się nowym podstawowym punktem końcowym konta magazynu, jak pokazano na poniższej ilustracji:

Diagram przedstawiający klient inicjuje przejście konta w tryb failover do pomocniczego punktu końcowego.

Dostęp do zapisu jest przywracany dla kont geograficznie nadmiarowych po zaktualizowaniu wpisu DNS, a żądania są kierowane do nowego podstawowego punktu końcowego. Istniejące punkty końcowe usługi magazynu pozostają takie same po przejściu w tryb failover. Obsługa plików i dzierżawy nie są zachowywane w trybie failover, dlatego klienci muszą odinstalować i ponownie zainstalować udziały plików.

Ważne

Po zakończeniu pracy w trybie failover konto magazynu jest skonfigurowane jako lokalnie nadmiarowe w nowym podstawowym punkcie końcowym/regionie. Aby wznowić replikację do nowej pomocniczej, ponownie skonfiguruj konto na potrzeby nadmiarowości geograficznej.

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 pracy w trybie failover.

Przewidywanie utraty danych

Uwaga

Przejście konta w tryb failover zwykle wiąże się z utratą danych. Ważne jest, aby zrozumieć implikacje inicjowania trybu failover konta.

Ponieważ dane są zapisywane asynchronicznie z regionu podstawowego do regionu pomocniczego, jeśli region podstawowy stanie się niedostępny, najnowsze zapisy mogą nie zostać jeszcze skopiowane do regionu pomocniczego.

Gdy wymusisz przejście w tryb failover, wszystkie dane w regionie podstawowym zostaną utracone, ponieważ region pomocniczy stanie się nowym regionem podstawowym. Nowy region podstawowy jest skonfigurowany jako lokalnie nadmiarowy po przejściu w tryb failover.

Wszystkie dane już skopiowane do pomocniczej są zachowywane po przejściu w tryb failover. Jednak wszystkie dane zapisane w bazie podstawowej, które nie zostały również skopiowane do pomocniczej, zostaną trwale utracone.

Sprawdzanie właściwości czasu ostatniej synchronizacji

Właściwość Czas ostatniej synchronizacji (LST) wskazuje ostatni raz, gdy dane z regionu podstawowego mają gwarancję, że zostały zapisane w regionie pomocniczym. Wszystkie dane zapisane przed ostatnim czasem synchronizacji są dostępne w pomocniczej bazie danych, natomiast dane zapisane po ostatniej synchronizacji mogły nie zostać zapisane w pomocniczej godzinie i mogą zostać utracone. Użyj tej właściwości w przypadku awarii, aby oszacować ilość utraty danych, którą można ponieść, inicjując tryb failover konta.

Aby zapewnić, że udziały plików są w stanie spójnym po przejściu w tryb failover, migawka systemu jest tworzona w regionie podstawowym co 15 minut i jest replikowana do regionu pomocniczego. W przypadku przejścia w tryb failover do regionu pomocniczego stan udziału będzie oparty na najnowszej migawki systemu w regionie pomocniczym. Jeśli wystąpi awaria w regionie podstawowym, region pomocniczy prawdopodobnie znajduje się za regionem podstawowym, ponieważ wszystkie operacje zapisu w regionie podstawowym nie zostaną jeszcze zreplikowane do pomocniczego. Ze względu na opóźnienie geograficzne lub inne problemy najnowsza migawka systemu w regionie pomocniczym może być starsza niż 15 minut.

Wszystkie operacje zapisu zapisane w regionie podstawowym przed ukończeniem LST zostały pomyślnie zreplikowane do regionu pomocniczego, co oznacza, że są dostępne do odczytu z pomocniczego. Wszystkie operacje zapisu zapisane w regionie podstawowym po ostatniej synchronizacji mogą lub nie zostały zreplikowane do regionu pomocniczego, co oznacza, że mogą nie być dostępne dla operacji odczytu.

Możesz wykonać zapytanie dotyczące wartości właściwości Czas ostatniej synchronizacji przy użyciu programu Azure PowerShell, interfejsu wiersza polecenia platformy Azure lub biblioteki klienta. Właściwość Czas ostatniej synchronizacji jest wartością daty/godziny GMT. Aby uzyskać więcej informacji, zobacz Sprawdzanie właściwości Czas ostatniej synchronizacji dla konta magazynu.

Należy zachować ostrożność podczas powrotu po awarii do oryginalnego elementu podstawowego

Jak wspomniano wcześniej, po przejściu w tryb failover z regionu podstawowego do regionu pomocniczego konto magazynu jest skonfigurowane jako lokalnie nadmiarowe w nowym regionie podstawowym. Następnie możesz skonfigurować konto w nowym regionie podstawowym na potrzeby nadmiarowości geograficznej. Po skonfigurowaniu konta na potrzeby nadmiarowości geograficznej po przejściu w tryb failover nowy region podstawowy natychmiast rozpoczyna kopiowanie danych do nowego regionu pomocniczego, który był podstawowym elementem podstawowym przed oryginalnym przejściem w tryb failover. Jednak może upłynąć trochę czasu, zanim istniejące dane w nowym podstawowym będą w pełni kopiowane do nowej pomocniczej.

Po ponownym skonfigurowaniu konta magazynu na potrzeby nadmiarowości geograficznej można zainicjować powrót po awarii z nowego podstawowego do nowego pomocniczego. W takim przypadku oryginalny region podstawowy przed przejściem w tryb failover ponownie stanie się regionem podstawowym i jest skonfigurowany tak, aby był lokalnie nadmiarowy lub strefowo nadmiarowy, w zależności od tego, czy oryginalna konfiguracja podstawowa to GRS, czy GZRS. Wszystkie dane w regionie podstawowym po przejściu w tryb failover (oryginalny pomocniczy) zostaną utracone podczas powrotu po awarii. Jeśli większość danych na koncie magazynu nie została skopiowana do nowej pomocniczej przed powrotem po awarii, może dojść do poważnej utraty danych.

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 ostatnim zapisem danych w nowym podstawowym, aby ocenić oczekiwaną utratę danych.

Po operacji powrotu po awarii można ponownie skonfigurować nowy region podstawowy jako geograficznie nadmiarowy. Jeśli oryginalna podstawowa baza danych została skonfigurowana dla magazynu LRS, można skonfigurować ją tak, aby była magazynem GRS. Jeśli oryginalny podstawowy został skonfigurowany dla magazynu ZRS, można skonfigurować go tak, aby był GZRS. Aby uzyskać dodatkowe opcje, zobacz Zmienianie sposobu replikacji konta magazynu.

Inicjowanie trybu failover konta

Możesz zainicjować tryb failover konta w witrynie Azure Portal, programie PowerShell, interfejsie wiersza polecenia platformy Azure lub interfejsie API dostawcy zasobów usługi Azure Storage. Aby uzyskać więcej informacji na temat inicjowania trybu failover, zobacz Inicjowanie trybu failover konta.

Tryb failover zarządzany przez firmę Microsoft

W ekstremalnych okolicznościach, w których region zostanie utracony z powodu znacznej awarii, firma Microsoft może zainicjować regionalną pracę w trybie failover. W takim przypadku nie jest wymagana żadna akcja ze swojej strony. Do czasu ukończenia trybu failover zarządzanego przez firmę Microsoft nie będziesz mieć dostępu do zapisu na koncie magazynu.

Zobacz też