Georeplikation in Azure Web PubSub

Unternehmenskritische Apps müssen häufig über ein robustes Failoversystem verfügen und den Benutzern näher an der Stelle dienen, an der sie sich befinden. Vor der Veröffentlichung des Georeplikationsfeatures mussten Entwickler mehrere Web PubSub-Ressourcen bereitstellen und benutzerdefinierten Code schreiben, um die Kommunikation über Ressourcen hinweg zu koordinieren. Mit der schnellen Konfiguration über Azure-Portal können Sie dieses Feature jetzt ganz einfach aktivieren.

Vorteile der Georeplikation

• Widerstandsfähiger gegenüber regionalem Ausfall: Wenn ein regionaler Ausfall auftritt, werden Clients automatisch an ein fehlerfreies Replikat weitergeleitet.
• Regionsübergreifende Kommunikation: Entwickler verwenden eine georeplikationsfähige Ressource wie gewohnt, obwohl hinter den Kulissen mehr als eine Ressource vorhanden ist. Die Kommunikation über Replikate hinweg wird vom Dienst verarbeitet.
• Verbesserte Netzwerkgeschwindigkeit: Geografisch verteilte Clients stellen eine Verbindung mit dem nächstgelegenen Replikat her. Diese Replikate kommunizieren über das globale Azure-Netzwerk-Backbone und sorgen für schnelle und stabile Netzwerke.
• Erleichterte Verwaltung. Alle Replikate teilen die Konfiguration der primären Web PubSub-Ressource.

Voraussetzungen

• Eine Web PubSub-Ressource auf premium-Ebene.

Beispiel eines Anwendungsfalls

Contoso, ein Unternehmen für soziale Medien

Contoso ist ein Social Media-Unternehmen mit seiner Kundenbasis in den USA und Kanada. Contoso stellt seinen Benutzern eine mobile und Web-App bereit, damit sie sich miteinander verbinden können. Contoso-Anwendung wird in Central US bereitgestellt. Im Rahmen der Architektur von Contoso wird Web PubSub verwendet, um dauerhafte WebSocket-Verbindungen zwischen Client-Apps und dem Anwendungsserver einzurichten. Contoso mag , dass sie die Verwaltung von WebSocket-Verbindungen in Web PubSub auslagern können, aber das Lesen von Berichten von Benutzern in Kanada mit einer höheren Latenz nicht gefällt. Darüber hinaus möchte das Entwicklungsteam von Contoso die App vor regionalem Ausfall versichern, damit die Benutzer ohne Unterbrechungen auf die App zugreifen können.

Contoso könnte eine weitere Web PubSub-Ressource in Kanada Central einrichten, die geografisch näher an den Benutzern in Kanada liegt. Das Verwalten mehrerer Web PubSub-Ressourcen bringt jedoch einige Herausforderungen:

1. Ein regionsübergreifender Kommunikationsmechanismus muss implementiert werden, damit Benutzer in Kanada und DEN USA miteinander interagieren können.
2. Das Entwicklungsteam müsste zwei separate Web PubSub-Ressourcen verwalten, jeweils mit unterschiedlichen Aufgaben Standard und Verbindungszeichenfolge.
3. Wenn ein regionaler Ausfall stattfindet, muss der Datenverkehr an eine verfügbare Ressource weitergeleitet werden.

Alle oben genannten Ressourcen nehmen technische Ressourcen weg, sich auf Produktinnovationen zu konzentrieren.

Nutzen des Georeplikationsfeatures

Mit dem Georeplikationsfeature kann Contoso jetzt ein Replikat in Kanada Zentral einrichten und die oben genannten Erwähnung Herausforderungen effektiv überwinden. Das Entwicklerteam freut sich, herauszufinden, dass sie keine Codeänderungen vornehmen müssen. Es ist so einfach wie das Klicken auf ein paar Schaltflächen auf Azure-Portal. Das Entwicklerteam teilt sich auch gerne mit den Projektbeteiligten, die als Contoso den europäischen Markt betreten will, müssen sie einfach ein weiteres Replikat in Europa hinzufügen.

Aktivieren der Georeplikation in einer Web PubSub-Ressource

Portal

Um ein Replikat in einer Azure-Region zu erstellen, wechseln Sie zu Ihrer Web PubSub-Ressource, und suchen Sie das Blatt "Replikate" auf der Azure-Portal, und klicken Sie auf "Hinzufügen", um ein Replikat zu erstellen.

Nach der Erstellung können Sie Ihr Replikat im Portal anzeigen/bearbeiten, indem Sie auf den Replikatnamen klicken.

Bicep

Verwenden Sie Visual Studio Code oder Ihren bevorzugten Editor, um eine Datei mit dem folgenden Inhalt zu erstellen, und nennen Sie sie main.bicep:

@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
  }
}

Bereitstellen der Bicep-Datei mit Azure CLI

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

BEFEHLSZEILENSCHNITTSTELLE (CLI)

Aktualisieren Sie die Webpubsub-Erweiterung auf die neueste Version, und führen Sie dann Folgendes aus:

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

Preis- und Ressourceneinheit

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

Replikat ist ein Feature der Premium-Ebene des Azure Web PubSub-Diensts. Jedes Replikat wird je nach eigener Einheit und ausgehender Datenverkehr separat abgerechnet. Das kostenlose Nachrichtenkontingent wird auch separat berechnet.

Im vorherigen Beispiel hat Contoso ein Replikat in Kanada Central hinzugefügt. Contoso würde für das Replikat in Kanada Central 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

Grundlegendes zur Funktionsweise des Georeplikationsfeatures

1. Der Client löst den vollqualifizierten Do Standard Namen (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 synchronisieren Daten miteinander. Nachrichten, die an ein Replikat gesendet werden, werden bei Bedarf an andere Replikate übertragen.
4. Falls ein Replikat die vom Traffic Manager (TM) durchgeführte Integritätsprüfung fehlschlägt, schließt die TM den Endpunkt der fehlgeschlagenen Instanz von ihrer Do Standard Auflösungsergebnisse aus. Ausführliche Informationen finden Sie unter " Resilienz und Notfallwiederherstellung"

Hinweis

• In der Datenebene funktioniert eine primäre Azure Web PubSub-Ressource identisch mit ihren Replikaten.

---

Resilienz und Notfallwiederherstellung

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

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

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

Sobald das Problem eastus behoben ist und die Region wieder online ist, wird die Integritätsprüfung erfolgreich ausgeführt. Clients in eastus werden dann erneut an das Replikat in ihrer Region weitergeleitet. Dieser Übergang ist reibungslos, da die verbundenen Clients erst betroffen sind, wenn diese vorhandenen Verbindungen geschlossen werden.

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

Deaktivieren oder Aktivieren des Replikatendpunkts

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

Sie können den Endpunkt auch deaktivieren, nachdem er erstellt wurde. Klicken Sie auf dem Replikatblatt der primären Ressource auf die Schaltfläche mit den Auslassungspunkten auf der rechten Seite des Replikats, und wählen Sie "Endpunkt aktivieren" oder "Endpunkt deaktivieren" aus:

Bevor Sie eine Replikation löschen, sollten Sie zuerst den Endpunkt deaktivieren. Im Laufe der Zeit werden vorhandene Verbindungen getrennt. Da keine neuen Verbindungen verfügbar sind, wird die Replikation schließlich im Leerlauf. Dadurch wird ein nahtloser Löschvorgang sichergestellt.

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

Hinweis

• Aufgrund des DNS-Caches kann es mehrere Minuten dauern, bis das DNS-Update wirksam wird.
• Vorhandene Verbindungen Standard nicht betroffen, bis sie die Verbindung trennen.

Auswirkungen auf die Leistung nach dem Aktivieren des Georeplikationsfeatures

Nachdem Replikate aktiviert wurden, werden Clients natürlich basierend auf ihren geografischen Standorten verteilt. Während Web PubSub die Verantwortung für die Synchronisierung von Daten über diese Replikate übernimmt, wissen Sie, dass der zugeordnete Aufwand für die Serverlast für die meisten gängigen Anwendungsfälle minimal ist.

Wenn Ihre Anwendung in der Regel an größere Gruppen (Größe >10) oder eine einzelne Verbindung sendet, ist die Leistungsauswirkung der Synchronisierung kaum spürbar. Wenn Sie kleine Gruppen (Größe < 10) messagingn, bemerken Sie möglicherweise etwas mehr Synchronisierungsaufwand.

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

Weitere Informationen zur Leistungsauswertung finden Sie unter Performance.