Certains ont peut-être remarqué que le blog a été indisponible pendant quasiment une semaine entre jeudi 14 novembre et hier. Tout d’abord je tiens à rappeler que je ne donne aucune garantie sur la disponibilité du blog et qu’il est normal qu’il se retrouve hors-ligne quelques jours de temps en temps. En effet, celui-ci est auto-hébergé sur un raspberry 3B+ et si pour une raison ou une autre je dois couper la connexion internet alors il n’est logiquement plus joignable. Cependant, cette dernière indisponibilité n’était pas volontaire. Je vais donc revenir sur ce qu’il s’est passé et sur les mesures à prendre pour éviter que cela ne se reproduise.

Toutes les heures ci-dessous sont les heures françaises métropolitaines.

Déroulement des évènements

Jeudi 14 novembre, une grande quantité de neige se met à tomber, ce qui provoque rapidement des chutes d’arbres et de multiples dommages aux lignes électriques. Aux environs de 18h le courant alimentant le serveur se coupe. Je m’en suis rendu compte très rapidement et est commencé à me renseigner sur la durée prévisionnelle de la panne. Vendredi, enedis a commencé à diffuser l’information qu’il ne fallait pas attendre avant la fin du week-end pour un retour à la normale étant donné le grand nombre de lignes touchées. En attendant, j’avais donc décidé de rediriger les visiteurs vers une page de travaux de mon hébergement OVH.

Dimanche à 20, le courant a été rétabli, entraînant le redémarrage normal du serveur. Dans l’heure, le résolveur DNS dynamique s’est mis à jour pour diriger à nouveau les visiteurs vers le blog.

Lundi aux environs de 8h, le courant a été de nouveau coupé avant de se rétablir vers 16h. Le serveur a redémarré à nouveau normalement. Mardi matin, je me suis aperçu que le serveur n’était de nouveau plus accessible. Enedis signalant encore des possibles pannes je ne me suis pas inquiété. Cependant mercredi, aucune panne de courant n’était signalé et dans les faits, le serveur était bien alimenté. De plus, certains essais affichaient une page d’erreur NGINX, preuve que la requête aboutissait bien au serveur. N’ayant aucune possibilité d’accès à distance fonctionnelle et n’étant pas sur site, je l’ai fait éteindre le mercredi à 19h.

Finalement, samedi à 16h, après plusieurs redémarrages et investigations, les services ont été définitivement rétablis.

Investigations

Mes investigations n’ont porté que sur la dernière indisponibilité; celle démarrant le lundi soir. En effet, la panne précédente avait pour unique raison la coupure de courant. Ne prévoyant et ne comptant pas prévoir de mesures de redondances dans ce cas-là, je ne m’y suis pas penché directement.

Ma première hypothèse était un problème de renouvellement de l’ip dynamique au niveau du DNS. En effet, le routeur ayant redémarré de nombreuses fois, un changement d’adresse IP mal répercuté n’était pas à exclure. Cependant, comme mentionné précédemment, j’ai eu quelques fois des erreurs NGINX dans le navigateur, prouvant que le serveur était bien atteint.

Ma seconde hypothèse était une corruption de la mémoire de masse du serveur suite aux nombreux redémarrages intempestifs. Toutefois, un premier redémarrage le samedi m’a permis de me reconnecter et de constater que tout fonctionnait bien dans un premier temps. C’est en voyant la consommation de RAM s’envoler quelques minutes après le redémarrage dans ma page de monitoring, ce qui a rendu le serveur de nouveau inaccessible, que j’ai trouvé le vrai problème.

Le lundi soir, lorsque je me suis reconnecté au serveur après le retour du courant, l’en avais profité pour ajouter un antivirus (Clamav) sur un autre service hébergé sur la machine. Ayant fait quelques essais sans constater de problèmes majeurs, je m’étais déconnecté en laissant le tout en l’état. Or, Chaque déclenchement de l’antivirus par l’autre service fait très rapidement saturer les 1Go de RAM disponibles puis la SWAP, provoquant le blocage complet du serveur. Après un nouveau redémarrage et la désactivation de l’antivirus, tout est rentré dans l’ordre.

Mesures correctives possibles.

La page de travaux utilisée par moment lors de la panne est la page par défaut du mini hébergement OVH fournit avec le nom de domaine. Je compte donc prendre le temps de créer une vraie page d’indisponibilité personnalisée qui servirait également pour les mises à jours.

Une autre mesure à laquelle je songe est d’essayer de faire un script watchdog en PHP qui serait exécuté régulièrement sur cet hébergement. En cas d’indisponibilité du serveur, il mettrait automatiquement à jour le DNS dynamique vers la page d’indisponibilité.

Enfin, concernant l’erreur humaine de l’installation d’un logiciel trop gourmand en ressource, une solution à long terme mais longue à mettre en place serais de faire des tests sur une VM iso-production avant. Cependant, le serveur étant sur une architecture ARM, la VM passerait automatiquement par une couche d’émulation qui pourrait fausser les résultats. Je verrais ce qu’il est possible de faire sans me prendre trop la tête dessus. De manière, ce serveur me sert régulièrement à expérimenter donc il n’est pas exclu qu’un problème similaire se reproduise.

Conclusion

Voilà pour les détails. En résumé ce fut une conjonction de problèmes météo et d’une expérimentation foireuse. Au moins vous saurez que clamav ne tourne pas tellement bien avec 1 Go de ram sur raspberry pi.

• blog
• Post-Mortem