VxRail : Échec du bilan de santé du nœud en raison du scratch de test

Le contrôle d’intégrité « scratch » permet de s’assurer que les connexions dans « vmkernel.log » sont accessibles dans la partition scratch :

/var/log/vmkernel.log

Les résultats de ce bilan de santé peuvent être parmi les suivants :

Chaque test réussi n’est pas répertorié dans le rapport récapitulatif, pour en faciliter la lecture.
Un exemple de résultat du bilan d’intégrité figure ci-dessous :

#========================#======#=========#====================================================================#==============#
|  Hostname / Category   |Status  Dell_KB |  Warnings or Failures, unless tests Passed                         ; Product S.N. |
#========================#======#=========#====================================================================#==============#
| node02                 | Critical 43145 | scratch: /scratch/log/vmkernel.log has not been written in the last 486096 seconds|

Le test « scratch » vérifie que le fichier « /scratch/log/vmkernel.log » est accessible.
Les horodatages des lignes les plus récentes sont vérifiés et une erreur est signalée si les lignes les plus récentes datent de plus de 2 heures.
Si, pour une raison quelconque, le vmkernel.log est introuvable dans la partition temporaire, le test signale une défaillance critique.

Vérifiez le fichier log VMkernel :

Un échec de ce test indique que la partition Scratch n’était pas lisible par le test et que cette partition doit être vérifiée.
Accédez à la ligne de commande d’un nœud et vérifiez la partition temporaire :

/scratch

Si la partition est accessible, vérifiez le contenu du log suivant, qui doit contenir les lignes d’événements récentes :

/scratch/log/vmkernel.log

L’emplacement du journal de travail a peut-être été modifié et l’emplacement de journalisation peut être vérifié à l’aide de la commande :

esxcli system syslog config get

Par exemple :

Local Log Output: /scratch/log

Si ce qui précède n’est pas /scratch/log, vérifiez le vmkernel.log dans l’autre chemin.

Vérifiez le lien VMkernel :

Il doit y avoir un lien vers le journal de travail (par exemple, /scratch/log/vmkernel.log), dans /var/log :

# ls -la /var/log/vmkernel.log
lrwxrwxrwx    1 root     root            25 Sep  8 12:01 /var/log/vmkernel.log -> /scratch/log/vmkernel.log

Si ce n’est pas le cas, créez le lien du fichier pour qu’il corresponde à l’entrée ci-dessus.

Pour corriger un manque de journalisation sur vmkernel.log :

Si l’vmkernel.log n’est pas en cours d’écriture (toutes les entrées durent plus de 2 heures), l’hôte doit être redémarré.

Pour redémarrer :

1. Mettre le nœud en mode maintenance
2. Redémarrer le nœud
3. Sortie du nœud du mode maintenance
4. Exécuter VxVerify à nouveau

Si le problème persiste, contactez le support Dell.

Il est également possible que le cluster dispose d’une valeur de répertoire global personnalisée définie dans les paramètres système avancés pour Syslog.global.logDir (ce qui n’est pas conforme aux normes VxRail).
Il peut s’agir d’un partage réseau ou d’une mauvaise configuration du serveur syslog.

Par exemple, un client peut personnaliser Syslog.global.logDir dans tous les nœuds pour enregistrer les journaux dans un système de fichiers réseau (NFS), comme dans l’exemple ci-dessous.

Vérifiez la variable Syslog.global.logDir, sous Paramètres système avancés du nœud, et vérifiez que la valeur est []/scratch/log.
Si la valeur est différente de la valeur par défaut []/scratch/log, le bilan de santé peut signaler que VMkernel.log est introuvable.
Vous trouverez plus d’informations sur les variables ci-dessus dans l’article VMware ci-dessous.
https://knowledge.broadcom.com/external/article?legacyId=2003322