Cet article décrit un problème rencontré il y a peu et qui nous a fait nous creuser la tête. Il s’agit une connexion à un AlwaysOn 2016 en multi-subnet, mais ça aurait très bien pu être une configuration cluster classique (FCI) en multi-subnet.
Les symptômes présentés étaient les suivants : dans un groupe de disponibilité AlwaysOn SQL Server 2016 + Windows Server 2016 en multi-subnet, certains clients n’arrivent pas à se connecter en ODBC.
Le premier réflexe a été de sous-estimer le problème : il suffit juste de cocher “multisubnet failover” dans le driver !
Sauf que non. C’était coché.
Deuxième réflexe : ça doit être surement être un problème de DNS : les 2 IP ne sont pas enregistrées par le cluster !
Sauf que non : un nslookup sur le nom du listener AlwaysOn renvoie bien les 2 IP.
Donc là, ça y est, on est dans la twilight zone.
Pour comprendre le problème, il faut déjà bien saisir le fonctionnement du cluster en multi-subnet.
Un cluster, ou un AlwaysOn peu importe, en multi-subnet, implique l’utilisation d’au moins 2 adresses IP dans des subnets différents. La solution “moderne” implique que les 2 IP sont enregistrées dans le DNS. Quand un client demandera donc à résoudre le nom du listener ou le nom de l’instance clusterisée, il va interroger le DNS et récupérer les 2 IP. Avec les mécanismes de Round-Robin le client va donc avoir du mal à se connecter ! En théorie, il se connectera une fois sur deux sur la bonne IP. Pour éviter ce problème, les drivers de connexion modernes disposent d’une option “multisubnet failover” et même encore plus récemment “Transparent Network IP resolution”. Leur combinaison change un peu la manière dont se comporte le driver : https://docs.microsoft.com/en-us/sql/connect/odbc/using-transparent-network-ip-resolution?view=sql-server-2017
Dans le doute, pour vérifier que les comportements attendus et obtenus étaient bien identiques, nous avons utilisé un Wireshark. Pour ceux qui ne connaissent pas, c’est un outil capture les trames réseaux échangées. Et là, nous avons bien vu que nous avions, comme attendu, deux connexions effectuées simultanément sur les deux IP enregistrées dans le DNS.
Sur la première IP (celle active), nous voyons bien le 3-way handshake s’effectuer normalement : la connexion s’établit bien (pas de souci réseau). Sur la deuxième IP : pas de réponse (normal : l’IP est inactive dans le cluster). Sauf que le driver ODBC refuse de considérer la réponse :
[Microsoft][ODBC Driver 13 for SQL Server]Unable to complete login process due to delay in opening server connection :
De là, après avoir testé différentes combinaisons de drivers, des tests de bascules, réseau DNS et j’en passe : toujours pas l’ombre d’une solution…
Jusqu’à tomber sur ce bug référencé chez Microsoft (KB2870437) :
Il est bien proposé un hotfix, mais il n’est plus téléchargeable chez Microsoft directement. Quelques recherches dans votre moteur de recherche favoris permettent de le retrouver quand même sans trop de difficultés. Ou sinon ici chez nous.
Même si j’avais un Windows Update à jour sur ce serveur, ce fix ne semble pas passer systématiquement. Donc : à installer à la main.
Une fois le patch installé, machine redémarrée : tout est rentré dans l’ordre !
Continuez votre lecture sur le blog :
- Haute disponibilité d’Oracle database sous Windows : et pourquoi pas Fail Safe ? (Capdata team) [Oracle]
- Se connecter à SQL Server à travers Oracle, quelle drôle d’idée ? (Capdata team) [OracleVintage]
- Les Managed Service Account (MSA et gMSA) : se simplifier la vie pour gérer ses comptes de service SQL Server (Capdata team) [Operating SystemSQL Server]
- Le chiffrement et SQL Server – Episode 1 : Transparent Data Encryption (TDE) vs Always Encrypted (Capdata team) [SQL Server]
- Les nouveautés de SQL Server 2022 (Capdata team) [SQL Server]