Hier l'hébergeur a continué à communiquer sur l'évolution de la situation de son site de Strasbourg, partiellement détruit. Des emails ont été envoyés aux clients touchés, une FAQ a été mise en ligne, le service « email pro » a été rétabli sans perte de données promet Michel Paulin.
En fin d'après-midi, Octave Klaba prenait la parole dans une vidéo pour s'excuser auprès des clients et confirmer qu'une remise en service des salles progressivement réparées est attendue à partir de la semaine prochaine. Un état des lieux est encore en cours, devant permettre de préciser à chaque client le statut de ses machines/services « dans 48 heures ». D'ici là, les autres datacenters de Gravelines et Roubaix sont mis à contribution, comme expliqué hier.
Il évoque aussi la conception de SBG2, entièrement détruit et qui avait été pensé pour réduire le refroidissement nécessaire, et donc l'impact énergétique, sous la forme d'une tour auto-ventilée. Ce qui n'a pas été le cas des suivants, comme SBG3.
La cause du départ de l'incendie n'est pas encore connue, l'enquête étant en cours. Mais Klaba précise qu'une intervention sur un onduleur a eu lieu dans la journée, avec de nombreux changements de pièces, celui-ci ayant été détecté par les pompiers comme l'un des éléments en feu dès leur arrivée (via des caméras thermiques).
On apprend également que lorsque le système anti-incendie a levé une alerte à 00h47, les équipes sont immédiatement intervenues, constatant la présence de beaucoup de fumée. Face au danger que cela représentait, décision avait été prise d'évacuer le datacenter.
L'objectif est donc désormais de comprendre la vitesse de propagation. 300 caméras étant présentes sur le site, leurs enregistrements vont être analysés pour savoir d'où le feu est parti, comment il s'est propagé et en tirer des conclusions.
Il faudra néanmoins attendre la conclusion de l'enquête et la publication d'un post-mortem technique par l'équipe pour savoir exactement ce qu'il en est et en tirer des conclusions sur des changements à opérer. « Et il y en a, c'est évident », conclut Klaba qui dit vouloir tout faire désormais pour qu'une telle situation « n'arrive plus jamais ».
Peu avant, plus de 36 heures après le premier tweet d'Octave Klaba concernant cet incident, on avait (enfin) des nouvelles du secrétaire d'État au numérique, Cédric O. Critiqué pour son silence tout au long de la journée, il a indiqué avoir parlé à Octave Klaba « pour lui dire [son] soutien aux équipes d’OVHcloud mobilisées sur le redémarrage des services affectés par l’incendie de Strasbourg. La #FrenchTech a besoin d’OVHcloud ! ». Il était suivi de peu par Agnès Pannier-Runacher, chargée de l'industrie.
Une déclaration qui, malgré les remerciements, cache mal la tension entre le secrétaire d'État et les hébergeurs, après des affaires comme le Health Data Hub (HDH), ou les déclarations qu'il tenait encore récemment dans une émission sur Club House (accessible en replay, dès 25').
Il y évoquait l'avance des acteurs américains dans le domaine du cloud et les milliards investis face à des acteurs français, écartant l'intérêt d'un soutien par la commande publique et renvoyant à l'échelon européen.
Une position remarquée des observateurs et acteurs du secteur, qui ont peu apprécié de se faire ainsi « jeter sous le bus » par leur secrétaire d'État, pour reprendre la formule de l'un de ceux que nous avons pu interroger.
Commentaires (100)
#1
Ah, si c’est dû à une opération de maintenance, il y a un sous-traitant/fabricant qui va probablement morfler.
En tout cas, cette transparence aura comme avantage :
Bon courage aux équipes.
PS : faudra penser à activer Windows dans l’image de la brève …
#1.1
Sauf si c’est une erreur humaine, et que le technicien est salarié OVH !
#1.2
De toutes façons comme très bien dit par Klaba, ce sera à l’enquête de déterminer les causes avec précisions, et donc les éventuelles responsabilités.
#2
Bien vu
#3
Comment une chose pareille peut arriver alors que les salles serveurs sont censées avoir un système d’extinction incendie gaz non destructif ?! Y’a une erreur quelque part là…
#3.1
Visiblement, il n’y a pas d’IEAG chez OVH :
https://lafibre.info/ovh-datacenter/ovh-et-la-protection-incendie/
Par ailleurs, la conception en cheminée pour favoriser la ventilation naturelle doit bien participer à la propagation du feu.
#3.2
Parce que tout se passe bien jusqu’à ce que tout se passe mal. Et que quoi que tu puisses anticiper, il peut toujours y avoir des ratés (aka le risque zéro n’existe pas).
Et les mécaniques à gaz que tu évoques quand elles sont implémentées sont en général temporisées et non automatiques (pour des raisons évidentes dans une zone où du personnel peut intervenir). Ce qui laisse le temps à l’incendie d’être trop avancé pour éventuellement intervenir (ce qui semble avoir été le cas ici).
Mais comme dit plus haut et à plusieurs occasions précédemment, ce sera aux experts de déterminer les causes et de faire leurs recommandations. Une telle enquête ne se fait pas sur la base d’impressions depuis l’extérieur armé d’un clavier sans détails techniques précis sur la situation
Attention quand même avec les reprises d’infos datant de plusieurs années, qui ne sont pas forcément le reflet de l’équipement du DC tel qu’il était mis en oeuvre à date de l’incident. (je ne sais pas s’il n’y a pas eu des travaux pour renforcer certains dispositifs depuis)
#3.3
Pas forcément ces datacenter sont conçu avec des systèmes de détection très performants. Dès qu’un dégagement de fumée est détecté il y a intervention en urgence, le plus souvent c’est une alim qui crame.
Une alim qui crame c’est courant, et ils vont pas inonder le datacenter a chaque alim qui crame. D’ailleurs le DC5 de Scaleway est conçu sur le même principe.
Ici le souci vient de la rapidité du depart, l’alarme se déclenche a 00h47,ils sont dans le bâtiment moins d’une minute plus tard mais il y a tellement de fumée (malgré la ventilation) qu’ils ne peuvent pas approcher du départ de feu. Ils évacuent.
Un feu qui dégage autant de fumée en moins de 2 minutes c’est excessivement rare et sûrement innatendu, il faudra attendre que l’enquête definisse le déroulement, feu caché qui a couvé plusieurs minutes avant (comme a notre dame), explosion d’un composant, autre…
L’onduleur est un client intéressant, il est dans une salle annexe et ses composants (batteries) s’enflamment vite et degagent énormément de fumée. Mais normalement il se protège de manière “autonome” il se coupe en cas de montée de température pour éviter de prendre feu.
C’est peut être tout autre chose.
#3.4
Tout dépend si ce sont des batteries au plomb ou au lithium. Les premières ne prennent pas feu facilement. Les secondes par contre peuvent très bien être de vraies torchères.
Je pense, comme toi, que l’hypothèse de l’onduleur se tient. L’enquête le dira de toutes.
#3.5
Le problème avec lui c’est qu’il à toujours l’air d’un Panda même quand tout va bien ahah
Même si en effet les journées doivent être longue, on sent surtout qu’il a pris un gros coup sur le crâne, les termes employés sont fort et ça va surement changer profondément la philosophie d’OVH à travers celle du patron.
C’est pas si simple, la batterie au plomb relâche de l’hydrogène en cas de défaillance (d’où la nécessité d’une bonne ventilation) et dans un UPS elles sont “scellées” le plus souvent, je ne sais pas comment réagit un pack batterie scellé qui explose. (et j’ai la flemme de fouiller la norme ahah)
Ensuite une fois un feu démarré c’est pas forcément le contenu de la batterie qui fume le plus mais les capotages et composants en plastique
https://www2.habasit.com/fr/fiche-de-securite-incendie.htm
J’ai souvenir que dans le ferroviaire nos normes Feu/Fumée affichaient des valeurs dingues, certaines plastiques génèrent plusieurs centaines de fois leur volume brulé en fumée dense et toxique. Et ça va très vite, raison pour laquelle la “charge” au feu d’un train (ou d’un avion) doit être très faible pour laisser le temps aux passager d’évacuer, donc tenir 5 à 15 minutes avant d’atteindre le point dangereux pour les passagers.
Et sur un feu, 5 à 15 minutes c’est une éternité.
#3.6
J’ai travaillé dans la maintenance ( courantfort/courant faible Detection incendie) sur des salles serveurs, après ce n’est peut être pas partout pareil, mais oui il y a des systemes très sensibles et a la premiere alerte ça ne déclenche pas le systeme, il faut une seconde détection. oui tout ça est temporisé mais c’est un système extrêmement efficace qui quoi qu’il arrive stoppera le feu par suppression de l’oxygène.
Les experts diront ce qu’il en est mais quand on est une entreprise se serveur on est censé être le mieux équipé, dans une petite entreprise je peux comprendre mais là…
#4
ça fera un bel article dans “face aux risques”.
Bon courage aux équipes d’OVH !
#5
Petite question : combien de data-centers brulent par an dans le monde ?
#6
Je sais bien que la crise est majeure chez OVHcloud comparée à d’autres interruptions de services chez d’autres acteurs de la tech française mais je salue la communication qu’ils ont mis en place et leur transparence contrôlée… Hmm… Iliad/Free est dans le coin ?
ça pourrait leur donner des idées, j’dis ça…
#7
Une opération sur un onduleur, avec changement de pièces, je pense surtout à un prestataire rien que pour des raisons d’assurance.
Ou alors on a trouvé Dédé la débrouille, il peut tout réparer avec de l’alu, du scotch et du WD40.
Merde, ça a été activé entre temps
#8
J’avais jamais noté son accent a Octave…
En tous cas l’exercice de transparence est appreciable, beaucoup devraient en prendre de la graine. Surtout avec la gueule fatiguée qu’il tirait…
Courage les mecs (et meufs, mais j’en doute)
#9
Aucun personnel, résultat personne pour remarquer le début d’un incendie, ou une odeur…
#9.1
Faudrait peut être lire les articles avant de commenter, il y a eut des employés dès le déclenchement.
Dans sa vidéo Octave donne même leur nom, c’est 2 techniciens et la personne “pompier” de service.
Leur boulot c’est de faire la maintenance et pas de regarder h24 s’il y a un onduleur ou une alimentation un peu chaude
#9.2
c’est fini en 2021 la détection par odeur avec un humain, c’est la détection par aspiration et c’est très performant. en 40 seconde ta détecté alors que robert risque de ne rien sentir avec la ventilation de la clim.
video interresante en condition dans une salle serveur
https://www.deftunisie.com/solution/detection-par-aspiration/
pour l’onduleur ce n’est pas des petits onduleurs que tu trouve dans le commerce, tu peux avoir dans les 500A qui débite sans problème dans ta clé plate de 13 :), la rapidité ne me surprend pas
#9.3
Exemple d’UPS utilisés chez OVH
https://twitter.com/olesovhcom/status/895893297981530112
#9.4
Ouaip du Eaton à batteries plomb scellées on dirait. Après rien ne dit qu’à l’epoque c’était ça qu’ils ont mis dans SBG2
Comme dirait le Commissaire Bialès : Écoutez, laissez la police faire son travail, dès que j’aurai de plus amples informations croyez bien que vous en serez les premiers informés.
😁
#9.5
C’était surtout pour illustrer le petit encombrement et la relative simplicité à éteindre un incendie sur un UPS industriel
Mais en effet, sur SBG2 rien ne dit qu’il s’agit de ceux-ci en particulier :)
Maintenant, s’ils étaient en maintenance avec “beaucoup de pièces remplacées” dixit Octave, il est fort probable qu’il n’était plus d’une fraiche jeunesse…
#9.6
De memoire sur les UPS qu’on a chez nous ils doivent changer les batteries toutes les quelques années ainsi que des composants des convertisseur DC/DC et DC/AC après j’en sais pas plus moi mon truc c’est la mécanique xD
#10
Ça valait le coup d’attendre !
#11
En tout cas, il a l’air fatigué, il n’a pas dû beaucoup dormir !
Courage à eux.
#12
Pardon ?
#12.1
On apprend plus de ses erreurs que de ses succès. En ce moment j’aurais plus confiance (après enquete) en OVH qu’en un autre hébergeur.
#13
“Il y évoquait l’avance des acteurs américains dans le domaine du cloud et les milliards investis face à des acteurs français, écartant l’intérêt d’un soutien par la commande publique et renvoyant à l’échelon européen.”
Ah parce que les USA et son budget (=dette) sans limite n’utilise pas massivement la commande publique lui (exemple avec l’armée)? Idéologue extrémiste et donc cocu le O?
#14
Si j’étais Octave Klaba, j’irais investir dans un pays qui veut voir réussir des gens modestes. Les dirigeants français ne se soucient pas de lui, c’est maintenant certain.
#15
Bin le “DC cheminée” pour favoriser le refroidissement, ils n’en ont visiblement fait que deux. Probable qu’ils aient vite pensé que c’était peut-être pas une si bonne idée et que l’argument écolo sur les gains énergétiques du refroidissement, après avoir saturé qq heures les capteurs de pollution de la métropole, ça le fait moins!
#16
#16.1
On peut déjà écarter celui d’OpenOffice…
#17
Oui, surtout que si ce sont des batteries au plomb, la fumée / acide est très dense et est très rapide. C’est vraiment impressionnant même sur des batteries de voitures, alors j’imagine même pas sûr les onduleurs de DC. J’ai vu les blocs lead acid en DC sur du matériel similaires, et même si ils sont scellés, il n’empêche qu’un gros accident est toujours possible.
#18
Moi mon interrogation c’est qu’il n’y a pas de site de réplication de ce datacenter ?
Franchement je m’attendais mieux venant d’OVH…
#19
Bien sûr qu’il y a redondance, mais on en a déjà parlé 20 fois dans les commentaires des différentes news, on va pas recommencer, d’autant que pas mal de gens mélangent tout (dédié, mutualisé, hébergement, stockage) alors que chaque type d’offre à son propre niveau de redondance.
#19.1
OK merci pour l’info. Je ne savais pas que ça dépendait de l’offre. Je pensais que c’était de base.
Par contre, de voir que certains backups étaient dans le même datacenter, là c’est plus problématique….
#20
Pas d’infos sur les sommes que OVH va verser à tous ceux qui leur faisaient confiance et qui ont tout perdu ?
#20.1
Message reçu cette nuit pour mon feu VPS :
J’ai reçu un message similaire pour mon dédié, mais 3 mois seulement car il est juste éteint, pas détruit.
Après, je ne sais pas ce qu’il en est pour les hébergements plus spécialisés comme les hébergements HDS (données de santé), où là, contractuellement, c’est beaucoup plus cadré et où la sauvegarde fait partie de la prestation (et donc de la responsabilité) d’OVH (mais beaucoup plus cher aussi !)
#20.3
Rip petit VPS
Pour le HDS ça concerne surtout la protection et le cloisonnement des données afin d’en garantir l’innaccessibilite (y compris par OVH). Cela reste des hôtes dédiés (physiques ou virtuel) donc à charge du souscripteur d’en faire ce qu’il souhaite, y compris sauvegarde.
#20.5
Doit garantir l’inaccessibilité ET la sécurité. Y compris la redondance dans le cadre hébergeur infogéreur. Contrairement au VPS, où OVH ne fait plus de sauvegarde, la mise à disposition d’un “VPS HDS” oblige à la sauvegarde. C’est dans la certification donc… obligatoire
#20.9
Ça dépend du niveau de certification
https://esante.gouv.fr/labels-certifications/hds/certification-des-hebergeurs-de-donnees-de-sante
#20.4
Même chose pour mon dédié, qui lui a été détruit, remise de 6x la facture de février.
En tous cas ils ont une bonne capacité de réaction car le nouveau dédié était disponible dans la minute.
#20.2
Si tu estime que OVH n’a pas respecté son contrat, et que la perte de tes données ont un impact financier majeur sur ton activité (que je suppose commerciale) c’est ton assurance qu’il faut contacter, elle se rapprochera des assurances de OVH pour t’indemniser à hauteur du préjudice subit. Mais ça restera à toi de prouver qu’OVH est contractuellement en tort vis à vis des services que tu as souscrit. Donc peut être mettre en jeu aussi la protection juridique si tu y a souscrit.
#20.6
Si tu confies ton enfant à l’école, et qu’elle prend feu et qu’ils te le rendent décédé, on va aussi dire “c’est pas leur faute, ils avaient juste l’obligation d’héberger, un incendie ça arrive”.
#20.7
Comparaison erronée, le personnel d’un établissement scolaire est responsable de la sécurité des enfants qu’il accueille.
#20.8
Ne fait pas l’amalgame entre pertes humaines et matériels, le matériel à défaut ça se remplace, et les données ça s’estime et s’indemnise mais n’a rien de vital. Et si c’était vital à mon entreprise, je ferais en sorte de ne pas mettre tous les œufs dans le même panier, et d’avoir à minima un backup des data hors infrastructure (et d’ailleurs c’est ce que je fais déjà… Je perds maxi 24h de boulot, et ça m’est déjà arrivé de perdre un serveur).
#21
Oui j’avoue me poser cette question et ne pas comprendre non plus.
#22
Tu as déjà entendu le proverbe “comparaison n’est pas raison” ?
#23
Conclusion il faut faire plusieurs enfants, et les mettre dans des écoles différentes.
#24
Ou faire des clones de sauvegarde qu’on réveille en cas de pertes
#24.1
Je valide les clones, et en sommeil si possible durant leur phase d’inutilité
#25
À tout ceux qui s’interrogent : comment cela est-il possible ?
Si le feu a véritablement pris au niveau d’un ou plusieurs onduleurs, il faut que vous réfléchissiez à la puissance des batteries qui sont installées derrière l’onduleur.
Si chacun réalise aisément que l’essence est inflammable, la plupart ignore la puissance d’un feu électrique.
Si les pompiers râlent contre les véhicules électriques, ce n’est pas pour rien. Timo (le Hollandais Volant) a plusieurs fois évoqué dans ses blogs la densité d’énergie que représentent des batteries haute-performance. Il est plus facile de mettre de la mousse carbonique sur un feu de pétrole que de stopper un feu électrique, en particulier si une forte puissance est disponible.
Les analyses de risque sont évidemment vitales. Néanmoins, aucune analyse de risque n’est parfaite et on apprend toujours des erreurs d’appréciation passées. Sur ce point, je suis sûr qu’OVH va fortement progresser mais également les autres (s’ils sont intelligents).
C’est exactement ce qui est fait dans l’aéronautique : les rapports sont publics et de nombreuses personnes et entreprises les lisent pour apprendre.
Personnellement, je lis régulièrement les rapports d’accident d’avion alors que mon secteur industriel est l’industrie pharmaceutique. Certaines erreurs - souvent causées par des biais cognitifs - sont aisément transposables dans différents contextes industriels.
Je trouve désolant le grand nombre de critique à l’encontre d’OVH alors que ce prestataire est toujours très transparent lorsqu’il y a des problèmes.
À ceux qui pensent qu’OVH ne fait que du bricolage, je leur rappelle que lorsqu’il y a eu une très violente attaque DDOS (Mirai), OVH a très honorablement résisté (même si les performances de l’infrastructure ont souffert) contrairement à d’autres prestataires - en particulier US - qui se sont littéralement écroulés.
OVH a tenté des innovations dans la conception des data centres. L’histoire nous montre avec le recul certaines faiblesses qui d’ailleurs avaient sans doute déjà été identifiées puisque l’architecture de SBG2 n’est plus mise en œuvre par OVH depuis plusieurs années.
La conception d’un data centre est toujours le résultat d’un compromis entre sécurité, fonctionnalité, maintenabilité, écologie et espace disponible. La solution parfaite n’existe pas.
En tout état de cause, rien ne justifie, côté client, de ne pas faire de sauvegarde des données quelque soit les contrats souscrits, à plus forte raison lorsque le contrat n’inclut pas les sauvegardes.
Lorsque l’ouragan Sandy (Sandy storm) a ravagé la côte Est des USA (Automne 2012), de nombreux data centres ont été inondés et détruits, y compris dans le cas d’infrastructures redondantes et hautement disponibles. J’avais étudié ces cas avec un collègue US et nous avions supposé - avec optimisme - que l’industrie avait une bonne occasion d’apprendre de ses erreurs. Visiblement nous étions trop optimistes sur ce point.
PS: Je n’ai aucun intérêt chez OVH hors le fait que je suis client d’OVH.
#25.1
Pour comparer la puissance des ups et la difficulté de l’extinction incendie, nous avons actuellement le même souci sur les véhicules électriques. Le meilleur moyen étant l’immersion totale longue durée…
Pour un datacentre, a moins de mettre les onduleurs dans un caisson étanche les rendant immersible je ne vois pas… même avec un gaz inerte, ça n’empêchera pas une nouvelle amorce électrique dés que l’oxygène sera revenue.
#26
Au passage, j’avais vu passer souvent des questions concernant le RGPD et la perte des données personnelles. Le mail d’information d’OVH envoyé aux clients indique ceci :
#27
Un article fait le point sur les sauvegardes : Incendie chez OVH : les données ont-elles été sauvegardées ? (JDN : voir les tableaux)
#28
La plèbe s’en fout. Ce n’est qu’une bonne occasion de faire comme le reste de la troupe. Ce fumant théorème du singe qui baffe tout nouvel arrivant au bout de quelques itérations…
Comme pour les problèmes de sécurité. On trouvera toujours plus de “Rho les gros nazes” que de gens capables d’expliquer/documenter/reproduire plus finement une faille ou une autre. Et surtout diffuser la bonne information.
+1 C’est suffisamment rare pour être remarqué.
Ps: je n’en suis pas client non plus (avant que les simiesques ne s’y engouffrent)
#28.1
pour moi c’est juste la goutte d’eau qui fait déborder le vase .. cad qualité de service et “uptime” de leurs services toujours à la ramasse, pas une semaine depuis 3 ans que j’ai des problèmes pour un tel service ou autre ( tkt ça a fini par migré ailleurs qu’OVH ) . Et sans support ( si enfait support +7 jours de réponse ) maintenant faut payer 50€ / mois pour avoir le support apparemment.
Et là on te sort un datacenter écolo en bois paroi métallique ( qui fond hein au passage ) avec de la tole de conteneur ? avec un système antiincedie bien loin d’autres datacenter
ps : à titre perso j’utilise OVH pas cher etc, puis les pannes je m’en fiche sur les services que j’ai
#29
Comme le vol AF447 qui s’est gauffré en décrochant : théoriquement, l’A330 en cause n’était pas censé décrocher : l’équilibre de l’appareil + les systèmes de contrôle étaient censés l’en empêcher, malheureusement, les systèmes de contrôle reposaient entre autres sur les fameuses sondes Pitot qui ont givré et toutes donné des valeurs inexploitables pour le système. Puis les pilotes sont entrés en jeu et quand l’un d’eux s’est dit que l’avion était peut être en décrochage, il a poussé le manche vers l’avant … et la vitesse a permis aux sondes de fonctionner à nouveau et de détecter le décrochage => alarme et le pilote a re-tiré le manche, remettant l’appareil en décrochage.
Tu peux faire plein de choses, tu n’arriveras jamais à prouver qu’il ne peut pas y avoir d’erreur et d’accident.
#30
Ce qui est un peu chiant avec les pro-OVH (qu’ils soient clients ou non) c’est qu’on a toujours le même raisonnement à chaque panne/incident :
1 - “Ce n’est pas leur faute”
2 - “Vous avez vu comment Octave il communique vachement bien en direct ?”
3 - “Ca les fera progresser pour la prochaine fois”
C’est un peu le syndrôme No Man Sky, ce n’est pas parce que tu fais tout pour rattraper tes conneries que ça excuse le fait d’avoir fait une connerie…
Idem pour la générosité du remboursement. A titre perso j’avais un serveur Kimsufi chez eux :
1 - Ils viennent de m’annoncer la facturation du renouvellement mensuel ce matin (lol)
2 - On me propose d’avoir 6 mois de facturation actuelle offert en commandant un nouveau serveur chez eux sauf que…
2a - Pour le même prix actuellement on me propose une puissance divisée par deux, à défaut je dois doubler ma facturation en passant sur les serveur OVH directement
2b - Si je ne leur fais plus confiance et désire passer chez un autre prestataire il n’y a aucun dédommagement possible, 0, nada
Donc la générosité on y repassera… J’ai connu des offres promotionnelles de fidélisation plus généreuses que ça.
Dernière précision : si je résilie mon serveur Kimsufi qui a brûlé (pour la blague le monitoring OVH m’indique toujours “OK”) je ne suis pas remboursé de la facturation qui vient de tomber pour le mois à venir..
#30.1
En fait ni pro, ni contre.
C’est juste qu’on essaye de faire comprendre au plus démunis que “shit happens” même si on fait bien les choses impeccablement à un temps T.
La plupart n’entrave pas (littéralement) que même s’il y a des normes et tout le toutim il n’en reste pas moins que c’est un domaine qui pousse dans les limites physique. Comme dit ailleur ce n’est pas une friteuse qui prends feu dans la cuisine.
Je suppose qu’on le doit aux feuilletons TV ou les héros sont à deux doigts de crever dans un réacteur nucléaire. L’ADN du mec est en lambeau. Mais ho surprise, hop une piqûre du docteur bigCerebro et le héro se relève derechef et fait des entrechats dans la foulé.
C’est désolant.
#30.2
Si la facturation concerne un serveur qui a brulé ils devront clairement te rembourser, puisque le service n’existe pas.
J’ai déjà été facturé pour un renouvellement automatique juste au moment ou j’allai résiller un serveur.
Le support m’a immédiatement annulé la facture après de rapides explications, alors que techniquement ils n’avaient pas à le faire (dans ton cas ils doivent annuler ta facture ou te rembourser).
#30.3
il serait capable de faire ça au prorata .
mais bon vu que c’est automatique ce genre d’opération , faut faire un ticket support
#31
Ce qui est un peu chiant avec les bas du front, c’est que tous ceux qui ne sont pas d’accord avec eux sont forcément des ‘pro ceci’ ou des ‘anti cela’.
L’éventualité d’une opinion à la fois valable et différente de la leur est exclue d’emblée.
#32
Par ailleurs, pour avoir visité un autre de leur DC, basé sur la même archi (RBX4), ça n’est pas basé sur des conteneurs. Ils avaient encore un vieux DC en conteneur à Strasbourg, qui a été sorti du service en 2017 après la panne électrique.
PS: pour avoir vu quelques DC, dont beaucoup de DC internes de grosses boites qui gèrent elle-même cet aspect; crois moi, les DC d’OVH sont loin des DC au rabais que tu sembles évoquer
#32.1
Petit correction sans animosité, il reste 1 datacentre en conteneur, à savoir SBG1. Il est en projet de le migrer et de le démanteler.
Sinon SBG2 date de 2014, depuis ils ont fait d’énormes modifications dans la conception de leurs DC. Exemple SBG3 BHS. Ils sont moins condensés, plus compartimentés.
A savoir aussi que la majorité des DC New gen avec un bâtiment dédié intégralement à cet usage, même hors OVH sont des bâtiments industriels en ossature métalliques. Exemple interxion. Les anciens DC sont souvent bétonés car positionnés dans des sous sol ou des étages de bâtiments utilisés à d’autres fins.
#32.2
je parle de paroi ou les façade si tu préfères , regarde pendant l’incendie les énormes trou que le feu provoque dans l’acier ; permettant d’attiser le feu sur les étages encore au dessus
PS ; personnellement je disais que c’était la “goutte d’eau qui fait déborder le vase ” bien chanceux à vous si vous avez une bonne expérience avec OVH , mais j’avais tous les services qu’ils proposent sur plusieurs clients. Et ça se dégrade autant que le cuivre pourri par Orange
#33
*Plusieurs prestataires travaillent actuellement sur place (30 personnes)
Sur SBG3 c’est plus rassurant, on va peut-être avoir des surprises
#34
Le projet de démantelage vient de progresser de 33% d’un coup alors !
#35
Peut être t’étonneras tu :
Juste pour dire que l’on ne fait pas les choses sans raison. Des normes découlent les spécifications à respecter suivant chaque site, pays.
De plus comme il y a des sites SEVESO (seuil haut) à coté comme le disait un capitaine des pompiers… Il y a du y avoir un certain nombre de pré-requis à lever.
Et pour l’instant pendant que la plupart commente en se moquant, la gestion de la crise semble conforme. D’une part car il y a les assureurs qui ne vont pas manquer une occasion de relever la moindre erreur mais aussi l’état qui garde un œil dessus à cause des site SEVESO.
Maintenant ton problème que tu décris dans ton commentaire provoque une association non pertinente qui fait l’association de qualité de serveur (ou application d’ailleurs) avec l’entretien du site lui même. Avec en plus le principe de l’exception qui devient généralité. Je ne suis pas certain qu’on puisse aller par la.
Je pense qu’une société française qui fait de l’hébergement et qui a survécu jusqu’ici face à la concurrence intra-europe et américaine n’aurait pas pu le faire sans un minimum de sérieux.
Il y a des problèmes en tout genre dans ces sites industriels mais il y a un niveau de maintient bien supérieur à celui de la chaude intimité de la cage d’escalier du bâtiment B de la cité des arrache’moi’ca. En bref vivre dans un datacenter est parfois mieux ne serait-ce que pour la qualité de l’air. Étonnant non ?
#35.1
Le sérieux ça se dégrade ; ça a pu survivre jusqu’ici mais ils ont de gros problèmes interne
#35.2
pourquoi l’acier de conteneur ? un feu de batiment c’est plus de 1000° ; l’acier type conteneur se déforme à partir de 400°-500°, déjà que le type de batiment autoventilation accélère les flammes, avec une telle structure on attise le feu.
#35.3
SBG2 n’était pas fait de conteneur.
N’importe quelle structure, bois, acier, béton, fini par céder sous l’assaut des flammes.
Béton : résistance à la température très relative et dépendant de beaucoup de facteurs dont la qualité des produits et surtout du mélange homogène, rupture nette sans signes avant coureur. Vu les bétons coupés à la cendre qu’on nous fournis aujourd’hui, il y a de quoi avoir peur même sur de grandes infrastructures.
Acier : résistance à la température modére, déformation progressive, mais impossible de savoir quand l’affaissement aura lieu (voir façade du SBG2). Même si l’acier n’est pas homogène, il est plus solidaire sous l’effet de la chaleur que le béton, et donc plus sécurisé (exemple échafaudage de Notre Dame)
Bois : étrangement le plus retardateur, mais lorsque la température monte haut, ça devient un brasier (Notre Dame est l’exemple parfait, l’incendie à mis énormément de temps à être décelé avant le drame). L’époque des colombages est terminé, nos bois d’assemblage sont beaucoup plus techniques. D’autant qu’il est possible d’anticiper la rupture plus facilement.
Donc construire en Acier/Bois n’est pas illogique en soit, d’autant que des architectes on eu l’obligation de viser les travaux quand aux respects des normes de construction.
Sinon pour ton impression de dégradation des services, personnellement je n’en ai pas trop souffert, mais il est vrai que leur croissance a nécessité une réorganisation assez difficile. Certains en on peut être pâti plus que d’autres. J’ai d’autres expériences avec d’autres hebergeurs, globalement OVH est dans la moyenne. Pour certains, inslaller un certificat Let’s encrypt est compliqué même 1an après la demande initiale, et pour d’autres j’ai des réponses et des solutions dans les 10min…
#35.4
Qu’est ce que tu fais des chainages/tiges en acier dans le béton ?
#35.5
Feraille, rien d’autre, le but de ces chenaux et ferraillages n’est pas la tenue en incendie, mais juste d’éviter des écartements en cas de fissure. Si le béton s’effrite sous l’action de la chaleur, les ferraillages seront à nu et vont faire de la guimauve en moins de deux. C’est d’ailleurs le triste exemple qu’on a eu au world trade center en 2001, l’impact de l’avion a été encaissé sans soucis par le béton armé, en revanche l’incendie, ou plus précisément le brasier, l’a achevé.
#35.7
Et pour la littérature, voici un récapitulatif bien documenté et assez neutre (les études par les constructeurs de maison ossature bois je m’en méfie)
https://enbau-online.ch/bauphysik/fr/8-5-comportement-au-feu-dune-selection-de-parties-de-construction-et-de-systemes-porteurs/
#35.6
Je dirais même que la conductivité thermique acrue de l’acier dans le béton qui aura une conductivité plus faible provoquera des différences de température au sein même du béton, et l’affaiblira probablement en créant des fissure voire plus autour du ferraillage
#36
Sources?
#37
Pour tout ceux qui “vantent” les systèmes anti incendie au gaz inerte, ça peut aussi engendrer des problèmes :
https://www.zdnet.com/article/how-a-loud-noise-brought-a-data-center-to-its-knees/
Un datacenter avait perdu une bonne partie des disques dur des serveurs, détruits par le bruit généré par la détente du gaz…
L’option backup chez OVH n’aurait probablement pas du s’appeler backup (Gandi a eu un problème similaire en janvier 2020, ils ont changé depuis le nom en “snapshot”) , visiblement Octave en est bien conscient du soucis (message de la liste de discussion VPS d’OVH) :
#38
Mouais. Et inventer une implémentation fiable et répétitive pour les courants faibles comme on l’a fait avec le 230 ce serait pas plus simple que d’acheter N prises en 220 pour N grosses armoires contenant N alims contenant N composants dont le taux de fiabilité même de 99%, par inférence de bayes, suffit à montrer que le risque incendie de concentrer des serveurs est démesuré ?
Il doit bien exister des conceptions convenables de data-center dans le monde non ?
#39
je suis quand même curieux de savoir comment un géant comme Google, MS ou AWS aurait géré ça
les incendies sont possibles chez eux également, mais finalement, le client s’en fiche si le temps d’indisponibilité est réduit
#39.1
La difficulté à maintenir les ressources en ligne et actives chez Azure l’année dernière lors du confinement et de l’augmentation du télétravail avait démontré qu’ils étaient loin d’être infaillibles aussi. (VM qui ne redémarraient pas, etc)
D’ailleurs, il me semble qu’Azure a aussi connu un gros crash de DC aux Pays Bas il y a quelques années.
Après, tout dépend du degré de résilience demandé par le client, comme toujours. Si tu ne demandes pas la redondance géographique de tes ressources, en cas de perte le risque que ça finisse par “Lulu” est avéré.
#39.2
Chez crosoft, ils font des “faux” incendies qui foutent aussi un beau bordel ^^ https://convergencit.com/2017/10/04/quand-azure-flanche-apres-une-maintenance-incendie/
Le problème reste la “puissance”. Et faire transiter du courant sur des grandes longueurs de câble provoque trop de déperdition dû au câble lui même (échauffement), sauf à augmenter la section des câbles.
C’est pour ca qu’on apporte une ligne de courant Fort, qui ensuite alimente plusieurs transformateur vers un courant faible. Même si la “transformation” est énergivore en soit, elle sera plus contrôlable et régulable.
C’est aussi pour cela qu’on achemine l’électricité des centrales électriques vers les zones habitables par des lignes à Très Haute Tension, qui sont ensuite subdivisées par des transformateurs sur des lignes a Haute Tension, puis ensuite subdivisé encore vers des lignes à Moyenne Tension, avant d’être encore subdivisé vers les habitations en lignes 220V dites “Basse tension”. Cela permet de couvrir de très grandes distances.
Si on tentait la même chose avec du 220V dés le départ, on irai pas loin, exemple 220Volt -> 12Ampères (maison en chauffage elec) -> Section de câble 50mm (énorme, le prix aussi) = 630m maxi, et encore on alimente qu’une seule maison…
Le problème c’est qu’un datacentre ca n’utilise pas un compteur domestique 220V classique, car il y a besoin pour une salle de beaucoup de puissance.
Exemple pratique calculons :
Sachant de plus qu’une alimentation 220V fournis plusieurs sous-alimentation en 12V, 12.3V, 5.5V, 3.3V selon les besoins, il y a donc déjà une sorte de régulation au sein d’un seul serveur. Ca va devenir une usine à gaz rien que pour une baie, et encore, sans jamais alimenter les serveurs en haut de la baie
Rien qu’en 220V, Imaginons maintenant une salle avec 10 Baies, il y aurait donc 80Kw. Actuellement aucune ligne 220V “simple” ne supporte une telle charge. il faut donc une tête de ligne à minmium Triphasée pour passer le cap (Soit trois lignes 220V).
Et encore je ne parles que des serveurs, je ne parles pas des autres équipements connexe, réseau, UPS, Monitoring, backup, refroidissement, etc
Donc oui, la concentration est malheureusement techniquement nécessaire lorsqu’il s’agit d’infrastructures d’ampleur. Et il est impossible techniquement de faire une concentration en basse tension uniquement.
#39.3
Un dimensionnement reste un dimensionnement. La puissance n’est pas le problème, le problème c’est le nombre de composants et la complexité des alims…
Ton exposé dit qu’en gros les reponsables ne sont responsables de rien à partir du passage AC->DC.
C’est un peu se tirer une balle dans le pied de ne pas assumer (concevoir ad hoc) et payer de sa poche l’usine à gaz en DC non ?
#40
ce que tu dis est très intéressant
du coup je me pose la question (naïve) de savoir si un DataCenter pourrait vraiment être alimenté directement par de l’énergie solaire sur son toit vu la puissance importante que ça semble demander
et la deuxième réflexion que ça me pose, c’est pourquoi Apple ne se lance pas directement dans les serveurs avec leur puce à la fois puissante et économe. Je sais qu’ils faisaient ça il y a longtemps mais là, ils pourraient avoir un avantage concurrentiel certain.
#40.1
Questions judicieuses
Le solaire peut être utilisé en “réduction de consommation” sur beaucoup de bâtiment en effet, mais le solaire est moins intéressant sur un DC, car la toiture terrasse est rarement libre, et surtout technique : elle est déjà massivement utilisé par les refroidissement (clim, ventilation, etc.), de plus il faudrait une ferme solaire immense pour compenser et du coup de la surface au sol.
Non OVH semble plus parier sur l’éolien :
https://twitter.com/olesovhcom/status/1173602212251078656
et 3 jours avant l’incident : https://twitter.com/olesovhcom/status/1359445119418654721
Concernant Apple…. et bien… il faudrait leur demander à Apple himself!
#40.2
oui, c’était plus une réflexion à voix haute pour Apple
après, je suppose que leur processeur n’est pas supporté par autre chose que Mac OS pour le moment, ce qui doit être un gros frein
#40.3
Après il faut se méfier de Apple, ils font outils superbes aussi bien techniquement que visuellement, mais
Frein N°1 : c’est conditionné au fait d’utiliser leur OS
Frein N°2 : Uniquement avec le matériel qu’ils décident de prendre en charge.
Frein N°3 : Le prix !
A voir en combien de temps le ratio économie d’énergie/prix/maintenabilité serait en notre faveur.
#41
Si cela peut permettre d’éclairer certains , j’ai extirpé la partie parlant d’incendie sur le dernier site sur lequel j’ai beaucoup bossé. ( j’ai enlevé des trucs pour raison de confidentialité)
Ce dossier est assez ancien mais donne une idée de ce qui est la base d’un projet d’hébergement sérieux.
(on voit par exemple que les compagnies d’assurances utilisent les règles APSAD avant de dire Amen ) ( clin d’oeuil à certains
Extraits:
La stabilité au feu des structures de l’immeuble est au minimum de 2 heures.
Les murs et cloisons autour des locaux techniques du site d’hébergement sont en matériaux garantissant une durée de résistance au feu de 2 heures au moins, de façon à respecter une isolation complète vis-à-vis des tiers.
L’enveloppe des volumes coupe-feu mis à disposition pour la séparation entre ces volumes sont coupe-feu 2 heures.
Les trémies, pénétrations ou passages de câbles sont réalisés à l’aide de matériaux présentant les mêmes caractéristiques de résistance au feu et assurent l’étanchéité du site.Les passages de fluides sont systématiquement rebouchés dans un matériau non pulvérisant, étanche et coupe-feu.
Les portes d’accès présentent une résistance au feu d’au moins une 2 h.
Les faux planchers sont de classe 3 selon la norme NFP 67-101.
Ils sont composés de vérins et dalles capables de supporter des charges de 1000 kg/m2 en standard (renforcement à la demande). La hauteur sous plancher minimale est de 600 mm.
Les dalles de faux-plancher sont aux dimensions standard de 600mm x 600mm et possèdent un revêtement de surface lisse mais antidérapant en laminé au moins égale à 13/10ème d’épaisseur anti- statique.
Les dalles présentent une résistance électrique transversale ou volumétrique de classe 1 selon la norme NF P 62.001.
Les dalles perforées sont à structure d’acier soudé et protégé anti- corrosion. Elles sont de même épaisseur que les dalles pleines et reçoivent le même revêtement. 10 % de la surface sera équipé de dalles perforées uniformément réparties sur la surfaces afin d’assurer la circulation correcte de l’air.
Par ailleurs, chaque ensemble de plancher est conçu pour fournir une liaison électrique à la terre afin de faciliter l’évacuation des charges électrostatiques. Enfin, les faux planchers sont équipés de détecteurs thermiques d’incendie et d’humidité. Le sol primaire qui supporte le plancher surélevé est revêtu d’une peinture ou tout autre traitement anti-poussière, y compris sur les remontées..
Une peinture est appliquée sur la totalité du plafond structurel et est mis hors poussière.
Pas de passage de liquides dans les salles informatiques ni en partie haute sous dalle plafond.
Les revêtements type PVC, papier ou autre matériaux combustibles sont proscrits.
Une peinture est appliquée sur les murs dans les salles.
Système de protection contre l’incendie conforme aux exigences des réglementations relatives à la protection contre l’incendie des personnes, des biens et de l’environnement et, a fortiori, des règles APSAD (Assemblée Plénière des Sociétés d’Assurance Dommage en France).
Les salles informatiques sont équipées d’un système de détection sur la base d’une double boucle de détection thermique et ionique qui permet de déceler tout départ de feu au plus tôt, en minimisant les fausses alarmes. La mise en œuvre du système anti-incendie par une alarme sonore et un déclenchement de scénario est effectif si l’alarme d’un déclencheur thermique est confirmée par l’alarme d’un deuxième détecteur ionique.
Des détecteurs en faux plancher et en ambiance sont répartis sur ces deux boucles. Ceux-ci sont protégés contre les surtensions, les fausses polarisations et les perturbations électriques ou électromagnétiques.
En cas d’incendie un arrêt des armoires de climatisation et la fermeture des clapets coupe feu s’effectuent. Un ordre d’évacuation immédiat du local impacté est donné.
Par synoptique lumineux et signal sonore, et après une temporisation de quelques secondes, la diffusion d’un gaz d’extinction (gaz neutre ou équivalent) conforme à la réglementation en vigueur, et la mise en œuvre d’une signalisation extérieure au local annoncent la présence de ce gaz.
Les bouteilles d’Inergen dont l’effet est d’éliminer le taux d’oxygène sont stockées dans un local séparé des salles informatiques.
Un dispositif de déclenchement manuel du système d’extinction, par boîtier de type “bris de glace “ est disponible à l’intérieur ou à l’entrée du site d’hébergement.
Toutes les alarmes sont reportées sur des baies de détection incendie situées au poste central de sécurité, situé ……
La stabilité au feu des structures de l’immeuble est au minimum de 2 heures.
Les murs et cloisons internes du site d’hébergement sont en matériaux garantissant une durée de résistance au feu de 1 heure au moins, de façon à respecter une isolation complète vis-à-vis des tiers.
L’enveloppe des volumes coupe-feu mis à disposition dans les salles informatiques et la séparation entre ces volumes sont coupe-feu 1 heure.
Les trémies, pénétrations ou passages de câbles sont réalisés à l’aide de matériaux présentant les mêmes caractéristiques de résistance au feu et assurent l’étanchéité du site.
Les portes d’accès internes présentent une résistance au feu d’au moins une 1H.
Le stockage de produits dangereux à proximité des locaux techniques et des salles informatiques est proscrit.
L’ensemble des portes sont munies d’étiquettes « porte coupe feu à maintenir fermée ». L’accès principal de service aux salles informatiques est composé d’une fermeture de type hydraulique ainsi que d’une barre anti-panique homologuée.
Des détecteurs multi ponctuels de fumée avec une large plage de sensibilité sont installés afin de pouvoir détecter des « feux couvrant » dès leur naissance bien avant le départ de flammes. Leur implantation est réalisée proche des grilles d’aspiration de l’air, notamment au-dessus des climatiseurs.
Les salles sont également dotées d’un système de détection incendie par analyse de particules (VESDA). Dans chaque salle, la détection incendie se fait à travers des capteurs de fumée situés en ambiance et sous les faux planchers.
#41.1
Je ne lis rien de spécifique, ce serait confidentiel ?
#41.2
C’est la règle élementaire ou ce qui a été appliqué chez OVH ?
edit : pas vu ton dernier poste
#42
Désolé pour la pavé mais mon dossier faisait 60 pages
#42.1
Merci
#43
oO
la seule chose que je lis, c’est que les contraintes physiques empêchent de déporter les alimentations des serveurs en-dehors de la salle serveur (à moins de vouloir dépenser plus cher de cuivre pour construire le circuit électrique basse tension haute puissance avec alimentation déportée que les serveurs eux-même)
#43.1
Plus de cuivre mais moins de pertes en prime d’assurance et clients…
#44
Ben une fois que j’ai enlevé 58 pages de mon dossier, il n’y a plus rien de confidentiel
T’auras pas les adresses de salle ni le lieu du poste de controle sécurité ni les noms des gens, ni le nombre de serveurs ni combien on payait par an etc etc …
Je n’ai laissé qu’une partie qui parlait incendie puisque c’était le sujet.
C’était principalement pour montrer qu’il y a des détails traités en amont avant de mériter le nom de site d’hébergement et pouvoir être assurré. ( il y a eu tellement de yavaitkafokon et de ah les nuls !!! )
Je précise malgré tout, que ce déménagement n’était pas vers OVH.
C’était une migration de 2 salles machines de 2 sites vers 2 autres sites (cause déménagement/fusion ) et il avait donc fallu trouver des sites d’hébergement ( 2 salles distantes )
et ces lignes font partie du dossier final. (c’est à dire une fois que notre choix a été fait et que nous avons signé les chèques) .
#45
Je dis juste que le Courant continu provoque plus d’échauffement du câble lors de l’acheminement, donc plus de déperdition, et qu’en grande longueur ce n’est techniquement pas réalisable a moins d’avoir des câbles de la section d’un verre d’eau (diamètre).
Au prix du cuivre, le câble va couter plus cher que la baie elle même.
De plus, niveau incendie, on reste sur du fort ampérage, donc même problème, puisque c’est l’ampérage qui provoque l’effet joule, et donc l’échauffement (c’est d’ailleurs le principe d’un poste à souder, qui diminue fortement la tension pour augmenter l’ampérage, et profiter de cet effet joules)
#46
“la puissance n’est pas un problème”
Enfin si un peu
Les hébergeurs te proposent 1000w d’ondulé au m² ou 2000w au m² ou autre
Je ne sais pas aujourd’hui ce qui est proposé , mais plus t’as de puissance au m² plus t’as de la dissipation de chaleur et plus t’as de chaleur plus tu as besoin de hauteur de plafond .
Et les hauteurs de plafond sont souvent un problème qui de ce fait limitent la puissance .
#47
Oui enfin la baie c’est du jetable dans tous les cas. On sait faire des lignes longue distance en DC depuis longtemps… donc je trouve dommage de ne pas clairement séparer le jetable du permanent. Après le foncier et les raccordements en fibre ne permettent pas de construire partout mais je suis certain qu’on peut dans ce cas récupérer la chaleur pour chauffer des logement au dessus par exemple etc.
Il doit y avoir une solution. Je vais chercher…
#48
Si ça peut te donner une idée
https://www.dropbox.com/s/6agawxvp8yiq8h7/Plafond.JPG?dl=0
#49
Si tu trouves la solution, tu sera le roi du pétrole crois moi!