OVH et ses clients devront tirer les leçons de la panne qui a plongé dans le noir 50 000 sites web

50 000 sites mis KO par la défaillance d’une baie vieille de cinq ans

OVH explique : « sur P19, dans certains cas, nous utilisons les baies de stockage propriétaires d’EMC VNX 5400 avec les disques SSD. Il s’agit d’une solution que nous avons mise en place en 2012 pour pallier les problèmes de performances de stockage que nous avons eu en 2012 sur les bases de données ». L’explication devient ensuite plus brouillonne et fleure bon l’approximation : « Il s’agit d’un ensemble composé de 96 disques SSD configurés en active/active sur plusieurs baies physiques. L’ensemble ne veut plus redémarrer. Nous avons contacté le constructeur et nous essayons de trouver une solution pour récupérer les données hébergés sur cette baie ».

Il est peu probable qu’OVH ait investi dans une solution EMC de réplication pour faire de l’actif/actif entre baies contrairement à ce qu’indique la première phrase. Plus vraisemblablement, les bases de données étaient stockées sur une baie bi-contrôleur en mode actif/actif (sur les baies VNX, les deux contrôleurs sont actifs simultanément, mais chaque LUN n’est contrôlé que par l’un d’entre eux, qui en cède éventuellement le contrôle en cas de défaillance).

C’est ce que semble attester la seconde partie de la phrase (« les données hébergées sur CETTE baie »). En fait, la description que fait OVH de sa panne ressemble fortement à un scénario de défaillance simultanée des deux contrôleurs de la baie (suite à un problème d’alimentation ou de surchauffe par exemple) et non pas à un scénario plus complexe impliquant plusieurs baies répliquées en mode actif/actif (avec une solution de type VPLEX par exemple).

Un domaine de panne sans doute largement sous-estimé par l'hébergeur

On aurait pu imaginer que pour un scénario avec un aussi large domaine de panne, OVH aurait au moins opté pour une solution de réplication asynchrone entre deux baies histoire de disposer d’une copie récente de ses bases (RPO de 15 ou 30 mn). En fait, ce n’était pas le cas, et le fournisseur a dû restaurer ses sauvegardes les plus récentes, avec des RPO allant selon les clients de 1 h à 22 h.

Le plus troublant est qu’OVH admet que la technologie d’EMC n’est pas directement à l’origine de l’incident. « Nos datacentres ne sont pas adaptés pour héberger ce type d’infrastructure », explique ainsi Octave Klaba, s'exposant au passage à des attaques pour non respect de son obligation de moyens. « Seules certaines salles sont spécialement préparées pour ce genre d’hébergement, mais cette baie de stockage n’y a pas été hébergée ce qui est l’origine du problème ». Si l’on résume, l’actif-actif ne l’était sans doute pas vraiment, et la baie était dans une salle machine qui n’était pas adaptée à la recevoir soit pour des questions électriques soit pour des raisons de température. Enfin, la fréquence de sauvegarde des données était de 24 h, un délai plutôt long (alors qu’on aurait pu imaginer un mécanisme de sauvegarde incrémental toutes les heures, par exemple).

Les sauvegardes à la rescousse

Afin de restaurer le service des clients affectés (en plein milieu des soldes), OVH a donc mené deux actions en parallèle. Tout d’abord, la firme a tenté de faire redémarrer la baie EMC défaillante, sans succès, puis a fait venir de Roubaix une baie de secours afin de tenter d’y installer les disques de la baie défectueuse et de la redémarrer avec l’aide d’EMC, avec un succès très relatif. En parallèle, la firme a commencé à restaurer les environnements de bases de données affectés depuis ses sauvegardes.

C’est cette seconde option qui l’a finalement emporté. N’arrivant pas à redémarrer rapidement la baie de stockage VNX 5400, OVH a progressivement restauré l’ensemble des bases de ses clients depuis la dernière sauvegarde, ce qui ne s’est pas fait sans casse. Les backups de cet environnement ne s’effectuant que toutes les 24 h, certains utilisateurs ont perdu jusqu’à 22 h de données.

Tous n'ont pas non plus retrouvé immédiatement l'accès à leurs sites. Dans un premier temps, OVH a activé les bases restaurées en lecture seule afin de permettre à ses clients de récupérer leurs données, avant de se résoudre à les basculer en lecture/écriture pour leur permettre finalement de reprendre leur production, même parfois avec des jeux de données incomplets. La firme a toutefois promis qu’elle donnerait accès aux données manquantes lorsqu’elle sera parvenue à relancer sa baie EMC (à charge alors pour les clients de réintégrer comme ils le pourront les deltas dans leurs applications). Au dernières nouvelles, OVH avait fait des progrès avec sa baie et testait l'intégrité des données.

Des leçons à tirer, pour OVH comme pour certains de ses clients

Si le déroulé des opérations publié par OVH montre que ses équipes n’ont pas démérité face à la crise, plusieurs leçons seront sans doute à tirer de l’incident tant du côté de l’hébergeur et que de celui des clients.

Le premier, sans doute trop confiant dans la technologie, a sous estimé le domaine de faute que représentait sa baie EMC et l’a sans doute insuffisamment protégée. Outre la question de l’inadéquation des conditions d’hébergement de la baie, la mise en œuvre d’une technologie de réplication asynchrone telle que Recoverpoint vers une seconde baie VNX ou VNXe, aurait sans doute permis à l’hébergeur de réduire de façon drastique le RPO par rapport à celui permis par sa solution de backup. Mais OVH y a sans doute renoncé du fait de la faible marge des hébergements mutualisés. A défaut des sauvegardes incrémentales plus fréquentes auraient permis d’abaisser le RPO (perdre une journée de données pour un site e-commerce pendant les soldes n’est pas une nouvelle que l’on apprend de gaité de cœur)

Une autre leçon à tirer de l’incident est sans doute qu’OVH devra mieux préciser les conditions de disponibilité de ses environnements mutualisés. Sur le site web cette information est totalement introuvable. Il faut se plonger dans les conditions contractuelles pour découvrir qu’OVH par contrat ne se donne qu’une obligation de moyens et qu’en cas de panne « il informera, dans la mesure du possible le Client, dans un délai raisonnable, par courrier électronique ou au travers du site http://travaux.ovh.net, d’une éventuelle interruption du service, afin que le Client prenne ses dispositions ».

Du côté des clients, l’aventure a aussi parfois révélé une forte incompréhension de la nature de l’hébergement mutualisé. Sur les forums, on a ainsi vu des clients se plaindre de perdre des milliers d’euros de chiffre d’affaires du fait de la panne. Ces clients devraient dès maintenant se poser la question de savoir si un hébergement vendu entre 1,5 et 6 €, sans aucune garantie de disponibilité de et SLA, était la meilleure option pour leur précieux site d'e-commerce.

Plus étonnant, on a aussi vu des prestataires partenaires d’OVH se plaindre de l’indisponibilité de dizaines de sites, alors que leur métier est d’opérer ses sites dans des conditions optimales pour leurs clients finaux et que ce métier inclut, de recommander la solution technique optimale, ou à défaut, la responsabilité de la sauvegarde régulière de leurs environnements. Une simple lecture de l’article 6 des conditions l’hébergement mutualisé leur aurait permis de découvrir cette recommandation : « OVH recommande au Client de mettre en œuvre une mesure de sauvegarde effectuée par ses soins ».

Bref, c’est l’ensemble des prestataires et clients des prestations low-cost d’hébergement qui viennent de se voir administrer un salutaire rappel à l'ordre et l’on espère que l’événement amènera chacun à réfléchir sur la nature des moyens à mettre en œuvre pour assurer la disponibilité de sites qui sont de plus en plus importants pour l’économie des acteurs qui les opèrent ou les utilisent...