Dell Unity: SPs wechseln möglicherweise in den Servicemodus aufgrund einer Aufblähung des Protokolls (/nbsnas-Partition wird zu 100 % voll).
Summary: Ein Array wechselt möglicherweise in den Servicemodus (Daten nicht verfügbar) aufgrund einer Aufblähung des Protokolls (von Dell korrigierbar).
Symptoms
Bei Dual-SP-Arrays wechselt ein SP des Speichersystems in den Servicemodus und das gesamte System kann nicht über Managementschnittstellen wie CLI, UI, REST API und SMI-S betrieben werden. Dies kann auch dadurch auftreten, dass SPs abwechselnd neu gestartet werden, bis beide SPs im Servicemodus sind.
Ein Unity-Array, bei dem sich beide SPs im Servicemodus befinden, verarbeitet keine I/O, sodass es sich um eine DU-Situation (Data Unavailable) handelt.
Bei VSA kann der einzelne SP im Servicemodus neu gestartet werden oder einfach im Normalmodus verbleiben, wobei in beiden Fällen die Verwaltung verloren geht.
Das gesamte System kann nicht über Managementschnittstellen wie CLI, UI, REST API und SMI-S betrieben werden.
SSH oder IPMI sollte funktionieren. IPMI funktioniert immer, SSH funktioniert möglicherweise erst, nachdem das Array stabilisiert wurde.
Dieses Problem tritt in OE-Version 4.0.0.x auf und wurde in OE-Version 4.0.1.x behoben.
Cause
Die Protokolldatei /nbsnas/http/logs/mod_jk.log, die alle Anforderungen von UI und REST aufzeichnet, befindet sich in einem Dateisystem, das auf /nbsnas des primären SP gemountet ist. Ohne einen Protokollrotationsmechanismus belegt das Aufblähen dieser Datei weiterhin den verfügbaren Speicherplatz des Dateisystems. Andere interne Verbraucher fallen aus, wenn kein Speicherplatz mehr auf dem Dateisystem vorhanden ist. Einer der SPs wechselt in den Servicemodus, wenn er wiederholte Ausfälle dieser Komponenten erkennt.
Im Labor wurde beobachtet, dass, wenn Dienste versuchen, ein Failover auf den sekundären SP durchzuführen, dieselben Symptome auftreten. Die SPs werden einige Male abwechselnd neu gestartet und schließlich wechseln beide in den Servicemodus.
Dieses Problem tritt bei Kunden auf, wenn: Verwenden Sie immer die Benutzeroberfläche oder REST API, um das Speichersystem zu konfigurieren, oder öffnen Sie die Benutzeroberfläche im Browser und belassen Sie sie dort, ohne sie zu schließen. Wenn Sie nur auf die Benutzeroberfläche zugreifen, dauert es normalerweise einige Monate, bis Kunden dieses Problem sehen. Wenn Kunden die REST API verwenden, um Daten aus dem Speichersystem häufig abzufragen, tritt dieses Problem schneller auf.
Ein zweites Problem wurde festgestellt, bei dem ein Upgrade auf Unity OE 4.0.1.8320161 das Problem möglicherweise noch verschlimmert, da die betreffende Protokolldatei während des unterbrechungsfreien Upgrades dupliziert und somit der Prozess beschleunigt werden kann.
Sie können überprüfen, ob dies der Fall ist, indem Sie den Speicherplatzverbrauch auf /nbsbas überprüfen. Wenn der Speicherplatzverbrauch minimal oder niedrig ist, ist dieses Problem während des unterbrechungsfreien Upgrades NICHT aufgetreten. Daher ist nichts weiter erforderlich.
4.0.1.x-Codes enthalten bereits die Korrektur für das Hauptproblem, sodass die Protokollrotation selbst korrekt funktioniert.
Wenn die Partition einen sehr hohen Prozentsatz an genutzten Protokollen anzeigt, müssen die entsprechenden Protokolldateien möglicherweise gelöscht werden (erfordert Dell Support).
Ein Beispiel für die Überprüfung der Speicherplatznutzung und die zu löschenden Protokolle finden Sie im Abschnitt "Hinweise".
Dell hat beschlossen, Unity OE 4.0.1.8320161 für Unity und UnityVSA aus support.emc.com zu entfernen. Eine überarbeitete Unity OE-Version (4.0.1.8404134) wurde im September 2016 veröffentlicht.
Resolution
Um dieses Problem zu beheben, muss der technische Support Root-Zugriff auf das Array erhalten.
Wenden Sie sich an den technischen Support von Unity und erwähnen Sie diesen Wissensdatenbank-Artikel: 489057.
Additional Information
Beispiel für die Überprüfung der Speicherplatznutzung:
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
Das Protokoll oder die Protokolle, die dies verursachen, finden Sie in /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 (Core-Speicherabbilder auflisten) können auch einige Speicherabbilder mit dem Suffix "_mgmtd" anzeigen.
Diese wurden erstellt, wenn bei den SPs ein Fehler auftritt, da einige Services nicht gestartet werden können (weil /nbsnas voll ist).
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