Georeplikation in Azure Web PubSub

Unternehmenskritische Apps müssen häufig über ein stabiles Failoversystem verfügen und Benutzern näher an ihrem Standort zur Verfügung stehen. Vor der Veröffentlichung des Georeplikationsfeatures mussten Entwickler mehrere Web PubSub-Ressourcen bereitstellen und benutzerdefinierten Code schreiben, um die Kommunikation ressourcenübergreifend zu orchestrieren. Mit der Schnellkonfiguration über das Azure-Portal können Sie dieses Feature jetzt ganz einfach aktivieren.

Nutzen der Verwendung der Georeplikation

• Widerstandsfähiger bei regionalen Ausfällen: Kommt es zu einem regionalen Ausfall, werden Clients automatisch an ein intaktes Replikat weitergeleitet.
• Regionsübergreifende Kommunikation: Entwickler verwenden wie gewohnt eine Ressource mit aktivierter Georeplikation, obwohl im Hintergrund mehrere Ressourcen vorhanden sind. Die replikatübergreifende Kommunikation wird vom Dienst verarbeitet.
• Verbesserte Netzwerkgeschwindigkeit: Geografisch verteilte Clients werden eine Verbindung mit dem nächstgelegenen Replikat herstellen. Diese Replikate kommunizieren über das globale Azure-Netzwerk-Backbone und sorgen für eine schnelle und stabile Netztechnologie.
• Erleichterte Verwaltung. Alle Replikate haben die gleiche Konfiguration wie die primäre Web PubSub-Ressource.

Voraussetzungen

• Eine Web PubSub-Ressource im Premium-Tarif

Beispiel eines Anwendungsfalls

Contoso, ein Social Media-Unternehmen

Contoso ist ein Social Media-Unternehmen, dessen Kundenbasis sich über die USA und Kanada erstreckt. Contoso stellt seinen Benutzern eine mobile App und eine Web-App bereit, damit sie miteinander in Kontakt treten können. Die Contoso-Anwendung wird in der Region „USA, Mitte“ bereitgestellt. Im Rahmen der Architektur von Contoso wird Web PubSub verwendet, um dauerhafte WebSocket-Verbindungen zwischen Client-Apps und dem Anwendungsserver einzurichten. Contoso schätzt es, dass das Verwalten von WebSocket-Verbindungen an Web PubSub ausgelagert werden kann, aber schätzt es nicht, Berichte darüber zu lesen, dass Benutzer in Kanada eine höhere Latenz erleben. Darüber hinaus möchte das Entwicklungsteam von Contoso die App vor einem regionalen Ausfall schützen, damit die Benutzer ohne Unterbrechungen auf die App zugreifen können.

Contoso könnte eine weitere Web PubSub-Ressource in „Kanada, Mitte“ einrichten, die geografisch näher an den Benutzern in Kanada liegt. Das Verwalten mehrerer Web PubSub-Instanzen birgt jedoch einige Herausforderungen:

1. Ein regionsübergreifender Kommunikationsmechanismus muss implementiert werden, damit Benutzer in Kanada und in den USA miteinander interagieren können.
2. Das Entwicklungsteam müsste zwei separate Web PubSub-Ressourcen verwalten, jeweils mit unterschiedlichen Domänen und Verbindungszeichenfolgen.
3. Bei einem regionalen Ausfall muss der Datenverkehr an eine verfügbare Ressource weitergeleitet werden.

All dies zieht Engineering-Ressourcen von der Fokussierung auf Produktinnovationen ab.

Verwenden der Geo-Replikationsfunktion

Mit dem neuen Feature für die Georeplikation kann Contoso nun ein Replikat in „Kanada, Mitte“ einrichten und die oben genannten Herausforderungen effektiv meistern. Das Entwicklerteam freut sich, dass es keine Codeänderungen vornehmen muss. Es ist so einfach, wie im Azure-Portal auf ein paar Schaltflächen zu klicken. Das Entwicklerteam freut sich auch, den Beteiligten mitteilen zu können, dass Contoso bei seinem Eintritt in den europäischen Markt einfach ein weiteres Replikat in Europa hinzufügen muss.

Aktivieren der Georeplikation in einer Web PubSub-Ressource

@description('The name for your Web PubSub service')
param primaryName string = 'contoso'

@description('The region in which to create your Web Pubsub service')
param primaryLocation string = 'eastus'

@description('Unit count of your Web PubSub service')
param primaryCapacity int = 1

resource primary 'Microsoft.SignalRService/webpubsub@2023-08-01-preview' = {
  name: primaryName
  location: primaryLocation
  sku: {
    capacity: primaryCapacity
    name: 'Premium_P1'
  }
  properties: {
  }
}

@description('The name for your Web PubSub replica')
param replicaName string = 'contoso-westus'

@description('The region in which to create the Web PubSub replica')
param replicaLocation string = 'westus'

@description('Unit count of the Web PubSub replica')
param replicaCapacity int = 1

@description('Whether to enable region endpoint for the replica')
param regionEndpointEnabled string = 'Enabled'

resource replica 'Microsoft.SignalRService/webpubsub/replicas@2023-08-01-preview' = {
  parent: primary
  name: replicaName
  location: replicaLocation
  sku: {
    capacity: replicaCapacity
    name: 'Premium_P1'
  }
  properties: {
    regionEndpointEnabled: regionEndpointEnabled
  }
}

az group create --name MyResourceGroup --location eastus
az deployment group create --resource-group MyResourceGroup --template-file main.bicep

az webpubsub replica create --sku Premium_P1 -l eastus --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Preise und Ressourceneinheit

Jedes Replikat verfügt über eigene Werte für unit und autoscale settings.

Replica ist eine Funktion der Premium-Stufe des Azure Web PubSub Service. Jedes Replikat wird nach ihrer eigener Einheit und dem ausgehenden Datenverkehr separat abgerechnet. Das kostenlose Nachrichtenkontingent wird ebenfalls separat berechnet.

Im vorherigen Beispiel hat Contoso eine Replik in Kanada Zentral hinzugefügt. Contoso würde für das Replikat in „Kanada, Mitte“ gemäß seiner Einheit und Nachricht im Premium-Preis bezahlen.

Es werden ausgehende Gebühren für grenzüberschreitenden ausgehenden Datenverkehr anfallen. Wenn eine Nachricht über Replikate hinweg übertragen und nach der Übertragung erfolgreich an einen Client oder Server gesendet wird, wird sie als ausgehende Nachricht in Rechnung gestellt.

Löschen eines Replikats

Nachdem Sie ein Replikat für eine Web PubSub-Ressource erstellt haben, können Sie es jederzeit löschen, wenn es nicht mehr benötigt wird.

So löschen Sie ein Replikat im Azure-Portal

1. Navigieren Sie zu Ihrer Web PubSub-Ressource, und wählen Sie das Blatt Replikate aus. Klicken Sie auf das Replikat, das Sie löschen möchten.
2. Klicken Sie auf dem Blatt „Replikatübersicht“ auf die Schaltfläche „Löschen“.

So löschen Sie ein Replikat mithilfe der Azure CLI

 az webpubsub replica delete --replica-name MyReplica --name MyWebPubSub -g MyResourceGroup

Verstehen, wie die Georeplikationsfunktion funktioniert

1. Der Client löst den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) contoso.webpubsub.azure.com des Web PubSub-Diensts auf. Dieser FQDN verweist auf einen Traffic Manager, der den kanonischen Namen (CNAME) der nächstgelegenen regionalen Web PubSub-Instanz zurückgibt.
2. Mit diesem CNAME stellt der Client eine WebSocket-Verbindung mit der regionalen Instanz (Replikat) her.
3. Die beiden Replikate werden Daten miteinander synchronisieren. Nachrichten, die an ein Replikat gesendet werden, würden bei Bedarf an andere Replikate übertragen.
4. Falls für ein Replikat bei der von Traffic Manager (TM) durchgeführten Integritätsprüfung ein Fehler auftritt, schließt TM den Endpunkt der fehlerhaften Instanz aus den Ergebnissen der Domänenauflösung aus. Ausführliche Informationen finden Sie unter Resilienz und Notfallwiederherstellung

Resilienz und Notfallwiederherstellung

Der Azure Web PubSub Service verwendet einen Traffic Manager für Integritätsprüfungen und DNS-Auflösung zu seinen Replikaten. Unter normalen Umständen, wenn alle Replikate ordnungsgemäß funktionieren, werden Clients an das nächstgelegene Replikat weitergeleitet. Beispiel:

• Clients in der Nähe von eastus werden an das Replikat weitergeleitet, das sich in eastus befindet.
• Ebenso werden Clients in der Nähe von westus an das Replikat in westus weitergeleitet.

Im Falle eines regionalen Ausfalls in „USA, Osten“ (unten dargestellt) wird der Datenverkehrsmanager den Integritätsprüfungsfehler für diese Region erkennen. Danach wird das DNS dieses fehlerhaften Replikats von den DNS-Auflösungsergebnissen des Datenverkehrsmanagers ausgeschlossen. Nach einer DNS-TTL (Time-to-Live)-Dauer, die auf 90 Sekunden festgelegt ist, werden Clients in eastus umgeleitet, um eine Verbindung mit dem Replikat in westus herzustellen.

Sobald das Problem in eastus behoben und die Region wieder online ist, wird die Integritätsprüfung erfolgreich sein. Clients in eastus werden dann erneut an das Replikat in ihrer Region weitergeleitet. Dieser Übergang verläuft nahtlos, da die verbundenen Clients nicht beeinträchtigt werden, solange die bestehenden Verbindungen nicht geschlossen werden.

Dieser Failover- und Wiederherstellungsvorgang ist automatisch und erfordert keinen manuellen Eingriff.

Replikat-Endpunkt aktivieren oder deaktivieren

Beim Einrichten eines Replikats haben Sie die Option, seinen Endpunkt zu aktivieren oder zu deaktivieren. Wenn er deaktiviert ist, enthält die DNS-Auflösung des primären FQDN das Replikat nicht, und daher wird der Datenverkehr nicht an ihn weitergeleitet.

Sie können den Endpunkt auch aktivieren oder deaktivieren, nachdem er erstellt wurde. Klicken Sie im Bereich „Replikate“ der primären Ressource auf die Ellipsenschaltfläche rechts neben dem Replikat, und wählen Sie Endpunkt aktivieren oder Endpunkt deaktivieren aus:

Bevor Sie eine Replikation löschen, sollten Sie zuerst ihren Endpunkt deaktivieren. Mit der Zeit werden bestehende Verbindungen unterbrochen. Da keine neuen Verbindungen verfügbar sind, wird die Replikation schließlich inaktiv. Dadurch wird ein nahtloser Löschprozess sichergestellt.

Dieses Feature ist auch hilfreich für die Behandlung regionaler Probleme.

Auswirkungen auf die Leistung nach der Aktivierung des Georeplikationsfeatures

Sobald Replikate aktiviert sind, verteilen sich die Clients automatisch entsprechend ihrem geografischen Standort. Web PubSub übernimmt zwar die Verantwortung für die Synchronisierung der Daten zwischen diesen Replikaten, aber der damit verbundene Overhead für die Serverlast ist für die meisten gängigen Anwendungsfälle minimal.

Wenn Ihre Anwendung typischerweise an größere Gruppen (Größe >10) oder eine einzelne Verbindung sendet, sind die Auswirkungen der Synchronisierung auf die Leistung kaum spürbar. Wenn Sie an kleine Gruppen (Größe < 10) senden, stellen Sie möglicherweise einen etwas höheren Synchronisierungsaufwand fest.

Um eine effektive Failoververwaltung sicherzustellen, empfiehlt es sich, die Einheitengröße jedes Replikats so festzulegen, dass es den gesamte Datenverkehr verarbeiten kann. Alternativ können Sie die automatische Skalierung aktivieren, um dies zu verwalten.

Weitere Informationen zur Leistungsauswertung finden Sie unter Leistung.

Nicht geerbte und geerbte Konfigurationen

Replikate erben die meisten Konfigurationen von der primären Ressource, einige Einstellungen müssen jedoch direkt auf den Replikaten konfiguriert werden. Im Folgenden finden Sie die Liste dieser Konfigurationen:

1. SKU: Jedes Replikat verfügt über einen eigenen SKU-Namen und eine eigene Einheitengröße. Die Regeln für die automatische Skalierung von Replikaten müssen basierend auf den jeweiligen Metriken separat konfiguriert werden.
2. Freigegebene private Endpunkte: Während freigegebene private Endpunkte automatisch in Replikate repliziert werden, sind für private Ziellinkressourcen separate Genehmigungen erforderlich. Um freigegebene private Endpunkte hinzuzufügen oder zu entfernen, verwalten Sie sie in der primären Ressource. Aktivieren Sie das Replikat nicht, bevor sein freigegebener privater Endpunkt genehmigt wurde.
3. Einstellungen für Protokollziel Wenn sie nicht für die Replikate konfiguriert wurden, werden nur Protokolle aus der primären Ressource übertragen.
4. Warnungen:

Alle anderen Konfigurationen werden von der primären Ressource geerbt. Beispielsweise Zugriffstasten, Identität, Anwendungsfirewall, benutzerdefinierte Domänen, private Endpunkte und Zugriffssteuerung.