La fuite d’un liquide de refroidissement a fait crasher la baie VNX dans le datacentre de l’hébergeur web.
Une fuite de liquide de refroidissement externe a bloqué un réseau Dell EMC VNX dans un centre de données OVH à Paris et a mis plus de 50 000 sites internet hors service pendant 24 heures.
OVH est la troisième plus grande entreprise d’hébergement Internet au monde avec 260 000 serveurs dans 20 centres de données dans 17 pays accueillant quelques 18 millions d’applications Web.
La panne s’est déroulée vers 19 heures dans le centre de données P19 d’OVH le 29 juin. C’était le premier centre de données d’OVH ouvert en 2003. Il a depuis été dépassé en taille par un centre de données Gravelines, le plus grand en Europe, avec une capacité de 400 000 serveurs.
OVH a développé son propre concept de refroidissement liquide, qui est utilisé dans l’installation P19. Il a un fluide de refroidissement circulant à travers le centre des racks de serveur et d’autres composants pour les refroidir via des échangeurs de chaleur à niveau de composants, accrochés à un échangeur de chaleur à bloc d’eau supérieur. L’eau chauffée est ensuite refroidie par échange thermique avec des eaux souterraines. Ce système permet d’économiser de l’électricité en évitant l’utilisation de climatiseurs.
OVH rack liquid cooling
Selon le journal d’incident, le P19 a de l’équipement dans le sous-sol, ce qui rend le refroidissement par l’air extérieur problématique, d’où le développement de refroidissement par eau.
OVH a ensuite acheté plusieurs réseaux VNX 5400 chez EMC. Celui en question avait 96 SSD dans trois châssis, 15 étagères de disque local et la paire de contrôleurs active-active. L’hôte dit : « Cette architecture est conçue pour assurer la disponibilité locale des données et tolérer les pannes des contrôleurs de données et des disques ».
Depuis lors, il a développé l’utilisation de matrices de produits non propriétaires utilisant Ceph et ZFS à Gravelines et le matériel exclusif est migré. Le tableau affecté à Paris, l’un des deux là-bas, n’était pas fait pour ce monde. Les deux agissaient en tant que serveurs de base de données, fournissant les données des pages dynamiques des sites hébergés, des informations relatives aux utilisateurs et des textes d’articles et des commentaires dans le cas d’un blog.
Le compte d’incident indique : « À 18 h 48, le jeudi 29 juin, dans la salle 3 du datacenter P19, en raison d’une fissure sur un tuyau en plastique léger dans notre système de refroidissement par eau, une fuite de liquide de refroidissement provoque l’entrée de fluide dans le système.
« L’une des deux baies de stockage propriétaires (racks) n’a pas été refroidie par cette méthode mais était à proximité. Cela a eu la conséquence directe de la détection d’un défaut électrique conduisant à l’arrêt complet de la baie ».
OVH admet que les avoir installé dans la même pièce que les serveurs refroidis par eau était une erreur. « Nous avons commis une erreur de jugement, car nous devrions avoir donné à ces installations de stockage un niveau de protection maximal, comme c’est le cas dans tous nos sites ».
Erreur sur erreur
Ensuite, la crise a été aggravée par une panne dans le système d’alerte audio. Les sondes capables de détecter un liquide dans un rack diffusent un message audio à travers le centre de données. Mais une mise à jour pour ajouter un support multilingue a échoué et les techniciens ont été alertés de la fuite en retard, arrivant 11 minutes après.
À 18 h 59, ils ont essayé de redémarrer la baie. À 9h25, ils n’avaient pas réussi et ont décidé de continuer à essayer de redémarrer la baie défectueuse (plan A) tout en essayant de restaurer ses données dans un second système en utilisant des sauvegardes (plan B).
Plan A
Le support EMC de Dell a été appelé à 20h et a finalement redémarré la baie, mais il s’est arrêté 20 minutes plus tard quand un mécanisme de sécurité a été déclenché. Ainsi, les techniciens OVH ont décidé de récupérer un troisième VNX 5400 à partir d’un site à Roubaix et de transférer les disques défectueux de la machine dans ce nouveau châssis, en utilisant ses modules d’alimentation et leurs contrôleurs.
Le système de Roubaix est arrivé à 4h30 avec tous les disques du système défectueux déménagés vers 6h du matin. Le système a été déclenché à 7 heures du matin mais, catastrophe, les données sur les disques étaient encore inaccessibles. Le support EMC Dell a été recontacté à 8 heures du matin et une visite sur place a été organisée.
Plan B
Une sauvegarde quotidienne a été la ressource utilisée comme Plan B, OVH notant : « Il s’agit d’une sauvegarde d’infrastructure globale, réalisée dans le cadre de notre plan de récupération d’entreprise, et non les instantanés des bases de données auxquelles nos clients ont accès dans leur espace client.
« La restauration des données ne signifie pas seulement la migration des données de sauvegarde du stockage froid vers un espace libre de la plate-forme technique d’hébergement partagé. Il s’agit de recréer l’environnement de production entier ».
Cela signifiait qu’il était nécessaire, pour restaurer les données, de :
- Trouvez l’espace disponible sur les serveurs existants à P19
- Migrer un environnement complet de services de support (machines virtuelles exécutant les bases de données, leurs systèmes d’exploitation, leurs packages et configurations spécifiques)
- Migrer des données vers la nouvelle infrastructure hôte
Ce processus a été testé en principe mais pas à une échelle de 50,000 sites. Une procédure a été scannée et, à 3 heures du matin, le clonage VM à partir d’un modèle source a commencé.
À 9 heures du matin, 20% des cas ont été recouvrés. Les heures sont passées et « à 23h40, la restauration de la [dernière] instance se termine et tous les utilisateurs trouvent un site fonctionnel, à l’exception de quelques utilisateurs dont la base de données a été hébergée sur des instances MySQL 5.1 et a été restaurée sous MySQL 5.5 ».
Avec du recul
Il était évident que les procédures désastreuses de récupération après sinistre pour le réseau affecté étaient insuffisantes et, dans les circonstances, le personnel de support technique d’OVH a fait un travail héroïque mais n’aurait pas dû avoir à le faire.
Le tableau VNX était dans la mauvaise pièce mais, même avec tout ça, les arrangements de basculement étaient inexistants. La planification et les tests DR actifs n’étaient pas à la hauteur du travail.
La communication avec les utilisateurs concernés a été critiquée et OVH l’a pris en plein visage. « Au sujet de la confusion qui a entouré l’origine de l’incident – c’est-à-dire une fuite de liquide de refroidissement de notre système de refroidissement par eau – nous faisons notre mea culpa ».
Et qu’avons-nous appris ?
- Ne mélangez pas les réseaux de stockage et l’eau
- Effectuez une planification complète de DR et testez tous les composants critiques du système
- Répétez régulièrement à mesure que les composants du système changent
- Ne mettez pas à jour les composants critiques du système, sauf si la procédure de mise à jour a été testée à l’épreuve des balles
®
Via The Register
