Comme je l’ai annoncé, il y a quelques jours, le 8 septembre 2022 est survenue une panne sur un de mes serveurs. Un disque dur qui a « rendu l’âme ». Ce genre de panne est classique, et j’étais préparé… enfin c’est ce que je pensais.
Voici donc un petit retour d’expérience, pleine d’humilité, où se mêlent la « loi de l’emmerdement maximum » (un dérivé de la loi de Murphy, erreurs d’évaluation des risques et imprévus… le tout à cause de ce qui n’était initialement qu’une défaillance…
Pour les plus pressés, rendez-vous à la section bilan. Pour les plus curieux… bonne lecture !
Petit apparté
Petit aparté afin de bien saisir l’ensemble de l’histoire. Le serveur affecté par la panne à la charge de plusieurs services que j’utilise en interne. Une panne signifie donc plus de serveur. Plus de serveur, plus de services…
Le serveur en question est une machine physique tenant le rôle d’hyperviseur. Un hyperviseur est une plateforme de virtualisation permettant d’héberger plusieurs machines, qui seront quant à elles, virtuelles.
Pour les plus curieux et techniques de mes lecteurs, l’hyperviseur est un Proxmox utilisant la technologie des conteneurs en guise de virtualisation.
Les pannes d’origines matérielles ne peuvent intervenir qu’un niveau de l’hyperviseur, puisque seul ce dernier à un accès à du matériel réel. La défaillance de l’hyperviseur à donc entrainer l’indisponibilité de l’ensemble des services s’exécutant sur ce serveur, c’est-à-dire quasiment tous (heureusement, mes mails sont gérés par un prestataire externe !).
Au commencement, une panne d’un disque dur
Tout commence donc par la panne d’un disque dur. Prévoyant, mon serveur en disposait de deux afin d’avoir une redondance. Dans le jargon informatique, on dit qu’ils étaient montés en miroir. Et effectivement, la panne du disque dur n’a pas altéré le fonctionnement du serveur. Les services étaient toujours disponibles, tout se passait bien.
Je contacte donc mon hébergeur afin de lui signaler la panne du disque dur afin qu’il procède à son changement. L’opération est rapide, et en moins de 2h, le disque dur est changé, et le serveur redémarré. C’est maintenant que les ennuis commencent…
Redémarrage du serveur en mode « rescue »
Le mode rescue est un mode de démarrage spéciale permettant de réaliser de la maintenance sur le serveur. Il s’agit de démarrer le serveur sur un système d’exploitation autre que celui qui est installé afin de pouvoir réaliser des opérations de maintenance en tout sécurité.
L’opération à effectuer est relativement simple : il s’agit de recopier le disque resté en place sur le nouveau qui vient d’être installé, afin de rétablir la redondance (et donc la sécurité) des données. La duplication du disque étant gérée de manière logiciel et non matériel, il fallait lancer la restauration manuellement avant de redémarrer le serveur.
Premier contre temps rencontré : l’impossibilité d’effectuer la restauration. Le disque est en cours d’utilisation et la restauration refusait catégoriquement de se faire tant que le disque était utilisé. Ce mécanisme de protection est tout à fait normal et même souhaitable afin de protéger les données. Encore fallait-il trouver ce qui utilisait ce disque.
Le problème trouvait sa source dans la duplication. Comme dit précédemment, la duplication est logicielle. Et il existe plusieurs méthodes pour la réaliser. Le mode « rescue » avait automatiquement chargée la méthode majoritairement utilisée de nos jours (mise en miroir de partitions de disques) alors que sur le serveur, c’était de la duplication gérée par le système de fichier (ZFS).
Quelques minutes furent donc nécessaire pour déterminer l’origine du problème et procéder à sa résolution. Il faut ensuite attendre plusieurs dizaines de minutes pour que la restauration soit effective et pouvoir redémarrer ensuite le serveur en mode « normal ».
Redémarrage du serveur en mode « normal »
Le serveur redémarre donc, et au bout de quelques secondes, un message d’erreur s’affiche. Ce message informe de l’impossibilité de démarrer, faute de système d’exploitation disponible.
Je repasse donc en mode « rescue » pour examiner plus en détail le contenu du disque. Il contient 3 partitions :
- une grande partition occupant quasiment tout le disque ;
- une partition plus petite de quelques Go ;
- et une dernière partition de quelques centaines de Mo.
Un examen de la plus grande des partitions montre qu’elle contient bien toutes les données relatives aux différentes machines virtuelles. Les différents services sont donc bien présent. Jusque là, tout va bien.
Une étude de la seconde partition, celle censée contenir le système d’exploitation de l’hyperviseur à proprement parlé, montre qu’elle est vide. Croyant à un mirage, je prends le temps de bien réexaminer la situation et je dois me rendre à l’évidence : lors de l’installation du serveur, les données (VM) étaient bien redondées, pas le système (hyperviseur) .
L’erreur au démarrage (système d’exploitation absent) était donc tout à fait normal.
Ayant des sauvegardes des services, je me décide à réinstaller le système d’exploitation, puis à restaurer les services.
Je garde mon optimisme. Je me dis que l’opération prendra certes un peu plus de temps qu’initialement prévue, mais qu’elle a de nombreuses vertus pédagogiques.
Installation du système d’exploitation
Afin de garder la meilleure compatibilité avec l’existant, je réinstalle le même système d’exploitation (Proxmox) mais en version plus récente, et en installant toutes les mises à jour disponibles.
L’installation se passe bien. Cette fois-ci, je tire une leçon de ma précédente erreur. Je passe sur une redondance au niveau des partitions, et je m’assure que toutes les partitions soient bien redondées.
Il reste ensuite à restaurer la configuration.
Restauration de la configuration
Après avoir récupéré la dernière sauvegarde de la configuration du serveur, je me rends compte que cette sauvegarde est complètement obsolète. La date de mars 2021 me permet de faire le lien avec l’incendie ayant ravagé un des centres de données d’OVH dans la nuit du 9 au 10 mars 2021.
Le serveur, bien qu’épargné par l’incendie, est resté plusieurs jours hors tension. Lors de sa remise en service, tous les services ont bien redémarré. Tous ? Non ! Celui en charge de la sauvegarde de la configuration n’a pas été automatiquement relancé, suite… à une erreur de configuration. Le démarrage automatique n’était tout simplement pas activé.
J’ai donc exhumé la documentation écrite à l’époque. Cela prend un petit peu de temps, mais cela avance. Il a fallu également mettre à jour cette documentation, entre le moment de son écriture, et le moment de sa réutilisation, la version de Proxmox n’était plus la même (passage de la version 5 à la version 7).
Restauration des différents services
Pour les services, je dispose de sauvegarde des conteneurs. En théorie, il me suffit donc de les restaurer à partir de la sauvegarde pour pouvoir les retrouver. Je suis confiant, j’avais réalisé des essais régulièrement pour cette étape crucial, afin de tester l’intégrité des sauvegardes.
Hormis un petit détail de configuration dont l’aspect technique ne revêt que peu d’intérêt, tout se passe bien.
Redémarrage des services
Et là, c’est le drame. Le vrai. La catastrophe. La restauration s’est faite sans aucun problème, les conteneurs se lancent… mais rien.
J’essaie de me connecter à un conteneur depuis l’interface de l’hyperviseur, et je n’obtiens qu’un écran noir.
J’essaie de me connecter à un conteneur directement depuis la ligne de commande. J’y arrive et vois son contenu. Bonne nouvelle : les données sont bien là et facilement accessibles.
Mais impossible de démarrer véritablement les services. Les logs sont vides, je n’ai aucun message d’erreur. Tout semble fonctionner, sauf que les services ne se lancent pas…
Après 1h d’investigation totalement infructueuse, deux solutions s’offrent à moi :
- réinstaller les services un à un, et procéder à une restauration des données lorsque c’est nécessaires ;
- ou essayer Yunohost.
La première solution aurait été longue. Ayant automatisé l’installation des services, je disposais des scripts permettant de les réinstaller. Mais il s’agit d’une réinstallation vierge, sans les données. Il aurait donc fallu intervenir manuellement sur chaque conteneur afin de les restaurer. Beaucoup de temps et d’énergie donc.
Je me suis donc laissé tenté par la seconde : l’installation de Yunohost. Yunohost, d’après Wikipédia, c’est :
YunoHost est une distribution basée sur Debian GNU/Linux composée de logiciels libres et ayant pour objectif de faciliter la pratique de l’auto-hébergement au sens large.
Autrement dit, YunoHost permet d’installer et d’utiliser son propre serveur dans le but d’héberger, le plus souvent chez soi, des services tels que des boites de courriers électroniques, des sites web, des outils de synchronisation de fichiers, de messagerie instantanée, etc.
https://fr.wikipedia.org/wiki/YunoHost
Cela faisait quelques temps que j’avais envie de tester cette solution, afin de faciliter la gestion de mes différents services. J’ai donc sauté sur l’occasion.
Quelques temps plus tard…
J’ai pu rétablir avec une facilité assez déconcertante la plupart de mes services. J’ai même pu en installer d’autres en quelques clics alors qu’une installation manuelle aurait demandée beaucoup plus de temps.
Si j’ai du consacré un peu de temps à la prise en main de Yunohost, je suis pour l’instant très satisfait de ce choix. J’ai encore quelques tests à faire (notamment la restauration de sauvegarde), mais pour l’instant, tout se déroule pour le mieux.
Résumé
L’ensemble des écueils rencontrés sont résumés dans le tableau ci-dessous :
| Problème | Conséquences |
|---|---|
| Panne disque dur | La panne a nécessité d’éteindre le serveur afin de remplacer le disque dur défectueux |
| Système non redondé | La panne d’un disque avait une chance sur deux d’empêcher le redémarrage du serveur |
| Configuration non sauvegardée | Nécessité de reconfigurer manuellement le serveur |
| Documentation non mise à jour | Temps supplémentaire pour procéder à la reconfiguration du serveur |
| Chargement des conteneurs | Impossibilité de relancer les services |
La dernière question que l’on peut se poser, c’est de savoir si les problèmes rencontrés étaient finalement évitables. Après tout, si on met la panne initiale d’origine matériel, le reste est un « manque » dans le plan de reprise d’activité.
Et la réponse est… oui ! Pour des raisons de gains illusoires de temps et de coûts, j’avais cédé à la facilité de ne réaliser que des tests partiels de restauration au lieu d’un test complet. En réinstallant les services sur un serveur différent alors :
- le système non redondé n’aurait pas été un souci, ayant été « habitué » à rétablir les services ;
- l’absence de la sauvegarde de la configuration aurait été détecté beaucoup plus tôt ;
- idem pour le problème de chargement des conteneurs, qui aurait aussi été identifié.
Je qualifie les gains d' »illusoires » car si les tests partiels présentaient effectivement un gain en temps, le temps passé à résoudre les problèmes « en urgence » a été bien supérieur au temps « économisé » à ne pas faire des tests complets.
Bilan
Gardant mon optimisme habituel, plutôt que de m’apitoyer sur le temps perdu, je regarde l’aspect pédagogique de ces événements, dont j’ai pu tirer de riches enseignements :
- il a mis en avant les lacunes dans mon plan de reprise d’activité « important » ;
- il a mis en lumière les défauts de configuration et de sauvegarde ;
- il m’a permis de découvrir et tester Yunohost.
Et surtout, cela va me permettre de mettre à jour mon plan de reprise d’activité pour les activités « primordiales ». En effet, je dispose de plusieurs plans de reprise d’activité en fonction des risques encourus et surtout de l’importance des services et des données en jeux.
Les défaillances dans un des plans vont me permettre de mettre à jour les autres, de les tester, afin de ne pas commettre les mêmes erreurs…
Pourquoi tout cela ?
Il s’agit d’un partage d’expérience. Je m’adresse non pas en tant qu’informaticien, mais en tant que chef d’entreprise, à mes pairs, aux décideurs, aux responsables dont les aspects techniques ne sont généralement pas leur priorité (à juste titre).
Imaginez qu’une panne arrive chez vous. Plus d’internet, plus d’intranet, plus de mails ou plus de téléphone. Etes-vous préparé à cela ? Avez-vous un plan de reprise d’activité ? Vos salariés peuvent-ils continuer de travailler ? Quel serait l’impact économique d’une telle panne par jour ? Et si la panne durait 2 semaines ?
Posez-vous ces questions. Laissez du temps à vos équipes techniques pour se préparer, répéter et tester (complètement !) différents scénarii de panne, et ceci de manière régulière.
Vous externalisez ? Testez votre prestataire régulièrement. Une fois par an, voire plus en fonction de l’impact d’une panne sur votre activité. Vérifiez également votre contrat pour déterminer ce qui est et ce qui n’est pas couvert. Pour revenir sur l’incendie d’OVH de l’année dernière déjà mentionné plus haut, beaucoup ont appris à leur dépend que les sauvegardes étaient de leur responsabilité, et non de celle de l’hébergeur. Soyez proactif !
Vérifiez aussi les assurances, aussi bien la vôtre que celles de vos prestataires afin d’être sûr d’être bien couvert et de ne pas tomber dans une clause d’exclusion.