Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S'applique à :
SQL Server
Cet article explique comment vous connecter à un écouteur de groupe de disponibilité Always On pour SQL Server. Un listener 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 la réplique de disponibilité qui est actuellement l'hôte de 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înes 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înes 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.
Exemple de chaîne de connexion de base pour le fournisseur ADO.NET (Microsoft.Data.SqlClient ou System.Data.SqlClient) :
Server=tcp: AGListener,1433;Database=MyDB;Integrated Security=SSPI
Remarque
Microsoft.Data.SqlClient est le fournisseur de données ADO.NET recommandé pour le nouveau développement d’applications. Il prend en charge les mêmes mots clés de chaîne de connexion que System.Data.SqlClient. Pour plus d’informations, consultez Présentation de l’espace de noms Microsoft.Data.SqlClient.
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
Par exemple, quand SQLVM1 est le 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 seront plus automatiquement routées vers le 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
Le routage en lecture seule consiste à router automatiquement les connexions entrantes de l'écouteur vers une réplique secondaire lisible qui est configurée pour autoriser des charges de travail en lecture seule.
Les connexions sont automatiquement routées vers la réplique 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 le login utilisé dans la connexion 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 d'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 propriétés de connexion).
L’attribut d’intention de l’application est stocké dans la session du client pendant la connexion. L’instance de SQL Server traite l’intention et détermine ce qu’il faut faire en fonction de la configuration du groupe de disponibilité et de 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 à l’aide de 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 :
Exemple de chaîne de connexion pour le fournisseur ADO.NET (Microsoft.Data.SqlClient ou System.Data.SqlClient) qui désigne 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 une réplique de disponibilité (SQL Server)
Port non par défaut
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 :
Exemple de chaîne de connexion pour le fournisseur ADO.NET (Microsoft.Data.SqlClient ou System.Data.SqlClient) qui spécifie un port non défini pour l’écouteur :
Server=tcp:AGListener,1445;Database=AdventureWorks;Integrated Security=SSPI
Ignorer les écouteurs
Bien que les écouteurs des groupes de disponibilité permettent la prise en charge de la redirection de basculement et du routage en lecture seule, il n'est pas nécessaire que les connexions clients les utilisent. Une connexion client peut également faire directement référence à l'instance de SQL Server au lieu de se connecter à l'auditeur 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 et autorise ou interdit la connectivité en fonction de la configuration du groupe de disponibilité et de 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 transitionnel, la connectivité à la base de données échoue.
Autrement, lors d'une migration depuis la mise en miroir de bases de données vers les Groupes de Disponibilité Always On, les applications peuvent spécifier la chaîne de connexion de mise en miroir de bases de données, à condition qu'il n'existe qu'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 de la mise en miroir de bases de données vers un groupe de disponibilité, tant que vous limitez le groupe de disponibilité à deux répliques de disponibilité (une réplique principale et une réplique 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. Optionnellement, 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 en tant que nom du 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 sur des sous-réseaux uniques ou multiples pour les points d'écoute des groupes de disponibilité et pour les noms d'instance de basculement de cluster 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 (Microsoft.Data.SqlClient ou System.Data.SqlClient) qui permet le basculement multi-sous-réseau :
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. Cette option vous permet de préconfigurer de nouveaux clients pour prendre en charge l’étendue future des sous-réseaux sans avoir à modifier les futures chaînes de connexion client et optimise également les performances de basculement pour les basculements de sous-réseaux uniques. Alors que l’option de connexion MultiSubnetFailover n’est pas obligatoire, elle offre l’avantage d’un basculement de sous-réseau plus rapide. Le pilote client tente d’ouvrir un socket TCP pour chaque adresse IP en parallèle associée au groupe de disponibilité. Le pilote client attend que la première adresse IP réponde avec succès et une fois celle-ci établie, 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 conjointement avec le chiffrement de session, le pilote client doit prendre en charge le nom alternatif du sujet dans le certificat TLS/SSL pour 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 Alternatif du Sujet (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, votre connexion est chiffrée 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 auditeurs de groupe de disponibilité, tels que 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
Listeners et Kerberos (SPNs)
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.