SQL Server Cluster non disponible après l'échec du serveur "principal"
J'ai déchiré cette question sur Stackoverflow, mais a été invité à republier ici donc ici c'est :
J'ai une base de données que je crée dans un environnement en cluster. Ce sera deux serveurs avec un stockage partagé. Servera est le serveur où je configure la base de données et Serverb est un nœud dans le cluster SQLServer.
Si je désactive de force le serveurb, tout continue à fonctionner comme prévu, mais si je désactive Servera, l'instance n'est plus disponible.
Windows Cluster est toujours en vie (je peux vous dire à Remote Desktop sur le cluster via un nom partagé), mais le SQL n'est pas visible et que Cluster Manager signale la ressource comme hors ligne.
Cela défait un peu le but du cluster et j'ai besoin de le résoudre, mais ce n'est pas vraiment dans mon domaine d'expertise et je ne sais pas où commencer.
Merci d'avance.
Modifier (Informations supplémentaires posées dans Commentaires): Windows a été installé J'ai ajouté une fonctionnalité de clustering pour DTC et SQL Server. En ce qui concerne l'accès, les adresses IP des machines sont * .101 pour la principale; * .102 pour le deuxième serveur; * .99 Pour les instances d'accès SQL Server et * .111 pour Gestionnaire de cluster. Je peux accéder à 99 des deux machines mais je ne peux pas accéder à la base de données à 101 ou 102.
Edit n ° 2 - J'ai essayé d'augmenter le seuil de basculement (à 50 en 24 heures, à des fins de test), mais le serveur ne se réveille toujours pas après avoir coupé le réseau pour serveur1. Le cluster revient environ 20 secondes, mais SQL Server reste en panne. Dans les journaux, j'ai des erreurs de serveur et un message de niveau critique qui provoque probablement l'échec. Le message est:
Le service de cluster s'arrête parce que le quorum a été perdu. Cela pourrait être dû à la perte de connectivité réseau entre certains nœuds ou tous les nœuds du groupe, ou un basculement du disque témoin. Exécutez la validation d'un magicien de configuration pour vérifier votre configuration réseau. Si la condition persiste, vérifiez les erreurs matérielles ou logicielles liées à l'adaptateur réseau. Vérifiez également les échecs dans tous les autres composants du réseau auxquels le nœud est connecté, tel que des hubs, des commutateurs ou des ponts.
Sans regarder les grumes de cluster ni aucune autre forme de rapports d'erreur, tout ce que je peux faire est de deviner ici.
Mais mes pensées initiales sont que vous avez peut-être frappé le seuil de basculement. Par défaut, cela va être défini sur un maximum de N-1 (où n est le nombre de nœuds) sur une période de 6 heures. Oui, c'est une longue période, et surtout dans un cluster à 2 noeuds, ce n'est pas de très nombreux échecs (équivaut à une seule échec). Ce seuil est défini pour empêcher l'effet de ping-pong des groupes de grappes.
En production, c'est probablement une bonne chose. Mais dans le test/le développement/non-prod, il est assez courant de rencontrer ce problème initialement perplexe, car vous essayez peut-être de basculer consécutivement. Il convient de noter que ces paramètres sont configurables à 100%. Tout ce que vous avez à faire est d'entrer dans les propriétés du groupe de cluster et dans l'onglet "basculement", vous aurez la possibilité de modifier ces deux paramètres (échecs maximaux dans la période spécifiée et Période (heures). Voici ce que cela ressemble dans le gestionnaire de cluster de basculement:
Remarque: Dans ma capture d'écran, le seuil est défini sur 2 car j'ai un cluster à 3 nœuds .
De même, on peut voir que cela peut être vu avec PowerShell (accéder au module FildoversClusters).
# you may need to set your cluster group name to whatever it is named
# in your environment
#
Get-ClusterGroup -Name "SQL Server (MSSQLSERVER)" |
Select-Object Name, FailoverThreshold, FailoverPeriod