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

Après une panne de baie de stockage qui a rendu indisponibles près de 50000 sites web hébergés sur ses infrastructures mutualisées, OVH devra sans doute faire son mea culpa. Mais certains de ses clients devront aussi tirer les leçons de l'incident.

Près de 50 000 sites web hébergés sur la plate-forme mutualisée d’OVH ont été brutalement mis hors ligne la semaine dernière, suite à la défaillance d’une baie EMC VNX utilisée par l’hébergeur sur son datacenter parisien du 19e arrondissement, un datacenter vieux d’une quinzaine d’années et rénové en 2013. La défaillance a causé un arrêt de service massif qui pour certains clients a duré plus d’une journée.

Octave Klaba explique sur le site OVH que la firme a rencontré un incident sur l’une de ses baies VNX5400 le jeudi 29 juin à 18 h 30. Cette baie est l’un des équipements que l’hébergeur utilise encore sur Paris pour stocker une partie des bases de données de son service d’hébergement web mutualisé (réparti principalement entre Paris et le datacenter de Gravelines). 

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...

PRO+

Contenu premium

Accéder à plus de contenu PRO+ ainsi qu'à d'autres offres réservées aux membres.

Approfondir

Participer à la conversation

2 commentaires

M'envoyer une notification dès qu'un autre membre commente.

En soumettant ces informations à LeMagIT.fr, vous acceptez de recevoir des emails de TechTarget et ses partenaires. Si vous résidez hors des Etats-Unis, vous consentez à ce que vos données personnelles soient transférées et traitées aux Etats-Unis. Politique de confidentialité

Merci de créer un identifiant pour pouvoir poster votre commentaire.

Un bon prestataire il y a 10 ans, méconnaissable aujourd'hui avec des tarifs qui n'ont cessé de grimpé et une hotline injoignable la plus part du temps  ! Cela fait bien longtemps que j'ai abandonné OVH, peu fiable.
Annuler

peu fiable, faut voir.. eux ils font ce en quoi ils se sont engagés.

Des pros, ca doit savoir lire un contrat, sinon, c'est quoi ? des clowns? ca serait faire injure aux clowns qui eux sont des professionnels.

maintenant, c'est aux prestataires et aux clients à savoir ce qu'ils veulent. on ne peux pas espérer que tout se déroule parfaitement dans tous les cas avec des sites mutualisés à 6 euros. à 6 euros, c'est un jouet..un site jetable qui doit pouvoir s'effondrer et être remonté en moins d'une demi-heure sur un autre hébergement.

il serait temps d'arrêter d'être rapaces et aveugles à ce point.

si c'est vital pour votre société, vous pouvez bien lui dédier 300 à 500 euros par mois, et ca restera toujours un budget minime par rapport au reste.. et beaucoup de tranquillité en plus, sans parler du responsive d'une solution sur serveur dédié qui envoie la braise comme on dit.

et si c'est vraiment vital pour vous, c'est à vous de faire des sauvegardes régulières et/ou de mettre en place une réplication des données et des sources.

Se reposer uniquement sur l'hébergeur est une absence de solution, car vous ne pouvez être sûr que du pire.

si votre prestataire ne vous propose pas une solution désastre, alors il ne vous propose pas quelque chose de sérieux. dans le cas qui nous intéresse, la solution d'OVH est effective et en rapport avec le prix.

client depuis plus de 10 ans chez ovh, j'ai vu leur gamme évoluer, mes services aussi, et l'adaptation s'est faite naturellement. j'ai connu 2 plantages matériels définitifs (carte mère et disque), mais sur le nombre de serveurs et la durée, c'est pas grand chose, et résolus en moins d'une heure grâce aux sauvegardes que j'effectue en permanence.

mais j'avais lu les contrats, compris ou pouvait se situer le danger et pris les mesures préventives.

moralité?  lisez vos contrats, et comprenez les.

Annuler

- ANNONCES GOOGLE

Close