Résilience et reprise d’activité après sinistre dans Azure SignalR Service

La résilience et la reprise d’activité après sinistre sont des besoins communs des systèmes en ligne. Azure SignalR Service fournit déjà une disponibilité de 99,9 %, mais il s’agit toujours d’un service régional. Lorsqu’il existe une panne à l’échelle de la région, votre instance de service ne bascule pas vers une autre région, car elle est toujours en cours d’exécution dans une région.

Pour la récupération d’urgence régionale, nous vous recommandons les deux approches suivantes :

• Activer la géoréplication (méthode simple). Cette fonctionnalité gère automatiquement le basculement régional. Lorsqu’elle est activée, il n’existe qu’une seule instance Azure SignalR et aucune modification du code n’est introduite. Vérifiez la géoréplication pour plus d’informations.
• Utilisez plusieurs points de terminaison dans le Kit de développement logiciel (SDK) de service. Notre Kit de développement logiciel (SDK) de service prend en charge plusieurs instances de service SignalR et bascule automatiquement vers d’autres instances lorsque certaines d’entre elles ne sont pas disponibles. Avec cette fonctionnalité, vous pouvez récupérer une fois qu’un sinistre a lieu, mais vous devez configurer la topologie système appropriée par vous-même. Vous apprenez à le faire dans ce document.

Architecture à haute disponibilité pour le service SignalR

Pour garantir la résilience entre régions pour le service SignalR, vous devez configurer plusieurs instances de service dans différentes régions. Par conséquent, lorsqu’une région est défaillante, les autres peuvent être utilisées comme sauvegarde. Lorsque les serveurs d’applications se connectent à plusieurs instances de service, il existe deux rôles, principaux et secondaires. Primary est une instance responsable de la réception du trafic en ligne, tandis que secondaire sert d’instance de secours entièrement fonctionnelle. Dans notre implémentation du Kit de développement logiciel (SDK), négociez uniquement les points de terminaison principaux. Par conséquent, les clients se connectent uniquement aux points de terminaison principaux dans des cas normaux. Toutefois, lorsque l’instance principale est en panne, la négociation retourne des points de terminaison secondaires afin que le client puisse toujours établir des connexions. L’instance principale et le serveur d’applications sont connectés via des connexions serveur normales, mais l’instance secondaire et le serveur d’applications sont connectés via un type spécial de connexion, appelée connexion faible. Une caractéristique distinctive d’une connexion faible est qu’il n’est pas en mesure d’accepter le routage de connexion client en raison de l’emplacement de l’instance secondaire dans une autre région. Le routage d’un client vers une autre région n’est pas un choix optimal (augmente la latence).

Une instance de service peut avoir différents rôles si elle se connecte à plusieurs serveurs d’applications. Une configuration classique pour un scénario interrégion consiste à avoir deux ou plusieurs paires d’instances de service SignalR et de serveurs d’applications. Dans chaque paire, le serveur d’applications et le service SignalR se trouvent dans la même région, et le service SignalR est connecté au serveur d’applications en tant que rôle principal. Entre deux paires, le serveur d’applications et le service SignalR sont également connectés, mais le service SignalR devient une instance secondaire lorsqu’il se connecte au serveur dans une autre région.

Avec cette topologie, un message provenant d’un serveur peut être remis à tous les clients, car tous les serveurs d’applications et toutes les instances du service SignalR sont interconnectés. Toutefois, lorsqu’un client est connecté, il est acheminé vers le serveur d’applications de la même région pour obtenir une latence réseau optimale.

Le diagramme suivant illustre cette topologie :

Configurer plusieurs instances de SignalR Service

Plusieurs instances de SignalR Service sont prises en charge sur les serveurs d'applications et Azure Functions.

Une fois que SignalR Service et les serveurs d'applications/Azure Functions ont été créés dans chaque région, vous pouvez configurer vos serveurs d'applications/Azure Functions pour qu'ils se connectent à toutes les instances de SignalR Service.

Configurer sur des serveurs d'applications

Vous pouvez procéder de deux façons :

Via la configuration

Normalement, vous savez déjà comment définir la chaîne de connexion du service SignalR grâce à des variables d’environnement/paramètres d’application/web.config, dans une entrée de configuration nommée Azure:SignalR:ConnectionString. Si vous avez plusieurs points de terminaison, vous pouvez les définir dans plusieurs entrées de configuration, chacune dans le format suivant :

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

Dans la Connecter ionString, <name> est le nom du point de terminaison et <role> son rôle (principal ou secondaire). Le nom est facultatif, mais il est utile si vous souhaitez personnaliser davantage le comportement de routage entre plusieurs points de terminaison.

Via le code

Si vous préférez stocker les chaînes de connexion à un autre endroit, vous pouvez également les lire dans votre code et les utiliser comme paramètres lorsque vous appelez AddAzureSignalR() (dans ASP.NET Core) ou MapAzureSignalR() (dans ASP.NET).

Voici l’exemple de code :

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"),
    };

Il est possible de configurer plusieurs instances principales ou secondaires, S’il existe plusieurs instances primaires et/ou secondaires, la négociation retourne un point de terminaison dans l’ordre suivant :

1. S’il y a au moins une instance principale en ligne, retourner une instance principale en ligne aléatoire.
2. Si toutes les instances principales sont hors service, retourner une instance secondaire en ligne aléatoire.

Configurer sur Azure Functions

Consultez cet article.

Bonne pratique et séquence de basculement

Vous disposez maintenant de la configuration appropriée de la topologie du système. Chaque fois qu’une instance de service SignalR est en panne, le trafic en ligne est acheminé vers d’autres instances. Voici ce qui se passe lorsqu’une instance principale est en panne (et récupère après un certain temps) :

1. L’instance de service principal est en panne, toutes les connexions de serveur sur cette instance sont déroulantes.
2. Tous les serveurs connectés à cette instance le marquent en mode hors connexion et négocient cesse de retourner ce point de terminaison et commencent à retourner le point de terminaison secondaire.
3. Toutes les connexions clientes sur cette instance sont également fermées, les clients se reconnectent ensuite. Étant donné que les serveurs d’applications retournent désormais un point de terminaison secondaire, les clients se connectent à une instance secondaire.
4. L’instance secondaire prend désormais en charge tout le trafic en ligne. Tous les messages du serveur aux clients peuvent encore être remis, car l’instance secondaire est connectée à tous les serveurs d’applications. Cependant, les messages des clients au serveur sont routés uniquement au serveur d’applications figurant dans la même région.
5. Une fois l’instance principale restaurée et de nouveau en ligne, le serveur d’applications rétablit les connexions à cette dernière et la marque comme étant en ligne. Négocier retourne à nouveau le point de terminaison principal afin que les nouveaux clients soient connectés au point de terminaison principal. Mais les clients existants ne sont pas supprimés et sont toujours acheminés vers le secondaire jusqu’à ce qu’ils se déconnectent.

Les diagrammes ci-dessous illustrent le basculement dans le service SignalR :

Fig.1 Avant le basculement

Fig.2 Après le basculement

Fig.3 Temps court après la récupération principale

Dans le cadre du fonctionnement normal, seuls le serveur d’applications et le service SignalR principaux gèrent le trafic en ligne (en bleu). Après le basculement, le serveur d’applications et le service SignalR secondaires deviennent également actifs. Une fois le service SignalR principal à nouveau en ligne, les nouveaux clients se connectent au service SignalR principal. Cependant, les clients existants restent connectés à l’instance secondaire, de sorte que les deux instances gèrent le trafic. Une fois que tous les clients existants se sont déconnectés, votre système revient à la normale (Figure 1).

Il existe deux modèles principaux pour implémenter une architecture inter-région à haute disponibilité :

1. Le premier consiste à avoir une paire de serveur d’applications et d’instance de service SignalR gérant tout le trafic en ligne, et à avoir une autre paire de secours (configuration active/passive, illustrée à la Figure 1).
2. L’autre consiste à avoir deux paires (ou plus) de serveurs d’applications et d’instances du service SignalR, gérant chacune une part du trafic en ligne et servant de sauvegarde pour les autres paires (configuration active/active, semblable à la Fig. 3).

Le service SignalR peut prendre en charge ces deux modèles, la principale différence étant la façon dont vous implémentez les serveurs d’applications. Si les serveurs d’applications sont actifs/passifs, le service SignalR est également actif/passif (car le serveur d’applications principal retourne uniquement son instance de service SignalR principale). Si les serveurs d’applications sont actifs/actifs, le service SignalR est également actif/actif (car tous les serveurs d’applications retournent leurs propres instances SignalR principales, afin que tous puissent obtenir le trafic).

Notez quels modèles que vous choisissez d’utiliser, vous devez connecter chaque instance de service SignalR à un serveur d’applications en tant que serveur d’applications principal.

En outre, en raison de la nature de la connexion SignalR (il s’agit d’une longue connexion), les clients rencontrent des échecs de connexion en cas de sinistre et de basculement. Vous devez gérer ces cas côté client pour le rendre transparent pour vos clients finaux. Par exemple, rétablissez une connexion qui a été fermée.

Guide pratique pour tester un basculement

Suivez les étapes pour déclencher le basculement :

1. Sous l’onglet Mise en réseau de la ressource principale dans le portail, désactivez l’accès au réseau public. Si la ressource a un réseau privé activé, utilisez des règles de contrôle d’accès pour refuser tout le trafic.
2. Redémarrez la ressource principale.

Étapes suivantes

Dans cet article, vous avez appris à configurer votre application pour obtenir une résilience pour le service SignalR. Pour plus de détails sur la connexion serveur/client et le routage des connexions dans le service SignalR, vous pouvez lire cet article sur les éléments internes du service SignalR.

Pour les scénarios de mise à l’échelle tels que le partitionnement qui utilise plusieurs instances ensemble pour gérer un grand nombre de connexions, lisez comment mettre à l’échelle plusieurs instances.

Pour plus d'informations sur la configuration d'Azure Functions avec plusieurs instances de SignalR Service, consultez Prise en charge de plusieurs instances d'Azure SignalR Service dans Azure Functions.