Georeplikation in Azure SignalR Service

Unternehmen, die lokale Präsenz suchen oder ein robustes Failoversystem benötigen, entscheiden sich häufig dafür, Dienste über mehreren Azure-Regionen hinweg bereitzustellen. Mit der Integration der Georeplikation in Azure SignalR Service ist die Verwaltung von Szenarien mit mehreren Regionen erheblich einfacher geworden.

Nutzen der Verwendung der Georeplikation

• Widerstandsfähiger gegenüber regionalem Ausfall: Wenn ein regionaler Ausfall auftritt, wird das Azure SignalR Service-DNS in fehlerfreie Replikate in anderen Regionen aufgelöst.
• Regionsübergreifende Kommunikation. Unterschiedliche Replikate können miteinander kommunizieren, als wären sie dieselbe Instanz.
• 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.
• Freigegebene Konfigurationen. Alle Replikate behalten die Konfiguration der primären Azure SignalR Service-Ressource bei.

Voraussetzungen

• Eine Azure SignalR Service-Instanz auf der Premium-Ebene.

Beispiel eines Anwendungsfalls

Contoso ist ein Social Media-Unternehmen, dessen Kundenbasis sich über die USA und Kanada erstreckt. Um diese Kunden zu bedienen und sie miteinander kommunizieren zu lassen, führt Contoso seine Dienste in „USA, Mitte“ aus. Azure SignalR Service wird verwendet, um Benutzerverbindungen zu verarbeiten und die Kommunikation zwischen Benutzern zu unterstützen. Die Endbenutzer von Contoso sind hauptsächlich Telefonbenutzer. Aufgrund der großen geografischen Entfernungen können Endbenutzer in Kanada hohe Wartezeit und schlechte Netzwerkqualität erfahren.

Vor dem Aufkommen des Georeplikationsfeatures konnte Contoso eine andere Azure SignalR Service-Instanz in „Kanada, Mitte“ einrichten, um seine kanadischen Benutzern zu bedienen. Durch die Einrichtung einer geografisch näheren Azure SignalR Service-Instanz verfügen Endbenutzer jetzt über eine bessere Netzwerkqualität und geringere Wartezeit.

Das Verwalten mehrerer Azure SignalR Service-Instanzen bringt jedoch einige Herausforderungen:

1. Ein regionsübergreifender Kommunikationsmechanismus wäre erforderlich, um die Konversation zwischen Kanada und US-Benutzern zu ermöglichen.
2. Das Entwicklungsteam müsste zwei separate Azure SignalR Service-Instanzen verwalten, jeweils mit unterschiedlichen Domänen und Verbindungszeichenfolgen.
3. Wenn ein regionaler Ausfall auftritt, muss der Datenverkehr zu einer anderen Region gewechselt werden.

Nutzen der Georeplikation

Mit dem neuen Feature für die Georeplikation kann Contoso nun ein Replikat in „Kanada, Mitte“ einrichten und die oben genannten Hürden effektiv überwinden.

Erstellen eines Azure SignalR Service-Replikats

Portal

Um ein Replikat zu erstellen, navigieren Sie zum Azure SignalR Service-Blatt Replikate im Azure-Portal und klicken auf Hinzufügen, um ein Replikat zu erstellen. Es wird beim Erstellen automatisch aktiviert.

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 SignalR service')
param primaryName string = 'contoso'

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

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

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

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

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

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

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

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

Bereitstellen der Bicep-Datei mithilfe von Azure CLI

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

Hinweis

• Die Replikatanzahl ist derzeit auf maximal 8 pro primäre Ressource beschränkt.

Preise und Ressourceneinheit

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

Replikat ist ein Feature der Premium-Ebene von Azure SignalR 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 ein Replikat in „Kanada, Mitte“ 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 Ihre Azure SignalR Service-Instanz 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 Azure SignalR Service-Instanz, 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“.

Verstehen der Funktionsweise des Azure SignalR Service-Replikats

Das folgende Diagramm zeigt eine kurze Abbildung der Funktionalität der Azure SignalR Service-Replikate:

1. Der Client verhandelt mit dem App-Server und empfängt eine Umleitung an den Azure SignalR Service-Dienst. Anschließend wird der vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) des Azure SignalR Service-Diensts aufgelöst – contoso.service.signalr.net. Dieser FQDN verweist auf einen Traffic Manager, der den kanonischen Namen (CNAME) der nächstgelegenen regionalen Azure SignalR Service-Instanz zurückgibt.
2. Mit diesem CNAME stellt der Client eine 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 die vom Traffic Manager (TM) durchgeführte Integritätsprüfung fehlschlägt, schließt der TM den Endpunkt der fehlgeschlagenen Instanz aus seinem Prozess der Domänenauflösung aus. Ausführliche Informationen finden Sie unter Resilienz und Notfallwiederherstellung

Hinweis

• In der Datenebene funktioniert eine primäre Azure SignalR Service-Ressource identisch wie ihre Replikate

Resilienz und Notfallwiederherstellung

Azure SignalR Service verwendet einen Datenverkehrsmanager für Integritätsprüfungen und DNS-Auflösung in Richtung seiner Replikate. 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 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.

Bei Serververbindungen funktioniert das Failover und die Wiederherstellung auf die gleiche Weise wie bei Clientverbindungen.

Hinweis

• Dieser Failovermechanismus gilt für den Azure SignalR Service-Dienst. Regionale Ausfälle des App-Servers liegen außerhalb des Rahmens dieses Dokuments.

Deaktivieren oder Aktivieren des Replikatendpunkts

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 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 ihren Endpunkt deaktivieren. Im Laufe der Zeit werden vorhandene Verbindungen getrennt. 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.

Hinweis

• Aufgrund des DNS-Caches kann es mehrere Minuten dauern, bis das DNS-Update wirksam wird.
• Vorhandene Verbindungen bleiben davon unberührt, bis sie die Verbindung trennen.

Auswirkungen auf die Leistung nach dem Hinzufügen von Replikaten

Nachdem Replikate aktiviert wurden, werden Clients natürlich basierend auf ihren geografischen Standorten verteilt. SignalR ü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) oder einzelne Benutzer senden, stellen Sie möglicherweise einen etwas größeren 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 erst, nachdem der freigegebene private 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. Dies betrifft beispielsweise Zugriffsschlüssel, Identität, Anwendungsfirewall, benutzerdefinierte Domänen, private Endpunkte und Zugriffssteuerung.