Georeplikation in Azure Event Hubs

Das Feature "Event Hubs Geo-replikation" stellt die Replikation von Metadaten (Entitäten, Konfiguration und Eigenschaften) und Daten (Ereignisnutzlasten) für den Namespace bereit, sodass Geschäftskontinuität und Notfallwiederherstellung möglich sind.

Mit diesem Feature wird sichergestellt, dass Metadaten und Daten eines Namespace kontinuierlich aus einer primären Region in die sekundäre Region repliziert werden. Der Namespace kann als auf mehr als eine Region erweitert betrachtet werden, wobei eine Region die primäre und die andere die sekundäre ist.

Die sekundäre Region kann jederzeit zur primären Region heraufgestuft werden. Durch das Höherstufen einer sekundären Domäne zeigt der Namespace-FQDN (vollqualifizierter Domänenname) auf die ausgewählte sekundäre Region, und die vorherige primäre Region wird zu einer sekundären Region herabgestuft.

Szenarien

Event Hubs Geo-Replikation kann in mehreren verschiedenen Szenarien verwendet werden, wie hier beschrieben.

Sicherstellen von Geschäftskontinuität und Notfallwiederherstellung

Georeplikation stellt die Notfallwiederherstellung und Geschäftskontinuität für alle Streamingdaten in Ihrem Namespace sicher. Durch replizierte Daten in allen Regionen können Organisationen vor Datenverlust schützen und sicherstellen, dass ihre Anwendungen auch bei einem regionalen Ausfall betriebsbereit bleiben. Dieses Feature ist für unternehmenskritische Anwendungen von entscheidender Bedeutung, die hohe Verfügbarkeit und minimale Ausfallzeiten erfordern.

Globale Datenverteilung

Georeplikation kann verwendet werden, um Daten global zu verteilen, sodass Anwendungen auf Daten aus der nächstgelegenen Region zugreifen können. Dadurch wird die Latenz reduziert und die Leistung für Workloads in verschiedenen Teilen der Welt verbessert.

Datenhoheit und Compliance

Organisationen, die in mehreren Ländern/Regionen tätig sind, müssen häufig Datenhoheitsgesetze einhalten, die die Speicherung von Daten innerhalb bestimmter geografischer Grenzen erfordern. Die Georeplikation ermöglicht es diesen Organisationen, Daten in Regionen zu replizieren, die lokale Vorschriften einhalten, um sicherzustellen, dass sie gesetzliche Anforderungen erfüllen und gleichzeitig eine einheitliche Datenplattform beibehalten.

Migration und Upgrades

Georeplikation kann auch verwendet werden, um Datenmigration, Wartung und Systemupgrades zu vereinfachen. Organisationen können ihren Namespace proaktiv von einer primären zu einer sekundären Region migrieren, um Wartungs- und Upgrades in der primären Region zu ermöglichen.

Grundkonzepte

Das Geo-Replikationsmerkmal implementiert die Replikation von Metadaten und Daten in einem Primär-Sekundär-Replikationsmodell. Zu einem bestimmten Zeitpunkt gibt es eine einzige primäre Region, die sowohl Produzenten als auch Verbrauchern zur Verfügung steht. Die Sekundäre fungiert als heiße Stand-by-Region, was bedeutet, dass es nicht möglich ist, mit diesen sekundären Regionen zu interagieren. Sie werden jedoch in derselben Konfiguration wie die primäre Region betrieben, was eine schnelle Höherstufung ermöglicht, sodass sie nach Abschluss der Höherstufung sofort einsatzbereit sind.

Einige der wichtigsten Aspekte der Geodatenreplikationsfunktion sind:

• Primär-Sekundär-Replikationsmodell – Die Georeplikation basiert auf dem Primär-Sekundär-Replikationsmodell, bei dem es zu einem bestimmten Zeitpunkt nur einen primären Namespace gibt, der sowohl Ereignisproduzenten als auch Ereigniskonsumenten bedient.
• Event Hubs führt eine vollständig verwaltete Byte-zu-Byte-Replikation von Metadaten, Ereignisdaten und Consumeroffsets mit den konfigurierten Konsistenzebenen über sekundäre Namespaces hinweg aus.
• Einzelner Namespace-Hostname – Bei erfolgreicher Konfiguration eines Geo-Replication aktivierten Namespaces können Benutzer den Namespace-Hostname in ihrer Clientanwendung verwenden. Der Hostname verhält sich unabhängig von den konfigurierten primären und sekundären Regionen und verweist immer auf die primäre Region.
• Wenn ein Kunde eine Höherstufung initiiert, verweist der Hostname auf die Region, die als neue primäre Region ausgewählt ist. Die alte primäre Region wird zu einer sekundären Region.
• Es ist nicht möglich, Lese- oder Schreibvorgänge für die sekundären Regionen durchzuführen.
• Die kundenseitig verwaltete Höherstufung von der primären zur sekundären Region ermöglicht für den Fall von Ausfällen die vollständige Besitzübertragung und Sichtbarkeit. Es sind Metriken verfügbar, die dazu beitragen können, die Höherstufung kundenseitig zu automatisieren. Sekundäre Regionen können nach eigenem Ermessen des Kunden hinzugefügt oder entfernt werden.
• Replikationskonsistenz: Es gibt zwei Einstellungen für die Replikationskonsistenz – synchron und asynchron.

Staat	Diagramm
Vor dem Failover (Höherstufung der sekundären Region)
Nach Failover (Höherstufung der sekundären Region)

Replikationsmethoden

Für die Replikationskonsistenz gibt es zwei Konfigurationen: synchron und asynchron. Es ist wichtig, die Unterschiede zwischen den beiden Konfigurationen zu kennen, da sie Auswirkungen auf Ihre Anwendungen und Ihre Datenkonsistenz haben.

Asynchrone Replikation

Bei Verwendung der asynchronen Replikation werden alle Anforderungen an die primäre Region committet, wonach eine Bestätigung an den Client gesendet wird. Die Replikation an die sekundären Regionen erfolgt asynchron. Benutzer können den maximalen zulässigen Zeitabstand konfigurieren – der dienstseitige Offset zwischen der neuesten Aktion für die primäre und die sekundären Regionen. Der Dienst repliziert kontinuierlich die Daten und Metadaten, um sicherzustellen, dass die Verzögerung so klein wie möglich bleibt. Wenn die Verzögerung für eine aktive sekundäre Instanz die vom Benutzer konfigurierte maximale Replikationsverzögerung übersteigt, beginnt die primäre Instanz mit der Drosselung eingehender Anforderungen.

Synchrone Replikation

Bei Verwendung der synchronen Replikation werden alle Anforderungen an die sekundäre Region repliziert, die den Vorgang vor dem Commit an die primäre Region committen und bestätigen muss. Ihre Anwendung veröffentlicht Elemente daher mit der Geschwindigkeit, die zum Veröffentlichen, Replizieren, Bestätigen und Committen benötigt wird. Darüber hinaus bedeutet dies auch, dass Ihre Anwendung an die Verfügbarkeit beider Regionen gebunden ist. Wenn die sekundäre Region eine Verzögerung aufweist oder nicht verfügbar ist, werden Nachrichten nicht bestätigt und festgeschrieben, und die primäre Region drosselt eingehende Anfragen.

Vergleich der Replikationskonsistenz

Bei Verwendung der synchronen Replikation:

• Die Latenz ist aufgrund der verteilten Commitvorgänge höher.
• Die Verfügbarkeit ist an die Verfügbarkeit von zwei Regionen gebunden. Wenn eine Region ausfällt, ist Ihr Namespace nicht verfügbar.

Andererseits bietet die synchrone Replikation die größte Sicherheit, dass Ihre Daten geschützt sind. Wenn Sie die synchrone Replikation nutzen, erfolgen Commits in alle Regionen, die Sie für die Georeplikation konfiguriert haben, sodass die bestmögliche Datensicherheit gewährleistet wird.

Bei Verwendung der asynchronen Replikation:

• Die Latenz wird minimal beeinträchtigt.
• Der Verlust einer sekundären Region wirkt sich nicht sofort auf die Verfügbarkeit aus. Die Verfügbarkeit wird jedoch beeinträchtigt, sobald die konfigurierte maximale Replikationsverzögerung erreicht ist.

Daher bietet sie keine absolute Garantie, dass alle Regionen vor dem Commit wie bei der synchronen Replikation über die Daten verfügen, und es können Datenverluste oder Duplizierungen auftreten. Da es jedoch keine sofortigen Auswirkungen mehr hat, wenn eine einzelne Region eine Verzögerung aufweist oder nicht verfügbar ist, kann die Anwendungsverfügbarkeit zusätzlich zu einer geringeren Latenz verbessert werden.

Der Replikationsmodus kann nach der Konfiguration der Georeplikation geändert werden. Sie können vom synchronen zum asynchronen bzw. vom asynchronen zum synchronen Modus wechseln. Wenn Sie vom asynchronen zum synchronen Modus wechseln, wird Ihr Sekundär als synchron konfiguriert, nachdem die Verzögerung null erreicht. Wenn bei der Ausführung aus irgendeinem Grund eine kontinuierliche Verzögerung vorliegt, müssen Sie Ihre Herausgeberkomponenten möglicherweise anhalten, damit der Verzögerungswert 0 erreicht wird und der Modus in „synchron“ geändert werden kann. Die Gründe für die Aktivierung der synchronen Replikation anstelle der asynchronen Replikation sind an die Bedeutung der Daten, spezifischen Geschäftsanforderungen oder Compliancegründe gebunden, anstatt an die Verfügbarkeit Ihrer Anwendung.

Auswahl der sekundären Region

Um das Georeplikationsfeature zu aktivieren, müssen Sie primäre und sekundäre Regionen verwenden, in denen das Feature aktiviert ist. Das Georeplikationsfeature hängt davon ab, ob veröffentlichte Nachrichten von der primären Region in die sekundäre Region repliziert werden können. Wenn sich die sekundäre Region auf einem anderen Kontinent befindet, hat dies erhebliche Auswirkungen auf die Replikationsverzögerung von der primären Region in die sekundäre Region. Wenn Sie die Georeplikation aus Verfügbarkeitsgründen verwenden, empfiehlt es sich, wenn sich die sekundären Regionen nach Möglichkeit mindestens auf demselben Kontinent befinden. Um die durch geografische Entfernung verursachte Latenz besser zu verstehen, informieren Sie sich über Azure-Netzwerk-Statistiken zur Round-Trip-Latenz.

Verwaltung der Georeplikation

Mit dem Georeplikationsfeature können Kunden eine sekundäre Region konfigurieren, in die Metadaten und Daten repliziert werden sollen. Kunden können daher die folgenden Verwaltungsaufgaben ausführen:

• Konfigurieren der Georeplikation – Sekundäre Regionen können für jeden neuen oder vorhandenen Namespace in einer Region konfiguriert werden, wobei das feature Geo-Replication aktiviert ist.
• Konfigurieren Sie die Replikationskonsistenz : Synchrone und asynchrone Replikation wird festgelegt, wenn Geo-Replication konfiguriert ist, aber auch danach gewechselt werden kann.
• Auslösen von Höherstufung/Failover – Alle Höherstufungen werden vom Kunden initiiert.
• Entfernen Sie eine sekundäre – Wenn Sie einen sekundären Bereich jederzeit entfernen möchten, können Sie dies tun, nachdem die Daten im sekundären Bereich gelöscht wurden.

Kriterien zum Auslösen von Werbung

Hier sind einige Fälle, in denen eine Heraufstufung einer sekundären Instanz in eine primäre ausgelöst werden kann.

• Regionaler Ausfall: Wenn sich ein regionaler Ausfall auf die primäre Region auswirkt, sollten Sie die sekundäre Region bewerben, um die Geschäftskontinuität sicherzustellen und Ausfallzeiten zu minimieren.

• Wartungsaktivitäten: Während geplanter Wartungsaktivitäten in der primären Region kann die Förderung der sekundären Region dazu beitragen, die hohe Verfügbarkeit für unternehmenskritische Anwendungen aufrechtzuerhalten.

• Notfallwiederherstellung: Im Falle einer Katastrophe, die sich auf die primäre Region auswirkt, stellt die Förderung der sekundären Region sicher, dass Ihre Daten weiterhin zugänglich bleiben und Ihre Anwendungen weiterhin funktionieren.

• Leistungsprobleme: Wenn in der primären Region Leistungsprobleme auftreten, die sich auf die Verfügbarkeit oder Zuverlässigkeit Ihrer Event Hubs auswirken, kann die Förderung der sekundären Region dazu beitragen, diese Probleme zu beheben.

Es wird empfohlen, gelegentlich Failovermechanismen zu testen, um sicherzustellen, dass der Geschäftskontinuitätsplan effektiv ist, und Ihre Anwendungen können bei Bedarf nahtlos zur sekundären Region wechseln.

Überwachen der Datenreplikation

Benutzer können den Fortschritt des Replikationsauftrags mithilfe der Metrik „Replikationsverzögerung“ in den Anwendungsmetrikprotokollen überwachen.

• Aktivieren Sie die Anwendungsmetrikprotokolle in Ihrem Event Hubs-Namespace wie unter Überwachung von Azure Event Hubs: Azure Event Hubs | Microsoft Learn beschrieben.

• Nachdem die Anwendungsmetrikprotokolle aktiviert wurden, müssen Sie einige Minuten lang über den Namespace Daten erzeugen und nutzen, damit die Protokolle angezeigt werden.

• Um Anwendungsmetrikprotokolle anzuzeigen, navigieren Sie zum Abschnitt Überwachung der Seite „Event Hubs“, und wählen Sie im linken Menü Protokolle aus. Mit der folgenden Abfrage können Sie die Replikationsverzögerung (in Sekunden) zwischen den primären und sekundären Namespaces ermitteln.

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

• Die Spalte count_d gibt die Replikationsverzögerung zwischen der primären und der sekundären Region in Sekunden an.

Veröffentlichen von Daten

Veröffentlichungsanwendungen können Daten über den Namespace-Hostnamen des Namespaces mit aktivierter Georeplikation für georeplizierte Namespaces veröffentlichen. Der Veröffentlichungsansatz ist identisch mit dem Fall der Nicht-Georeplikation, und es sind keine Änderungen an Datenebenen-SDKs oder Clientanwendungen erforderlich.

Die Ereignisveröffentlichung ist unter den folgenden Umständen möglicherweise nicht verfügbar:

• Nach dem Anfordern einer Heraufgestufung einer sekundären Region lehnt die vorhandene primäre Region alle neuen Ereignisse ab, die im Event Hub veröffentlicht werden.
• Wenn die Replikationsverzögerung zwischen primären und sekundären Regionen die maximale Dauer der Replikationsverzögerung erreicht, wird die Eingangsworkload des Herausgebers möglicherweise gedrosselt.

Herausgeberanwendungen können nicht direkt auf Namespaces in den sekundären Regionen zugreifen.

Verwenden von Daten

Verbrauchsanwendungen können Daten mithilfe des Namespace-Hostnamens eines Namespaces verwenden, für den das Georeplikationsfeature aktiviert ist. Verbrauchervorgänge werden ab dem Zeitpunkt, zu dem die Höherstufung initiiert wird, nicht unterstützt. Sie werden erst unterstützt, wenn die Höherstufung abgeschlossen ist.

Prüfpunkt-/Offsetverwaltung

Anwendungen, die Ereignisse nutzen, können die Offsetverwaltung weiterhin wie bei einem nicht georeplizierten Namespace vornehmen. Für die Offsetverwaltung für georeplikationsfähige Namespaces sind keine besonderen Überlegungen erforderlich.

Kafka

Offsets werden direkt in Event Hubs committet und regionsübergreifend repliziert. Verbraucher können daher den Verbrauch von dort fortsetzen, wo es in der primären Region unterbrochen wurde.

Hier sind die Liste der Apache Kafka-Clients, die unterstützt werden -

Im Fall anderer Bibliotheken werden diejenigen, die die folgenden API-Versionen verwenden, unterstützt :

Event Hubs SDK/AMQP

Bei AMQP wird der Prüfpunkt von Benutzern mit einem Prüfpunktspeicher wie Azure Blob Storage oder einer benutzerdefinierten Speicherlösung verwaltet. Wenn ein Failover stattfindet, muss der Prüfpunktspeicher über die sekundäre Region verfügbar sein, damit Clients Prüfpunktdaten abrufen und den Verlust von Nachrichten vermeiden können.

Die neueste Version des Event Hubs SDK hat einige Änderungen an der Prüfpunktdarstellung vorgenommen, um Failovers zu unterstützen. Es wird empfohlen, die neuesten Versionen der SDKs zu verwenden, aber auch frühere Versionen der folgenden SDKs werden unterstützt.

Überlegungen

Beachten Sie die folgenden Überlegungen, die Sie bei diesem Feature berücksichtigen sollten:

• Bei der Planung einer Höherstufung sollten Sie auch den Zeitfaktor berücksichtigen. Falls beispielsweise die Verbindung länger als 15 bis 20 Minuten ausfällt, könnten Sie sich entscheiden, die Werbeaktion einzuleiten.
• Die Höherstufung einer komplexen verteilten Infrastruktur sollte mindestens einmal getestet werden.

Preiskalkulation

Die Preise variieren je nach ausgewählter Stufe, haben jedoch im Allgemeinen 2 Parameter -

• Die Computegebühr für den Cluster oder Namespace.
• Die Bandbreitengebühr für die Daten, die zwischen den primären und sekundären Regionen repliziert werden.

Dedizierte Cluster

Die Verwendung der Georeplikation mit dedizierten Event Hubs erfordert, dass Sie mindestens zwei dedizierte Cluster in separaten Regionen haben, die zum Hosten von Namespaces verwendet werden können, abgesehen von demjenigen, der georepliziert wird. Diese dedizierten Cluster werden separat anhand der Anzahl der einzelnen Kapazitätseinheiten (Capacity Units, CUs) abgerechnet.

Wenn die Georeplikation aktiviert ist, ist die einzige zusätzliche Gebühr die Bandbreitengebühr für die daten, die von primär auf sekundär repliziert wurden. Diese Gebühr hängt vom Standort der primären Region ab.

Premium-Namespaces

Für Premium-Namespaces stellt die Aktivierung der Georeplikation dieselbe Anzahl von Verarbeitungseinheiten (PUs) in der sekundären Region bereit. Daher bezahlen Sie die Anzahl der verwendeten PUs und die Bandbreite für die zwischen der primären und sekundären Region übertragenen Daten.

Wenn Sie z. B. die Georeplikation für einen Premium-Namespace aktivieren, der mit 4 PU bereitgestellt wurde, werden Ihnen die entsprechenden Kosten in Rechnung gestellt.

• 4 PUs in der primären Region,
• 4 PUs in der sekundären Region,
• Georeplikationsgebühr pro GB replizierter Daten.

Die Bandbreite wird basierend auf den zwischen den primären und sekundären Regionen übertragenen Daten berechnet.

Preise für Verbrauchseinheiten

Die Preise für Verbrauchseinheiten für die Bandbreitengebühren der Datenübertragung bei der Georeplikation werden mit den folgenden Details angezeigt.

Private Endpunkte

Dieser Abschnitt enthält zusätzliche Überlegungen bei der Verwendung von Geo-Replication mit Namespaces, die private Endpunkte verwenden. Allgemeine Informationen zur Verwendung privater Endpunkte mit Event Hubs finden Sie unter Integrieren von Azure Event Hubs in Azure Private Link.

Bei der Implementierung von Geo-Replication für einen Event Hubs-Namespace, der private Endpunkte verwendet, ist es wichtig, private Endpunkte sowohl für die primären als auch für sekundäre Regionen zu erstellen. Diese Endpunkte sollten für virtuelle Netzwerke konfiguriert werden, die sowohl primäre als auch sekundäre Instanzen Ihrer Anwendung hosten. Wenn Sie beispielsweise über zwei virtuelle Netzwerke verfügen, VNET-1 und VNET-2, müssen Sie zwei private Endpunkte im Event Hubs-Namespace erstellen, wobei Subnetze von VNET-1 bzw. VNET-2 verwendet werden. Darüber hinaus sollten die VNETs mit regionsübergreifendem Peering eingerichtet werden, damit Clients mit einem der privaten Endpunkte kommunizieren können. Schließlich muss das DNS so verwaltet werden, dass alle Clients die DNS-Informationen abrufen, die den Namespaceendpunkt (namespacename.servicebus.windows.net) auf die IP-Adresse des privaten Endpunkts in der aktuellen primären Region verweisen sollten.

Der Vorteil dieses Ansatzes besteht darin, dass Failover unabhängig auf der Anwendungsschicht oder im Event Hubs-Namespace erfolgen kann:

• Nur-Anwendungsfailover: In diesem Szenario wechselt die Anwendung von VNET-1 zu VNET-2. Da private Endpunkte sowohl für VNET-1 als auch für VNET-2 für primäre und sekundäre Namespaces konfiguriert sind, funktioniert die Anwendung weiterhin nahtlos.
• Nur Failover des Event Hubs-Namespace: Wenn das Failover nur auf Event Hubs-Namespaceebene erfolgt, bleibt die Anwendung betriebsbereit, da in beiden virtuellen Netzwerken private Endpunkte konfiguriert sind.

Anhand dieser Richtlinien können Sie stabile und zuverlässige Failovermechanismen für Ihre Event Hubs-Namespaces mithilfe privater Endpunkte sicherstellen.

Zugehöriger Inhalt

Informationen zur Verwendung des Features „Georeplikation“ finden Sie unter Verwenden der Georeplikation.