Windows Server Failover Clustering (WSFC)

Windows Server Failover Clustering : fondation des solutions de clustering

22 minutes à lire

Comprendre WSFC

WSFC signifie Windows Server Failover Clustering. C’est le « nouveau » service de cluster, qui remplace MSCS (Microsoft Clustering Service), qui date des années 90.

WSFC est disponible dans l’édition standard de Windows à partir de Windows Server 2012.

Il offre un basculement automatique de services cluster-aware.

C’est une fonctionnalité à ajouter dans le gestionnaire de serveur Windows.

Terminologie

Fonctionnalités

Métadonnées et notifications distribuées – Propagation des modifications d’état.
Gestion des ressources – Les ressources du cluster sont basculables. Dépendance des ressources possible.
Contrôle d’intégrité – Surveillance des ressources et heartbeat. Vote de quorum pour le basculement.
Coordination du basculement – Transfert automatique ou manuel de ressources. Notification aux ressources.

Heartbeat

Réseau privé dédié au heartbeat

Désactiver Netbios

Choisir l’ordre dans la communication du cluster

La même interface peut prendre en charge le trafic et le heartbeat

Le Quorum

Un cluster est un groupe de machines et de ressources qui collaborent. Les différents nœuds d’un cluster peuvent accéder à des ressources partagées, comme un emplacement disque, par exemple. Il est important que le disque ne soit accédé que par un seul nœud à la fois, sinon, cela risque de provoquer de la corruption de données.

Comment faire pour s’assurer qu’un seul nœud accède à une ressource à la fois ? Il faut un mécanisme de régulation des nœuds qui permette d’éviter les situations où plusieurs nœuds pensent être principaux, ce qu’on appelle une situation de split brain.

Ce mécanisme de régulation s’appelle le Quorum.

La définition du terme quorum par le dictionnaire Le Robert est la suivante :

Droit ou administratif : Nombre minimum de membres présents pour qu’une assemblée puisse valablement délibérer.

Pour WSFC, cela signifie qu’il doit y avoir une majorité de membres, qu’on appelle des « votants », en ligne et en communication les uns avec les autres pour que le cluster fonctionne.

Un votant est soit un nœud du cluster, soit un disque ou un emplacement de partage, qui contient une copie de la base de données du cluster. La configuration du quorum détermine le nombre de défaillances de votants que le cluster peut supporter tout en restant en ligne.

Atteindre le quorum signifie qu’il reste dans le système un nombre suffisant de votants pour assurer la santé du cluster. Il faut à tout moment éviter toute corruption potentielle d’un disque en raison de la présence simultanée de deux propriétaires. Si le quorum n’est pas atteint, le cluster forcera le service de cluster à s’arrêter pour s’assurer que le nœud ne puisse pas faire de bêtise.

Rôles et ressources

Un cluster sert à gérer des ressources qui vont être actives sur un nœud, et qui vont pouvoir basculer au besoin. Ces ressources sont groupées dans un rôle, ce qu’on appelait auparavant un groupe de ressources (ancienne terminologie MSCS).

Toutes les ressources à l’intérieur d’un rôle, basculent ensemble, dans un ordre de précédence établi par la configuration du rôle.

Par exemple, lorsque vous créer un groupe de disponibilité AlwaysOn, cela crée un rôle qui comporte la ressource du groupe de disponibilité, et la ressource du listener.

Quand vous créer un cluster de basculement SQL Server, les services SQL Server et SQL Server Agent, ainsi que les partitions partagées pour les données et les journaux, sont des ressources dans le même rôle. Lors d’un basculement, l’ordre de précédence de démarrage des ressources sur le nouveau nœud, est le suivant :

partitions,
service SQL Server,
service SQL Agent.

C’est un ordre de démarrage logique en rapport avec les besoins de chaque service.

Pour faire partie d’un rôle, une application comme SQL Server doit être « cluster-aware », c’est-à-dire qu’elle doit pouvoir s’insérer comme ressource dans un rôle, et collaborer avec le service de cluster.

WSFC peut aussi gérer des ressources non cluster-aware, d’une façon plus brutale (démarrage et arrêt du service par exemple).

En cas de cluster de basculement, le service SQL Server est géré par WSFC, et doit être installé comme service dans le cluster.

En cas de groupe de disponibilité, le service SQL Server communique avec WSFC, mais n’est pas géré par lui.

On peut considérer les ressources comme des « plugins » de WSFC. Ce sont des DLL qui permettent l’interopérabilité avec WSFC. Elles sont en général développées en C++ avec l’entête resapi.h6https://docs.microsoft.com/en-us/windows/win32/api/resapi/ .

Types de ressources

Les types de ressources classiques dans un rôle WSFC sont :

partitions de disques partagés ;
adresses IP virtuelles (VIP, pour Virtual IP) ;
noms de domaine virtuels (VNN, pour Virtual Network Name) ;
services Windows.

Les VIP et VNN permettent d’accéder par une seule adresse au nœud actif du rôle. WSFC se charge de rediriger la connexion sur le nœud actif.

Gestion des ressources

Les ressources d’un cluster sont gérées par des DLL spécifiques. Ces DLL sont hébergées par le processus RHS.exe du cluster, appelé Resource Hosting Subsystem (sous-système d’hébergement de ressources).

On le voit marqué [RHS] dans le journal du cluster.

La gestion des ressources qui font parties du RHS est de la responsabilité du Resource Control Manager (RCM), qui est In-Process dans le service de cluster (WSFC).

Ce sous-système est responsable de la surveillance des ressources qui font partie d’un rôle de cluster.

On le voit marqué [RCM] dans le journal du cluster.

Composants dans un groupe de disponibilité

Chaque nœud dans le cluster exécute une seule instance du service de cluster, qui gère le cluster de basculement et surveille toutes les ressources du cluster.

L’hôte de ressource (Resource host) fonctionne en processus séparé et est l’interface entre le service de cluster et les ressources du cluster. L’hôte de ressource réalise des opérations sur les ressources du cluster lorsqu’il est sollicité par le service de cluster. Les applications cluster-aware comme SQL Server fournissent des interfaces personnalisées au moniteur de ressource via des DLL de ressource. La DLL de ressource implémente les opérations en ligne et hors ligne ainsi que la surveillance de la santé pour les ressources personnalisées. L’hôte de ressource est un processus enfant du service de cluster et est arrêté chaque fois que le service de cluster est arrêté.

Pour SQL Server, la DLL de ressource AG détermine la santé de l’AG basée sur le mécanisme de bail de l’AG et la détection de santé Always On. La DLL de ressource AG expose la santé de la ressource à travers l’opération IsAlive. Le moniteur de ressource interroge IsAlive à l’intervalle de battement de cœur du cluster, qui est défini par les valeurs globales du cluster CrossSubnetDelay et SameSubnetDelay. Sur un nœud principal, le service de cluster initie des basculements chaque fois que l’appel IsAlive à la DLL de ressource retourne que l’AG n’est pas sain.

Le service de cluster envoie des battements de cœur aux autres nœuds dans le cluster et accuse réception des battements de cœur reçus d’eux. Lorsqu’un nœud détecte une défaillance de communication à partir d’une série de battements de cœur non accusés de réception, il diffuse un message provoquant la réconciliation de leur vue de la santé du nœud de cluster par tous les nœuds atteignables. Cet événement, appelé un événement de regroupement, maintient la cohérence de l’état du cluster à travers les nœuds. Suite à un événement de regroupement, si le quorum est perdu alors toutes les ressources du cluster y compris les AG dans cette partition sont prises hors ligne. Tous les nœuds dans cette partition sont transitionnés vers un état de résolution. Si une partition existe, qui détient un quorum, l’AG sera attribué à un nœud dans la partition et deviendra la réplique principale tandis que tous les autres nœuds seront des répliques secondaires.

Mise en œuvre

Installation

Ajout de fonctionnalité dans Windows Server
Validation du cluster
L’inscription du cluster est faite automatiquement dans l’AD
Cluster Name Object = CNO = clustername$
Le compte utilisé pour créer le cluster doit avoir la permission de créer un compte de machine dans l’AD.
Configuration du quorum

Gérer les permissions du CNO

CNO (Cluster Name Object)

A les permissions nécessaires dans les cas simples
doit avoir le privilège « Create Computer Objects » dans son OU (Organizational Unit)
Les VCO sont créés dans l’OU du CNO.
Dans un environnement restrictif, le CNO peut être créé dans une OU spécifique.
Ajouter le distinguished name.

New-Cluster -Name CN=MyCluster,OU=Cluster,DC=Contoso,DC=com -Node node1,node2

Pré-staging

Si le compte qui crée le cluster n’a pas les permissions suffisantes sur l’Active Directory, vous devez procéder à un « pré-staging ».

Création du CNO (Cluster Name Object) à l’aide de l’outil Active Directory Users and Computers (dsa.msc).
Désactiver le CNO – L’assistant de création du cluster va tester que le CNO n’est pas utilisé.
Tous les rôles de cluster ont un VCO (Virtual Computer Object) – Pour les pré-créer : dans dsa.msc : View / Advanced Features.
Inscrire les VCO dans le DNS – Donner une permission « Full Control » à ces entrées au CNO.

Pré-installation pour le failover clustering ou AlwaysOn AG

Vous pouvez installer WSFC sur un seul nœud, et créer un cluster d’un nœud, afin de vous préparer à construire une vraie haute disponibilité plus tard.

Vous pouvez ensuite installer SQL Server sur ce cluster sur un seul nœud, ou configurer AlwaysOn pour fonctionner sur ce cluster. Vous serez ainsi prêt à ajouter un deuxième nœud plus tard, sans arrêt de service.

Créer et supprimer un cluster

Créer un cluster en Powershell

New-Cluster -Name cluster1 -Node node1,node2 -StaticAddress 2.0.0.123 -NoStorage

Supprimer un cluster en Powershell

Remove-Cluster -Force -CleanupAD

Si vous avez un message : « le nœud est déjà connecté à un cluster »

Clear-ClusterNode

Comprendre le quorum

Pour le basculement automatique, vous devez avoir une majorité. Pour devenir principal, un secondaire doit pouvoir parler à quelqu’un : prévention du split brain.
En général, on utilise en troisième acteur un témoin (partage de fichier, disque partagé), au lieu d’un troisième nœud.
Ce témoin doit obligatoirement résider sur une machine ou VM séparée. Mettre deux acteurs sur une même machine équivaut à une bombe à retardement.
Chaque nœud envoie une pulsation régulière (heartbeat)
Chaque nœud participe au quorum : statut déterminé par un vote de quorum périodique
Absence de quorum = cluster non intègre. WSFC passe hors connexion, les instances SQL Server s’arrêtent.
Récupération possible par quorum forcé.

Les modes de quorum

Nœud majoritaire – Vote à la majorité des nœuds
Nœud et partage de fichiers majoritaires – Vote à la majorité des nœuds + partage de fichiers témoin. La connectivité d’un nœud au partage est comptabilisée. (partage sur machine séparée !)
Nœud et disque majoritaire – Vote à la majorité des nœuds + disque partagé témoin
Disque uniquement – Vote par accès à un disque partagé témoin.

Le File Share Witness (FSW)

La connectivité d’un nœud au partage est comptabilisé

Partage sur machine séparée !

Permission à donner au CNO

No stocke pas la configuration du cluster (comme le disque de quorum), mais quelle est la base de configuration la plus récente.

On ne peut pas demander un accès exclusif au FSW.
5 Mo minimum.
Ne doit pas contenir de fichier.
Ne peut servir qu’à un cluster.

Configurer le quorum

Vous pouvez configurer le quorum graphiquement, avec le menu contextuel du cluster dans la gestionnaire de cluster, comme le montre la copie d’écran suivante.

Pour choisir un témoin de partage de fichier, choisissez l’option « Sélectionnez un témoin de quorum ».

Vous pouvez utiliser également Powershell. L’exemple de code suivant définit un témoin de partage de fichier.

Set-ClusterQuorum -NodeAndFileShareMajority "\\fileserver\fsw"

After the wizard runs and the Summary page appears, if you want to view a report of the tasks that the wizard performed, click View Report. The most recent report will remain in the systemroot\Cluster\Reports folder with the name QuorumConfiguration.mht.

Référence : https://docs.microsoft.com/fr-fr/windows-server/failover-clustering/manage-cluster-quorum

Vous pouvez obtenir les informations de quorum du cluster à l’aide de la cmdlet Get-ClusterQuorum.

Get-ClusterQuorum -Cluster clu01

La configuration du quorum dans un cluster de basculement détermine le nombre de défaillances que le cluster peut supporter. Si une panne supplémentaire se produit, le cluster doit cesser de fonctionner.

Quorum dynamique

Depuis Windows Server 2012, WSFC implémente une technique de quorum dynamique. La majorité se recalcule dynamiquement selon le nombre de votants.

Si un nœud est arrêté manuellement pour de la maintenance, par exemple, son vote est retiré du nombre de votants. Ce qui change la majorité nécessaire. Cela permet de sortir des nœuds pour de la maintenance en prenant moins de risque.

Si le nombre de votants est pair, le quorum dynamique attribue un non vote à un des acteurs.

À partir de Windows Server 2012 R2, il est très recommandé, sinon obligatoire, d’ajouter un témoin, témoin de disque ou témoin de partage de fichier. Celui-ci sera automatiquement sélectionné par le quorum dynamique si le nombre de nœuds est pair, ou silencieusement ignoré si le nombre de nœuds est impair7https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/understand-quorum .

La fonctionnalité de quorum dynamique est activée par défaut. Vous pouvez la désactiver si vous le souhaitez.

Pour savoir si le quorum dynamique est activé, vous pouvez lancer cette commande Powershell sur un des nœuds du cluster :

Get-Cluster | fl Name, DynamicQuorum

Pour activer le quorum dynamique

(Get-Cluster ClusterSQL1).DynamicQuorum=1

Valeurs de quorum du cluster

Deux valeurs indiquent la présence de votants et la valeur de vote attribué par le quorum dynamique :

NodeWeight – détermine si un nœud participe au quorum. Si le poids est 0, il est dans tous les cas non votant, et ne participe pas à déterminer la majorité.

DynamicWeight – le statut de vote actuellement défini par le système de quorum dynamique.

Le statut des votants peut être aussi affiché dans SQL Server, dans le tableau de bord d’AlwaysOn.

Vous pouvez afficher ces informations en utilisant Powershell :

Get-ClusterQuorum | ft Cluster, QuorumType -AutoSize
Get-ClusterNode | ft ID, NodeName, NodeWeight, DynamicWeight, State -AutoSize

Définir et voir les votes

(Get-ClusterNode sql1).NodeWeight=0
(Get-ClusterNode sql1).NodeWeight=1

Cloud Witness sur Azure

Utilisant Azure Storage.

Comment fonctionne un cluster sans témoin ?

Si vous n’avez pas de témoin, et que vous avez seulement deux nœuds, vous verrez un seul vote actif, comme sur l’image suivante.

Le vote d’un nœud est retiré par la fonctionnalité de quorum dynamique du cluster. Ainsi, la majorité est déterminée sur un seul vote. C’est un peu la loterie : si le nœud non votant tombe (ici sql2), le cluster survit. Si le nœud votant (ici sql1) tombe, le cluster n’est plus intègre et il tombe également. Si vous arrêtez correctement le nœud votant, il transfère son vote à l’autre nœud.

En fait, si vous avez un nombre de nœuds pair et aucun témoin, un des nœuds voit son vote annulé. Par exemple, seuls trois de quatre nœuds disposent d’un vote. Le nombre total de votes est donc de trois, et s’il reste deux survivants disposant d’un vote, ils forment une majorité.

Si vous avez un nombre pair de nœuds, il est donc fortement recommandé d’ajouter un témoin.

Gestion du quorum

Ajouter un nœud

When adding a new node into the cluster, it is important that NoStorage option is specified with the Add-ClusterNode cmdlet to make sure shared storage on all nodes are not added to the cluster during the join operation. Adding shared storage to cluster has a serious repercussion because all shared storage on all nodes will be OFFLINE when they are added to the cluster. This will crash SQL Server if you have databases residing on shared storage.

When node PTEMP1 is added into the cluster, a report will be generated and PowerShell will prompt for the location of the report. This process is similar to using the Failover Cluster Manager GUI to add a node into the cluster.

Get-Cluster CLUSQL01 | Add-ClusterNode PTEMP1 -NoStorage

Vérifier le quorum

Get-ClusterNode | ft name, dynamicweight, nodeweight, state -AutoSize

Dans le cas d’un cluster de deux nœuds, en quorum dynamique :

Name DynamicWeight NodeWeight State
---- ------------- ---------- -----
sql1             1          1    Up
sql2             0          1    Up

Gestion des votes

(Get-ClusterNode"Principal").NodeWeight=1
(Get-ClusterNode"Replica2").NodeWeight=0

Forcer le quorum

Absence de quorum = le cluster disparaît

Récupération possible par quorum forcé.

De préférence sur le nœud à forcer.

Dans le gestionnaire : Actions / Force Cluster Start

Powershell (elevated) (ne marche pas toujours) :

Start-ClusterNode -name SRV3 -FixQuorum
(Get-ClusterNode SRV3).NodeWeight = 1

En net.exe (ça, ça marche) :

net.exe stop clussvc
net.exe start clussvc /forcequorum

Force start cluster nodes

After you determine that you cannot recover your cluster by bringing the nodes or quorum witness to a healthy state, forcing your cluster to start becomes necessary. Forcing the cluster to start overrides your cluster quorum configuration settings and starts the cluster in ForceQuorum mode.

Forcing a cluster to start when it does not have quorum may be especially useful in a multisite cluster. Consider a disaster recovery scenario with a cluster that contains separately located primary and backup sites, SiteA and SiteB. If there is a genuine disaster at SiteA, it could take a significant amount of time for the site to come back online. You would likely want to force SiteB to come online, even though it does not have quorum.

When a cluster is started in ForceQuorum mode, and after it regains sufficient quorum votes, the cluster automatically leaves the forced state, and it behaves normally. Hence, it is not necessary to start the cluster again normally. If the cluster loses a node and it loses quorum, it goes offline again because it is no longer in the forced state. To bring it back `online when it does not have quorum requires forcing the cluster to start without quorum.

Important

After a cluster is force started, the administrator is in full control of the cluster.

The cluster uses the cluster configuration on the node where the cluster is force started, and replicates it to all other nodes that are available.

If you force the cluster to start without quorum, all quorum configuration settings are ignored while the cluster remains in ForceQuorum mode. This includes specific node vote assignments and dynamic quorum management settings.

Prevent quorum on remaining cluster nodes

After you have force started the cluster on a node, it is necessary to start any remaining nodes in your cluster with a setting to prevent quorum. A node started with a setting that prevents quorum indicates to the Cluster service to join an existing running cluster instead of forming a new cluster instance. This prevents the remaining nodes from forming a split cluster that contains two competing instances.

This becomes necessary when you need to recover your cluster in some multisite disaster recovery scenarios after you have force started the cluster on your backup site, SiteB. To join the force started cluster in SiteB, the nodes in your primary site, SiteA, need to be started with the quorum prevented.

Important

After a cluster is force started on a node, we recommend that you always start the remaining nodes with the quorum prevented.

To recover the cluster by using Failover Cluster Manager

In Failover Cluster Manager, select or specify the cluster you want to recover.

With the cluster selected, under Actions, click Force Cluster Start.

Failover Cluster Manager force starts the cluster on all nodes that are reachable. The cluster uses the current cluster configuration when starting.

Note

To force the cluster to start on a specific node that contains a cluster configuration that you want to use, you must use the Windows PowerShell cmdlets or equivalent command-line tools as presented after this procedure.

If you use Failover Cluster Manager to connect to a cluster that is force started, and you use the Start Cluster Service action to start a node, the node is automatically started with the setting that prevents quorum.

Windows PowerShell equivalent commands

The following example shows how to use the Start-ClusterNode cmdlet to force start the cluster on node ContosoFCNode1.

Start-ClusterNode –Node ContosoFCNode1 –FQ

Alternatively, you can type the following command locally on the node:

Net Start ClusSvc /FQ

The following example shows how to use the Start-ClusterNode cmdlet to start the Cluster service with the quorum prevented on node ContosoFCNode1.

Start-ClusterNode –Node ContosoFCNode1 –PQ

Alternatively, you can type the following command locally on the node:

Net Start ClusSvc /PQ

Supprimer un témoin de partage de fichiers

Si votre cluster est mal en point à cause d’un témoin de partage de fichier défini, qui n’est plus accessible, vous pouvez le retirer du cluster avec la commande suivante.

cluster res "File Share Witness (\\Server name\fsw_folder name)" /priv /delete

Le quorum dynamique de WSFC devrait permettre de réorganiser les votes de nœuds et redémarrer le cluster. Vous pouvez ensuite ajouter un FSW à nouveau.

Configurations

Heartbeat

SameSubnetDelay – Délai entre les heartbeats en millisecondes. 1000 par défaut = 1 seconde

SameSubnetThreshold – Nombre de heartbeats avant de considérer qu’il y a problème. 5 par défaut

Si le heartbeat est configuré à travers une connexion problématique, valeurs à ajuster.

Paramètres de failover

Options configurables pour éviter les basculements erronés.

Check timeout

Pendant le démarrage de SQL Server, WSFC utilise la DLL de ressource du moteur de base de données pour créer une nouvelle connexion sur un thread séparé, utilisé exclusivement pour surveiller l’état d’intégrité. Cela garantit que l’instance SQL dispose des ressources requises pour signaler son état d’intégrité lorsqu’elle est sous charge. En utilisant cette connexion dédiée, SQL Server exécute la procédure stockée système sp_server_diagnostics en mode de répétition pour signaler périodiquement l’état d’intégrité des composants SQL Server à la DLL de ressource.

HealthCheckTimeout = combien de temps d’attente en ms avant de décider que l’instance ne répond pas.

La valeur par défaut est de 30000 (30 secondes).

ALTER SERVER CONFIGURATION
SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 15000;

Ou en Powershell.

Import-Module FailoverClusters
$fci = "mon_serveur"
Get-ClusterResource $fci | Set-ClusterParameter HealthCheckTimeout 15000

La DLL de ressource appelle la procédure stockée sp_server_diagnostics et définit l’intervalle de répétition à un tiers du paramètre HealthCheckTimeout.
Si la procédure stockée sp_server_diagnostics est lente ou si elle ne retourne pas d’informations, la DLL de ressource attendra l’intervalle spécifié par HealthCheckTimeout avant de signaler au service WSFC que l’instance SQL est sans réponse.
Si la connexion dédiée est perdue, la DLL de ressource retentera la connexion à l’instance SQL à l’intervalle spécifié par HealthCheckTimeout avant de signaler au service WSFC que l’instance SQL ne répond pas8https://docs.microsoft.com/fr-fr/sql/sql-server/failover-clusters/windows/failover-policy-for-failover-cluster-instances . https://docs.microsoft.com/fr-fr/sql/sql-server/failover-clusters/windows/failover-policy-for-failover-cluster-instances

FailureConditionLevel

0 – Aucun basculement (pour maintenance)
1 – Sur arrêt du service : le service SQL est arrêté.
2 – 1 ou non-réponse de SQL. HEALTH_CHECK_TIMEOUT est dépassé, ou le réplica est en état d’échec.
3 – 2 ou sp_server_diagnostics retourne « erreur système ». Valeur par défaut. Les erreurs graves sont, par exemple des violations d’accès en écriture.
4 – 3 ou sp_server_diagnostics retourne « erreur de ressource », erreurs internes par exemple une condition persistante de mémoire insuffisante dans le pool de ressources interne.
5 – 4 ou sp_server_diagnostics retourne « erreur query_processing », par exemple insuffisance de worker threads.

ALTER SERVER CONFIGURATION
SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 3;

Ou, en PowerShell :

Import-Module FailoverClusters
$fci = "mon_serveur"
Get-ClusterResource $fci | Set-ClusterParameter FailureConditionLevel 3

Gestion du heartbeat

Les appels de heartbeat permettent de valider la présence des nœuds du cluster. Si un nœud n’est pas disponible à temps (délai), il sera considéré comme offline.

Quelques raisons qui peuvent expliquer ces problèmes sont listées dans cet article (qui date de 2012) : https://docs.microsoft.com/en-us/archive/blogs/askcore/having-a-problem-with-nodes-being-removed-from-active-failover-cluster-membership

La perte de l’intégrité du cluster peut se produire à cause de problèmes de réseau. Si c’est le cas, vous pouvez augmenter les délais de heartbeat, sur le même sous-réseau (SameSubnetDelay et SameSubnetThreshold) et, le cas échéant, sur des sous-réseaux différents (CrossSubnetDelay et CrossSubnetThreshold).

Exemple de modification de ces valeurs en utilisant PowerShell :

(get-cluster).SameSubnetDelay = 1000

(get-cluster).SameSubnetThreshold = 30

(get-cluster).CrossSubnetDelay = 1000

(get-cluster).CrossSubnetThreshold = 30

get-cluster | fl subnet

Le delay indique la fréquence, en millisecondes, entre chaque heartbeat.

Le threshold indique combien de heartbeats peuvent être manqués avant que la route soit déclarée comme inaccessible.

Pour plus d’information sur les thresholds, l’article suivant est très intéressant : https://techcommunity.microsoft.com/t5/failover-clustering/tuning-failover-cluster-network-thresholds/ba-p/371834

Augmenter le log du cluster

À partir de Windows Server 2012, cluster.log contient des informations qui permettent de mieux diagnostiquer le trafic du heartbeat. Si vous augmentez les valeurs de threshold, modifiez également la valeur de la propriété RouteHistoryLength pour lui donner une valeur plus grande (le double, en général). Cela permettra de conserver plus de log.

(get-cluster).RouteHistoryLength = 20

Gestion en PowerShell

WSFC est totalement gérable à l’aide de cmdlets PowerShell. En voici quelques unes :

Get-Cluster
New-Cluster
Add-ClusterGroup
Add-ClusterNode
Add-ClusterResource
Get-ClusterQuorum
Set-ClusterQuorum

…

Diagnostic

Vous pouvez interroger le cluster à l’aide de DMV (Dynamic Management Views) dans SQL Server.

sys.dm_hadr_cluster – Retourne le nom de cluster, les informations du quorum, pour un cluster (intègre) utilisé par AlwaysOn AG.

sys.dm_hadr_cluster_members

Interroger le log de WSFC

La cmdlet Get-ClusterLog crée un journal pour tous les nœuds du cluster9https://docs.microsoft.com/en-us/powershell/module/failoverclusters/get-clusterlog .

La destination par défaut est le dossier de rapports du cluster (C:\Windows\Cluster\Reports).

Vous pouvez indiquer la destination. Vous pouvez aussi demander un log d’un période de temps. Par exemple, pour déposer un log de tous les nœuds, sur les derniers 30 minutes, dans le répertoire local :

Get-ClusterLog -Destination . -TimeSpan 30

L’option -UseLocalTime écrit les timestamps en heure locale. Sinon, l’heure sera en UTC.

Informations du log du cluster

Les informations intéressantes sont concentrées dans la section [=== Cluster Logs ===].

La source de l’entrée est indiquée. Par exemple :

[API]	API du cluster : clients qui manipulent le cluster
[RES]	Ressource du cluster
[CSVREMPRV] et [CSVPRV]	Cluster Shared Volume, sur une machine virtuelle
[VSS]
[VRTA]	VSS Writer Agent

[API]

API du cluster : clients qui manipulent le cluster

[RES]

Ressource du cluster

[CSVREMPRV] et [CSVPRV]

Cluster Shared Volume, sur une machine virtuelle

[VSS]

[VRTA]

VSS Writer Agent

sp_server_diagnostics

WSFC surveille la santé de SQL Server en maintenant un appel en boucle de la procédure sp_server_diagnostics10https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-server-diagnostics-transact-sql dans une session dédiée, à forte priorité.

Vous pouvez identifier cette session dans SQL Server en cherchant le type d’attente SP_SERVER_DIAGNOSTICS_SLEEP. Par exemple, la requête suivante retrouve la session dans SQL Server :

SELECT *
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
WHERE s.is_user_process = 1
AND r.last_wait_type = 'SP_SERVER_DIAGNOSTICS_SLEEP';

La procédure sp_server_diagnostics peut être appelée manuellement.

Son appel et ses résultats sont documentés : https://docs.microsoft.com/fr-fr/sql/relational-databases/system-stored-procedures/sp-server-diagnostics-transact-sql .

Vous pouvez aussi récupérer ses résultats via une session d’évènements étendus.

CREATE EVENT SESSION [diag]
ON SERVER
ADD EVENT [sp_server_diagnostics_component_result] (set collect_data=1)
ADD TARGET [asynchronous_file_target] (set filename='c:\temp\diag.xel');
GO
ALTER EVENT SESSION [diag]
ON SERVER STATE = start;
GO

Les résultats de la procédure peuvent être utilisés pour surveiller les performances du système, notamment dans les sections Resource et Query processing, qui donnent beaucoup d’indications, cumulatives, sur la consommation de mémoire et les attentes, notamment.

Niveaux d’erreur pour le basculement

Des informations plus complètes sur les niveaux de retour de la procédure sp_server_diagnostics sont disponibles sur la page de documentation suivante : https://docs.microsoft.com/fr-fr/sql/database-engine/availability-groups/windows/configure-flexible-automatic-failover-policy.

La session SQLDIAG

L’exécution de sp_server_diagnostics est tracée par une session d’évènements cachée, qu’il est possible de retrouver dans le répertoire LOG de SQL Server. Les fichiers de log sont nommés de la façon suivante :

<HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel

C’est une trace de diagnostic utile.

Configurations spéciales

WSFC sans domaine

Windows Server 2016. Marche à suivre :

Créer un « Primary DNS suffix” sur chaque nœud »
Créer le cluster avec une AdministrativeAccessPoint DNS

new-cluster -name moncluster –Node node1,node2 -StaticAddress 192.168.1.110 -NoStorage –AdministrativeAccessPoint DNS

Pas de FSW
Pas de VCO
A la création du groupe de disponibilité : choix d’une méthode de sécurité par certificat.

(Get-Cluster).AdministrativeAccessPoint

Expertise SQL Server Besoin de services avec SQL Server ? Contactez-moi et parlons de votre projet