Indisponibilité de phobos les 04/04 17/04 et 21/04
Ce ticket reprend la suite d'incidents constatés sur notre nouvelle machine phobos, et ayant eu lieu pour le moment :
- le 04/04 à 10h49, rétablissement à 11h30
- le 17/04 à 23h15, rétablissement à 0h05
Ce défaut en est au stade de qualification, nous n'avons pas identifié la cause racine et ne pouvons pas prendre d'action corrective adaptée. Nous mettrons à jour le ticket lorsque nous aurons plus d'informations.
Constat
Le défaut constaté consiste en :
- indisponibilité du serveur phobos sur son IP principale et ses services système (pas de SYN/ACK) ;
- indisponibilité de tous les services hébergés sur phobos (pas de SYN/ACK) ;
- absence de logs pendant la période d'interruption ;
- absence de métriques pendant la période d'interruption.
Impact
Les services suivants sont impactés : Hiboo, Blogs, Nextcloud, DNS principal, DNS secondaire, Onlyoffice, TTRSS, Seafile, Gitlab, Img, Mailu, Mastodon, Matrix (bridges compris), Mumble, Nitter, Pads, Pixelfed, Weblate, Vault, Peertube, Writefreely.
Les services sont complètement indisponibles pendant la période d'interruption.
Aucune perte ou incohérence de donnée n'est constatée, sauf si vous étiez en train d'insérer des données pendant l'interruption (upload d'image, de vidéo, etc.)
Recherche de cause
Temps de réaction
Le temps de réaction sur chacun des crash est élevé (environ 1h entre l'interruption et le rétablissement). Ce temps élevé est principalement dû à l'indisponibilité des canaux d'alerte des robots de supervision pendant l'inerruption complète.
La cause secondaire est le manque de documentation et de procédure sur la réaction à un crash complet ou reboot de phobos.
PS : après mis à jour des agents de supervision, nouveau temps de réaction > 30 minutes. Un second niveau de supervision à mettre en place pour palier ce défaut.
Crash de phobos
Les pistes suivantes sont explorées :
- défaut du pare-feu, qui causerait l'interruption de tous les flux réseau ;
- kernel panic.
Le défaut de pare-feu n'est pas définitivement écarté, mais peu probable étant donné l'absence de logs système durant la période concernée.
Le kernel panic est probable. A l'issue de la première interruption, l'outillage de dump kernel (kdump
) a été déployé et configuré. L'étude des traces est toujours en cours pour la seconde interruption.
Les journaux ont été inspectés :
auth.log
syslog
messages
daemon.log
- journaux Docker du firewall
- journaux Docker de traefik
Rien n'indique la cause du problème à ce stade.
DNS secondaire
Le DNS secondaire est le seul service impacté hébergé sur une machine distincte.
Le service est hébergé dans un pod unique, comprenant pdns et acolyte (notre agent de synchronisation DNS). Acolyte échoue lors de l'indisponibilité, ce qui entraîne le redémarrage du pod. Le pod est configuré en mode pull: always
, et ne parvient pas à pull depuis la forge (puisqu'indisponible), il reste donc en état de redémarrage.
Mesures conservatoires
Mise en place d'alertes hors Matrix
-
ajout d'une notification Matrix sur un homeserver différent -
configuration de clients Matrix sur un homeserver différent -
ajout d'un canary pour détecter l'indisponibilité totale -
ajout de notification SMS en cas d'indisponibilité totale -
souscription temporaire à un service d'alerte SaaS
Documentation de la procédure de reboot
-
écriture de la documentation -
relecture de la documentation -
vérification que tous les administrateurs disposent des accès requis -
vérification que personne n'est dépendant de Vault en ligne
Mesures de correction
Remplacement du système de fichiers
Bien que la cause racine ne soit pas identifiée, elle est soupçonnée côté stockage. Il s'agit de supprimer la dépendance à btrfs.
-
identification d'un remplaçant -
remplacement progressif du stockage (ou rapide si changement de machine)
Mise à jour de acolyte
Acolyte doit être mis à jour pour supporter plus largement les erreurs de contact du DNS primaire.
-
mise à jour du code pour attraper les exceptions -
déploiement en test sur dns2 -
déploiement sur dns1