Replikacja geograficzna (publiczna wersja zapoznawcza)

Istnieją dwie funkcje zapewniające odzyskiwanie po awarii geograficznej w usłudze Azure Event Hubs.

• Odzyskiwanie po awarii geograficznej (Metadata DR), które zapewnia tylko replikację tylko metadanych.
• Replikacja geograficzna (publiczna wersja zapoznawcza), która zapewnia replikację metadanych i danych.

Uwaga

Funkcja replikacji geograficznej jest obsługiwana tylko przez dedykowaną warstwę.

Te funkcje nie powinny być mylone z Strefy dostępności. Obie funkcje odzyskiwania geograficznego zapewniają odporność między regionami świadczenia usługi Azure, takimi jak Wschodnie stany USA i Zachodnie stany USA. Obsługa strefy dostępności zapewnia odporność w określonym regionie geograficznym, takim jak Wschodnie stany USA. Aby uzyskać więcej informacji na temat Strefy dostępności, zobacz Obsługa strefy dostępności usługi Event Hubs.

Ważne

• Ta funkcja jest obecnie dostępna w publicznej wersji zapoznawczej i w związku z tym nie powinna być używana w scenariuszach produkcyjnych.
• Następujące regiony są obecnie obsługiwane w publicznej wersji zapoznawczej.

Region (Region)	Region (Region)	Region (Region)
AustraliaCentral	NiemcyNorth	NorwegiaWest
AustraliaCentral2	GermanyWestCentral	PolskaCentral
AustraliaEast	IsraelCentral	SouthAfricaNorth
AustraliaSoutheast	WłochyNorth	PołudniowoafrykadaWest
BrazilSoutheast	JapanEast	SoutheastAsia
CanadaCentral	JaponiaWest	SouthIndia
CanadaEast	JioIndiaCentral	HiszpaniaCentral
CentralIndia	JioIndiaWest	SzwecjaCentral
CentralUS	KoreaCentral	SwitzerlandNorth
CentralUSEUAP	KoreaSouth	SzwajcariaWest
EastAsia	MeksykCentral	ZeACentral
EastUS2	NorthCentralUS	UAENorth
FranceCentral	NorthEurope	UKSouth
FranceSouth	NorwayEast	UKWest

Odzyskiwanie po awarii metadanych a replikacja geograficzna metadanych i danych

Funkcja odzyskiwania po awarii metadanych replikuje informacje o konfiguracji 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 informacjami o konfiguracji ani nie są replikowane przypisania uprawnień.

Nowsza funkcja replikacji geograficznej replikuje informacje o konfiguracji i wszystkie dane z podstawowej przestrzeni nazw do co najmniej jednej pomocniczej przestrzeni nazw. Po zakończeniu pracy w trybie failover wybrana pomocnicza staje się podstawowa, a poprzednia podstawowa staje się pomocnicza. Użytkownicy mogą w razie potrzeby wykonać powrót w tryb failover do oryginalnego podstawowego obiektu podstawowego.

W pozostałej części tego artykułu skupiono się na funkcji replikacji geograficznej. Aby uzyskać szczegółowe informacje na temat funkcji odzyskiwania po awarii metadanych, zobacz Odzyskiwanie po awarii geograficznej usługi Event Hubs dla metadanych.

Replikacja geograficzna

Publiczna wersja zapoznawcza funkcji replikacji geograficznej jest obsługiwana w przypadku przestrzeni nazw w samoobsługowym skalowaniu dedykowanych klastrów usługi Event Hubs. Funkcji można używać z nowymi lub istniejącymi przestrzeniami nazw w dedykowanych klastrach samoobsługowych. Następujące funkcje nie są obsługiwane w przypadku replikacji geograficznej:

• Klucze zarządzane przez klienta (CMK)
• Tożsamość zarządzana do przechwytywania
• Funkcje sieci wirtualnej (punkty końcowe usługi lub prywatne punkty końcowe)
• Obsługa dużych komunikatów (teraz w publicznej wersji zapoznawczej)
• Transakcje platformy Kafka (teraz w publicznej wersji zapoznawczej)

Niektóre kluczowe aspekty publicznej wersji zapoznawczej replikacji danych geograficznych to:

• 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.
• Stabilna przestrzeń nazw w pełni kwalifikowana nazwa domeny (FQDN) — nazwa FQDN nie musi zmieniać się podczas podwyższania poziomu.
• Spójność replikacji — istnieją dwa ustawienia spójności replikacji, synchroniczne i asynchroniczne.
• Podwyższenie poziomu pomocniczego zarządzanego przez użytkownika do nowego podstawowego elementu.

Zmiana pomocniczego na nową podstawową jest wykonywana na dwa sposoby:

• Planowane: podwyższenie poziomu pomocniczego do podstawowego miejsca, w którym ruch nie jest przetwarzany, dopóki nowy podstawowy nie dogoni wszystkie dane przechowywane przez poprzednie wystąpienie podstawowe.
• Wymuszone: jako tryb failover, w którym pomocnicza staje się podstawowa tak szybko, jak to możliwe. Funkcja replikacji geograficznej replikuje wszystkie dane i metadane z regionu podstawowego do wybranych regionów pomocniczych. Nazwa FQDN przestrzeni nazw zawsze wskazuje region podstawowy.

Po zainicjowaniu podwyższenia poziomu pomocniczej nazwa FQDN wskazuje region wybrany jako nowy podstawowy. Stary podstawowy staje się następnie pomocniczym. Możesz podwyższyć poziom pomocniczego jako nowy element podstawowy z powodów innych niż tryb failover. Przyczyny te mogą obejmować uaktualnienia aplikacji, testowanie trybu failover lub dowolną liczbę innych rzeczy. W takich sytuacjach często przełącza się z powrotem po zakończeniu tych działań.

Regiony pomocnicze są dodawane lub usuwane według uznania klienta. Istnieją pewne bieżące ograniczenia, które warto zauważyć:

• Nie ma możliwości obsługi widoków tylko do odczytu w regionach pomocniczych.
• Nie ma możliwości automatycznego podwyższania poziomu/trybu failover. Wszystkie promocje są inicjowane przez klienta.
• Regiony pomocnicze muszą być inne niż region podstawowy. Nie można wybrać innego dedykowanego klastra w tym samym regionie.
• Tylko jedna pomocnicza jest obsługiwana w publicznej wersji zapoznawczej.

Spójność 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

Po włączeniu replikacji asynchronicznej wszystkie komunikaty są zatwierdzane w podstawowej, a następnie wysyłane do pomocniczej. Użytkownicy mogą skonfigurować akceptowalny czas opóźnienia, który pomocniczy musi nadrobić zaległości. Gdy opóźnienie aktywnej pomocniczej jest większe niż konfiguracja opóźnienia użytkownika, region podstawowy ogranicza przychodzące żądania publikowania.

Replikacja synchroniczna

Po włączeniu replikacji synchronicznej opublikowane zdarzenia są replikowane do pomocniczej, co musi potwierdzić komunikat, zanim zostanie zatwierdzony w obiekcie podstawowym. Dzięki replikacji synchronicznej aplikacja publikuje ją w tempie publikowania, replikowania, potwierdzania i zatwierdzania. Oznacza to również, że aplikacja jest powiązana z dostępnością obu regionów. Jeśli region pomocniczy ulegnie awarii, komunikaty nie mogą być potwierdzane ani zatwierdzane.

Porównanie spójności replikacji

W przypadku replikacji synchronicznej:

• Opóźnienie jest dłuższe z powodu zatwierdzenia rozproszonego.
• Dostępność jest powiązana z dostępnością dwóch regionów. Jeśli jeden region ulegnie awarii, przestrzeń nazw jest niedostępna.
• Odebrane dane zawsze znajdują się w co najmniej dwóch regionach (tylko dwa regiony obsługiwane w początkowej publicznej wersji zapoznawczej).

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. Po włączeniu replikacji synchronicznej dostępność aplikacji może zostać zmniejszona w zależności od dostępności obu regionów.

Włączenie replikacji asynchronicznej nie ma wpływu na opóźnienie, a na dostępność usługi nie ma wpływu utrata regionu pomocniczego. Replikacja asynchroniczna nie ma bezwzględnej gwarancji, że wszystkie regiony mają dane, zanim zostanie zatwierdzone, tak jak replikacja synchroniczna. Możesz również ustawić czas, przez który pomocnicza może nie być zsynchronizowana, zanim ruch przychodzący zostanie ograniczony. Ustawienie może wynosić od 5 minut do 1440 minut, czyli jeden dzień. Jeśli chcesz używać regionów z dużą odległością między nimi, replikacja asynchroniczna jest prawdopodobnie najlepszą opcją.

Konfiguracja spójności replikacji może ulec zmianie po konfiguracji replikacji geograficznej. Możesz przejść z synchronicznego do asynchronicznego lub z asynchronicznego do synchronicznego. Jeśli przejdziesz od synchronicznego do asynchronicznego, opóźnienie i dostępność aplikacji poprawi się. Jeśli przejdziesz z asynchronicznego do synchronicznego, pomocnicza stanie się skonfigurowana jako synchroniczna po osiągnięciu zera. Jeśli korzystasz z ciągłego opóźnienia z jakiegokolwiek powodu, może być konieczne wstrzymanie wydawców, aby opóźnienie osiągło zero i tryb, aby można było przełączyć się na synchroniczne.

Ogólne przyczyny włączenia replikacji synchronicznej są powiązane z ważnością danych, specyficznymi potrzebami biznesowymi lub przyczynami zgodności. Jeśli głównym celem jest dostępność aplikacji, a nie zapewnienie bezpieczeństwa danych, spójność asynchroniczna prawdopodobnie będzie lepszym wyborem.

Wybór regionu pomocniczego

Aby włączyć funkcję replikacji geograficznej, należy użyć regionu podstawowego i pomocniczego, w którym włączono funkcję replikacji geograficznej. Należy również mieć klaster usługi Event Hubs już istniejący w regionach podstawowych i pomocniczych.

Funkcja replikacji geograficznej zależy od możliwości replikowania opublikowanych zdarzeń z regionu podstawowego do regionu pomocniczego. Jeśli region pomocniczy znajduje się na innym kontynencie, ma duży wpływ na opóźnienie replikacji z regionu podstawowego do regionu pomocniczego. W przypadku korzystania z replikacji geograficznej ze względów dostępności i niezawodności 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 | Microsoft Learn.

Zarządzanie replikacją geograficzną

Funkcja replikacji geograficznej umożliwia skonfigurowanie regionu pomocniczego w celu replikowania konfiguracji i danych. Masz następujące możliwości:

• Konfigurowanie replikacji geograficznej — regiony pomocnicze można skonfigurować w dowolnej istniejącej przestrzeni nazw w dedykowanym klastrze w regionie z włączonym zestawem funkcji replikacji geograficznej. Można go również skonfigurować podczas tworzenia przestrzeni nazw w tych samych dedykowanych klastrach. Aby wybrać region pomocniczy, musisz mieć dedykowany klaster dostępny w tym regionie pomocniczym, a region pomocniczy również musi mieć włączony zestaw funkcji replikacji geograficznej dla tego regionu.
• Skonfiguruj spójność replikacji — replikacja synchroniczna i asynchroniczna jest ustawiana podczas konfigurowania replikacji geograficznej, ale można je również przełączać później. Dzięki spójności asynchronicznej można skonfigurować czas opóźnienia regionu pomocniczego.
• Podwyższenie poziomu wyzwalacza/tryb failover — wszystkie promocje lub tryb failover są inicjowane przez klienta. Podczas promocji możesz zdecydować się na to, aby wymuszone od początku, a nawet zmienić zdanie po rozpoczęciu promocji i zmusić go.
• Usuń pomocniczą — jeśli w dowolnym momencie chcesz usunąć parowanie geograficzne między regionami podstawowymi i pomocniczymi, możesz to zrobić, a dane w regionie pomocniczym zostaną usunięte.

Monitorowanie replikacji danych

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

• Włączanie dzienników metryk aplikacji w przestrzeni nazw usługi Event Hubs po monitorowaniu usługi Azure Event Hubs — Azure Event Hubs | Microsoft Learn.

• Po włączeniu dzienników metryk aplikacji należy utworzyć i korzystać z danych z przestrzeni nazw przez kilka minut, zanim zaczniesz wyświetlać 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 zdarzeń mogą publikować dane w przestrzeniach nazw replikowanych geograficznie za pośrednictwem stabilnej nazwy FQDN przestrzeni nazw replikowanej geograficznie. Podejście do publikowania zdarzeń jest takie samo jak w przypadku odzyskiwania po awarii geograficznej i nie są wymagane żadne zmiany w aplikacjach klienckich.

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

• W okresie prolongaty trybu failover istniejący region podstawowy odrzuca wszelkie nowe zdarzenia publikowane w centrum zdarzeń.
• Gdy opóźnienie replikacji między regionami podstawowymi i pomocniczymi osiągnie maksymalny czas trwania opóźnienia replikacji, obciążenie ruchu przychodzącego wydawcy 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 z zdarzeń mogą korzystać z danych przy użyciu stabilnej nazwy FQDN przestrzeni nazw replikowanej geograficznie. Operacje konsumentów nie są obsługiwane, od momentu zainicjowania trybu failover do momentu jego ukończenia.

Zarządzanie punktami kontrolnymi/przesunięciem

Aplikacje korzystające z zdarzeń mogą nadal utrzymywać zarządzanie przesunięciem, tak jak w przypadku pojedynczej przestrzeni nazw.

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ąć korzystać z miejsca, w którym została przerwana w regionie podstawowym.

Zestaw SDK usługi Event Hubs/AMQP

Klienci korzystający z zestawu SDK usługi Event Hubs muszą przeprowadzić uaktualnienie do wersji zestawu SDK z kwietnia 2024 r. Najnowsza wersja zestawu SDK usługi Event Hubs obsługuje tryb failover z aktualizacją punktu kontrolnego. 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.

Cennik

Dedykowane klastry usługi Event Hubs są wyceniane niezależnie od replikacji geograficznej. Korzystanie z replikacji geograficznej z dedykowanymi usługami Event Hubs wymaga posiadania co najmniej dwóch dedykowanych klastrów w oddzielnych regionach. Dedykowane klastry używane jako wystąpienia pomocnicze na potrzeby replikacji geograficznej mogą być używane w przypadku innych obciążeń. Opłata za replikację geograficzną zależy od opublikowanej przepustowości * liczby regionów pomocniczych. Opłata za replikację geograficzną zostanie zrzeknięta we wczesnej publicznej wersji zapoznawczej.

Powiązana zawartość

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