Odzyskiwanie po awarii i tryb failover dla usługi Azure Files
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.
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:
- 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 dla udziałów plików SMB.
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.
Na czym polega przełączanie konta w tryb failover
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:
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:
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:
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 Ważne implikacje dotyczące trybu failover konta.
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.