En silencio, en algún lugar de una oficina en el centro de la ciudad, los rodamientos diseñados para durar 25 mil horas han estado funcionando sin parar durante más de cuarenta y tres mil. El ventilador se fabricó a bajo coste a partir de componentes obtenidos durante varios años en una docena de proveedores. Estuvo en caja durante semanas antes de ser instalado en el chasis del router, que a su vez estaba en caja. Dos meses en el mar, bien embalado en un contenedor de transporte, y luego más meses rebotando y revolviendo de un camión a un almacén, y de vuelta a una entrega de paquetes. Finalmente, el dispositivo fue configurado, embalado y enviado a su punto de instalación final. Metido en un armario demasiado estrecho y sin circulación de aire, este router de misión crítica ha estado funcionando sin parar durante los últimos cinco años. Es un milagro que haya funcionado tanto tiempo.
La velocidad del ventilador fue lo primero que se vio afectado por el fallo del rodamiento.
El aumento de la fricción en el eje del impulsor del ventilador hizo que el consumo de amperaje aumentara para compensar y mantener la velocidad de rotación. Cuando el consumo de amperaje llegaba al máximo, las rotaciones por minuto (RPM) disminuían. Con la velocidad más lenta del ventilador vino menos flujo de aire, con menor flujo de aire la temperatura del chasis aumentó.
Los dispositivos complejos, como los routers, requieren temperaturas de funcionamiento bajas. Cuanto más frío esté, más fácil será el movimiento de los electrones. A medida que la temperatura del chasis aumentaba, el router experimentaba problemas para procesar los paquetes de datos que atravesaban las interfaces. Al principio era un error aquí o allá, luego el enrutamiento de tráfico rutinario tuvo problemas y el router comenzó a descartar paquetes. A partir de ahí las cosas empeoraron mucho.
Es sábado por la tarde y tu fin de semana ha sido tranquilo hasta ahora. Una noche con tu pareja, una película y una cena. Ya es tarde y estás listo para ir a la cama cuando tu teléfono suena. El mensaje de texto es corto;
Dispositivo: Router principal
Evento: Chasis de alta temperatura con paquetes de salida de alto descarte
Acción tomada: Redirigir el tráfico aumentando el coste de OSPF
Acción requerida: Velocidad del ventilador baja, amperaje alto. El ingeniero debe investigar para reparar o reemplazar.
Un ventilador se estropeó, ¿qué es lo siguiente?
El sistema había respondido como lo haría usted: redirigió el tráfico fuera de la interfaz afectada evitando un posible impacto en el funcionamiento del sistema. Añadiendo una nota en su calendario para investigar el router a primera hora de la mañana del lunes se acostó para dormir bien.
A nuestro ingeniero principal en Asia-PAC, Nick Day, le gusta referirse a las soluciones de Opmantek como un "seguro de sueño para ingenieros". Viniendo de una experiencia en proveedores de servicios gestionados, puedo apreciar la situación. Los equipos siempre se rompen en su tiempo de vacaciones, a menudo cuando el ingeniero de guardia está lo más lejos posible, y con poca información útil del NMS. Este fue uno de los principales escenarios que utilizamos cuando creamos nuestra solución de Automatización de Procesos Operativos (OPA).
Construir una solución
Aprovechando la capacidad combinada de opTrend para identificar parámetros operativos fuera de las normas de tendencia, opEvents correlaciona los eventos y automatiza la corrección. Con la adición de opConfig se pueden automatizar los cambios de configuración de los dispositivos de red. La Automatización del Proceso Operativo (OPA) se basa en este análisis estadístico y en la heurística basada en reglas, para automatizar la resolución de problemas y la corrección de los eventos de red. Esto, a su vez, reduce el impacto negativo en la experiencia del usuario.
Los magos nunca revelan sus secretos... pero haremos una excepción.
Veamos ahora cómo se ha conseguido con el ejemplo anterior. opTrend es un motor de análisis estadístico. opTrend recoge los datos de rendimiento de NMIS, el sistema de fallos y rendimiento de Opmantek, y determina lo que es un funcionamiento normal. Mirando hacia atrás durante varias semanas, normalmente veintiséis, opTrend determina lo que es normal para cada parámetro que procesa. Lo hace hora por hora, considerando cada día de la semana individualmente. Así, el lunes por la mañana, de 9 a 10, tiene su propio cálculo, que es distinto al del sábado por la tarde, de 3 a 4. Al considerar varias semanas, opTrend puede normalizar cosas como los días festivos y las vacaciones.
Una vez que se determina la media de cada parámetro, opTrend calcula la desviación estadística del parámetro y crea una ventana de tres desviaciones estándar por encima y por debajo de la media. Cualquier actividad por encima o por debajo de estas ventanas desencadena un evento de opTrend en NMIS. Estos eventos pueden ser adicionales a los generados por el sistema de Umbral y Alerta de NMIS, o en su lugar.
En el ejemplo anterior, opTrend habría visto que la temperatura del chasis superaba la ventana normal de funcionamiento. Si la velocidad del ventilador y/o el amperaje también hubieran sido procesados por opTrend (no lo es por defecto, pero puede configurarse para que lo sea si se desea), éstos se habrían reportado como una baja velocidad del ventilador, y un alto amperaje).
Este evento de opTrend habría sido enviado a NMIS, y luego compartido con opEvents para su procesamiento. Un conjunto de reglas, o Acciones de Eventos, buscaba eventos que pudieran ser causados por una alta temperatura; a menudo relacionados con errores o descartes de paquetes de la interfaz. En el caso de los dispositivos inalámbricos (WiFi y RF), esto puede afectar a la intensidad de la señal y a la velocidad de conexión. Un resultado similar podría ser manejado usando una Regla de Correlación, que agruparía múltiples eventos a través de una ventana de tiempo en un nuevo evento padre. Ambos métodos son relevantes y tienen sus propios pros y contras.
opEvents ahora utiliza el evento de alta temperatura / altos descartes para iniciar una rutina de solución de problemas. Esto puede incluir dirigir opConfig para conectarse al dispositivo a través de SSH y ejecutar comandos CLI para recopilar información adicional de solución de problemas. El resultado de estos comandos puede tener su propia vida operacional - siendo evaluado por condiciones de error, disparando nuevos eventos y ellos mismos iniciando Acciones de Evento.
Revisemos el flujo del proceso:
- NMIS recoge datos de rendimiento del dispositivo, incluyendo la velocidad del ventilador, la temperatura y las métricas de rendimiento de la interfaz.
- opTrend procesa los datos de rendimiento recogidos de NMIS y determina cuál es el comportamiento normal/anormal de cada parámetro.
- Los eventos son generados por opTrend en NMIS, que luego se comparten con opEvents.
- opEvents recibe eventos de opTrend que identifican descartes de temperatura y de salida de la interfaz fuera de lo normal. Estos eventos se correlacionan en un único evento sintético, al que se le da una mayor prioridad, y se evalúa para la acción
- Una regla de acción de eventos coincide con un evento que afecta al rendimiento en un dispositivo Core que ejecuta un SO conocido. Esto llama a opConfig para que inicie copias de seguridad de la configuración cada hora y cada día, y luego ejecute un cambio de configuración para aumentar el coste de OSPF en la interfaz forzando el desvío del tráfico fuera de esta interfaz.
- opEvents también abre un ticket de asistencia a través de una API RESTful, y luego envía un mensaje de texto al técnico de guardia con las acciones realizadas y las actividades de seguimiento recomendadas.
- Una vez que el tráfico a través de la interfaz caiga, el error de descarte se borrará, generando un texto de notificación de subida al técnico de guardia.
Este es un ejemplo de lo que consideraríamos una automatización de complejidad media. Se compone de varias soluciones de Opmantek, cada una de ellas configurada (la mayoría de forma automática) para trabajar conjuntamente. Estas siete soluciones comparten y procesan información sobre fallos y rendimiento, correlacionan los eventos resultantes, aplican un único conjunto de acciones de eventos para recopilar información adicional y configuran en torno al evento. A la hora de aplicar las automatizaciones de las soluciones, abogamos por una metodología de rastreo-caminata-ejecución en la que se empieza por recopilar la información de resolución de problemas (rastreo), luego se automatizan las correcciones sencillas de un solo paso (caminata) y, a continuación, se despliegan lentamente las correcciones de varias rutas con puntos de control (ejecución).
Póngase en contacto con nosotros y empiece a automatizar la gestión de su red
Póngase en contacto con nuestro equipo de expertos aquí si desea saber cómo se desarrolló esta solución, o cómo se puede aprovechar la automatización de procesos operativos para ahorrar horas de trabajo y reducir el tiempo medio de resolución (MTTR).
