Mon expérience de l’incendie OVH, ce que j’en ai tiré comme leçons

Cet article a été publié il y a 3 ans 16 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Je pensais que vu le caractère exceptionnel et les impacts, ça aurait dépassé la sphère du monde de l’informatique. Mais non, l’incendie important qui a touché OVH, premier hébergeur d’Europe, et paralysé plusieurs milliers de clients, est finalement resté sous le radar du grand public. J’ai fait partie des victimes, et j’avais envie de vous partager un peu mon ressenti pendant ces deux semaines compliquées. Et comment je compte m’adapter.

Vous ne verrez pas ici de grosse critique de ma part sur la situation, hébergeur n’est pas mon métier, et je n’ai pas assez de connaissances concernant les normes d’infrastructures informatiques pour donner des leçons. En dehors même des vrais reproches qu’on pourrait faire à OVH, aussi bien sur des problèmes passés qu’actuels, j’en ai beaucoup plus à propos des réactions des clients, mais je vais tenter de me retenir aussi. La communication d’OVH pourrait aussi en prendre pour son grade, hein.

Petit descriptif chronologique

Donc pour rappel, au petit matin du 10 mars dernier, un important incendie a débuté dans l’un des datacenters d’OVH, au petit nom d’SBG2, entrainant la perte complète du datacenter en question, et donc tout ce qu’il contenait de machines, de réseau, de stockage : VPS, serveurs dédiés, clusters VMware, datastores, et quelques backups, tout y passe. La proximité avec les autres datacenters faut que le voisin historique, SBG1, a pris aussi une bonne claque dans la gueule, avec à ce moment-là la perte confirmée de 4 « salles » sur les 12 qui le constituaient. Je met « salle » entre guillemets car la construction d’SBG1 reposait sur un concept maison, sous forme de container maritime, une salle = un container. Je vais pas m’étendre trop sur le sujet, à savoir qu’au final sur le site de Strasbourg, il y a actuellement 5 « DC », et qu’ils ont coupé électriquement les SBG1 à 4 par sécurité pendant tout ce bordel.

Je découvre ça le matin à 6h30, les pompiers sont eux en train de se battre courageusement contre le feu, et je me demande où était le serveur dédié. De son côté, mon LibreNMS m’inonde de messages sur Telegram pour me dire que tout est HS. Je colle une bonne grosse maintenance pour lui couper la chique et me concentrer effectivement sur le serveur. Où était-il ? En effet, il remonte à 2013, on l’a récupéré courant 2014, et j’avoue que jusque là, à part savoir qu’il était géographiquement à Strasbourg, et que ça avait impacté négativement le ping sur les serveurs Call of Duty, ça n’avait jamais plus intéressé. À ce moment-là, les clients ne sont pas tous réveillés, donc je peux encore accéder au manager OVH et voir que le serveur serait à SBG4. Donc, en l’état le serveur ne serait que éteint. Je suis pas forcément super rassuré, vu l’âge du machin, on est pas à l’abri qu’il ne redémarre pas, mais au moins il n’a pas fondu. J’attaque donc ma journée de boulot moins inquiet que prévu.

Dans une certaine mesure seulement, nous gérons quelques infrastructures hébergées par OVH pour des clients, et on est salement touché : une plateforme mutualisée qui contenait une centaine de machines virtuelles est partie en fumée, une autre dédiée à un client a sauté aussi, au total, bref, une vingtaine de clients se sont retrouvés la tête dans la fumée. Nos services managers se retrouvent à jongler avec leur(s) téléphone(s) toute la journée, et deux semaines après, certains sont encore particulièrement en difficulté, mais ce n’est pas le sujet ici. De mon côté, je surveille surtout les annonces notamment d’Octave Klaba, le patron d’OVH, qui pour l’anecdote est mon deuxième abonné Twitter lors de mon inscription en 2012. On a donc confirmation de la destruction complète d’SBG2, partielle sur SBG1, SBG3 a été épargné, le 4 qui est derrière le 3 aussi. Tout ce petit monde est en coupure de sécurité. Le feu est maitrisé dans la journée, les premiers constats commencent avec le retour des employés sur site, l’inventaire commence pour trouver des solutions aux clients. De mon côté, on m’annonce un rallumage à partir du 15, une fois l’électricité remise en place et le réseau contrôlé. Je met un message sur Twitter qui a dû en faire sourire plus d’un.

Donc pour info, le #blog est HS suite à la coupure électrique sur #OVH #SBG . Comme je suis un gros flemmard et que le rallumage est prévu pour lundi prochain, j'attendrais jusque là. Pendant ce temps-là, je vais préparer le nouveau serveur que je dois faire depuis six mois 🙂

— Seboss666 (@Seboss666) March 10, 2021

Si vous avez déroulé le fil Twitter en question, vous avez la suite, mais bon, je résume : le serveur est rallumé le 18 mars au soir vers 22h, mais je ne reçois pas le mail avec les infos du mode rescue. C’est une particularité d’OVH, et une première bêtise de ma part, le contact utilisé pour envoyer le mail est le contact technique. Celui-ci est différent du contact administrateur. Sauf que la boite mail que le contact technique utilise… est normalement hébergée sur le serveur dans une machine virtuelle dédiée. Qui est donc éteinte. Donc pas d’infos. Et pour accéder au manager OVH avec ce compte et consulter la copie du mail envoyé, il faut rentrer un second facteur… envoyé par mail aussi. L’ouvre boite dans la boite, c’est génial 😀 Je ne percute pas tout de suite, je suis claqué, je vais me coucher pour réfléchir aux solutions le lendemain matin. Et donc, vendredi matin, je tente avec ce que je connais déjà comme info (la clé SSH enregistrée sur le compte technique), et j’accède donc au mode rescue permettant de procéder au diagnostic, à savoir vérifier l’état du RAID, des systèmes de fichiers, pour écarter tout risque de corruption de données. Bref, tout à l’air OK, et on redémarre sur les disques. Je passe sur quelques difficultés de certains services à redémarrer, je les relance à la main, le blog est de retour, youpi, je bip sur Twitter et je retournes bosser. Je suis quand même content de retrouver mon FreshRSS pour pouvoir reprendre ma veille (et mes abonnements YouTube).

Le soir, je continue à dépiler les quelques 800+ entrées, et d’un coup sans prévenir, plus rien ne répond. Mon premier réflexe, une fois ma connexion vérifiée, c’est que le serveur a dû crash; encore une fois, il n’est plus tout jeune. Je demande confirmation à Arowan, qui n’accède plus non plus, pour découvrir moins de 10 minutes plus tard, un nouveau message d’Octave, qui annonce avoir recoupé SBG1 et SBG4 pour vérification. Un peu plus tard, on apprend que c’est un deuxième départ de feu, sur un jeu de batteries d’onduleur, qui a du être maîtrisé très vite. Mais sur SBG1, qui pour rappel, avait déjà pris une bonne sauce avec le premier feu. Je termine la soirée sur un message encourageant indiquant un potentiel redémarrage le lendemain dans l’après-midi.

Samedi matin, apparemment c’est plus grave que prévu : il est décidé d’abandonner SBG1, de déménager une partie des machines sur SBG3, ou carrément Roubaix, soit plusieurs centaines de kilomètres entre les deux. De reconstruire l’électricité de SBG4 from scratch, et de remplacer le réseau présent dans SBG1 par une nouvelle installation dans SBG5. Les dégâts sont donc plus importants que prévus. Et tout ça repousse le redémarrage effectif de SBG4 au 24 mars. Je reviendrai dessus tout à l’heure, mais comme j’ai plus que jamais besoin de mes flux RSS, je m’attaque à l’accès à mes sauvegardes au moins pour celui-là, et ça prendra un peu de temps. Je met à jour le fil Twitter concernant le blog. En fin de journée, j’ai récupéré mon FreshRSS via une stack lamp déployée avec docker-compose sur mon laptop, et il reste encore 250 flux RSS à vraiment lire/visionner.

Fast-forward parce qu’il n’y a pas grand chose à dire entre temps, une mise à jour indique un redémarrage des serveurs le 25 mars, et finalement c’est le bien 24 mars dans la soirée. J’ai encore le souci de services qui ont du mal à cause de lenteurs disque, mais je remet tout en ligne, et depuis, tout va bien.

Le gros problème : les sauvegardes

On va rentrer un peu dans le détail technique, sans pour autant rentrer dans le très dur. Ma machine est donc un serveur dédié, ce qui s’appelle maintenant « bare metal » dans le catalogue d’OVH, à savoir, un vrai « PC » pour moi tout seul. Le service associé comprend un espace de backup de 500Go, sachant que le serveur a une capacité de 2To. Ouais, faut faire des choix, ceci dit il existe des options (payantes et pas qu’un peu) pour augmenter cet espace. La particularité et l’intérêt de cet espace, c’est qu’il est géographiquement loin : serveur à Strasbourg, backup à Roubaix. Il y a cependant plusieurs inconvénients, dont certains ont eu des conséquences sur mon usage réel de cet espace, et sur son accès. Le premier, c’est sa performance : c’est tout simplement une catastrophe. Les débits sont infernalement bas. Au départ, j’ai tenté de plugger directement les backups de Proxmox dessus, mais les taux de transferts étant anémiques (on parle d’1Mo/s, voire moins), ça prenait plusieurs heures même pour une petite machine. J’ai donc laissé tomber cette approche, et me suis concentré sur une sauvegarde « fichiers » des principaux sites webs de la machine vox, via backup-manager. Et au final, je n’ai pas fait grand chose de plus en termes de backup, ce qui n’est pas la meilleure chose, puisqu’il y a aussi sur ce serveur, une machine virtuelle « pare-feu » dont la configuration n’était pas sauvegardée, un machine virtuelle « mail » (celle que j’ai évoqué, qui contient les mails pour réparer le serveur…), une machine virtuelle contenant plusieurs serveurs de jeu Call of Duty, Minecraft, une machine Windows que je venais de remonter pour un ami qui voulait un serveur Hurtworld (parce que monsieur connait pas Linux…), bref, beaucoup de monde qui était sans filet.

Chat = données, panier = backup storage

Quand bien même j’aurais pu sauvegarder tout ce beau monde, il reste l’accès à ces sauvegardes. OVH a une approche conservatrice, à savoir que via le manager, seules les adresses IP associées au serveur peuvent être autorisées à accéder à l’espace backup. Sauf que toutes les IPs étant sur le serveur qui était éteint, j’étais coincé. La première solution apportée par OVH, c’est de commander une autre machine, de « déplacer » une des IPs failover sur cette nouvelle machine, et hop, on a accès au backup. Oui mais non, c’est pas au programme, les machines chez OVH ont doublé de tarif depuis, c’est aussi pour ça que le serveur a huit ans. Sans parler qu’on a un historique peu glorieux en matière de fiabilité de déplacement d’IP entre serveur, et en ce moment le support technique a d’autres chats à fouetter. La deuxième solution qui a failli être bien sauf pour les humains, c’est l’utilisation de l’API pour ajouter une IP autre que celles du service. L’espoir d’accéder directement aux backups depuis chez moi a cependant été vite douché par une petite mise à jour de la documentation spécifiant que l’adresse IP doit être celle d’un service OVH. Le lot de consolation donc que cette IP n’a pas besoin d’être déplacée d’un serveur à un autre, ni qu’on doit prendre un truc de la mort, un simple VPS à 3€ par mois suffit. Ça tombe bien, le LibreNMS est sur un VPS OVH, je l’ajoute donc via l’API (en vrai, via l’interface web c’est assez facile), et quelques minutes plus tard, j’ai enfin accès à l’espace backup, et je peux récupérer mes backups, les derniers datant du 9 au soir, soit juste avant le début de l’incendie.

Et je m’en suis sorti comme ça en attendant le rallumage. Mais le fait est que si j’avais été encore plus négligeant, ou que le serveur avait été détruit, j’aurais tout perdu (ce qui était arrivé à Nicolargo par exemple).

Quels sont les constats de toute cette histoire ?

Déjà, que je suis chanceux : ma machine n’a pas été détruite ou endommagée par l’incendie, alors que certains ont tout perdu. Pour le dire rapidement, certains avaient leurs sauvegardes physiquement proche de leurs machines, et tout à été détruit en même temps. La recommandation est d’avoir son backup géographiquement éloigné, sauf que la plupart du temps, l’option coûte vite assez cher : le Backup as a Service des offres Private Cloud fait un x3 sur le tarif quand on veut que les backups soient stockés à Roubaix quand le cluster est à Strasbourg. Et ceux qui laissent volontairement tout backup de côté pour gratter quelques euros vont maintenant payer beaucoup plus cher d’avoir tout perdu (j’avais dit que les clients allaient prendre un taquet ?).

À Copier 200 fois

Ensuite, que ma politique de sauvegarde est salement incomplète : je l’ai dit, j’avais carrément laissé tomber certaines machines virtuelles, mais ce que j’ai également constaté en fouillant dans les backups disponibles, c’est que si je sauvegarde les fichiers et les bases de données des sites web, je n’ai rien gardé des configurations de Nginx ni de PHP que j’ai utilisé pour les différents sites. Donc même avec les fichiers, il me manque certains éléments pour remonter à l’identique, en tout cas dans une configuration la plus proche possible, un environnement d’exécution pour les sites. Je n’avais non plus aucune méthode sur le moment pour accéder à l’espace de backup avant qu’OVH finisse par communiquer dessus. Je suis donc resté plusieurs jours sans pouvoir restaurer certains éléments même de manière temporaire (mes flux RSS) le temps de rétablir le service. Au passage, le VPS n’est sauvegardé nulle part, et je l’ai appris avec douleur lors d’une mauvaise manipulation qui a supprimé beaucoup plus de fichiers que prévu sur le site web de mon équipe. Ce VPS étant à Gravelines, il est déjà géographiquement à part du serveur, ce qui était justement un des buts recherchés.

Pour discuter en dehors de ma situation, j’ai vu quantité de messages et d’articles sur le sujet. On se croirait dans la situation de la pandémie, avec un épidémiologiste derrière chaque compte Twitter, et une cohorte de cerveaux lavés aux discours des « cloud providers » américains qui pensent qu’OVH faisait gratuitement plusieurs copies géographiques de toutes les données de tous les services de tous les clients. La même réflexion qu’on avait pu voir quand des clients mutualisés avaient souffert lors de la perte du SAN mutu-pro deux ans auparavant, suite à une fuite de watercooling. Des boutiques en ligne, donc une activité commerciale, hébergées sur des offres à 3€, aux garanties et services très faibles donc, et qui demandent des comptes à l’hébergeur… Je pratique AWS, GCP et Azure au quotidien, et s’il est certainement plus facile de mettre en place des gardes-fous, sauvegardes, réplications multi-zones/régions, rien n’est automatique ou presque, et surtout, rien n’est gratuit. Une instance CloudSQL (Database as a Service), en haute disponibilité, ben ça vous coûte deux fois plus cher que sans la haute disponibilité. Mais si à la main c’est chiant à faire, là, vous cochez une case et tout est fait pour vous. Et la case n’est pas cochée par défaut. Donc tous ceux qui se plaignent sont ceux qui ne veulent pas sortir leur portefeuille pour fiabiliser leur activité.

Et avec tous les clients qui ont vu passer l’incident et qui nous font chier sur l’absence de DRP/PRA (parce qu’à un moment donné il faut le dire), on leur rappelle que la facture serait deux à trois fois plus élevée s’ils en voulaient. Et dans la quasi-totalité des cas, ça se finit en « ouais finalement on va rester comme ça, à la limite si les backups pouvaient être multi-zones ? ». Et allez pas croire que même les plus grosses structures sortent les moyens plus facilement, c’est même souvent l’inverse.

Qu’est-ce que je prévois de faire pour éviter les futurs problèmes, et surtout m’en remettre plus facilement ?

J’ai déjà modifié la configuration de backup-manager pour inclure PHP et Nginx, en plus des fichiers et bases de données. Pour le reste, je n’ai pas prévu de pousser beaucoup plus dans l’immédiat, pour la bonne et simple raison que j’avais déjà prévu, mais je vais accélérer, le déménagement de tout ce bazar vers une installation plus récente, et surtout, pas chez OVH : comme je l’ai dit, je n’ai pas envie de rester chez eux pour ce besoin-là en particulier parce que l’offre n’est plus intéressante. La gamme OVH est devenu inintéressante techniquement (Intel Only), notamment dans les gammes de prix que je vise, un remplaçant actuel me coûterait presque deux fois plus cher. La gamme « SYS » utilise du matériel qui la plupart du temps date de l’époque de mon serveur actuel, donc niet. Et l’offre Scaleway actuelle ne m’attire absolument pas.

Celui qui m’a fait de l’œil et que j’ai sélectionné, c’est Hetzner. La petite pousse allemande propose des gammes Intel et surtout AMD dans des prix beaucoup plus intéressants par rapport à OVH pour la prestation proposée. Les Storage Box sont beaucoup plus souples à utiliser que le Backup Storage fourni chez OVH, je m’oriente donc vers un serveur en Allemagne et une Storage box en Finlande. Et au final, je ne vais pas détruire mon budget. Il est prévu de copier certaines machines virtuelles en l’état, et d’en refaire de zéro (celle du blog va enfin passer sur Debian 10, ou 11 en fonction du plus rapide à se bouger le fion :D). Les fichiers du VPS seront aussi sauvegardés sur cette Storage Box. Et je vais remettre en service comme il faut les backups des VMs. Les refaire de zéro permet aussi de remettre à plat leur stockage. Cerise sur le gâteau, on vise une installation full firewallé via pfSense, et la mise en place de l’IPv6. Un programme ambitieux donc 🙂

Et pour les autres clients d’OVH ?

Chacun sa merde ? 😀 Plus sérieusement, je ne peux réellement parler que des projets de nos clients. Certains n’ont pas de données stockées sur les infras détruites, et sont en capacité de redéployer leur application n’importe où : on a donc reconstruit des machines from scratch dans l’urgence ailleurs pour qu’ils redéploient leur application et fassent pointer leur domaine dessus. Pour les autres, c’est plus délicat : dans le cadre des Private Cloud, si les sauvegardes sont intactes, on n’a plus qu’à remonter un cluster from scratch pour qu’OVH procède aux restaurations. Une petite reconfiguration réseau plus tard, et les machines pourront revenir en ligne. Pour les sauvegardes perdues, le dernier espoir est une sauvegarde interne des datastores effectués par OVH. Mais ces sauvegardes ont peut-être été détruites aussi en fonction de leur emplacement. N’étant pas au cœur de l’action dans les équipes concernées, je n’en dirai pas plus, surtout que ces opérations peuvent prendre du temps, et les équipes d’OVH travaillent d’arrache-pied pour les milliers de clients touchés. Je leur tire mon chapeau dans tous les cas pour le boulot qu’ils abattent depuis un mois pour remettre tout le monde sur pied d’une manière ou d’une autre.

Là encore, dans les enseignements qu’on va en tirer, je pense qu’on aura pas trop le choix que de payer plus cher pour avoir un système de sauvegarde plus solide. Le problème, et je parlais de la communication chez OVH, c’est qu’historiquement, le Backup as a Service n’avait qu’une seule option pour un seul prix. Quand ils ont fait évoluer le service pour ajouter les options géographiques, personne ne l’a su et on a pas adapté la stratégie en amont. On en paie donc les conséquences aujourd’hui. Certains clients vont nous demander de quitter OVH, sauf que ça leur coûtera inévitablement plus cher. D’autres nous feront payer des pénalités parce que notre métier est de garantir la disponibilité et l’intégrité de leur plateforme. De notre côté, il est certain qu’une fois la tension retombée, la bataille sera contractuelle et juridique pour réclamer les dédommagements de rigueur à OVH.

De mon côté, je vais accepter le fameux mois offert de compensation, et pendant ce temps-là, je vais préparer la nouvelle infra. Je ne garderai que le VPS, et je cherche encore un système de stockage pas cher pour gérer une bouée de secours pour les backups de VMs les plus lourdes, qui ne tiendrons pas sur la Storage Box (sauf à la prendre beaucoup plus grosse, mais ça coûte beaucoup plus cher). Bref, tout est bien qui finit bien.