Always On : Maîtriser les Timeouts

Quand vous gérez des Groupes de Disponibilité AlwaysOn, il n’est pas rare que vous ayez des basculements intempestifs alors que votre système fonctionne correctement.

Cela peut arriver pendant la nuit et plus rarement dans la journée. La cause la plus fréquente est une indisponibilité temporaire du système, qui provoque un timeout des tests de santé du cluster. Cela peut arriver par exemple lorsqu’il y a une frise de VM quand un logiciel de backup prend un snapshot.

Comme ça vous est certainement déjà arrivé, ou ça va probablement vous arriver, Voici les valeurs de timeout sur lesquelles vous pouvez agir pour éviter les basculements intempestifs.

Pour qu’un Groupe de Disponibilité fonctionne, plusieurs composants doivent s’assurer mutuellement qu’ils sont « en vie ». Si l’un d’eux met trop de temps à répondre, le mécanisme de basculement se déclenche.

La communication entre SQL Server et le cluster.

Le Lease Timeout (Le bail)

C’est le mécanisme de communication directe entre le moteur SQL Server et le service de cluster (RHS.exe). C’est SQL qui communique en direction du service de cluster. Cette communication n’apparaît que sur le nœud principal du groupe de disponibilité.

• Valeur par défaut : 20000 ms (20 secondes).
• Comment ça marche : Si le moteur SQL est trop occupé (pression CPU massive par exemple) ou si le thread s’arrête plus de 20 secondes, le bail est rompu et le cluster force l’arrêt de l’instance pour basculer.

Le HealthCheck Timeout

Il repose sur la procédure stockée système sp_server_diagnostics. C’est le service de cluster qui interroge SQL Server pour vérifier son état de santé. Cette vérification a lieu sur tous les nœuds du cluster, principal et secondaires.

• Valeur par défaut : 30000 ms (30 secondes).
• Comment ça marche : SQL Server envoie des informations sur l’état du système (mémoire, requêtes bloquées, erreurs système). Si SQL Server ne répond pas à cette requête dans les 30 secondes, le cluster considère que l’instance est « malade ».

Le Failure Condition Level

C’est le degré de tolérance aux erreurs.

• Valeur par défaut : 3.
• Niveau 3 : SQL Server basculera en cas d’erreur critique du système ou de « Spinlock » interne.

Le risque des réseaux instables : Le Heartbeat WSFC

Outre les réglages internes de SQL, WSFC (Windows Server Failover Cluster) possède ses propres réglages de réseau.

Si vos nœuds sont répartis sur deux sites géographiques (Multi-Subnet), la latence réseau peut provoquer une perte de Quorum. Le cluster croit que l’autre nœud est mort simplement parce que le « ping » interne (Heartbeat) a mis trop de temps.

Les réglages recommandés pour le Multi-Site :

Si vous subissez des pertes de Quorum, vérifiez ces paramètres via PowerShell :

• SameSubnetThreshold : Nombre de pings manqués autorisés sur le même réseau (Défaut : 5).
• CrossSubnetThreshold : Nombre de pings manqués autorisés entre deux sites (Défaut : 20).

En augmentant légèrement ces valeurs, vous permettez au cluster de supporter une micro-coupure réseau sans couper la production.

Pourquoi ne pas simplement mettre des valeurs maximales ?

Si vous mettez un LeaseTimeout à cinq minutes, votre serveur ne basculera jamais « pour rien ». Mais le jour où un vrai crash survient, vos utilisateurs resteront bloqués cinq minutes devant un écran figé avant que la haute disponibilité ne se réveille.

La règle d’or : > On n’augmente les timeouts que pour couvrir des pics de charge identifiés ou des latences réseau connues, jamais pour masquer un problème de performance sous-jacent.

Comment modifier ces paramètres ?

Ses réglages se trouvent dans les Propriétés de la ressource de rôle SQL Server dans le gestionnaire de cluster.

Vous pouvez également les modifier en T-SQL pour plus de précision :

ALTER AVAILABILITY GROUP [MonAG] 
SET (HEALTH_CHECK_TIMEOUT = 60000); -- Passage à 60 secondes

Ou via PowerShell pour le cluster :

(Get-Cluster).SameSubnetThreshold = 10

Trouvez votre équilibre

Une configuration AlwaysOn robuste est un équilibre entre réactivité (basculer vite en cas de crash) et tolérance (ne pas basculer pour une micro-latence). Les valeurs par défaut (20s / 30s) sont excellentes pour 95 % des cas. Si vous devez les modifier, faites-le par palier de cinq ou dix secondes et surveillez vos logs.

Vos basculements AlwaysOn vous semblent inexpliqués ? Contactez-moi pour un diagnostic afin de stabiliser votre architecture.

Références

• Mechanics and guidelines of lease, cluster, and health check timeouts for Always On availability groups