Niezawodność w usłudze Azure Service Bus

Azure Service Bus to w pełni zarządzana usługa brokera komunikatów przedsiębiorstwa, która zapewnia niezawodne asynchroniczne możliwości obsługi komunikatów na potrzeby oddzielenia aplikacji i usług. Usługa Service Bus obsługuje kolejki dla komunikacji punkt-punkt oraz tematy z subskrypcjami dla wzorców komunikatów typu publish-subscribe. Usługa zapewnia wbudowane funkcje niezawodności, w tym trwałość komunikatów, gwarancje dostarczania co najmniej raz oraz kolejki utraconych komunikatów do obsługi przetwarzania komunikatów zakończonych niepowodzeniem.

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 zapewnić odporność usługi Service Bus na różne potencjalne awarie i problemy, w tym przejściowe błędy, awarie stref dostępności i awarie regionów. Wyróżniono również niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Service Bus.

Zalecenia dotyczące wdrażania produkcyjnego

Platforma Azure Well-Architected Framework udostępnia zalecenia dotyczące niezawodności, wydajności, zabezpieczeń, kosztów i operacji. Aby zrozumieć, jak te obszary wpływają na siebie i przyczyniają się do niezawodnego rozwiązania App Service, zobacz Najlepsze praktyki architektoniczne dla Azure Service Bus w przewodniku Azure Well-Architected Framework.

Omówienie architektury niezawodności

W tej sekcji opisano niektóre ważne aspekty działania usługi, które są najbardziej istotne z perspektywy niezawodności. W sekcji przedstawiono architekturę logiczną, która zawiera niektóre z zasobów i funkcji wdrażanych i używanych. Omówiono również architekturę fizyczną, która zawiera szczegółowe informacje na temat działania usługi za kulisami.

Architektura logiczna

Przestrzeń nazw służy jako kontener zarządzania dla usługi Service Bus i może być skonfigurowana do używania warstwy Podstawowa, Standardowa lub Premium. Usługę można skonfigurować na poziomie przestrzeni nazw, przydzielając pojemność, konfigurując zabezpieczenia sieci i włączając Geo-Replication i Geo-Disaster Recovery.

W przestrzeni nazw wdrażasz kolejki i tematy, które są jednostkami obsługi komunikatów z różnymi semantykami. Aby uzyskać więcej informacji, zobacz Kolejki, tematy i subskrypcje usługi Service Bus.

Opcjonalnie możesz skonfigurować partycje w swoim obszarze nazw, które rozmieszczają kolejki i tematy w wielu brokerach komunikatów i magazynach komunikatów. Przestrzeń nazw może używać wielu partycji do przetwarzania równoległego i skalowania w poziomie. Usługa Service Bus gwarantuje zachowanie kolejności tylko w ramach jednej partycji. Partycjonowanie odgrywa kluczową rolę w projekcie niezawodności aplikacji. Podczas projektowania aplikacji należy dokonać kompromisu między maksymalizacją dostępności i spójnością. W przypadku warstwy Premium włączysz partycjonowanie w przestrzeni nazw. W przypadku przestrzeni nazw w warstwach Podstawowa i Standardowa można skonfigurować partycje w jednostce i opcjonalnie, gdy wysyłasz komunikaty.

Możesz użyć usługi Service Bus i jej asynchronicznych metod projektowania, aby zwiększyć dostępność aplikacji. Aby uzyskać więcej informacji, zobacz Asynchroniczne wzorce obsługi komunikatów i wysoka dostępność.

Architektura fizyczna

Usługa Service Bus udostępnia podstawowe zasoby obliczeniowe i magazynowe. Dla każdej przestrzeni nazw wiele brokerów komunikatów przetwarza komunikaty, a wiele magazynów komunikatów przechowuje komunikaty. Istnieją trzy kopie magazynu wiadomości: jedna podstawowa i dwie pomocnicze. Usługa Service Bus przechowuje wszystkie trzy kopie zsynchronizowane na potrzeby operacji danych i zarządzania. Jeśli kopia podstawowa nie powiedzie się, jedna z kopii pomocniczych zostanie podwyższona do poziomu podstawowego bez postrzeganego przestoju.

W przypadku przestrzeni nazw korzystających z warstwy Podstawowa lub Standardowa usługa Service Bus zapewnia nadmiarowość za pośrednictwem współużytkowanej infrastruktury wielodostępnej, która automatycznie replikuje komunikaty w strefach dostępności tam, gdzie jest dostępna. Usługa obsługuje wiele repozytoriów wiadomości i przechowuje wszystkie kopie zsynchronizowane zarówno dla operacji danych, jak i zarządzania.

W przypadku przestrzeni nazw warstwy Premium usługa Service Bus udostępnia dedykowane jednostki przetwarzania komunikatów, z których każda posiada dedykowane zasoby CPU i pamięci. Przestrzenie nazw o poziomie Premium mogą być skalowane automatycznie na podstawie wymagań dotyczących obciążeń. Aby uzyskać więcej informacji, zobacz Automatyczne aktualizowanie jednostek obsługi komunikatów przestrzeni nazw usługi Azure Service Bus.

Infrastruktura usługi Service Bus obejmuje wiele fizycznych maszyn i stojaków rozmieszczonych w różnych domenach błędów, co zmniejsza ryzyko katastrofalnych awarii wpływających na przestrzeń nazw. W regionach, w których znajdują się strefy dostępności, infrastruktura rozszerza się na oddzielne fizyczne centra danych. Usługa implementuje przezroczyste mechanizmy wykrywania błędów i failover, które zapewniają kontynuację działania w ramach zapewnianych poziomów usług, zazwyczaj bez zauważalnych przerw, gdy dochodzi do takich awarii.

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.

Zestaw SDK usługi Azure Service Bus zawiera automatyczną logikę ponawiania prób z zastosowaniem wykładniczego odstępu dla operacji, które zawodzą z powodu przejściowych problemów, takich jak przekroczenia limitu czasu sieci lub tymczasowa niedostępność usługi. Gdy aplikacje doświadczają przejściowego rozłączenia z usługą Service Bus, zestaw SDK automatycznie próbuje ponownie nawiązać połączenie przy użyciu skonfigurowanych zasad ponawiania prób.

Aby zoptymalizować obsługę błędów przejściowych w aplikacjach, użyj najnowszego zestawu SDK usługi Service Bus, który zawiera najbardziej aktualne funkcje logiki ponawiania prób i zarządzania połączeniami. Aby uzyskać więcej informacji, zobacz Biblioteka klienta usługi Azure Service Bus dla platformy .NET.

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 Service Bus obsługuje wdrożenia strefowo nadmiarowe na wszystkich poziomach usługi. Podczas tworzenia przestrzeni nazw usługi Service Bus w obsługiwanym regionie nadmiarowość strefy jest automatycznie włączana bez dodatkowych kosztów. Model wdrażania strefowo nadmiarowego ma zastosowanie do wszystkich funkcji usługi Service Bus, w tym partycjonowania i sesji.

Usługa Service Bus w sposób przezroczysty replikuje dane konfiguracji, metadanych i komunikatów w wielu strefach dostępności w regionie. Redundancja strefy zapewnia automatyczne przełączenie awaryjne bez konieczności interwencji z Twojej strony. Wszystkie składniki usługi Service Bus, w tym zasoby obliczeniowe, sieć i magazyn, są replikowane między strefami. Service Bus ma wystarczające rezerwy pojemności, aby natychmiast poradzić sobie z całkowitą utratą strefy. Nawet jeśli cała strefa dostępności stanie się niedostępna, usługa Service Bus nadal działa bez utraty danych lub przerw w działaniu aplikacji do obsługi komunikatów.

Requirements

• Obsługa regionów: Strefowo nadmiarowe przestrzenie nazw usługi Service Bus można wdrażać w regionach świadczenia usługi Azure z obsługą stref dostępności. Usługa Service Bus automatycznie włącza obsługę stref dostępności podczas tworzenia przestrzeni nazw w obsługiwanym regionie bez konieczności dodatkowej konfiguracji.

• Warstwy: Wszystkie warstwy usługi Service Bus (Podstawowa, Standardowa i Premium) obsługują strefy dostępności bez dodatkowych wymagań.

Rozważania

Przestrzenie nazw usługi Service Bus zawierają właściwość zoneRedundant. Wcześniej ta właściwość była wymagana do włączenia stref dostępności, ale to działanie uległo zmianie i właściwość zoneRedundant jest obecnie uznawana za przestarzałą. Ta właściwość może nadal wyświetlać się jako false, nawet gdy redundancja strefy jest włączona. Wszystkie przestrzenie nazw w regionach ze strefami dostępności są strefowo nadmiarowe.

Koszt

Nadmiarowość stref w usłudze Service Bus nie dodaje dodatkowych kosztów.

Konfiguruj obsługę stref dostępności

Namespace'y usługi Service Bus automatycznie obsługują redundancję strefową po wdrożeniu w obsługiwanych regionach. Nie trzeba konfigurować niczego więcej.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy nazwy przestrzeni usługi Service Bus są konfigurowane pod kątem nadmiarowości stref i wszystkie strefy dostępności działają.

• Routing ruchu między strefami. Usługa Service Bus używa modelu aktywne-aktywne, w którym komunikaty są dystrybuowane w wielu strefach dostępności. Połączenia klienckie są automatycznie rozkładane pomiędzy strefy, a usługa kieruje operacje do dostępnej infrastruktury obsługi komunikatów, niezależnie od wybranej strefy.

• Replikacja danych między strefami. Usługa Service Bus używa replikacji synchronicznej w strefach dostępności, w tym w przypadku metadanych i danych komunikatów. Wiele kopii magazynu komunikatów musi potwierdzić operacje zapisu, zanim zostaną uznane za ukończone, zapewniając spójność danych między strefami podczas normalnych operacji.

Zachowanie podczas awarii strefy

W tej sekcji opisano, czego można oczekiwać, gdy przestrzenie nazw usługi Service Bus są skonfigurowane dla redundancji strefowej i dochodzi do awarii strefy dostępności.

• Wykrywanie i reagowanie: firma Microsoft automatycznie wykrywa awarie stref i przechodzi do zdrowych stref. Do przejścia w tryb failover na poziomie strefy nie jest wymagana żadna akcja klienta.

• Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy strefa nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie błędy strefy, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

• Aktywne żądania: podczas awarii strefy usługa Service Bus może usuwać aktywne żądania. Jeśli klienci odpowiednio obsługują błędy przejściowe, ponawiając próbę po krótkim czasie, zwykle unikają znaczącego wpływu.

• Oczekiwana utrata danych: brak utraty danych podczas awarii strefy, ponieważ usługa Service Bus synchronicznie replikuje komunikaty między strefami przed potwierdzeniem.

• Oczekiwany przestój: awaria strefy może spowodować kilka sekund przestoju. Jeśli klienci odpowiednio obsługują błędy przejściowe, ponawiając próbę po krótkim czasie, zwykle unikają znaczącego wpływu.

• Przekierowywanie ruchu: usługa Service Bus wykrywa utratę strefy i automatycznie przekierowuje nowe żądania do innej repliki w jednej ze sprawnych stref dostępności.

  SDK usługi Service Bus zwykle obsługuje zarządzanie połączeniami i logikę ponawiania prób w sposób przezroczysty.

Odzyskiwanie strefy

Po odzyskaniu strefy dostępności usługa Service Bus automatycznie ponownie integruje strefę z aktywną topologią usługi. Odzyskana strefa rozpoczyna akceptowanie nowych połączeń i przetwarzanie komunikatów wraz z innymi strefami. Dane, które zostały zreplikowane do stref ocalałych podczas awarii, pozostają nienaruszone, a normalne synchroniczne replikacje są wznawiane we wszystkich strefach. Nie musisz podejmować akcji dla odzyskiwania strefy i ponownej integracji.

Testowanie pod kątem niepowodzeń strefy

Usługa Service Bus zarządza trasowaniem ruchu, mechanizmem przełączenia awaryjnego i odzyskiwaniem stref w przypadku awarii stref, dzięki czemu nie trzeba weryfikować procesów awarii stref dostępności ani udostępniać dalszych danych wejściowych.

Odporność na awarie całego regionu

Usługa Service Bus oferuje dwa typy obsługi wieloregionalnej, z których oba wymagają przestrzeni nazw w warstwie Premium.

• Replikacja geograficzna zapewnia aktywną-pasywną replikację zarówno metadanych, jak i danych komunikatów między regionem podstawowym a regionem pomocniczym. Użyj Geo-Replication dla większości aplikacji, które muszą pozostać odporne na awarie regionów oraz mają niską tolerancję na utratę danych wiadomości.

• Metadane Geo-Disaster Recovery zapewniają aktywną-pasywną replikację konfiguracji i metadanych między regionem podstawowym i pomocniczym, ale nie replikuje danych komunikatów. Rozważ użycie usługi Geo-Disaster Recovery dla aplikacji, które obsługują własną replikację danych lub które nie wymagają replikacji danych.

Zarówno Geo-Replication, jak i metadane Geo-Disaster Recovery, wymagają ręcznego zainicjowania trybu failover lub podwyższenia poziomu regionu pomocniczego, aby stać się nowym regionem podstawowym. Firma Microsoft nie wykonuje automatycznego przełączenia awaryjnego ani promocji, nawet jeśli region podstawowy nie działa.

Przestrzenie nazw w warstwach Podstawowa i Standardowa nie obejmują natywnych funkcji wielu regionów, ale można zaimplementować wzorce replikacji na poziomie aplikacji przy użyciu wielu przestrzeni nazw w różnych regionach. Aby uzyskać więcej informacji, zobacz sekcję Niestandardowe rozwiązania obejmujące wiele regionów dla odporności poniżej.

Geo-Replication

Warstwa Premium obsługuje replikację geograficzną. Ta funkcja replikuje zarówno metadane (takie jak jednostki, konfiguracja i właściwości), jak i dane (na przykład komunikaty w kolejkach i tematach, oraz właściwości i stan wiadomości) dla przestrzeni nazw. Konfigurujesz podejście do replikacji dla konfiguracji i danych przestrzeni nazw. Ta funkcja zapewnia, że komunikaty pozostaną dostępne w innym regionie i umożliwią przełączenie się do regionu pomocniczego w razie potrzeby.

Użyj Geo-Replication w scenariuszach, które wymagają odporności na awarie regionów i mają niską tolerancję na utratę danych komunikatów.

Przestrzeń nazw zasadniczo rozszerza się w różnych regionach. Jeden region służy jako podstawowy, a pozostałe regiony służą jako pomocnicze. Subskrypcja platformy Azure zawiera jedną przestrzeń nazw.

W dowolnym momencie możesz podwyższyć poziom regionu pomocniczego do regionu podstawowego. Po promocji regionu pomocniczego, usługa Service Bus zmienia przyporządkowanie w pełni kwalifikowanej nazwy domeny (FQDN) przestrzeni nazw do wybranego regionu pomocniczego i degraduje poprzedni region podstawowy do regionu pomocniczego. Decydujesz, czy przeprowadzić planowaną promocję, co oznacza, że czekasz na zakończenie replikacji danych, czy wymuszoną promocję, co może spowodować utratę danych.

Ta sekcja zawiera podsumowanie ważnych aspektów replikacji geograficznej. Przejrzyj pełną dokumentację, aby dokładnie zrozumieć, jak działa. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna usługi Service Bus.

Requirements

• Obsługa regionów: Możesz wybrać dowolny region świadczenia usługi Azure, który obsługuje usługę Service Bus jako region podstawowy lub pomocniczy. Nie musisz używać sparowanych regionów platformy Azure, więc możesz wybrać regiony pomocnicze na podstawie opóźnień, zgodności ani wymagań dotyczących rezydencji danych.

• Kondygnacja: Aby włączyć replikację geograficzną, przestrzeń nazw musi używać warstwy Premium.

• Odzyskiwanie Geo-Disaster metadanych: Nie można skonfigurować przestrzeni nazw do używania zarówno Geo-Replication, jak i Geo-Disaster Recovery.

Rozważania

• Ograniczenia funkcji: Po włączeniu replikacji geograficznej istnieją pewne ograniczenia. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna usługi Service Bus.

• Prywatne punkty końcowe: Jeśli używasz prywatnych punktów końcowych do nawiązywania połączenia z przestrzenią nazw, musisz również skonfigurować sieć w regionach podstawowych i pomocniczych. Aby uzyskać więcej informacji, zobacz Prywatne punkty końcowe w dokumentacji usługi Azure Event Hubs.

Koszt

Aby dowiedzieć się, jak działa cennik replikacji geograficznej, zobacz Cennik.

Konfigurowanie obsługi wielu regionów

• Włącz Geo-Replication w nowej przestrzeni nazw. Aby włączyć Geo-Replication w przestrzeni nazw podczas jej tworzenia, zobacz Przełączanie trybu replikacji.

• Migracja z Odzyskiwania awaryjnego Geo do Replikacji geograficznej.Możesz przełączyć się z wykorzystania Odzyskiwania awaryjnego Geo na Replikację geograficzną.

• Zmień podejście replikacji. Aby zmienić tryb replikacji synchronicznej i asynchronicznej, zobacz Przełączanie trybu replikacji.

• Wyłącz replikację geograficzną. Aby wyłączyć Geo-Replication do regionu pomocniczego, zobacz Usuwanie regionu pomocniczego.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy przestrzeń nazw usługi Service Bus jest skonfigurowana na potrzeby replikacji geograficznej, a region podstawowy działa.

• Routing ruchu między regionami: Aplikacje klienckie łączą się poprzez nazwę FQDN przestrzeni nazw, a ich ruch jest kierowany do regionu podstawowego.

  Tylko region podstawowy aktywnie przetwarza komunikaty od klientów podczas normalnych operacji. Region pomocniczy odbiera replikowane komunikaty, ale w przeciwnym razie pozostaje pasywny w trybie wstrzymania.

• Replikacja danych między regionami: Zachowanie replikacji danych między regionem podstawowym i pomocniczym zależy od tego, czy skonfigurować parowanie replikacji w celu używania replikacji synchronicznej, czy asynchronicznej.

  • Synchroniczny: Komunikaty są replikowane do regionu pomocniczego przed zakończeniem operacji zapisu.

    Ten tryb zapewnia największą pewność, że dane wiadomości są bezpieczne, ponieważ muszą zostać zapisane w regionie podstawowym i pomocniczym. Jednak replikacja synchroniczna znacznie zwiększa opóźnienie zapisu dla komunikatów przychodzących. Wymaga również, aby region pomocniczy był dostępny do akceptowania operacji zapisu, więc awaria w regionie pomocniczym powoduje niepowodzenie operacji zapisu.

    • Asynchroniczny: Komunikaty są zapisywane w regionie podstawowym, a następnie kończy się operacja zapisu. Chwilę później replikuje komunikaty do regionu pomocniczego.

    Ten tryb zapewnia większą przepływność zapisu niż replikacja synchroniczna, ponieważ podczas operacji zapisu nie ma opóźnienia replikacji między regionami. Ponadto tryb replikacji asynchronicznej może tolerować utratę regionu pomocniczego, jednocześnie zezwalając na operacje zapisu w regionie podstawowym. Jeśli jednak region podstawowy ma awarię, wszystkie dane, które nie zostały jeszcze zreplikowane w regionie pomocniczym, mogą być niedostępne lub utracone.

    Podczas konfigurowania replikacji asynchronicznej należy skonfigurować maksymalny dopuszczalny czas opóźnienia replikacji. W dowolnym momencie możesz zweryfikować bieżące opóźnienie replikacji przy użyciu metryk usługi Azure Monitor.

    Jeśli opóźnienie replikacji asynchronicznej wzrośnie powyżej maksymalnej wartości, główny region zacznie ograniczać żądania przychodzące, aby replikacja mogła nadrobić zaległości. Aby uniknąć tej sytuacji, ważne jest, aby wybrać regiony pomocnicze, które nie są zbyt odległe geograficznie i upewnić się, że pojemność jest wystarczająca dla przepustowości.

    Niektóre typy metadanych są replikowane synchronicznie, nawet jeśli wybierzesz tryb replikacji asynchronicznej.

    Aby uzyskać więcej informacji, zobacz Tryby replikacji.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać, gdy przestrzeń nazw usługi Service Bus jest skonfigurowana dla Geo-Replication i występuje awaria w regionie podstawowym lub pomocniczym.

• Wykrywanie i reagowanie: Odpowiadasz za podjęcie decyzji, kiedy awansować region pomocniczy Twojej przestrzeni nazw, aby został nowym regionem podstawowym. Firma Microsoft nie podejmuje tej decyzji ani nie inicjuje procesu, nawet jeśli wystąpi awaria w regionie. Aby zapoznać się z sugerowanymi kryteriami, które należy wziąć pod uwagę podczas podejmowania decyzji o przejściu w tryb failover, zobacz Zalecane scenariusze wyzwalania podwyższenia poziomu.

  Aby uzyskać więcej informacji na temat promowania regionu pomocniczego do nowego regionu głównego, zobacz Przepływ promocji.

  Gdy promujesz region pomocniczy, wybierz, czy chcesz przeprowadzić promocję planowaną czy promocję wymuszoną. Planowana promocja czeka na nadrobienie zaległości w regionie pomocniczym przed zaakceptowaniem nowego ruchu. Takie podejście eliminuje utratę danych, ale wprowadza przestoje.

  Podczas awarii w regionie podstawowym zazwyczaj trzeba przeprowadzić wymuszoną promocję. Jeśli region podstawowy jest dostępny i z innego powodu uruchomisz promocję, możesz zdecydować się na planowaną promocję.

• Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie awarie regionów, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

• Aktywne żądania: Zachowanie zależy od tego, czy awaria regionu występuje w regionie podstawowym, czy w regionie pomocniczym:

  • Awaria regionu podstawowego: Jeśli region podstawowy jest niedostępny, wszystkie aktywne żądania zostaną zakończone. Aplikacje klienckie powinny ponawiać próby wykonania operacji po zakończeniu promocji.

  • Awaria regionu pomocniczego: Awaria w regionie pomocniczym może powodować problemy z aktywnymi żądaniami w następujących sytuacjach:

    • Jeśli używasz trybu replikacji synchronicznej, region podstawowy nie może ukończyć operacji zapisu, jeśli jakikolwiek region pomocniczy jest niedostępny.

    • Jeśli używasz trybu replikacji asynchronicznej, przestrzeń nazw ogranicza przepływność i nie akceptuje nowych wiadomości, gdy opóźnienie replikacji osiągnie maksymalną skonfigurowaną wartość.

    Aby kontynuować korzystanie z przestrzeni nazw w regionie podstawowym, usuń pomocniczą przestrzeń nazw z konfiguracji Geo-Replication.

• Oczekiwana utrata danych: Ilość utraty danych zależy od typu promocji, którą wykonujesz (planujesz lub wymuszasz), oraz trybu replikacji (synchronicznego lub asynchronicznego):

  • Planowana promocja: Nie oczekuje się utraty danych. Jednak podczas awarii regionu planowana promocja może nie być możliwa, ponieważ wymaga ona udostępnienia wszystkich regionów podstawowych i pomocniczych.

  • Wymuszona promocja, replikacja synchroniczna: Nie oczekuje się utraty danych.

  • Wymuszona promocja, replikacja asynchroniczna: Może wystąpić utrata danych dla ostatnich komunikatów, które nie zostały zreplikowane do drugorzędnego regionu, oraz dla zmian stanu, które nie są jeszcze zreplikowane. Ilość zależy od opóźnienia replikacji. Aby sprawdzić bieżące opóźnienie replikacji, użyj metryk usługi Azure Monitor.

  Jeśli wykonasz wymuszoną promocję, nie możesz odzyskać utraconych danych nawet po udostępnieniu regionu podstawowego.

• Oczekiwany przestój: Oczekiwany przestój zależy od tego, czy wykonasz zaplanowaną, czy wymuszoną promocję:

  • Planowana promocja: Pierwszy krok planowanej promocji dokonuje replikacji danych do regionu drugorzędnego. Ten proces zwykle kończy się szybko, ale w niektórych sytuacjach może potrwać tyle, ile opóźnienie replikacji. Po zakończeniu replikacji proces podwyższania poziomu zwykle trwa około 5 do 10 minut. Czasami serwery systemu nazw domen (DNS) mogą potrzebować więcej czasu na aktualizację wpisów i pełną synchronizację swoich zapisów z klientami.

    Podstawowy region nie akceptuje operacji zapisu podczas całego procesu promocji.

    Ta opcja może nie być możliwa podczas awarii regionu, ponieważ wymaga dostępności wszystkich regionów podstawowych i pomocniczych.

  • Wymuszona promocja: Podczas wymuszonej promocji usługa Service Bus nie czeka na ukończenie replikacji danych i natychmiast przystępuje do promocji. Proces podwyższania poziomu zwykle trwa od około 5 do 10 minut. Czasami może upłynąć dłużej, aby wpisy DNS były w pełni replikowane i aktualizowane na klientach.

    Podstawowy region nie akceptuje operacji zapisu podczas całego procesu promocji.

• Przekierowywanie ruchu: Po zakończeniu podwyższania poziomu nazwa FQDN przestrzeni nazw wskazuje nowy region podstawowy. Jednak to przekierowanie zależy od tego, jak szybko aktualizowane są rekordy DNS klientów, w tym na ich serwerach DNS, aby respectować czas żywotności (TTL) rekordów DNS w przestrzeni nazw.

Odzyskiwanie regionów

Gdy oryginalny region podstawowy zostanie przywrócony, jeśli chcesz, aby przestrzeń nazw wróciła do oryginalnego regionu podstawowego, wykonaj ten sam proces promowania regionu.

Jeśli podczas niedostępności regionu wykonano wymuszoną promocję, nie można odzyskać utraconych danych nawet po udostępnieniu regionu podstawowego.

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

Aby przetestować replikację geograficzną, tymczasowo podwyższ poziom regionu pomocniczego do podstawowego i sprawdź, czy aplikacje klienckie mogą przełączać się między regionami z minimalnymi zakłóceniami.

Monitoruj czas trwania promocji i zweryfikuj, czy Runbooki i automatyzacja działają prawidłowo. Po przetestowaniu można przywrócić oryginalną konfigurację.

Poznaj potencjalne przestoje i utratę danych, które mogą wystąpić podczas procesu podwyższania poziomu i po jego zakończeniu. Przetestuj Geo-Replication w środowisku nieprodukcyjnym, które odzwierciedla konfigurację produkcyjnej przestrzeni nazw.

Odzyskiwanie metadanych po katastrofie geograficznej

Warstwa Premium obsługuje metadane odzyskiwania po katastrofach geograficznych. Ta funkcja usprawnia odbudowę po katastrofie, w tym katastrofalną stratę regionu. Funkcja Geo-Disaster Recovery replikuje tylko konfigurację i metadane twojej przestrzeni nazw. Jednak nie replikuje danych komunikatów. Aby zapewnić obsługę odzyskiwania po awarii, ta funkcja gwarantuje, że przestrzeń nazw w innym regionie jest wstępnie skonfigurowana i gotowa do natychmiastowego akceptowania komunikatów od klientów. Geo-Disaster Recovery służy jako jednokierunkowe rozwiązanie do odzyskiwania i nie obsługuje powrotu po awarii do poprzedniego regionu podstawowego.

Metadane Geo-Disaster Recovery działają najlepiej w przypadku aplikacji, które nie muszą utrzymywać każdego komunikatu i mogą tolerować niektóre straty danych podczas scenariusza awarii. Metadane Geo-Disaster Recovery mogą być również odpowiednie dla aplikacji, które replikują dane samodzielnie lub które w ogóle nie wymagają replikacji danych. Jeśli na przykład komunikaty reprezentują duże obrazy, które później przekonwertujesz na miniatury, możesz zdecydować, że możesz sobie pozwolić na utratę niektórych komunikatów z regionu, który zakończył się niepowodzeniem, jeśli możesz szybko wznowić przetwarzanie nowych komunikatów w innym regionie i później odtworzyć komunikaty w celu nadrobienia zaległości.

Podczas konfigurowania metadanych Geo-Disaster Recovery należy utworzyć alias , z którym łączą się aplikacje klienckie. Alias to nazwa FQDN, która domyślnie kieruje cały ruch do podstawowej przestrzeni nazw.

Jeśli region podstawowy ulegnie awarii lub wystąpi inna awaria, możesz ręcznie zainicjować jednokierunkowe przejście w tryb failover z regionu podstawowego do regionu pomocniczego w dowolnym momencie. Możesz wybrać bezpieczny tryb failover, który czeka na ukończenie replikacji przed przełączeniem na serwer zapasowy, chociaż ta opcja może nie być dostępna podczas przerwy w działaniu regionu. Po rozpoczęciu trybu failover kończy się niemal natychmiast. Podczas procesu trybu failover alias usługi Geo-Disaster Recovery ponownie wskazuje na pomocniczą przestrzeń nazw, a parowanie zostanie usunięte.

W tej sekcji podsumowano ważne aspekty Geo-Disaster Recovery. Przejrzyj pełną dokumentację, aby dokładnie zrozumieć, jak działa. Aby uzyskać więcej informacji, zobacz Service Bus Geo-Disaster Recovery.

Requirements

• Obsługa regionów: Możesz wybrać dowolny region świadczenia usługi Azure, który obsługuje usługę Service Bus jako podstawową lub pomocniczą przestrzeń nazw. Nie musisz używać sparowanych regionów platformy Azure, więc możesz wybrać regiony pomocnicze na podstawie opóźnień, zgodności ani wymagań dotyczących rezydencji danych.

• Tier: Aby włączyć metadane Geo-Disaster Recovery, obie przestrzenie nazw muszą używać poziomu Premium.

• Partycjonowanie: Nie można sparować partycjonowanej przestrzeni nazw z niepartyjną przestrzenią nazw.

• Odzyskiwanie Geo-Disaster metadanych: Nie można skonfigurować przestrzeni nazw do używania zarówno Geo-Replication, jak i Geo-Disaster Recovery.

Rozważania

• Ograniczenia funkcji: Po włączeniu Geo-Disaster Recovery istnieją pewne ograniczenia. Aby uzyskać więcej informacji, zobacz Ważne kwestie do rozważenia i zagadnienia.

• Przypisania ról: Przypisania kontroli dostępu opartej na rolach (RBAC) Microsoft Entra do elementów w podstawowym obszarze nazw nie są replikowane do pomocniczego obszaru nazw. Ręczne tworzenie przypisań ról w pomocniczej przestrzeni nazw w celu zabezpieczenia dostępu do nich.

• Projekt aplikacji: Geo-Disaster Recovery wymaga szczególnych zagadnień podczas projektowania aplikacji klienckich. Aby uzyskać więcej informacji, zobacz Considerations.

• Prywatne punkty końcowe: Jeśli używasz prywatnych punktów końcowych do nawiązywania połączenia z przestrzenią nazw, skonfiguruj sieć zarówno w regionie podstawowym, jak i pomocniczym. Aby uzyskać więcej informacji, zobacz Prywatne punkty końcowe.

• Przestrzenie nazw migrowane ze standardu do warstwy Premium: Jeśli przestrzeń nazw była wcześniej w warstwie Standardowa i została ona zmigrowana do warstwy Premium, musisz obsługiwać alias inaczej. Aby uzyskać więcej informacji, zobacz Service Bus Standard to Premium.

Koszt

Po włączeniu funkcji Geo-Disaster Recovery dla metadanych płacisz zarówno za podstawowe, jak i pomocnicze przestrzenie nazw.

Konfigurowanie obsługi wielu regionów

• Utwórz metadane parowania geograficznego odzyskiwania po awarii. Aby skonfigurować odzyskiwanie po awarii między podstawowymi i zapasowymi przestrzeniami nazw, zobacz Przepływ konfiguracji i tryb failover.

• Wyłącz odzyskiwanie po awarii geograficznej metadanych. Aby przerwać parowanie między przestrzeniami nazw, zobacz Konfiguracja i przepływ awaryjny.

Planowanie pojemności i zarządzanie nimi

Podczas planowania wdrożeń w wielu regionach upewnij się, że oba regiony mają wystarczającą pojemność do obsługi pełnego obciążenia, jeśli jeden region ulegnie awarii. Region zapasowy pozostaje pasywny podczas normalnych operacji, ale po przełączeniu awaryjnym musi natychmiast obsługiwać ruch. Zaplanuj sposób skalowania pojemności przestrzeni nazw pomocniczej, aby mogła odbierać ruch produkcyjny bez opóźnień. Jeśli możesz tolerować dodatkowy przestój podczas procesu przełączania awaryjnego, rozważ skalowanie pojemności pomocniczej przestrzeni nazw podczas lub po przełączeniu awaryjnym. Aby zmniejszyć przestoje, należy wcześniej zapewnić pojemność w pomocniczej przestrzeni nazw, aby była gotowa na przyjęcie obciążenia produkcyjnego.

Zachowanie, gdy wszystkie regiony są w dobrej kondycji

W tej sekcji opisano, czego można oczekiwać, gdy przestrzeń nazw usługi Service Bus jest skonfigurowana dla usługi Geo-Disaster Recovery, a region podstawowy działa.

• Routing ruchu między regionami: Aplikacje klienckie łączą się za pośrednictwem aliasu Geo-Disaster Recovery dla przestrzeni nazw, a ich ruch kierowany jest do podstawowej przestrzeni nazw w regionie podstawowym.

  Tylko podstawowa przestrzeń nazw aktywnie przetwarza komunikaty od klientów podczas normalnych operacji. Pomocnicza przestrzeń nazw pozostaje pasywna w trybie wstrzymania, a wszystkie żądania dostępu do danych kończą się niepowodzeniem.

• Replikacja danych między regionami: Tylko metadane konfiguracji są replikowane między przestrzeniami nazw. Replikacja konfiguracji odbywa się w sposób ciągły i asynchroniczny.

  Wszystkie dane komunikatów pozostają tylko w podstawowej przestrzeni nazw i nie są replikowane do pomocniczej przestrzeni nazw.

Zachowanie podczas awarii regionu

W tej sekcji opisano, czego można oczekiwać, gdy przestrzeń nazw usługi Service Bus jest skonfigurowana dla usługi Geo-Disaster Recovery i występuje awaria w regionie podstawowym.

• Wykrywanie i reagowanie: Odpowiadasz za monitorowanie kondycji regionu i ręczne inicjowanie trybu failover. Firma Microsoft nie przeprowadza przełączania awaryjnego ani nie promuje automatycznie regionu zapasowego, nawet jeśli region podstawowy nie działa.

  Aby uzyskać więcej informacji na temat inicjowania trybu failover, zobacz Przepływ trybu failover.

  Po zainicjowaniu failover wybierz, czy przeprowadzić bezpieczny failover, czy standardowy (wymuszony lub ręczny failover). Bezpieczny failover czeka na ukończenie replikacji do regionu pomocniczego przed jego rozpoczęciem. Takie podejście zmniejsza utratę metadanych, ale wprowadza przestoje. Bezpieczne przejście w tryb failover wymaga, aby przestrzenie nazw były w tej samej subskrypcji platformy Azure.

  Podczas awarii w regionie podstawowym zazwyczaj konieczne jest przeprowadzenie wymuszonego przejścia w tryb failover. Jeśli region podstawowy jest dostępny i inicjujesz awaryjne przełączenie z innego powodu, możesz wybrać zaplanowane przełączenie.

  Failover jest jednokierunkową operacją, więc należy później ponownie ustanowić sparowanie Geo-Disaster Recovery. Aby uzyskać więcej informacji, zobacz Odzyskiwanie regionów.

• Powiadomienie: firma Microsoft nie powiadamia cię automatycznie, gdy region nie działa. Możesz jednak użyć usługi Azure Service Health , aby zrozumieć ogólną kondycję usługi, w tym wszelkie awarie regionów, i skonfigurować alerty usługi Service Health w celu powiadamiania o problemach.

• Aktywne żądania: Aktywne żądania w toku kończą się po uruchomieniu trybu failover. Aplikacje klienckie powinny ponawiać próby wykonania operacji po zakończeniu pracy w trybie failover.

• Oczekiwana utrata danych:

  • Metadane: Konfiguracja i metadane zwykle są replikowane do pomocniczej przestrzeni nazw. Jednak replikacja metadanych odbywa się asynchronicznie, więc ostatnie zmiany mogą nie być replikowane, szczególnie złożone zmiany. Przed uzyskaniem dostępu do niej przez klientów sprawdź konfigurację pomocniczej przestrzeni nazw.

  • Dane komunikatu: Dane komunikatów nie są replikowane między regionami. Jeśli region podstawowy ulegnie awarii, komunikaty w podstawowej przestrzeni nazw staną się niedostępne.

    Komunikaty nie zostaną trwale utracone, chyba że katastrofalna katastrofa spowoduje całkowitą utratę regionu podstawowego. Jeśli region zostanie odzyskany, możesz później pobrać komunikaty z podstawowej przestrzeni nazw.

• Oczekiwany przestój: Failover na ogół występuje w ciągu 5 do 10 minut. Pełne replikowanie i aktualizowanie wpisów DNS przez klientów może potrwać dłużej.

• Przekierowywanie ruchu: Klienci używający aliasu usługi Geo-Disaster Recovery do łączenia się z przestrzenią nazw automatycznie przekierowują do pomocniczej przestrzeni nazw po awarii. Jednak to przekierowanie zależy od serwerów DNS honorujących TTL rekordów DNS przestrzeni nazw i klientów odbierających te zaktualizowane rekordy DNS.

Odzyskiwanie regionów

Po przywróceniu oryginalnego regionu podstawowego należy ręcznie przywrócić połączenie i opcjonalnie przełączyć się z powrotem. Utwórz nową parę Geo-Disaster Recovery z odzyskanym regionem jako pomocniczym, a następnie wykonaj kolejne przełączenie awaryjne, jeśli chcesz powrócić do oryginalnego regionu. Ten proces obejmuje potencjalną utratę danych komunikatów wysyłanych do tymczasowego podstawowego elementu.

Jeśli awaria spowoduje utratę wszystkich stref w regionie podstawowym, dane mogą być nieodwracalne. W innych scenariuszach dane komunikatów pozostają w podstawowej przestrzeni nazw z okresu sprzed przełączenia awaryjnego i można je odzyskać. Po przywróceniu dostępu można uzyskać historyczne komunikaty ze starej podstawowej przestrzeni nazw. Odpowiadasz za konfigurowanie aplikacji pod kątem odbierania i przetwarzania tych komunikatów. Firma Microsoft nie przywraca ich automatycznie do regionu pomocniczego.

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

Aby przetestować procesy reagowania i odzyskiwania po awarii, wykonaj planowane przejście w tryb failover podczas okna serwisowego. Przełącz swoją podstawową przestrzeń nazw do pomocniczej przestrzeni nazw i zweryfikuj, czy aplikacje mogą się z nią łączyć i przetwarzać komunikaty z nowej podstawowej przestrzeni nazw.

Monitoruj czas trwania failoveru i sprawdź, czy runbooki oraz automatyzacja działają poprawnie. Po przetestowaniu można przywrócić oryginalną konfigurację.

Zapoznaj się z możliwymi przestojami i utratą danych, które mogą wystąpić podczas i po procesie przełączania awaryjnego. Testuj metadane Geo-Disaster Recovery w środowisku nieprodukcyjnym, które odzwierciedla konfigurację przestrzeni nazw wykorzystywanej w produkcji.

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

Geo-Replication i Geo-Disaster Recovery dla metadanych zapewniają odporność na awarie regionów i inne problemy oraz są odpowiednie dla większości obciążeń. Mogą one jednak nie odpowiadać Twoim potrzebom w następujących sytuacjach:

• Masz wymagania dotyczące replikacji niestandardowej lub obsługi wielu aktywnych regionów jednocześnie.
• Używasz warstwy usługi Service Bus, która nie obsługuje tych funkcji.

Istnieje szereg wzorców projektowych, które umożliwiają osiągnięcie różnych typów obsługi wielu regionów w usłudze Service Bus. Wiele wzorców wymaga wdrożenia wielu przestrzeni nazw i odpowiedniego skonfigurowania aplikacji do używania przestrzeni nazw. Aby dowiedzieć się więcej, zobacz następujące artykuły:

• Użycie wielu przestrzeni nazw do ochrony aplikacji przed przestojami i katastrofami usługi Service Bus
• Replikacja komunikatów i federacja między regionami.

Odporność usługi na prace konserwacyjne

Usługa Service Bus wykonuje regularną konserwację. Podczas planowanej konserwacji przestrzenie nazw są przenoszone do nadmiarowego węzła zawierającego najnowsze aktualizacje. Gdy następuje to przeniesienie, zestaw SDK klienta automatycznie rozłącza się i ponownie łączy w przestrzeni nazw. Zazwyczaj uaktualnienia odbywają się w ciągu 30 sekund. Ważne jest, aby aplikacje przygotowywały się do wszelkich przejściowych rozłączeń sieci występujących w okresach konserwacji.

Aby uzyskać więcej informacji, zobacz Wskazówki dotyczące zdarzeń konserwacji platformy Azure dla usługi Azure Service Bus.

Tworzenie kopii zapasowej i przywracanie

Usługa Service Bus nie jest zaprojektowana jako długoterminowa lokalizacja przechowywania danych. Zazwyczaj dane są przechowywane w temacie lub kolejce przez krótki czas, a następnie przetwarzane lub utrwalane w innym systemie magazynu danych, w którym momencie są usuwane. W związku z tym projektem usługa Service Bus automatycznie utrzymuje repliki danych komunikatów, ale nie zapewnia możliwości tworzenia kopii zapasowych i przywracania danych komunikatów.

W przypadku scenariuszy wymagających długoterminowego przechowywania komunikatów rozważ zaimplementowanie archiwizacji na poziomie aplikacji w usłudze Azure Storage lub innych trwałych usługach magazynu.

Umowa dotycząca poziomu usług

Umowa dotycząca poziomu usług (SLA) dla usług platformy Azure opisuje oczekiwaną dostępność każdej usługi oraz warunki, które rozwiązanie musi spełnić, aby osiągnąć te oczekiwania dotyczące dostępności. Aby uzyskać więcej informacji, zobacz Umowy SLA dotyczące usług online.

Usługa Service Bus zapewnia umowę SLA dla wszystkich przestrzeni nazw. Umowa SLA dotycząca dostępności jest wyższa, gdy przestrzeń nazw spełnia wszystkie następujące kryteria:

• Używa warstwy premium.
• Znajduje się w regionie ze strefami dostępności.
• Używa partycjonowania.

Treści powiązane

• Dokumentacja usługi Service Bus
• Odzyskiwanie po awarii geograficznej usługi Azure Service Bus
• Replikacja geograficzna usługi Azure Service Bus