Cadena de watchdog

En los optiMEAS Devices se pone un fuerte énfasis en la tolerancia a fallos, la alta disponibilidad y la fiabilidad en el funcionamiento. Un elemento esencial es una cadena de watchdog continua desde el hardware hasta los componentes de software.

Principio básico

La cadena de watchdog de los dispositivos optiMEAS se compone de una combinación de componentes de hardware y de software que forman en conjunto una línea de supervisión. En esta línea se supervisa de forma continua el correcto funcionamiento de cada componente. Si un componente falla, se inician automáticamente medidas para garantizar el funcionamiento sin interrupciones. Las medidas abarcan distintos enfoques, entre ellos el reinicio selectivo de procesos individuales, el reinicio completo por software del sistema Linux, así como la desconexión selectiva y posterior reinicio de componentes de hardware individuales o incluso de todo el sistema.

La cadena de watchdog se representa esquemáticamente en la imagen siguiente.

Los distintos niveles de supervisión

El nivel más bajo lo forma el watchdog de hardware (controlador de alimentación). Se trata de un microcontrolador capaz de cortar selectivamente la alimentación de todos los demás componentes de hardware (procesador principal con el sistema Linux, módem, etc.) y de reiniciarlos. Dispone a su vez de un watchdog interno que lo reinicia en caso de fallo.

Este watchdog de hardware espera del nivel superior, el Device-Manager, una señal de vida cíclica. El Device-Manager es un componente central de software que envía una señal de vida al watchdog de hardware a través del bus I2C. Supervisa todos los procesos de software específicos de aplicación (apps) y es iniciado y supervisado, a su vez, por el proceso de Linux «systemd». En caso de fallo, systemd intenta reiniciar el Device-Manager hasta cinco veces antes de realizarse un reinicio completo por software.

Todos los procesos de software específicos de aplicación (apps) forman el nivel situado por encima del Device-Manager. El DeviceManager supervisa las apps (p. ej., el smartCORE) mediante un watchdog de software. La lista de las apps que deben supervisarse ya está definida en la configuración del sistema, de modo que el DeviceManager puede supervisar ya el inicio de los procesos. De este modo también se cubren los casos en los que el proceso se bloquea durante el arranque. Si no se recibe la señal de watchdog, el proceso se finaliza de forma selectiva y se reinicia. Los reinicios de procesos se cuentan y, al superarse ciertos límites, se produce un reinicio del sistema. Un funcionamiento estable durante un período prolongado restablece el contador.

Qué ocurre en caso de fallo

Veamos qué sucede cuando fallan componentes individuales: si una app se «bloquea», su señal de vida al Device-Manager deja de llegar. El Device-Manager reinicia entonces la app y cuenta los reinicios de la app a lo largo del tiempo. Si el problema no puede resolverse reiniciando la app, es decir, si los componentes fallan repetidamente, se reinicia todo el sistema.

Si el propio Device-Manager se bloquea, actúa en primer lugar el proceso systemd de Linux y reinicia el Device-Manager hasta cinco veces. Si aun así no se consigue un funcionamiento estable, se reinicia el sistema Linux completo.

Si fallan el Device-Manager y systemd, la señal de watchdog al watchdog de hardware deja de llegar. Este reiniciaría entonces todo el sistema mediante un ciclo de apagado y encendido (power cycle).

Prueba sencilla del sistema

No se recomienda intervenir manualmente en el sistema. No obstante, si el usuario experto desea realizar una prueba del sistema, se recomienda el siguiente procedimiento. Tras autenticarse y acceder al sistema, se finaliza un proceso supervisado a través de la consola de Linux, por ejemplo con

killall smartcore  

Tras un breve tiempo, el Device-Manager detectará la ausencia de la señal de vida y, con ello, el fallo del proceso. A continuación, el Device-Manager reiniciará el proceso.

La ausencia de la señal de vida y el reinicio del proceso quedan registrados en los archivos de registro del Device-Manager. Un vistazo al archivo de registro permite reconocer el proceso.