Freigeben über

Azure Service Bus-Georeplikation (Vorschau)

  • Artikel

Das Service Bus-Georeplikationsfeature ist eine der Optionen zum Isolieren von Azure Service Bus-Anwendungen gegen Ausfälle und Katastrophen. Es ermöglicht die Replikation von Metadaten (Entitäten, Konfigurationen, Eigenschaften) und Daten (Nachrichtendaten sowie Status- und Eigenschaftsänderungen von Nachrichten).

Hinweis

Dieses Feature ist für den Premium-Tarif von Azure Service Bus verfügbar.

Das Georeplikationsfeature stellt sicher, dass die Metadaten und Daten eines Namespaces kontinuierlich aus einer primären Region in eine oder mehrere sekundäre Regionen repliziert werden.

  • Warteschlangen, Themen, Abonnements, Filter
  • Daten, die sich in den Entitäten befinden
  • Alle Status- und Eigenschaftsänderungen, die für die Nachrichten in einem Namespace ausgeführt werden
  • Namespacekonfiguration

Hinweis

Derzeit wird nur eine einzelne sekundäre Region unterstützt.

Dieses Feature ermöglicht es, jede sekundäre Region jederzeit zur primären Region höherzustufen. Durch das Höherstufen einer sekundären Region verweist der Name für den Namespace auf die ausgewählte sekundäre Region, und die Rollen der primären bzw. sekundären Region werden getauscht. Die Höherstufung erfolgt fast unmittelbar nach der Initiierung.

Wichtig

  • Dieses Feature befindet sich derzeit in der Public Preview und sollte daher nicht in Produktionsszenarien verwendet werden.
  • Die folgenden Regionen werden derzeit in der Public Preview unterstützt.
Region Region Region
Australien,Mitte DeutschlandNorden NorwayWest
Australien, Mitte 2 GermanyWestCentral PolenMitte
Australien, Osten IsraelCentral Südafrika, Nord
AustraliaSoutheast ItalyNorth Südafrika, West
BrazilSoutheast JapanEast SoutheastAsia
Kanada,Mitte Japan, Westen SouthIndia
Kanada,Osten JioIndiaCentral SpainCentral
CentralIndia JioIndiaWest SwedenCentral
USA, Mitte KoreaCentral SchweizNorden
CentralUSEUAP KoreaSouth SchweizWesten
Asien, Osten MexicoCentral UAECentral
EastUS2 NorthCentralUS UAENorth
Frankreich, Mitte Europa, Norden UKSouth
Frankreich, Süden NorwayEast UK, Westen
  • Dieses Feature ist derzeit für neue Namespaces verfügbar. Wenn dieses Feature zuvor für einen Namespace aktiviert war, kann es deaktiviert (durch Entfernen der sekundären Regionen) und erneut aktiviert werden.
  • Die folgenden Features werden derzeit nicht unterstützt. Wir arbeiten kontinuierlich daran, weitere Features in der Public Preview bereitzustellen und aktualisieren diese Liste mit den neuesten Status.
    • Unterstützung umfangreicher Nachrichten
    • VNET/erweiterte Netzwerkfeatures (private Endpunkte, IP-ACLs, NSP, Dienstendpunkte)
    • Identitäten (MSI, Deaktivieren der lokalen Authentifizierung) und Verschlüsselungseinstellungen (Verschlüsselung kundenseitig verwalteter Schlüssel (CMK) oder Bring-Your-Own-Key-Verschlüsselung (BYOK))
    • Automatische Skalierung
    • Partitionierte Namespaces
    • Senden von Ereignissen an Event Grid
  • Dieses Feature kann nicht in Kombination mit dem Azure Service Bus-Feature für die georedundante Notfallwiederherstellung verwendet werden.

Szenarien

Das Georeplikationsfeature kann wie hier beschrieben verwendet werden, um verschiedene Szenarios zu implementieren.

Notfallwiederherstellung

Daten und Metadaten werden kontinuierlich zwischen den primären und sekundären Regionen synchronisiert. Wenn eine Region Verzögerungen aufweist oder nicht verfügbar ist, ist es möglich, eine sekundäre Region zur primären Region höherzustufen. Diese Höherstufung ermöglicht den unterbrechungsfreien Betrieb von Workloads in der nun höhergestuften Region. Eine solche Höherstufung kann durch die Leistungsminderung von Service Bus oder anderen Diensten innerhalb der Workload erforderlich sein, insbesondere dann, wenn Sie die verschiedenen Komponenten gemeinsam ausführen möchten. Je nach Schweregrad und betroffenen Diensten kann die Höherstufung entweder geplant oder erzwungen werden. Im Falle einer geplanten Höherstufung werden In-Flight-Nachrichten vor Abschluss der Höherstufung repliziert, während dieser Vorgang bei einer erzwungenen Höherstufung sofort durchgeführt wird.

Regionsmigration

Es gibt Zeiten, in denen Sie Ihre Service Bus-Workloads migrieren möchten, um sie in einer anderen Region auszuführen. Dies könnte beispielsweise der Fall sein, wenn Azure eine neue Region hinzufügt, die Ihrem Standort, Ihren Benutzern oder anderen Diensten näher liegt. Möglicherweise ist auch eine Migration erforderlich, wenn die Regionen verschoben werden, in denen die meisten Workloads ausgeführt werden. Das Georeplikationsfeature stellt auch in diesen Fällen eine geeignete Lösung bereit. In diesem Fall würden Sie die Georeplikation für Ihren vorhandenen Namespace mit der gewünschten neuen Region als sekundäre Region einrichten und warten, bis die Synchronisierung abgeschlossen ist. An diesem Punkt würden Sie eine geplante Höherstufung initiieren, sodass alle In-Flight-Nachrichten repliziert werden können. Nachdem die Höherstufung abgeschlossen ist, können Sie nun optional die alte Region entfernen, die jetzt die sekundäre Region ist, und Ihre Workloads in der gewünschten Region weiter ausführen.

Grundlegende Konzepte

Das Georeplikationsfeature implementiert die Replikation von Metadaten und Daten in einem Replikationsmodell mit primärer und sekundärer Region. Zu einem bestimmten Zeitpunkt gibt es eine einzige primäre Region, die sowohl Produzenten als auch Verbrauchern zur Verfügung steht. Die sekundären Regionen fungieren als betriebsbereite Stand-by-Regionen, 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 ausgeführt, was eine schnelle Höherstufung ermöglicht und bedeutet, dass Ihre Workloads sofort nach Abschluss der Höherstufung weiter ausgeführt werden können. Das Georeplikationsfeature ist für den Premium-Tarif verfügbar.

Dies sind einige der wichtigsten Aspekte des Georeplikationsfeatures:

  • Service Bus-Dienste führen die vollständig verwaltete Replikation von Metadaten, Nachrichtendaten sowie Nachrichtenstatus- und Eigenschaftsänderungen in allen Regionen aus, die der im Namespace konfigurierten Replikationskonsistenz entsprechen.
  • Einzelner Namespace-Hostname: Nach erfolgreicher Konfiguration eines georeplikationsfähigen Namespaces können Benutzer den Namespace-Hostnamen 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.
  • Synchrone und asynchrone Replikationsmodi (werden hier näher beschrieben)
  • 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.

Replikationsmodi

Es gibt zwei Replikationsmodi: synchron und asynchron. Es ist wichtig, die Unterschiede zwischen den beiden Modi zu kennen.

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 die maximal zulässige Verzögerungszeit konfigurieren. Die Verzögerungszeit ist der dienstseitige Offset zwischen der letzten Aktion für die primäre und sekundäre Region. Wenn die Verzögerung für eine aktive sekundäre Region die Benutzerkonfiguration überschreitet, beginnt die primäre Region damit, die eingehenden Anforderungen zu drosseln.

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 committet, und die primäre Region drosselt eingehende Anforderungen.

Vergleich der Replikationsmodi

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.

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.

Funktion Synchrone Replikation Asynchrone Replikation
Latency Länger aufgrund von verteilten Commitvorgängen Minimale Beeinträchtigung
Verfügbarkeit An die Verfügbarkeit von sekundären Regionen gebunden Der Verlust einer sekundären Region wirkt sich nicht sofort auf die Verfügbarkeit aus.
Datenkonsistenz Daten, die vor der Bestätigung immer in beide Regionen committet werden Daten, die nur vor der Bestätigung in die primäre Region committet werden
RPO (Recovery Point Objective) RPO 0, kein Datenverlust bei Höherstufung RPO > 0, mögliche Datenverluste bei Höherstufung

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 Ihre sekundäre Region als asynchron konfiguriert, nachdem der Verzögerungswert 0 erreicht hat. Wenn bei der Ausführung aus irgendeinem Grund eine kontinuierliche Verzögerung vorliegt, müssen Sie die herausgebenden Komponenten möglicherweise anhalten, damit der Verzögerungswert 0 erreicht wird und zum synchronen Modus gewechselt 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.

Hinweis

Falls eine sekundäre Region eine Verzögerung aufweist oder nicht verfügbar ist, kann die Anwendung nicht mehr in diese Region replizieren und startet die Drosselung, sobald der Replikationsverzögerungswert erreicht ist. Um den Namespace weiterhin in der primären Region zu verwenden, kann die betroffene sekundäre Region entfernt werden. Wenn keine weiteren sekundären Regionen konfiguriert sind, werden die Vorgänge für den Namespace ohne aktivierte Georeplikation fortgesetzt. Es ist jederzeit möglich, zusätzliche sekundäre Regionen hinzuzufügen.

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. Lesen Sie den Artikel Roundtrip-Latenzstatistiken von Azure-Netzwerken, um ein besseres Verständnis der Latenz zu erhalten, die durch geografische Entfernungen verursacht wird.

Georeplikationsverwaltung

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 mit aktiviertem Georeplikationsfeature konfiguriert werden.

    Hinweis

    In der Public Preview werden derzeit nur neue Namespaces unterstützt.

  • Konfigurieren der Replikationskonsistenz: Die synchrone und asynchrone Replikation wird beim Konfigurieren der Georeplikation festgelegt, kann aber später geändert werden.
  • Auslösen der Höherstufung: Alle Höherstufungen werden vom Kunden initiiert.
  • Entfernen einer sekundären Region: Wenn Sie eine sekundäre Region zu einem beliebigen Zeitpunkt entfernen möchten, können Sie dies tun, nachdem die Daten in der sekundären Region gelöscht wurden.

Setup

Verwenden des Azure-Portals

Im folgenden Abschnitt finden Sie eine Übersicht zum Einrichten des Georeplikationsfeatures für einen neuen Namespace über das Azure-Portal.

Hinweis

Diese Option kann sich während der Public Preview ändern. Dieses Dokument wird entsprechend aktualisiert.

  1. Erstellen Sie einen neuen Namespace im Premium-Tarif.
  2. Aktivieren Sie das Kontrollkästchen Georeplikation aktivieren unter dem Abschnitt Replikation (Vorschau).
  3. Klicken Sie auf die Schaltfläche Sekundäre Region hinzufügen, und wählen Sie eine Region aus.
  4. Aktivieren Sie das Kontrollkästchen Synchrone Replikation, oder geben Sie einen Wert in Sekunden für Asynchrone Replikation – maximale Replikationsverzögerung an. Screenshot: Option „Namespace erstellen“ mit aktivierter Georeplikation

Verwenden der Bicep-Vorlage

Um einen Namespace mit aktiviertem Georeplikationsfeature zu erstellen, fügen Sie den Eigenschaftenabschnitt geoDataReplication hinzu.

param serviceBusName string
param primaryLocation string
param secondaryLocation string
param maxReplicationLagInSeconds int

resource sb 'Microsoft.ServiceBus/namespaces@2023-01-01-preview' = {
  name: serviceBusName
  location: primaryLocation
  sku: {
    name: 'Premium'
    tier: 'Premium'
    capacity: 1
  }
  properties: {
    geoDataReplication: {
      maxReplicationLagDurationInSeconds: maxReplicationLagInSeconds
      locations: [
        {
          locationName: primaryLocation
          roleType: 'Primary'
        }
        {
          locationName: secondaryLocation
          roleType: 'Secondary'
        }
      ]
    }
  }
}

Verwaltung

Nachdem Sie einen Namespace mit aktiviertem Georeplikationsfeature erstellt haben, können Sie das Feature über das Blatt Replikation (Vorschau) verwalten.

Ändern des Replikationsmodus

Um zwischen Replikationsmodi zu wechseln oder die maximale Replikationsverzögerung zu aktualisieren, klicken Sie auf den Link unter Replikationskonsistenz. Klicken Sie dann auf das Kontrollkästchen, um die synchrone Replikation zu aktivieren bzw. deaktivieren, oder aktualisieren Sie den Wert im Textfeld, um den maximalen Verzögerungswert für die asynchrone Replikation zu ändern. Screenshot: Aktualisieren der Konfiguration des Georeplikationsfeatures

Löschen der sekundären Region

Um eine sekundäre Region zu entfernen, klicken Sie auf die Auslassungspunkte ... neben der Region, und wählen Sie Löschen aus. Um die Region zu löschen, folgen Sie den Anweisungen auf dem Popupblatt. Screenshot: Löschen einer sekundären Region

Höherstufungsflow

Eine Höherstufung wird manuell vom Kunden (entweder explizit über einen Befehl oder über clienteigene Geschäftslogik, die den Befehl auslöst) und nie von Azure ausgelöst. Dadurch erhält der Kunde vollständigen Besitz und vollständige Transparenz für die Auflösung von Ausfällen im Backbone von Azure. Wenn Sie den Höherstufungstyp Geplant auswählen, wartet der Dienst vor Initiierung der Höherstufung, bis die Replikationsverzögerung aufgeholt wurde. Wenn Sie jedoch den Höherstufungstyp Erzwungen auswählen, initiiert der Dienst die Höherstufung sofort. Für den Namespace wird ab dem Zeitpunkt der schreibgeschützte Modus festgelegt, zu dem eine Höherstufung angefordert wird, bis die Höherstufung abgeschlossen ist. Es ist jederzeit möglich, eine erzwungene Höherstufung durchzuführen, nachdem eine geplante Höherstufung initiiert wurde. Dadurch kann der Benutzer die Höherstufung beschleunigen, wenn ein geplantes Failover länger dauert als gewünscht.

Wichtig

Wenn Sie den Höherstufungstyp Erzwungen verwenden, gehen möglicherweise alle Daten verloren, die nicht repliziert wurden.

Nach dem Initiieren der Höherstufung:

  1. Der Hostname wird aktualisiert, um auf die sekundäre Region zu verweisen. Dieser Vorgang kann einige Minuten dauern.

    Hinweis

    Sie können die aktuelle primäre Region ermitteln, indem Sie einen Pingbefehl initiieren: ping your-namespace-fully-qualified-name

  2. Clients stellen automatisch wieder eine Verbindung mit der sekundären Region her.

Screenshot: Höherstufungsflow von der primären zur sekundären Region im Portal

Sie können die Höherstufung entweder mit Überwachungssystemen oder mit benutzerdefinierten Überwachungslösungen automatisieren. Für diese Art der Automatisierung sind aber zusätzliche Planungs- und Arbeitsschritte erforderlich, was den Rahmen dieses Artikels sprengen würde.

Verwenden des Azure-Portals

Klicken Sie im Portal auf das Symbol Höherstufen, und befolgen Sie die Anleitungen auf dem Popupblatt, um die Region zu löschen.

Screenshot: Flow zum Höherstufen der sekundären Region

Verwenden der Azure-Befehlszeilenschnittstelle

Führen Sie den Azure CLI-Befehl aus, um die Höherstufung zu initiieren. Die Force-Eigenschaft ist optional und standardmäßig auf false festgelegt.

az rest --method post --url https://management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/providers/Microsoft.ServiceBus/namespaces/<namespaceName>/failover?api-version=2023-01-01-preview --body "{'properties': {'PrimaryLocation': '<newPrimaryocation>', 'api-version':'2023-01-01-preview', 'Force':'false'}}"

Überwachen der Datenreplikation

Benutzer können den Fortschritt des Replikationsauftrags überprüfen, indem sie die Replikationsverzögerungsmetrik in Log Analytics überwachen.

  • Aktivieren Sie Metrikprotokolle im Service Bus-Namespace (wie unter Überwachen von Azure Service Bus beschrieben).
  • Sobald die Metrikprotokolle aktiviert sind, müssen Sie Daten über den Namespace erstellen und für einige Minuten nutzen, bevor die Protokolle angezeigt werden können.
  • Um Metrikprotokolle anzuzeigen, navigieren Sie zum Abschnitt „Überwachung“ von Azure Service Bus, und klicken Sie auf das Blatt Protokolle. Sie können die folgende Abfrage verwenden, um die Replikationsverzögerung (in Sekunden) zwischen den primären und sekundären Regionen zu ermitteln.
AzureMetrics
| where TimeGenerated > ago(1h)
| where MetricName == "ReplicationLagDuration"

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 Veröffentlichung ist unter den folgenden Umständen möglicherweise nicht verfügbar:

  • Nach dem Anfordern der Höherstufung einer sekundären Region lehnt die vorhandene primäre Region alle neuen Nachrichten ab, die in Service Bus veröffentlicht werden, bis die Höherstufung abgeschlossen ist.
  • Wenn die Replikationsverzögerung zwischen primären und sekundären Regionen die maximale Replikationsverzögerungsdauer erreicht, wird die Eingangsworkload des Herausgebers möglicherweise eingeschränkt.

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.

Überlegungen

Beachten Sie für diesen Release Folgendes:

  • 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, müssen Sie möglicherweise die Höherstufung initiieren.
  • Die Höherstufung einer komplexen verteilten Infrastruktur sollte mindestens einmal getestet werden.

Preiskalkulation

Der Premium-Tarif für Azure Service Bus wird pro Messagingeinheit abgerechnet. Mit dem Georeplikationsfeature werden sekundäre Regionen auf derselben Anzahl von MUs wie die primäre Region ausgeführt, und die Preise werden über die Gesamtzahl der MUs berechnet. Darüber hinaus fällt basierend auf Folgendem eine Gebühr an: Veröffentlichte Bandbreite × Anzahl der sekundären Regionen. Während der frühen Public Preview fällt diese Gebühr nicht an.

Nächste Schritte

Weitere Informationen zum Service Bus-Messaging finden Sie in folgenden Artikeln: