Maintenant que les groupes de disponibilité sont de plus en plus répandus, j'ai pensé couvrir un sujet qui peut être négligé lors de la planification et de l'installation initiales de SQL Server dans ce type d'environnement. Afin d'avoir vraiment une configuration tolérante aux pannes, il faut réfléchir et planifier la configuration de la connectivité de la base de données.
Je n'entrerai pas dans les détails de la configuration de votre environnement AlwaysOn dans cet article, mais pour une aide supplémentaire, je vous suggère de jeter un œil à l'article d'Aaron Bertrand, "Troubleshooting AlwaysOn - Parfois, cela prend plusieurs paires d'yeux". Une fois votre environnement configuré, l'étape suivante pour assurer la connectivité de la base de données consiste à créer un écouteur de groupe de disponibilité à l'aide de SQL Management Studio ou T-SQL :
ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (WITH IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433);
Chaînes de connexion de l'écouteur AG
Votre nom de réseau virtuel (VNN) est enregistré dans le DNS et appartient toujours à l'instance SQL Server où réside le réplica principal. Toutes les adresses IP fournies lors de la configuration de l'écouteur AG sont enregistrées dans le DNS sous le même nom de réseau virtuel.
Après avoir créé votre AG Listener, vous devez vous assurer que vos clients peuvent se connecter. Votre connexion d'application fonctionne de la même manière qu'elle l'a toujours fait, cependant, au lieu de pointer vers un serveur spécifique dans votre chaîne de connexion, vous pointez vers l'AG Listener.
Les écouteurs AG ne peuvent être connectés qu'à l'aide de TCP et sont résolus par votre DNS local à la liste des adresses IP et des ports TCP qui sont mappés au VNN. Votre client tentera de se connecter à chacune des adresses IP tour à tour jusqu'à ce qu'il obtienne une connexion ou jusqu'à ce qu'il atteigne un délai de connexion. Un paramètre de chaîne de connexion important à envisager d'utiliser est MultiSubnetFailover. Si ce paramètre est défini sur true, le client tentera les connexions en parallèle, permettant une connectivité plus rapide et, si nécessaire, des basculements client plus rapides :
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True
Lorsqu'un basculement se produit, les connexions client sont réinitialisées et la propriété de l'écouteur AG est transférée à l'instance SQL Server qui prend le relais du rôle de réplica principal. Le point de terminaison VNN est ensuite lié aux nouvelles adresses IP et ports TCP de la nouvelle instance de réplica principale. Selon le client, une reconnexion automatique à l'AG se produira, ou l'utilisateur devra peut-être redémarrer manuellement l'application ou la connexion affectée.
Intention de l'application
L'une des principales raisons d'implémenter des groupes de disponibilité est de fournir la possibilité de tirer parti de vos environnements de sauvegarde ou de reprise après sinistre pour décharger le travail de votre environnement de production. Ces serveurs peuvent désormais être utilisés pour des sauvegardes, des analyses, des requêtes ad hoc et des rapports, ou toute autre opération dans laquelle il suffit d'avoir une copie en lecture seule de la base de données.
Pour fournir un accès en lecture seule à vos réplicas secondaires, le paramètre de chaîne de connexion ApplicationIntent est utilisé. Une liste de routage en lecture seule facultative des points de terminaison SQL Server peut être configurée sur chaque réplica. Cette liste est utilisée pour rediriger les demandes de connexion client qui utilisent le paramètre ApplicationIntent=ReadOnly vers le premier réplica secondaire disponible qui a été configuré avec un filtre d'intention d'application approprié.
Server=tcp:MyAgListener,1433;Database=Db1;IntegratedSecurity=SSPI; MultiSubnetFailover=True;ApplicationIntent=ReadOnly;
Filtrage des intentions d'application
Pour faciliter l'intention d'application des clients se connectant à votre groupe de disponibilité, chaque instance SQL Server du groupe doit être configurée avec un filtre d'intention d'application approprié. Le filtre détermine les types de connexions que chaque réplique acceptera.
Un réplica principal qui est configuré pour avoir des connexions dans le rôle principal de "Autoriser toutes les connexions" acceptera toutes les connexions établies via l'écouteur AG. Un réplica principal configuré sur "Autoriser les connexions en lecture/écriture" rejettera toute connexion qui spécifie "ApplicationIntent=ReadOnly".
Lors de la configuration des réplicas, vous devez également définir si chacun sera ou non un secondaire lisible. Une réplique configurée sur "Non" refusera toutes les connexions. Cette réplique est supposée être utilisée uniquement pour le basculement dans une situation de reprise après sinistre. Si le réplica secondaire est configuré sur "Oui", toutes les connexions seront autorisées, mais uniquement pour l'accès en lecture, même si "ApplicationIntent=ReadOnly" n'est pas spécifié. Enfin, si le secondaire est configuré en "Intent en lecture seule", seuls les clients qui spécifient "ApplicationIntent=ReadOnly" seront autorisés à se connecter.
Routage en lecture seule
Maintenant que nous savons comment configurer l'intention d'application sur les instances de serveur et créer les chaînes de connexion nécessaires, nous devons configurer le routage en lecture seule du groupe de disponibilité. Lorsque vous vous connectez à l'écouteur AG à l'aide de la chaîne de connexion définie ci-dessus, l'écouteur interroge l'instance de réplica principale et détermine si la connexion doit être établie avec l'instance principale (lecture/écriture) ou avec une instance secondaire en lecture seule. Pour ce faire, une liste de routage doit être créée pour CHAQUE réplica de disponibilité qui est utilisée si et quand le réplica assume le rôle de principal. En règle générale, la meilleure pratique consiste à inclure chaque URL de routage en lecture seule pour chaque réplica secondaire en lecture seule avec l'URL du réplica local à la fin de la liste. Les demandes de connexion d'intention de lecture sont acheminées vers le premier secondaire accessible en lecture disponible sur la liste de routage, il n'y a pas d'équilibrage de charge entre les secondaires.
Tout d'abord, modifiez chaque réplique pour fournir l'URL de routage en lecture seule :
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER01.mydomain.com:1433')); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY)); ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH (SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://COMPUTER02.mydomain.com:1433'));
Deuxièmement, modifiez chaque réplique pour fournir la liste de routage en lecture seule à utiliser lorsque la réplique donnée est dans le rôle principal :
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER01' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER02','COMPUTER01')));
ALTER AVAILABILITY GROUP [Group1] MODIFY REPLICA ON N'COMPUTER02' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST=('COMPUTER01','COMPUTER02'))); L'URL de routage doit être sous la forme "TCP://:". Pour vous aider à déterminer votre URL, consultez ce blog et ce script créés par Matt Neerincx.
Conclusion
Avec votre routage en lecture seule configuré, AG Listener créé et vos applications clientes utilisant les chaînes de connexion correctes, vous devriez avoir une connexion entièrement tolérante aux pannes pour votre groupe de disponibilité. Assurez-vous de prendre le temps de tester votre connectivité et la capacité de vos applications à suivre vos serveurs en cas de basculement.
