Amélioration
L’SQL Server d’écoute FCI (Failover Cluster Instance) de SQL Server 2019 et 2016 est améliorée pour fonctionner ensemble avec le point d’accès au cluster de Windows Server Failover Cluster (WSFC) Distributed Network Name (DNN).
Informations supplémentaires
SQL Server L’auditeur DFCI (Failover Cluster Instance) fonctionne actuellement uniquement avec le nom de réseau Windows Server Failover Cluster (WSFC) et le point d’accès IP virtuel. Étant donné que l’adresse IP virtuelle ne fonctionne pas dans l’environnement Azure, vous devez configurer un équilibreur de charge interne Azure pour contourner ce problème (découvrez comment configurer un équilibreur de charge interne Azure).
Cette mise à jour permet au client SQL Server de se connecter à FCI sans équilibrage de charge à l’aide de la ressource DNN (Distributed Network Name) dans un cluster de changement de serveur Windows. Lorsqu’une ressource DNN est créée, WSFC lie le nom DNS DNN aux adresses IP de tous les nodes dans le cluster. Le SQL Server va essayer de connecter chaque adresse IP de cette liste pour trouver le nœud sur quoi l’ID FCI est en cours d’exécution. Ce processus de connexion est encore plus rapide en connectant toutes les adresses IP en parallèle si la propriété de connexion SQL Server MultiSubnetFailover est vraie. Cela permet au client SQL Server de se connecter instantanément à l’ÉC FCI en cours d’exécution.
Par rapport à la solution de contournement précédente de l’utilisation d’Azure Internal Load Balancer, l’approche de l’auditeur DNN permet d’éviter la latence supplémentaire de basculement présentée par la succession de l’équilibrage de la charge. Par défaut, ce processus dure 10 à 15 secondes. (Consultez ce document Azuresur le calcul de la latence.) Vous n’avez pas besoin de configurer et de gérer les composants de l’équilibrage de charge. Cela simplifie le processus de mise en service. La suppression de l’équilibreur de charge supprime également un composant susceptible d’échouer. Cela améliore la robustesse globale.
Les étapes suivantes sont nécessaires pour utiliser cette fonctionnalité :
-
Pour une FCI installée, vous devez créer une ressource DNN et définir son nom DNS. Exécutez les trois commandes PowerShell suivantes en tant qu’administrateur :
-
Add-ClusterResource -Name <dnnResourceName> -ResourceType « Distributed Network Name » -Group « <WSFC role of SQL server instance> »
Get-ClusterResource -Name <dnnResourceName> | Set-ClusterParameter -Name DnsName -Value <DNSName>
Start-ClusterResource -Name <dnnResourceName>
Par exemple :
-
Add-ClusterResource -Name dnn-demo -ResourceType « Distributed Network Name » -Group « SQL Server (MSSQLSERVER) »
Get-ClusterResource -Name dnn-demo | Set-ClusterParameter -Name DnsName -Value dnnlsnr
Start-ClusterResource -Name dnn-demo
Explication :
-
La première commande ajoute une ressource DNN au WSFC en ayant un nom de ressource <dnnResourceName>. Le nom de la ressource est utilisé par WSFC pour identifier de manière unique une ressource WSFC. Utilisez-en un qui a du sens pour vous et qui est unique dans le cluster WSFC. Le type de ressource doit être Nom du réseau distribué. Le nom du groupe à qui appartient cette ressource DNN doit être le groupe de ressources (rôle) WSFC correspondant à l’ÉCF à qui vous voulez ajouter la ressource DNN. Le format classique de ce nom de groupe est « SQL Server (nom de l’instance) ». Par conséquent, pour l’instance par défaut, le nom sera « SQL Server (MSSQLSERVER) ». Vous pouvez également vérifier le nom du groupe dans la console Gestionnaire de clusterover.
-
La deuxième commande définit le nom DNS de cette ressource DNN. Le nom DNS est important, car il s’agit du nom que les clients utilisent pour se connecter à l’FCI.
-
La troisième commande démarre la ressource DNN.
Par défaut, le nom DNN DNS se lie à tous les noms dans WSFC. Configurez le propriétaire possible de la ressource DNN de telle sorte qu’elle n’inclue que les seuls nodes de cette FCI si tous les non-niveaux dans WSFC participent à l’FCI.
-
-
Redémarrer SQL Server instance.
-
Remplacez le nom de réseau virtuel (VNN) dans la chaîne de connexion du client SQL par le nom DNS DNN, puis définissez la propriété MultiSubnetFailover sur « true ». Vous pouvez ignorer ce paramètre si SQL version du client est ultérieure à 4.6.1.
Résolution
Cette amélioration est incluse dans la mise à jour cumulative suivante pour SQL Server :
À propos des mises à jour cumulatives SQL Server :
Chaque nouvelle mise à jour cumulative SQL Server contient tous les correctifs et tous les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
Informations sur le Service Pack SQL Server 2016
Ce problème est résolu dans le Service Pack suivant pour SQL Server :
Les Service Packs sont cumulatifs. Chaque nouvelle version contient tous les correctifs fournis dans les Service Packs précédents et tous les nouveaux correctifs. Nous vous recommandons d’appliquer le dernier Service Pack et la dernière mise à jour cumulative pour ce Service Pack. Il n'est donc pas nécessaire d'installer la version antérieure d'un Service Pack avant d'installer la dernière version disponible. Utilisez le tableau 1 dans l’article suivant pour trouver des informations supplémentaires sur le dernier Service Pack et la dernière mise à jour cumulative.
Déterminer la version, l’édition et le niveau de mise à jour SQL Server et ses composants
Références
En savoir plus à propos de la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.
