Replikacja geograficzna usługi Azure Event Hubs

Funkcja replikacji geograficznej usługi Event Hubs zapewnia replikację metadanych (jednostek, konfiguracji i właściwości) oraz danych (ładunków zdarzeń) dla przestrzeni nazw, co umożliwia ciągłość działania i odzyskiwanie po awarii.

Ta funkcja zapewnia, że metadane i dane przestrzeni nazw są stale replikowane z regionu podstawowego do regionu pomocniczego. Przestrzeń nazw można traktować jako rozszerzoną do więcej niż jednego regionu, a jeden region jest podstawowym, a drugi jest pomocniczym.

W dowolnym momencie region pomocniczy może zostać podwyższony do regionu podstawowego. Promocja regionu pomocniczego przekierowuje FQDN przestrzeni nazw do wybranego regionu pomocniczego, a poprzedni region podstawowy zostaje zdegradowany do regionu pomocniczego.

Scenariusze

Replikacja geograficzna usługi Event Hubs może być używana w wielu różnych scenariuszach, zgodnie z opisem w tym miejscu.

Zapewnianie ciągłości działania i odzyskiwania po awarii

Replikacja geograficzna zapewnia odzyskiwanie po awarii i ciągłość działania dla wszystkich danych przesyłanych strumieniowo w waszej przestrzeni nazw. Replikując dane między regionami, organizacje mogą chronić przed utratą danych i zapewnić, że ich aplikacje pozostaną operacyjne nawet w przypadku awarii regionalnej. Ta funkcja ma kluczowe znaczenie dla aplikacji o krytycznym znaczeniu, które wymagają wysokiej dostępności i minimalnych przestojów.

Globalna dystrybucja danych

Replikacja geograficzna może służyć do globalnego dystrybuowania danych, co umożliwia aplikacjom uzyskiwanie dostępu do danych z najbliższego regionu. Zmniejsza to opóźnienia i zwiększa wydajność obciążeń znajdujących się w różnych częściach świata.

Niezależność i zgodność danych

Organizacje działające w wielu krajach/regionach często muszą przestrzegać przepisów dotyczących niezależności danych, które wymagają przechowywania danych w określonych granicach geograficznych. Replikacja geograficzna umożliwia tym organizacjom replikowanie danych do regionów, które są zgodne z lokalnymi przepisami, zapewniając spełnienie wymagań prawnych przy zachowaniu ujednoliconej platformy danych.

Migracja i uaktualnienia

Replikacja geograficzna może również służyć do ułatwiania migracji, konserwacji i uaktualnień systemu danych. Organizacje mogą aktywnie migrować przestrzeń nazw z regionu podstawowego do regionu pomocniczego, aby umożliwić konserwację i uaktualnienia w regionie podstawowym.

Podstawowe pojęcia

Funkcja replikacji geograficznej implementuje metadane i replikację danych w podstawowym modelu replikacji pomocniczej. W danym momencie istnieje jeden region podstawowy, który obsługuje zarówno producentów, jak i konsumentów. Pomocnicza działa jako region rezerwowy, co oznacza, że nie można wchodzić w interakcje z tymi regionami pomocniczymi. Są one jednak uruchamiane w tej samej konfiguracji co region podstawowy, co umożliwia szybkie podwyższenie poziomu, gotowe do przejścia po zakończeniu promocji.

Oto niektóre kluczowe aspekty funkcji replikacji danych geograficznych:

• Podstawowy pomocniczy model replikacji — replikacja geograficzna jest oparta na podstawowym pomocniczym modelu replikacji, w którym w danym momencie istnieje tylko jedna podstawowa przestrzeń nazw, która obsługuje producentów zdarzeń i odbiorców zdarzeń.
• Usługa Event Hubs wykonuje w pełni zarządzaną replikację bajtów do bajtów metadanych, danych zdarzeń i przesunięcie odbiorcy w innych dokumentach ze skonfigurowanymi poziomami spójności.
• Nazwa hosta pojedynczej przestrzeni nazw — po pomyślnej konfiguracji przestrzeni nazw z włączoną funkcją Geo-Replication użytkownicy mogą używać nazwy hosta przestrzeni nazw w aplikacji klienckiej. Nazwa hosta działa niezależnie od skonfigurowanych regionów podstawowych i wtórnych, i zawsze wskazuje region podstawowy.
• Gdy klient inicjuje podwyższenie poziomu, nazwa hosta wskazuje region wybrany jako nowy region podstawowy. Stary region główny staje się regionem pomocniczym.
• Nie można odczytywać ani zapisywać danych w regionach pomocniczych.
• Przeniesienie zarządzane przez klienta z regionu podstawowego do pomocniczego, zapewniając pełną kontrolę i wgląd w rozwiązanie awarii. Dostępne są metryki, które mogą pomóc zautomatyzować proces promowania po stronie klienta. Regiony pomocnicze można dodawać lub usuwać według uznania klienta.
• Spójność replikacji — istnieją dwa ustawienia spójności replikacji, synchroniczne i asynchroniczne.

Państwo	Schemat
Przed failoverem (promocją zapasowego)
Po przejściu w tryb failover (podwyższenie poziomu pomocniczego)

Tryby replikacji

Istnieją dwie konfiguracje spójności replikacji, synchroniczne i asynchroniczne. Ważne jest, aby znać różnice między dwiema konfiguracjami, ponieważ mają one wpływ na aplikacje i spójność danych.

Replikacja asynchroniczna

Przy użyciu replikacji asynchronicznej wszystkie żądania są zatwierdzane na serwerze podstawowym, po czym potwierdzenie jest wysyłane do klienta. Replikacja do regionów pomocniczych odbywa się asynchronicznie. Użytkownicy mogą skonfigurować maksymalny dopuszczalny czas opóźnienia — przesunięcie po stronie usługi między najnowszą akcją w regionach podstawowych i pomocniczych. Usługa stale replikuje dane i metadane, zapewniając, że opóźnienie pozostaje tak małe, jak to możliwe. Jeśli opóźnienie dla aktywnej pomocniczej zwiększa się poza maksymalne opóźnienie replikacji skonfigurowane przez użytkownika, podstawowe rozpoczyna ograniczanie żądań przychodzących.

Replikacja synchroniczna

Przy użyciu replikacji synchronicznej wszystkie żądania są replikowane do serwera pomocniczego, który musi zatwierdzić i potwierdzić operację przed zatwierdzeniem na serwerze podstawowym. W związku z tym aplikacja działa w tempie, które obejmuje publikowanie, replikację, potwierdzanie i zatwierdzanie. Ponadto oznacza to również, że aplikacja jest powiązana z dostępnością obu regionów. Jeśli region pomocniczy ma opóźnienie lub jest niedostępny, komunikaty nie zostaną potwierdzone i zatwierdzone, a region główny będzie spowalniać przychodzące żądania.

Porównanie spójności replikacji

W przypadku replikacji synchronicznej :

• Opóźnienie jest dłuższe z powodu rozproszonych operacji zatwierdzania.
• Dostępność jest powiązana z dostępnością dwóch regionów. Jeśli jeden region ulegnie awarii, przestrzeń nazw jest niedostępna.

Z drugiej strony replikacja synchroniczna zapewnia największą pewność, że dane są bezpieczne. Jeśli masz replikację synchroniczną, to po zatwierdzeniu zostanie ona zatwierdzona we wszystkich regionach skonfigurowanych na potrzeby replikacji geograficznej, zapewniając najlepszą gwarancję danych.

Z replikacją asynchroniczną :

• Opóźnienie jest minimalnie wpływane.
• Utrata regionu pomocniczego nie ma natychmiastowego wpływu na dostępność. Jednak na dostępność ma wpływ osiągnięcie skonfigurowanego maksymalnego opóźnienia replikacji.

W związku z tym nie ma pełnej gwarancji, że wszystkie regiony mają dostęp do danych przed ich zatwierdzeniem, jak to ma miejsce w przypadku replikacji synchronicznej. Może wystąpić utrata lub powielanie danych. Jednak ponieważ nie jesteś już natychmiastowo dotknięty opóźnieniem lub niedostępnością pojedynczego regionu, dostępność aplikacji się zwiększa, a także zmniejsza się opóźnienie.

Tryb replikacji można zmienić po skonfigurowaniu replikacji geograficznej. Możesz przejść z synchronicznego do asynchronicznego lub z asynchronicznego do synchronicznego. Jeśli przejdziesz z trybu asynchronicznego na tryb synchroniczny, serwer pomocniczy zostanie skonfigurowany jako synchroniczny po tym, jak opóźnienie osiągnie zero. Jeśli masz ciągłe opóźnienie z jakiegokolwiek powodu, może być konieczne wstrzymanie wydawców, aby opóźnienie osiągnęło zero i aby tryb mógł przełączyć się na synchroniczny. Przyczyny włączenia replikacji synchronicznej zamiast replikacji asynchronicznej są powiązane z ważnością danych, specyficznymi potrzebami biznesowymi lub przyczynami zgodności, a nie dostępnością aplikacji.

Wybór regionu pomocniczego

Aby włączyć funkcję replikacji geograficznej, należy użyć regionów podstawowych i pomocniczych, w których funkcja jest włączona. Funkcja replikacji geograficznej zależy od możliwości replikowania opublikowanych komunikatów z regionu podstawowego do regionów pomocniczych. Jeśli region pomocniczy znajduje się na innym kontynencie, ma to duży wpływ na opóźnienie replikacji z regionu podstawowego do regionu pomocniczego. Jeśli ze względów dostępności używasz replikacji geograficznej, najlepiej jest korzystać z regionów pomocniczych znajdujących się co najmniej na tym samym kontynencie, gdzie to możliwe. Aby lepiej zrozumieć opóźnienia spowodowane odległością geograficzną, możesz dowiedzieć się więcej na temat statystyk opóźnienia okrężnego sieci platformy Azure.

Zarządzanie replikacją geograficzną

Funkcja replikacji geograficznej umożliwia klientom skonfigurowanie regionu pomocniczego, w którym mają być replikowane metadane i dane. W związku z tym klienci mogą wykonywać następujące zadania zarządzania:

• Konfigurowanie replikacji geograficznej — regiony pomocnicze można skonfigurować w dowolnej nowej lub istniejącej przestrzeni nazw w regionie z włączoną funkcją Geo-Replication.
• Skonfiguruj spójność replikacji — replikacja synchroniczna i asynchroniczna jest ustawiana po skonfigurowaniu Geo-Replication, ale może być również przełączana później.
• Uruchomienie promocji/awaryjne przełączenie — wszystkie promocje są inicjowane przez klienta.
• Usuń pomocniczą — jeśli w dowolnym momencie chcesz usunąć region pomocniczy, możesz to zrobić po usunięciu danych w regionie pomocniczym.

Kryteria wyzwalania podwyższania poziomu

Przedstawiamy kilka przypadków, w których może zostać zainicjowany awans z podrzędnego na główny.

• Awaria regionalna: jeśli wystąpi awaria regionalna wpływająca na region podstawowy, należy podwyższyć poziom regionu pomocniczego, aby zapewnić ciągłość działania i zminimalizować przestoje.

• Działania konserwacyjne: Podczas planowanych działań konserwacyjnych w regionie podstawowym promowanie regionu pomocniczego może pomóc w utrzymaniu wysokiej dostępności dla aplikacji o znaczeniu krytycznym.

• Odzyskiwanie po awarii: w przypadku awarii wpływającej na region podstawowy promowanie regionu pomocniczego gwarantuje, że dane będą nadal dostępne, a aplikacje będą nadal działać.

• Problemy z wydajnością: jeśli w regionie podstawowym występują problemy z wydajnością, które wpływają na dostępność lub niezawodność usługi Event Hubs, promowanie regionu pomocniczego może pomóc rozwiązać te problemy.

Zaleca się od czasu do czasu testowanie mechanizmów pracy w trybie failover w celu zapewnienia skuteczności planu ciągłości działania, a aplikacje mogą bezproblemowo przełączać się do regionu pomocniczego w razie potrzeby.

Monitorowanie replikacji danych

Użytkownicy mogą monitorować postęp zadania replikacji, monitorując metrykę opóźnienia replikacji w dziennikach metryk aplikacji.

• Włącz dzienniki metryk aplikacji w przestrzeni nazw usługi Event Hubs zgodnie z Monitoring Azure Event Hubs - Azure Event Hubs | Microsoft Learn.

• Po włączeniu dzienników metryk aplikacji należy generować i przetwarzać dane z przestrzeni nazw przez kilka minut, zanim zaczniesz widzieć dzienniki.

• Aby wyświetlić dzienniki metryk aplikacji, przejdź do sekcji Monitorowanie na stronie usługi Event Hubs i wybierz pozycję Dzienniki w menu po lewej stronie. Poniższe zapytanie umożliwia znalezienie opóźnienia replikacji (w sekundach) między podstawowymi i pomocniczymi przestrzeniami nazw.

  AzureDiagnostics
    | where TimeGenerated > ago(1h)
    | where Category == "ApplicationMetricsLogs"
    | where ActivityName_s == "ReplicationLag
  

• count_d Kolumna wskazuje opóźnienie replikacji w sekundach między regionem podstawowym i pomocniczym.

Publikowanie danych

Aplikacje do publikowania mogą publikować dane w replikowanych geograficznie przestrzeniach nazw za pośrednictwem nazwy hosta przestrzeni nazw z włączoną replikacją geograficzną. Podejście do publikowania jest takie samo jak w przypadku braku replikacji geograficznej i nie wymaga żadnych zmian w zestawach SDK płaszczyzny danych ani w aplikacjach klienckich.

Publikowanie zdarzeń może nie być dostępne w następujących okolicznościach:

• Po zgłoszeniu wniosku o promocję regionu pomocniczego istniejący region podstawowy odrzuca wszelkie nowe zdarzenia publikowane w centrum zdarzeń.
• Gdy opóźnienie replikacji między regionem głównym i pomocniczym osiągnie maksymalny czas trwania tego opóźnienia, obciążenie związane z przetwarzaniem danych wejściowych przez wydawcę może zostać ograniczone.

Aplikacje wydawcy nie mogą bezpośrednio uzyskiwać dostępu do żadnych przestrzeni nazw w regionach pomocniczych.

Korzystanie z danych

Aplikacje korzystające mogą używać danych za pomocą nazwy hosta przestrzeni nazw z włączoną funkcją replikacji geograficznej. Operacje konsumentów nie są obsługiwane od momentu zainicjowania promocji do momentu ukończenia promocji.

Zarządzanie punktami kontrolnymi/zarządzanie przesunięciem

Aplikacje przetwarzające zdarzenia mogą nadal utrzymywać zarządzanie offsetami, tak jakby to była przestrzeń nazw niereplikowana geograficznie. Do zarządzania przesunięciami dla przestrzeni nazw z włączoną replikacją geograficzną nie jest wymagana żadna szczególna uwaga.

Kafka

Przesunięcia są zatwierdzane bezpośrednio w usłudze Event Hubs, a przesunięcia są replikowane między regionami. W związku z tym konsumenci mogą zacząć spożywać od miejsca, w którym przerwali w regionie podstawowym.

Oto lista obsługiwanych klientów platformy Apache Kafka —

W przypadku innych bibliotek obsługiwane są te korzystające z poniższych wersji interfejsu API —

Zestaw SDK usługi Event Hubs/AMQP

W przypadku protokołu AMQP punkt kontrolny jest zarządzany przez użytkowników z magazynem punktów kontrolnych, takim jak usługa Azure Blob Storage lub niestandardowe rozwiązanie magazynu. W przypadku przejścia w tryb failover magazyn punktów kontrolnych musi być dostępny w regionie pomocniczym, aby klienci mogli pobierać dane punktu kontrolnego i unikać utraty komunikatów.

Najnowsza wersja zestawu SDK usługi Event Hubs wprowadziła pewne zmiany w reprezentacji punktu kontrolnego w celu obsługi trybu failover. Zalecamy używanie najnowszych wersji zestawów SDK, ale obsługiwane są również wcześniejsze wersje poniższych zestawów SDK.

Rozważania

Zwróć uwagę na następujące zagadnienia, aby pamiętać o tej funkcji:

• W planowaniu promocji należy również wziąć pod uwagę czynnik czasu. Jeśli na przykład utracisz łączność przez dłuższy niż 15 do 20 minut, możesz zdecydować się na zainicjowanie promocji.
• Promowanie złożonej rozproszonej infrastruktury powinno być próbowane co najmniej raz.

Cennik

Ceny różnią się w zależności od wybranego poziomu, ale zazwyczaj mają 2 parametry —

• Opłata za zasoby obliczeniowe dla klastra lub przestrzeni nazw.
• Opłata za przepustowość danych replikowanych między regionami podstawowymi i pomocniczymi.

Dedykowane klastry

Użycie replikacji geograficznej z dedykowaną usługą Event Hubs wymaga posiadania co najmniej dwóch dedykowanych klastrów w oddzielnych regionach, które mogą być używane do hostowania przestrzeni nazw innych niż ta, która jest replikowana geograficznie. Te dedykowane klastry są rozliczane oddzielnie na podstawie liczby jednostek wydajności przydzielonych do każdego z nich.

Po włączeniu replikacji geograficznej jedyną dodatkową opłatą jest opłata za przepustowość danych replikowanych z podstawowej na pomocniczą. Ta opłata zależy od lokalizacji regionu podstawowego.

Przestrzenie nazw Premium

W przypadku przestrzeni nazw Premium włączenie replikacji geograficznej przydziela tę samą liczbę jednostek przetwarzania (PUs) w regionie pomocniczym. W związku z tym płacisz za liczbę używanych jednostek PU oraz przepustowość danych przesyłanych między regionem podstawowym i pomocniczym.

Jeśli na przykład włączysz replikację geograficzną w przestrzeni nazw Premium, która została aprowizowana przy użyciu 4 pu, opłata zostanie naliczona za

• 4 jednostki PU w regionie podstawowym,
• 4 jednostki PU w regionie pomocniczym,
• Opłata za replikację geograficzną na GB replikowanych danych.

Przepustowość jest naliczana na podstawie danych przesyłanych między regionami podstawowymi i pomocniczymi.

Mierniki cen

Wskaźniki cenowe opłaty za przepustowość transferu danych w ramach replikacji geograficznej będą wyświetlane z następującymi szczegółami —

Prywatne punkty końcowe

Ta sekcja zawiera dodatkowe zagadnienia dotyczące używania Geo-Replication z przestrzeniami nazw korzystającymi z prywatnych punktów końcowych. Aby uzyskać ogólne informacje na temat korzystania z prywatnych punktów końcowych z usługą Event Hubs, zobacz Integrowanie usługi Azure Event Hubs z usługą Azure Private Link.

Podczas implementowania Geo-Replication dla przestrzeni nazw usługi Event Hubs korzystającej z prywatnych punktów końcowych ważne jest utworzenie prywatnych punktów końcowych zarówno dla regionów podstawowych, jak i pomocniczych. Te punkty końcowe powinny być skonfigurowane względem sieci wirtualnych hostujących zarówno podstawowe, jak i pomocnicze instancje aplikacji. Jeśli na przykład masz dwie sieci wirtualne, VNET-1 i VNET-2, musisz utworzyć dwa prywatne punkty końcowe w przestrzeni nazw usługi Event Hubs, używając odpowiednio podsieci z sieci VNET-1 i VNET-2. Ponadto sieci wirtualne powinny być konfigurowane za pomocą peeringu między regionami, aby klienci mogli komunikować się z dowolnym z prywatnych punktów końcowych. Na koniec DNS musi być zarządzany w taki sposób, aby wszyscy klienci uzyskiwali potrzebne informacje DNS, które wskażą punkt końcowy przestrzeni nazw (namespacename.servicebus.windows.net) na adres IP prywatnego punktu końcowego w bieżącym regionie podstawowym.

Zaletą tego podejścia jest to, że przejście w tryb failover może nastąpić niezależnie w warstwie aplikacji lub w przestrzeni nazw usługi Event Hubs:

• Tryb failover tylko dla aplikacji: w tym scenariuszu aplikacja przechodzi z sieci wirtualnej VNET-1 do sieci wirtualnej-2. Ponieważ prywatne punkty końcowe są konfigurowane zarówno w sieci wirtualnej VNET-1, jak i VNET-2 dla podstawowych i pomocniczych przestrzeni nazw, aplikacja będzie nadal bezproblemowo działać.
• Tryb failover tylko dla przestrzeni nazw usługi Event Hubs: podobnie, jeśli tryb failover występuje tylko na poziomie przestrzeni nazw usługi Event Hubs, aplikacja pozostaje operacyjna, ponieważ prywatne punkty końcowe są skonfigurowane w obu sieciach wirtualnych.

Postępując zgodnie z tymi wytycznymi, można zapewnić solidne i niezawodne mechanizmy failover dla przestrzeni nazw Event Hubs przy użyciu prywatnych punktów końcowych.

Powiązana zawartość

Aby dowiedzieć się, jak używać funkcji replikacji geograficznej, zobacz Używanie replikacji geograficznej.