web-dev-qa-db-fra.com

Comment surveiller un témoin de partage de fichiers pour l'accessibilité

Dans le contexte d'un groupe de disponibilité SQL Server, quelle est la meilleure façon de surveiller un témoin de partage de fichiers pour l'accessibilité?

Je tiens à vous assurer que le témoin peut être consulté par les répliques de groupe de disponibilité, qui est quelque chose de différent que d'être disponible. Par exemple, le compte utilisé pour exécuter SQL Server a besoin de droits d'accès au partage de fichiers.

EDIT: J'ai récemment remarqué des événements enregistrés par le cluster digne d'être surveillée.

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          6/1/2019 1:23:09 PM
Event ID:      1564
Task Category: File Share Witness Resource
Level:         Critical
Keywords:     
User:          SYSTEM
Computer:      node1.contoso.com
Description:
File share witness resource 'File Share Witness' failed to arbitrate for
the file share '\\servername\sharename'. Please ensure that file share 
'\\servername\sharename' exists and is accessible by the cluster.

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          6/1/2019 1:23:08 PM
Event ID:      1562
Task Category: File Share Witness Resource
Level:         Warning
Keywords:     
User:          SYSTEM
Computer:      node1.contoso.com
Description:
File share witness resource 'File Share Witness' failed a periodic health
check on file share '\\servername\sharename'. Please ensure that file 
share '\\servername\sharename' exists and is accessible by the cluster.
1
user763861

Le témoin partage de fichiers n'a pas besoin d'être accessible par le compte de service SQL Server. Le FSW est utilisé par le cluster de clustering de basculement Windows Server pour obtenir un quorum et éviter les scénarios cérébraux scindés. Le compte Machine de cluster est le directeur public qui a besoin d'un accès à la FSW et s'il n'avait pas accès, vous ne seriez pas en mesure de le configurer en tant que témoin dans votre cluster.

D'une perspective de groupe de disponibilité, cela ne se soucie pas de l'accès au FSW. Le cluster se soucie de cela et quand il échoue (et le quorum est perdu), il signale le AG de s'arrêter pour éviter les cerveaux fendus. L'AG ne se soucie que des contrôles de santé spécifiques SQL Server (latence, connectivité aux réplicas, etc.) et les signaux reçus du groupe WSFC concernant la santé du cluster.

Si le CLUSTER CNO perd des droits sur la part de la FSW, cette ressource irait sur le cluster. Cela ne déclenchera pas nécessairement une action dans le cluster, mais doit enregistrer des alertes et des événements dans le journal des événements Windows pour lesquels vous pouvez surveiller.

1
HandyD