IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

OVH abandonne le datacenter SBG1 envahi par de la fumée provenant de batteries lors du nouvel incendie maîtrisé :
Le résultat d'erreurs de conception de l'alimentation électrique révélées en 2017 ?

Le , par Patrick Ruiz

161PARTAGES

14  0 
Dizaine difficile pour OVH lancé dans la gestion d’un incendie qui lui a valu la perte du datacenter dénommé SBG2 sur son site de Strasbourg. En effet, l’addition est désormais plus salée pour le leader français et espoir européen de l’hébergement web. L’entreprise a frôlé un nouvel incendie et décide y faisant suite de l’abandon du datacenter SBG1. Qu’est-ce qui explique cette série de départs en fumée ? La piste de l’erreur de conception de l’alimentation électrique n’est-elle pas à explorer ?

La fumée dans le datacenter SBG1 provenait d’un lot de 300 batteries stockées en son sein dans un local non utilisé. Dans la foulée, OVHCloud a annoncé que tous les serveurs SBG1 seraient finalement déplacés sur d'autres centres de données situés sur le site de Strasbourg ou sur ses campus de Gravelines et Roubaix. L’entreprise avait pointé du doigt un dysfonctionnement d’un onduleur comme cause de l’incendie qui a détruit le datacenter SBG2. À date, 60 % des VPS de SBG3 sont en principe fonctionnels, contre 25 % pour l'offre bare metal. On reste dans l’attente de 40 % de Private Cloud (pCC). Le travail se poursuit. Il en va de même pour SBG4, avec le redémarrage attendu pour ce mercredi 24 mars.


La piste de l’erreur de conception de l’alimentation électrique du site est-elle à exclure ?

Dans une mise à jour de gestion d’incident survenu en 2017 Octave Klaba explique que :

« Ce matin à 7 h 23, nous avons eu une panne majeure sur notre site de Strasbourg (SBG) : une coupure électrique qui a mis dans le noir nos trois datacentres SBG1, SBG2 et SBG4 durant 3h30. Le pire scénario qui puisse nous arriver.

« Le site de SBG est alimenté par une ligne électrique de 20 kV composée de deux câbles qui délivrent chacun 10 MVA. Les deux câbles fonctionnent ensemble, et sont connectés à la même source et sur le même disjoncteur chez ELD (Strasbourg Électricité Réseaux). Ce matin, l’un des deux câbles a été endommagé et le disjoncteur a coupé l’alimentation des datacentres.

« Le site SBG est prévu pour fonctionner, sans limite de temps, sur les groupes électrogènes. Pour SBG1 et SBG4, nous avons mis en place, un premier système de deux groupes électrogènes de 2 MVA chacun, configurés en N+1 et en 20 kV. Pour SBG2, nous avons mis en place trois groupes en N+1 de 1.4MVA chacun. En cas de coupure de la source externe, les cellules haute tension sont reconfigurées automatiquement par un système de bascule motorisé. En moins de 30 secondes, les datacentres SBG1, SBG2 et SBG4 sont réalimentés en 20 KV. Pour permettre toutes ces bascules sans couper l’alimentation électrique des serveurs, nous disposons d’onduleurs (UPS) sachant fonctionner sans aucune alimentation durant huit minutes.

« Ce matin, le système de basculement motorisé n’a pas fonctionné. L’ordre de démarrage des groupes n’a pas été donné par l’automate. Il s’agit d’un automate NSM (Normal Secours Motorisé), fournit par l’équipementier des cellules haute-tension 20 kV. Nous sommes en contact avec lui, afin de comprendre l’origine de ce dysfonctionnement. C’est toutefois un défaut qui aurait dû être détecté lors des tests périodiques de simulation de défaut sur la source externe. Le dernier test de reprise de SBG sur les groupes date de la fin du mois mai 2017. Durant ce dernier test, nous avons alimenté SBG uniquement à partir des groupes électrogènes durant 8H sans aucun souci et chaque mois nous testons les groupes à vide. Et malgré tout, l’ensemble de ce dispositif n’a pas suffi aujourd’hui pour éviter cette panne.

« Vers 10h, nous avons réussi à basculer les cellules manuellement et nous avons recommencé à alimenter le datacentre à partir des groupes électrogènes. Nous avons demandé à ELD de bien vouloir déconnecter le câble défectueux des cellules haute tension et remettre le disjoncteur en marche avec un seul des deux câbles, et donc limité à 10 MVA. La manipulation a été effectuée par ELD et le site a été réalimenté vers 10 h 30. Les routeurs de SBG ont été joignables à partir de 10 h 58.

« Depuis, nous travaillons, sur la remise en route des services. Alimenter le site en énergie permet de faire redémarrer les serveurs, mais il reste à remettre en marche les services qui tournent sur les serveurs. C’est pourquoi chaque service revient progressivement depuis 10 h 58. Notre système de monitoring nous permet de connaitre la liste de serveurs qui ont démarré avec succès et ceux qui ont encore un problème. Nous intervenons sur chacun de ces serveurs pour identifier et résoudre le problème qui l’empêche de redémarrer.

« À 7 h 50, nous avons mis en place une cellule de crise à RBX, où nous avons centralisé les informations et les actions de l’ensemble des équipes. Un camion en partance de RBX a été chargé de pièces de rechange pour SBG. Il est arrivé à destination vers 17 h 30. Nos équipes locales ont été renforcées par des équipes du datacentre de LIM en Allemagne et de RBX, ils sont tous mobilisés sur place depuis 16H00. Actuellement, plus de 50 techniciens travaillent à SBG pour remettre tous les services en route. Nous préparons les travaux de cette nuit et, si cela était nécessaire, de demain matin.

« Prenons du recul. Pour éviter un scénario catastrophe de ce type, durant ces 18 dernières années, OVH a développé des architectures électriques capables de résister à toutes sortes d’incidents électriques. Chaque test, chaque petit défaut, chaque nouvelle idée a enrichi notre expérience, ce qui nous permet de bâtir aujourd’hui des datacentres fiables.

« Alors pourquoi cette panne ? Pourquoi SBG n’a pas résisté à une simple coupure électrique d’ELD ? Pourquoi toute l’intelligence que nous avons développée chez OVH, n’a pas permis d’éviter cette panne ?

« La réponse rapide : le réseau électrique de SBG a hérité des imperfections de design liées à la faible ambition initialement prévue pour le site.

« La réponse longue :

En 2011, nous avons planifié le déploiement de nouveaux datacentres en Europe. Pour tester l’appétence de chaque marché, avec de nouvelles villes et de nouveaux pays, nous avons imaginé une nouvelle technologie de déploiement de datacentres, basée sur les containers maritimes. Grâce à cette technologie, développée en interne, nous avons voulu avoir la souplesse de déployer un datacentre sans les contraintes de temps liées aux permis de construire. À l’origine, nous voulions avoir la possibilité de valider nos hypothèses avant d’investir durablement dans un site.

« C’est comme ça que début 2012, nous avons lancé SBG avec un datacentre en containers maritimes : SBG1. Nous avons déployé huit containers maritimes et SBG1 a été opérationnel en seulement deux mois. Grâce à ce déploiement ultra rapide, en moins de 6 mois nous avons pu valider que SBG est effectivement un site stratégique pour OVH. Fin 2012, nous avons décidé de construire SBG2 et en 2016, nous avons lancé la construction de SBG3. Ces deux constructions n’ont pas été faites en containers, mais ont été basées sur notre technologie de « Tour » : la construction de SBG2 a pris neuf mois et SBG3 sera mis en production dans un mois. Pour pallier les problèmes de place début 2013, nous avons construit très rapidement SBG4, l’extension basée encore sur les fameux containers maritimes.

« Le problème est qu’en déployant SBG1 avec la technologie basée sur les containers maritimes, nous n’avons pas préparé le site au large scale. Nous avons fait deux erreurs : primo, nous n’avons pas remis le site SBG aux normes internes qui prévoient deux arrivées électriques indépendantes de 20*KV, comme tous nos sites de DC qui possèdent plusieurs doubles arrivées électriques. Il s’agit d’un investissement important d’environ 2 à 3 millions d’euros par arrivée électrique, mais nous estimons que cela fait partie de notre norme interne. Deuxio, nous avons construit le réseau électrique de SBG2 en le posant sur le réseau électrique de SBG1, au lieu de les rendre indépendants l’un de l’autre, comme dans tous nos datacentres. Chez OVH, chaque numéro de datacentre veut dire que le réseau électrique est indépendant d’un autre datacentre. Partout sauf sur le site de SBG.

« La technologie basée sur les containers maritimes n’a été utilisée que pour construire SBG1 et SBG4. En effet, nous avons réalisé que le datacentre en containers n’est pas adapté aux exigences de notre métier. Avec la vitesse de croissance de SBG, la taille minimale d’un site est forcément de plusieurs datacentres, et donc d’une capacité totale de 200*000 serveurs. C’est pourquoi, aujourd’hui, pour déployer un nouveau datacenter, nous n’utilisons plus que deux types de conceptions largement éprouvées et prévues pour le large scale avec de la fiabilité : la construction de tours de cinq ou six étages (RBX4, SBG2-3, BHS1-2), pour 40*000 serveurs ; l’achat des bâtiments (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) pour 40 000 ou 80 000 serveurs.

« Même si l’incident de ce matin a été causé par un automate tiers, nous ne pouvons nous dédouaner de la responsabilité de la panne. À cause du déploiement initial basé sur les containers maritimes, nous avons un historique à rattraper sur SBG pour atteindre le même niveau de normes que sur les autres sites d’OVH.

« Cet après-midi, nous avons décidé du plan d’action suivant : la mise en place de la 2e arrivée électrique, totalement séparée, de 20 MVA ; la séparation du réseau électrique de SBG2 vis-à-vis de SBG1/SBG4, ainsi que la séparation du futur SBG3 vis-à-vis de SBG2 et SBG1/SBG4 ; la migration des clients de SBG1/SBG4 vers SBG3 ; la fermeture de SBG1/SBG4 et la désinstallation des containers maritimes.

« Il s’agit d’un plan d’investissement de 4-5 millions d’euros, que nous mettons en route dès demain, et qui, nous l’espérons, nous permettra de restaurer la confiance de nos clients envers SBG et plus largement OVH.

« Les équipes sont toujours en train de travailler sur la remise en route des derniers clients impactés. Une fois l’incident clos, nous appliquerons les SLA prévus dans nos contrats.

« Nous sommes profondément désolés pour la panne générée et nous vous remercions des encouragements que vous nous témoignez durant cet incident. »

La Cnil monte au créneau

La CNIL a pour sa part procédé à la publication d’ une note sur son site qui rappelle les règles du RGPD aux propriétaires des sites web affectés par les incidents OVH. S'ils ont perdu des données personnelles, il faut le signaler à l'autorité :

« Suite à l’incendie du 10 mars 2021 ayant eu lieu dans un centre de données d’OVH à Strasbourg, la CNIL rappelle les obligations en matière de notification de violation en cas d’indisponibilité ou de destruction de données personnelles. La destruction de données personnelles (temporaire ou définitive), y compris accidentelle, constitue une violation de données au sens du RGPD. À ce titre, les responsables de traitement qui hébergeaient des données personnelles au sein des infrastructures touchées doivent documenter la violation (les faits, ses effets et les mesures prises pour y remédier) dans un registre tenu en interne. Les sous-traitants doivent informer leurs clients de l'incident afin que ces derniers puissent remplir leurs propres obligations, dont celle de documentation dans le registre des violations tenu en interne par chacun d’entre eux. »

Sources : Twitter, Cnil

Et vous ?

Qu’en pensez-vous ?

Voir aussi :

OVHcloud lance le processus d'une éventuelle introduction en bourse selon un porte-parole de l'entreprise
Capgemini et OVHcloud signent un partenariat mondial pour permettre aux organisations de mener leur transformation dans le cloud de manière sécurisée et apporter des solutions cloud robustes
OVHcloud s'associe à Orange Business Services afin d'accompagner les projets de migration et de transformation vers le cloud OVHcloud dans «*une approche multifournisseur »
OVHcloud s'associe à IBM et Atempo pour offrir aux organisations européennes une solution de stockage dans le cloud souveraine et compétitive, partenariat basé sur les solutions de stockage sur bande

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Patrick Ruiz
Chroniqueur Actualités https://www.developpez.com
Le 07/12/2021 à 19:17
Incendie OVH : 20 clients s’inscrivent à un recours collectif destiné à obtenir de l’hébergeur des compensations équitables
Après l’incendie qui a ravagé le centre de données SBG2 au mois de mars

Le cabinet d'avocats parisien Ziegler & Associés annonce qu'une vingtaine de clients d'OVHcloud se sont joints à un recours collectif. Objectif : engager la responsabilité d’OVHcloud afin d’obtenir des compensations équitables après l’incendie qui a ravagé le centre de données SBG2 au mois de mars. Les plaignants reprochent à l’hébergeur d'avoir proposé à tous ses clients impactés par l'incendie de ses centres de données la même indemnisation, sans prendre en contre le chiffrage du préjudice de chacun.

Le cabinet d'avocats appelle d'autres clients de l'hébergeur à se joindre au recours collectif. Elle entend estimer leurs dommages avant d'envoyer une facture officielle à OVHcloud. Un accord à l’amiable entre Ziegler et OVHcloud devrait ensuite voir le jour. À défaut, l'affaire sera portée devant le tribunal du commerce.



Les entreprises qui participent au recours collectif contre OVHcloud sont de divers secteurs : comptabilité, marketing, santé et tourisme. Un accord de confidentialité les lie au cabinet Ziegler & Associés. En vertu de ce dernier, leurs noms sont tenus secrets. L’autre dénominateur commun entre ces personnes morales est qu’elles rapportent des pertes de leurs bases de données suite à l’incendie du mois de mars. Le tableau de l’après incendie c’est un acteur du secteur de la santé qui se retrouve sans aucune information associée aux patients ou une entreprise touristique qui ne sait plus retrouver les détails de réservations de ses clients.

« Pertes de nombreuses données et préjudices économiques significatifs : plusieurs milliers de sociétés clientes d’OVHcloud ont été durement frappées par cet incendie », souligne le cabinet d'avocats parisien Ziegler & Associés pour lequel « OVHcloud a donc, sans aucun doute, failli à son obligation contractuelle de protection de vos données, qui lui est impartie en sa qualité de prestataire de service. »

Suite à l’incendie du mois de mars, La fameuse question de gestion des sauvegardes faisait à nouveau surface à l’ère du cloud qui a le vent en poupe. OVH s’était expliqué en soulignant qu’il offre du hosting.

« Il semble que les consommateurs à l’échelle globale ne comprennent pas notre offre. Cela fait déjà trop de discussions autour de cet aspect. Nous ne voulons pas nous enfoncer dans cette brèche. Nous allons plutôt revoir la sécurité à la hausse en offrant le plus haut niveau de sauvegarde pour tous nos clients de tous nos centres de données. Cela va changer les standards de l’industrie, ainsi que notre façon d’offrir nos services », avait expliqué Octave Klaba en annonçant du même coup l’adoption d’une nouvelle politique de sauvegarde gratuite des données de tous les clients.

Source : Ziegler

Et vous ?

Quel est votre avis sur le sujet ? OVHcloud peut-il être tenu pour responsable de la perte de données de ses clients comme le martèle le cabinet Zigler ?

Voir aussi :

OVHcloud lance le processus d'une éventuelle introduction en bourse selon un porte-parole de l'entreprise
Capgemini et OVHcloud signent un partenariat mondial pour permettre aux organisations de mener leur transformation dans le cloud de manière sécurisée et apporter des solutions cloud robustes
OVHcloud s'associe à Orange Business Services afin d'accompagner les projets de migration et de transformation vers le cloud OVHcloud dans « une approche multifournisseur »
OVHcloud s'associe à IBM et Atempo pour offrir aux organisations européennes une solution de stockage dans le cloud souveraine et compétitive, partenariat basé sur les solutions de stockage sur bande
25  0 
Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 11/03/2022 à 19:03
Incendie OVH : absence de système d'extinction incendie automatique et de dispositif de coupure électrique général,
le rapport des pompiers souligne des défaillances

Dans la nuit du 9 au 10 mars 2021, un incendie s’est déclaré dans l’un des datacenters de la société OVH cloud. Plusieurs entreprises ont été victimes de cet incendie et de nombreux sites internet ont à déplorer une perte irréversible de leurs données. Que les pertes de données n’aient été que temporaires ou définitives, cet incendie a porté, dans tous les cas, un préjudice économique à plusieurs milliers de sociétés.

Un an plus tard, l'enquête des sapeur-pompiers du Bas-Rhin est désormais disponible.

Le rapport souligne les défaillances dans le système de sécurité du bâtiment. Le bâtiment n’était notamment pas équipé d’un dispositif de coupure de l’électricité selon ce rapport : « la pérennité de l'alimentation électrique est un enjeu fort pour ce type d'exploitation. La conception intrinsèque de l'activité est faite pour éviter les coupures d'électricité. Deux niveaux de groupes électrogènes sont prévus pour palier une défaillance du réseau. Aucun organe de coupure d'urgence n'existe (choix de stratégie économique de l'entreprise) ».

Les pompiers n'ont pas pu couper l'électricité ni dans le local en flamme ni sur le site ce qui a favorisé la propagation de l'incendie.

Les pompiers évoquent également l'absence de système d'extinction automatique, le site misant sur une détection précoce et une alerte rapide des secours.

Autre défaillance : le fait que la direction d'OVH n'avait pas inscrit le site sur la liste des établissements répertoriés comme sensibles. Enfin, la présence d'une seule bouche d'incendie dans ce quartier du port autonome de Strasbourg.


L'incident déplorable a mis hors ligne environ 3,6 millions de sites Web répartis sur 464 000 domaines distincts. Octave Klaba n'a pas tardé à faire une sortie vidéo pour présenter ses excuses et expliquer à ses clients ce qui aurait déclenché le feu. On retient surtout que le patron d'OVHCloud a promis tirer des enseignements de ce sinistre et tout faire désormais pour qu'une telle situation « n'arrive plus jamais ».

Pourtant, dix jours après le feu qui a détruit un des quatre datacenters d'OVHcloud, certains médias ont annoncé un nouvel incendie sur le site de Strasbourg du français. Heureusement, la situation a rapidement été maitrisée.

Quoiqu'il en soit, le cabinet d'avocats parisien Ziegler & Associés a pour sa part amorcé un recours collectif contre OVHcloud. Pour le cabinet, si un accord à l'amiable n'est pas trouvé en termes de préjudice et d'indemnisation, l'affaire prendrait le chemin du tribunal de commerce.

Il faut dire que le 16 mars 2021, le PDG d’OVH avait annoncé que les clients bénéficieraient de trois mois gratuits en cas de coupure de service et d'une gratuité de six mois en cas de perte de données.

À cette même date, le fondateur de la société a également reconnu que beaucoup de clients n’avaient pas compris l’offre d’OVH en matière d’hébergement des données et de la nécessité de souscrire à une offre de sauvegarde complémentaire. Octave Klaba a alors annoncé une modification de la politique d’OVH afin d’accroître la sécurité des données et permettre une option de sauvegarde de données à tous les clients, sans aucun surcoût.

Cette annonce est cruciale car, certains clients n’avaient pas souscrit à l’offre de sauvegarde supplémentaire avant la survenance de l’incendie. Et cela peut avoir un impact sur l’indemnisation future de leurs pertes.

Ainsi, comment les clients dont le préjudice économique est lourd pourront-ils engager la responsabilité d’OVH s’ils sont contraints de ne jamais retrouver leurs données ? Autrement dit, pourront-il obtenir une indemnisation pour les pertes subies ?

La nature juridique des relations établies entre OVH, prestataire de service, et ses clients est contractuelle. Par conséquent, les stipulations contractuelles présentes au sein des conditions générales du fournisseur règlent la question de la responsabilité.

D’autre part, il existe deux grandes catégories de contrat chez ce type d’hébergeurs. On peut donc retrouver un contrat d’hébergement simple qui ne sera pas assorti de services associés ; on peut également retrouver un contrat d’hébergement avec des services ajoutés comme la possibilité de sauvegarde, de mise en place de plan de continuité ou de reprise d’activité etc.

C’est-à-dire que d’un contrat à l’autre, en fonction des options choisies par le client et des clauses rédigées entre les parties, le régime de responsabilité n’est pas le même pour OVH. À titre d’exemple, suivant la disponibilité choisie, OVHCloud dispose entre 9h (99,9%) et jusqu’à 36 jours (90%) pour rétablir les services.

Par conséquent, pour espérer intenter une action en indemnisation, la première question à se poser est de savoir quel type de contrat votre entreprise a conclu avec OVH ?


Début novembre, les sept entreprises que le cabinet a fédéré ont été rejoint par 13 entreprises supplémentaires. Désormais, le recours collectif comporte 130 entreprises.

Les entreprises qui participent au recours collectif contre OVHcloud sont de divers secteurs : comptabilité, marketing, santé et tourisme. Un accord de confidentialité les lie au cabinet Ziegler & Associés. En vertu de ce dernier, leurs noms sont tenus secrets. L’autre dénominateur commun entre ces personnes morales est qu’elles rapportent des pertes de leurs bases de données suite à l’incendie du mois de mars. Le tableau de l’après incendie c’est un acteur du secteur de la santé qui se retrouve sans aucune information associée aux patients ou une entreprise touristique qui ne sait plus retrouver les détails de réservations de ses clients.

En parallèle du recours collectif suite à l'incendie d'OVH à Strasbourg, un groupe du Cac 40 et trois sociétés de plus de 10 000 salariés ont décidé de porter une action de façon individuelle.

Chaque client figurant sur la liste finale verra ses pertes évaluées individuellement, y compris les coûts financiers directs et les dommages causés à leurs marques, avant que Ziegler n'envoie sa lettre. Le cabinet laissera un mois à OVHcloud pour trouver un accord à l'amiable, sous peine de saisir le tribunal de commerce.

« L'objectif est de démontrer que la situation d'OVH n'est plus tenable, et qu'elle devra passer par une discussion amiable si elle ne veut pas un procès perdant », a indiqué Jocelyn Ziegler.

« Les organismes qui ont rejoint le recours collectif en ont assez de la réaction d'OVH. La plupart ont reçu des courriers dans lesquels le groupe indique qu'il se dégage de sa responsabilité ou se limite à une clause de limitation de responsabilité. Ils demandent à OVH de reconnaître le préjudice et les indemniser », a déclaré Ziegler.

Sources : rapport des pompiers, Ziegler & Associés
20  0 
Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 10/01/2022 à 21:17
Près de 60 entreprises, dont un groupe du CAC 40, demandent réparation après l'incendie d'OVH Cloud.
les procédures sont désormais entamées

Dans la nuit du 9 au 10 mars 2021, un incendie s’est déclaré dans l’un des datacenters de la société OVH cloud. Plusieurs entreprises ont été victimes de cet incendie et de nombreux sites internet ont à déplorer une perte irréversible de leurs données. Que les pertes de données n’aient été que temporaires ou définitives, cet incendie a porté, dans tous les cas, un préjudice économique à plusieurs milliers de sociétés.

La CNIL a procédé à la publication d’une note sur son site qui rappelle les règles du RGPD aux propriétaires des sites web affectés par les incidents OVH. S'ils ont perdu des données personnelles, il faut le signaler à l'autorité :

« Suite à l’incendie du 10 mars 2021 ayant eu lieu dans un centre de données d’OVH à Strasbourg, la CNIL rappelle les obligations en matière de notification de violation en cas d’indisponibilité ou de destruction de données personnelles. La destruction de données personnelles (temporaire ou définitive), y compris accidentelle, constitue une violation de données au sens du RGPD. À ce titre, les responsables de traitement qui hébergeaient des données personnelles au sein des infrastructures touchées doivent documenter la violation (les faits, ses effets et les mesures prises pour y remédier) dans un registre tenu en interne. Les sous-traitants doivent informer leurs clients de l'incident afin que ces derniers puissent remplir leurs propres obligations, dont celle de documentation dans le registre des violations tenu en interne par chacun d’entre eux. »

Le cabinet d'avocats parisien Ziegler & Associés a pour sa part amorcé un recours collectif contre OVHcloud. Pour le cabinet, si un accord à l'amiable n'est pas trouvé en termes de préjudice et d'indemnisation, l'affaire prendrait le chemin du tribunal de commerce.

Il faut dire que le 16 mars 2021, le PDG d’OVH avait annoncé que les clients bénéficieraient de trois mois gratuits en cas de coupure de service et d'une gratuité de six mois en cas de perte de données.

À cette même date, le fondateur de la société a également reconnu que beaucoup de clients n’avaient pas compris l’offre d’OVH en matière d’hébergement des données et de la nécessité de souscrire à une offre de sauvegarde complémentaire. Octave Klaba a alors annoncé une modification de la politique d’OVH afin d’accroître la sécurité des données et permettre une option de sauvegarde de données à tous les clients, sans aucun surcoût.

Cette annonce est cruciale car, certains clients n’avaient pas souscrit à l’offre de sauvegarde supplémentaire avant la survenance de l’incendie. Et cela peut avoir un impact sur l’indemnisation future de leurs pertes.

Ainsi, comment les clients dont le préjudice économique est lourd pourront-ils engager la responsabilité d’OVH s’ils sont contraints de ne jamais retrouver leurs données ? Autrement dit, pourront-il obtenir une indemnisation pour les pertes subies ?

La nature juridique des relations établies entre OVH, prestataire de service, et ses clients est contractuelle. Par conséquent, les stipulations contractuelles présentes au sein des conditions générales du fournisseur règlent la question de la responsabilité.

D’autre part, il existe deux grandes catégories de contrat chez ce type d’hébergeurs. On peut donc retrouver un contrat d’hébergement simple qui ne sera pas assorti de services associés ; on peut également retrouver un contrat d’hébergement avec des services ajoutés comme la possibilité de sauvegarde, de mise en place de plan de continuité ou de reprise d’activité etc.

C’est-à-dire que d’un contrat à l’autre, en fonction des options choisies par le client et des clauses rédigées entre les parties, le régime de responsabilité n’est pas le même pour OVH. À titre d’exemple, suivant la disponibilité choisie, OVHCloud dispose entre 9h (99,9%) et jusqu’à 36 jours (90%) pour rétablir les services.

Par conséquent, pour espérer intenter une action en indemnisation, la première question à se poser est de savoir quel type de contrat votre entreprise a conclu avec OVH ?

Ce contrat stipule-t-il l’obligation pour OVH de sauvegarder les données partagées ? À défaut, le client ne pourra engager la responsabilité de l’hébergeur au titre de la perte de données.

Si la sauvegarde de données était comprise dans le contrat, alors il est possible de rechercher la responsabilité d’OVH, car cette dernière aurait dès lors commis une faute contractuelle.

Début novembre, les sept entreprises que le cabinet a fédéré ont été rejoint par 13 entreprises supplémentaires. Cette fois-ci, elles sont 56 et les procédures sont désormais entamées.


Les entreprises qui participent au recours collectif contre OVHcloud sont de divers secteurs : comptabilité, marketing, santé et tourisme. Un accord de confidentialité les lie au cabinet Ziegler & Associés. En vertu de ce dernier, leurs noms sont tenus secrets. L’autre dénominateur commun entre ces personnes morales est qu’elles rapportent des pertes de leurs bases de données suite à l’incendie du mois de mars. Le tableau de l’après incendie c’est un acteur du secteur de la santé qui se retrouve sans aucune information associée aux patients ou une entreprise touristique qui ne sait plus retrouver les détails de réservations de ses clients.

Maître Dakos, avocat chez Ziegler & Associés, travaille sur ce dossier: « Dans ces 56 entreprises, on a une majorité de PME et de TPE, on a aussi quelques grands groupes industriels basés à l’international. On a aussi un groupe du CAC 40 et une administration. On va démontrer dans notre recours qu'OVH aurait pu prendre des mesures, des dispositifs: extincteur automatique, des dispositifs de préventions ».

Les indemnités demandées s’élèvent à plusieurs dizaines de milliers d’euros selon l’avocat. « Les préjudices subis par les entreprises s’échelonnent entre 10 000 euros et 1,9 million d’euros et au total on est sur des sommes considérables de plusieurs millions, voire dizaines de millions d’euros » poursuit l'avocat.

Dans cette affaire, OVH se dédouane de toute « faute » et invoque un cas de « force majeure ». OVHcloud avait consenti a des « gestes commerciaux » au lendemain du sinistre.

Le cabinet d'avocats assure de son côté à OVH l'absence de système d'extinction dans le bâtiment et que les « sauvegardes back-up étaient sur le même serveur que les originales ». Les avocats estiment également que la clause « limitative de responsabilité » ne tient pas et veulent que soient pris en compte « les dommages indirects » subis par les entreprises clientes.

Source : Ziegler & Associés
15  1 
Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 30/03/2021 à 10:05
OVH donne des informations relatives au nettoyage des équipements suite à l'incendie,
opération nécessaire avant une remise en service

L'opérateur de cloud français OVH a révélé comment il nettoie tous les serveurs qui, selon lui, peuvent être remis en service dans ses centres de données brulés à Strasbourg. Le fondateur et président Octave Klaba a utilisé son compte Twitter pour montrer une partie du travail effectué par l'équipe de nettoyage de l'entreprise.

« Le nettoyage prend du temps. Nous avons 80 personnes (SBG3) + 20 personnes (Croix). Sur la gauche, une carte mère avec la pollution par la fumée sur le socket du CPU. C'est très corrosif ! Si nous mettons sous tension, il est mort. Identique au disque. Sur la droite, le même appareil 24 h après le nettoyage ».


Klaba a également déclaré que tous les serveurs devraient être nettoyés d'ici mardi, mais que le stockage et l'empilage de l'infrastructure pour certains services prennent plus de temps que prévu.

La mise à jour du dimanche après-midi d'OVH a offert plus de détails : « Aujourd'hui, le temps de nettoyage d'un rack est de 7 heures, et nos équipes s'améliorent chaque jour ».

La mise à jour avait également de meilleures nouvelles pour les clients :
  • SBG1 : Les serveurs récupérables Bare Metal Cloud sont en cours de nettoyage pour réinstallation à Strasbourg (SBG3 et SBG4). La remise en service débutera progressivement au début de la semaine prochaine (après inspection et nettoyage).
  • SBG3 est opérationnel : 84 % des services Bare Metal Cloud (VPS) ont de nouveau été mis à la disposition des clients, avec un objectif de 90 % au soir du 28 mars.
  • SBG4 est opérationnel : 100 % des serveurs Bare Metal sont à la disposition des clients.

Les serveurs du centre de données SBG1 reviendront en ligne à des moments différents. Certains resteront à Strasbourg et logeront au SBG4. D'autres sont destinés à d'autres centres de données OVH. La mise à jour mentionne un redémarrage « en milieu de semaine du 29 mars » pour certains et un redémarrage le 1er ou le 2 avril pour ceux qui ont été déplacés vers d'autres emplacements.

La reprise après sinistre est également en cours.

Certains services cloud d'OVH ne sont pas non plus restaurés à 100% de disponibilité. La société a également averti que des niveaux élevés de demande signifient que « les délais de livraison de nos services Bare Metal Cloud peuvent prendre plus de temps que d'habitude ».

« Nos équipes sont pleinement mobilisées et nous travaillons d'arrache-pied pour livrer le plus rapidement possible à nos clients, en particulier à tous les clients concernés », indique le communiqué de dimanche.

Klaba, quant à lui, a révélé que l'incendie avait coûté à OVH l'opportunité de lancer un nouveau service.

Sources : OVH, Octave Klaba

Et vous ?

Hébergez-vous des données ou sites sur OVHcloud ? Avez-vous été impactés par cet incendie ?
Si oui, faites-vous partie des clients dont les services ont été restaurés ?

Voir aussi :

OVHcloud lance le processus d'une éventuelle introduction en bourse selon un porte-parole de l'entreprise
Capgemini et OVHcloud signent un partenariat mondial pour permettre aux organisations de mener leur transformation dans le cloud de manière sécurisée et apporter des solutions cloud robustes
OVHcloud s'associe à Orange Business Services afin d'accompagner les projets de migration et de transformation vers le cloud OVHcloud dans « une approche multifournisseur »
OVHcloud s'associe à IBM et Atempo pour offrir aux organisations européennes une solution de stockage dans le cloud souveraine et compétitive, partenariat basé sur les solutions de stockage sur bande
13  0 
Avatar de Bill Fassinou
Chroniqueur Actualités https://www.developpez.com
Le 10/05/2021 à 20:41
OVH : le site de Roubaix de l'hébergeur aurait une sécurité incendie déficiente,
selon un rapport de Bureau Veritas

Un peu plus d'un mois après l'incendie qui a ravagé les datacenters strasbourgeois du français OVH, l'on apprend l'existence d'un rapport qui démontre la défaillance du système de sécurité incendie du site hébergeant ses datacenters à Roubaix. Le rapport, signé Bureau Veritas, a analysé en janvier la protection incendie du site de Roubaix qui renferme plus de 130 000 serveurs. Selon Bureau Veritas, les salles de batteries sont mal protégées et nécessitent une remise en conformité, la protection anti-foudre comporte des câbles susceptibles de conduire la foudre à l'intérieur de l'édifice, et d'autres problèmes encore.

Les sites abritant les centres de données du fournisseur français d'infrastructures cloud OVH seraient mal sécurisés. En effet, c'est ce que démontre un rapport d'audit de Bureau Veritas datant de janvier 2021, soit environ deux mois avant l'incendie qui a détruit ses installations à Strasbourg. Le rapport d'expertise sur le site de Roubaix attire l'attention sur trois points essentiels, notamment les salles abritant les batteries, les poteaux-incendie et la protection anti-foudre des datacenters roubaisiens. En premier, Bureau Veritas a remarqué que les pièces où OVH entrepose les batteries sont mal sécurisées.



Ces salles ne respecteraient pas les conditions minimales requises de résistance au feu. « Aucune prise de terre paratonnerre n’a été créée, seule une interconnexion en 50 mm² a été réalisée avec une câblette de terre passant sur un chemin de câble près de la clôture extérieure. Descente reliée à une barrette de liaison avec une câblette elle-même reliée à un conducteur présent dans un chemin de câble à environ 5 m (la gaine grise présente dans le regard ne contient pas de conducteur) », a noté Bureau Veritas à propos du bâtiment Roubaix 1, parlant du choix de la protection externe pour cette structure.

Vu sous cet angle, le bureau d'inspection recommande une remise en conformité des locaux qui abritent les batteries, notamment en ce qui concerne le côté « coupe-feu ». Toujours par rapport à ces observations, Bureau Veritas recommande également le déplacement de certaines de ces salles vers d'autres espaces respectant les contraintes réglementaires. Cette dernière recommandation vient du fait que, selon l'organisme, le bâtiment Roubaix 4 serait difficile d'accès aux engins de secours en cas de pépins. Le rapport mentionne que "les locaux de batteries de Roubaix 4 ne disposent pas d'une voie d'échelle".

Toutefois, il a précisé que "l'intégralité des salles contenant des batteries est en cours de mise en conformité" et qu'elles devraient être conformes à la réglementation ICPE d'ici fin 2022. La deuxième défaillance majeure mise en évidence par le rapport concerne les poteaux- incendie. À ce stade, l'organisme a révélé que le débit disponible en simultané sur trois poteaux-incendie installés sur le site de Roubaix, soit 360 m3/h, est "insuffisant par rapport aux besoins requis (420 m3/h)" par l'ensemble des installations. Il recommande donc l'implantation de "bassins de confinement" pour résoudre ce déficit.

En troisième grand point, c'est le dispositif anti-foudre du site roubaisien du fournisseur cloud français qui a été remis en cause par Bureau Veritas. En plus de pointer du doigt une installation défectueuse, il ajoute que les câbles de parafoudre, tels qu’installés, sont susceptibles de conduire la foudre « directement à l'intérieur de l'édifice ». En fait, le rapport note qu'aux abords des bâtiments Roubaix 2 et 4, un câble de parafoudre mal protégé se glisse sur une quinzaine de mètres à l'intérieur du centre de données Roubaix 2. Il s'agirait d'une installation contraire aux bonnes pratiques du domaine.



« Ce câble pénètre dans le bâtiment et remonte vers les bureaux. Cette installation peut être dangereuse, car elle peut amener en cas d'impact la foudre directement à l'intérieur de l'édifice », lit-on dans le rapport. Outre ces faits, Bureau Veritas note l'absence de parafoudres de type 1 au sein des tableaux basse tension (TGBT), à l'exception du bâtiment Roubaix 7. « L'ensemble des TGBT et TGBT de secours du site de Roubaix devront être équipés de parafoudres de type 1+2 », recommande l'organisation de certification dans son rapport de janvier dernier.

À lecture du rapport, des critiques avancent que les bâtiments des centres de données de Strasbourg souffriraient des mêmes défaillances, ce qui aurait donc conduit à l'incendie qui s'est ravagé le site dans la nuit du mardi 9 à mercredi 10 mars 2021. S'exprimant sur Twitter au lendemain de l'incendie, le fondateur et PDG d'OVHcloud, Octave Klaba avait expliqué que l’incendie est parti du centre de données SBG2, qui a été entièrement détruit au moment où arrivaient les secours. Il s'est propagé pour toucher une partie de SBG1. Les autres centres de données du site SBG3 et SGB4 ont été épargnés par l'incendie.

À la suite de ses recommandations pour la mise en conformité et la sécurisation des centres de données roubaisiens d'OVH, Bureau Veritas a estimé le montant des travaux. L'organisme mentionne dans le rapport que le fournisseur cloud français devra dépenser pas moins de 2,9 millions d'euros pour remettre le site aux normes actuelles de l'industrie.

Source : Rapport de l'étude (PDF)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi

Un important incendie sur les installations d'OVHcloud à Strasbourg provoque l'indisponibilité de nombreux sites internet en France et en dehors de l'Hexagone

OVHcloud lance le processus d'une éventuelle introduction en bourse, selon un porte-parole de l'entreprise

OVHcloud promet de créer un laboratoire de simulation des incendies de datacenters pour mieux les modéliser et trouver des moyens plus efficaces de les éteindre

OVH abandonne le datacenter SBG1 envahi par de la fumée provenant de batteries lors du nouvel incendie maîtrisé : le résultat d'erreurs de conception de l'alimentation électrique révélées en 2017 ?
13  0 
Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 02/06/2022 à 18:25
Le recours collectif suite aux incendies d'OVHcloud compte 140 entreprises et sollicite plus de 10 millions d'euros,
les lettres de mise en demeure seront envoyées à l'hébergeur français cette semaine

Le 10 mars 2021, un centre de données d'OVH basé à Strasbourg partait en fumée. Le bâtiment strasbourgeois de cinq étages contenait plus de 14 000 serveurs. La catastrophe a entraîné l'arrêt total ou partiel de « 120 000 services », selon OVHcloud.

Plus d'un an après, OVHcloud n'a toujours pas formellement expliqué la cause de l'incendie. Un rapport des pompiers publié ce mois-ci souligne les défaillances dans le système de sécurité du bâtiment. Le bâtiment n’était notamment pas équipé d’un dispositif de coupure de l’électricité selon ce rapport : « la pérennité de l'alimentation électrique est un enjeu fort pour ce type d'exploitation. La conception intrinsèque de l'activité est faite pour éviter les coupures d'électricité. Deux niveaux de groupes électrogènes sont prévus pour palier une défaillance du réseau. Aucun organe de coupure d'urgence n'existe (choix de stratégie économique de l'entreprise) ».

Les pompiers n'ont pas pu couper l'électricité ni dans le local en flamme ni sur le site ce qui a favorisé la propagation de l'incendie.

Les pompiers évoquent également l'absence de système d'extinction automatique, le site misant sur une détection précoce et une alerte rapide des secours.

Autre défaillance : le fait que la direction d'OVH n'avait pas inscrit le site sur la liste des établissements répertoriés comme sensibles. Enfin, la présence d'une seule bouche d'incendie dans ce quartier du port autonome de Strasbourg.

Néanmoins, OVHcloud a indiqué qu'il ne fournira pas de communiqué officiel tant qu'il n'aura pas obtenu l'autorisation de ses assureurs et des agences gouvernementales.

Le cabinet Ziegler & Associés soutient pour sa part qu'OVHcloud a fait preuve de négligence dans les domaines évoqués dans ce rapport et n'a pas offert de compensation suffisante. Le cabinet d’avocats qui porte le recours collectif contre OVHcloud après l’incendie de Strasbourg, affirme être près d’envoyer les lettres de mise en demeure. Pas toutes dans un premier temps, certains clients devant encore lui communiquer des éléments. Mais d’ici à fin juin, tout sera parti.

Le recours collectif contre l'incendie du centre de données d'OVHcloud en mars 2021 compte désormais 140 clients.


Le cabinet évalue le préjudice de ses clients à 12 millions d’euros, mais il l'a revu à la baisse et il est maintenant de 10 millions d'euros soit en moyenne 71 428 euros par entreprise. Il faut préciser qu'il atteint les 3,2 millions d’euros pour l’entreprise qui a subi le plus lourd préjudice. Un montant (10 millions d'euros) estimé à condition de négocier à l'amiable. « Si on part en justice, ce chiffre [quadruple] », étant donné les dommages-intérêts et les frais de justice, prétend-on chez Ziegler & Associés.

Dans son rapport trimestriel, OVHcloud a indiqué avoir fait 3 millions d'euros de « gestes commerciaux » (remboursements), dépensé 3 millions d'euros en amortissement accéléré des serveurs endommagés et payé une prime d'assurance de 2 millions d'euros. L'opération semble s'être bien déroulée. L'annonce des résultats indique que les chiffres d'affaires ont été calculés « en excluant les impacts directs de l'incident de Strasbourg ». OVHcloud a indemnisé les clients pour la perte de son service, et non pour les pertes financières qu'ils ont subies, ou les atteintes à leur réputation, arguant que l'incendie n'était pas de sa responsabilité, mais un « cas de force majeure ».

Séparément, quatre grandes entreprises intentent une action individuelle contre OVHcloud pour l'incendie.

« La lettre de mise en demeure est un papier officiel réclamant à OVH les dommages et intérêts que les entreprises sont en droit de réclamer suite à ce fameux incendie. Il s'agit donc d'une tentative de parvenir à un accord à l'amiable », a déclaré Ziegler & Associates.

« Le recours collectif reste ouvert, donc les entreprises qui souhaitent le rejoindre peuvent le faire », a-t-il ajouté – bien qu'il ait précédemment déclaré que les entreprises avaient jusqu'en février 2022 pour se joindre, puis repoussé la date limite à la mi-avril.

Les premières lettres du cabinet d'avocats à OVHcloud devraient être envoyées ce mois-ci.

Le 28 février dernier, date de clôture de son premier semestre fiscal 2022, l’entreprise disait avoir reçu 410 réclamations et demandes d’information de la part de clients prétendant avoir été touchés. Avec, dans certains cas, des demandes de dédommagement pécuniaire « en général pour des montants individuels faibles, ou […] pas chiffrées ».

OVHcloud estime infondées la plupart des demandes des entreprises et assure que pour l’essentiel des autres, les gestes commerciaux accordés compensent largement les éventuels préjudices subis. À la date de publication de ses résultats financiers, l’hébergeur recensait six dossiers au stade contentieux. Pour couvrir les effets du sinistres (frais d’expertise et de procédure, actions en responsabilité), il a provisionné, au dernier pointage, 26,4 millions d'euros.

Source : Ziegler & Associés
13  0 
Avatar de Fleur en plastique
Membre extrêmement actif https://www.developpez.com
Le 24/03/2021 à 10:47
Je suis tout feu tout flamme !

C'est vraiment des bandes de branquignoles, là on peut dire que leur réputation a cramé, que la confiance est partie en fumée, mais le feu de la catastrophe à venir devait couver depuis longtemps. Il a fallu que les flammes du destin viennent consumer le clair manque de sécurité de leurs datacentres. OVH sur le coup, a fait long feu, et leur aura de premier hébergeur de France est en cendres. Il est certain qu'il leur faudra des années à OVH pour faire des étincelles à nouveau.

Pour mon expérience personnelle : j'exploite un serveur situé sur le datacentre SBG1, dans l'une des salles qui a échappée au premier feu. Le serveur a été rallumé 7 jours après l'incident, mais mis en mode rescue, obligeant du coup à une opération manuelle pour le mettre en mode normal. Mais le robot de reboot était HS, il a donc fallu attendre qu'ils soit réparé pour que je puisse le relancer en mode normal. OVH a envoyé deux mails de condoléances dans les jours qui suivaient l'incident, a prévenu du démarrage du serveur en mode secours. Mais depuis, plus rien. D'ailleurs, le serveur est à nouveau HS, probablement suite au déménagement prochain vers un datacentre non maudit ? En tant que cliente, je n'en ai pas la moindre idée.

Je pensais les incendier au téléphone. J'ai été mise en attente pendant très exactement 59 minutes, m'assurant qu'un opérateur allait prendre mon appel. Mais au final, on m'a juste raccroché au nez. J'étais verte.
14  2 
Avatar de sevyc64
Modérateur https://www.developpez.com
Le 07/12/2021 à 23:41
Citation Envoyé par defZero Voir le message
LoL, les personnes (j'espère pas des pro ) qui on perdu leurs donner dans cette histoire ne peuvent s'en prendre qu'à elles même.
Justement ceux sont beaucoup de pros. Et non, ils ne sont pas forcément fautifs, mais bien victimes.

On est parmi ces pros, on hébergeait chez OVH, les vitrines commerciales d'un certains nombres de nos clients. L'offre choisit était une offre globale avec sauvegarde assurée par OVH. Rien n'indiquait et ne permettait de choisir, dans le contrat d'hébergement, l’emplacement des sauvegardes réalisées. Mais la terminologie utilisée dans le contrat pouvait laisser penser à une sauvegarde sécurisée et redondante.
Dans les faits, comme l'incendie l'a révélé, rien de tout ça.

Une partie de nos clients ont perdus leur site, mais pas tous, malgré l'offre globale que l'on avait acheté à OVH.
Parmi ceux qui ont perdus leur site, une large partie a aussi perdu les sauvegardes, mais pas tous. Tout le contenu de SBG2 n'était pas forcément sauvegardé à SBG2. Dans notre cas, certaines sauvegardes étaient sur SBG3 et 4, d'après les infos qu'OVH avait donné, quelques rares, ailleurs, Roubaix il me semble.

Je peux te dire qu'il y a une armée d'avocats à éplucher les contrats, et c'est pas nous, le client, qui sommes coupables, mais bien OVH. Coupables, oui, de négligences, entre-autre, mais maintenant condamnable, cela reste une autre histoire.
13  1 
Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 17/03/2022 à 19:43
Incendie OVH : l'action du recours collectif est retardée jusqu'à mi-avril pour permettre à davantage d'entreprises d'en faire partie,
tandis qu'OVHcloud lance des services avec Nutanix et NetApp

Une action collective des entreprises qui ont souffert de l'incendie qui a détruit le centre de données SBG2 d'OVHcloud en 2021 a été retardée pour permettre à davantage de clients de se joindre. Ziegler & Associés avait prévu d'envoyer une lettre fin février, énonçant des demandes d'indemnisation aux clients d'OVHcloud dont les entreprises ont été affectées par l'incendie, mais maintient l'action ouverte jusqu'à la mi-avril, car davantage de clients se sont joints. Parallèlement, OVHcloud a enrichi son offre en lançant un service de cloud privé basé sur Nutanix et de stockage objet basé sur NetApp.

Plus d'un an après, OVHcloud n'a toujours pas formellement expliqué la cause de l'incendie. Un rapport des pompiers publié ce mois-ci souligne les défaillances dans le système de sécurité du bâtiment. Le bâtiment n’était notamment pas équipé d’un dispositif de coupure de l’électricité selon ce rapport : « la pérennité de l'alimentation électrique est un enjeu fort pour ce type d'exploitation. La conception intrinsèque de l'activité est faite pour éviter les coupures d'électricité. Deux niveaux de groupes électrogènes sont prévus pour palier une défaillance du réseau. Aucun organe de coupure d'urgence n'existe (choix de stratégie économique de l'entreprise) ».

Les pompiers n'ont pas pu couper l'électricité ni dans le local en flamme ni sur le site ce qui a favorisé la propagation de l'incendie.

Les pompiers évoquent également l'absence de système d'extinction automatique, le site misant sur une détection précoce et une alerte rapide des secours.

Autre défaillance : le fait que la direction d'OVH n'avait pas inscrit le site sur la liste des établissements répertoriés comme sensibles. Enfin, la présence d'une seule bouche d'incendie dans ce quartier du port autonome de Strasbourg.

Néanmoins, OVHcloud a indiqué qu'il ne fournira pas de communiqué officiel tant qu'il n'aura pas obtenu l'autorisation de ses assureurs et des agences gouvernementales.

Ziegler & Associés soutient pour sa part qu'OVHcloud a fait preuve de négligence dans les domaines évoqués dans ce rapport et n'a pas offert de compensation suffisante. Jusqu'à présent, Ziegler rapporte que 130 entreprises se sont inscrites pour son recours collectif, mais a déclaré cette semaine que sa lettre officielle à OVHcloud a été retardée car « de plus en plus d'entreprises » s'inscrivent, et Ziegler évalue une demande spécifique pour chacune d'elles. La lettre de recours collectif est actuellement attendue à la mi-avril.


Les entreprises qui participent au recours collectif contre OVHcloud sont de divers secteurs : comptabilité, marketing, santé et tourisme. Un accord de confidentialité les lie au cabinet Ziegler & Associés. En vertu de ce dernier, leurs noms sont tenus secrets. L’autre dénominateur commun entre ces personnes morales est qu’elles rapportent des pertes de leurs bases de données suite à l’incendie du mois de mars. Le tableau de l’après incendie c’est un acteur du secteur de la santé qui se retrouve sans aucune information associée aux patients ou une entreprise touristique qui ne sait plus retrouver les détails de réservations de ses clients.

En parallèle du recours collectif suite à l'incendie d'OVH à Strasbourg, un groupe du Cac 40 et trois sociétés de plus de 10 000 salariés ont décidé de porter une action de façon individuelle.

Chaque client figurant sur la liste finale verra ses pertes évaluées individuellement, y compris les coûts financiers directs et les dommages causés à leurs marques, avant que Ziegler n'envoie sa lettre. Le cabinet laissera un mois à OVHcloud pour trouver un accord à l'amiable, sous peine de saisir le tribunal de commerce.

« L'objectif est de démontrer que la situation d'OVH n'est plus tenable, et qu'elle devra passer par une discussion amiable si elle ne veut pas un procès perdant », a indiqué Jocelyn Ziegler.

« Les organismes qui ont rejoint le recours collectif en ont assez de la réaction d'OVH. La plupart ont reçu des courriers dans lesquels le groupe indique qu'il se dégage de sa responsabilité ou se limite à une clause de limitation de responsabilité. Ils demandent à OVH de reconnaître le préjudice et les indemniser », a déclaré Ziegler.

Pendant ce temps, les activités normales se poursuivent du côté d'OVHcloud qui a lancé deux autres services.


Un service de cloud privé hébergé basé sur la plateforme cloud Nutanix est conçu pour permettre aux clients de migrer rapidement entre les centres de données privés et le cloud en mettant en place une architecture cloud hybride. Plus tôt ce mois-ci, OVHcloud a également lancé un service de stockage de fichiers d'entreprise optimisé par NetApp.

Le service basé sur Nutanix est préinstallé et offre aux clients un matériel dédié dans l'infrastructure OVHcloud « en quelques heures », afin qu'ils puissent évoluer en fonction des demandes saisonnières ou mettre en place une sauvegarde dans le cloud. Les clients Nutanix peuvent lier leurs services OVHcloud à la Nutanix Cloud Platform. Le service Nutanix s'exécute sur le logiciel d'infrastructure hyperconvergée de Nutanix.

Le service de stockage de fichiers d'entreprise basé sur NetApp est destiné à fournir un service de stockage haute disponibilité aux clients exécutant dans le cloud ou utilisant NetApp sur site. Il est basé sur la technologie de système de fichiers Ontap de NetApp et est entièrement géré par OVHcloud.

Présentation de la solution technique

Rappel sur la définition d’un nœud

Une solution Nutanix est composée de ce que l’on appelle des nœuds. En pratique, un nœud est un ordinateur physique. Sur cet ordinateur, on retrouve :
  • Un disque système ou deux disques systèmes en RAID. Sur ce disque système est installé l’hyperviseur AHV.
  • Un disque SSD ou est stocké la CVM (machine virtuelle qui assure les connexions entre chaque nœud et qui est une composante essentielle de la solution Nutanix). L’espace disque restant éventuellement disponible peut servir pour le stockage de données.
  • D’autres disques SSD ou SAS, avec un coût de licence différent en fonction de la technologie de stockage choisie.
  • Un ou plusieurs processeurs.
  • De la mémoire.
  • Parfois une carte graphique GPU (Graphical Processor Unit).

Dans l’idéal, chaque nœud d’un cluster Nutanix doit être identique. Il peut néanmoins arriver qu’il y ait des différences, notamment lorsqu’un GPU est présent. Cependant, les nœuds qui contiennent du stockage doivent être identiques.

Fonctionnement du cluster Nutanix

Un cluster est créé à partir des nœuds du cluster. Il faut au minimum 3 nœuds pour faire fonctionner un cluster Nutanix.

Lors de la création d’un cluster, tous les disques disponibles sont ajoutés dans ce que l’on appelle un Storage POOL. Nous recommandons de n’avoir qu’un seul Storage POOL.

Pour rappel, la solution Nutanix d’OVHcloud commence à partir de 3 nœuds et peut aller jusqu’à 18 nœuds.

La redondance des données ne se fait pas sur un nœud comme avec du RAID, mais au travers du réseau sur plusieurs nœuds.

Il y a plusieurs niveaux de redondances :
  • RF2: les données sont disponibles sur 2 nœuds, ce qui permet la défaillance d’un nœud ou d’un disque de données sur un des nœuds.
  • RF3: Les données sont disponibles sur 3 nœuds. Cette solution n’est possible qu’à partir de 5 nœuds, elle est plus sécurisée car elle permet la perte de deux nœuds avec une capacité de stockage moindre.

Présentation de la virtualisation

La virtualisation se fait au travers de l’hyperviseur AHV. Cet hyperviseur est intégré sur chaque nœud et ne nécessite pas de licence supplémentaire.

Les ordinateurs virtuels fonctionnent sur un des nœuds et peuvent basculer à chaud d’un nœud à l’autre en fonctionnement normal.

En cas de défaillance d’un nœud, les ordinateurs virtuels redémarrent sur un des nœuds.

Liste des possibilités de connexion à un cluster Nutanix
  • À partir de l’interface WEB Prism Central (machine virtuelle supplémentaire qui possède des fonctionnalités que n’a pas Prism Element et qui permet de se connecter à un ou plusieurs clusters).
  • Sur l’interface WEB Prism ELEMENT (il s’agit en réalité d’une des CVM).
  • En SSH sur le cluster (dans ce cas-là, il s’agit aussi d’une des CVM).
  • En SSH sur un des nœuds du cluster pour des opérations de maitenance sur l’hyperviseur.


Au travers de Prism Central et de Prism Element, il est possible d’utiliser l’interface RESTAPI pour automatiser certaines tâches en ligne de commande.

Sources : Ziegler & Associés, OVHcloud
12  0 
Avatar de petitours
Membre expérimenté https://www.developpez.com
Le 07/12/2021 à 19:25
« Il semble que les consommateurs à l’échelle globale ne comprennent pas notre offre. Cela fait déjà trop de discussions autour de cet aspect. Nous ne voulons pas nous enfoncer dans cette brèche. Nous allons plutôt revoir la sécurité à la hausse en offrant le plus haut niveau de sauvegarde pour tous nos clients de tous nos centres de données. Cela va changer les standards de l’industrie, ainsi que notre façon d’offrir nos services »
Çà c'est se moquer du monde.

Changer les standards de l'industrie en ne laissant pas la sauvegarde au même endroit que les données à protéger même l'amateur qui recherche "sauvegarde" sur son moteur de recherche préféré trouvera dés la première réponse le principe élémentaire du 3-2-1, non respecté par OVH.

Ok c'est une faute importante de la part des clients que de confier au prestataire A la sauvegarde de ses données qui sont déjà chez le prestataire A mais prétendre être dans les standards de l'industrie avec leurs sauvegardes locales c'est se moquer du monde.
D'ailleurs ils disent qu'il y a des sauvegardes qui ont été perdues mais vu ce qu'elles sont devenues et cet endroit stupide où elles étaient on est en droit d'imaginer qu'elles n'existaient pas du tout les sauvegardes.
11  0