Une baie de stockage regroupant une partie des bases de données des serveurs mutualisés d'OVH est en panne, entrainant dans son sillage de nombreux sites. L'hébergeur a restauré une sauvegarde, ce qui n'est pas sans conséquence pour certains clients qui ont perdu des données dans l'histoire.
Mercredi, 8h précise, c'était le coup d'envoi des soldes, une période commerciale importante pour de nombreuses boutiques qui peuvent alors écouler leurs stocks et revendre à perte si elles le souhaitent. Un lancement qui a tourné au vinaigre pour certains, à cause d'une panne d'ampleur sur l'offre d'hébergement mutualisé d'OVH.
Mutualisés : le datacenter de Paris victime d'une importante panne sur certaines BDD
Ils sont actuellement plus de trois millions de sites web à utiliser ce service, répartis sur deux datacenters : Paris (P19) et Gravelines (GRA1). Dans la majorité des cas, le Roubaisien affirme utiliser une technologie maison pour le stockage, combinée à des solutions propriétaires dans le cas de P19. Et c'est justement une de ces dernières qui pose problème.
« Le jeudi 29 juin à 18h30, nous avons eu un incident sur l'une de baies de stockage EMC VNX 5400 que nous utilisons pour stocker une partie de bases de données de l'hébergement mutualisé à P19 » explique Octave Klaba, qui a repris son poste de directeur général en mars.
L'ensemble comprend 96 SSD sur plusieurs baies physiques configurées en mode active-active, ce qui signifie que si l'une des deux flanches, la seconde assure la continuité du service. « On a eu le souci sur les deux baies physiques. le cas qui n'arrive jamais » affirme Octave Klaba sur Twitter. C'est « notre faute » ajoute-t-il au passage... mais la situation n'a pas toujours été aussi simple, notamment lors des premières heures de l'incident.
OVH blanchit Dell/EMC, son infrastructure mise en cause
Dans la première version de ce ticket d'incident technique, il était simplement précisé que « l'ensemble ne veut plus redémarrer » et que le fabricant, EMC, avait été contacté afin de tenter de trouver une solution. Depuis, un paragraphe a été ajouté et il précise que « la technologie d'EMC n'est pas à l'origine de l'incident ».
Le directeur général déclare que les datacentres d'OVH « ne sont pas adaptés pour héberger ce type d'infrastructure. 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 ». Nous n'aurons par contre pas plus de précisions sur les salles utilisées, ni sur les causes de l'incident. Contacté, OVH n'a pour le moment pas souhaité nous apporter de détails supplémentaires.
De son côté, Dell/EMC nous indique que cet ajout mettant hors de cause sa baie VNX 5400, « c'est OVH qui l'a fait de son propre chef ». La société nous affirme aussi avoir découvert « le démenti » ce week-end lors de la mise à jour du ticket d'incident par l'hébergeur roubaisien.
Une fuite d'eau pourrait être l'origine de la panne
Par contre, OVH ne s'étend pas vraiment sur les causes de cette défaillance. Octave Klaba explique simplement qu'il s'agit d'une « panne sur des composants de stockage nécessaires au bon fonctionnement du système ». Si l'on en croit certains (ici et là par exemple), l'hébergeur aurait été victime d'une fuite d'eau, mais cette mention aurait disparu de cet autre ticket d'incident.
Si c'est le cas, rappelons que ce ne serait pas la première fois qu'un problème du genre arrive. En septembre 2014, Octave Klaba donnait des détails sur un incident à Strasbourg : « Un module de climatisation dans la salle 5.1 est tombé en panne. Suite à cette panne, il a produit un peu d'eau qui a goutté sur deux baies. Le switch p19-63 et p19-64 sont hébergés dans deux baies différentes, mais sous ce même module de la clim. D'où la panne malgré les redondances mises en place ».
Restauration d'une sauvegarde, avec un décalage temporel et...
Dans tous les cas, OVH a mis en place deux actions distinctes le jeudi 29 juin au soir : essayer de redémarrer la baie de stockage afin de récupérer les données, restaurer une sauvegarde. Une opération fastidieuse et longue puisqu'elle s'est terminée le 30 juin à 23h44. Au total, 97 serveurs de base de données ont été remis sur pied, chacun pouvant être exploité par de nombreux sites web.
Problème, les sauvegardes des bases de données n'ont lieu qu'une fois par jour, sur d'autres systèmes de stockage dans un datacenter à Roubaix. Fatalement, cela entraine une différence entre les données qui ont été perdues et celles remises en place. OVH annonce une différence oscillant entre « minimum 1h et maximum 22h ». Un délai à la fois court et long, surtout en période de soldes pour certains.
Pour le moment, nous ne savons toujours pas si les données de la baie EMC ont pu être récupérées, la dernière mise à jour du ticket des travaux indiquant seulement que les équipes restent mobilisées et qu'elles tiendront informé « de l'état d'avancement de la restauration des données de la baie de stockage ».
Sur Twitter, le compte officiel du support n'était pas en mesure de donner plus de précisions aux clients, qui demandaient notamment s'il y avait un risque d'écrasement si les données de la baie EMC parvenaient à être récupérées :
Navré mais je n'ai pas encore de confirmation à t'apporter. Désolé. ^GuiF
— OVH Support FR (@ovh_support_fr) 3 juillet 2017
... une possible incohérence dans le nom des BDD
Une mauvaise nouvelle n'arrivant jamais seule, la restauration de la base de données entraine pour certains un changement dans la configuration. En effet, les mutualisés d'OVH sont passés de MySQL 5.1 à 5.5 il y a « quelques mois » et le nom des bases de données a évolué de « mysql51-* » vers « mysql55-* ». Une liste de correspondance entre les 5.1 et les 5.5 est disponible par ici. OVH recommande la solution suivante en cas de problème :
Si vous utilisez un serveur dans votre fichier de configuration nommé "sql**-**.**", vous devez le remplacer par le host "classique" à savoir NomDeLaBase.mysql.db. Le nom de host adéquat est disponible dans votre espace client rubrique "Hébergements" onglet "Base de données" puis colonne "Adresse du serveur".
De la transparence, mais pas trop
OVH fait amende honorable et essaie de jouer la carte de la transparence... bien que cela soulève des questions quant aux changements apportés discrètement sur les différents tickets d'incidents. Une transparence qui se limite d'ailleurs à la communication d'Octave Klaba puisque l'hébergeur n'a pas souhaité répondre à nos questions.
Le directeur général affirme que la « dernière panne de cette ampleur date de 2006 » et elle avait conduit à une remise en question des technologies de stockage utilisées à l'époque. Il ajoute qu'il en tirera les conclusions qui s'imposent et qu'il mettra en place des changements pour éviter que cela ne se reproduise. Lesquels ? Ce n'est pas précisé...
