Azure Service Bus-Georeplikation (Vorschau)

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Verwenden der Azure CLI

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': '<newPrimaryLocation>', '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

• Lesen der REST-API-Referenz zur Georeplikation
• Ausführen des Georeplikationsbeispiels auf GitHub
• Testen des Georeplikationsbeispiels zum Senden von Nachrichten an Aliase

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

• Service Bus-Warteschlangen, -Themen und -Abonnements
• Erste Schritte mit Service Bus-Warteschlangen
• Verwenden von Service Bus-Themen und -Abonnements
• REST-API