Azure Event Hubs — odzyskiwanie po awarii geograficznej

  • 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 Event Hubs już rozprzestrzenia ryzyko katastrofanych awarii poszczególnych maszyn, a nawet kompletnych stojaków w klastrach obejmujących wiele domen awarii w centrum danych. Implementuje ona przejrzyste mechanizmy wykrywania błędów i trybu failover, takie jak to, że usługa będzie nadal działać w ramach zapewnianych poziomów usług i zwykle bez zauważalnych przerw w przypadku takich awarii. Jeśli tworzysz przestrzeń nazw usługi Event Hubs z włączonymi strefami dostępności, zmniejszysz ryzyko awarii i włączysz wysoką dostępność. W przypadku stref dostępności ryzyko awarii jest dodatkowo rozłożone na trzy fizycznie oddzielone obiekty, a usługa ma wystarczającą ilość rezerw pojemności, aby natychmiast poradzić sobie z pełną, katastrofalną utratą całego obiektu.

Model klastra usługi Azure Event Hubs z obsługą strefy dostępności zapewnia odporność 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 Event Hubs została zaprojektowana tak, aby ułatwić odzyskiwanie po awarii tej wielkości i porzucenie nieudanego regionu świadczenia usługi Azure na dobre i bez konieczności zmiany konfiguracji aplikacji. Porzucenie regionu platformy Azure zwykle wiąże się z kilkoma usługami, a ta funkcja ma na celu przede wszystkim ułatwienie zachowania integralności konfiguracji aplikacji złożonej.

Funkcja odzyskiwania po awarii geograficznej zapewnia, że cała konfiguracja przestrzeni nazw (event hubs, grupy odbiorców i ustawienia) 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 spowoduje ponowne wskazanie wybranej nazwy aliasu przestrzeni nazw do pomocniczej przestrzeni nazw, a następnie przerwanie parowania. Przejście w tryb failover jest niemal natychmiastowe po zainicjowaniu.

Ważne

  • Ta funkcja umożliwia natychmiastową ciągłość operacji z tą samą konfiguracją, ale nie replikuje danych zdarzenia. Jeśli awaria nie spowodowała utraty wszystkich stref, dane zdarzenia zachowane w podstawowym centrum zdarzeń po przejściu w tryb failover będą możliwe do odzyskania, a zdarzenia historyczne można uzyskać z tego miejsca po przywróceniu dostępu. W przypadku replikowania danych zdarzeń i obsługi odpowiednich przestrzeni nazw w konfiguracjach aktywnych/aktywnych w celu radzenia sobie z awariami i awariami nie należy polegać na tym zestawie funkcji odzyskiwania po awarii geograficznej, ale postępuj zgodnie ze wskazówkami dotyczącymi replikacji.
  • Przypisania kontroli dostępu opartej na rolach (RBAC) firmy Microsoft do jednostek 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.

Awarie i awarie

Ważne jest, aby zauważyć rozróżnienie między "awariami" i "awariami". Awaria to tymczasowa niedostępność usługi Azure Event Hubs 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 Event Hubs zostanie ponownie udostępniona. 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 Event Hubs, 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 Event Hubs 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 standardowych, premium i dedykowanych jednostek SKU. 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.

  • 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 centra zdarzeń i grupy odbiorców, oraz ich właściwości usługi skojarzone z przestrzenią nazw. Tylko jednostki i ich ustawienia są replikowane automatycznie. Komunikaty i zdarzenia nie są replikowane.

  • Tryb failover: proces aktywowania pomocniczej przestrzeni nazw.

Obsługiwane pary przestrzeni nazw

Obsługiwane są następujące kombinacje podstawowych i pomocniczych przestrzeni nazw:

Podstawowa warstwa przestrzeni nazw Dozwolona dodatkowa warstwa przestrzeni nazw
Standardowy Standardowa, Dedykowana
Premium Premium
Dedykowane Dedykowane

Uwaga

Nie można sparować przestrzeni nazw, które znajdują się w tym samym dedykowanym klastrze. Przestrzenie nazw, które znajdują się w oddzielnych klastrach, można sparować.

Konfigurowanie i przepływ trybu failover

W poniższej sekcji omówiono proces pracy w trybie failover i wyjaśniono, jak skonfigurować początkowy tryb failover.

Image showing the overview of failover process

Instalacja

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.

  2. Utwórz pomocniczą przestrzeń nazw 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.

    Initiate pairing from the primary namespace

  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 wybrano istniejącą przestrzeń nazw.
    2. W polu Alias wprowadź alias dla parowania geo-dr.
    3. Następnie wybierz przycisk Utwórz.

    Select the secondary namespace

  6. Powinna zostać wyświetlona strona Alias geo-DR . Możesz również przejść do tej strony z podstawowej przestrzeni nazw, wybierając pozycję Odzyskiwanie geograficzne w menu po lewej stronie.

    Geo-DR alias page

  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.

  8. Na tej stronie Przegląd można 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. Wybierz pozycję Tryb failover na pasku narzędzi.

      Ostrzeżenie

      Przełączenie w tryb failover spowoduje aktywowanie pomocniczej przestrzeni nazw i usunięcie podstawowej przestrzeni nazw z parowania odzyskiwania po awarii geograficznej. Utwórz inną przestrzeń nazw, aby mieć nową parę odzyskiwania po awarii geograficznej.

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

Przykład

W jednym przykładzie tego scenariusza rozważ rozwiązanie punkt sprzedaży (POS), które emituje komunikaty lub zdarzenia. Usługa Event Hubs przekazuje te zdarzenia do rozwiązania mapowania lub ponownego formatowania, które następnie przekazuje zamapowane dane do innego systemu w celu dalszego przetwarzania. W tym momencie wszystkie te systemy mogą być hostowane w tym samym regionie świadczenia usługi Azure. Decyzja o tym, kiedy i jaka część przejścia w tryb failover zależy od przepływu danych w infrastrukturze.

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.

Przepływ trybu failover

W przypadku zainicjowania trybu failover wymagane są dwa kroki:

  1. Jeśli wystąpi inna awaria, chcesz ponownie przełączyć się w tryb failover. W związku z tym 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.

Image showing the failover flow

Ręczne przełączenie w tryb failover

W tej sekcji pokazano, jak ręcznie przejść w tryb failover przy użyciu witryny Azure Portal, interfejsu wiersza polecenia, programu PowerShell, języka C#itp.

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

  2. Wybierz pozycję Odzyskiwanie geograficzne w menu po lewej stronie.

  3. Ręczne przełączenie w tryb failover do pomocniczej przestrzeni nazw. Wybierz pozycję Tryb failover na pasku narzędzi.

    Ostrzeżenie

    Przełączenie w tryb failover spowoduje aktywowanie pomocniczej przestrzeni nazw i usunięcie podstawowej przestrzeni nazw z parowania odzyskiwania po awarii geograficznej. Utwórz inną przestrzeń nazw, aby mieć nową parę odzyskiwania po awarii geograficznej.

Zarządzanie

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

Kwestie wymagające rozważenia

Należy pamiętać o następujących kwestiach:

  1. Zgodnie z projektem odzyskiwanie po awarii geograficznej usługi Event Hubs nie replikuje danych i dlatego nie można ponownie użyć starej wartości przesunięcia podstawowego centrum zdarzeń w pomocniczym centrum zdarzeń. Zalecamy ponowne uruchomienie odbiornika zdarzeń przy użyciu jednej z następujących metod:

    • EventPosition.FromStart() — jeśli chcesz odczytać wszystkie dane w pomocniczym centrum zdarzeń.
    • EventPosition.FromEnd() — jeśli chcesz odczytać wszystkie nowe dane od czasu połączenia z pomocniczym centrum zdarzeń.
    • EventPosition.FromEnqueuedTime(dateTime) — jeśli chcesz odczytać wszystkie dane odebrane w pomocniczym centrum zdarzeń, począwszy od danej daty i godziny.

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

  3. Fakt, że żadne dane nie są replikowane, oznacza, że bieżące aktywne sesje nie są replikowane. Ponadto wykrywanie duplikatów i zaplanowane komunikaty mogą nie działać. Nowe sesje, zaplanowane komunikaty i nowe duplikaty będą działać.

  4. Przechodzenie w tryb failover złożonej rozproszonej infrastruktury powinno być przećwiane co najmniej raz.

  5. Synchronizowanie jednostek może zająć trochę czasu— około 50–100 jednostek na minutę.

  6. Niektóre aspekty płaszczyzny zarządzania dla pomocniczej przestrzeni nazw stają się tylko do odczytu, podczas gdy parowanie odzyskiwania geograficznego jest aktywne.

  7. Płaszczyzna danych pomocniczej przestrzeni nazw będzie tylko do odczytu, a parowanie odzyskiwania geograficznego jest aktywne. Płaszczyzna danych pomocniczej przestrzeni nazw będzie akceptować żądania GET, aby umożliwić walidację łączności klienta i kontroli dostępu.

Strefy dostępności

Usługa Event Hubs obsługuje Strefy dostępności, zapewniając izolowane błędy lokalizacje w regionie świadczenia usługi Azure. Obsługa Strefy dostępności jest dostępna tylko w regionach świadczenia usługi Azure ze strefami dostępności. Metadane i dane (zdarzenia) są replikowane w centrach danych w strefie dostępności.

Podczas tworzenia przestrzeni nazw podczas wybierania regionu ze strefami dostępności zobaczysz następujący wyróżniony komunikat.

Image showing the Create Namespace page with region that has availability zones

Uwaga

W przypadku korzystania z witryny Azure Portal nadmiarowość strefy za pośrednictwem obsługi stref dostępności jest automatycznie włączona. Nie można go wyłączyć w portalu. Możesz użyć polecenia interfejsu wiersza polecenia az eventhubs namespace platformy Azure z --zone-redundant=false poleceniem programu PowerShell New-AzEventHubNamespace z poleceniem -ZoneRedundant=false , aby utworzyć przestrzeń nazw z wyłączoną nadmiarowością strefy.

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 na temat używania prywatnych punktów końcowych z usługą Event Hubs, zobacz Konfigurowanie prywatnych punktów końcowych.

Nowe pary

Jeśli spróbujesz utworzyć parowanie między podstawową przestrzenią nazw z prywatnym punktem końcowym i pomocniczym 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 sprawdzania poprawności 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 będzie działać zgodnie z oczekiwaniami po przejściu w tryb failover.

Aby sprawdzić, czy konfiguracje prywatnego punktu końcowego są takie same w podstawowych i pomocniczych przestrzeniach nazw, wyślij żądanie odczytu (na przykład: Pobierz centrum zdarzeń) 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 przestrzeni nazw usługi Event Hubs należy utworzyć prywatne punkty końcowe dla podstawowych i pomocniczych przestrzeni nazw usługi Event Hubs 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: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Należy wykonać następujące czynności:

  • W usłudze EventHubs-Namespace1-Primary utwórz dwa prywatne punkty końcowe używające podsieci z sieci wirtualnej VNET-1 i VNET-2
  • W usłudze EventHubs-Namespace2-Secondary utwórz dwa prywatne punkty końcowe, które używają tych samych podsieci z sieci VNET-1 i VNET-2

Private endpoints and virtual networks

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 Event Hubs. Rozważ następujące scenariusze:

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

Tryb failover tylko w przestrzeni nazw usługi Event Hubs: w tym miejscu ponownie, ponieważ oba prywatne punkty końcowe są konfigurowane w obu sieciach wirtualnych zarówno dla podstawowych, jak i pomocniczych przestrzeni nazw, aplikacja będzie 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 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

Zapoznaj się z poniższymi przykładami lub dokumentacją referencyjną.