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 demeure un service régional. En cas de panne à l’échelle d’une région, votre instance de service ne bascule pas vers une autre région dans la mesure où elle s’exécute toujours dans la même région.

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

• Activer la géoréplication (méthode simple). Cette fonctionnalité gère automatiquement le basculement régional. Quand vous activez cette fonctionnalité, il n’y a qu’une seule instance Azure SignalR et aucune modification de code n’est introduite. Pour plus d’informations, consultez cet article sur la géoréplication.
• Utiliser plusieurs points de terminaison dans le Kit de développement logiciel (SDK) du service. Le kit SDK de notre service prend en charge plusieurs instances du service SignalR et bascule automatiquement vers d’autres instances lorsque certaines d’entre elles ne sont pas disponibles. Cette fonctionnalité vous permet de récupérer en cas de sinistre, mais vous devez configurer vous-même la bonne topologie du système. Ce document vous explique comment faire.

Architecture à haute disponibilité pour le service SignalR

Pour assurer la résilience inter-région du service SignalR, vous devez configurer plusieurs instances du 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 du service, deux rôles existent : principal et secondaire. Le rôle principal est une instance chargée de recevoir le trafic en ligne, tandis que le rôle secondaire sert d’instance de secours entièrement fonctionnelle. Dans notre implémentation du kit SDK, la négociation retourne uniquement les points de terminaison principaux. Ainsi, les clients ne se connectent qu’aux points de terminaison principaux dans le cadre d’un fonctionnement normal. Mais lorsque l’instance principale est défaillante, la négociation retourne les points de terminaison secondaires pour permettre aux clients de continuer à se connecter. 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. L’une des caractéristiques d’une connexion faible est qu’elle est incapable d’accepter le routage de la connexion du 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, car il augmente la latence.

Une instance de service peut avoir différents rôles si elle se connecte à plusieurs serveurs d’applications. Une installation type pour un scénario inter-région consiste à avoir deux paires ou plus 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. Mais lorsqu’un client est connecté, il est routé vers le serveur d’applications dans 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.

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

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

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

dotnet user-secrets set Azure:SignalR:Endpoints:east-region-a <ConnectionString1>
dotnet user-secrets set Azure:SignalR:Endpoints:east-region-b:primary <ConnectionString2>
dotnet user-secrets set Azure:SignalR:Endpoints:backup:secondary <ConnectionString3>

var serviceManager = new ServiceManagerBuilder()
                    .WithOptions(option =>
                    {
                        options.Endpoints = new ServiceEndpoint[]
                        {
                            // Note: this is just a demonstration of how to set options.Endpoints
                            // Having ConnectionStrings explicitly set inside the code is not encouraged
                            // You can fetch it from a safe place such as Azure KeyVault
                            new ServiceEndpoint("<ConnectionString0>"),
                            new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
                            new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
                            new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
                        };
                    })
                    .BuildServiceManager();

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 du service SignalR est défaillante, le trafic en ligne est acheminé vers d’autres instances. Voici ce qui se passe lorsqu’une instance principale est défaillante (et est restaurée plus tard) :

1. L’instance de service principale est défaillante. Toutes les connexions serveur sur cette instance sont supprimées.
2. Tous les serveurs connectés à cette instance la marquent comme hors connexion. La négociation cesse de retourner ce point de terminaison et commence à retourner le point de terminaison secondaire.
3. Toutes les connexions client sur cette instance sont également fermées, puis les clients se reconnectent. Dans la mesure où les serveurs d’applications retournent maintenant un point de terminaison secondaire, les clients se connectent à l’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. La négociation retourne désormais à nouveau le point de terminaison principal, si bien que les nouveaux clients sont reconnectés à l’instance principale. En revanche, les clients existants ne sont pas supprimés et continuent d’être routés vers l’instance secondaire jusqu’à ce qu’ils se déconnectent eux-mêmes.

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

Figure 1. Avant le basculement

Figure 2. Après le basculement

Figure 3. Peu de temps après la récupération de l’instance 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 en mode actif/passif, le service SignalR est également en mode actif/passif (car le serveur d’applications principal retourne uniquement son instance de service SignalR principale). Si les serveurs d’applications sont en mode actif/actif, le service SignalR est également en mode actif/actif (car tous les serveurs d’applications retournent leurs propres instances SignalR principales afin qu’ils puissent tous obtenir le trafic).

Quel que soit le modèle que vous choisissez d’utiliser, notez que vous devez connecter chaque instance de service SignalR à un serveur d’applications en tant qu’instance principale.

De plus, en raison de la nature de la connexion SignalR (connexion longue), les clients sont confrontés à des interruptions de connexion en cas de sinistre et de basculement. Vous devez gérer de telles situations côté client pour les rendre transparentes pour vos clients finaux. Par exemple, rétablissez une connexion qui a été fermée.

Comment tester un basculement

Effectuez les étapes suivantes 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 un réseau privé est activé pour la ressource, 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 assurer la résilience du 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, comme le partitionnement qui utilise conjointement plusieurs instances pour gérer un grand nombre de connexions, lisez l’article sur la mise à l’échelle de 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.