diff options
Diffstat (limited to 'content/operations/pannes')
4 files changed, 138 insertions, 0 deletions
diff --git a/content/operations/pannes/2020-01-20-changement-ip.md b/content/operations/pannes/2020-01-20-changement-ip.md new file mode 100644 index 0000000..c86eb85 --- /dev/null +++ b/content/operations/pannes/2020-01-20-changement-ip.md @@ -0,0 +1,53 @@ ++++ +title = "Janvier 2020" +description = "Janvier 2020: changement imprévu d'adresses IP" +date = 2022-12-22 +dateCreated = 2022-12-22 +weight = 10 ++++ + +Le 20 janvier free a changé mon IP, un peu comme partout en France. +Ça concerne l'IPv4 et le préfixe IPv6. +Ici le bon vieux Bortzmoinsbien qui tweet : https://twitter.com/bortzmeyer/status/1351434290916155394 + +Max a update tout de suite l'IPv4 mais avec un TTL de 4h le temps de propagation est grand. +J'ai réduit les entrées sur les IP à 300 secondes, soit 5 minutes, le minimum chez Gandi, à voir si c'est une bonne idée. +Reste à update les IPv6, moins critiques pour le front facing mais utilisées pour le signaling en interne... + +## Le fameux signaling +Ça pose un gros problème avec Nomad (et en moindre mesure avec Consul). +En effet, Nomad utilise l'IPv6 pour communiquer, il faut donc changer les IPs de tous les noeuds. +Problème ! On peut pas faire la migration au fur et à mesure car, changeant d'IP, les noeuds ne seront plus en mesure de communiquer. +On n'a pas envie de supprimer le cluster et d'en créer un nouveau car ça voudrait dire tout redéployer ce qui est long également (tous les fichiers HCL pour Nomad, tout le KV pour consul). +On ne peut pas non plus la faire à la bourrin en stoppant tous les cluster, changer son IP, puis redémarrer. +Enfin si, Consul accepte mais pas Nomad, qui lui va chercher à communiquer avec les anciennes IP et n'arrivera jamais à un consensus. + +Au passage j'en ai profité pour changer le nom des noeuds car la dernière fois, Nomad n'avait PAS DU TOUT apprécié qu'un noeud ayant le même nom change d'IP. Ceci dit, si on utilise de facto le `peers.json` c'est peut être pas problématique. À tester. + +Du coup, après moult réflexions, la silver bullet c'est la fonction outage recovery de nomad (consul l'a aussi au besoin). +Elle est ici : https://learn.hashicorp.com/tutorials/consul/recovery-outage +En gros, il faut arrêter tous les nodes. +Ensuite créer un fichier à ce path : `/var/lib/nomad/server/raft/peers.json` +Ne vous laissez pas perturber par le fichier `peers.info` à côté, il ne faut pas le toucher. +Après la grande question c'est de savoir si le cluster est en Raft v2 ou Raft v3. +Bon ben nous on était en Raft v2. Si vous vous trompez, au redémarrage Nomad va crasher avec une sale erreur : + +``` +nomad: failed to start Raft: error="recovery failed to parse peers.json: json: cannot unmarshal string into Go value of type raft.configEntry" +``` + +(je me suis trompé bien sûr). +Voilà, après il ne vous reste plus qu'à redémarrer et suivre les logs, cherchez bien la ligne où il dit qu'il a trouvé le peers.json. + +## Les trucs à pas oublier + + - Reconfigurer le backend KV de traefik (à voir à utiliser des DNS plutôt du coup) + - Reconfigurer l'IPv4 publique annoncée à Jitsi + +## Ce qui reste à faire + + - Mettre à jour les entrées DNS IPv6, ce qui devrait créer : + - digitale.machine.deuxfleurs.fr + - datura.machine.deuxfleurs.fr + - drosera.machine.deuxfleurs.fr + - Mettre à jour l'instance garage sur io diff --git a/content/operations/pannes/2021-07-12-synapse-bdd-rempli-disque.md b/content/operations/pannes/2021-07-12-synapse-bdd-rempli-disque.md new file mode 100644 index 0000000..17650fa --- /dev/null +++ b/content/operations/pannes/2021-07-12-synapse-bdd-rempli-disque.md @@ -0,0 +1,22 @@ ++++ +title = "Juillet 2021" +description = "Juillet 2021: la BDD Synapse remplit nos disques" +date = 2022-12-22 +dateCreated = 2022-12-22 +weight = 20 ++++ + +# La BDD synapse rempli nos disques + +Todo: finir ce blog post et le dupliquer ici https://quentin.dufour.io/blog/2021-07-12/chroniques-administration-synapse/ + +Le WAL qui grossissait à l'infini était également du à un SSD défaillant dont les écritures était abyssalement lentes. + +Actions mises en place : + - Documentation de comment ajouter de l'espace sur un disque différent avec les tablespaces + - Interdiction de rejoindre les rooms avec une trop grande complexité + - nettoyage de la BDD à la main (rooms vides, comptes non utilisés, etc.) + - Remplacement du SSD défaillant + +Actions à mettre en place : + - Utiliser les outils de maintenance de base de données distribuées par le projet matrix diff --git a/content/operations/pannes/2022-01-xx-glusterfs-corruption.md b/content/operations/pannes/2022-01-xx-glusterfs-corruption.md new file mode 100644 index 0000000..bbd94af --- /dev/null +++ b/content/operations/pannes/2022-01-xx-glusterfs-corruption.md @@ -0,0 +1,36 @@ ++++ +title = "Janvier 2022" +description = "Janvier 2022: Corruptions GlusterFS" +date = 2022-12-22 +dateCreated = 2022-12-22 +weight = 30 ++++ + +# Corruption GlusterFS + +Suite au redémarrage d'un serveur, les emails ne sont plus disponibles. +Il apparait que GlusterFS ne répliquait plus correctement les données depuis un certain temps. +Suite à ce problème, il a renvoyé des dossiers Dovecot corrompu. +Dovecot a reconstruit un index sans les emails, ce qui a désynchronisé les bàl des gens. +À la fin, certaines boites mails ont perdu tous leurs emails. +Aucune sauvegarde des emails n'était réalisée. +Le problème a été créé cet été quand j'ai réinstallé un serveur. +J'ai installé sur une version de Debian différente. +La version de GlusterFS était pinnée dans un sources.list, en pointant vers le repo du projet gluster +Mais le pinning était pour la version de debian précédente. +Le sources.list a été ignoré, et c'est le gluster du projet debian plus récent qui a été installé. +Ces versions étaient incompatibles mais silencieusement. +GlusterFS n'informe pas proactivement non plus que les volumes sont désynchronisées. +Il n'y a aucune commande pour connaitre l'état du cluster. +Après plusieurs jours de travail, il m'a été impossible de remonter les emails. + +Action mise en place : + - Suppression de GlusterFS + - Sauvegardes journalière des emails + - Les emails sont maintenant directement sur le disque (pas de haute dispo) + +Action en cours de mise en place : + - Développement d'un serveur IMAP sur Garage + + + diff --git a/content/operations/pannes/petits-incidents.md b/content/operations/pannes/petits-incidents.md new file mode 100644 index 0000000..658757f --- /dev/null +++ b/content/operations/pannes/petits-incidents.md @@ -0,0 +1,27 @@ ++++ +title = "Petits incidents" +description = "Petits incidents" +date = 2022-12-22 +dateCreated = 2022-12-22 +weight = 1000 ++++ + +- **2020** Publii efface le disque dur d'un de nos membres. Il a changé le dossier de sortie vers /home qui a été effacé + +- **2021-07-27** Panne de courant à Rennes - 40 000 personnes sans électricité pendant une journée - nos serveurs de prod étant dans la zone coupée, deuxfleurs.fr est dans le noir - https://www.francebleu.fr/infos/faits-divers-justice/rennes-plusieurs-quartiers-prives-d-electricite-1627354121 + +- **2021-12:** Tentative de migration un peu trop hâtive vers Tricot pour remplacer Traefik qui pose des soucis. Downtime et manque de communication sur les causes, confusion généralisée. + + *Actions à envisager:* prévoir à l'avance toute intervention de nature à impacter la qualité de service sur l'infra Deuxfleurs. Tester en amont un maximum pour éviter de devoir tester en prod. Lorsque le test en prod est inévitable, s'organiser pour impacter le moins de monde possible. + +- **2022-03-28:** Coupure d'électricité au site Jupiter, `io` ne redémarre pas toute seule. T est obligée de la rallumer manuellement. `io` n'est pas disponible durant quelques heures. + + *Actions à envisager:* reconfigurer `io` pour s'allumer toute seule quand le courant démarre. + +- **2022-03-28:** Grafana (hébergé par M) n'est pas disponible. M est le seul à pouvoir intervenir. + + *Actions à envisager:* cartographier l'infra de monitoring et s'assurer que plusieurs personnes ont les accès. + +- **2022-12-23:** Les backups de la production ne s'effectuaient pas correctement car Nomad ne voulait pas lancer les jobs pour cause de ressources épuisées (pas assez de CPU). + + *Action menée:* La préemption des jobs a été activée pour tous les schedulers Nomad, ce qui permet aux jobs de backup de virer les jobs de plus faible priorité pour pouvoir se lancer (ces derniers seront relancés sur une autre machine automatiquement). |