Dell Unity: Gli SP possono entrare in modalità di servizio a causa di un rigonfiamento del registro (la partizione /nbsnas è piena al 100%)
Summary: Un array può entrare in modalità di servizio (dati non disponibili) a causa di un rigonfiamento dei registri (correggibile da Dell)
Symptoms
Per gli array a due SP, un SP del sistema di storage entra in modalità di assistenza e l'intero sistema non può essere utilizzato tramite interfacce di gestione, tra cui CLI, UI, API REST e SMI-S. Ciò può anche manifestarsi come riavvio alternato degli SP fino a quando entrambi gli SP non passano alla modalità di servizio.
Un array Unity con entrambi gli SP in modalità di servizio non servirà I/O, quindi si tratta di una situazione di non disponibilità dei dati (DU).
Per VSA, il singolo SP può riavviarsi in modalità di servizio o semplicemente rimanere in modalità normale, perdendo la gestione in entrambi i casi.
L'intero sistema non può essere gestito tramite interfacce di gestione, tra cui CLI, UI, API REST e SMI-S.
SSH o IPMI dovrebbero funzionare. IPMI funziona sempre, SSH potrebbe funzionare solo dopo la stabilizzazione dell'array.
Questo problema si verifica nella versione OE 4.0.0.x ed è stato risolto nella versione OE 4.0.1.x.
Cause
Il file log /nbsnas/http/logs/mod_jk.log, che registra ogni richiesta dall'interfaccia utente e da REST, risiede in un file system montato su /nbsnas dell'SP primario. Senza un meccanismo di rotazione del registro, il rigonfiamento di questo file continua a utilizzare lo spazio disponibile del file system. Altri consumer interni iniziano a non funzionare quando non viene lasciato spazio nel file system. Uno degli SP entra in modalità di servizio quando rileva errori ripetuti di tali componenti.
In laboratorio è stato osservato che quando ciò si verifica e i servizi tentano di eseguire il failover sull'SP secondario, anche questo riscontra gli stessi sintomi. Gli SP si riavviano alcune volte alternativamente e alla fine entrambi entrano in modalità di assistenza.
I clienti riscontrano questo problema se: utilizzare sempre l'interfaccia utente o l'API REST per configurare il sistema di storage oppure aprire l'interfaccia utente nel browser e lasciarla senza chiuderlo. Con il solo accesso all'interfaccia utente, normalmente sono necessari alcuni mesi prima che i clienti rilevino questo problema. Se i clienti utilizzano l'API REST per eseguire frequentemente query sui dati dal sistema di storage, questo problema si verifica più rapidamente.
È stato rilevato un secondo problema in cui l'aggiornamento a Unity OE 4.0.1.8320161 potrebbe aggravare il problema in quanto potrebbe duplicare il file di registro in questione durante l'NDU, accelerando così il processo.
In tal caso, è possibile controllare il consumo di spazio su /nbsbas. Se il consumo di spazio è minimo o basso, NON si è verificato questo problema durante l'NDU e pertanto non è necessario nient'altro.
I codici 4.0.1.x contengono già la correzione del problema principale, quindi la rotazione del registro funziona correttamente.
Se la partizione mostra una percentuale di utilizzo molto elevata, potrebbe essere necessario eliminare i file di registro responsabili (richiede il supporto Dell).
Un esempio di come controllare l'utilizzo dello spazio e i registri da eliminare è disponibile nella sezione delle note.
Dell ha deciso di rimuovere Unity OE 4.0.1.8320161 per Unity e UnityVSA dalla support.emc.com. È stata pubblicata una versione rivista di Unity OE (4.0.1.8404134) nel mese di settembre 2016.
Resolution
Per risolvere questo problema, è necessario che il supporto tecnico ottenga l'accesso root all'array.
Contattare il supporto tecnico Unity e citare questo articolo della Knowledge Base: 489057
Additional Information
Esempio di come controllare l'utilizzo dello spazio:
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
Il log o i log che causano questo problema sono disponibili 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 (list core dumps) può anche mostrare alcuni dump con il suffisso "_mgmtd".
Questi sono stati creati quando gli SP hanno un errore irreversibile poiché alcuni servizi non sono in grado di avviarsi (a causa del riempimento di /nbsnas).
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