Discussion :

[xavier.valentin]

Ben non justement, ceux qui ont eux les problèmes sont sont qui ont pris des VPS, des VM mais n'ont pas pris les services de sauvegarde et/ou redondance entre DC.

Ceux qui étaient en mutualisé ont eu peu de probs, mise à part un retard dans l'acheminement des mails et un ralentissement des autres services suite à la charge accrue sur les autres DC.

Cela n’empêche pas OVH d'avoir des tords si ils n'ont pas servis à leurs clients la qualité et disponibilité de service défini dans leur contrat. Par exemple dans le cas des sites Web mutualisés et des services mails, il y a des sauvegardes automatiques mais non contractuelles. Et je ne pense pas qu'il y ai de GTR sur ce type de service. Pour les pros, pour av

Et leur image de marque en a pris un coup de toute façon.

Les services impactés sont des services dédiés aux professionnels. Si un professionnel n'est pas capable de préparer un PRA, ou éventuellement déléguer, il a au moins une co-responsabilié.

Le problème est que les 2 datacenters concernés n'avaient pas que des VM et des VPS. (ou autres offres low cost)

Mais également des Hosted Private Cloud : https://www.ovhcloud.com/fr/enterpri...-cloud/prices/
(l'offre commence à plus de 1000 € HT/ mois et après c'est no limit)
Qui sont des offres avec de nombreux services inclus (dont les sauvegardes - comme tu peux le voir dans l'image ci dessous)

Le problème est qu'OVH est certifié ISO 27001&HDS, certifié SOC et j'en passe... (https://www.ovhcloud.com/fr/enterpri...ty-compliance/) Ce qui oblige d'avoir des sauvegardes, comme tout hébergeur sérieux, sur des sites séparé de 45km



Hors OVH a bien fait des sauvegardes, y compris pour les Private Cloud
Le problème c'est qu'elles ont été faites dans le même datacenter et sans respecter les règles les plus élémentaires d'éloignement des sauvegardes... ce qui a rendu ces sauvegardes totalement inutiles. (car entièrement détruites)

Ce qui me gène c'est que le professionnel qui a souscrit chez OVH un private Cloud à 3000 €HT/mois et avec des sauvegardes, pour avoir un PRA, est comme un con. Et qu'OVH au lieu de dire que son propre PRA est un lamentable échec, renvoie la faute sur ce même professionnel qui lui faisait confiance.

Mais il faut être honnête également, c'est une catastrophe pour OVH, mais également pour les professionnels impactés. Mais le fautif, et Octave l'a bien dit dans son interview, est la conception d'ancienne génération de ces datacenters et le système de sauvegarde dans le même DC.

PS : je ne suis pas chez OVH, et je ne suis pas impacté par ce problème.

[chrtophe]

Le problème c'est qu'elles ont été faites dans le même datacenter et sans respecter les règles les plus élémentaires d'éloignement des sauvegardes

Ce qui n'est pas clair dans le doc c'est si les services et les sauvegardes concernent les mêmes clients. Si c’est le cas, les clients auront perdus les deux, si ce n'est pas le cas certains auront perdus leur services et devront restaurer les sauvegardes, d'autres devront refaire leurs sauvegardes.

Le problème est qu'OVH est certifié ISO 27001

Je ne connais pas exactement la norme, mais si ils l'ont obtenu, je suppose qu'ils répondent aux critères de celle-ci.
Je suppose aussi que sur les offres private cloud, tu peux choisir ton datacenter, et celui ou tu stockes tes sauvegardes.

46% des entreprises n'ont pas de PRA. Je parlais de co-responsabilité car ceux qui ont tout perdu n'ont probablement pas de PRA.
Et sur ce type d'offre (private cloud cher), il est recommandé de redonder sur un autre cloud. Mais ça c'est pour les très gros.

[Escapetiger]

Cela n’empêche pas OVH d'avoir des tords si ils n'ont pas servis à leurs clients la qualité et disponibilité de service défini dans leur contrat. Par exemple dans le cas des sites Web mutualisés et des services mails, il y a des sauvegardes automatiques mais non contractuelles. Et je ne pense pas qu'il y ai de GTR sur ce type de service. Pour les pros, pour av

Et leur image de marque en a pris un coup de toute façon.

Les services impactés sont des services dédiés aux professionnels. Si un professionnel n'est pas capable de préparer un PRA, ou éventuellement déléguer, il a au moins une co-responsabilié.

J'en profite pour nos chères lectrices et lecteurs (et moi-même) avec tous ces acronymes sigles :

GTR Garantie de Temps de Rétablissement qui fait partie d'un PRA Plan de Reprise d' Activité (également appelé PRI Plan de Reprise Informatique et plus connu en anglais en tant que DRP Disaster Recovery Plan)

Il est important de connaître les différents concepts et niveaux, voir ci-après par exemple :

Préface de Bruno BROCHETON - Vice-Président du CIGREF (Réseau de Grandes Entreprises) et Chief Information Officer d'Euro Disney.
Ce livre s'adresse principalement aux Responsables des risques et de la continuité (RPCA, Risks Managers, RSSI), aux Di...

Plan de Continuité d'Activité Concepts et démarche - Correspondance français-anglais - Open mediabook - Editions ENI

[Patrick Ruiz]

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 ?

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

[user056478426]

Que dire ?

[Michael Guilloux]

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

L'enquête relative à l'incendie sur les installations d'OVHcloud à Strasbourg est en cours, mais elle ne devrait pas livrer ses conclusions de sitôt. Essayant de redorer l'image de son entreprise après un sinistre qui a soulevé de nombreuses critiques, y compris sur la politique de sauvegarde des données des clients, Octave Klaba a annoncé de nouvelles mesures. Il promet par exemple la création d'un laboratoire de test pour modéliser les effets des incendies de datacenters. Mais ce n'est pas tout.

Deux semaines après l'incident, l'entreprise travaille d'arrache-pied pour qu'enfin tous ses datacenters soient de nouveau en service. Du moins, ceux qui sont encore utilisables, notamment SBG3 et SGB4 qui n'ont pas été touchés par le feu. Le datacenter SBG2 a été entièrement détruit, donc irrécupérable. Quant au datacenter SBG1, il a été en partie touché. Et avec l'épaisse nuée de fumée qui s'y est dégagée il y a quelques jours, OVHcloud n'est pas sûr de vouloir le remettre en service.

De leur côté, la police judiciaire et les experts en assurance mènent leurs enquêtes, pour faire la lumière sur les circonstances qui ont déclenché l'incendie. « Il faudra attendre des mois pour avoir les conclusions sur les causes de cet incident. Nous en communiquerons les résultats dès que nous les aurons », explique Octave Klaba dans une récente vidéo publiée sur Twitter. Vu sa promesse de tout faire désormais pour qu'une telle situation « n'arrive plus jamais », le PDG a d'OVHcloud a décidé de ne pas attendre les conclusions de l'enquête. Tentant de redorer l'image de son entreprise, il a annoncé un certain nombre de mesures, y compris la création d'un laboratoire de test pour modéliser les effets des incendies de datacenters.

Octave Klaba compte mettre sur pied un laboratoire d'essai qui étudiera les départs de feu dans les datacenters, leur modèle de propagation et les moyens les plus efficaces de les éteindre. Et les résultats de ces simulations en laboratoire, OVHcloud envisage de les partager avec les autres fournisseurs de cloud « de sorte qu’un incendie ne se reproduise plus non seulement chez nous, mais aussi dans toute la profession des datacenters », explique le PDG de l'entreprise d'hébergement Web. Il rappelle en effet qu'on n'éteint pas de la même façon un feu selon qu'il provienne des serveurs ou qu'il soit d'origine électrique.

Octave Klaba

OVHcloud a également décidé de renforcer les mesures de sécurité incendie dans tous ses datacenters et discuter avec l’ensemble de la communauté des datacenters pour faire évoluer les standards de protection. Octave Klaba voudrait par exemple changer le mode de refroidissement des salles de serveurs à l’intérieur du datacenter. Le standard aujourd’hui est le « free cooling ». Également désigné par « système de refroidissement passif », le free cooling consiste à refroidir naturellement un bâtiment tout en étant parfaitement respectueux de l'environnement, c'est-à-dire en utilisant l’air extérieur. En période de chaleur, ce procédé naturel est complété par la climatisation.

D'après Octave Klaba, OVHcloud a utilisé ce standard jusqu’en 2016, avant de passer à un système maison de refroidissement à l'eau comme pour ses serveurs. « Nous avons décidé de mettre ce procédé dans le domaine open source, l’ouvrant ainsi à tous les opérateurs de datacenters », a-t-il ajouté.

En ce qui concerne le retour à la normale, Octave Klaba promet que cela sera effectif à la fin de la semaine ou au début de la semaine prochaine. OVHcloud, qui fabrique ses propres serveurs, en a déjà produit 5000 depuis l’incident selon Octave Klaba, et devrait en faire encore entre 10 000 à 15 000 dans les deux semaines à venir. « Ces serveurs vont, selon les choix de migration des clients touchés, sur les datacenters de Roubaix, Gravelines, Francfort, Londres ou Varsovie », dit-il.

Source : Octave Klaba

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

[toutwd]

Je ne comprends pas bien l’intérêt.
Au final, cet incendie a t'il plus impacté le patrimoine d'OVH ou ses clients ?
Si créer un laboratoire est bon pour l'image de l'entreprise du futur, je ne pense pas que cela permettra pas de rétablir la confiance du présent.
Ce qui a brûlé, c'est du hard, c'est du soft mais c'est surtout une partie du crédit de la société.
Je crois que les sociétés, les professionnels qui ont "tout perdu" vont allez voir d'autres hébergeurs et leur première question sera: "hormis les back-up payant, disposez-vous de sauvegardes générales redondantes digne de ce nom" ?
Des laboratoires d'expertises et des centres de recherches performants et professionnels contre l'incendie existent déjà, il suffit d'en mandater un, à chacun son métier non ?

[Fleur en plastique]

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.

[Anselme45]

Ce ne serait pas plus "productif" de simplement ajouter à leurs datacenters un système anti-incendie efficace comme c'est le cas dans tous les datacenters sérieux?

Ou pourquoi pas, soyons fou, de ne pas mettre les serveurs et leur backup dans le même local?

[Levure]

Donc en 2017, OVH annonce ceci :

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

Et en 2021, rien n'a été apparemment fait :

• Il n'y a toujours qu'une seule alimentation électrique pour l'ensemble du site de Strasbourg.
• SBG1 et SBG4 sont toujours là. (Ce n'est que maintenant qu'ils vont fermer SBG1 et déplacer une partie des serveurs de SBG1 vers SBG4)

Pire, OVHCloud a annoncé qu'ils allaient alimenter SBG4 (électricité et réseau) à partir de SBG3.
Il n'y a aucune redondance sur le datacenter de Strasbourg, c'est effrayant. Le site de Strasbourg est clairement un site à éviter en l'état.

Et quand à la climatisation des salles via un refroidissement à eau, OVH n'a rien inventé : ça existe déjà chez Scaleway (DC5) : https://lafibre.info/scaleway/dc5/

Enfin, la dernière annonce d'OVHCloud de vouloir "faire évoluer les standards de protection" fait rire (jaune)...
Qu'ils implémentent déjà les principes de base existants de l'agencement et la gestion d'un datacenter et qu'ils soient plus transparents sur l'éventuel backup de leurs hébergements ainsi que leurs offres payantes de backup (réplications éventuelles et lieux de stockages des backups), ce sera déjà un énorme pas en avant...
..
OVHCloud c'est du low-cost, et le low-cost - il n'y a pas de magie - ca se fait toujours au détriment de l'un ou l'autre élément.
Je ne comprends pas comment on a pu reconnaître OVHcloud comme fournisseur de cloud souverain.

[petitours]

C'est juste incroyable.

Ils n'ont pas mis en place la moindre des bonnes pratiques connues par des tas de gens compétents (salles inertées, locaux électriques coupe feu avec les installations électriques sous sprinklage (par exemple) pour éviter une propagation à la prod, et j'en passe beaucoup) et ils nous disent qu'ils vont faire de la recherche pour réinventer ce que tout un tas de gens compétents maitrisent parfaitement ?

Faut être gonflé pour faire une annonce pareil, n'importe qui qui a déjà fait une analyse des risques sur un process sait à quel point cette annonce est ridicule.

[Leruas]

Donc en 2017, OVH annonce ceci :



Et en 2021, rien n'a été apparemment fait :

• Il n'y a toujours qu'une seule alimentation électrique pour l'ensemble du site de Strasbourg.
• SBG1 et SBG4 sont toujours là. (Ce n'est que maintenant qu'ils vont fermer SBG1 et déplacer une partie des serveurs de SBG1 vers SBG4)

Pire, OVHCloud a annoncé qu'ils allaient alimenter SBG4 (électricité et réseau) à partir de SBG3.
Il n'y a aucune redondance sur le datacenter de Strasbourg, c'est effrayant. Le site de Strasbourg est clairement un site à éviter en l'état.

Et quand à la climatisation des salles via un refroidissement à eau, OVH n'a rien inventé : ça existe déjà chez Scaleway (DC5) : https://lafibre.info/scaleway/dc5/

Enfin, la dernière annonce d'OVHCloud de vouloir "faire évoluer les standards de protection" fait rire (jaune)...
Qu'ils implémentent déjà les principes de base existants de l'agencement et la gestion d'un datacenter et qu'ils soient plus transparents sur l'éventuel backup de leurs hébergements ainsi que leurs offres payantes de backup (réplications éventuelles et lieux de stockages des backups), ce sera déjà un énorme pas en avant...
..
OVHCloud c'est du low-cost, et le low-cost - il n'y a pas de magie - ca se fait toujours au détriment de l'un ou l'autre élément.
Je ne comprends pas comment on a pu reconnaître OVHcloud comme fournisseur de cloud souverain.

Il y a des offres "premium" chez OVH, le Private Cloud par exemple coutant au minimum 1000€ / mois (pas spécialement moins cher que la concurrence), à première vue les Private Cloud étaient stockés de la même façon que les serveurs hébergeant des sites lambdas à 5€/mois ou des instances VPS/Public Cloud.
Le plus étonnant étant surement que des serveurs Private Cloud (PCC) de Strasbourg se sont retrouvés mis dans des vieux containers maritimes. J'imagine que les clients en question n'était pas au courant que leur PCC était dans un container maritime au milieu d'un terrain vague alimenté juste par un gros câble électrique. (Et que la backup Veeam était dans le container maritime d'à côté...).

[petitours]

Il y a des offres "premium" chez OVH, le Private Cloud par exemple coutant au minimum 1000€ / mois (pas spécialement moins cher que la concurrence), à première vue les Private Cloud étaient stockés de la même façon que les serveurs hébergeant des sites lambdas à 5€/mois ou des instances VPS/Public Cloud.
Le plus étonnant étant surement que des serveurs Private Cloud (PCC) de Strasbourg se sont retrouvés mis dans des vieux containers maritimes. J'imagine que les clients en question n'était pas au courant que leur PCC était dans un container maritime au milieu d'un terrain vague alimenté juste par un gros câble électrique. (Et que la backup Veeam était dans le container maritime d'à côté...).

Il y a forcément une question de coût/valeur ajouté qui justifierait très légitiment pourquoi certaines infrastructures sont mieux protégées que d'autres.
Pour moi rien de choquant à dire là que l'on a des installations low cost où on vous garanti rien du tout, même si certaines choses (comme isoler les installations électriques du reste) ne coute pas plus cher que de les mettre à un endroit ou ça peut se propager.

Mais là la question n'est pas là. Il est ici question de faire de la recherche pour trouver des solutions contre de tels incendies. Les solutions existent et sont parfaitement connues de pleins de gens spécialisés là dedans !

Un exemple très courant dans l'industrie métallurgique ou agroalimentaire où il y a des outils de production monstrueux, très couteux et tellement spécifiques qu'ils peuvent être irremplaçables (comme des données) ; les assureurs font déplacer les alimentations électrique pour les éloigner des process et de puissants sprinklages sont mis en place pour neutraliser totalement l'installation électrique en cas de départ de feu. L’assureur sait qu'il va massacrer l'alimentation électrique mais ça il sait le remplacer facilement et il sait aussi fournir des 10n de MW de puissance avec des camions générateurs le temps des réparations.
Chez OVH c'est pareil. Les infras fibres sont ultra précieuses, les datas pareil, les serveurs un peu moins et l'alim élec représente queudal car très facilement remplacée. Et comme partout les départs de feu sont plus probables sur les appareils énergétiques (onduleurs, groupes froids et compresseurs, protections...), les fameux trucs les plus faciles à remplacer.

Autre solution technique trés répandu avec les armoire électrique inertées. si départ de feu dans l'armoire elle st automatiquement noyée dans l'azote pour stopper le feu. J'ai vu ça sur des 10n d'armoire de machines critiques dans l'industrie et je suis même rentré dans un local serveur d'une usine (15m² le truc) où toute la salle était équipée du même système d'inertage à l'azote. En cas d'alarme on avait quelques secondes pour quitter la salle.

Soit on évite la propagation des flammes, soit on protège ce qui est précieux, soit on fait les 2 (en gros) et l'analyse des risque indique aussi ce qu'il faut remplacer et comment le cas échéant.

Ça fait 20 ans que je bosse dans l'industrie lourde et vois des spécialistes du risque industriel mettre en place des infras et je vous garantis que les solutions méthodologiques et techniques sont là ; ce labo d’étude et simulation est un gag de communication.

[Sylvain_LD]

Ce ne serait pas plus "productif" de simplement ajouter à leurs datacenters un système anti-incendie efficace comme c'est le cas dans tous les datacenters sérieux?

Ou pourquoi pas, soyons fou, de ne pas mettre les serveurs et leur backup dans le même local?

Je ne pesais vraiment pas qu'OVH était amateur à ce point! Se vanter d'âtre le N°1 et avoir des systèmes concentrés au même endroit sans redondance miroir ça fait vraiment guignol!
Le B A BA de la sécutité des systèmes informatiques bafoué!

[Mingolito]

Et voila comment on gagne des centaines de millions : faire croire aux gogos qu'on leur vends un cloud haut de gamme, en réalité en ne faisant qu'entasser n'importe comment des serveurs pas cher dans un container maritime avec une infrastructure électrique en toc, aucune sécurité incendie, et pire encore en mettant les sauvegardes sur le même site ce qui est profondément idiot.

Vu que sa réputation est grillée, Octave n'a plus qu'à fuir la France et partir du Costa Rica avec le mago

[pierre.E]

il est mur pour faire de la politique celui la
ps j ai pas cité un parti bien que ca me démangeait

[ManPaq]

https://fr.wikipedia.org/wiki/Uptime_Institute
Uptime Institute est connu en particulier pour avoir défini la notion de « Tier » pour les centres de données, largement adopté dans le monde.
ovh va plus loin: Nos datacentres de GSW et DC1 (Paris 19ème) sont sécurisés contre les intrusions. Des caméras couplées à des détecteurs de mouvements enregistrent le moindre mouvement à l’intérieur et à l’extérieur du bâtiment et présentent ces images en temps réel à des vigiles postés dans le datacentre. Pour accéder au datacentre, il est nécessaire de franchir un accès contrôlé par une procédure de sécurité renforcée. Un système de détection de flammes et de fumées par laser permet d’éviter tout risque de départ d’incendie.
« Respirer Paris, cela conserve l’âme »
Victor Hugo

[chrtophe]

ovh va plus loin: Nos datacentres de GSW et DC1 (Paris 19ème) sont sécurisés contre les intrusions.....

Sauf que là on parle des DC de Strasbourg.

Apparemment SGB1 ne sera pas redémarré et abandonné. Je pense qu'ils ont pris la bonne décisions par rapport au bad buzz.

[petitours]

https://fr.wikipedia.org/wiki/Uptime_Institute
Uptime Institute est connu en particulier pour avoir défini la notion de « Tier » pour les centres de données, largement adopté dans le monde.
ovh va plus loin: Nos datacentres de GSW et DC1 (Paris 19ème) sont sécurisés contre les intrusions. Des caméras couplées à des détecteurs de mouvements enregistrent le moindre mouvement à l’intérieur et à l’extérieur du bâtiment et présentent ces images en temps réel à des vigiles postés dans le datacentre. Pour accéder au datacentre, il est nécessaire de franchir un accès contrôlé par une procédure de sécurité renforcée. Un système de détection de flammes et de fumées par laser permet d’éviter tout risque de départ d’incendie.
« Respirer Paris, cela conserve l’âme »
Victor Hugo

Ce truc parle surtout d'exploitation courante, des choses très informatiques, seul le dernier niveau évoque les sinistres. et est très peu détaillé, le cloisonnement coup feu par exemple ça veut tout et rien dire. Dans une vraie analyse des risque il y a la durée d'isolement au feu, qui est mis en rapport avec les moyens de lutte contre le feu du site.
Le Wiki n'evoque pas la notion d'analyse de risque, de moyens de lutte contre le feu, de temps de panne sur sinistre majeur, de pra... Soit ce Wiki est trés light sur le "ultime_institute", soit ce n'est pas vachement sérieux.

Cameras et aux procédures d’accès ; ça ne change rien au problème de l'onduleur qui peut mettre le feu au datacenter et détruire les infra fibre... Ils auraient eu une procédure contre les glissades après nettoyage des sols là j'aurais été impressionné

Détection de flammes et de fumées par laser ; ouais super, il y a pleins d'autres moyens de détection qui peuvent être bien meilleurs dans beaucoup de cas, du préventif aussi avec le rapport Q19 (thermographie infrarouge) qui permet d'anticiper pas mal de départs de feu. Bref le risque de feu est un sujet à part entière et il n'y a pas besoin de labo de recherche pour travailler sur le sujet.

[Stéphane le calme]

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 1^er 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