Un importante proveedor de PaaS que ofrece una plataforma de computación ininterrumpida necesitaba automatizar su forma de evitar los problemas recurrentes para seguir garantizando sus SLA de pérdida y recuperación de datos en milisegundos, dándoles tiempo para diagnosticar y eliminar los problemas subyacentes.

La otra semana asistí a uno de los ingenieros de un importante proveedor de PaaS para que pudiera volver a dormir bien.

La empresa para la que trabaja ofrece una plataforma informática IBM Power PC sin interrupciones y necesitaba automatizar las actividades que realizaban sus ingenieros para poder seguir garantizando los SLA de pérdida y recuperación de datos en milisegundos para los que fue diseñada. Sabían que necesitaban tiempo para diagnosticar y eliminar los problemas subyacentes, por lo que necesitaban una forma rápida y fiable de solucionar los problemas a medida que se producían mientras tanto.

Este blog describe lo que se hizo en este entorno especializado, pero proporciona un gran ejemplo de aplicación de la automatización de la remediación en cualquier entorno. Este proveedor de servicios ofrece una plataforma IBM PowerPC como servicio a bancos, empresas de servicios públicos, empresas de telecomunicaciones y similares, utilizando dos clústeres en dos centros de datos, la replicación entre sitios proporciona alta disponibilidad y cero pérdida de datos. Los ingenieros utilizan NMIS, opEvents y opConfig para gestionar todo el entorno. NMIS se utiliza para recopilar estadísticas, estados y eventos de las instancias del clúster IBM Power PC, NMIS también recoge datos de los servidores miembros, la conmutación Fibre Channel y Ethernet y la SAN. Disponer de NMIS significa tener visibilidad en todo el entorno y hasta el estado del sistema operativo, en particular los demonios subyacentes, los servicios, etc. en el clúster de Power PC. En este caso, se utilizó la gestión de servicios de NMIS y las capacidades de los complementos para supervisar los sistemas de IBM.

El equipo estaba haciendo uso de las funciones de gestión de servidores de NM IS para recopilar datos de estado y rendimiento de varios plugins de Nagios para los servidores PowerPC. NMIS y opEvents alertaban al equipo de que la replicación de SVC fallaba ocasionalmente enviando notificaciones por SMS y correo electrónico a los equipos adecuados. El equipo respondía a estas notificaciones siguiendo un proceso para reiniciar el servicio SVC en las máquinas, por supuesto, esto era generalmente en medio de la noche. Necesitaban una manera de automatizar esta tarea de remediación rápidamente, así que esto es lo que hicieron en unos 20 minutos para completar el trabajo y sin gastar dinero.

Primero leen los documentos sobre la automatización de acciones de eventos en opEvents 

A continuación, se examinaron los eventos de replicación de SVC en opEvents mirando la pestaña de detalles de uno de los eventos anteriores. Se decidió que sólo querían que se activara si la alerta era "Servicio caído" en lugar de "Servicio degradado" y que sólo querían que ocurriera si el servicio estaba caído en el sitio primario, no si estaba caído en el sitio secundario. En la pestaña de detalles del evento se anotaron los siguientes atributos del evento:
event => Service Down
element => svc_lun_inservice
host => primary_cluster.example.com

A continuación probaron un script de shell que habían utilizado para reiniciar el servicio svc de forma remota, esto era simplemente tres comandos ssh remotos que habían estado emitiendo a mano, lo colocaron en el servidor NMIS en:
/usr/local/nmis8/bin/restart_svc.sh

La última pieza del rompecabezas era llamar al script cuando los detalles del evento coincidían.

Así que editando el archivo EventActions.nmis
/usr/local/omk/conf/EventActions.nmis

Se añadió lo siguiente:

1. Una acción de script - añadido a la sección 'script' de EventActions.nmis (copiando uno de los scripts de ejemplo como ejemplo) crearon lo siguiente:
'script' => {
'restart_svc' => {
arguments => 'node.host',                           # this script takes the nodes IP or hostname
exec => '/usr/local/nmis8/bin/restart_svc.sh',
output => 'save',                 # save a copy of the script's stdout which echos what it is doing
stderr => "save",
exitcode => "save",
max_tries => 2,
},

2. Una regla de coincidencia - añadida cerca de la parte superior de EventActions.nmis en la ubicación apropiada (de nuevo lo más fácil fue copiar y editar una de las entradas existentes).
'20' => {
IF => ' event.event eq "Service Down" and event.element eq "svc_lun_inservice" and node.host eq "primary_node.example.com" ' ,
THEN => 'script.restart_svc ()', # note this name matches the the name in the script section above
BREAK => 'false'
},

Finalmente, necesitaban una forma de probarlo sin hacer nada ni romper nada. Así que primero editaron el script de reinicio ligeramente para que sólo se hiciera eco de los comandos clave que emitiría en el servidor. Luego encontraron una copia del evento de caída del servicio en /usr/local/nmis/logs/event.log, la copiaron en el portapapeles, cambiaron la fecha (epoch) a ahora y la añadieron al registro.
"echo {the editied event line} >> event.log"
y observado opEvents para que el evento aparezca.

Luego miraron la sección de acciones del evento en la GUI y pudieron ver que el script se había disparado y pudieron ver todo lo que el script había hecho, desde su salida hasta su código de salida y sus mensajes stderr.

Finalmente cambiaron el script para que realmente ejecutara los comandos y se fuera a casa.

Esa noche falló la replicación del servicio, pero no se les envió un correo electrónico ni un mensaje de texto, ya que el sistema se reparó por sí solo inmediatamente y antes de que pasara el tiempo de escalamiento de 5 minutos. Trabajo realizado.

Mientras tanto, después de un mes de diagnósticos adicionales con el operador de la red, el proveedor del centro de datos, el proveedor de SAN y un equipo de otras personas, encontraron el problema subyacente de la replicación de LUN, un problema de tiempo de espera relacionado con el canal de fibra entre sitios y las cargas adicionales de copia de seguridad que se producen por la noche. Se cambiaron un par de temporizadores y todo fue bien.

 

Consiga el libro electrónico aquí