Sélectionner une page
Post-mortem de l’incident majeur sur l’instance Mastodon de FairSocialNet

Bonjour à toutes et à tous,

Le 9 février 2020 l’instance Mastodon tooting.ch a connu un coup dur sans précédent; celle-ci a été indisponible durant un mois complet. Fort heureusement, aucune donnée n’a été perdue et nous souhaitons vous expliquer ce qu’il s’est passé en toute transparence.

Il a fallu un mois complet pour remettre sur pied l’instance dû à un nombre de contraintes conséquentes, ceci étant le fruit de plusieurs facteurs. Tout d’abord, nous souhaitons nous excuser pour la non-disponibilité de l’instance. Nous savons combien certain·e·s y sont attaché·e·s et l’utilisent quotidiennement pour échanger, s’informer et communiquer. Il nous est important de montrer que nous sommes capables de créer des réseaux sociaux fédérés, hébergés localement avec du logiciel libre, transparent et qui respectent votre vie privée contrairement à plusieurs de nos « concurrents ».

Si vous n’avez pas le temps de lire ceci, sachez que nous nous sommes entouré·e·s de personnes habituées à faire de l’administration système et de la gestion de serveurs. Ensemble nous sommes plus résilients et ceci est important pour l’association. Nous avons également comme projet de déménager l’ensemble de nos services chez SwissNeutralNet. Durant cette interruption, nous avons dû faire le choix entre laisser le service “sur place” ou de le déménager directement. Nous avons choisi la deuxième option car elle comprenait des bénéfices certains, notamment une remise à plat complète de l’instance Mastodon.

Le facteur humain
Au début de FairSocialNet, il y a eu un enthousiasme grandissant pour la mise en place de services web éthiques, en particulier des réseaux sociaux comme Mastodon, Diaspora*, PeerTube, etc. À ce moment, nous devons avouer qu’il n’y avait pas les compétences en interne pour mettre en place de tels services. Notre travail est entièrement bénévole et engager un·e administrateur·ice système n’est pas dans nos moyens financiers. Nous avons fait appel à une tierce personne qui n’était pas très impliquée dans le projet et a mis en place les différents éléments contre une petite rémunération. Malheureusement, tout ceci a été fait sur la même machine avec un fort mélange de technologies, de versions, le gros du problème venant surtout des sauvegardes non testées.

Nous ne voulons pas blâmer cette personne, c’est un fait voilà tout. Nous prenons acte de ce qui s’est passé pour prendre de meilleures décisions pour le futur.

Si vous n’êtes pas dans la technique vous pouvez passer directement à la conclusion.

Le facteur technique
En prenant en compte le point précédent, il est évident qu’avec un manque de compétences au sein de l’association FairSocialNet, nous n’avions pas le recul nécessaire sur les choix techniques pris au moment de l’installation des services fournis. Nous devons nous rendre à l’évidence qu’un mauvais choix technique est extrêmement impactant pour le fonctionnement de l’infrastructure, tout comme assembler un château avec des pierres n’est pas à la portée de tout le monde: une pierre mal placée et l’ensemble peut s’écrouler. C’est ce qu’il s’est passé.

Les faits techniques
Le 9 février à la suite d’une maintenance d’urgence, l’instance tooting.ch qui consommait toutes les ressources du processeur et aussi du stockage ne voulait pas redémarrer. Elle consommait de plus en plus d’espace disque sans que nous ne sachions pourquoi et les autres services installés sur la machine ne fonctionnaient plus par manque de puissance processeur.

Par manque de connaissance, une des commandes lancées sur le serveur a rendu les choses plus compliquées, cassant le container Docker présent sur le serveur. Vu la complexité de la situation nous avons fait appel à plusieurs personnes venues en aide pour gérer la situation. La situation était critique. En effet, notre dernier snapshot remontait à novembre (ceci n’est pas automatique de manière journalière chez notre hébergeur) et nous avons constaté que les backups ne fonctionnaient plus depuis plusieurs mois. Nous devions également prendre en compte qu’utiliser ce snapshot de novembre pour remonter le service au plus vite impliquait aussi d’effacer un certain nombre de données sur les autres services comme Diaspora*.

Nous avons fait le choix de ne pas l’utiliser et de rechercher les données qui seraient éventuellement existantes sur le serveur pour ne pas péjorer diasporing.ch. N’étant pas des connaisseurs de Docker, et celui-ci étant complexe à gérer en production si il n’est pas bien maîtrisé sur tous ses aspects, nous avons dû apprendre certaines choses « sur le tas ». Cela n’a pas rendu la tâche facile car tant l’instance que la base de données étaient gérés avec ce système.

En cherchant dans le serveur, nous avons retrouvé le stockage de la base de données qui était géré avec PostgreSQL 9, une ancienne version du serveur de bases de données. Nous avons exporté puis réimporté les fichiers de la base sur un nouveau serveur virtuel (conteneur LXC) de développement. À ce moment, nous constatons que la base de données est gérée avec l’utilisateur principal de PostgresSQL et qu’il y a des données propres au gestionnaire de base de données qui ne concernent pas Mastodon; la base de données n’est donc pas propre.

En voulant l’exporter, nous constatons que cela n’est pas possible car la base template0 nous en empêche. Il a fallu à ce moment effectuer un ensemble de manipulations relativement techniques pour pouvoir retravailler sur la base de données.

Ensuite il a fallu faire un comparatif entre une base de données neuve en version 9 et celle que nous avions récupérée, avec plusieurs manipulations pour arriver à un état standard.

Tout ceci a pris un nombre de jours conséquent, rappelons que nous ne sommes pas salarié·e·s et que nous réalisons cela sur notre temps libre.

Après le nettoyage de la base de données et sa migration en version 11, nous devions récupérer les fichiers relatifs aux médias qui étaient stockés sur un serveur séparé (un bucket S3), à l’origine pour des raisons de coût. Mastodon laisse à l’administrateur·ice le soin de supprimer manuellement les médias inutiles aux intervalles désirés. Du fait que ce nettoyage n’avait jamais eu lieu, le nombre de fichiers était impressionnant: 3’186’078 fichiers représentant environ 600 Go.

Nous avons fait plusieurs tentatives pour essayer de rapatrier ces fichiers et nous avons constaté que ceci nécessitait une quantité de RAM gigantesque. Nous avons donc augmenté la RAM en conséquence, jusqu’à 24 Go sur l’hyperviseur de SwissNeutralNet (heureusement que nous avions cela à disposition) en monitorant en permanence le téléchargement et les ressources serveur. Nous avons relancé la commande de téléchargement du bucket S3 et celle-ci a mis 7 heures rien que pour lister les fichiers à télécharger ce qui a demandé 15.5 Go de RAM en permanence durant 3 jours, le temps de tout télécharger.

Après le rapatriement des données, nous avons effectué une copie de sécurité qui a durée une journée. Durant le téléchargement nous avons préparé le nouveau serveur avec une procédure d’installation toute neuve. Plusieurs logiciels ont été mis à jours vers leur dernière version, ce qui avant devenait aussi un problème de sécurité avec Docker. Nous avons fait le choix de ne plus utiliser Docker pour des raisons techniques, de sauvegarde et surtout de maintenance.

Notre procédure d’installation étant fonctionnelle, nous avons effectué la procédure de nettoyage des médias, ce qui a duré de nombreuses heures. Le soir-même, nous avons modifié les enregistrements DNS pour diminuer le TTL (temps de vie) à cinq minutes pour migrer facilement lorsque ce serait prêt. Le lendemain, nous avons recréé le container depuis le début, exécuté la procédure d’installation, réimplanté la base de données et les fichiers média. Après un test concluant nous avons basculé l’enregistrement DNS IPv4 et créé l’enregistrement IPv6 ce qui a permis à l’instance de refonctionner.

Après plus d’un mois d’arrêt, celle-ci a dû rattraper tous les pouets des autres instances auquels nos abonné·e·s de l’instance ont souscrit, ce qui a occasionné une charge processeur un peu conséquente durant le jour qui a suivi.

L’ensemble de ces opérations s’est déroulé sur environ 3 à 4 jours par semaine durant nos disponibilités, tout en gérant notre énergie qui n’était pas au beau fixe mais nous sommes heureux·se·s que l’instance soit à nouveau fonctionnelle, propre et désormais gérée correctement.

En conclusion
Nous devons nous rendre à l’évidence qu’il y a plusieurs défaillances au sein de l’association. Nous prenons notamment acte d’un fort manque de gestion technique et également de communication puisque nous n’avons que peu communiqué durant l’incident, ce qui a sûrement occasionné des départs de certaines personnes vers d’autres instances. Nous hébergeons également des comptes officiels de plusieurs associations et d’une administration cantonale. Ceci rend notre service d’autant plus critique. Nous espérons que vous continuerez à nous faire confiance malgré cet incident et sommes heureux de constater que la vie de l’instance sereinement repris.

Nous souhaitons également vous informer que nous avons pris de fortes dispositions pour que ce genre d’incident n’arrivent plus. Ces modifications sont en cours et en particulier des changements majeurs auront lieu sur le principe de sauvegarde de l’infrastructure, qui a été complètement défaillant.

Au nom de l’association FairSocialNet et des membres de SwissNeutralNet qui nous ont soutenu durant cette situation, nous souhaitons vous remercier pour votre compréhension et la patience dont vous avez fait preuve, ceci nous encourage à continuer et d’améliorer continuellement nos services respectueux de votre vie privée et d’un Internet décentralisé.

Le comité de FairSocialNet

Texte rédigé conjointement par Rafael Munoz (président), Florian Siegenthaler (SwissNeutralNet) et Mathias B. (SwissNeutralNet) le 21.03.2020.