Udostępnij przez

Niezawodność w usłudze Azure Files

W tym artykule opisano obsługę niezawodności w usłudze Azure Files. Usługa Azure Files udostępnia w pełni zarządzane udziały plików w chmurze, które są dostępne za pośrednictwem standardowych w branży protokołów bloku komunikatów serwera (SMB) i sieciowego systemu plików (NFS).

W przypadku korzystania z platformy Azure niezawodność jest wspólną odpowiedzialnością. Firma Microsoft oferuje szereg możliwości wspierania odporności systemów i odzyskiwania. Odpowiadasz za zrozumienie sposobu działania tych możliwości we wszystkich używanych usługach oraz wybór możliwości potrzebnych do osiągnięcia twoich celów biznesowych i celów dostępności.

W tym artykule opisano, jak zapewnić odporność usługi Azure Files na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie strefy dostępności i awarie regionów. W tym artykule opisano również, jak można używać kopii zapasowych do odzyskiwania po innych typach problemów, oraz wyróżnia niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Azure Files.

Uwaga / Notatka

Usługa Azure Files jest częścią platformy Azure Storage. Niektóre możliwości usługi Azure Files są wspólne dla wielu usług Azure Storage. W tym artykule używamy usługi Azure Storage do odwoływania się do tych typowych możliwości.

Zalecenia dotyczące wdrażania produkcyjnego

Aby dowiedzieć się, jak wdrożyć usługę Azure Files, aby obsługiwać wymagania dotyczące niezawodności rozwiązania i jak niezawodność wpływa na inne aspekty architektury, zobacz Najlepsze rozwiązania dotyczące architektury usługi Azure Files w przewodniku Azure Well-Architected Framework.

Omówienie architektury niezawodności

Magazyn lokalnie nadmiarowy (LRS) replikuje dane w ramach kont magazynu do co najmniej jednej strefy dostępności platformy Azure znajdującej się w wybranym regionie podstawowym. Chociaż nie ma możliwości wyboru preferowanej strefy dostępności, platforma Azure może przenosić lub rozszerzać konta LRS między strefami, aby poprawić równoważenie obciążenia. Nie ma gwarancji, że dane będą rozłożone między strefy. Aby uzyskać więcej informacji na temat stref dostępności, zobacz Co to są strefy dostępności?.

Diagram przedstawiający sposób replikacji danych w strefach dostępności przy użyciu magazynu LRS.

Magazyn strefowo nadmiarowy (ZRS), magazyn geograficznie nadmiarowy (GRS) i magazyn geograficznie nadmiarowy (GZRS) zapewniają dodatkową ochronę. W tym artykule opisano szczegółowo te opcje.

Usługa Azure Files jest dostępna w dwóch warstwach multimediów:

  • Warstwa Premium używa dysków półprzewodnikowych (SSD) w celu zapewnienia wysokiej wydajności. Ta warstwa jest zalecana w przypadku obciążeń wymagających małych opóźnień.

  • Warstwa Standardowa obsługuje dyski twarde (HDD). Udziały plików na dyskach HDD stanowią ekonomiczne rozwiązanie magazynowania dla ogólnego przeznaczenia udostępniania plików.

Aby uzyskać więcej informacji, zobacz Planowanie wdrażania warstw usługi Azure Files — Storage.

Azure Files implementuje nadmiarowość na poziomie konta magazynowego, a udziały plików automatycznie dziedziczą tę konfigurację nadmiarowości. Usługa obsługuje wiele modeli nadmiarowości, które różnią się podejściem do ochrony danych.

Odporność na błędy przejściowe

Błędy przejściowe to krótkotrwałe, sporadyczne awarie w komponentach. Występują one często w środowisku rozproszonym, takich jak chmura, i są one normalną częścią operacji. Błędy przejściowe naprawiają się po krótkim czasie. Ważne jest, aby aplikacje mogły obsługiwać błędy przejściowe, zwykle ponawiając próby żądań, których dotyczy problem.

Wszystkie aplikacje hostowane w chmurze powinny postępować zgodnie ze wskazówkami dotyczącymi obsługi błędów przejściowych platformy Azure podczas komunikowania się z dowolnymi interfejsami API hostowanymi w chmurze, bazami danych i innymi składnikami. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Aby skutecznie zarządzać błędami przejściowymi podczas korzystania z usługi Azure Files, skonfiguruj odpowiednie wartości limitu czasu dla operacji na plikach na podstawie rozmiaru pliku i warunków sieciowych. Większe pliki wymagają dłuższych limitów czasu, podczas gdy mniejsze operacje mogą szybko wykrywać błędy przy użyciu krótszych wartości.

Aby zagwarantować, że tylko bezpieczne połączenia są nawiązywane z udziałem NFS, rekomendujemy skonfigurowanie prywatnego punktu końcowego dla rachunku magazynowego. Prywatny punkt końcowy używa usługi Azure Private Link do przypisywania statycznego adresu IP do konta magazynowego w ramach prywatnej przestrzeni adresowej sieci wirtualnej. Prywatny punkt końcowy pomaga zapobiec przerwom w łączności przed zmianami dynamicznych adresów IP. Więcej informacji na temat zabezpieczeń udziałów NFS znajdziesz w Udziałach plików NFS — Zabezpieczenia i sieć.

Odporność na błędy strefy dostępności

Strefy dostępności są fizycznie oddzielnymi grupami centrów danych w regionie świadczenia usługi Azure. Gdy jedna strefa ulegnie awarii, usługi mogą przejść w tryb failover do jednej z pozostałych stref.

Azure Files zapewnia silne wsparcie dla stref dostępności poprzez konfiguracje ZRS, automatycznie rozprowadzające dane po wielu strefach dostępności w regionie. W przeciwieństwie do LRS, ZRS gwarantuje, że Azure synchronicznie replikuje dane w wielu strefach dostępności. Magazyn ZRS zapewnia dostępność danych nawet wtedy, gdy jedna strefa wystąpi awaria.

Diagram przedstawiający sposób replikacji danych w regionie podstawowym z magazynem strefowo nadmiarowym (ZRS).

Requirements

ZRS jest obsługiwany w:

Koszt

Po włączeniu magazynu strefowo nadmiarowego (ZRS) opłaty są naliczane z innej stawki niż magazyn lokalnie nadmiarowy (LRS) ze względu na dodatkową replikację i obciążenie magazynu.

Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik usługi Azure Files.

Konfiguruj obsługę stref dostępności

  • Utwórz udostępnianie plików z redundancją strefową. Aby utworzyć nowy udział plików z ZRS, zobacz Tworzenie udziału plików platformy Azure i wybierz ZRS lub GZRS jako opcję nadmiarowości podczas tworzenia konta.

  • Zmień typ replikacji. Aby przekonwertować istniejące konto magazynowe na ZRS i dowiedzieć się więcej o opcjach migracji i wymaganiach, więcej informacji znajdziesz w Zmienianie konfiguracji nadmiarowości dla usługi Azure Files.

  • Wyłącz strefową nadmiarowość. Przekonwertuj konta ZRS z powrotem na konfigurację niezonową, taką jak LRS, w tym samym procesie zmiany konfiguracji nadmiarowości.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy konto magazynu plików jest skonfigurowane z nadmiarowością strefową, a wszystkie strefy dostępności są operacyjne.

  • Routing ruchu między strefami: Usługa Azure Storage z magazynem strefowo nadmiarowym (ZRS) automatycznie dystrybuuje żądania między klastrami magazynu w wielu strefach dostępności. Dystrybucja ruchu jest niewidoczna dla aplikacji i nie wymaga konfiguracji po stronie klienta.

  • Replikacja danych między strefami: Wszystkie operacje zapisu w magazynach ZRS są replikowane synchronicznie we wszystkich strefach dostępności w regionie. Podczas przekazywania lub modyfikowania danych operacja nie jest uznawana za ukończoną, dopóki dane nie zostaną pomyślnie zreplikowane we wszystkich strefach dostępności. Ta synchroniczna replikacja zapewnia silną spójność i zero utraty danych podczas awarii strefy.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy konto magazynu plików jest skonfigurowane pod kątem nadmiarowości strefowej i dochodzi do awarii strefy dostępności.

  • Wykrywanie i reagowanie: Firma Microsoft automatycznie wykrywa błędy strefy i inicjuje procesy odzyskiwania. Dla kont magazynu strefowo nadmiarowego (ZRS) nie jest wymagana żadna akcja klienta.

    Jeśli strefa stanie się niedostępna, platforma Azure podejmuje aktualizacje sieci, takie jak przekierowanie w systemie nazw domen (DNS).

  • Aktywne żądania: Żądania w locie mogą zostać porzucone podczas procesu odzyskiwania i należy je ponowić. Aplikacje powinny implementować logikę ponawiania prób w celu obsługi tych tymczasowych przerw.

  • Oczekiwana utrata danych: Brak utraty danych podczas awarii strefy, ponieważ dane są synchronicznie replikowane w wielu strefach przed zakończeniem operacji zapisu.

  • Oczekiwany przestój: Niewielka ilość przestojów, zazwyczaj kilka sekund, może wystąpić podczas automatycznego odzyskiwania, ponieważ ruch jest przekierowywany do stref w dobrej kondycji. Podczas projektowania aplikacji dla magazynu ZRS postępuj zgodnie z rozwiązaniami dotyczącymi obsługi błędów przejściowych, w tym implementowania zasad ponawiania z wycofywaniem wykładniczym.

  • Przekierowywanie ruchu: Platforma Azure automatycznie przekierowuje ruch do pozostałych stref dostępności w dobrej kondycji. Usługa utrzymuje pełną funkcjonalność przy użyciu stref ocalałych bez konieczności interwencji klienta. Nie jest wymagane ponowne instalowanie udziałów plików platformy Azure z połączonych klientów.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie przywrócona, usługa Azure Storage automatycznie przywraca normalne operacje we wszystkich strefach dostępności. Usługa automatycznie zapewnia spójność danych, synchronizując wszystkie operacje, które wystąpiły w okresie awarii.

Testowanie pod kątem niepowodzeń strefy

W przypadku korzystania z magazynu strefowo nadmiarowego (ZRS) usługa Azure Storage automatycznie zarządza replikacją, routingiem ruchu i odpowiedziami strefowymi. Ponieważ ta funkcja jest w pełni zarządzana, nie trzeba inicjować ani weryfikować procesów awarii strefy dostępności.

Odporność na awarie całego regionu

Usługa Azure Storage, w tym Azure Blob Storage, Azure Files, Azure Table Storage i Azure Queue Storage, udostępnia szereg funkcji nadmiarowości geograficznej i trybu failover, które spełniają różne wymagania.

Ważne

Magazyn geograficznie nadmiarowy (GRS) działa tylko w sparowanych regionach platformy Azure. Jeśli region konta magazynu nie jest sparowany, rozważ użycie niestandardowych rozwiązań z wieloma regionami w celu zapewnienia odporności.

Przechowywanie geo-nadmiarowe dla sparowanych regionów

Usługa Azure Storage udostępnia kilka typów grs w sparowanych regionach. Niezależnie od używanego typu magazynu GRS dane w regionie pomocniczym są zawsze replikowane przy użyciu magazynu lokalnie nadmiarowego (LRS). Takie podejście zapewnia ochronę przed awariami sprzętu w regionie pomocniczym.

Ważne

Usługa Azure Files obsługuje tylko nadmiarowość geograficzną (GRS lub GZRS) dla standardowych udziałów plików na dyskach twardych (HDD).

Usługa Azure Files nie obsługuje geograficznie redundantnego magazynu z dostępem tylko do odczytu (RA-GRS) ani geograficznie redundantnego magazynu strefowego z dostępem tylko do odczytu (RA-GZRS). Jeśli konto magazynu jest skonfigurowane do używania RA-GRS lub RA-GZRS, standardowe udziały plików (HDD) są konfigurowane i rozliczane jako GRS lub GZRS.

Typy przełączania awaryjnego

Usługa Azure Storage obsługuje trzy typy trybu failover w różnych scenariuszach.

  • Nieplanowana praca w trybie failover zarządzana przez klienta: Odpowiadasz za inicjowanie odzyskiwania, jeśli w regionie podstawowym wystąpi awaria magazynu w całym regionie.

  • Planowane przełączenie w trybie failover zarządzane przez klienta: Użytkownik jest odpowiedzialny za inicjowanie odzyskiwania, jeśli inna część Twojego rozwiązania ma awarię w regionie podstawowym, a całe rozwiązanie musi zostać przełączone do regionu pomocniczego. Użyj planowanego failoveru, gdy zasób pozostaje operacyjny w regionie głównym, ale musisz przełączyć całe rozwiązanie do regionu zapasowego, na przykład w przypadku ćwiczeń z odzyskiwania po awarii, mających na celu zapewnienie zgodności i wymagań audytu.

  • Tryb failover zarządzany przez firmę Microsoft: W wyjątkowych okolicznościach firma Microsoft może zainicjować tryb failover dla wszystkich kont magazynu geograficznie nadmiarowego (GRS) w regionie. Jednak tryb failover zarządzany przez firmę Microsoft jest ostatecznością i powinien być wykonywany tylko po dłuższym okresie awarii. Nie należy polegać na zarządzanym przez Microsoft mechanizmie awaryjnego przełączania.

Konta GRS mogą używać dowolnego z tych typów trybu failover. Nie musisz wstępnie konfigurować konta magazynowego, aby z wyprzedzeniem korzystać z dowolnego typu przełączania awaryjnego.

Requirements

  • Tylko standardowe udziały plików: Azure Files obsługuje georedundancję (GRS lub GZRS) wyłącznie dla standardowych udziałów plików (HDD). Udziały plików w warstwie Premium (SSD) muszą używać magazynu LRS lub ZRS. Jeśli masz udziały plików w warstwie Premium i chcesz replikować dane między regionami w celu uzyskania większej odporności, zobacz Niestandardowe rozwiązania obejmujące wiele regionów, aby uzyskać odporność.

  • Tylko magazyn GRS i GZRS: Usługa Azure Files nie obsługuje magazynu geograficznie nadmiarowego z dostępem do odczytu (RA-GRS) ani magazynu geograficznie strefowo-nadmiarowego z dostępem do odczytu (RA-GZRS). Jeśli konto magazynu jest skonfigurowane do używania RA-GRS lub RA-GZRS, standardowe udziały plików (HDD) są konfigurowane i rozliczane jako GRS lub GZRS.

Rozważania

Podczas implementowania usługi Azure Files w wielu regionach należy wziąć pod uwagę następujące ważne czynniki:

  • Opóźnienie replikacji asynchronicznej: Replikacja danych do regionu pomocniczego jest asynchroniczna, co oznacza, że występuje opóźnienie między tym, kiedy dane są zapisywane w regionie podstawowym i gdy staną się dostępne w regionie pomocniczym. To opóźnienie może spowodować potencjalną utratę danych, jeśli wystąpi awaria regionu podstawowego przed zreplikowanie ostatnich danych. Utrata danych jest mierzona przez cel punktu odzyskiwania (RPO). Opóźnienie replikacji może być mniejsze niż 15 minut, ale tym razem jest szacowane i nie jest gwarantowane.

    Możesz sprawdzić właściwość Czas ostatniej synchronizacji , aby dowiedzieć się, ile danych może zostać utraconych, jeśli konto magazynu ma nieplanowany tryb failover.

  • Czas ostatniej synchronizacji: W przypadku usługi Azure Files czas ostatniej synchronizacji jest oparty na najnowszą migawkę systemu w regionie pomocniczym.

    Obliczenie Ostatniego czasu synchronizacji może zakończyć się z przekroczeniem limitu czasu, jeśli na koncie pamięci masowej istnieje więcej niż 100 udziałów plików. Zalecamy wdrożenie 100 lub mniej udziałów plików dla każdego konta magazynu, aby uniknąć przekroczenia limitu czasu.

  • Dostęp do regionu pomocniczego: Region pomocniczy nie jest dostępny dla operacji odczytu do czasu przejścia w tryb failover.

  • Ograniczenia funkcji: Niektóre funkcje usługi Azure Files nie są obsługiwane lub mogą mieć ograniczenia przy korzystaniu z GRS lub trybu failover zarządzanego przez klienta. Ograniczenia te obejmują określone typy udziałów plików, warstwy dostępu oraz narzędzia i operacje zarządzania. Przed wdrożeniem redundancji geograficznej zapoznaj się z dokumentacją zgodności funkcji.

Koszt

Konfiguracje konta usługi Azure Storage w wielu regionach generują dodatkowe koszty replikacji między regionami i magazynu w regionie pomocniczym. Opłaty za transfer danych między regionami platformy Azure są naliczane na podstawie standardowych stawek przepustowości między regionami.

Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik usługi Azure Files.

Konfigurowanie obsługi wielu regionów

  • Utwórz nowe konto magazynu geograficznie nadmiarowego (GRS). Aby utworzyć konto GRS, zobacz Tworzenie konta magazynu i wybieranie magazynu GRS, magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GRS), magazyn geograficznie nadmiarowy strefowo nadmiarowy (GZRS) lub magazyn geograficznie nadmiarowy dostępny do odczytu (RA-GZRS) podczas tworzenia konta.

  • Włącz redundancję geograficzną na istniejącym koncie magazynowania plików. Aby przekonwertować istniejące konto magazynu plików na GRS, więcej informacji znajdziesz w Zmienianie Konfiguracji Nadmiarowości dla usługi Azure Files.

    Ostrzeżenie

    Po ponownym skonfigurowaniu konta na potrzeby nadmiarowości geograficznej może upłynąć dużo czasu, zanim istniejące dane w nowym regionie podstawowym będą w pełni kopiowane do nowego regionu pomocniczego.

    Aby uniknąć poważnej utraty danych, sprawdź wartość właściwości Czas ostatniej synchronizacji przed zainicjowaniem nieplanowanego trybu failover. Aby ocenić potencjalną utratę danych, porównaj czas ostatniej synchronizacji z ostatnim momentem, w którym dane zostały zapisane w nowym regionie podstawowym.

  • Wyłącz nadmiarowość geograficzną. Przekonwertuj konta GRS na konfiguracje jednoregionowe (LRS lub ZRS) za pomocą tego samego procesu zmiany konfiguracji nadmiarowej.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy konto magazynu jest skonfigurowane na potrzeby nadmiarowości geograficznej, a wszystkie regiony działają.

  • Routing ruchu między regionami: Usługa Azure Files używa podejścia aktywnego pasywnego, w którym wszystkie operacje odczytu i zapisu są kierowane do regionu podstawowego.

  • Replikacja danych między regionami: Operacje zapisu są najpierw zastosowane w regionie podstawowym przy użyciu skonfigurowanego typu nadmiarowości (LRS w kontekście GRS lub ZRS w kontekście GZRS). Po pomyślnym zakończeniu w regionie głównym dane są asynchronicznie replikowane do regionu pomocniczego, gdzie są przechowywane przy użyciu LRS.

    Asynchroniczny charakter replikacji między regionami oznacza, że zazwyczaj występuje opóźnienie między czasem zapisywania danych w regionie podstawowym a dostępnością w regionie pomocniczym. Czas replikacji można monitorować przy użyciu właściwości Czas ostatniej synchronizacji.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego oczekiwać po skonfigurowaniu konta magazynowego dla nadmiarowości geograficznej w przypadku awarii w regionie podstawowym.

  • Tryb failover zarządzany przez klienta (nieplanowany): Użyj nieplanowanego trybu failover, gdy magazyn w regionie podstawowym jest niedostępny.

    • Wykrywanie i reagowanie: W mało prawdopodobnym przypadku niedostępności konta magazynu w regionie podstawowym można rozważyć zainicjowanie nieplanowanego trybu failover zarządzanego przez klienta. Aby podjąć tę decyzję, należy wziąć pod uwagę następujące czynniki:

      • Czy usługa Azure Resource Health pokazuje problemy z uzyskiwaniem dostępu do konta magazynu w regionie podstawowym

      • Czy firma Microsoft zaleca przeprowadzenie przejścia w tryb failover do innego regionu

      Ostrzeżenie

      Nieplanowane przejście w tryb failover może spowodować utratę danych. Przed zainicjowaniem trybu failover zarządzanego przez klienta zdecyduj, czy przywrócenie usługi uzasadnia ryzyko utraty danych.

    • Aktywne żądania: Podczas procesu failover punkty końcowe konta przechowywania podstawowego i pomocniczego stają się tymczasowo niedostępne dla operacji zarówno odczytu, jak i zapisu. Wszystkie aktywne żądania mogą zostać porzucone, a aplikacje klienckie muszą ponowić próbę po zakończeniu pracy w trybie failover.

    • Oczekiwana utrata danych: Utrata danych jest powszechna podczas nieplanowanego trybu failover z powodu opóźnienia replikacji asynchronicznej, co oznacza, że ostatnie zapisy mogą nie być replikowane. Możesz sprawdzić właściwość Czas ostatniej synchronizacji , aby dowiedzieć się, ile danych może zostać utraconych podczas nieplanowanego przejścia w tryb failover. Oczekiwana utrata danych jest często określana jako cel punktu odzyskiwania (RPO). Zazwyczaj można oczekiwać, że RPO będzie poniżej 15 minut, ale ten czas nie jest gwarantowany.

    • Oczekiwany przestój: Oczekiwany przestój jest często określany jako cel czasu odzyskiwania (RTO). Proces failover zarządzany przez klienta zazwyczaj kończy się w ciągu 60 minut, w zależności od wielkości konta i stopnia złożoności.

    • Przekierowywanie ruchu: Po zakończeniu pracy w trybie failover platforma Azure automatycznie aktualizuje punkty końcowe konta magazynu, aby aplikacje nie musiały być ponownie skonfigurowane. Jeśli aplikacja przechowuje buforowane wpisy systemu nazw domen (DNS), może być konieczne wyczyszczenie pamięci podręcznej w celu zapewnienia, że aplikacja wysyła ruch do nowego regionu podstawowego.

    • Konfiguracja po przejściu w tryb failover: Po zakończeniu nieplanowanego przejścia w tryb failover konto magazynu w regionie docelowym używa warstwy magazynu lokalnie nadmiarowego (LRS). Jeśli musisz ponownie replikować geograficznie, musisz ponownie włączyć magazyn geograficznie nadmiarowy (GRS) i poczekać, aż dane zostaną zreplikowane do nowego regionu pomocniczego.

    Aby uzyskać więcej informacji na temat inicjowania trybu failover zarządzanego przez klienta, zobacz Jak działa tryb failover zarządzany przez klienta (nieplanowany) i Inicjowanie trybu failover konta magazynu.

  • Tryb failover zarządzany przez klienta (planowany): Użyj planowanego trybu failover, gdy magazyn pozostaje operacyjny w regionie podstawowym, ale z innego powodu musisz przejąć całe rozwiązanie w tryb failover w regionie pomocniczym. Na przykład inna usługa platformy Azure może mieć problem i musisz przełączyć się na korzystanie z regionu pomocniczego dla całego rozwiązania. Możesz też użyć planowanego przejścia w tryb failover do przeprowadzenia próbnego odzyskiwania po awarii na potrzeby zgodności i inspekcji.

    • Wykrywanie i reagowanie: Odpowiadasz za podjęcie decyzji o przejściu w tryb failover. Zazwyczaj podejmujesz tę decyzję, jeśli konieczne jest przełączenie w tryb failover między regionami, nawet jeśli konto magazynu jest w dobrej kondycji. Na przykład możesz wyzwolić przełączenie awaryjne, gdy wystąpi poważna awaria innego składnika aplikacji, której nie można naprawić w regionie podstawowym.

    • Aktywne żądania: Podczas procesu failover punkty końcowe konta przechowywania podstawowego i pomocniczego stają się tymczasowo niedostępne dla operacji zarówno odczytu, jak i zapisu. Wszystkie aktywne żądania mogą zostać porzucone, a aplikacje klienckie muszą ponowić próbę po zakończeniu pracy w trybie failover.

    • Oczekiwana utrata danych: Utraty danych nie należy się spodziewać, ponieważ proces failover kończy się dopiero po zsynchronizowaniu wszystkich danych, co daje wskaźnik RPO równy zero.

    • Oczekiwany przestój: Proces failover zwykle trwa do 60 minut, co oznacza, że oczekiwany czas odzyskiwania również wynosi 60 minut, w zależności od rozmiaru konta i złożoności. Podczas procesu trybu failover punkty końcowe konta magazynu podstawowego i pomocniczego stają się tymczasowo niedostępne zarówno dla operacji odczytu, jak i zapisu.

    • Przekierowywanie ruchu: Po zakończeniu pracy w trybie failover platforma Azure automatycznie aktualizuje punkty końcowe konta magazynu, aby aplikacje nie musiały być ponownie skonfigurowane. Jeśli aplikacja przechowuje wpisy DNS w pamięci podręcznej, może być konieczne wyczyszczenie pamięci podręcznej w celu zapewnienia, że aplikacja wysyła ruch do nowego regionu podstawowego.

    • Konfiguracja po przejściu w tryb failover: Po zakończeniu planowanego przejścia w tryb failover konto magazynu w regionie docelowym będzie nadal replikowane geograficznie i pozostaje w warstwie GRS.

    Aby uzyskać więcej informacji na temat inicjowania trybu failover zarządzanego przez klienta, zobacz Jak działa tryb failover zarządzany przez klienta (planowany) i Inicjowanie trybu failover konta magazynu.

  • Tryb failover zarządzany przez firmę Microsoft: W rzadkim przypadku poważnej awarii, w której firma Microsoft ustali, że region podstawowy jest trwale nieodwracalny, może zostać zainicjowane automatyczne przejście w tryb failover do regionu pomocniczego. Firma Microsoft obsługuje cały proces i nie jest wymagana żadna akcja klienta. Czas, który upłynął przed przejściem w tryb failover, zależy od ważności awarii i czasu wymaganego do oceny sytuacji.

    Ważne

    Użyj opcji failover zarządzanej 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 prawdopodobnie jest inicjowany dla całego regionu. Nie można go zainicjować dla poszczególnych kont przechowywania, subskrypcji ani klientów. Przełączenie awaryjne może wystąpić w różnym czasie dla różnych usług Azure. Zalecamy korzystanie z trybu failover zarządzanego przez klienta.

Odzyskiwanie regionów

Proces powrotu po awarii różni się znacznie między scenariuszami trybu failover zarządzanymi przez firmę Microsoft i zarządzanymi przez klienta.

  • Tryb failover zarządzany przez klienta (nieplanowany): Po nieplanowanym przejściu w tryb failover konto magazynu jest skonfigurowane z magazynem lokalnie nadmiarowym (LRS). Aby powrócić po awarii, należy ponownie ustanowić relację magazynu geograficznie nadmiarowego (GRS) i poczekać na replikowanie danych.

  • Tryb failover zarządzany przez klienta (planowany): Po zaplanowanym przejściu w tryb failover konto magazynu pozostaje replikowane geograficznie. Możesz zainicjować inny tryb failover zarządzany przez klienta, aby powrócić po awarii do oryginalnego regionu podstawowego. Mają zastosowanie te same zagadnienia dotyczące trybu failover.

  • Tryb failover zarządzany przez firmę Microsoft: Jeśli firma Microsoft inicjuje tryb failover, prawdopodobnie wystąpi znaczna awaria w regionie podstawowym, a region podstawowy może nie być możliwy do odzyskania. Wszelkie harmonogramy lub plany odzyskiwania zależą od zakresu regionalnych działań związanych z awarią i odzyskiwaniem. Aby uzyskać szczegółowe informacje, należy monitorować komunikację usługi Azure Service Health.

Testowanie pod kątem błędów regionów

W przypadku kont GRS można wykonać zaplanowane operacje przełączania awaryjnego podczas okien konserwacji, aby przetestować pełny proces przełączania awaryjnego i przywracania. Planowana praca w trybie failover nie wymaga utraty danych, ale wymaga przestoju zarówno podczas przechodzenia w tryb failover, jak i powrotu po awarii.

Niestandardowe rozwiązania obejmujące wiele regionów w celu zapewnienia odporności

Możliwości trybu failover między regionami usługi Azure Storage mogą być nieodpowiednie z następujących powodów:

  • Twoje konto magazynu znajduje się w regionie niepowiązanym.

  • Cele czasu pracy firmy nie są spełnione przez czas odzyskiwania lub utratę danych, które zapewniają wbudowane opcje trybu failover.

  • Musisz przejść w tryb failover do regionu, który nie jest parą regionu podstawowego.

  • Potrzebna jest aktywna/aktywna konfiguracja w różnych regionach.

  • Używasz typów udziałów plików, które nie obsługują nadmiarowości geograficznej.

Ta sekcja zawiera ogólne omówienie niektórych podejść do rozważenia. Kompleksowy przegląd topologii wdrażania w wielu regionach dla usługi Azure Storage wykracza poza zakres tego artykułu.

Rozważ następujące typowe podejścia wysokiego poziomu:

  • Wiele kont magazynowych: Usługę Azure Files można wdrożyć w wielu regionach, używając oddzielnych kont magazynowych w każdym regionie. Takie podejście zapewnia elastyczność wyboru regionów, możliwość korzystania z niepairowanych regionów i bardziej szczegółową kontrolę nad czasem replikacji i spójnością danych. Podczas implementowania wielu kont magazynu w różnych regionach należy skonfigurować replikację danych między regionami, zaimplementować zasady równoważenia obciążenia i trybu failover oraz zapewnić spójność danych w różnych regionach.

  • Replikacja na poziomie aplikacji: Zaimplementuj logikę replikacji niestandardowej przy użyciu usługi Azure Data Factory lub narzędzia AzCopy , aby synchronizować dane między udziałami plików w różnych regionach. Takie podejście wymaga niestandardowych mechanizmów tworzenia i rozwiązywania konfliktów.

  • Użyj usługi Azure File Sync, aby replikować pliki do udziału dyskowego w innym regionie świadczenia usługi Azure. Azure File Sync pozwala na synchronizację między udziałem plików platformy Azure SMB (punktem końcowym w chmurze), lokalnym serwerem plików systemu Windows i zamontowanym udziałem plików działającym na maszynie wirtualnej w innym regionie platformy Azure (punkt końcowy serwera DR).

    Takie podejście wymaga wdrożenia wielu udziałów plików i maszyny wirtualnej w celu koordynowania procesu synchronizacji.

    Jeśli używasz tego podejścia do replikacji plików w wielu regionach:

    • Wyłącz warstwowanie w chmurze, aby upewnić się, że wszystkie dane są dostępne lokalnie na serwerze plików.

    • Aprowizuj wystarczającą ilość miejsca do magazynowania na maszynie wirtualnej platformy Azure, aby przechowywać cały zestaw danych.

    • Uzyskiwanie dostępu do plików i modyfikowanie ich w punkcie końcowym serwera, a nie na platformie Azure, w celu zapewnienia szybkiego replikacji zmian do regionu pomocniczego.

Tworzenie kopii zapasowej i przywracanie

Kopia zapasowa usługi Azure Files to natywna integracja między usługami Azure Files i Azure Backup, która została zaprojektowana w celu ochrony danych przed przypadkowym usunięciem, uszkodzeniem i atakami wymuszającym okup.

Kopia zapasowa usługi Azure Files tworzy migawki na poziomie udziału przechowywane na tym samym koncie magazynu. Ta funkcja umożliwia szybkie odzyskiwanie zarówno pojedynczych plików, jak i całych udziałów plików. Można również użyć zasad tworzenia kopii zapasowych , aby zapewnić długie okresy przechowywania z dostosowywalną częstotliwością tworzenia kopii zapasowych.

Możesz tworzyć migawki i przechowywać je na dwa różne sposoby:

  • Przechowywanie na poziomie udziału: W przypadku scenariuszy odzyskiwania operacyjnego i krótkoterminowego można tworzyć migawki na poziomie udziału i przechowywać je na tym samym koncie magazynowym. Migawki na poziomie udziału umożliwiają szybkie odzyskiwanie pojedynczych plików lub całych udziałów plikowych do oryginalnej lub alternatywnej lokalizacji.

  • Magazyn kopii zapasowych w skarbcu: Korzystając z kopii zapasowej w skarbcu, możesz skopiować codzienne migawki do skarbca usług Azure Recovery Services. Aby zwiększyć bezpieczeństwo, ta skrytka jest odizolowana od głównego konta przechowywania.

    Jeśli używasz sparowanego regionu platformy Azure i skonfigurujesz magazyn do używania magazynu GRS, magazyn replikuje dane do sparowanego regionu. Ta replikacja obsługuje przepływy pracy odzyskiwania między regionami i odzyskiwania po awarii.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usługi Azure Storage opisuje oczekiwaną dostępność usługi oraz warunki, które muszą zostać spełnione, aby osiągnąć te oczekiwania dotyczące dostępności. Umowa SLA dotycząca dostępności, dla której kwalifikujesz się, zależy od warstwy magazynowania i używanego typu replikacji. Aby uzyskać więcej informacji, zobacz Umowy SLA dla usług online.

Treści powiązane

  • Last updated on