Planowanie i przechodzenie w tryb failover w usłudze Azure Storage po awarii

  • Artykuł

Firma Microsoft stara się zapewnić, że usługi platformy Azure są zawsze dostępne. Mogą jednak wystąpić nieplanowane awarie usługi. Kluczowe składniki dobrego planu odzyskiwania po awarii obejmują strategie:

Ten artykuł koncentruje się na przejściu w tryb failover dla globalnie nadmiarowych kont magazynu (GRS, GZRS i RA-GZRS) oraz sposobu projektowania aplikacji pod kątem wysokiej dostępności w przypadku awarii i późniejszego przejścia w tryb failover.

Wybieranie odpowiedniej opcji nadmiarowości

Usługa Azure Storage obsługuje wiele kopii konta magazynu w celu zapewnienia trwałości i wysokiej dostępności. Wybrana opcja nadmiarowości dla konta zależy od stopnia odporności potrzebnej dla aplikacji.

W przypadku magazynu lokalnie nadmiarowego (LRS) trzy kopie konta magazynu są automatycznie przechowywane i replikowane w jednym centrum danych. W przypadku magazynu strefowo nadmiarowego (ZRS) kopia jest przechowywana i replikowana 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.

Odzyskiwanie pojedynczej kopii konta magazynu odbywa się automatycznie przy użyciu magazynu LRS i ZRS.

Magazyn globalnie nadmiarowy i tryb failover

Dzięki magazynowi globalnie nadmiarowemu (GRS, GZRS i RA-GZRS) platforma Azure kopiuje dane asynchronicznie do pomocniczego regionu geograficznego co najmniej setki kilometrów. Umożliwia to odzyskanie danych w przypadku awarii w regionie podstawowym. Funkcja, która odróżnia magazyn globalnie nadmiarowy od magazynu LRS i magazynu ZRS, to możliwość przejścia w tryb failover do regionu pomocniczego, jeśli wystąpi awaria w regionie podstawowym. Proces przełączania w tryb failover aktualizuje wpisy DNS dla punktów końcowych usługi konta magazynu, tak aby punkty końcowe dla regionu pomocniczego stały się nowymi podstawowymi punktami końcowymi dla konta magazynu. Po zakończeniu pracy w trybie failover klienci mogą rozpocząć zapisywanie w nowych podstawowych punktach końcowych.

Konfiguracje nadmiarowości RA-GRS i RA-GZRS zapewniają magazyn geograficznie nadmiarowy z dodatkową korzyścią dostępu do odczytu do pomocniczego punktu końcowego w przypadku awarii w regionie podstawowym. Jeśli w podstawowym punkcie końcowym wystąpi awaria, aplikacje skonfigurowane pod kątem dostępu do odczytu do regionu pomocniczego i zaprojektowane pod kątem wysokiej dostępności mogą nadal odczytywać z pomocniczego punktu końcowego. 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 w usłudze Azure Storage, zobacz Nadmiarowość usługi Azure Storage.

Planowanie trybu failover konta magazynu

Konta usługi Azure Storage obsługują dwa typy trybu failover:

  • Tryb failover zarządzany przez klienta — 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 tylko w przypadku poważnej awarii w regionie podstawowym. 1,2

1Nie 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 Plan odzyskiwania po awarii powinien być oparty na trybie failover zarządzanym przez klienta. 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 Gen2). Ta tabela zawiera podsumowanie tych aspektów każdego typu trybu failover:

Typ Zakres trybu failover Przypadek użycia Oczekiwana utrata danych Obsługiwana usługa HNS
Zarządzane przez klienta 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 lub jednostka skalowania Region podstawowy staje się całkowicie niedostępny z powodu znacznej awarii, ale region pomocniczy jest dostępny. Tak Tak

Tryb failover zarządzany przez klienta

Jeśli punkty końcowe danych dla usług magazynu na koncie magazynu staną się niedostępne w regionie podstawowym, możesz przejść w tryb failover do regionu pomocniczego. Po zakończeniu pracy w trybie failover region pomocniczy staje się nowym podstawowym, a użytkownicy mogą przejść do danych w nowym regionie podstawowym.

Aby w pełni zrozumieć wpływ trybu failover konta zarządzanego przez klienta na użytkowników i aplikacje, warto wiedzieć, co się dzieje podczas każdego kroku procesu przechodzenia w tryb failover i powrotu po awarii. Aby uzyskać szczegółowe informacje o sposobie działania procesu, zobacz Jak działa tryb failover konta magazynu zarządzanego przez klienta.

Tryb failover zarządzany przez firmę Microsoft

W ekstremalnych okolicznościach, gdy oryginalny region podstawowy jest uznawany za nieodwracalny w rozsądnym czasie z powodu poważnej awarii, firma Microsoft może zainicjować regionalny tryb failover. W takim przypadku nie jest wymagana żadna akcja w Twojej części. Do czasu ukończenia trybu failover zarządzanego przez firmę Microsoft nie będziesz mieć dostępu do zapisu na koncie magazynu. Aplikacje mogą odczytywać dane z regionu pomocniczego, jeśli konto magazynu jest skonfigurowane dla magazynu RA-GRS lub RA-GZRS.

Ważne

Plan odzyskiwania po awarii powinien być oparty na trybie failover zarządzanym przez klienta. 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 jednostka skalowania. Nie można go zainicjować dla poszczególnych kont magazynu, subskrypcji ani dzierżaw. Aby można było selektywnie przejść w tryb failover poszczególnych kont magazynu, użyj trybu failover konta zarządzanego przez klienta.

Przewidywanie utraty i niespójności danych

Uwaga

Przejście konta magazynu w tryb failover zwykle wiąże się z utratą danych i potencjalnie niespójnościami 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, najnowsze zapisy mogły jeszcze nie zostać skopiowane do pomocniczej.

W przypadku przejścia w tryb failover wszystkie dane w regionie podstawowym zostaną utracone, ponieważ region pomocniczy staje się nowym podstawowym. Wszystkie dane już skopiowane do pomocniczej są zachowywane po przejściu w tryb failover. Jednak wszystkie dane zapisane w regionie podstawowym, które nie zostały również skopiowane do regionu pomocniczego, 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:

Czas ostatniej synchronizacji

Właściwość Czas ostatniej synchronizacji wskazuje ostatni raz, że dane z regionu podstawowego mają gwarancję, że zostały 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 listy ACL. Wszystkie dane i metadane zapisane przed ostatnim czasem synchronizacji są dostępne w pomocniczej bazie danych, natomiast dane i metadane zapisane po ostatniej synchronizacji mogły nie zostać zapisane w pomocniczym czasie i mogą zostać utracone. Użyj tej właściwości, jeśli wystąpi awaria, aby oszacować ilość utraty danych, którą możesz ponieść, inicjując tryb failover konta.

Najlepszym rozwiązaniem jest zaprojektowanie aplikacji tak, aby można było użyć czasu ostatniej synchronizacji, aby ocenić oczekiwaną utratę 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.

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 Gen2

Replikacja kont magazynu z włączoną hierarchiczną przestrzenią nazw (Azure Data Lake Storage Gen2) odbywa się na poziomie pliku. Oznacza to, że w przypadku wystąpienia awarii w regionie podstawowym możliwe jest, że tylko niektóre pliki w kontenerze lub katalogu mogły zostać pomyślnie zreplikowane 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 konta magazynu geograficznie nadmiarowego 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 obu aktualizacji dzienników zmian oraz replikacji danych obiektów blob z regionu podstawowego do regionu pomocniczego. Jedyną sytuacją, w której nie można oczekiwać niespójności, jest to, że wszystkie bieżące rekordy dziennika zostały pomyślnie opróżnione do plików dziennika, a wszystkie dane magazynu zostały pomyślnie zreplikowane z regionu podstawowego do regionu pomocniczego.

Aby uzyskać informacje o sposobie działania zestawienia zmian, zobacz Jak działa zestawienie zmian.

Należy pamiętać, że inne funkcje konta magazynu wymagają włączenia zestawienia zmian, takiego jak operacyjna kopia zapasowa usługi Azure Blob Storage, replikacja 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.

Załóżmy na przykład, że okres przechowywania został ustawiony na 30 dni. Jeśli upłynęło więcej niż 30 dni od przejścia w tryb failover, możesz przywrócić do dowolnego punktu w ciągu tych 30 dni. Jeśli jednak upłynęło mniej niż 30 dni od przejścia w tryb failover, nie można przywrócić do punktu przed przejściem w tryb failover, niezależnie od okresu przechowywania. Jeśli na przykład minęło 10 dni od przejścia w tryb failover, najwcześniejszy możliwy punkt przywracania wynosi 10 dni w ciągu ostatnich, a nie 30 dni w przeszłości.

Czas i koszt pracy w trybie failover

Czas potrzebny na ukończenie pracy w trybie failover po zainicjowaniu może się różnić, chociaż zazwyczaj trwa to mniej niż jedną godzinę.

Tryb failover zarządzany przez klienta traci nadmiarowość geograficzną po przejściu w tryb failover (i powrotu po awarii). Konto magazynu jest automatycznie konwertowane na magazyn lokalnie nadmiarowy (LRS) w nowym regionie podstawowym podczas pracy w trybie failover, a konto magazynu w oryginalnym regionie podstawowym zostanie usunięte.

Możesz ponownie włączyć magazyn geograficznie nadmiarowy (GRS) lub magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GRS) dla konta, ale należy pamiętać, że konwersja z magazynu LRS na GRS lub RA-GRS wiąże się z dodatkowymi kosztami. Koszt jest spowodowany opłatami za ruch wychodzący sieci w celu ponownego replikowania danych do nowego regionu pomocniczego. Ponadto wszystkie zarchiwizowane obiekty blob muszą zostać ponownie przywrócone do warstwy online, zanim konto będzie można skonfigurować pod kątem nadmiarowości geograficznej, co spowoduje naliczenie kosztów. 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 replikacji zależy od wielu czynników, takich jak:

  • 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ą.
  • Jeśli konto magazynu zawiera obiekty blob, liczba migawek na obiekt blob.
  • Jeśli konto magazynu zawiera tabele, strategia partycjonowania danych. 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
Tryb failover zarządzany przez klienta 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 konta zarządzanego 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 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.

Jeśli wystąpi awaria, 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.

Azure Data Lake Storage Gen2

Ważne

Tryb failover konta zarządzanego przez klienta dla kont z hierarchiczną przestrzenią nazw (Azure Data Lake Storage Gen2) jest obecnie w wersji zapoznawczej i jest 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.

Jeśli wystąpi znaczna awaria, 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 konta:

  • Usługa Azure File Sync nie obsługuje trybu failover konta magazynu zainicjowanego przez klienta. Konta magazynu zawierające udziały plików platformy Azure używane jako punkty końcowe w chmurze w usłudze Azure File Sync nie powinny być przenoszone w tryb failover. Wykonanie tej operacji spowoduje, że synchronizacja przestanie działać, a także może spowodować nieoczekiwaną utratę danych w przypadku nowych plików warstwowych. 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.
  • Aby przepracować konto w trybie failover z włączonym protokołem SSH File Transfer Protocol (SFTP), musisz najpierw wyłączyć protokół SFTP dla konta. Jeśli chcesz wznowić korzystanie z protokołu SFTP po zakończeniu pracy w trybie failover, po prostu ponownie ją włącz.
  • 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 pod kątem globalnej nadmiarowości z włączonym systemem plików NFSv3.

Tryb failover nie jest przeznaczony do migracji konta

Tryb failover konta magazynu nie powinien być używany w ramach strategii migracji danych. Tryb failover to tymczasowe rozwiązanie awarii usługi. 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 konto będzie można skonfigurować pod kątem 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. Jeśli region podstawowy stanie się niedostępny i przejdziesz w tryb failover do regionu pomocniczego, musisz ponownie utworzyć wszystkie maszyny wirtualne po przejściu w tryb failover. Istnieje również potencjalna utrata danych skojarzona z trybem failover konta. Firma Microsoft zaleca przestrzeganie wskazówek dotyczących wysokiej dostępności i odzyskiwania po awarii specyficznych dla maszyn wirtualnych na platformie Azure.

Pamiętaj, że wszystkie dane przechowywane na dysku tymczasowym zostaną utracone po zamknięciu maszyny wirtualnej.

Dyski niezarządzane platformy Azure

Najlepszym rozwiązaniem jest, aby firma Microsoft zaleca konwertowanie dysków niezarządzanych na dyski zarządzane. Jeśli jednak musisz przejąć konto, które zawiera dyski niezarządzane dołączone do maszyn wirtualnych platformy Azure, musisz zamknąć maszynę wirtualną przed zainicjowaniem trybu failover.

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 wykonać tryb failover, wykonaj następujące kroki:

  1. 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.
  2. Zamknij maszynę wirtualną.
  3. Usuń maszynę wirtualną, ale zachowaj pliki VHD dla dysków niezarządzanych. Zanotuj czas usunięcia maszyny wirtualnej.
  4. Poczekaj na zaktualizowanie czasu ostatniej synchronizacji i jest późniejsza niż czas usunięcia maszyny wirtualnej. Ten krok jest ważny, ponieważ jeśli pomocniczy punkt końcowy nie został w pełni zaktualizowany przy użyciu plików VHD, gdy nastąpi przejście w tryb failover, maszyna wirtualna może nie działać prawidłowo w nowym regionie podstawowym.
  5. Zainicjuj tryb failover konta.
  6. Poczekaj na zakończenie pracy w trybie failover konta, a region pomocniczy stał się nowym regionem podstawowym.
  7. Utwórz maszynę wirtualną w nowym regionie podstawowym i dołącz ponownie dyski VHD.
  8. Uruchom nową maszynę wirtualną.

Pamiętaj, że wszystkie dane przechowywane na dysku tymczasowym zostaną utracone po zamknięciu maszyny wirtualnej.

Kopiowanie danych jako alternatywa dla przechodzenia w tryb failover

Jeśli konto magazynu jest skonfigurowane pod kątem dostępu do odczytu do regionu pomocniczego, możesz zaprojektować aplikację do odczytu z pomocniczego punktu końcowego. Jeśli wolisz nie przejść w tryb failover w przypadku awarii w regionie podstawowym, możesz użyć narzędzi, takich jak Narzędzie AzCopy lub program Azure PowerShell , aby skopiować dane z konta magazynu w regionie pomocniczym do innego konta magazynu w nieobjętym regionie. Następnie możesz wskazać aplikacje na to konto magazynu 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:

Należy pamiętać o tych najlepszych rozwiązaniach dotyczących utrzymania wysokiej dostępności danych usługi Azure Storage:

Śledzenie awarii

Klienci mogą subskrybować pulpit nawigacyjny usługi Azure Service Health w celu śledzenia kondycji i stanu usługi Azure Storage oraz 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ż