Resilienz und Notfallwiederherstellung in Azure SignalR Service

  • Artikel

Resilienz und Notfallwiederherstellung sind eine übliche Anforderung für Onlinesysteme. Azure SignalR Service bietet bereits 99,9 % Verfügbarkeit, es ist jedoch immer noch ein regionaler Dienst. Wenn es einen regionsweiten Ausfall gibt, schlägt Ihre Dienstinstanz nicht zu einer anderen Region fehl, da sie immer in der einen Region ausgeführt wird.

Für die regionale Notfallwiederherstellung empfehlen wir die folgenden beiden Ansätze:

  • Georeplikation aktivieren (einfach). Mit diesem Feature wird das regionale Failover automatisch behandelt. Wenn diese Option aktiviert ist, gibt es nur eine Azure SignalR-Instanz, und es werden keine Codeänderungen eingeführt. Überprüfen Sie die Georeplikation auf Details.
  • Verwenden mehrerer Endpunkte im Service SDK. Unser Service SDK unterstützt mehrere SignalR-Dienstinstanzen und wechselt automatisch zu anderen Instanzen, wenn einige von ihnen nicht verfügbar sind. Mit diesem Feature können Sie wiederherstellen, wenn ein Notfall stattfindet, aber Sie müssen die richtige Systemtopologie selbst einrichten. In diesem Dokument erfahren Sie, wie Dies geschieht.

Hochverfügbare Architektur für SignalR Service

Um die Regionsresilienz für den SignalR-Dienst sicherzustellen, müssen Sie mehrere Dienstinstanzen in verschiedenen Regionen einrichten. So können beim Ausfall einer Region die anderen Regionen als Sicherung fungieren. Wenn App-Server eine Verbindung mit mehreren Dienstinstanzen herstellen, gibt es zwei Rollen, primär und sekundär. Primär ist eine Instanz, die für den Empfang von Onlinedatenverkehr verantwortlich ist, während sekundär als Fallbackinstanz fungiert, die voll funktionsfähig ist. In unserer SDK-Implementierung werden nur primäre Endpunkte zurückgegeben, sodass Clients nur in normalen Fällen eine Verbindung mit primären Endpunkten herstellen. Wenn jedoch die primäre Instanz deaktiviert ist, werden sekundäre Endpunkte zurückgegeben, damit der Client weiterhin Verbindungen herstellen kann. Die primäre Instanz und der App-Server werden über normale Serververbindungen verbunden. Die sekundäre Instanz und der App-Server aber werden über einen speziellen Verbindungstyp verbunden, der als „unsichere Verbindung“ bezeichnet wird. Ein Unterscheidungsmerkmal einer schwachen Verbindung besteht darin, dass das Clientverbindungsrouting aufgrund des Standorts der sekundären Instanz in einer anderen Region nicht akzeptiert werden kann. Das Weiterleiten eines Clients an eine andere Region ist keine optimale Wahl (erhöht die Latenz).

Eine Dienstinstanz kann beim Herstellen einer Verbindung mit mehreren App-Servern unterschiedliche Rollen innehaben. Ein typisches Setup für ein szenarioübergreifendes Szenario besteht darin, zwei oder mehr Paare von SignalR-Dienstinstanzen und App-Servern zu haben. Innerhalb jedes Paars befinden sich der App-Server und die SignalR Service-Instanz in derselben Region, und SignalR Service wird als primäre Rolle mit dem App-Server verbunden. Zwischen den einzelnen Paaren werden der App-Server und SignalR Service ebenfalls verbunden. SignalR wird beim Herstellen einer Verbindung mit einem Server in einer anderen Region jedoch zu einer sekundären Instanz.

In dieser Topologie können Nachrichten von einem Server weiterhin an alle Clients übermittelt werden, da alle App-Server und SignalR Service-Instanzen miteinander verbunden sind. Wenn ein Client jedoch verbunden ist, wird er an den App-Server in derselben Region weitergeleitet, um eine optimale Netzwerklatenz zu erzielen.

Das folgende Diagramm veranschaulicht eine solche Topologie:

Diagram shows two regions each with an app server and a SignalR service, where each server is associated with the SignalR service in its region as primary and with the service in the other region as secondary.

Konfigurieren von mehreren SignalR Service-Instanzen

Mehrere SignalR Service-Instanzen werden sowohl auf App-Servern als auch auf Azure-Funktionen unterstützt.

Nachdem Sie SignalR Service und App-Server/Azure Funktionen in jeder Region erstellt haben, können Sie Ihre App-Server/Azure-Funktionen zum Herstellen einer Verbindung mit allen SignalR Service-Instanzen konfigurieren.

Konfigurieren auf App-Servern

Dafür stehen Ihnen zwei Möglichkeiten zur Auswahl:

Über die Konfigurationsdatei

Sie sollten bereits wissen, wie Sie die SignalR-Service-Verbindungszeichenfolge über Umgebungsvariablen/App-Einstellungen/web.config in einem Konfigurationseintrag namens Azure:SignalR:ConnectionString festlegen. Wenn Sie mehrere Endpunkte haben, können Sie diese in mehreren Konfigurationseinträgen im folgenden Format festlegen:

Azure:SignalR:ConnectionString:<name>:<role>

In der Verbinden ionString <name> ist der Name des Endpunkts und <role> seine Rolle (primär oder sekundär). Der Name ist optional, aber es ist nützlich, wenn Sie das Routingverhalten zwischen mehreren Endpunkten weiter anpassen möchten.

Über den Code

Wenn Sie die Verbindungszeichenfolgen an anderer Stelle speichern möchten, können Sie sie auch in Ihrem Code einlesen und als Parameter beim Aufrufen von AddAzureSignalR() (ASP.NET Core) oder MapAzureSignalR() (ASP.NET) verwenden.

Sehen Sie sich den Beispielcode an:

ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

ASP.NET:

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

Sie können mehrere primäre oder sekundäre Instanzen konfigurieren. Wenn mehrere primäre und/oder sekundäre Instanzen vorhanden sind, wird ein Endpunkt in der folgenden Reihenfolge zurückgegeben:

  1. Wenn mindestens eine primäre Instanz online ist, wird eine zufällige primäre Onlineinstanz zurückgegeben.
  2. Wenn alle primären Instanzen ausgefallen sind, wird eine zufällige sekundäre Onlineinstanz zurückgegeben.

Konfigurieren von Azure-Funktionen

In diesem Artikel finden Sie weitere Informationen.

Failoversequenz und bewährte Methode

Sie verfügen jetzt über die richtige Konfiguration der Systemtopologie. Wenn eine SignalR-Dienstinstanz abfällt, wird der Onlinedatenverkehr an andere Instanzen weitergeleitet. Hier erfahren Sie, was geschieht, wenn eine primäre Instanz abfällt (und nach einiger Zeit wiederhergestellt wird):

  1. Die primäre Dienstinstanz ist deaktiviert, alle Serververbindungen in dieser Instanz drop.
  2. Alle server, die mit dieser Instanz verbunden sind, markieren sie als offline, und aushandeln beendet die Rückgabe dieses Endpunkts und starten die Rückgabe des sekundären Endpunkts.
  3. Alle Clientverbindungen auf dieser Instanz werden ebenfalls geschlossen, clients dann erneut verbinden. Da App-Server jetzt sekundären Endpunkt zurückgeben, stellen Clients eine Verbindung mit sekundärer Instanz her.
  4. Die sekundäre Instanz übernimmt nun den gesamten Onlinedatenverkehr. Alle Nachrichten vom Server an Clients können weiterhin übermittelt werden, da die sekundäre Instanz mit allen App-Servern verbunden ist. Nachrichten von Clients an Server werden jedoch nur an den App-Server in der gleichen Region weitergeleitet.
  5. Nachdem die primäre Instanz wiederhergestellt wurde und wieder online ist, stellt der App-Server die Verbindungen wieder her und markiert die Instanz als „online“. Aushandeln gibt jetzt erneut den primären Endpunkt zurück, sodass neue Clients wieder mit der primären Verbindung verbunden sind. Vorhandene Clients werden jedoch nicht abgelegt und weiterhin an sekundär weitergeleitet, bis sie sich trennen.

Die folgenden Diagramme veranschaulichen das Failover in SignalR Service:

Abb.1 Vor Failover Before Failover

Abb.2 Nach Failover After Failover

Abb.3 Kurze Zeit nach der primären Wiederherstellung Short time after primary recovers

Wie Sie sehen, liegt im Normalfall nur für den primären App-Server und die primäre SignalR Service-Instanz Onlinedatenverkehr vor (blau dargestellt). Nach dem Failover werden auch der sekundäre App-Server und die sekundäre SignalR Service-Instanz aktiv. Wenn die primäre SignalR Service-Instanz wieder online ist, stellen neue Clients eine Verbindung mit der primären SignalR-Instanz her. Vorhandene Clients stellen jedoch weiterhin eine Verbindung mit der sekundären Instanz her, sodass beide Instanzen Datenverkehr verarbeiten. Nachdem alle vorhandenen Clients die Verbindung getrennt haben, kehrt das System zum normalen Betriebszustand zurück (Abb. 1).

Für die Implementierung einer regionsübergreifenden hochverfügbaren Architektur stehen zwei grundlegende Muster zur Verfügung:

  1. Verwendung eines Paars von App-Server und SignalR Service-Instanz, das den gesamten Onlinedatenverkehr verarbeitet, und eines weiteren Paars als Sicherung (bezeichnet als Aktiv/Passiv-Konfiguration, siehe Abb. 1).
  2. Verwendung von zwei (oder mehr) Paaren von App-Servern und Azure SignalR Service-Instanzen, die alle Onlinedatenverkehr verarbeiten und als Sicherung für andere Paare fungieren (bezeichnet als Aktiv/Aktiv-Konfiguration, siehe Abb. 3).

SignalR Service kann beide Muster unterstützen. Der wesentliche Unterschied besteht in der Implementierung der App-Server. Wenn App-Server aktiv/passiv sind, ist der SignalR-Dienst auch aktiv/passiv (da der primäre App-Server nur seine primäre SignalR-Dienstinstanz zurückgibt). Wenn App-Server aktiv/aktiv sind, ist der SignalR-Dienst auch aktiv/aktiv (da alle App-Server ihre eigenen primären SignalR-Instanzen zurückgeben, sodass alle Datenverkehr abrufen können).

Beachten Sie, welche Muster Sie verwenden möchten. Sie müssen jede SignalR-Dienstinstanz als primäre Verbindung mit einem App-Server herstellen.

Aufgrund der Art der SignalR-Verbindung (es ist eine lange Verbindung) fällt die Verbindung von Clients ab, wenn ein Notfall und Failover stattfindet. Sie müssen solche Fälle auf clientseitiger Seite behandeln, um sie für Ihre Endkunden transparent zu machen. Stellen Sie beispielsweise nach dem Schließen einer Verbindung erneut eine Verbindung her.

So testen Sie ein Failover

Führen Sie die Schritte aus, um das Failover auszulösen:

  1. Deaktivieren Sie auf der Registerkarte "Netzwerk" für die primäre Ressource im Portal den Öffentlichen Netzwerkzugriff. Wenn die Ressource ein privates Netzwerk aktiviert hat, verwenden Sie Zugriffssteuerungsregeln , um den gesamten Datenverkehr zu verweigern.
  2. Starten Sie die primäre Ressource neu .

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie Ihre Anwendung so konfigurieren, dass sie resilienz für den SignalR-Dienst erreicht. Weitere Details zur Server-/Clientverbindung und zum Verbindungsrouting in SignalR Service finden Sie in diesem Artikel.

Für Skalierungsszenarien wie sharding, die mehrere Instanzen zusammen verwenden, um eine große Anzahl von Verbindungen zu verarbeiten, lesen Sie , wie mehrere Instanzen skaliert werden.

Ausführliche Informationen zum Konfigurieren von Azure Functions mit mehreren SignalR Service-Instanzen finden Sie unter Unterstützung mehrerer Azure SignalR Service-Instanzen in Azure-Funktionen.