Dell Unity : Les processeurs de stockage peuvent passer en mode maintenance en raison du gonflement des logs (la partition /nbsnas devient pleine à 100 %)
Summary: Une baie peut passer en mode maintenance (données indisponibles) en raison d’un gonflement des logs (corrigible par Dell)
Symptoms
Pour les baies à SP double, un SP du système de stockage passe en mode maintenance et l’ensemble du système ne peut pas être utilisé via les interfaces de gestion, y compris l’interface de ligne de commande, l’interface utilisateur, l’API REST et SMI-S. Cela peut également se manifester par des redémarrages alternatifs des processeurs de stockage jusqu’à ce qu’ils se retrouvent tous les deux en mode maintenance.
Une baie Unity avec les deux SP en mode maintenance ne traitera pas les E/S, il s’agit donc d’une situation d’indisponibilité des données (DU).
Pour VSA, le processeur de stockage unique peut redémarrer en mode maintenance ou simplement rester en mode normal, perdant la gestion dans les deux cas.
L’ensemble du système ne peut pas être utilisé via des interfaces de gestion, y compris l’interface de ligne de commande, l’interface utilisateur, l’API REST et SMI-S.
SSH ou IPMI devrait fonctionner. IPMI fonctionne toujours, SSH ne fonctionne qu’une fois la baie stabilisée.
Ce problème se trouve sur OE version 4.0.0.x et est résolu dans OE version 4.0.1.x.
Cause
Le fichier journal /nbsnas/http/logs/mod_jk.log, qui enregistre chaque demande de l’interface utilisateur et de REST, réside dans un système de fichiers monté sur /nbsnas du processeur de stockage principal. Sans mécanisme de rotation des logs, le gonflement de ce fichier continue de consommer l’espace disponible du système de fichiers. Les autres clients internes commencent à tomber en panne une fois qu’il n’y a plus d’espace sur le système de fichiers. L’un des processeurs de stockage passe en mode maintenance lorsque détecte des défaillances répétées de ces composants.
Il a été observé en laboratoire que lorsque cela se produit et que les services tentent de basculer vers le processeur de stockage secondaire, celui-ci éprouve également les mêmes symptômes. Les processeurs de stockage redémarrent plusieurs fois de manière alternative, et finissent tous les deux par passer en mode maintenance.
Les clients rencontrent ce problème si : toujours utiliser l’interface utilisateur ou l’API REST pour configurer le système de stockage, ou ouvrir l’interface utilisateur dans le navigateur et la laisser là sans fermer. Avec un accès à l’interface utilisateur uniquement, normalement, il faut quelques mois pour que les clients voient ce problème. Si les clients utilisent fréquemment l’API REST pour interroger fréquemment les données du système de stockage, ce problème se produit plus rapidement.
Un deuxième problème a été détecté, dans lequel la mise à niveau vers Unity OE 4.0.1.8320161 peut exacerber le problème, car elle peut dupliquer le fichier journal en question lors de la mise à niveau sans perturbation, accélérant ainsi le processus.
Vous pouvez le confirmer en vérifiant la consommation d’espace sur /nbsbas. Si la consommation d’espace est minime ou faible, vous n’avez PAS rencontré ce problème lors de la mise à niveau sans perturbation et rien d’autre n’est donc nécessaire.
Les codes 4.0.1.x contiennent déjà le correctif pour le problème principal, de sorte que la rotation des journaux elle-même fonctionne correctement.
Si la partition affiche un pourcentage d’utilisation très élevé, les fichiers log responsables devront peut-être être supprimés (nécessite le support de Dell).
Vous trouverez un exemple de vérification de l’utilisation de l’espace et des journaux à supprimer dans la section Remarques.
Dell a décidé de supprimer Unity OE 4.0.1.8320161 pour Unity et UnityVSA de support.emc.com. Une version révisée d’Unity OE (4.0.1.8404134) a été publiée en septembre 2016.
Resolution
Pour résoudre ce problème, il est nécessaire que le support technique obtienne un accès root à la baie.
Contactez le support technique Unity et mentionnez cet article de la base de connaissances : 489057
Additional Information
Exemple de vérification de l’utilisation de l’espace :
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
Le ou les journaux à l’origine de ce problème se trouvent dans /nbsnas/http/logs :
spx:~> cd /nbsnas/http/logs spx:/nbsnas/http/logs> ll -h total 975M -rw-r--r-- 1 root root 12K Sep 8 13:32 access_log -rw-r--r-- 1 root root 165K Sep 8 08:45 access_log.1.gz -rw-r--r-- 1 root root 239K Sep 8 06:59 access_log.2.gz -rw-r--r-- 1 root root 1.6M Sep 8 13:32 error_log -rw-r--r-- 1 root root 167K Sep 3 04:56 error_log.1.gz -rw-r--r-- 1 root root 495M Sep 8 13:32 mod_jk.log <<<<<<<<<< -rw-r--r-- 1 root root 475M Sep 8 08:45 mod_jk.log.1 <<<<<<<<<<
svc_dc lcd (list core dumps) peut également afficher quelques vidages avec le suffixe « _mgmtd ».
Ceux-ci ont été créés lorsque les processeurs de stockage paniquent car certains services ne peuvent pas démarrer (car /nbsnas est plein).
spx:/> svc_dc -lcd ======================== [DC copier]: Available on backend: CP_dump_spb_CKM00161701xxx_2016-09-08_13_29_47_17275_ECOM core-dump_dump_spb_CKM00161701xxx_2016-09-08_08_46_23_778_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_19_11994_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_53_21524_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_05_11446_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_45_24620_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_28_30_3067_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_29_08_15086_mgmtd