Chaîne de watchdog
Les optiMEAS Devices mettent fortement l'accent sur la tolérance aux pannes, la haute disponibilité et la fiabilité en fonctionnement. Un élément essentiel à cet égard est une chaîne de watchdog continue, du matériel jusqu'aux composants logiciels.
Principe de base
La chaîne de watchdog des appareils optiMEAS se compose d'une combinaison de composants matériels et logiciels qui forment ensemble une ligne de surveillance. Dans cette ligne, le bon fonctionnement de chaque composant est surveillé en continu. Si un composant tombe en panne, des mesures sont automatiquement engagées pour garantir un fonctionnement sans accroc. Ces mesures comprennent différentes approches, notamment le redémarrage ciblé de processus individuels, le redémarrage logiciel complet du système Linux ainsi que la mise hors tension sélective puis le redémarrage de composants matériels individuels, voire de l'ensemble du système.
La chaîne de watchdog est représentée schématiquement dans l'image suivante.
Les différents niveaux de surveillance
Le niveau le plus bas est constitué par le watchdog matériel (contrôleur d'alimentation). Il s'agit d'un microcontrôleur capable de mettre hors tension de manière ciblée tous les autres composants matériels (processeur principal avec système Linux, modem, etc.) et de les redémarrer. Il dispose lui-même d'un watchdog interne qui le redémarre en cas d'erreur.
Ce watchdog matériel attend du niveau supérieur, le Device-Manager, un signal de vie cyclique. Le Device-Manager est un composant logiciel central qui envoie un signal de vie au watchdog matériel via le bus I2C. Il surveille tous les processus logiciels spécifiques aux applications (apps) et est lui-même démarré et surveillé par le processus Linux « systemd ». En cas d'erreur, systemd tente de redémarrer le Device-Manager jusqu'à cinq fois avant qu'un redémarrage logiciel complet ne soit effectué.
Tous les processus logiciels spécifiques aux applications (apps) constituent le niveau situé au-dessus du Device-Manager. Le DeviceManager surveille les apps (par ex. le smartCORE) au moyen d'un watchdog logiciel. La liste des apps à surveiller est déjà définie dans la configuration du système, de sorte que le DeviceManager peut déjà surveiller le démarrage des processus. Les cas où le processus plante pendant la montée en charge sont ainsi également couverts. En l'absence de signal de watchdog, le processus est arrêté de manière ciblée puis redémarré. Les redémarrages de processus sont comptés et, lorsque certaines limites sont dépassées, un redémarrage de l'appareil est déclenché. Un fonctionnement stable sur une période prolongée remet le compteur à zéro.
Que se passe-t-il en cas d'erreur
Voyons ce qui se passe en cas de défaillance de composants individuels : si une app « plante », son signal de vie vers le Device-Manager cesse. Le Device-Manager redémarre alors l'app et compte les redémarrages de l'app dans le temps. Si le problème ne peut pas être résolu par un redémarrage de l'app, c'est-à-dire si les composants tombent en panne de façon répétée, l'ensemble du système est redémarré.
Si le Device-Manager lui-même plante, c'est d'abord le processus systemd de Linux qui intervient et redémarre le Device-Manager jusqu'à cinq fois. Si aucun fonctionnement stable ne s'établit malgré tout, le système Linux complet est redémarré.
Si le Device-Manager et systemd tombent en panne, le signal de watchdog vers le watchdog matériel cesse. Celui-ci redémarrerait alors l'ensemble du système par un cycle d'alimentation (power cycle).
Test simple du système
Il n'est pas recommandé d'intervenir manuellement sur le système. Si l'utilisateur averti souhaite néanmoins effectuer un test du système, la démarche suivante convient. Après authentification et connexion au système, un processus surveillé est arrêté via la console Linux, par exemple avec
killall smartcore
Après un court laps de temps, le Device-Manager détectera l'absence du signal de vie et donc la défaillance du processus. Le processus est alors redémarré par le Device-Manager.
L'absence du signal de vie et le redémarrage du processus sont consignés dans les fichiers journaux du Device-Manager. Un coup d'œil au fichier journal permet de reconnaître le déroulement.
