Niezawodność w usłudze Azure Event Hubs

Azure Event Hubs to natywna usługa w chmurze, która może przesyłać strumieniowo miliony zdarzeń na sekundę z małym opóźnieniem z dowolnego źródła do dowolnego miejsca docelowego. Usługa Event Hubs umożliwia pozyskiwanie i przechowywanie danych przesyłanych strumieniowo oraz integrowanie z aplikacjami klienckimi utworzonymi na potrzeby platformy Apache Kafka lub aplikacji korzystających z zestawów SDK klienta usługi Event Hubs.

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 sposobu działania tych możliwości we wszystkich używanych usługach oraz wybór możliwości potrzebnych do osiągnięcia twoich celów biznesowych i celów dostępności.

W tym artykule opisano, jak usługa Event Hubs jest odporna na różne potencjalne awarie i problemy oraz jak można ją skonfigurować, aby była odporna na inne rodzaje awarii, w tym błędy przejściowe, awarie stref dostępności i awarie regionów. Opisuje również opcje tworzenia kopii zapasowych i odzyskiwania oraz wyróżnia niektóre kluczowe informacje o umowie dotyczącej poziomu usług (SLA) usługi Azure Event Hubs.

Zalecenia dotyczące wdrażania produkcyjnego

Aby dowiedzieć się, jak wdrożyć usługę Event Hubs, aby obsługiwać wymagania dotyczące niezawodności rozwiązania i zrozumieć, jak niezawodność wpływa na inne aspekty architektury, zobacz Artykuł Architecture best practices for Event Hubs in the Azure Well-Architected Framework (Najlepsze rozwiązania dotyczące architektury dla usługi Event Hubs w strukturze Azure Well-Architected Framework).

Omówienie architektury niezawodności

W tej sekcji opisano ważne aspekty działania usługi Event Hubs z perspektywy niezawodności. Wprowadza on architekturę logiczną, która obejmuje zasoby i funkcje wdrażane i używane. Wyjaśniono również architekturę fizyczną, która zawiera szczegółowe informacje o sposobie wewnętrznego zarządzania operacjami przez usługę.

Architektura logiczna

Przestrzeń nazw usługi Event Hubs służy jako kontener zarządzania dla co najmniej jednego centrum zdarzeń. Konfigurujesz usługę poprzez takie czynności, jak alokacja pojemności przesyłania strumieniowego, konfiguracja zabezpieczeń sieci oraz włączenie odporności geograficznej i odzyskiwania po awarii na poziomie przestrzeni nazw.

W przestrzeni nazw można organizować zdarzenia w centrum zdarzeń. Ekosystem platformy Apache® Kafka odnosi się do tego typu jednostki jako tematu. Centrum zdarzeń lub temat to rozproszony dziennik zdarzeń wyłącznie do dołączania.

Każde centrum zdarzeń zawiera co najmniej jedną partycję, która jest dziennikami zdarzeń sekwencyjnych. Centrum zdarzeń może używać wielu partycji do przetwarzania równoległego i skalowania w poziomie. Event Hubs gwarantuje kolejność tylko w obrębie 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ą. Aby zmaksymalizować czas pracy większości aplikacji, unikaj adresowania partycji bezpośrednio z aplikacji klienckich. Aby uzyskać więcej informacji, zobacz Dostępność i spójność w usłudze Event Hubs.

Użytkownicy odczytujący z centrum zdarzeń mogą sekwencyjnie odczytywać swoje zdarzenia, utrzymując własny punkt kontrolny, który identyfikuje ostatnie zdarzenie, które otrzymuje.

Aby uzyskać więcej informacji na temat partycji i innych podstawowych pojęć w usłudze Event Hubs, zobacz Funkcje i terminologia w usłudze Event Hubs.

Architektura fizyczna

W architekturze fizycznej przestrzeń nazw usługi Event Hubs jest uruchamiana w klastrze. Klaster udostępnia bazowe zasoby obliczeniowe i magazynowe. Większość przestrzeni nazw działa w klastrach udostępnianych przez innych klientów platformy Azure. W przypadku korzystania z warstwy Premium przestrzeń nazw jest przydzielana dedykowanym zasobom w udostępnionym klastrze. W przypadku korzystania z dedykowanego poziomu, klaster jest przypisany do przestrzeni nazw. Aby uzyskać więcej informacji na temat dedykowanych klastrów, zobacz Omówienie dedykowanej warstwy usługi Event Hubs. Niezależnie od warstwy i typu klastra firma Microsoft zarządza klastrami i ich podstawowymi maszynami wirtualnymi i magazynem.

Aby uzyskać nadmiarowość, każdy klaster ma wiele replik, które przetwarzają żądania odczytu i zapisu. W celu zapewnienia wysokiej dostępności i optymalizacji wydajności wszystkie dane są przechowywane w trzech replikach pamięci masowej. Aby skalować zasoby obliczeniowe przestrzeni nazw, zaimplementuj jednostki przepływności (TUs), jednostki przetwarzania (PUs) lub jednostki pojemności (CUs), w zależności od warstwy. Aby uzyskać więcej informacji, zobacz Scaling with Event Hubs (Skalowanie za pomocą usługi Event Hubs).

Klastry obejmują wiele fizycznych maszyn i stojaków, co zmniejsza ryzyko katastrofalnych awarii wpływających na przestrzeń nazw. W regionach, w których znajdują się strefy dostępności, klastry rozszerzają się na oddzielne fizyczne centra danych. Aby uzyskać więcej informacji, zobacz Odporność na błędy strefy dostępności.

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.

Usługa Event Hubs implementuje przezroczyste mechanizmy wykrywania błędów i trybu failover, dzięki czemu usługa nadal działa w ramach zapewnianych poziomów usług, zwykle bez zauważalnych przerw w działaniu w przypadku wystąpienia awarii.

Podczas projektowania aplikacji klienckich do pracy z usługą Event Hubs postępuj zgodnie z następującymi wskazówkami:

• Użyj wbudowanych zasad ponawiania prób. Zestawy SDK usługi Event Hubs i platformy Apache Kafka automatycznie ponawiają operacje w przypadku błędów, które można ponowić, takich jak przekroczenia limitu czasu sieci, ograniczenia przepustowości lub gdy serwer jest zajęty. Aby uniknąć niepotrzebnego przeciążenia usługi, domyślnie implementują wycofywanie wykładnicze.

• Skonfiguruj odpowiednie wartości limitu czasu na podstawie wymagań aplikacji. Domyślny limit czasu wynosi zazwyczaj 60 sekund, ale można go dostosować na podstawie scenariusza.

• Zaimplementuj tworzenie punktów kontrolnych w procesorze zdarzeń, aby śledzić postęp i umożliwiać odzyskiwanie z ostatniej przetworzonej pozycji po przejściowych awariach.

• Używanie pakietów danych podczas operacji wysyłania pozwala na zwiększenie przepustowości oraz zmniejszenie wpływu przejściowych problemów z siecią na poszczególne komunikaty.

• Jeśli pracujesz z protokołem Kafka, użyj zestawów SDK platformy Apache Kafka. Zestawy SDK platformy Kafka implementują również zasady ponawiania prób i inne najlepsze rozwiązania, które ułatwiają obsługę błędów przejściowych.

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 Event Hubs obsługuje wdrożenia z strefową redundancją we wszystkich poziomach usług. Podczas tworzenia przestrzeni nazw usługi Event Hubs w obsługiwanym regionie nadmiarowość strefy jest automatycznie włączana bez dodatkowych kosztów. Jednak w przypadku warstwy Dedykowane strefy dostępności są obsługiwane tylko przy co najmniej trzech jednostkach CU. Model wdrażania strefowo nadmiarowego dotyczy wszystkich funkcji usługi Event Hubs, w tym obsługi protokołu Capture, Schema Registry i Kafka.

Usługa Event Hubs replikuje konfigurację, metadane oraz dane dotyczące zdarzeń w sposób przejrzysty i spójny w trzech 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 Event Hubs, w tym obliczenia, sieć i magazyn, są replikowane między strefami. Usługa Event Hubs ma wystarczające rezerwy pojemności, aby natychmiast poradzić sobie z całkowitą utratą obszaru. Nawet jeśli cała strefa dostępności stanie się niedostępna, usługa Event Hubs nadal działa bez utraty danych lub zakłóceń w przesyłaniu strumieniowego aplikacji.

Obsługa regionów

Strefowo redundantne przestrzenie nazw Event Hubs można wdrożyć w dowolnym regionie Azure, który obsługuje strefy dostępności.

Requirements

• Warstwy Standardowa i Premium obsługują strefy dostępności bez konieczności dodatkowej konfiguracji.

• W przypadku warstwy Dedykowane strefy dostępności wymagają co najmniej trzech jednostek obliczeniowych.

Koszt

Redundantność strefowa w usłudze Event Hubs nie powoduje dodatkowych kosztów.

Konfiguruj obsługę stref dostępności

Przestrzenie nazw Event Hubs automatycznie obsługują nadmiarowość stref po wdrożeniu w obsługiwanych regionach. Nie trzeba konfigurować niczego więcej.

Zachowanie, gdy wszystkie strefy są w dobrej kondycji

Gdy przestrzenie nazw usługi Event Hubs używają nadmiarowości strefowej, a wszystkie strefy dostępności działają normalnie, można spodziewać się następującego działania:

• Routing ruchu między strefami: Usługa Event Hubs działa w modelu aktywny-aktywny, w którym infrastruktura zlokalizowana w trzech strefach dostępności jednocześnie przetwarza zdarzenia przychodzące.

• Replikacja danych między strefami: Usługa Event Hubs używa replikacji synchronicznej w strefach dostępności. Gdy producent zdarzeń wysyła zdarzenie, Event Hubs zapisuje je w replikach w wielu strefach, zanim potwierdzi ukończenie operacji zapisu klientowi. Takie podejście zapewnia zerową utratę danych, nawet jeśli cała strefa stanie się niedostępna. Metoda replikacji synchronicznej zapewnia silne gwarancje spójności przy zachowaniu małych opóźnień dzięki zoptymalizowanym protokołom replikacji.

Zachowanie podczas awarii strefy

Gdy przestrzenie nazw usługi Event Hubs używają strefowej nadmiarowości i wystąpi awaria strefy dostępności, można oczekiwać następującego zachowania:

• Wykrywanie i reagowanie: Usługa Event Hubs jest odpowiedzialna za automatyczne wykrywanie awarii w strefie dostępności. Nie musisz inicjować trybu failover strefy.

• 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 Event Hubs 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 Event Hubs synchronicznie replikuje zdarzenia 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 Event Hubs wykrywa utratę strefy i automatycznie przekierowuje nowe żądania do innej repliki w jednej ze stref dostępności w dobrej kondycji.

  Klient SDK do Event Hubs zwykle obsługują zarządzanie połączeniami i logikę ponawiania prób w przejrzysty sposób.

Odzyskiwanie strefy

Gdy strefa dostępności zostanie odzyskana, usługa Event Hubs automatycznie ponownie połączy strefę z aktywną topologią usługi. Odzyskana strefa rozpoczyna akceptowanie nowych połączeń i przetwarzanie zdarzeń 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 Event Hubs zarządza trasowaniem ruchu, trybem przełączania awaryjnego i odzyskiwaniem w przypadku awarii stref, dzięki czemu nie musisz weryfikować procesów związanych z awariami stref dostępności ani dostarczać dodatkowych danych wejściowych.

Odporność na awarie całego regionu

Usługa Event Hubs zapewnia dwa typy obsługi wielu regionów:

• Replikacja geograficzna (warstwa Premium i Dedykowana) zapewnia aktywną replikację zarówno metadanych, jak i danych zdarzeń między regionem podstawowym a co najmniej jednym regionem pomocniczym. Użyj replikacji geograficznej dla większości aplikacji, które muszą pozostać odporne na awarie regionów i mają niską tolerancję dla utraty danych o zdarzeniach.

• Metadane dotyczące odzyskiwania po awarii geograficznej (warstwa Standardowa i wyższa) zapewniają aktywną-pasywną replikację konfiguracji i metadanych między obszarem podstawowym i obszarem pomocniczym, ale nie replikują danych zdarzeń. Użyj geograficznego odzyskiwania po katastrofie dla aplikacji, które mogą tolerować pewną utratę danych zdarzeń w scenariuszu awarii i które potrzebują szybko wznowić operacje w innym regionie.

Zarówno replikacja geograficzna, jak i odzyskiwanie po awarii geograficznej metadanych 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.

Geo-replication

Warstwy Premium i Dedykowane obsługują replikację geograficzną. Ta funkcja replikuje zarówno metadane (takie jak jednostki, konfiguracja i właściwości) oraz dane (takie jak ładunki zdarzeń) dla przestrzeni nazw. Konfigurujesz metodę replikacji dla danych konfiguracji i zdarzeń przestrzeni nazw. Ta funkcja zapewnia, że zdarzenia pozostaną dostępne w innym regionie i umożliwią przełączenie się do regionu pomocniczego w razie potrzeby. Replikuje również metadane i dane rejestru schematów.

Użyj replikacji geograficznej w scenariuszach, które wymagają odporności na awarie regionów i mają niską tolerancję dla utraty danych o zdarzeniach.

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 pokazuje jedną przestrzeń nazw niezależnie od liczby regionów pomocniczych skonfigurowanych na potrzeby replikacji geograficznej.

W dowolnym momencie możesz podwyższyć poziom regionu pomocniczego do regionu podstawowego. Po promowaniu regionu pomocniczego, usługa Event Hubs przekierowuje w pełni kwalifikowaną nazwę domeny przestrzeni nazw (FQDN) 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 Event Hubs.

Obsługa regionów

Możesz wybrać dowolny region świadczenia usługi Azure, który obsługuje usługę Event Hubs jako region podstawowy lub regiony pomocnicze. 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.

Requirements

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

Rozważania

Po włączeniu replikacji geograficznej należy wziąć pod uwagę następujące czynniki:

• Format punktu kontrolnego: Format punktów kontrolnych zmienia się. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna: Korzystanie z danych.

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

Koszt

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

Konfigurowanie obsługi wielu regionów

• Włącz replikację geograficzną w nowej lub istniejącej przestrzeni nazw. Aby skonfigurować replikację aktywne-aktywne dla nowo utworzonej przestrzeni nazw, zobacz Włączanie replikacji geograficznej w nowej przestrzeni nazw. Aby skonfigurować replikację active-active w istniejącej przestrzeni nazw, zobacz Włączanie replikacji geograficznej w istniejącej przestrzeni nazw.

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

• Wyłącz replikację geograficzną. Aby wyłączyć replikację geograficzną 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 Event Hubs jest skonfigurowana do 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 zdarzenia od klientów podczas normalnych operacji. Region pomocniczy odbiera zreplikowane zdarzenia, ale w przeciwnym razie pozostaje pasywny w trybie oczekiwania.

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

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

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

    • Asynchroniczny: Zdarzenia są zapisywane w regionie podstawowym, a następnie kończy się operacja zapisu. Chwilę później replikuje zdarzenia 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.

    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 Event Hubs jest skonfigurowana do replikacji geograficznej 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 uzyskać więcej informacji na temat promowania regionu pomocniczego na nowy region podstawowy, zobacz Promowanie pomocniczego.

  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.

  Użyj tych informacji i innych metryk, aby zdecydować, kiedy podwyższyć poziom regionu pomocniczego do regionu podstawowego.

• 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 działanie i nie akceptuje nowych zdarzeń, gdy opóźnienie replikacji osiągnie swoją maksymalną, skonfigurowaną wartość.

    Aby kontynuować korzystanie z przestrzeni nazw w regionie podstawowym, usuń pomocniczą przestrzeń nazw z konfiguracji replikacji geograficznej.

• 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 zdarzeń, które nie są replikowane do regionu pomocniczego. 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 Event Hubs nie czeka na ukończenie replikacji danych i natychmiast inicjuje promocję. 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.

  W niektórych sytuacjach należy skonfigurować aplikacje dla konsumentów, aby działały spójnie po awansie regionu. Aby uzyskać więcej informacji, zobacz Replikacja geograficzna: Korzystanie z danych.

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 replikację geograficzną w środowisku nieprodukcyjnym, które odzwierciedla konfigurację produkcyjnej przestrzeni nazw.

Odzyskiwanie po awarii geograficznej metadanych

Poziom Standardowy i wyższe poziomy obsługują geograficzne odzyskiwanie awaryjne metadanych. Ta funkcja usprawnia odbudowę po katastrofie, w tym katastrofalną stratę regionu. Odzyskiwanie po awarii geograficznej replikuje tylko konfigurację i metadane przestrzeni nazw. Nie replikuje jednak danych zdarzeń. 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 zdarzeń od klientów. Odzyskiwanie po awarii geograficznej służy jako rozwiązanie do jednokierunkowego odzyskiwania i nie obsługuje przywracania do poprzedniego głównego regionu.

Odzyskiwanie po awarii geograficznej metadanych działa najlepiej w przypadku aplikacji, które nie muszą utrzymywać każdego zdarzenia i mogą tolerować niektóre straty danych w scenariuszu awarii. Jeśli na przykład zdarzenia reprezentują odczyty czujników, które zostały później zagregowane, możesz zdecydować, że możesz sobie pozwolić na utratę niektórych zdarzeń z regionu, w którym wystąpił błąd, jeśli możesz szybko wznowić przetwarzanie nowych zdarzeń w innym regionie.

Gdy konfigurujesz odzyskiwanie po awarii geograficznej metadanych, tworzysz 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. Przełączenie awaryjne zakończy się niemal natychmiast. Podczas procesu trybu failover alias odzyskiwania po awarii geograficznej ponownie wskazuje na pomocniczą przestrzeń nazw, a parowanie zostanie usunięte.

W tej sekcji przedstawiono ważne aspekty odzyskiwania po awarii geograficznej. Przejrzyj pełną dokumentację, aby dokładnie zrozumieć, jak działa. Aby uzyskać więcej informacji, zobacz Odtworzenie awarii geograficznej usługi Event Hubs.

Obsługa regionów

Możesz wybrać dowolny region świadczenia usługi Azure, który obsługuje usługę Event Hubs 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.

Requirements

• Podstawowa warstwa przestrzeni nazw: Podstawowa przestrzeń nazw musi znajdować się w warstwie Standardowa lub nowszej, aby korzystać z odzyskiwania po awarii geograficznej metadanych.

• Wtórna przestrzeń nazw: Odzyskiwanie metadanych po awarii geograficznej obsługuje określone kombinacje poziomów dla podstawowej i wtórnej przestrzeni nazw. Aby uzyskać więcej informacji, zobacz Obsługiwane pary przestrzeni nazw.

Rozważania

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

• Rejestr schematów: Metadane rejestru schematów są replikowane podczas korzystania z geograficznego odzyskiwania po awarii metadanych, ale schematy zarejestrowane w rejestrze schematów nie podlegają replikacji.

• Projekt aplikacji: Odzyskiwanie po awarii geograficznej wymaga konkretnych 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.

Koszt

Po włączeniu możliwości odzyskiwania danych po awarii geograficznej metadanych płacisz zarówno za podstawowe, jak i drugorzędne przestrzenie nazw.

Konfigurowanie obsługi wielu regionów

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

• Wyłącz odzyskiwanie metadanych po awarii geograficznej. 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 Event Hubs jest skonfigurowana do odzyskiwania po awarii geograficznej, a region podstawowy działa.

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

  Tylko podstawowa przestrzeń nazw aktywnie przetwarza zdarzenia 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 zdarzenia 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 Event Hubs jest skonfigurowana w przypadku odzyskiwania po katastrofie geograficznej oraz w przypadku awarii 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 Ręczne przechodzenie w tryb failover.

  Tryb failover jest operacją jednokierunkową, więc później należy ponownie utworzyć połączenie odzyskiwania po awarii geograficznej. 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.

  Użyj tych informacji i innych metryk, aby zdecydować, kiedy przejść w tryb failover do regionu pomocniczego.

• 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 zdarzenia: Dane zdarzenia nie są replikowane między regionami. Jeśli region podstawowy ulegnie awarii, zdarzenia w podstawowej przestrzeni nazw staną się niedostępne.

    Zdarzenia nie zostaną trwale utracone, chyba że katastrofalna katastrofa spowoduje całkowitą utratę regionu podstawowego. Jeśli region zostanie odzyskany, możesz później pobrać zdarzenia 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 odzyskiwania po awarii geograficznej do łączenia się z przestrzenią nazw automatycznie zostają przekierowani do pomocniczej przestrzeni nazw po przełączeniu awaryjnym. 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ę odzyskiwania po awarii geograficznej z odzyskanym regionem jako pomocniczym, a następnie wykonaj kolejne przejście w tryb failover, jeśli chcesz powrócić do oryginalnego regionu. Ten proces wiąże się z potencjalną utratą danych dotyczących zdarzeń wysyłanych do tymczasowego serwera głównego.

Jeśli awaria spowoduje utratę wszystkich stref w regionie podstawowym, dane mogą być nieodwracalne. W innych scenariuszach dane zdarzeń pozostają w podstawowej przestrzeni nazw, do odzyskania po awarii. Zdarzenia historyczne można uzyskać ze starej podstawowej przestrzeni nazw po przywróceniu dostępu. Odpowiadasz za konfigurowanie aplikacji w celu odbierania i przetwarzania tych zdarzeń. 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. Zainicjuj przełączanie na tryb awaryjny (failover) z podstawowej przestrzeni nazw do pomocniczej przestrzeni nazw i sprawdź, czy aplikacje mogą łączyć się z nową podstawową przestrzenią nazw i przetwarzać zdarzenia.

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. Przetestuj replikację geograficzną w środowisku nieprodukcyjnym, które odzwierciedla konfigurację produkcyjnej przestrzeni nazw.

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

Replikacja geograficzna i odzyskiwanie metadanych po awarii geograficznej zapewniają odporność na awarie regionów i inne problemy, a także obsługują większość obciążeń. Niektóre warstwy usługi Event Hubs nie obsługują tych funkcji lub mogą wymagać replikacji niestandardowej lub muszą obsługiwać wiele aktywnych regionów jednocześnie.

Różne wzorce projektowe mogą osiągnąć różne typy obsługi wielu regionów w usłudze Event Hubs. Wiele wzorców wymaga wdrożenia wielu przestrzeni nazw i używania usług takich jak Azure Functions do replikowania zdarzeń między nimi. Aby uzyskać więcej informacji, zobacz Federacja wielu lokacji i wielu regionów.

Tworzenie kopii zapasowej i przywracanie

Usługa Event Hubs nie jest zaprojektowana jako długoterminowa lokalizacja przechowywania danych. Zazwyczaj dane są przechowywane w centrum zdarzeń przez krótki czas, a następnie są przetwarzane lub utrwalane w innym systemie magazynowania danych. Okres przechowywania danych dla Event Hub można skonfigurować na podstawie wymagań oraz poziomu, który wykorzystuje Twoja przestrzeń nazw. Aby uzyskać więcej informacji, zobacz Przechowywanie zdarzeń.

Jeśli chcesz zachować kopię zdarzeń, rozważ użycie funkcji przechwytywania usługi Event Hubs, która zapisuje kopie zdarzeń na koncie usługi Azure Blob Storage.

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.

Umowa SLA (Service Level Agreement) dotycząca dostępności przestrzeni nazw jest wyższa, gdy używane są poziomy Premium lub Dedykowany.

Treści powiązane

• Dokumentacja usługi Event Hubs
• Omówienie niezawodności platformy Azure