Le basculement automatique du groupe de disponibilité AlwaysOn ne fonctionne pas

Jouer avec la configuration AG J'ai le WSFC et configuré avec deux nœuds dans un groupe de disponibilité appelé DevClusterOnline. Les deux nœuds (DEV-AWEB5 principal, DEV-AWEB6 secondaire) exécutent Windows Server 2008 R2.

Si je vérifie la santé de mon AG, j'obtiens ceci:

L'exécution de la requête ci-dessous renverra cet ensemble de résultats:

select
    ar.replica_server_name,
    availability_group_name = ag.name,
    ar.availability_mode_desc,
    ar.failover_mode_desc
from sys.availability_replicas ar
inner join sys.availability_groups ag
on ar.group_id = ag.group_id
order by availability_group_name, replica_server_name;

Si je déconnecte DEV-AWEB5, je ne peux pas me connecter à l'écouteur de groupe (DevListener), mais je peux le cingler et il répondra à mon ping. La réplique - DEV-AWEB6 entre dans un état RESOLVING et ma base de données est inaccessible. Je peux cependant aller manuellement dans Management Studio et définir le basculement sur DEV-AWEB6, puis je suis à nouveau opérationnel et DevListener acceptera à nouveau les connexions.

Étant donné que ces faits confirment que le basculement fonctionne réellement, que j'ai synchronisé les validations et que le basculement automatique est configuré, je ne sais pas si je ne fonctionne pas correctement dans ma configuration.

Lorsque je déconnecte DEV-AWEB5, je m'attends à ce que ma réplique conserve la connexion et donc, DevListener aussi. Je m'attends à ce que le basculement automatique me permette de me connecter à l'AG Listener de manière transparente. Du point de vue de l'utilisateur final, en utilisant un système Web, il ne devrait pas être perceptible que l'un des serveurs de base de données tombe en panne.

Je suis coincé ici, est-ce que quelqu'un peut m'éclairer sur ce que je fais mal?

Si je déconnecte DEV-AWEB5

Définissez «déconnecter», si vous voulez. Je suppose que vous avez gardé la boîte en place mais que vous avez supprimé SQL Server.

Je ne peux pas me connecter à l'écouteur de groupe (DevListener), mais je peux le cingler et il répondra à mon ping

En effet, l'écouteur n'est qu'un nom de réseau virtuel (VNN) dans le groupe de ressources de cluster WSFC pour le groupe de disponibilité représenté. Votre nœud DEV_AWEB5 possède toujours le groupe de ressources de cluster, mais c'est juste la ressource de cluster AG qui est probablement en état d'échec. Le VNN doit toujours être en ligne (comportement attendu). Il pointe simplement vers le nœud qui possède ce groupe de ressources (dans ce cas, DEV-AWEB5). En fait, si vous avez activé la communication à distance PowerShell et que vous avez exécuté ce qui suit:

Invoke-Command -ComputerName "YourListenerName" -ScriptBlock { $env:computername }

De même, si vous pouvez RDP dans DEV-AWEB5 (à condition que vous ayez la capacité et l'accessibilité, etc.), vous seriez en mesure de RDP en utilisant le nom de l'écouteur ( mstsc /v:YourListenerName). C'est juste un VNN.

Le retour serait le nom de l'ordinateur de votre nœud propriétaire.

D'après tous vos symptômes, je serais prêt à parier que vous avez atteint votre seuil de basculement. Le seuil de basculement détermine le nombre de fois que le cluster tentera de basculer votre groupe de ressources au cours d'une période spécifiée. La valeur par défaut de ces valeurs est le nombre maximal de basculements n - 1 (où n est le nombre de nœuds) sur une période de 6 heures . Vous pouvez le voir à travers la commande WSFC PowerShell suivante:

Get-ClusterGroup -Name "YourAgName" |
    Select-Object Name, FailoverThreshold, FailoverPeriod

Cela vous donne simplement les paramètres (que vous pouvez modifier si vous le souhaitez, bien sûr).

La meilleure façon de prouver que c'est le cas pour vous, vous devez générer le journal du cluster (les journaux des événements système n'entrent en détail que dans la mesure où "a échoué", ou quelque chose comme ça).

Get-ClusterLog -Node "YourClusterNode" -TimeSpan <amount_of_minutes_since_failure>

Cela sera par défaut placé dans le dossier "C: \ Windows \ Cluster \ Reports", et le fichier est appelé "Cluster.log".

Si vous deviez ouvrir ce journal de cluster, vous devriez pouvoir y trouver la chaîne suivante, indiquant exactement ce qui s'est passé et pourquoi cela s'est produit:

Ne pas basculer sur le groupe [YourClusterGroupName] , failoverCount [# de basculements] , seuil de basculement [valeur de seuil de basculement] , nodeAvailCount [nombre de nœuds disponibles ].

Le message ci-dessus est simplement WSFC vous disant qu'il ne basculera pas votre groupe parce que c'est trop arrivé (vous atteignez le seuil).

Pourquoi cela arrive-t-il? Simplement pour éviter l'effet Ping-Pong des ressources de cluster qui vont et viennent trop fréquemment entre les nœuds.

Alors que cela serait courant d'atteindre ces seuils lors des tests de basculement, en production, cela indiquerait généralement un problème qui devrait être étudié.

L'ajout de MSSQL en tant que ressource de service générique n'est pas la réponse.

Cela mettra simplement le gestionnaire de cluster en charge du service SQL Server, OK, oui, il basculera automatiquement, mais vous remarquerez dans SQL Server Configuration Manager que vos services sont désormais définis sur "Manuel" indiquant que le gestionnaire de cluster est maintenant en contrôle de votre service SQL Server.

Vous mettez Cluster Manager en charge d'une application NON Clustered.

Cela se terminera en larmes.

L'approche correcte pour configurer correctement les groupes de disponibilité SQL Server selon la documentation MS.

Et assurez-vous également que vous ne dépassez pas les paramètres de basculement définis dans le gestionnaire de cluster> Rôles> onglet Basculement.

Si vous dépassez ces limites, le cluster ne fera pas basculer vos ressources et une erreur sera publiée dans le journal des événements d'application.