SQL Server Always On File Share Witness (vote de quorum) sur un sous-réseau différent vers d'autres nœuds
Je rencontre actuellement des problèmes avec certains de mes groupes de disponibilité où le nœud 1 et le nœud 2 perdent la connectivité entre eux ("Un dépassement de délai de connexion s'est produit sur une connexion précédemment établie à la réplique de disponibilité".
Les erreurs dans le gestionnaire de cluster de basculement indiquent "La ressource témoin de partage de fichiers 'File Share Witness' n'a pas arbitré pour le partage de fichiers" Le serveur sur lequel le partage de fichiers se trouve n'a pas redémarré ou a rencontré des problèmes et tout les autorisations fonctionnent.
La seule chose que je peux voir, c'est que le serveur de partage de fichiers se trouve sur un sous-réseau différent des 2 autres nœuds SQL Server du cluster.
Quelqu'un pourrait-il confirmer que le serveur de partage de fichiers sur un autre sous-réseau est un grand non non dans un environnement AlwaysOn? Toutes les règles de pare-feu sont en place car il peut parler aux autres nœuds mais en dehors des heures (généralement), il perd la connectivité.
L'autre chose étrange est qu'il y a 3 votes dans le quorum, y compris le partage de fichiers, donc même si le partage de fichiers perd la connectivité au cluster de basculement, node1 et node2 ne devraient pas perdre de connectivité entre eux car il y a suffisamment de votes pour le quorum (2)
Quelqu'un pourrait-il confirmer que le serveur de partage de fichiers sur un autre sous-réseau est un grand non non dans un environnement AlwaysOn?
C'est très bien d'avoir le FSW sur un sous-réseau différent, il n'y a absolument rien de mal à cela. Il n'est pas nécessaire de l'avoir sur le même sous-réseau, en fait il y a un témoin Azure qui ne sera certainement pas sur le même sous-réseau et cela fonctionne sans problème.
"Un dépassement de délai de connexion s'est produit sur une connexion précédemment établie à la réplique de disponibilité"
Semble pointer vers quelque chose dans le réseau qui pose problème o si c'est sur une machine virtuelle, quelque chose arrive à l'invité/hôte qui vous cause ce problème. Étant donné qu'il existe une pléthore de paramètres de configuration détaillés au niveau de l'hôte, de l'invité et du système d'exploitation qui peuvent y contribuer, je n'entrerai pas dans les détails car cela serait hors de portée de ce site.
Les erreurs dans le gestionnaire de cluster de basculement indiquent "La ressource témoin de partage de fichiers" File Share Witness "n'a pas arbitré pour le partage de fichiers" Le serveur sur lequel le partage de fichiers se trouve n'a pas redémarré ou a rencontré des problèmes et toutes les autorisations fonctionnent.
Cela signifie que quiconque a tenté d’arbitrer pour le témoin n’a obtenu qu’un vote sur le quorum du groupe. Puisqu'il s'agit d'un cluster à deux nœuds, si les nœuds ne pouvaient pas se parler, ils seraient dans cette situation exacte.
Si aucun nœud ne peut se parler (évidemment un problème) et qu'aucun nœud ne peut parler au FSW (un autre problème), je me demande ce qui est cassé dans l'infrastructure - encore une fois, soit au niveau de la couche virtuelle soit au niveau de la couche physique (réseau). Il est clair que quelque chose se produit et est spécifique à votre environnement, pas à SQL Server.
L'autre chose étrange est qu'il y a 3 votes dans le quorum, y compris le partage de fichiers, donc même si le partage de fichiers perd la connectivité au cluster de basculement, node1 et node2 ne devraient pas perdre de connectivité entre eux car il y a suffisamment de votes pour le quorum (2)
Oui, mais je parie que les nœuds ont perdu la connectivité entre eux. Il y a probablement quelques entrées sur les battements de cœur manqués, la connectivité à ~ 3343, les regroupements, etc., dans le journal du cluster.
La connectivité ne signifie pas des votes, la connectivité signifie des contrôles de santé. Une fois que les contrôles d'intégrité échouent, les nœuds deviennent partitionnés et c'est à ce moment que ces événements se produisent. Vous devrez découvrir ce qui s'est produit dans votre environnement au moment où cela s'est produit. Si cela se produit assez souvent et dans les délais, il s'agit d'une tâche ou d'un logiciel dans l'environnement.S'il se produit de manière aléatoire, il s'agit très probablement de problèmes d'infrastructure tels que la mise en réseau ou les paramètres d'hôte/invité/système d'exploitation s'il se produit lorsqu'il est sous charge.
Je n'ai vu qu'un comportement similaire lors de l'exécution d'AAG sur des machines virtuelles dans VMWare. Si la réplique secondaire est étourdie tout en maintenant un verrou de fichier sur le témoin, les choses deviennent étranges (voir un article légèrement obsolète sur VM Stun: https://cormachogan.com/2015/04/28/quand-et-pourquoi-nous-étourdir-une-machine-virtuelle / ). Lorsque vous par exemple étendez le disque, le VM peut être étourdi (pause) de quelques secondes à 20-30 secondes pour un grand disque.