OVH, je t’aime moi non plus

Je m’apprêtais à écrire un article sur l’utilisation que je fais de l’offre Public Cloud d’OVH. Mais ce matin (nous sommes le 29 janvier 2018 au moment où je commence à écrire ces lignes), l’hébergeur rencontre de gros soucis qui empêchent de se connecter à son interface utilisateur, et donc de gérer les machines. Je me suis dit que ça pourrait être une bonne occasion de revenir sur les récents problèmes techniques qui ont entaché la réputation de la licorne française de l’hébergement (la dernière fois que j’en avais parlé, c’était il y a presque 7 ans maintenant).

Pour faire un tour d’horizon un peu complet, je vais remonter au 29 juin 2017, il y a 7 mois exactement. Ce jour-là, OVH subissait une très grosse panne, qualifiée par son président comme étant le «pire incident depuis 2006».

29 juin 2017

Je vous invite à lire le ticket de travaux qui a été écrit par Octave Klaba, ainsi que le post-mortem publié sur le blog d’OVH, qui récapitule ce qu’il s’est passé à ce moment. En résumé, il y a eu une fuite de liquide dans le refroidissement liquide d’un serveur, qui a coulé sur une baie de disque qui s’est éteinte après avoir détecté un problème électrique. Cette baie n’aurait pas dû se trouver à côté d’équipements refroidis par eau. De plus, le système de détection de fuites d’eau n’a pas pu alerter les techniciens, car il avait été mis à jour le même jour, et cette mise-à-jour était boguée ; du coup, les techniciens sont intervenus tardivement.

Ce qui n’est pas dit clairement dans le post-mortem, mais qui était dit dans les premières communications effectuées par OVH ce jour-là (et depuis modifiées), c’est que les techniciens semblaient ne pas avoir conscience du problème hydraulique. Ils ont essayé de redémarrer la baie de disque, et ont incriminé le matériel.

L’impact de ce problème technique est la mise hors ligne d’un très grand nombre de sites web. La baie de disques était utilisée pour le stockage des bases de données de l’offre d’hébergement mutualisé ; sans base de données, la plupart des sites ne sont plus fonctionnels. On parle de cinquante mille sites impactés (cf. cet article sur ZDNet), qui plus est en période de soldes.

En urgence, une baie de secours a été acheminée de Roubaix à Paris pour tenter de réinstaller les disques durs, et en parallèle les sauvegardes quotidiennes ont été restaurées sur un autre système. La deuxième baie n’a semble-t-il pas fonctionné, et la restauration des données a duré jusqu’à la fin du jour suivant.

Au passage, la manière dont OVH a communiqué a été largement critiquée (le post-mortem tente d’expliquer tout ça).

Mon analyse tient en 4 points :
1) Le geste commercial est plutôt symbolique (2 mois d’hébergement offerts aux clients impactés), mais c’est un symbole fort. À 4 euros par mois d’hébergement mutualisé en moyenne, cela fait un réel manque à gagner pour OVH, mais qui reste une goutte d’eau pour une entreprise de cette taille.

2) Les clients qui font tourner leurs sites de e-commerce sur de l’hébergement mutualisé devraient avoir honte et ne pas trop s’étonner de rencontrer des problèmes. Faire tourner leur business sur une offre à 4€/mois sans garantie de service, c’est comme construire une boutique physique avec des murs en carton : on n’est pas stupéfait lorsque ça s’écroule sous la pluie.

3) Un système de monitoring et d’alerte en datacenter qui est mis à jour mais qui n’est pas testé, vérifié, validé ? Vraiment ?

4) Passons sur le fait que la baie n’aurait pas dû rester à côté du refroidissement liquide, ça a été bien expliqué par OVH. Mais les données ont été restaurées sur un système qui a été mis en place en une nuit ? Soit ça veut dire qu’ils auraient pu le faire bien plus tôt, soit ça implique qu’ils ont reconstruit un truc à la va-vite, qui ne respecte pas leur niveau de qualité habituel ; sauf que je crains que les sites mutualisés tournent encore sur ce système « temporaire »… Est-ce que ça pétera encore un de ces jours ?

État des lieux avant l’incident : Une installation temporaire (baie posée à côté de serveurs refroidis par eau) qui a été oubliée en l’état, même si elle n’était pas « au standard ».
État des lieux après l’incident : Une installation réalisée en quatrième vitesse, sans qu’on ait plus d’information sur le fait qu’elle soit « au standard ».

9 novembre 2017

Donc, l’incident de juin était censé être le pire vécu par OVH depuis plus de 10 ans. Manque de chance, 4 mois plus tard a lieu un incident dont l’ampleur est bien plus importante. En fait il s’agissait de deux incidents arrivés en même temps, dans deux datacenters différents. Résultat, il y a pas mal de littérature officielle sur le sujet :

• Le ticket de support qui résume les deux incidents
• Le ticket qui détaille l’incident de Strasbourg
• Le ticket qui détaille l’incident de Roubaix
• L’annonce d’Octave sur Twitter
• Le post-mortem publié le 21 novembre sur le blog d’OVH

À Strasbourg, le câble d’alimentation électrique a été endommagé, et les groupes électrogènes n’ont pas démarré, et donc tous les serveurs se sont éteints. Voilà, c’est aussi simple que ça. Ah oui, il faut savoir que la dernière fois que les groupes électrogènes avaient été testés, c’était au mois de mai. Soit 6 mois auparavant ! Enfin, pour être plus précis, les groupes électrogènes sont (censés être) testés « à vide » tous les mois ; ce qui datait du mois de mai, c’est le test d’alimentation des datacenters par l’alimentation de secours en conditions réelles. Après investigations, il s’avère que l’automate de démarrage des groupes électrogènes était bloqué en position verrouillée ; pas plus d’explication, mais on peut imaginer que cela datait du test du mois de mai (comme quoi il faut tester plus souvent en conditions réelles).

Il faut aussi savoir que la manière dont les datacenters de Strasbourg ont été construits n’est pas « au standard » d’un point de vue électrique. Certains datacenters ont une arrivée électrique simple (non redondée), d’autres encore ont été chaînés (entraînant un effet domino si le premier datacenter de la chaîne rencontre un souci).

À Roubaix, siège historique de l’entreprise qui représente un nœud d’interconnexion majeur, les 6 fibres optiques sont tombées d’un coup. La raison tient du fait que ces fibres sont gérées par deux équipements réseau identiques, qui ont perdu simultanément leurs configurations. Même en expliquant qu’il y a eu une cascade de bugs, démarrée par une surcharge CPU, je pense qu’on ne saura jamais le fin mot réel de l’histoire.

On peut toutefois remarquer qu’OVH avait initié deux semaines auparavant le remplacement des cartes contrôleurs, les nouvelles ayant deux fois plus de puissance CPU et deux fois plus de RAM que celles en place. Cela laisse penser que la surcharge CPU de ces cartes n’était pas un phénomène nouveau. Dans le ticket d’incident en date du 10 novembre, il est écrit «Nous avons reçu les 2 premières hier pour Roubaix»… Donc ils les ont reçues le jour de l’incident ; c’est dommage que ce remplacement n’ait pas eu lieu juste quelques jours plus tôt.

Le souci avec ces deux incidents est qu’en arrivant en même temps, ils ont créé le pire des scénarii. Si vous avez des serveurs dédiés et que vous redoutez qu’une panne survienne dans le datacenter où ils sont hébergés, vous pouvez louer des serveurs dans plusieurs datacenters différents − éventuellement chez plusieurs hébergeurs différents. Mais pour rediriger le trafic, vous allez avoir besoin de pouvoir configurer certaines choses : soit modifier les IP fail-over/load-balancing (dans le cas où vous avez des serveurs dans des datacenters OVH), soit modifier les DNS pour faire pointer sur des serveurs différents (dans le cas où vous passez par des hébergeurs différents).
Le bug ayant affecté Strasbourg a fait tomber des serveurs. Mais celui de Roubaix a rendu indisponible l’interface client d’OVH. Il était alors impossible de modifier la moindre configuration. C’est la double peine : vos serveurs sont HS, mais vous ne pouvez même pas rediriger les requêtes vers d’autres serveurs.

La communication d’OVH est aussi à prendre avec du recul. On nous dit que l’incident de Strasbourg a duré 4 heures, et que celui de Roubaix a duré 2 heures 20 minutes.

Pourtant, si on regarde dans le détail, 9 heures après le début de l’incident de Strasbourg, seuls 71% des serveurs avaient été redémarrés ; au bout de 30 heures, 99% des serveurs étaient redémarrés ; les derniers serveurs ont été redémarrés après 4 jours d’interruption. En effet, ce genre de problème électrique peut faire griller des serveurs, dont certaines parties physiques doivent alors être remplacées.
Et concernant Roubaix, il faut plutôt attendre 6h30 avant que la plate-forme soit complètement stable.

Dans tous les cas, il se pose la même question que pour l’incident du 29 juin : les solutions mises en place sont-elles pérennes ou bien sont-elles juste des bricolages effectués rapidement pour que les services soient en ligne ? Dans le deuxième cas, est-ce que le temps a été pris ensuite pour revenir dessus et tout remettre d’équerre ?

Mon analyse :
Là encore, on voit que la situation résulte de choses connues et anticipables par Ovh. Que ce soit l’installation électrique pas « au standard » à Strasbourg, ou les cartes CPU qui devaient être changées à Roubaix. L’explication tient évidemment au fait qu’il s’agit d’investissements coûteux dans un cas (pour Strasbourg, Octave parle de 4-5 millions d’euros) et délicat dans l’autre cas (on ne touche pas l’équipement réseau d’un nœud aussi important que Roubaix sans quelques précautions).
Mais dans les deux cas, c’était identifié et important. Ils ne l’ont pas fait avant que ça leur pète à la gueule, c’est tout.

6 décembre 2017

Là ce n’est vraiment pas de chance. Suite à l’incident du 9 novembre, ils ont prévu une intervention pour corriger les failles (isolation des équipements réseau en trois groupes séparés, pour qu’un souci ne puisse plus impacter qu’un tiers du trafic dans le pire des cas). Sauf qu’en préparant cette opération de maintenance, tout est retombé de nouveau − de manière identique au 9 novembre.

Les liens d’info :

• Le ticket d’intervention correspondant aux instabilités que cette opération devait corriger
• Le ticket d’incident correspondant au problème et à sa résolution
• L’annonce d’Octave sur Twitter
• Un résumé facile à comprendre sur NextImpact

Le résultat, c’est 4 heures d’interruption de service de nouveau.

On peut se dire que c’est quelque chose qui peut arriver. Rien n’est parfait, on est d’accord. Mais là, ça reste étrange : soit la plate-forme était tellement instable qu’elle menaçait de s’écrouler à tout moment, soit cette intervention aurait dû être menée avec beaucoup plus de précautions. Peut-être qu’il aurait fallu être plus précautionneux, justement parce que la plate-forme était instable.

Est-ce que des équipements réseau identiques avaient été montés en labo, pour répéter l’opération avant de la tenter « pour de vrai » ? On ne le saura jamais. De la même manière qu’on ne sait pas si l’opération a été refaite avec succès depuis…

24 janvier 2017

Dans le datacenter de Gravelines, un onduleur est tombé en panne. L’onduleur se rendant compte de son propre défaut, il laisse passer le courant en se by-passant lui-même. Malheureusement, le souci électrique de cet onduleur était « trop important », ce qui fait que le tableau électrique a arrêté de l’alimenter ; et donc les serveurs qui étaient derrière l’onduleur n’étaient plus alimentés à leur tour.

À lire :

• Le ticket d’incident au sujet de l’onduleur
• Le ticket d’incident sur les serveurs impactés, avec un post-mortem

C’est quelque chose qui peut arriver. Sauf que justement, ce type d’incident devrait être bien géré. Là, 1150 serveurs sont tombés. Le problème s’est déclaré à 23h02 ; plus d’un millier de serveurs avaient été redémarrés à 5h00 du matin (soit une interruption de 6 heures), mais ils ont fini de redémarrer tous les serveurs impactés le lendemain à 19h37 (plus de 20 heures d’interruption). Mais il faut savoir que ces serveurs étaient sans protection électrique par l’onduleur, puisqu’à 21h45 le support indiquait «Nous avons sorti l’UPS7 de l’installation. Nous avons procédé à son remplacement par un modèle neuf. Le nouvel UPS7 va être mis en fonctionnement.»

Là encore, on ne sait pas quand il a été mis en fonctionnement. Mais surtout, on ne sait pas si ce genre d’incident peut se renouveler. Un onduleur qui déconne, encore une fois, ça peut arriver. Mais ça ne devrait pas avoir ce genre d’impact et prendre autant de temps à être corrigé.
Enfin, peut-être que je me trompe.

29 janvier 2018

Et donc, dernier gros incident en date, durant lequel il semblerait qu’un équipement réseau soit tombé en panne à 7h33. Malheureusement, le ticket d’incident est assez cryptique. J’en comprends que c’est un équipement qui travaillait en binôme («L’autre membre du couple p19-94-n6 est toujours fonctionnel») ; mais dans ce cas, pourquoi celui qui n’est pas tombé en panne n’a pas pris correctement la relève ? Est-ce que ces équipements sont sous-dimensionnés au point que même en étant redondés, un élément d’une paire ne peut pas faire le travail de la paire entière ?

Le résultat est que tous les hébergements mutualisés sur Paris sont devenus indisponibles. Mais aussi, l’interface de gestion est devenue indisponible (ainsi que l’API OVH qui permet de gérer les services sans l’interface web), exactement comme lors de l’incident de novembre à Roubaix. Ça devient un peu lourd, d’ailleurs ; que le souci soit à Paris ou à Roubaix, on subit les mêmes effets…

Toujours d’après le ticket, les services étaient de nouveau fonctionnels à 15h45, soit 8 heures d’interruption de service.

Sur cet incident, la communication a été particulièrement mauvaise (en tout cas pour le moment). Le ticket ne dit pas grand-chose, et les échanges sur Twitter se sont révélés très succincts.

D’ailleurs, lorsque des gens ont demandé sur Twitter s’il y aurait des indemnisations, la réponse était «c’est du mutualisé, donc pas de SLA, donc pas d’indemnisation». Je peux comprendre que ça commence à faire beaucoup d’indemnisation pour l’entreprise, mais si l’interruption du mois de juin avait duré 30 heures et entraîné 2 mois d’hébergement gratuit, c’est un peu dur de ne rien donner du tout cette fois-ci en échange d’une interruption de 8 heures.

Le manque de communication sur cet incident (pas de post-mortem notamment, mais on peut croiser les doigts qu’il arrive dans les jours ou semaines à venir) est étonnant et un peu problématique. On ne peut pas banaliser cette perturbation : si les hébergements mutualisés étaient importants en juin, ils le sont toujours aujourd’hui ; et le fait de ne pas pouvoir gérer ses serveurs et ses DNS est assez inadmissible.

Conclusion

C’est bien de soutenir l’innovation et de lever des millions (250 en 2016 et 400 en 2017), mais il faut que la base soit solide sinon tout s’écroule.

Le service DownDetector permet de faire quelques statistiques rapides et perfectibles, mais quand même intéressantes. Si on s’intéresse toujours à cette période de 7 mois comprise entre le 29 juin 2017 et le 29 janvier 2018 (soit 214 jours), on obtient :

• OVH : 34 jours avec des incidents, soit 16%
• AWS : 16 jours avec des incidents, soit 8%
• Salesforce : 6 jours avec des incidents, soit 2,8%
• Microsoft Azure : 3 jours avec des incidents, soit 1,4%
• Rackspace : 3 jours avec des incidents, soit 1,4%

Ça laisse quand même à réfléchir.

On peut remarquer que plusieurs incidents sont le résultat de choses qui auraient dû être anticipées. Et que l’argent économisé en ne lançant pas les chantiers à temps est perdu en devant payer des jets privés pour dépêcher des équipes techniques en urgence (sans parler des coûts humains).

Mais faut-il quitter OVH pour autant ? À chacun de se faire sa propre idée, mais la réponse ne peut évidemment pas être binaire. Pour ma part, j’utilisais déjà OVH et AWS en parallèle, en choisissant les services chez l’un ou chez l’autre en fonction de ce qui me semblait pertinent. Et, comme je l’ai écrit en préambule, je comptais écrire un article au sujet de l’offre Public Cloud que je trouve pas mal du tout.

Pour le moment, ces incidents ne me font pas quitter OVH. Bien sûr, ils me rendent plus attentif, mais les offres restent d’une compétitivité incroyable. On peut se dire qu’il vaut mieux payer plus cher ailleurs pour avoir un service qui ne tombe absolument jamais, mais je n’en suis pas encore là ; les économies restent largement supérieures aux inconvénients. D’un autre côté, si un jour tout tombe en rade pendant une longue durée, je ne tiendrai pas le même discours…

Il est assez amusant de voir que le bilan que je tirais en 2011 reste complètement d’actualité. Il faut de toute façon se préparer à ce que les choses se passent mal, quel que soit l’hébergeur.