Odzyskiwanie po awarii geograficznej usługi Azure Service Bus

Funkcja odzyskiwania po awarii geograficznej usługi Service Bus jest jedną z opcji izolowania aplikacji usługi Azure Service Bus przed awariami i awariami, a przede wszystkim ma na celu ułatwienie zachowania integralności konfiguracji aplikacji złożonej.

Uwaga

Ta funkcja jest dostępna dla warstwy Premium usługi Azure Service Bus.

Funkcja odzyskiwania po awarii geograficznej zapewnia, że cała konfiguracja przestrzeni nazw (jednostki, konfiguracja, właściwości) jest stale replikowana z podstawowej przestrzeni nazw do pomocniczej przestrzeni nazw, z którą jest sparowana, 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 brokera, która jest oferowana w funkcji replikacji geograficznej (publiczna wersja zapoznawcza).
• 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
  • Subskrypcje usługi Azure Event Grid
• 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 pomocnicza stanie się podstawowa, stan ostatniego 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 ramach AutoDeleteOnIdle oczyszczania.

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 skorzystaj z funkcji Replikacja geograficzna lub postępuj zgodnie ze wskazówkami dotyczącymi replikacji.

Podstawowe pojęcia i terminy

Funkcja odzyskiwania po awarii geograficznej 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 warstwy 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.

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.

   

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 odzyskiwania po awarii geograficznej.

   3. Następnie wybierz przycisk Utwórz.

      

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.

   

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ę Bezpieczny 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 do pomocniczego. Alternatywnie wymuszone lub ręczne przejście w tryb failover nie czeka na ukończenie oczekujących replikacji przed przełączeniem do pomocniczej wersji.
         • 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.

         

         Ważne

         Przechodzenie w tryb failover aktywuje pomocniczą przestrzeń nazw i usuwa przestrzeń nazw podstawowej 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.

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 kolejną pomocniczą 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 po awarii geograficznej 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.

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 wymagane w usłudze Microsoft Entra ID do używania 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.

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.

Zalecana konfiguracja

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

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

• Zobacz dokumentację interfejsu API REST odzyskiwania po awarii geograficznej tutaj.
• Uruchom przykład odzyskiwania po awarii geograficznej w usłudze GitHub.
• Zobacz przykład Geo-Disaster Recovery , który wysyła komunikaty do aliasu.

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

• Kolejki, tematy i subskrypcje usługi Service Bus
• Wprowadzenie do kolejek usługi Service Bus
• Jak używać tematów i subskrypcji usługi Service Bus
• Interfejs API REST