Dell Unity: Los SP pueden entrar en modo de servicio debido a la sobrecarga de registros (la partición /nbsnas se llena un 100 %)
Summary: Un arreglo puede entrar en modo de servicio (datos no disponibles) debido a la hinchazón del registro (corregible por Dell)
Symptoms
Para los arreglos de SP dobles, un SP del sistema de almacenamiento entra en modo de servicio y todo el sistema no se puede operar a través de las interfaces de administración, incluidas la CLI, UI, API REST y SMI-S. Esto también puede manifestarse como SP que se reinician alternativamente hasta que ambos SP terminan en modo de servicio.
Un arreglo Unity con ambos SP en modo de servicio no atenderá I/O, por lo que esta sería una situación de datos no disponibles (DU).
Para VSA, es posible que el SP único se reinicie en modo de servicio o simplemente permanezca en modo normal, lo que pierde la administración en cualquier caso.
No se puede operar todo el sistema a través de interfaces de administración, incluidas la CLI, UI, API REST y SMI-S.
SSH o IPMI deberían funcionar. IPMI funciona siempre; es posible que SSH solo funcione después de estabilizar el arreglo.
Este problema se encuentra en la versión 4.0.0.x del OE y se corrige en la versión 4.0.1.x del OE.
Cause
El archivo de registro /nbsnas/http/logs/mod_jk.log, que registra todas las solicitudes de UI y REST, reside en un sistema de archivos montado en /nbsnas del SP principal. Sin un mecanismo de rotación de registros, la hinchazón de este archivo continúa consumiendo el espacio disponible del sistema de archivos. Otros consumidores internos comienzan a fallar después de que no queda espacio en el sistema de archivos. Uno de los SP entra en modo de servicio cuando detecta fallas repetidas de esos componentes.
Se observó en el laboratorio que cuando esto sucede y los servicios intentan conmutar por error al SP secundario, también experimenta los mismos síntomas. Los SP se reinician varias veces de manera alterna y, finalmente, ambos entran en modo de servicio.
Los clientes ven este problema si: siempre utilizan la interfaz de usuario o la API REST para configurar el sistema de almacenamiento, o abren la interfaz de usuario en el navegador y la dejan allí sin cerrarse. Con solo acceso a la interfaz de usuario, normalmente los clientes tardan unos meses en ver este problema. Si los clientes utilizan la API REST para consultar datos del sistema de almacenamiento con frecuencia, este problema ocurre más rápidamente.
Se encontró un segundo problema en el que la actualización a Unity OE 4.0.1.8320161 puede agravar el problema, ya que puede duplicar el archivo de registro en cuestión durante la NDU, lo que acelera el proceso.
Puede confirmar si es así comprobando el consumo de espacio en /nbsbas. Si el consumo de espacio es mínimo o bajo, NO experimentó este problema durante la NDU y, por lo tanto, no se requiere nada más.
Los códigos 4.0.1.x ya contienen la solución para el problema principal, por lo que la rotación de registros en sí funciona correctamente.
Si la partición muestra un porcentaje de uso muy alto, es posible que se deban eliminar los archivos de registro responsables (requiere soporte de Dell).
En la sección Notas, se puede encontrar un ejemplo de cómo comprobar el uso del espacio y qué registros eliminar.
Dell decidió eliminar Unity OE 4.0.1.8320161 para Unity y UnityVSA de support.emc.com. En septiembre del 2016, se publicó una versión revisada de Unity OE (4.0.1.8404134).
Resolution
Para resolver este problema, es necesario que el soporte técnico obtenga acceso raíz al arreglo.
Comuníquese con el soporte técnico de Unity y mencione este artículo de la base de conocimientos: 489057
Additional Information
Ejemplo de cómo comprobar el uso del espacio:
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
El registro o registros que causan esto se pueden encontrar en /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 (enumerar volcados de núcleo) también puede mostrar algunos volcados con el sufijo "_mgmtd".
Estos se crearon cuando los SP entraron en estado de alarma, ya que algunos servicios no se podían iniciar (debido a que /nbsnas estaba lleno).
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