Odzyskiwanie po awarii geograficznej usługi Azure Service Bus

  • Artykuł

Odporność na katastrofalne awarie zasobów przetwarzania danych jest wymagana dla wielu przedsiębiorstw, a w niektórych przypadkach nawet wymagana przez przepisy branżowe.

Usługa Azure Service Bus już rozprzestrzenia ryzyko katastroficznych awarii poszczególnych maszyn, a nawet kompletnych stojaków w klastrach obejmujących wiele domen awarii w centrum danych i implementuje przezroczyste mechanizmy wykrywania błędów i trybu failover, tak aby usługa nadal działała w ramach zapewnianych poziomów usług i zwykle bez zauważalnych przerw w działaniu w przypadku wystąpienia takich awarii. Przestrzeń nazw w warstwie Premium może mieć co najmniej dwie jednostki obsługi komunikatów, a te jednostki obsługi komunikatów są rozmieszczone w wielu domenach awarii w centrum danych, obsługując model klastra usługi Service Bus wszystkich aktywnych.

W przypadku przestrzeni nazw warstwy Premium ryzyko awarii jest dodatkowo rozłożone na trzy fizycznie oddzielone obiekty (strefy dostępności), a usługa ma wystarczającą ilość rezerw pojemności, aby natychmiast poradzić sobie z całkowitą, katastrofalną utratą centrum danych. Cały aktywny model klastra usługi Azure Service Bus w domenie awarii wraz z obsługą strefy dostępności jest lepszy od dowolnego lokalnego produktu brokera komunikatów pod względem odporności na poważne awarie sprzętowe, a nawet katastrofalną utratę całych obiektów centrum danych. Mimo to, mogą istnieć poważne sytuacje z powszechnym zniszczeniem fizycznym, że nawet te środki nie mogą wystarczająco bronić przed.

Funkcja odzyskiwania po awarii geograficznej usługi Service Bus została zaprojektowana w celu ułatwienia odzyskiwania po awarii tej wielkości i porzucenia nieudanego regionu świadczenia usługi Azure na dobre i bez konieczności zmiany konfiguracji aplikacji. Porzucenie regionu platformy Azure zwykle obejmuje kilka usług, a ta funkcja ma na celu przede wszystkim ułatwienie zachowania integralności konfiguracji aplikacji złożonej. Ta funkcja jest dostępna globalnie dla jednostki SKU Usługi Service Bus Premium.

Funkcja odzyskiwania po awarii geograficznej zapewnia, że cała konfiguracja przestrzeni nazw (kolejki, tematy, subskrypcje, filtry) jest stale replikowana z podstawowej przestrzeni nazw do pomocniczej przestrzeni nazw po połączeniu i umożliwia zainicjowanie jednorazowego przejścia w tryb failover z podstawowej do pomocniczej w dowolnym momencie. Przeniesienie trybu failover ponownie wskazuje wybraną nazwę aliasu przestrzeni nazw do pomocniczej przestrzeni nazw, a następnie przerywa parowanie. Przejście w tryb failover jest niemal natychmiastowe po zainicjowaniu.

Ważne kwestie, na które należy zwrócić uwagę

  • Ta funkcja umożliwia natychmiastową ciągłość operacji z tą samą konfiguracją, ale nie replikuje komunikatów przechowywanych w kolejkach lub subskrypcjach tematów ani kolejkach utraconych komunikatów. Aby zachować semantyka kolejek, taka replikacja wymaga nie tylko replikacji danych komunikatów, ale każdej zmiany stanu w brokerze. W przypadku większości przestrzeni nazw usługi Service Bus wymagany ruch replikacji znacznie przekracza ruch aplikacji i z kolejkami o wysokiej przepływności większość komunikatów będzie nadal replikowana do pomocniczego, gdy są one już usuwane z warstwy podstawowej, powodując nadmiernie marnotrawstwo ruchu. W przypadku tras replikacji o dużym opóźnieniu, które mają zastosowanie do wielu par, które należy wybrać na potrzeby odzyskiwania po awarii geograficznej, ruch replikacji może być również niemożliwy do utrzymania utrzymania ruchu aplikacji z powodu skutków ograniczania opóźnienia.
  • Przypisania kontroli dostępu opartej na rolach (RBAC) firmy Microsoft do jednostek usługi Service Bus w podstawowej przestrzeni nazw nie są replikowane do pomocniczej przestrzeni nazw. Ręczne tworzenie przypisań ról w pomocniczej przestrzeni nazw w celu zabezpieczenia dostępu do nich.
  • Następujące konfiguracje nie są replikowane.
    • Konfiguracje sieci wirtualnej
    • Połączenia prywatnego punktu końcowego
    • Włączono dostęp do wszystkich sieci
    • Włączony dostęp do zaufanej usługi
    • Dostęp do sieci publicznej
    • Domyślna akcja sieciowa
    • Tożsamości i ustawienia szyfrowania (szyfrowanie kluczy zarządzanych przez klienta lub szyfrowanie byOK)
    • Włączanie automatycznego skalowania
    • Wyłączanie uwierzytelniania lokalnego
  • Parowanie podzielonej na partycje przestrzeni nazw z przestrzenią nazw bez partycji nie jest obsługiwane.
  • Jeśli AutoDeleteOnIdle jest włączona dla jednostki, jednostka może nie znajdować się w pomocniczej przestrzeni nazw, gdy nastąpi przejście w tryb failover. Gdy pomocniczy stanie się podstawowym ostatnim stanem dostępu, który nie jest częścią metadanych, nie będzie dostępny dla nowej jednostki podstawowej i może zostać usunięty w AutoDeleteOnIdle ramach czyszczenia.

Napiwek

Aby replikować zawartość kolejek i subskrypcji tematów oraz obsługiwać odpowiednie przestrzenie nazw w konfiguracjach aktywnych/aktywnych, aby poradzić sobie z awariami i awariami, nie opieraj się na tym zestawie funkcji odzyskiwania po awarii geograficznej, ale postępuj zgodnie ze wskazówkami dotyczącymi replikacji.

Awarie i awarie

Ważne jest, aby zauważyć rozróżnienie między "awariami" i "awariami".

Awaria to tymczasowa niedostępność usługi Azure Service Bus i może mieć wpływ na niektóre składniki usługi, takie jak magazyn komunikatów, a nawet całe centrum danych. Jednak po naprawieniu problemu usługa Service Bus stanie się ponownie dostępna. Zazwyczaj awaria nie powoduje utraty komunikatów ani innych danych. Przykładem takiej awarii może być awaria zasilania w centrum danych. Niektóre awarie to tylko krótkie straty połączeń z powodu przejściowych lub problemów z siecią.

Awaria jest definiowana jako trwała lub długoterminowa utrata klastra usługi Service Bus, regionu platformy Azure lub centrum danych. Region lub centrum danych może być ponownie dostępny lub może nie być dostępny lub może być wyłączony przez godziny lub dni. Przykłady takich katastrof to pożar, powodzie lub trzęsienie ziemi. Awaria, która stanie się trwała, może spowodować utratę niektórych komunikatów, zdarzeń lub innych danych. Jednak w większości przypadków nie powinno być żadnych utraty danych i komunikaty można odzyskać po utworzeniu kopii zapasowej centrum danych.

Funkcja odzyskiwania po awarii geograficznej usługi Azure Service Bus to rozwiązanie odzyskiwania po awarii. Pojęcia i przepływ pracy opisane w tym artykule dotyczą scenariuszy awarii, a nie przejściowych lub tymczasowych awarii. Aby zapoznać się ze szczegółowym omówieniem odzyskiwania po awarii na platformie Microsoft Azure, zobacz ten artykuł.

Podstawowe pojęcia i terminy

Funkcja odzyskiwania po awarii implementuje odzyskiwanie po awarii metadanych i opiera się na podstawowych i pomocniczych przestrzeniach nazw odzyskiwania po awarii. Funkcja odzyskiwania po awarii geograficznej jest dostępna tylko dla jednostki SKU Premium. Nie musisz wprowadzać żadnych parametry połączenia zmian, ponieważ połączenie jest wykonywane za pośrednictwem aliasu.

W tym artykule są używane następujące terminy:

  • Alias: nazwa skonfigurowanej konfiguracji odzyskiwania po awarii. Alias zapewnia jedną stabilną, w pełni kwalifikowaną nazwę domeny (FQDN) parametry połączenia. Aplikacje używają tego aliasu parametry połączenia do nawiązywania połączenia z przestrzenią nazw. Użycie aliasu gwarantuje, że parametry połączenia będzie niezmieniona po wyzwoleniu trybu failover.

  • Podstawowa/pomocnicza przestrzeń nazw: przestrzenie nazw odpowiadające aliasowi. Podstawowa przestrzeń nazw jest "aktywna" i odbiera komunikaty (może to być istniejąca lub nowa przestrzeń nazw). Pomocnicza przestrzeń nazw jest "pasywna" i nie odbiera komunikatów. Metadane między obiem są zsynchronizowane, więc obie mogą bezproblemowo akceptować komunikaty bez żadnego kodu aplikacji lub parametry połączenia zmian. Aby upewnić się, że tylko aktywna przestrzeń nazw odbiera komunikaty, należy użyć aliasu.

  • Metadane: jednostki, takie jak kolejki, tematy i subskrypcje, oraz ich właściwości usługi skojarzone z przestrzenią nazw. Tylko jednostki i ich ustawienia są replikowane automatycznie. Komunikaty nie są replikowane.

  • Tryb failover: proces aktywowania pomocniczej przestrzeni nazw.

Ustawienia

Poniższa sekcja zawiera omówienie konfigurowania parowania między przestrzeniami nazw.

Obraz przedstawiający sposób działania odzyskiwania po awarii geograficznej.

Najpierw należy utworzyć istniejącą przestrzeń nazw podstawową lub użyć nowej pomocniczej przestrzeni nazw, a następnie utworzyć parę tych dwóch. To parowanie zapewnia alias, którego można użyć do nawiązania połączenia. Ponieważ używasz aliasu, nie musisz zmieniać parametry połączenia. Do parowania trybu failover można dodać tylko nowe przestrzenie nazw.

  1. Utwórz podstawową przestrzeń nazw warstwy Premium.

  2. Utwórz dodatkową przestrzeń nazw warstwy Premium w innym regionie. To krok jest opcjonalny. Przestrzeń nazw pomocniczych można utworzyć podczas tworzenia parowania w następnym kroku.

  3. W witrynie Azure Portal przejdź do podstawowej przestrzeni nazw.

  4. Wybierz pozycję Odzyskiwanie geograficzne w menu po lewej stronie, a następnie wybierz pozycję Zainicjuj parowanie na pasku narzędzi.

    Zrzut ekranu przedstawiający stronę Odzyskiwania geograficznego z wybranym linkiem Inicjowanie parowania.

  5. Na stronie Inicjowanie parowania wykonaj następujące kroki:

    1. Wybierz istniejącą pomocniczą przestrzeń nazw lub utwórz jedną w innym regionie. W tym przykładzie istniejąca przestrzeń nazw jest używana jako pomocnicza przestrzeń nazw.

    2. W polu Alias wprowadź alias dla parowania geo-dr.

    3. Następnie wybierz przycisk Utwórz.

      Zrzut ekranu przedstawiający stronę Inicjowanie parowania w witrynie Azure Portal.

  6. Powinna zostać wyświetlona strona aliasu geo-dr usługi Service Bus, jak pokazano na poniższej ilustracji. Możesz również przejść do strony Geo-DR Alias na stronie podstawowej przestrzeni nazw, wybierając pozycję Geo-Recovery w menu po lewej stronie.

    Zrzut ekranu przedstawiający stronę aliasu geograficznego odzyskiwania po awarii usługi Service Bus z podstawowymi i pomocniczymi przestrzeniami nazw.

  7. Na stronie Alias geo-DR wybierz pozycję Zasady dostępu współdzielonego w menu po lewej stronie, aby uzyskać dostęp do parametry połączenia podstawowej dla aliasu. Użyj tej parametry połączenia zamiast bezpośrednio używać parametry połączenia do podstawowej/pomocniczej przestrzeni nazw. Początkowo alias wskazuje podstawową przestrzeń nazw.

  8. Przejdź do strony Przegląd . Możesz wykonać następujące czynności:

    1. Przerwij parowanie między podstawowymi i pomocniczymi przestrzeniami nazw. Wybierz pozycję Przerwij parowanie na pasku narzędzi.
    2. Ręczne przełączenie w tryb failover do pomocniczej przestrzeni nazw.

      1. Wybierz pozycję Tryb failover na pasku narzędzi.

      2. Upewnij się, że chcesz przejść w tryb failover do pomocniczej przestrzeni nazw, wpisując w aliasie.

      3. Włącz opcję Sejf Tryb failover, aby bezpiecznie przejść w tryb failover do pomocniczej przestrzeni nazw.

        Uwaga

        • Bezpieczny tryb failover zapewnia, że oczekujące replikacje odzyskiwania po awarii geograficznej zostały ukończone przed przełączeniem na pomocniczą. Podczas gdy wymuszone lub ręczne przejście w tryb failover nie czeka na ukończenie oczekujących replikacji przed przełączeniem do pomocniczej.
        • Obecnie bezpieczny tryb failover kończy się niepowodzeniem, jeśli podstawowe i pomocnicze przestrzenie nazw nie są w tej samej subskrypcji platformy Azure.

      4. Następnie wybierz pozycję Tryb failover.

        Zrzut ekranu przedstawiający stronę trybu failover.

        Ważne

        Przechodzenie w tryb failover aktywuje pomocniczą przestrzeń nazw i usuwa podstawową przestrzeń nazw z parowania odzyskiwania po awarii geograficznej. Utwórz inną przestrzeń nazw, aby mieć nową parę odzyskiwania po awarii geograficznej.

  9. Na koniec należy dodać pewne monitorowanie, aby wykryć, czy konieczne jest przejście w tryb failover. W większości przypadków usługa jest jedną z części dużego ekosystemu, dlatego automatyczne przechodzenie w tryb failover jest rzadko możliwe, ponieważ często tryb failover musi być wykonywany w synchronizacji z pozostałym podsystemem lub infrastrukturą.

Usługa Service Bus w warstwie Standardowa do premium

Jeśli przeprowadzono migrację przestrzeni nazw usługi Azure Service Bus w warstwie Standardowa do usługi Azure Service Bus w warstwie Premium, musisz użyć istniejącego aliasu (czyli przestrzeni nazw usługi Service Bus Standard parametry połączenia), aby utworzyć konfigurację odzyskiwania po awarii za pomocą interfejsu WIERSZA polecenia lub interfejsu API REST.

Jest to spowodowane tym, że podczas migracji standardowa przestrzeń nazw usługi Azure Service Bus parametry połączenia/DNS staje się aliasem przestrzeni nazw usługi Azure Service Bus w warstwie Premium.

Aplikacje klienckie muszą korzystać z tego aliasu (czyli standardowej przestrzeni nazw usługi Azure Service Bus parametry połączenia), aby połączyć się z przestrzenią nazw w warstwie Premium, w której skonfigurowano parowanie odzyskiwania po awarii.

Jeśli używasz witryny Azure Portal do skonfigurowania konfiguracji odzyskiwania po awarii, portal wyodrębni to zastrzeżenie.

Przepływ trybu failover

Przejście w tryb failover jest wyzwalane ręcznie przez klienta (jawnie za pomocą polecenia lub za pośrednictwem logiki biznesowej należącej do klienta, która wyzwala polecenie) i nigdy przez platformę Azure. Zapewnia to pełnej własności klienta i wgląd w rozwiązanie awarii w sieci szkieletowej platformy Azure.

Obraz przedstawiający przepływ trybu failover z podstawowej do pomocniczej przestrzeni nazw.

Po wyzwoleniu trybu failover —

  1. Alias parametry połączenia jest aktualizowany w celu wskazania pomocniczej przestrzeni nazw Premium.

  2. Klienci (nadawcy i odbiorcy) automatycznie łączą się z pomocniczą przestrzenią nazw.

  3. Istniejące parowanie między przestrzeń nazw Podstawowa i Pomocnicza w warstwie Premium jest przerwane.

Po zainicjowaniu trybu failover —

  1. Jeśli wystąpi inna awaria, chcesz ponownie przełączyć się w tryb failover. Dlatego skonfiguruj inną pasywną przestrzeń nazw i zaktualizuj parowanie.

  2. Ściąganie komunikatów z poprzedniej podstawowej przestrzeni nazw po ponownym udostępnieniu. Następnie użyj tej przestrzeni nazw do regularnego przesyłania komunikatów poza konfiguracją odzyskiwania geograficznego lub usuń starą przestrzeń nazw podstawowej.

Uwaga

Obsługiwane są tylko semantyka przekazywania dalej w trybie fail. W tym scenariuszu przełączysz się w tryb failover, a następnie ponownie połączysz nową przestrzeń nazw. Powrót po awarii nie jest obsługiwany; na przykład w klastrze SQL.

Tryb failover można zautomatyzować za pomocą systemów monitorowania lub niestandardowych rozwiązań do monitorowania. Jednak taka automatyzacja wymaga dodatkowego planowania i pracy, która jest poza zakresem tego artykułu.

Obraz przedstawiający sposób automatyzowania trybu failover.

Zarządzanie

Jeśli na przykład popełniono błąd, sparowano nieprawidłowe regiony podczas początkowej konfiguracji, możesz przerwać parowanie dwóch przestrzeni nazw w dowolnym momencie. Jeśli chcesz użyć sparowanych przestrzeni nazw jako zwykłych przestrzeni nazw, usuń alias.

Użyj istniejącej przestrzeni nazw jako aliasu

Jeśli masz scenariusz, w którym nie można zmienić połączeń producentów i użytkowników, możesz ponownie użyć nazwy przestrzeni nazw jako nazwy aliasu. Zobacz przykładowy kod w witrynie GitHub tutaj.

Przykłady

Przykłady w usłudze GitHub pokazują, jak skonfigurować i zainicjować tryb failover. Te przykłady przedstawiają następujące pojęcia:

  • Przykład platformy .NET i ustawienia, które są wymagane w usłudze Microsoft Entra ID do korzystania z usługi Azure Resource Manager z usługą Service Bus, do skonfigurowania i włączenia odzyskiwania po awarii geograficznej.
  • Kroki wymagane do wykonania przykładowego kodu.
  • Jak używać istniejącej przestrzeni nazw jako aliasu.
  • Kroki umożliwiające alternatywne włączenie odzyskiwania po awarii geograficznej za pomocą programu PowerShell lub interfejsu wiersza polecenia.
  • Wysyłaj i odbieraj z bieżącej podstawowej lub pomocniczej przestrzeni nazw przy użyciu aliasu.

Kwestie wymagające rozważenia

Zwróć uwagę na następujące zagadnienia, które należy wziąć pod uwagę w tej wersji:

  • W planowaniu trybu failover należy również wziąć pod uwagę współczynnik czasu. Jeśli na przykład utracisz łączność przez dłuższy niż 15 do 20 minut, możesz zdecydować się na zainicjowanie trybu failover.
  • Fakt, że żadne dane nie są replikowane, oznacza, że obecnie aktywne sesje nie są replikowane. Ponadto wykrywanie duplikatów i zaplanowane komunikaty mogą nie działać. Nowe sesje, nowe zaplanowane komunikaty i nowe duplikaty działają.
  • Przechodzenie w tryb failover złożonej rozproszonej infrastruktury powinno być przećwiane co najmniej raz.
  • Synchronizowanie jednostek może zająć trochę czasu— około 50–100 jednostek na minutę. Subskrypcje i reguły również są liczone jako jednostki.

Strefy dostępności

Jednostka SKU usługi Service Bus Premium obsługuje strefy dostępności, zapewniając lokalizacje izolowane od błędów w tym samym regionie świadczenia usługi Azure. Usługa Service Bus zarządza trzema kopiami magazynu obsługi komunikatów (1 podstawowy i 2 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. Jeśli aplikacje widzą przejściowe rozłączenie z usługą Service Bus, logika ponawiania próby w zestawie SDK automatycznie ponownie łączy się z usługą Service Bus.

W przypadku korzystania ze stref dostępności zarówno metadane, jak i dane (komunikaty) są replikowane w centrach danych w strefie dostępności.

Uwaga

Obsługa Strefy dostępności usługi Azure Service Bus Premium jest dostępna tylko w regionach świadczenia usługi Azure, w których znajdują się strefy dostępności.

Podczas tworzenia przestrzeni nazw warstwy Premium za pośrednictwem portalu obsługa stref dostępności (jeśli jest dostępna w wybranym regionie) jest automatycznie włączona dla przestrzeni nazw. W przypadku tworzenia przestrzeni nazw warstwy Premium za pomocą innych mechanizmów, takich jak szablony usługi ARM/Bicep, interfejs wiersza polecenia lub program PowerShell, właściwość zoneRedundant musi być jawnie ustawiona, aby true włączyć strefy dostępności (jeśli są dostępne w wybranym regionie). Nie ma dodatkowych kosztów korzystania z tej funkcji i nie można wyłączyć ani włączyć tej funkcji po utworzeniu przestrzeni nazw.

Prywatne punkty końcowe

Ta sekcja zawiera więcej zagadnień dotyczących korzystania z odzyskiwania po awarii geograficznej z przestrzeniami nazw korzystającymi z prywatnych punktów końcowych. Aby dowiedzieć się więcej o korzystaniu z prywatnych punktów końcowych z usługą Service Bus, zobacz Integrowanie usługi Azure Service Bus z usługą Azure Private Link.

Nowe pary

Jeśli spróbujesz utworzyć parowanie między podstawową przestrzenią nazw z prywatnym punktem końcowym a dodatkową przestrzenią nazw bez prywatnego punktu końcowego, parowanie zakończy się niepowodzeniem. Parowanie powiedzie się tylko wtedy, gdy zarówno podstawowe, jak i pomocnicze przestrzenie nazw mają prywatne punkty końcowe. Zalecamy używanie tych samych konfiguracji w podstawowych i pomocniczych przestrzeniach nazw oraz w sieciach wirtualnych, w których tworzone są prywatne punkty końcowe.

Uwaga

Podczas próby sparowania podstawowej przestrzeni nazw z prywatnym punktem końcowym i pomocniczym przestrzenią nazw proces weryfikacji sprawdza tylko, czy prywatny punkt końcowy istnieje w pomocniczej przestrzeni nazw. Nie sprawdza, czy punkt końcowy działa, czy działa po przejściu w tryb failover. Twoim zadaniem jest upewnienie się, że pomocnicza przestrzeń nazw z prywatnym punktem końcowym działa zgodnie z oczekiwaniami po przejściu w tryb failover.

Aby sprawdzić, czy konfiguracje prywatnego punktu końcowego są takie same, wyślij żądanie Get queues do pomocniczej przestrzeni nazw spoza sieci wirtualnej i sprawdź, czy z usługi jest wyświetlany komunikat o błędzie.

Istniejące pary

Jeśli parowanie między podstawową i pomocniczą przestrzenią nazw już istnieje, tworzenie prywatnego punktu końcowego w podstawowej przestrzeni nazw zakończy się niepowodzeniem. Aby rozwiązać ten problem, najpierw utwórz prywatny punkt końcowy w pomocniczej przestrzeni nazw, a następnie utwórz go dla podstawowej przestrzeni nazw.

Uwaga

Chociaż zezwalamy na dostęp tylko do odczytu do pomocniczej przestrzeni nazw, dozwolone są aktualizacje konfiguracji prywatnego punktu końcowego.

Podczas tworzenia konfiguracji odzyskiwania po awarii dla aplikacji i usługi Service Bus należy utworzyć prywatne punkty końcowe dla podstawowych i pomocniczych przestrzeni nazw usługi Service Bus dla sieci wirtualnych hostowania zarówno wystąpień podstawowych, jak i pomocniczych aplikacji.

Załóżmy, że masz dwie sieci wirtualne: VNET-1, VNET-2 i te podstawowe i pomocnicze przestrzenie nazw: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. Należy wykonać następujące czynności:

  • W programie ServiceBus-Namespace1-Primaryutwórz dwa prywatne punkty końcowe korzystające z podsieci z sieci VNET-1 i VNET-2
  • W programie ServiceBus-Namespace2-Secondaryutwórz dwa prywatne punkty końcowe, które używają tych samych podsieci z sieci VNET-1 i VNET-2

Prywatne punkty końcowe i sieci wirtualne

Zaletą tego podejścia jest to, że przejście w tryb failover może nastąpić w warstwie aplikacji niezależnie od przestrzeni nazw usługi Service Bus. Rozważ następujące scenariusze:

Tryb failover tylko dla aplikacji: w tym miejscu aplikacja nie istnieje w sieci wirtualnej VNET-1, ale przechodzi do sieci wirtualnej VNET-2. Ponieważ oba prywatne punkty końcowe są konfigurowane zarówno w sieci wirtualnej VNET-1, jak i VNET-2 dla podstawowych i pomocniczych przestrzeni nazw, aplikacja działa tylko.

Tryb failover tylko dla przestrzeni nazw usługi Service Bus: tutaj ponownie, ponieważ oba prywatne punkty końcowe są konfigurowane w obu sieciach wirtualnych zarówno dla podstawowych, jak i pomocniczych przestrzeni nazw, aplikacja po prostu działa.

Uwaga

Aby uzyskać wskazówki dotyczące odzyskiwania po awarii geograficznej sieci wirtualnej, zobacz Virtual Network — Business Continuity (Sieć wirtualna — ciągłość działania).

Kontrola dostępu oparta na rolach

Przypisania kontroli dostępu opartej na rolach (RBAC) firmy Microsoft do jednostek usługi Service Bus w podstawowej przestrzeni nazw nie są replikowane do pomocniczej przestrzeni nazw. Ręczne tworzenie przypisań ról w pomocniczej przestrzeni nazw w celu zabezpieczenia dostępu do nich.

Następne kroki

Aby dowiedzieć się więcej o komunikatach usługi Service Bus, zobacz następujące artykuły: