U2000 - No es posible acceder al iManager U2000

Pubilicado 2019-4-22 11:51:17Última respuesta abr. 22, 2019 16:21:24 46 1 3 1

Cuando se genera una alarma relacionada con el sistema HA en U2000 V200R014C60SPC200 o posterior, la tarea programada que reporta la alarma tiene defectos, por lo que se genera un gran número de pequeños archivos en la particion /var. Después de que el U2000 funcione durante mucho tiempo, el uso del inode de la partición /var está lleno. Como resultado, la funcionalidad del U2000 es anormal, la conmutación en el sistema HA falla, y el cliente U2000 no se puede iniciar sesión.

[Descripcion del Problema]

Condiciones de disparo:

l  La versión de  U2000 es una de las siguientes:

U2000 V200R014C60: Menor a la versión V200R014C60CP2033

U2000 V200R015C50: Menor a la versión V200R015C50CP2021

U2000 V200R015C60: Menor a la versión V200R015C60CP2012

U2000 V200R016C50: Menor a la versión V200R016C50SPC201

U2000 V200R016C60: V200R016C60SPC200, V200R016C60SPC202 y siguientes versiones (excluyendo V200R016C60CP2026)


l  Corra el siguiente comando como usuario root para verificar el uso del inode de la partición /var y confirmar si el resultado es mayor a 5%:


Linux:

df -i| grep var

/dev/sda6     1310720    1310720  0       100%  /var

Solaris:

df -F ufs -o i | grep var

/dev/vx/dsk/bootdg/var    2428608  0     100%   /var


l  Las tareas programadas relacionadas a las alarmas del sistema de HA no son redirigidas a /dev/null. El método de revisión es el siguiente:


Corra los siguientes comando como el usuario root:

# crontab -l | egrep "alarmlog|dblogmonitor|vvrmonitor"

Esto desplegará información similiar a la siguiente:

0-59 * * * * /opt/oss/server/platform/resourcemonitor/../../../engr/../manager/../engr/engineering/alarmmonitor/alarmlog.sh

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/oss/engr/install/scripts/dblogmonitor.sh

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/oss/engr/OSSApp/vvrmonitor.sh

Si en el resultado no se despliega "> /dev/null 2>&1", la tarea no esta redirigida a /dev/null.


l  En servidores Solaris, revise si Sendmail está instalado.


Corra el siguiente comando como usuario root:

# pkginfo | grep Sendmail

Si se muestra la siguiente información, Sendmail se encuentra inslatado:

system SUNWsndmr Sendmail (root)

system SUNWsndmu Sendmail (/usr)

En servidores Linux, no es necesario revisar la instalación de Sendmail.


Si todos las condiciones anteriores se cumplen, el problema existe.

 

Síntomas:

l  La funcionalidad del U2000 es anormal,  y el cliente de U2000 no lográ hacer login.

l  Los sitios primario y secundario estan anormales, y el switchover falla.

l  El uso del inode de la partición /var esta lleno, y el uso de espacio en la particion /var es muy alto.

 

[Causa Raíz]

Las siguientes tareas programadas no están redirigidas a /dev/null:

alarmlog.shdblogmonitor.shvvrmonitor.sh.

Cuando estas tareas se ejecutan, se genera un archivo en el directorio /var/spool/ postfix maildrop/ (/var/spool/clientmqueue en el sistema operativo Solaris). Después de que el U2000 ha estado operativo por mucho tiempo, el inode de la partición /var se llena, y no es posible generar nuevos archivos, ocasionando que la operación de U2000 sea anormal.

 

[Impacto y Riesgos]

l  La funcionalidad de U2000 es anormal, y el cliente de U2000 no logra hacer login.

l  El switchover de HA es anromal o falla.

 

[Medidas ySoluciones]

Medidas de recuperación:


Solución:

Nota

Estas medidas no causan un impacto adverso o riesgos para U2000. Realice estas medidas en ambos sitios primeario y secundario, no es necesario realizar un switchover.

1.         Ejecute los siguientes comando como usuario root para borrar los archivos de correo en la partición /var:

Linux:

# cd /var/spool/postfix/maildrop

# pwd

Se despliega la siguiente información:

/var/spool/postfix/maildrop

Ejecute los siguientes comandos para borrar los archivos de correo solo después de que se despliegue "/var/spool/postfix/maildrop" con el comando pwd, de otra manera, puede dañar el sistema.

# ls | xargs -n 100 rm -rf &

 

Solaris:

# cd /var/spool/clientmqueue

# pwd

Se despliega la siguiente información:

/var/spool/clientmqueue

 

Ejecute los siguientes comandos para borrar los archivos de correo solo después de que se despliegue "/var/spool/postfix/maildrop" con el comando pwd, de otra manera, puede dañar el sistema.

# ls | xargs -n 100 rm -rf &

 

2.         (Opcional) Si el sistema HA esta anormal, rectifique la falla e inicie el U2000.

Ejecute el siguiente comando en el sitio primario y en el sitio secundario para corregir los recursos dañados:

# hagrp -clear AppService

Ejecute el siguiente comando en el sitio primario para inciar el U2000:

# hagrp -online -force AppService -sys `hostname`

3.         Copie y ejectue los siguientes comandos (excluyendo el símbolo #) para modificar las tareas relacionadas a las alarmas de HA:

# crontab -l | egrep -v "alarmlog|dblogmonitor|vvrmonitor" >/tmp/crontab.txt

# crontab -l | grep "alarmlog" >/tmp/alarmlog.txt

# crontab -l | grep "dblogmonitor" >/tmp/dblogmonitor.txt

# crontab -l | grep "vvrmonitor" >/tmp/vvrmonitor.txt

# echo "`cat /tmp/alarmlog.txt` >/dev/null 2>&1" >>/tmp/crontab.txt

# echo "`cat /tmp/dblogmonitor.txt` >/dev/null 2>&1" >>/tmp/crontab.txt

echo "`cat /tmp/vvrmonitor.txt` >/dev/null 2>&1" >>/tmp/crontab.txt

# crontab /tmp/crontab.txt

 

Verificación:

1.         Ejecute el siguiente comandos para revisar que las tareas relacionadas a las alrams del sistema HA se encuentran redirigidas al directorio dev/null:

# crontab -l | egrep "alarmlog|dblogmonitor|vvrmonitor"

Se mostrará información similiar a la siguiente:

0-59 * * * * /opt/oss/server/platform/resourcemonitor/../../../engr/../manager/../engr/engineering/alarmmonitor/alarmlog.sh > /dev/null 2>&1

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/oss/engr/install/scripts/dblogmonitor.sh > /dev/null 2>&1

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/oss/engr/OSSApp/vvrmonitor.sh > /dev/null 2>&1

Si en el resultado no se despliega "> /dev/null 2>&1", la tarea está redirigida a /dev/null.

2.         Ejecute el siguiente comando para revisar el uso del inode de la partición  /var y que este ha disminuido a 5% o menos:

Linux

df -i| grep var

/dev/sda6     1048576    4625  1043951       1%  /var

Solaris

# df -F ufs -o i | grep var

/dev/vx/dsk/bootdg/var    9411 12419005     0%   /var




  • x
  • convención:

ruvader  Visitante   Pubilicado 2019-4-22 16:21:24 Útil(1) Útil(1)
Excelente caso, es necesario aplicar el procedimineto para versiones V200R016C60CP2026 y superiores?
  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente
Respuesta rápida Desplácese hasta arriba