Se connecter à un écouteur de groupe de disponibilité Always On
S'applique à : 
SQL Server
Cet article explique comment vous connecter à un écouteur de groupe de disponibilité Always On pour SQL Server. Un écouteur de groupe de disponibilité est un nom de réseau virtuel que les clients utilisent pour se connecter à une base de données hébergée dans un groupe de disponibilité. L’écouteur fournit un point de terminaison de connexion cohérent pour les applications clientes, quel que soit le réplica de disponibilité qui héberge actuellement la base de données primaire. L’écouteur active également la prise en charge du routage en lecture seule et du basculement automatique.
Une fois que vous avez configuré votre écouteur, mettez à jour vos chaîne de connexion pour pointer vers l’écouteur afin que le trafic de l’application soit automatiquement routé vers le réplica prévu sans avoir à mettre à jour manuellement les chaîne de connexion après chaque basculement.
Se connecter au réplica principal
Spécifiez le nom DNS de l’écouteur du groupe de disponibilité dans la chaîne de connexion pour établir la connexion au réplica principal en vue de l’accès en lecture-écriture.
Par exemple, pour vous connecter au réplica principal dans SQL Server Management Studio par le biais de l’écouteur, entrez le nom DNS de l’écouteur dans le champ Nom du serveur :
Si le réplica principal est changé durant un basculement, les connexions à l’écouteur existantes sont déconnectées et les nouvelles connexions sont routées vers le nouveau réplica principal.
Voici un exemple de chaîne de connexion de base pour le fournisseur ADO.NET (System.Data.SqlClient) :
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Vous pouvez vérifier à quel réplica vous êtes actuellement connecté par le biais de l’écouteur en exécutant la commande Transact-SQL (T-SQL) suivante :
SELECT @@SERVERNAME
Exemple où SQLVM1 est configuré comme réplica principal :
Vous pouvez toujours vous connecter directement à l’instance de SQL Server en spécifiant le nom d’instance du réplica principal ou secondaire au lieu d’utiliser l’écouteur du groupe de disponibilité. Toutefois, dans ce cas, les nouvelles connexions ne sont plus routées automatiquement vers le nouveau réplica principal actuel. De plus, vous perdez l’avantage du routage en lecture seule, où les connexions spécifiées avec read-intent sont automatiquement routées vers le réplica secondaire accessible en lecture.
Se connecter à un réplica en lecture seule
Leroutage en lecture seule fait référence à la capacité de router automatiquement les connexions entrantes de l’écouteur vers un réplica secondaire accessible en lecture qui est configuré pour autoriser des charges de travail en lecture seule.
Les connexions sont automatiquement routées vers le réplica en lecture seule si les conditions suivantes sont remplies :
Au moins un réplica secondaire est configuré pour l’accès en lecture seule, et chaque réplica secondaire en lecture seule ainsi que le réplica principal sont configurés pour prendre en charge le routage en lecture seule.
La chaîne de connexion référence une base de données impliquée dans le groupe de disponibilité. Une alternative serait que la connexion utilisée ait la base de données configurée comme base de données par défaut. Pour plus d’informations, consultez cet article sur le fonctionnement de l’algorithme avec le routage en lecture seule.
La chaîne de connexion fait référence à un écouteur de groupe de disponibilité, et l’intention de l’application de la connexion entrante est définie en lecture seule (par exemple, à l’aide du mot clé Application Intent=ReadOnly dans les chaînes de connexion ODBC ou OLEDB, ou dans les attributs ou les propriétés de connexion).
L’attribut d’intention d’application est stocké dans la session du client lors de la connexion. L’instance de SQL Server traite ensuite cette intention et détermine ce qu’il faut faire, selon la configuration du groupe de disponibilité et l’état en lecture-écriture actuel de la base de données cible dans le réplica secondaire.
Par exemple, pour vous connecter à un réplica en lecture seule dans SQL Server Management Studio, sélectionnez Options dans la boîte de dialogue Se connecter au serveur, sélectionnez l’onglet Paramètres de connexion supplémentaires, puis spécifiez ApplicationIntent=ReadOnly dans la zone de texte :
Voici un exemple de chaîne de connexion pour le fournisseur ADO.NET (System.Data.SqlClient) qui indique l’intention d’application en lecture seule :
Server=tcp:AGListener;Database=AdventureWorks;Integrated Security=SSPI;ApplicationIntent=ReadOnly
Pour plus d’informations, consultez Configurer l’accès en lecture seule sur un réplica de disponibilité (SQL Server)
Port nondefault
Quand vous créez un écouteur, vous spécifiez le port que l’écouteur doit utiliser. Si le port est le port par défaut 1433, vous n’avez pas à spécifier un numéro de port pour vous connecter à l’écouteur. En revanche, si le port à utiliser n’est pas le port 1433, vous devez spécifier le port dans la chaîne de connexion au format listenername,port, comme dans cet exemple :
Voici un exemple de chaîne de connexion pour le fournisseur ADO.NET (System.Data.SqlClient) qui spécifie un port autre que le port par défaut pour l’écouteur :
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Ignorer les écouteurs
Alors que les écouteurs de groupe de disponibilité permettent la prise en charge de la redirection de basculement et le routage en lecture seule, les connexions clientes ne sont pas requises pour les utiliser. Une connexion cliente peut également faire directement référence à l'instance de SQL Server au lieu de se connecter à l'écouteur du groupe de disponibilité.
Pour l’instance de SQL Server, cela ne fait aucune différence si une connexion est établie à l’aide de l’écouteur du groupe de disponibilité ou avec un autre point de terminaison d’instance. L'instance de SQL Server vérifie l'état de la base de données ciblée, puis autorise ou interdit la connectivité, selon la configuration du groupe de disponibilité et l'état actuel de la base de données sur l'instance. Par exemple, si une application cliente se connecte directement à une instance de port SQL Server et se connecte à une base de données cible hébergée dans un groupe de disponibilité, et que la base de données cible se trouve à l’état primaire et en ligne, la connectivité aboutit. Si la base de données cible est hors connexion ou dans un état de transition, la connectivité à la base de données échoue.
Autrement, lors d'une migration depuis une mise en miroir de bases de données vers Groupes de disponibilité Always On, les applications peuvent spécifier la chaîne de connexion de mise en miroir de bases de données dans la mesure où il existe un seul réplica secondaire et qu'il n'autorise pas les connexions utilisateur.
Chaînes de connexion de mise en miroir de bases de données
Si un groupe de disponibilité possède uniquement un réplica secondaire et est configuré avec ALLOW_CONNECTIONS = READ_ONLY ou ALLOW_CONNECTIONS = NONE pour le réplica secondaire, les clients peuvent se connecter au réplica principal à l'aide d'une chaîne de connexion de mise en miroir de bases de données. Cette approche peut être utile lors de la migration d'une application existante depuis la mise en miroir de bases de données vers un groupe de disponibilité, tant que vous limitez le groupe de disponibilité à deux réplicas de disponibilité (un réplica principal et un réplica secondaire). Si vous ajoutez des réplicas secondaires supplémentaires, vous devrez créer un écouteur de groupe de disponibilité pour le groupe de disponibilité et mettre à jour vos applications pour utiliser le nom DNS de l'écouteur du groupe de disponibilité.
Lors de l'utilisation de chaînes de connexion de mise en miroir de bases de données, le client peut soit utiliser SQL Server Native Client, soit le fournisseur de données .NET Framework pour SQL Server. La chaîne de connexion fournie par un client doit fournir au minimum le nom d'une instance de serveur, le nom du partenaire initial, pour identifier l'instance de serveur qui héberge initialement le réplica de disponibilité auquel vous envisagez de vous connecter. Éventuellement, la chaîne de connexion peut également fournir le nom d'une autre instance de serveur, le nom du partenaire de basculement, pour identifier l'instance de serveur qui héberge initialement le réplica secondaire comme nom de partenaire de basculement.
Pour plus d’informations sur les chaînes de connexion de mise en miroir de bases de données, consultez Connecter des clients à une session de mise en miroir de bases de données (SQL Server).
Basculements de plusieurs sous-réseaux
Si vous utilisez des bibliothèques clientes qui prennent en charge l’option de connexion MultiSubnetFailover dans la chaîne de connexion, vous pouvez optimiser le basculement du groupe de disponibilité vers un sous-réseau différent en définissant MultiSubnetFailover sur « True » ou « Yes », selon la syntaxe du fournisseur que vous utilisez.
Remarque
Nous vous recommandons de définir ce paramètre à la fois pour les connexions à un seul ou à plusieurs sous-réseaux aux écouteurs de groupes de disponibilité et aux noms d'instance de cluster de basculement SQL Server. L'activation de cette option ajoute des optimisations supplémentaires, même pour les scénarios de sous-réseau unique.
L’option de connexion MultiSubnetFailover fonctionne uniquement avec le protocole réseau TCP et elle est prise en charge uniquement lors de la connexion à un écouteur de groupe de disponibilité et pour n’importe quel nom de réseau virtuel se connectant à SQL Server.
Voici un exemple de chaîne de connexion du fournisseur ADO.NET (System.Data.SqlClient) qui permet le basculement de plusieurs sous-réseaux :
Server=tcp:AGListener,1433;Database=AdventureWorks;Integrated Security=SSPI; MultiSubnetFailover=True
L’option de connexion MultiSubnetFailover doit prendre la valeur True même si le groupe de disponibilité s’étend sur un seul sous-réseau. Cela vous permet de préconfigurer de nouveaux clients afin de prendre en charge la future couverture de sous-réseaux, sans recourir à de futures modifications de la chaîne de connexion du client. Par ailleurs, cela permet d'optimiser les performances de basculement pour les basculements au sein d'un seul sous-réseau. Alors que l’option de connexion MultiSubnetFailover n’est pas obligatoire, elle offre l’avantage d’un basculement de sous-réseau plus rapide. Cela est dû au fait que le pilote client essaie d'ouvrir un socket TCP pour chaque adresse IP en parallèle associée au groupe de disponibilité. Le pilote client attend une réponse correcte de la première adresse IP et, ceci fait, l'utilise pour la connexion.
Écouteurs et certificats TLS/SSL
Lors de la connexion à un écouteur de groupe de disponibilité, si les instances participantes de SQL Server utilisent des certificats TLS/SSL en même temps que le chiffrement de session, le pilote client de la connexion doit prendre en charge le nom SAN (Subject Alternate Name) dans le certificat TLS/SSL afin de forcer le chiffrement.
Un certificat X.509 doit être configuré pour chaque nœud serveur participant dans le cluster de basculement, avec une liste de tous les écouteurs de groupe de disponibilité définis dans le nom SAN du certificat.
Le format des valeurs du certificat est le suivant :
CN = Server.FQDN
SAN = Server.FQDN,Listener1.FQDN,Listener2.FQDN
Par exemple, si vous avez les valeurs suivantes :
Servername: Win2019
Instance: SQL2019
AG: AG2019
Listener: Listener2019
Domain: contoso.com (which is also the FQDN)
Pour un cluster WSFC qui a un seul groupe de disponibilité, le certificat doit avoir le nom de domaine complet (FQDN) du serveur et le nom de domaine complet de l’écouteur :
CN: Win2019.contoso.com
SAN: Win2019.contoso.com, Listener2019.contoso.com
Avec cette configuration, vos connexions seront chiffrées lors de la connexion à l’instance (WIN2019\SQL2019) ou à l’écouteur (Listener2019).
En fonction de la configuration de la mise en réseau, il existe un petit sous-ensemble de clients qui peuvent également avoir besoin d’ajouter le NetBIOS au réseau SAN. Dans ce cas, les valeurs du certificat doivent être :
CN: Win2019.contoso.com
SAN: Win2019,Win2019.contoso.com,Listener2019,Listener2019.contoso.com
Si le cluster WSFC dispose de trois écouteurs de groupe de disponibilité, par exemple : Listener1, Listener2, Listener3
Les valeurs de certificat doivent être les suivantes :
CN: Win2019.contoso.com
SAN: Win2019.contoso.com,Listener1.contoso.com,Listener2.contoso.com,Listener3.contoso.com
Écouteurs et Kerberos (SPN)
Un administrateur de domaine doit configurer un nom de principal de service (SPN) dans Active Directory pour chaque écouteur du groupe de disponibilité afin d’activer Kerberos pour les connexions clientes vers l’écouteur. Lors de l’inscription du SPN, vous devez utiliser le compte de service de l’instance de serveur qui héberge le réplica de disponibilité. Pour que le SPN fonctionne sur tous les réplicas, le même compte de service doit être utilisé pour toutes les instances du cluster WSFC qui héberge le groupe de disponibilité.
Utilisez l’outil de ligne de commande setspn Windows pour configurer le SPN. Par exemple, pour configurer un SPN pour un écouteur de groupe de disponibilité nommé AG1listener.Adventure-Works.com hébergé dans un ensemble d'instances de SQL Server, toutes configurées pour s'exécuter sous le compte de domaine corp\svclogin2 :
setspn -A MSSQLSvc/AG1listener.Adventure-Works.com:1433 corp\svclogin2
Pour plus d'informations sur l'inscription manuelle d'un SPN pour SQL Server, consultez Inscrire un nom de principal du service pour les connexions Kerberos.