Udostępnij przez

Niezawodność w usłudze Azure Queue Storage

Azure Queue Storage to usługa do przechowywania i dystrybucji dużej liczby komunikatów. Usługa Queue Storage jest często używana do tworzenia listy prac w celu asynchronicznego przetwarzania. Zapewnia niezawodne dostarczanie komunikatów dla luźno powiązanych architektur aplikacji. Komunikat w kolejce może mieć rozmiar do 64 KB, a kolejka może zawierać miliony komunikatów do całkowitego limitu pojemności konta magazynu.

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, jak te możliwości działają w ramach wszystkich używanych usług oraz za wybór tych, które są potrzebne do osiągnięcia Twoich celów biznesowych i celów dotyczących niezawodności.

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

Note

Usługa Queue Storage jest częścią platformy Azure Storage. Niektóre możliwości usługi Queue Storage są wspólne dla wielu usług Azure Storage.

Zalecenia dotyczące wdrażania produkcyjnego pod kątem niezawodności

W środowiskach produkcyjnych:

  • Włącz magazyn strefowo nadmiarowy (ZRS) dla kont magazynu, które zawierają zasoby usługi Queue Storage. Magazyn ZRS zapewnia wyższą dostępność, replikując dane synchronicznie w wielu strefach dostępności w regionie podstawowym. Wyższa dostępność pomaga chronić konta magazynu przed awariami strefy dostępności.

  • Jeśli potrzebujesz odporności na awarie regionów, a region podstawowy konta magazynu jest sparowany, rozważ włączenie magazynu geograficznie nadmiarowego (GRS). Magazyn GRS replikuje dane asynchronicznie do sparowanego regionu. W obsługiwanych regionach można połączyć nadmiarowość geograficzną z nadmiarowością strefy przy użyciu magazynu geograficznie nadmiarowego strefowo nadmiarowego (GZRS).

Aby uzyskać zaawansowane wymagania dotyczące obsługi komunikatów, rozważ użycie usługi Azure Service Bus. Aby dowiedzieć się więcej o różnicach między usługą Queue Storage i usługą Service Bus, zobacz Porównanie kolejek usługi Azure Storage i kolejek usługi Service Bus.

Omówienie architektury niezawodności

Usługa Queue Storage działa jako rozproszona usługa obsługi komunikatów w infrastrukturze platformy Azure Storage. Usługa zapewnia nadmiarowość za pośrednictwem wielu kopii kolejki i danych komunikatów. Określony model nadmiarowości zależy od konfiguracji konta magazynu.

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.

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.

Usługa Queue Storage jest często używana w aplikacjach, aby ułatwić im obsługę błędów przejściowych w innych składnikach. Dzięki asynchronicznej obsłudze komunikatów z usługą, takiej jak Queue Storage, aplikacje mogą odzyskiwać dane po przejściowych błędach przez ponowne przetwarzanie komunikatów w późniejszym czasie. Aby dowiedzieć się więcej, zobacz Asynchroniczne podstawy obsługi komunikatów.

W ramach samej usługi usługa Queue Storage automatycznie obsługuje błędy przejściowe przy użyciu kilku mechanizmów zapewnianych przez platformę Azure Storage i biblioteki klienckie. Usługa została zaprojektowana w celu zapewnienia odpornych możliwości kolejkowania komunikatów nawet podczas tymczasowych problemów z infrastrukturą.

Biblioteki klienta usługi Queue Storage obejmują wbudowane zasady ponawiania, które automatycznie obsługują typowe błędy przejściowe, takie jak przekroczenia limitu czasu sieci, tymczasowa niedostępność usługi (HTTP 503) i odpowiedzi ograniczania przepustowości (HTTP 429). Gdy aplikacja napotka te przejściowe warunki, biblioteki klienckie automatycznie ponawiają próby operacji przy użyciu strategii wycofywania wykładniczego.

Aby efektywnie zarządzać błędami przejściowymi przy użyciu usługi Queue Storage, możesz wykonać następujące czynności:

  • Skonfiguruj odpowiednie limity czasu w kliencie usługi Queue Storage, aby zrównoważyć czas reakcji z odpornością na tymczasowe spowolnienie. Domyślne limity czasu w bibliotekach klienckich usługi Azure Storage są zazwyczaj odpowiednie dla większości scenariuszy.

  • Zaimplementuj wzorce wyłącznika w aplikacji, gdy przetwarza komunikaty z kolejek. Wzorce wyłącznika uniemożliwiają awarie kaskadowe, gdy usługi podrzędne napotkają problemy.

  • Odpowiednio używaj limitów czasu widoczności , gdy aplikacja odbiera komunikaty. Limity czasu widoczności zapewniają dostępność komunikatów na potrzeby ponawiania próby, jeśli aplikacja napotka błędy podczas przetwarzania.

Aby dowiedzieć się więcej na temat architektury usługi Azure Table Storage i sposobu projektowania odpornych i wysokoskalowych aplikacji, zobacz Lista kontrolna wydajności i skalowalności usługi Queue Storage.

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.

Usługa Azure Queue Storage jest strefowo nadmiarowa podczas wdrażania z konfiguracją magazynu ZRS. W przeciwieństwie do magazynu LRS magazyn ZRS gwarantuje, że platforma Azure synchronicznie replikuje dane kolejki w wielu strefach dostępności. Magazyn ZRS zapewnia dostępność danych nawet wtedy, gdy jedna strefa wystąpi awaria. Magazyn ZRS zapewnia, że kolejki pozostaną dostępne, nawet jeśli cała strefa dostępności stanie się niedostępna. Wszystkie operacje zapisu muszą być potwierdzane w wielu strefach przed ich ukończeniem, co zapewnia silne gwarancje spójności.

Nadmiarowość strefowa jest włączona na poziomie konta magazynowania i ma zastosowanie do wszystkich zasobów usługi Queue Storage w ramach tego konta. Nie można skonfigurować poszczególnych kolejek dla różnych poziomów nadmiarowości. Ustawienie dotyczy całego konta magazynu. Gdy strefa dostępności powoduje awarię, usługa Azure Storage automatycznie kieruje żądania do stref w dobrej kondycji bez konieczności interwencji aplikacji.

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

Requirements

  • Typy kont magazynu: Aby włączyć magazyn ZRS dla usługi Queue Storage, należy użyć konta magazynu ogólnego przeznaczenia w warstwie Standardowa w wersji 2. Konta usługi Premium Storage nie obsługują usługi Queue Storage.

Cost

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 Queue Storage.

Konfiguruj obsługę stref dostępności

  • Utwórz konto magazynu strefowo nadmiarowego i kolejkę, wykonując następujące kroki.

    1. Utwórz konto magazynu i wybierz ZRS, GZRS lub magazyn geograficznie nadmiarowy z dostępem do odczytu (RA-GZRS) jako opcję nadmiarowości podczas tworzenia konta.

    2. Utwórz kolejkę.

  • Zmień typ replikacji. Aby dowiedzieć się, jak zmienić istniejące konto magazynu na magazyn strefowo nadmiarowy (ZRS) oraz o opcjach konfiguracji i wymaganiach, zobacz Zmienianie sposobu replikacji konta magazynu.

  • Wyłącz strefową nadmiarowość. Przekonwertuj konta magazynu ZRS z powrotem na konfigurację niezonową, taką jak magazyn lokalnie nadmiarowy (LRS), przy użyciu tego samego procesu zmiany konfiguracji nadmiarowości.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy konto magazynu kolejek jest skonfigurowane pod kątem nadmiarowości strefowej, 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

Gdy strefa dostępności stanie się niedostępna, usługa Queue Storage automatycznie obsługuje proces pracy w trybie failover, wykonując następujące akcje.

  • 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. Jeśli strefa stanie się niedostępna, platforma Azure podejmuje aktualizacje sieci, takie jak ponowne określanie punktu nazw domen (DNS), dzięki czemu żądania są kierowane 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.

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.

Important

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.

Magazyn z georedundancją w regionach sparowanych.

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.

Przechowywanie z geograficzną redundancją

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 awaryjne zarządzane przez klienta: Jesteś odpowiedzialny za inicjowanie procesu odzyskiwania, jeśli inna część twojego rozwiązania ulegnie awarii w regionie podstawowym. Musisz wtedy przełączyć całe rozwiązanie do regionu pomocniczego. Użyj planowanego przełączenia awaryjnego, gdy magazyn pozostaje operacyjny w regionie podstawowym, ale musisz przełączyć całe rozwiązanie na region pomocniczy, na przykład podczas ćwiczeń z odzyskiwania po awarii, które mają na celu spełnienie wymagań zgodności i audytów.

  • 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

  • Typy kont magazynu: Geograficznie nadmiarowa pamięć masowa (GRS) i inicjowane przez klienta przełączenie awaryjne oraz powrót po awarii są dostępne we wszystkich sparowanych regionach platformy Azure, które obsługują konta typu Azure Storage ogólnego przeznaczenia w wersji 2.

Considerations

Podczas implementowania usługi Queue Storage 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.

  • Dostęp do regionu pomocniczego: W przypadku konfiguracji magazynu geograficznie nadmiarowego (GRS) i magazynu geograficznie nadmiarowego (GZRS) region pomocniczy nie jest dostępny do odczytu do czasu przejścia w tryb failover.

    Konfiguracje magazynu geograficznie nadmiarowego z dostępem do odczytu (RA-GRS) i magazynu geograficznie nadmiarowego z dostępem do odczytu (RA-GZRS) zapewniają dostęp do odczytu do regionu pomocniczego podczas normalnych operacji, ale ze względu na opóźnienie replikacji asynchronicznej mogą zwracać nieco nieaktualne dane.

  • Ograniczenia funkcji: Niektóre funkcje usługi Azure Storage nie są obsługiwane lub mają ograniczenia dotyczące korzystania z magazynu geograficznie nadmiarowego (GRS) ani trybu failover zarządzanego przez klienta. Przed wdrożeniem nadmiarowości geograficznej przejrzyj zgodność funkcji .

Cost

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 Queue Storage.

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 nadmiarowość geograficzną na istniejącym koncie magazynu. Aby przekonwertować istniejące konto magazynu na magazyn geograficznie nadmiarowy (GRS), zobacz Zmienianie sposobu replikacji konta magazynu.

    Warning

    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 zapisem danych w nowym regionie podstawowym.

  • Wyłącz nadmiarowość geograficzną. Przekonwertuj konta GRS z powrotem na konfiguracje z jednym regionem, takie jak magazyn lokalnie nadmiarowy (LRS) lub magazyn strefowo nadmiarowy (ZRS), korzystając z tego samego procesu zmiany konfiguracji nadmiarowości.

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 Storage używa podejścia aktywnego pasywnego, w którym wszystkie operacje zapisu i większość operacji odczytu są kierowane do regionu podstawowego.

    W przypadku konfiguracji magazynu geograficznie nadmiarowego dostępnego do odczytu (RA-GRS) i magazynu geograficznie nadmiarowego z dostępem do odczytu (RA-GZRS) aplikacje mogą opcjonalnie odczytywać z regionu pomocniczego, korzystając z pomocniczego punktu końcowego. Takie podejście wymaga jawnej konfiguracji aplikacji i nie jest automatyczne. Ponadto ze względu na opóźnienie replikacji asynchronicznej dane w regionie pomocniczym mogą być nieco nieaktualne.

  • Replikacja danych między regionami: Operacje zapisu są najpierw zatwierdzane w regionie podstawowym przy użyciu następujących skonfigurowanych typów nadmiarowości:

    • Magazyn lokalnie nadmiarowy (LRS) dla magazynu geograficznie nadmiarowego (GRS) i RA-GRS
    • Magazyn strefowo nadmiarowy (ZRS) dla magazynu geograficznie nadmiarowego (GZRS) i RA-GZRS

    Po pomyślnym zakończeniu w regionie podstawowym dane są asynchronicznie replikowane do regionu pomocniczego, w którym są przechowywane przy użyciu magazynu 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

      Warning

      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.

    Important

    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

Możesz symulować regionalne błędy w celu przetestowania procedur odzyskiwania po awarii.

  • Planowane testowanie trybu failover: W przypadku kont magazynu geograficznie nadmiarowego (GRS) można wykonać zaplanowane operacje pracy w trybie failover podczas okien konserwacji, aby przetestować kompletny proces pracy w trybie failover i powrotu po awarii. Planowane przejście w tryb failover nie wymaga utraty danych, ale wiąże się z przestojami podczas przechodzenia w tryb failover i powrotu po awarii.

  • Dodatkowe testowanie punktów końcowych: W przypadku konfiguracji magazynu geograficznie nadmiarowego dostępnego do odczytu (RA-GRS) i magazynu geograficznie nadmiarowego z dostępem do odczytu (RA-GZRS) regularnie testuje operacje odczytu względem pomocniczego punktu końcowego, aby upewnić się, że aplikacja może pomyślnie odczytywać dane z regionu pomocniczego.

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.

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.

Note

Aby uzyskać zaawansowane wymagania dotyczące wielu regionów, rozważ użycie usługi Service Bus, która obejmuje obsługę regionów niepaired.

Usługę Azure Storage można wdrożyć w wielu regionach przy użyciu oddzielnych kont magazynu 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.

Takie podejście wymaga zarządzania dystrybucją komunikatów, obsługi synchronizacji danych między kolejkami na różnych kontach magazynu i implementowania niestandardowej logiki mechanizmu przełączania awaryjnego.

Tworzenie kopii zapasowej i przywracanie

Usługa Queue Storage nie zapewnia tradycyjnych funkcji tworzenia kopii zapasowych, takich jak przywracanie do punktu w czasie (PITR). Dzieje się tak, ponieważ kolejki są przeznaczone do przejściowego przechowywania komunikatów zamiast długoterminowego trwałości danych. Komunikaty są zwykle przetwarzane i usuwane z kolejek podczas normalnych operacji aplikacji.

W przypadku scenariuszy wymagających trwałości komunikatów poza wbudowanymi opcjami nadmiarowości rozważ zaimplementowanie własnego rejestrowania komunikatów na poziomie aplikacji lub trwałości w trwałym magazynie danych, takim jak Blob Storage lub Azure SQL Database. Takie podejście umożliwia zachowanie historii komunikatów podczas korzystania z usługi Queue Storage w celu tymczasowego buforowania i koordynacji przetwarzania komunikatów.

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