Fondation continue sur le serveur de production
Au moins quelques fois par jour, mon serveur de production principal a récemment commencé à défailler. Seulement, le quorum ne bouge pas sur l'autre nœud.
J'ai dirigé le rapport de validation et j'ai reçu beaucoup d'informations que je ne comprends pas. C'est un HP ProLiant BL680C G5. Certaines des informations dans le rapport que je m'interroge sur:
Degraded:
HpCISSs
HP MPIO DSM for EVA4x00/6x00/8x00 family of Disk Arrays
Link-Layer Topology Discovery Mapper I/O Driver
Mount Point Manager
Ce ne sont que quelques-uns. Je ne suis pas si inquiet pour les "erreurs", mais "dégradé" semble impliquer que cela devrait être en cours d'exécution mais ne va pas si bien.
System details:
sql - 10.50.4000.0
Windows - Windows NT - 64 Bit
Cela va vraiment être affreux s'il IS une question de MPIO. Cela s'est passé plusieurs fois et l'équipe DBA a été accusée de modifier les paramètres! Je suis la tête de l'équipe, et même je n'ai aucune idée de la moitié de cela signifie (je sais ce que MPIO est, et je reconnais tous les éléments SAN, mais dépannage? Nah.)
Nouvelles informations intéressantes - juste avant que cela ne commence à se produire, nous avons mis à jour le module de service du pare-feu et avons redémarré les commutateurs de base.
Je pense qu'il y a des paramètres qui n'ont pas les valeurs par défaut correctes?
Connecté pendant le basculement:
Agent de cluster: la ressource de cluster FileServer- (serveur) (disque de cluster 1) a échoué. [Piège SNMP: 15006 dans cpqclus.mib] "" Agent de cluster: L'agent SQL Server de la ressource de cluster est devenu dégradé. [TRAP SNMP: 15005 dans cpqclus.mib] "" Agent de cluster: le serveur SQL de la ressource de cluster est devenu dégradé. [Piège SNMP: 15005 dans cpqclus.mib] "" Agent de cluster: Les services d'analyse des ressources de cluster se sont dégradés. [SNMP TRAP: 15005 dans cpqclus.mib] "" Agent de cluster: la ressource de cluster FileServer- (ServerName) (disque de cluster 4) a échoué. [Piège SNMP: 15006 dans cpqclus.mib] "
c'est vraiment étrange, car il n'y a pas beaucoup de messages d'erreur. Les seules informations réelles que j'ai proviennent du rapport de validation. Les disques 1-4 échouent toujours, mais pas connecté le même ordre, puis le quorum reste sur le nœud qu'il est activé.
Après avoir parlé avec le réseau réseau, il pense que peut-être que lorsque le commutateur principal a été redémarré, il affectait les itinéraires préférés pour les NIC. Il va nettoyer les choses un peu ce week-end (en retirant les actions de fichiers et les recréer) et nous verrons où nous sommes. L'ajout/enlever n'a pas fonctionné. Il a échoué hier soir.
Nous utilisons des canaux de fibres pour se connecter entre les serveurs et la matrice de stockage. Nous venons de corriger Windows (en utilisant Shavlik) et nous avons maintenant le même problème. Je commence à me demander s'il s'agit d'un paramètre par défaut dans la messagerie MPIO qui continue de retourner.
Je ne connais pas cette erreur particulière, mais j'ai rencontré des situations lorsqu'un groupe à deux nœuds avait plusieurs basculement dus à des problèmes de MPIO avec le SAN LUNS. Plus souvent, il a été résolu. en mettant à jour les pilotes HBA.
Une autre chose à rechercher est de s'assurer que les dépendances du disque sont correctement définies. Le service SQL Server doit dépendre de tous les disques qui hébergeent les fichiers DB et les sauvegardes ainsi que le disque avec la lettre de lecteur agissant en tant qu'hôte de montage. J'ai rencontré quelques hôtes où une dépendance de disque manquante a provoqué un disque à démarrer avant que SQL puisse fermer les fichiers DB.