Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące izolowania aplikacji od wyłączeń i awarii usługi Service Bus

  • Artykuł

Aplikacje o znaczeniu krytycznym muszą działać w sposób ciągły, nawet w obecności nieplanowanych awarii lub awarii. 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. W tym artykule opisano techniki, których można użyć do ochrony aplikacji usługi Service Bus przed potencjalną awarią lub awarią usługi.

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.

Ponadto 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.

Funkcje odzyskiwania geograficznego i replikacji geograficznej usługi Service Bus zostały zaprojektowane tak, aby ułatwić odzyskiwanie po awarii tej wielkości i porzucenie nieudanych regionów świadczenia usługi Azure na dobre i bez konieczności zmieniania konfiguracji aplikacji.

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 awarii składnika jest niedostępność określonego magazynu komunikatów. Przykładem awarii całego centrum danych jest awaria zasilania centrum danych lub wadliwy przełącznik sieci centrum danych. Awaria może trwać od kilku minut do kilku dni. 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.

Ochrona przed awariami i awariami

Istnieją dwie funkcje, które zapewniają odzyskiwanie po awarii geograficznej w usłudze Azure Service Bus dla warstwy Premium. Najpierw istnieje funkcja odzyskiwania po awarii geograficznej (Metadata DR) zapewniająca replikację metadanych (jednostki, konfiguracja, właściwości). Po drugie, istnieje replikacja geograficzna, która jest obecnie w publicznej wersji zapoznawczej, zapewniając replikację zarówno metadanych, jak i danych (dane komunikatu i właściwość komunikatu / zmiany stanu). Żadna funkcja odzyskiwania po awarii geograficznej nie powinna być mylona z Strefy dostępności. Niezależnie od tego, czy jest to replikacja metadanych, czy replikacja geograficzna, obie funkcje odzyskiwania grafiki geograficznej zapewniają odporność między regionami świadczenia usługi Azure, takimi jak Wschodnie stany USA i Zachodnie stany USA.

Strefy dostępności są dostępne we wszystkich warstwach usługi Service Bus, a obsługa zapewnia odporność w określonym regionie geograficznym, takim jak Wschodnie stany USA. Aby zapoznać się ze szczegółowym omówieniem odzyskiwania po awarii na platformie Microsoft Azure, zobacz ten artykuł.

Pojęcia dotyczące wysokiej dostępności i odzyskiwania po awarii są wbudowane bezpośrednio w warstwę Premium usługi Azure Service Bus, zarówno w tym samym regionie (za pośrednictwem stref dostępności), jak i w różnych regionach (za pośrednictwem odzyskiwania po awarii geograficznej i replikacji geograficznej).

Opcje odzyskiwania po awarii geograficznej

Odzyskiwanie po awarii geograficznej

Warstwa Premium usługi Service Bus obsługuje odzyskiwanie po awarii geograficznej na poziomie przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Geo-Disaster Recovery usługi Azure Service Bus. Funkcja odzyskiwania po awarii geograficznej , dostępna tylko dla warstwy Premium, implementuje odzyskiwanie po awarii metadanych i opiera się na podstawowych i pomocniczych przestrzeniach nazw. W przypadku odzyskiwania po awarii geograficznej tylko metadane jednostek są replikowane między podstawowymi i pomocniczymi przestrzeniami nazw.

Replikacja geograficzna

Warstwa Premium usługi Service Bus obsługuje również replikację geograficzną na poziomie przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna usługi Azure Service Bus (publiczna wersja zapoznawcza). Funkcja replikacji geograficznej, dostępna tylko dla warstwy Premium i obecnie w publicznej wersji zapoznawczej, implementuje metadane i odzyskiwanie po awarii danych oraz opiera się na regionach podstawowych i pomocniczych. W przypadku replikacji geograficznej zarówno metadane, jak i dane jednostek są replikowane między regionami podstawowymi i pomocniczymi.

Ogólne różnice między funkcjami

Funkcja odzyskiwania po awarii geograficznej (Metadata DR) replikuje metadane przestrzeni nazw z podstawowej przestrzeni nazw do pomocniczej przestrzeni nazw. Obsługuje jednorazowy tryb failover tylko w regionie pomocniczym. Podczas przełączania klienta w tryb failover nazwa aliasu przestrzeni nazw jest ponownie określana w pomocniczej przestrzeni nazw, a następnie parowanie zostanie przerwane. Żadne dane nie są replikowane poza metadanymi ani nie są replikowane przypisania kontroli dostępu opartej na rolach.

Funkcja replikacji geograficznej replikuje metadane i wszystkie dane z regionu podstawowego do co najmniej jednego regionu pomocniczego. Po przejściu w tryb failover przez klienta wybrany pomocniczy staje się podstawowym, a poprzednia podstawowa staje się pomocnicza. Użytkownicy mogą w razie potrzeby wykonać powrót w tryb failover do oryginalnego podstawowego obiektu podstawowego.

Strefy dostępności

Wszystkie warstwy usługi Service Bus obsługują strefy dostępności, zapewniając lokalizacje odizolowane 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łączenia z usługą Service Bus, logika ponawiania próby w zestawie SDK automatycznie ponownie nawiązuje połączenie 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 stref dostępności jest dostępna tylko w regionach świadczenia usługi Azure, w których znajdują się strefy dostępności.

Podczas tworzenia przestrzeni nazw obsługa stref dostępności (jeśli jest dostępna w wybranym regionie) jest automatycznie włączona dla przestrzeni nazw. Nie ma dodatkowych kosztów korzystania z tej funkcji i nie można wyłączyć ani włączyć tej funkcji po utworzeniu przestrzeni nazw.

Uwaga

Wcześniej było wymagane ustawienie właściwości zoneRedundant w celu true włączenia stref dostępności, jednak to zachowanie zostało zmienione w celu włączenia stref dostępności domyślnie. Istniejące przestrzenie nazw są również migrowane do stref dostępności, a właściwość zoneRedundant jest przestarzała. Właściwość zoneRedundant może nadal być wyświetlana jako false, nawet jeśli strefy dostępności zostały włączone.

Ochrona przed awariami — warstwa Standardowa

Aby osiągnąć odporność na awarie w warstwie Standardowa usługi Service Bus, można użyć replikacji aktywnej lub pasywnej . W przypadku każdego podejścia, jeśli dana kolejka lub temat musi pozostać dostępna w obecności awarii centrum danych, możesz utworzyć ją w obu przestrzeniach nazw. Obie jednostki mogą mieć taką samą nazwę. Na przykład w contosoPrimary.servicebus.windows.net/myQueue można uzyskać dostęp do kolejki podstawowej, a jej pomocniczy odpowiednik można uzyskać w contosoSecondary.servicebus.windows.net/myQueue.

Uwaga

Aktywna replikacja i konfiguracja replikacji pasywnej są rozwiązaniami ogólnego przeznaczenia, a nie specyficznymi funkcjami usługi Service Bus. Logika replikacji (wysyłanie do 2 różnych przestrzeni nazw) znajduje się w aplikacjach nadawcy, a odbiorca musi mieć niestandardową logikę wykrywania duplikatów.

Jeśli aplikacja nie wymaga stałej komunikacji nadawcy z odbiornikiem, aplikacja może zaimplementować trwałą kolejkę po stronie klienta, aby zapobiec utracie komunikatów i chronić nadawcę przed przejściowymi błędami usługi Service Bus.

Aktywna replikacja

Aktywna replikacja używa jednostek w obu przestrzeniach nazw dla każdej operacji. Każdy klient, który wysyła komunikat, wysyła dwie kopie tego samego komunikatu. Pierwsza kopia jest wysyłana do jednostki podstawowej (na przykład contosoPrimary.servicebus.windows.net/sales), a druga kopia komunikatu jest wysyłana do jednostki pomocniczej (na przykład contosoSecondary.servicebus.windows.net/sales).

Klient odbiera komunikaty z obu kolejek. Odbiorca przetwarza pierwszą kopię komunikatu, a druga kopia jest pomijana. Aby pominąć zduplikowane komunikaty, nadawca musi oznaczyć każdy komunikat unikatowym identyfikatorem. Obie kopie wiadomości muszą być oznaczone tym samym identyfikatorem. Możesz użyć właściwości ServiceBusMessage.MessageId lub ServiceBusMessage.Subject lub właściwości niestandardowej, aby oznaczyć komunikat. Odbiorca musi obsługiwać listę komunikatów, które zostały już odebrane.

Uwaga

Podejście aktywnej replikacji podwoi liczbę operacji, dlatego takie podejście może prowadzić do wyższych kosztów.

Replikacja pasywna

W przypadku bez błędów replikacja pasywna używa tylko jednej z dwóch jednostek obsługi komunikatów. Klient wysyła komunikat do aktywnej jednostki. Jeśli operacja w aktywnej jednostce zakończy się niepowodzeniem z kodem błędu wskazującym centrum danych hostujące aktywną jednostkę, klient wysyła kopię komunikatu do jednostki kopii zapasowej. W tym momencie aktywne i jednostki kopii zapasowej przełączają role. Klient wysyłający uważa, że stara aktywna jednostka jest nową jednostką kopii zapasowej, a stara jednostka kopii zapasowej jest nową aktywną jednostką. Jeśli obie operacje wysyłania nie powiedzą się, role dwóch jednostek pozostaną niezmienione i zostanie zwrócony błąd.

Klient odbiera komunikaty z obu kolejek. Ponieważ istnieje prawdopodobieństwo, że odbiorca otrzyma dwie kopie tego samego komunikatu, odbiorca musi pominąć zduplikowane komunikaty. Duplikaty można pominąć w taki sam sposób, jak opisano w przypadku aktywnej replikacji.

Ogólnie rzecz biorąc, replikacja pasywna jest bardziej ekonomiczna niż aktywna replikacja, ponieważ w większości przypadków jest wykonywana tylko jedna operacja. Opóźnienie, przepływność i koszt pieniężny są identyczne ze scenariuszem niereplikowanym.

W przypadku korzystania z replikacji pasywnej w następujących scenariuszach komunikaty mogą zostać utracone lub odebrane dwa razy:

  • Opóźnienie lub utrata komunikatów: załóżmy, że nadawca pomyślnie wysłał komunikat m1 do kolejki podstawowej, a następnie kolejka stanie się niedostępna, zanim odbiorca otrzyma m1. Nadawca wysyła kolejny komunikat m2 do kolejki pomocniczej. Jeśli kolejka podstawowa jest tymczasowo niedostępna, odbiorca otrzyma m1 po ponownym udostępnieniu kolejki. W przypadku awarii odbiornik nigdy nie może otrzymać m1.
  • Zduplikowany odbiór: załóżmy, że nadawca wysyła komunikat m do kolejki podstawowej. Usługa Service Bus pomyślnie przetwarza m, ale nie może wysłać odpowiedzi. Po przekroczeniu limitu czasu operacji wysyłania nadawca wysyła identyczną kopię m do kolejki pomocniczej. Jeśli odbiornik może odbierać pierwszą kopię m, zanim kolejka podstawowa stanie się niedostępna, odbiorca otrzymuje obie kopie m w przybliżeniu w tym samym czasie. Jeśli odbiornik nie może odebrać pierwszej kopii m, zanim kolejka podstawowa stanie się niedostępna, odbiorca początkowo odbiera tylko drugą kopię m, ale otrzymuje drugą kopię m, gdy kolejka podstawowa stanie się dostępna.

W przykładzie Zadania replikacji usługi Azure Messaging przy użyciu platformy .NET Core przedstawiono replikację komunikatów między przestrzeniami nazw.

Następne kroki

Aby dowiedzieć się więcej na temat odzyskiwania po awarii, zobacz następujące artykuły: