Victime d’un incendie dans la nuit du 9 mars,  un datacenter d’OVH a subi de lourdes pertes . Ne faisant heureusement aucun blessé physique, l’accident a néanmoins provoqu é la perte totale du datacenter SBG2 et une partie de SBG1 (quatre salles serveurs). 

Grâce à l’intervention des pompiers, les deux autres datacenters, SBG3 et 4 ont pu être sauvés, a affirmé Octave Klaba, PDG d’OVHCloud sur  Twitter . Ce dernier a d’ailleurs récemment publié une  vidéo pour faire un état des lieux de la situation . 

Malgré tout, pour maîtriser l’incendie, une coupure de courant totale n’a pas pu être évitée. Ainsi ce sont 3,6 millions de sites web, représentant 464 000 noms de domaines distincts qui se sont retrouvés  hors ligne.  

Organiser la résilience de son système d’information est primordial dès lors que l’on construit un projet. Pour être sûr de ne pas perdre ses données et de voir son site fonctionner malgré certains aléas, l’architecture et le choix de disponibilités des machines doit être réfléchi en amont. Comment faire pour rendre son SI plus résilient ? C’est la question à laquelle nous allons essayer de répondre ! Face à cet événement,  Célyne Courmont , a essayé de comprendre l’impact depuis sa fenêtre de néophyte. En se basant sur des expériences propres à Agaetis et sur l’exemple de l’incendie d’OVH,  Pierre Pironin  nous éclaire sur le fonctionnement des datacenter et sur l’importance de son architecture ainsi que des Disaster Recovery Plan.  Cédric Lamouche  nous explique également la considération qu’il faut apporter à la lecture et la compréhension des contrats. 

Prenons l’exemple de Kubernetes, qui est la plateforme permettant d’automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d’application sur des clusters de serveurs,  que nous utilisons le plus chez nos clients . 

Kubernetes est hébergé sur des machines virtuelles (VM) sur des serveurs chez un cloud provider (prenons ici l’exemple d’Azure mais le cas serait tout à fait similaire sur OVH). Un cluster Kubernetes est composé de plusieurs VM et donc de plusieurs serveurs. 

Une des façons de provisionner du Kubernetes dans Azure est d’adopter un modèle Infrastructure as a Service (IaaS), c’est à dire qu’Azure fournit des briques d’infrastructures comme des VM, du réseau, du stockage… 

Toutes ces briques d’infrastructure ont un Service Level Agreement (SLA) ou Service Le vel Objectives (SLO) qui correspond au temps de disponibilité ou d’indisponibilité des briques de l’infrastructure garantie par Azure. 

Plus le SLA est haut, plus la qualité de service est bonne car cela signifie que le temps de service sera le plus élevé possible (pas d’interruption ou le moins possible). Ainsi pour créer des architectures résilientes, on vise un haut niveau de SLA sur les briques d’infrastructure.

Les salles serveurs des datacenters sont remplis d’armoires contenant des racks dans lesquels se trouvent des serveurs physiques qui font fonctionner les machines virtuelles (VM) La VM fonctionne donc dans une armoire de serveur, se trouvant dans un bâtiment. Si ce bâtiment brûle (ou qu’un autre type d’incident se produit) et qu’il n’y avait qu’une machine virtuelle pour héberger la plateforme, toutes les données sont perdues et la SLA descend logiquement à 0, le temps de disponibilité des machines étant nul. 

Pour se prémunir de ce genre d’incidents, les datacenters tels que Strasbourg pour OVH ou encore Amsterdam pour Azure, vont être organisés en zones (SBG1-4 pour OVH par exemple). Nous retrouvons sur un site plusieurs édifices distincts, ayant leur propre alimentation électrique, ventilation, coupe feu… Ces structures sont normalement assez isolées les unes des autres. Ainsi si un problème survient dans un bâtiment, les autres peuvent continuer de fonctionner (hors cas exceptionnels comme l’incendie d’OVH).

Lorsque l’on travaille sur du Kubernetes, on peut par exemple investir dans trois VM au lieu d’une. Kubernetes va lui-même se charger de répartir les tâches de travail sur les 3 machines virtuelles et chacune de ces machines sera placée dans des bâtiments différents. Ainsi, si un problème survient dans un des datacenter, une VM peut se retrouver inexploitable à un moment donné mais les deux autres prendront le relais. Kubernetes y dispatchera toute la charge de travail et continuera de faire fonctionner le tout. Ce sont les zones d’un datacenter. 

Pour Pierre Pironin, spécialiste cloud chez Agaetis, le plus gros problème survenu à OVH, c’est que tous les projets étant hébergés dans le datacenter qui a brûlé et n’ayant pas été répartis sur plusieurs zones ont perdu toutes leurs données. La seule solution est alors d’aller chercher des backups sauvegardés ailleurs (dans un autre cloud ou un autre datacenter par exemple) pour les restaurer. 

L’intérêt de ces différentes zones est également de pouvoir appréhender des bugs. Par exemple, lorsque Azure fait des modifications de son infrastructure, ils s’assurent de ne pas le faire sur toutes les zones en même temps. Ainsi, si ils introduisent un bug dans une zone et que celui-ci en détériore les fonctionnalités, les autres zones vont pouvoir continuer à fonctionner. C’est à la fois une sécurité physique et logique par rapport aux actions de maintenance menées par les équipes d’infrastructure. 

Kubernetes peut absorber la perte de chacune des zones en dispatchant la workload sur les autres VM. Cela permet de s’assurer que les applications hébergées sur le cluster Kubernetes n’ont pas été impactées par la perte d’une zone. 

Des incidents comme des incendies, des inondations ou des séismes peuvent faire tomber plusieurs bâtiments et même la totalité d’un site. 

Dans certains cas et dans certaines entreprises on se préserve de ce genre d’événements pour les applications hypercritiques. En plus d’être hébergées sur un cluster Kubernetes dans un datacenter comme les autres, elles sont également hébergées sur un autre cluster Kubernetes identique ou quasi identique dans un autre datacenter, c’est le niveau de service maximum mis en place dans le cadre d’un Disaster Recovery Plan (DRP). Cela permet de prévenir une perte totale des VM et ainsi assurer un relai pour les applications hypercritiques. 

Pour Cédric Lamouche, expert en cybersécurité chez Agaetis, le contrat, souvent lu et signé dans la précipitation ou en complète confiance avec le prestataire est un acte d’engagement fort bipartie. Il est partie prenante de la gestion des risques dans l’entreprise ce qui impose d’en avoir une lecture précise et attentive, il doit surtout être en adéquation avec le contrat de service que vous attendez du prestataire mais aussi des engagements de sécurité et de productions garanties à votre entreprise. Oui, cela peut paraître normal, banal, acté que, par exemple, vos données soient sécurisées sur l’hébergement de votre prestataire mais dans quelles conditions ? Est-ce compatible avec votre activité ? Les piliers fondamentaux de la sécurité qui sont disponibilité, intégrité et confidentialité doivent être, là aussi, évalués. Souvent par questions de coûts finaux on peut faire l’impasse sur des options ou fonctions qui, si elles ne sont pas évaluées, peuvent avoir des conséquences désastreuses pour le business de l’entreprise.

Aujourd’hui suite à la perte de ce datacenter chez OVH combien de sociétés sont lais sées sur le carreaux ? Combien de sociétés se retrouvent sans sauvegarde ? Combien d’entre elles n’ont plus accès à leur service email ?

Il n’est pas trop tard pour reprendre vos contrats, comprendre ce qui est mentionné et voir si les engagements de vos prestataires sont en adéquation avec vos exigences de sécurité et votre continuité d’activité. 

Si il y a une chose à retenir de cet incendie c’est la suivante : au moment du déploiement il faut être rigoureux et bien choisir les disponibilités des machines. Selon les besoins et les projets il faut qu’un DRP soit monté en amont afin de se prémunir de ce type d’ennuis. Adopter une approche résiliente dès le départ c’est s’assurer que son SI continue de fonctionner et de vivre même en cas d’incidents graves. 



Si vous avez des questions ou simplement envie d’échanger sur le sujet n’hésitez pas à nous contacter !