Dans SQL Server, les groupes de disponibilité Always On fournissent une solution de haute disponibilité et de reprise après sinistre avec plusieurs réplicas. Cependant, lorsqu’un basculement se produit, il peut être difficile de rediriger les connexions des utilisateurs vers le nouveau réplica principal. C’est là que les écouteurs Always On de SQL Server entrent en jeu.

Un écouteur Always On de SQL Server est un nom de réseau virtuel qui pointe toujours vers le réplica principal. Il permet aux applications clientes de se connecter au groupe de disponibilité sans avoir besoin de connaître la configuration sous-jacente des réplicas. Dans cet article, nous explorerons les concepts des écouteurs Always On de SQL Server et de MultiSubnetFailover.

Écouteurs Always On de SQL Server

Pour configurer un écouteur Always On de SQL Server, vous pouvez utiliser SQL Server Management Studio (SSMS). Il suffit d’étendre le nœud Écouteur du groupe de disponibilité dans SSMS et de cliquer sur “Ajouter un écouteur”. Fournissez un nom de réseau virtuel unique dans DNS et spécifiez le port pour l’écouteur SQL. Il est recommandé d’utiliser un port différent du port SQL par défaut 1433 pour éviter les conflits de port.

Une fois qu’un écouteur SQL est configuré, il devient une ressource de cluster. Vous pouvez voir le nom de l’écouteur et l’adresse IP virtuelle dans le gestionnaire de cluster de basculement sous Rôles. L’application cliente peut ensuite utiliser le nom de l’écouteur SQL et le port dans sa chaîne de connexion.

MultiSubnetFailover dans les groupes de disponibilité Always On de SQL Server

Dans le cas de groupes de disponibilité Always On multi-sous-réseaux, où les réplicas sont répartis sur différents sous-réseaux, nous devons utiliser plusieurs adresses IP pour l’écouteur SQL. Chaque sous-réseau doit avoir sa propre adresse IP virtuelle. Lorsqu’un client se connecte via DNS pour résoudre le nom de réseau virtuel, il reçoit une liste de toutes les adresses IP disponibles. L’application cliente essaie ensuite de se connecter à chaque adresse IP jusqu’à ce qu’une connexion réussie soit établie.

Cependant, cette approche d’essai et d’erreur peut entraîner des retards dans la connexion de l’application, en particulier s’il y a plusieurs sous-réseaux. Pour résoudre ce problème, nous pouvons activer le paramètre MultiSubnetFailover dans la chaîne de connexion. Ce paramètre permet à l’application de se connecter à toutes les adresses IP simultanément et de se connecter au réplica principal en utilisant l’adresse IP qui établit une connexion réussie.

Exemple :

Si vous souhaitez vous connecter à la base de données à l’aide de SQL Server Management Studio (SSMS), vous pouvez spécifier MultiSubnetFailover=True dans les Paramètres de connexion supplémentaires. De même, vous pouvez spécifier MultiSubnetFailover dans les connexions du fournisseur ODBC et ADO.NET.

Limitations de MultiSubnetFailover

Il est important de noter que MultiSubnetFailover présente certaines limitations :

• Il ne prend pas en charge les noms d’hôte avec plus de 64 adresses IP.
• Il ne prend en charge que le protocole TCP.
• Il ne se connecte pas aux instances SQL Server en mode miroir.
• Il ne prend pas en charge les instances SQL nommées.

Configuration RegisterAllProvidersIP

Par défaut, l’application essaie de se connecter avec plusieurs adresses IP virtuelles en mode série. Pour permettre un traitement parallèle des connexions, nous pouvons configurer la valeur RegisterAllProvidersIP dans le cluster SQL Server. Lorsque RegisterAllProvidersIP est défini sur 1, toutes les adresses IP sont enregistrées et disponibles pour la connectivité de l’application.

Si l’application ne prend pas en charge MultiSubnetFailover, nous pouvons définir la valeur RegisterAllProvidersIP sur 0. Cela garantit que seule l’adresse IP du nœud actif est enregistrée. Lorsque l’application se connecte à DNS pour l’adresse IP de l’écouteur, elle reçoit l’adresse IP du nœud actif, éliminant ainsi tout problème de délai d’expiration pouvant survenir avec plusieurs adresses IP.

Pour modifier la valeur RegisterAllProvidersIP, vous pouvez utiliser PowerShell avec des permissions d’administration. Exécutez la commande suivante :

Get-ClusterResource "Nom de la ressource de cluster" | Set-ClusterParameter RegisterAllProvidersIP 0

Assurez-vous de remplacer “Nom de la ressource de cluster” par le nom réel de la ressource de cluster. Après avoir exécuté la commande, redémarrez le rôle du cluster en le mettant hors ligne, puis en ligne.

Conclusion

Dans cet article, nous avons exploré les concepts des écouteurs Always On de SQL Server et de MultiSubnetFailover. Les écouteurs Always On fournissent un nom de réseau virtuel qui simplifie le processus de connexion pour les applications clientes. MultiSubnetFailover permet un traitement parallèle des connexions pour améliorer les performances de l’application. En comprenant ces concepts et configurations, vous pouvez optimiser la disponibilité et les performances de vos groupes de disponibilité Always On de SQL Server.