Le datacenter SBG2 d'OVHcloud a pris feu cette nuit, il est désormais détruit selon Octave Klaba, tout comme une partie de SBG1. Les pompiers sont actuellement sur place afin de tenter de maitriser ce qu'il reste de l'incendie.
Ce matin à 3h56 OVHcloud déclarait un incident après avoir rencontré des problèmes dans les salles 71 et 72 de son site de Strasbourg (proche de sites Seveso), un feu s'étant déclaré dans le datacenter SBG2.
« Les pompiers sont intervenus immédiatement sur place mais ne sont pas parvenus à contrôler l’incendie », prévenait alors l'équipe, des employés de l'hébergeur étant alors mobilisés sur place. « Par mesure de précaution, l’électricité a été coupée sur l’ensemble du site, ce qui impacte tous nos services à SBG1, SBG2, SBG3 et SBG4 ».
Les clients étaient alors invités à enclencher leur Plan de Reprise de l'Activité (PRA). De quoi annoncer pour certains une fin de nuit difficile où ils devront s'assurer que tout est opérationnel de bon matin. À 5h24, Octave Klaba précisait que tout le personnel était sain et sauf, mais que l'impact de l'incident était lourd : « le feu a détruit SBG2. Une partie de SBG1 est détruite. Les pompiers protègent SBG3. Il n'y a aucun impact pour SBG4. »
La situation semble donc être en train de se régler. Les heures et jours à venir vont être pour les équipes d'OVHcloud l'occasion de chercher à comprendre comment un incident d'une telle ampleur a pu se produire malgré les sécurités mises en œuvre et éviter que cela puisse arriver dans les autres datacenters du groupe. Pour rappel, c'était déjà le site de Strasbourg qui avait été touché par une grosse panne d'alimentation fin 2017.
Cette fois, l'incident intervient alors que la société venait d'annoncer sa certification ISO 27001 et ISO 27701 en matière de sécurité et le début de l'évaluation d'une possible introduction en bourse. OVHcloud devra ainsi également se demander quel aurait été l'impact économique d'une telle annonce sur les marchés.
L'entreprise nous a fait parvenir le communiqué suivant :
« Ce mercredi 10 mars 2021, à 00h47, un incendie s’est déclaré dans une salle d’un de nos 4 datacentres strasbourgeois, SBG2. Nous précisons que le site ne fait pas l’objet d’une classification seveso. Les pompiers sont immédiatement intervenus sur site afin de protéger les équipes et limiter la progression de l’incendie. Ils ont ainsi procédé à l’isolation complète du site et de son périmètre dès 2h54.
À 4h09, le feu a détruit SBG2 et continuait de présenter des risques pour les datacentres voisins jusqu'à ce que les pompiers prennent le contrôle complet de l’incendie. Depuis 5h30, le site est inaccessible à nos équipes pour des raisons évidentes de sécurité, sous le pilotage de la préfecture. L’incendie est désormais circonscrit.
Nous sommes soulagés qu’aucun blessé ne soit à déplorer, ni parmi nos équipes ni parmi les pompiers et les services de la préfecture que nous remercions pour leur mobilisation exemplaire à nos côtés.
Grâce à notre parc opérationnel de 15 datacentres en Europe, nos équipes techniques et commerciales sont pleinement investies pour accompagner nos clients, mettre en œuvre des solutions et pallier l’indisponibilité de notre site strasbourgeois.
Notre mission est d’offrir à nos clients une qualité de services optimale pour accompagner leurs activités en ligne et nous savons l’importance cruciale que cela revêt pour eux. Nous leur présentons nos plus sincères excuses pour les difficultés que cet incendie leur cause. Nous nous engageons ainsi à communiquer avec la plus grande transparence sur ses causes et ses impacts.
Nous sommes actuellement en train d’évaluer l’impact de cet incident et communiquerons dès que possible avec la plus grande transparence sur l’avancée de nos analyses et la mise en œuvre de solutions.
Tous nos canaux de communication, à commencer par notre plateforme de suivi d’incidents (travaux.ovh.com), sont accessibles pour vous tenir informés en temps réel sur l’évolution de la situation. »
Commentaires (279)
#1
Ouhlà, bizarre, au regard des mesures qu’impliquent une certification ISO-2700x… Le Rex sera intéressant en tout cas, affaire à suivre. Par contre, pas térrible comme timing suite aux annonces des derniers jours… Et bonne chance au clients dont certains ont dû se lever tôt pour assurer la continuité de services.
#2
J’avais mal compris la news d’avant. Il s’agissait d’une Intervention des Pompiers Obligatoire donc…
#3
La préfecture est revenue sur la classification Seveso du site. Il ne l’est pas.
#3.1
Oui on a modifié dans la foulée
#3.2
Je ne vois pas bien ce qui pourrait justifier que des datacenters soient classés Seveso? Des produits dangereux stockés en grande quantité pour assurer leur fonctionnement?
#3.3
Le site initialement supposé Seveso était autre site, à proximité du datacenter, pas le datacenter lui-même.
#4
OK, ça explique pourquoi mon serveur répondait plus ce matin.
Bon courage à eux !
(edit, bon, mon serveur était à SBG1, donc j’imagine que c’est mort)
(re edit : par contre j’aurais bien aimé être informé par leur intermédiaire et non le votre… aucun mail reçu)
#4.1
C’est sur les newsletters qu’Octave communique en priorité, c’est le moyen le plus rapide d’avoir les infos et de résoudre des soucis en général.
#5
À en croire l’heure de cette tâche de travaux, le feu se serait déclaré dès 00h42 (heure de Paris) la nuit dernière.
#6
Juste après l’annonce d’une possible introduction en bourse ? Bizarre …
#7
Ce que je trouve bizarre moi, c’est de trouver ça bizarre en mode complot direct.
#8
J’ai un dédié sur SBG3. Indisponible pour le moment (normal, si le courant est coupé !). Par contre, au niveau de la console OVH, on m’annonce que tous les services sont OK
#9
Vu les images il risque de ne pas y avoir grand chose à récupérer dans SBG2
https://twitter.com/abonin_DNA/status/1369538028243456000
Bon courage a ceux qui avaient des services dedans :-/
#9.1
Question bête, mais il n’ont pas de redondance et équilibrage de charge de leurs serveurs répartis sur plusieurs sites? Toute leur prod sur un seul site? Seulement du backup à restaurer?
#9.2
Quand t’as des logiciels c’est un peu compliqué de les répartir. Les bases de données c’est effectivement une autre histoire, ça peut très bien être réparti.
#10
Je viens de me rendre compte que mon serveur KS et celui de sauvegarde étaient de le même site (Roubaix heureusement). Peut être une bonne idée d’en migrer au Canada je crois ^^
#11
Les données sont réellement dans un nuage maintenant
Bon courage a tout ceux qui vont devoir tout remonter
#11.1
Excellent!
#11.2
J’ai ri xD
Courage aux équipes, des jours et semaines difficile à venir, un datacenter complet à reconstruire et des conclusions à tirer sur cette défaillance majeure dans la protection incendie, les tickets d’incidents semblent tendre vers le fait qu’ils n’ont pas détecté le feu très tôt. (ils parlent d’un problème d’accès et de communication d’abord)
#12
00h42 etrange cette annonce Free
#13
Comme quoi, MS a raison d’essayer de faire des datacenters sous l’eau, en cas d’incendie, il suffit d’ouvrir les écoutilles
#14
Ca se passe comment pour les serveurs hébergés la ? ils ont des sauvegardes externes pour tout ? ou ca dépend de l’offre d’hébergement choisie ?
#14.1
Ca va dépendre de l’offre d’hébergement.
Pour tout ce qui est VPS par exemple, ils font des sauvegardes régulières, et devraient donc pouvoir remonter le tout sans trop de perte, car les sauvegardes sont normalement répliquées sur plusieurs sites.
Pour tout ce qui est dédié, c’est différent. Pour le dédié en lui-même, OVH ne fait pas de sauvegarde. C’est de la responsabilité du client de le faire (possiblement en passant par les services OVH).
#15
Mon serveur est devenu injoignable à 00h37. Un des premiers à succomber je suppose…
#16
#17
#18
Tous les sites de France vont être HS !!!!!
#18.1
Non, loin de là. Quelques un c’est vrai, d’autres vont être un peu plus lents mais c’est qu’une “petite” partie d’OVH et tout le monde n’est pas chez eux ou limite les SPOF en étant sur plusieurs sites géographique.
#19
D’un autre côté une bonne réponse à ce genre de désastre qui peut toucher tout le monde peut donner confiance dans la solidité de la boite.
#20
Une idée pour savoir sur quel SGB est notre serveur ?
Dans mon cas j’ai pris un VPS cet été, est-ce que ça veut forcément dire que le VPS est dans les dernièrs SGB ?
#20.1
J’avais plusieurs VPS à une époque, on choisissait l’emplacement à la commande, de mémoire. Puis c’était rappelé dans le courriel de confirmation.
Je crois qu’on a aussi l’info dans l’interface de gestion.
#20.2
Dans ta console de gestion (difficile à ateindre en ce momoent), sinon dans la liste de tes facturation : https://www.ovh.com/manager/dedicated/#/billing/
tu cliques sur le serveur en question et tu à l’info sous “Localisation”.
#21
Euh envoyer un mail alors que la probabilité que les clients hébergent leur mail dans le DC est non négligeable ?
#22
AHAHAHA
#23
Nos serveurs GitLab sont impactés, on est dans la merde :(
#23.1
Un serveur gitlab c’est suffisamment important pour qu’il soit en multi-AZ… :p
#23.2
Ça va être un bon test pour la sauvegarde…
#24
J’ai reçu un email du système de monitoring comme quoi mon VPS dans SBG1 (cluster-001) était injoignable à 1h04 du matin…
#25
Pas de bol, une pensée à tous ceux qui ont perdu des données (j’espère que vous aviez une sauvegarde …) et aux équipes d’OVH.
#26
Et surtout tous les serveurs sur le site SBG sont HS puisque le courant est coupé sur tout le site à la demande des pompiers, et il ne sera remis qu’avec leur autorisation en principe (ou celle du fournisseur d’électricité).
#27
Ils ont peut-être essayé de faire tourner Shadow dans leur infrastructure…
#28
L’incendie était apparemment assez impressionnant, et l’état de l’immeuble est représentatif des dégâts…
#29
Merci @janiko & @chantoine
Via l’interface d’admin d’OVH c’est pas possible pour le moment, je vais chercher dans mes mails…
#30
#31
accès a rien : un dédié + vrack et un vps….RIEN
quelqu’un sait comment faire le lien entre un dns serveur et son datacenter ? en gros savoir si le dédié est dans SGB1 ou 2 etc en fonction du nom…
#32
Arrête, tu vas donner des idées à Flock pour les dessins de ce week-end
#32.1
Avec data.gouv.fr dans le lot, certains vont crier au complot…
Dommage pour les chiffres du covid.
#33
Quelqu’un a une info sur les degâts ? Je veux dire : j’ai lu qqpart que c’est un entrepôt de stockage qui aurait brûlé et donc que seuls quelques serveurs risquaient d’être perdus. Par contre si le bâtiment le plus touché était un datacenter, ça va être plus compliqué.
PI la console d’admin rame à mort, mauvais point pour la continuité de service, surtout pour les clients qui ne sont pas touchés.
Et au risque de me répéter, ça a dû commencer avant 0h42 (message OVH) car mon VPS ne répondait déjà plus à 0h27.
EDIT : On peut effectivement voir sur la console la localisation du VPS. Pour moi c’est SBG3.
#33.1
Ils ont totalement perdu la partie “2” et une section de la zone “1”.
Le reste à l’air “ok” d’après les news récentes, mais il y aura plus d’information d’ici quelques heures en théorie.
#34
Pour une photo de l’incendie : https://www.macg.co/ailleurs/2021/03/un-gros-incendie-detruit-une-partie-du-data-center-strasbourgeois-dovh-120127
C’est effectivement assez violent.
#35
Je connais une boite qui ne peut pas lancer son PRA à Roubaix car l’infrastructure VRACK globale d’OVH est également INpacté.
Je connais aussi des assureurs qui transpirent à grosses gouttes…
#35.1
Le nom de l’infra…
#36
Ça dépend des services. Pour du dédié, tu loues un serveur et tu te débrouille dessus (y compris sauvegarde). Pour tous les services mutualisés, c’est OVH qui s’occupe de tout (équilibrage, sauvegarde).
#37
Les photos du bâtiment cramé indiquent que sa structure était entourée d’un revêtement super inflammable telle qu’on en voit de plus en plus sur les constructions dites « modernes », en bois ou composite « recyclable » et « durable ».
Le bâtiment en béton et les caissons en métal adjacents ont mieux résisté.
Cela rappelle l’incendie monstre de la tour Grenfell à Londres, pour semble-t-il les mêmes raisons : d’autres considérations sont passées avant la sécurité incendie.
#37.1
Tu es doué pour déterminer les matériaux utilisés avec une simple photo et leur contribution au feu. Tu devrais postuler auprès des assureurs pour apporter ton expertise.
#37.2
Il y a un fil dédié sur le forum LaFibre. Il y a effectivement une bonne partie de la structure qui est en bois (sauf autour des escaliers ?).
#37.4
C’est vraiment idiot, on est d’accord ?
#37.5
Oui je suis d’accord, il y a d’autres matériaux comme le fermacell qui servent de coupe-feu et qui sont isolant électrique… Le prix c’est pas le même que du bois
#37.6
Il n’y a pas besoin d’être ingénieur ou architecte pour comprendre qu’un bâtiment dont l’extérieur s’embrase comme un torche implique l’utilisation de matériaux facilement combustibles. J’en ai cité 2 usuels mais il en existe d’autres.
#37.7
Il ne faut pas être ingénieur pour lire une fiche technique d’une plaque “coupe feu” et se rendre compte qu’elle n’est “coupe feu” que pendant x minutes.
Tout les isolants au feu ne sont pas égaux aux différentes phases d’un incendie.
le choix d’un matériaux selon sa résistance au feu et là pour augmenter en priorité les chances aux personnes d’évacuer.
#37.3
Moi je vois au contraire des panneaux qui ont fondu, qui se sont rabougri, mais qui ne semblent pas avoir brûlé du tout.
#38
J’ai quelques VRACK et IP Failover qui intégrait et/ou pointait sur des machines impacté, les commandes ne fonctionnait pas via le manager mais via l’API les opérations de bascule sur d’autres régions ce sont bien passé.
Bref je pense que c’est plus le rush sur le manager qui pose souci que les services eux même.
#39
Je confirme, pour remplir un dossier de déplacement pour motif impérieux à la Réunion, sur le site du gouvernement, site indisponible.
Hasard ou site hébergé chez OVH ?
#40
Sur des photos de la construction de ce bâtiment on voit qu’OVH avait fait des planchers en bois à chaque étage mais après déterminer la tenue au feu c’est une autre histoire
#41
Je pense qu’il faut également saluer la transparence d’OVH (du moins d’Octave) : je ne connais pas d’autre hébergeur fournissant publiquement (sur http://travaux.ovh.net/ ) et sur les réseaux sociaux le détail de l’ensemble de ses incidents !
#41.1
D’ailleurs, puisqu’on parle de travaux.ovh.net : quelqu’un sait ce que signifient vraiment les pictogrammes à côté des différents services ? (si c’est down, quelle étendue…). Ce n’est vraiment pas explicite sur ce point.
#42
Oui, trop génial :
http://travaux.ovh.net/vms/index_sbg2.html
#42.1
C’est sur que sur SGB2 il n’y a aucune sonde qui remonte des erreurs
#42.2
C’est digne d’un meme Reddit
“Wow, your datacenter is on fire”…“Never mind, my dashboard says that everything is OK :oui2: “.
#43
C’est tmt dans toute sa splendeur, quoi.
) a flambé complètement, seule la structure acier du bâtiment a résisté alors que les panneaux extérieurs en alliage d’aluminium étaient vraiment dans un sale état (les moins touchés étaient “seulement” tordus à 120° au lieu d’être plans, d’autres avaient carrément fondu aux 3⁄4 à cause de la chaleur dégagée).
Mais ca me fait bien rire de voir ca, surtout suite à un bel incendie que j’ai pu voir : une entreprise de recyclage de papiers et plastiques (le genre de trucs absolument pas inflammables
Vu la chaleur dégagée par la combustion du plastique, à moins d’utiliser de l’acier à haute résistance en température, il n’y a pas grand chose qui résiste. Donc bois ou autre chose…
#43.1
Le béton épais résiste au feu .. pas des conteneurs et des plaques d’allu
et en datacenter y a pas des systèmes antifeu coupure d’oxygène ?
#44
Ma boite est aussi touché.
J’essaye de voir où sont stockées nos VMs, mais le site OVH rame à mort.
#45
Nos mails sont hébergés là bas, donc pas de mail pour le moment
#46
Hébergés chez OVH, oui.
https://twitter.com/datagouvfr/status/1369554310707765250
#47
Les panneaux extérieurs fondus ont l’air d’être en métal… Donc non, ca ne change pas grand chose au final à ce niveau. Par contre ca apporte un énorme gain niveau isolation électrique, tu ne te prendras pas une décharge juste en marchant.
#48
EDIT : notre serveur était sur SBG2. :(
Donc si j’ai bien compris, il a été détruit. :/
#49
Hello.
ON aurait une disposition des salles?
Parce que par exemple j’ai deux serveurs mais qui sont à RBX, genre RBX2 et 5, c’est histoire de voir si au final ça craint pas trop vu qu’on voit que là c’est deux salles qui ont brulées donc avoir 2 serveurs dans 2 salles ne suffit visiblement pas.
#49.1
Par exemple http://travaux.ovh.net/vms/index_sbg1.html
(dont le monitoring n’es bien sur pas à jour)
tu trouves ta zone dans ta console de gestion au dessus de la localisation
#49.2
ça ne donne pas vraiment de disposition physique non?
Genre savoir quelle distance sépare RBX 2 de 3 etc, si c’est collé etc.
#49.3
OpenStreetMap donnent quelques indications
https://www.openstreetmap.org/#map=19⁄48.58569⁄7.79857
#49.4
Pas mal effectivement.
Merci.
#50
Quelqu’un sait si le site ENT (Lycées) de l’Education Nationale est impacté ?
çà ne répond pas en idf.
Merci.
#50.1
Une recherche DNS montre que ent.iledefrance.fr pointe sur des ip OVH.
#51
Vue des bâtiments, mais ça c’était avant le drame…
Lien https://www.google.com/maps/place/Altimat+OVH/@48.5854816,7.798022,5a,41.7y,90t/data=!3m8!1e2!3m6!1sAF1QipPqNGpeMmyBeypXOMrp4Pfz6G0NyM-GOzBHU9dB!2e10!3e12!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipPqNGpeMmyBeypXOMrp4Pfz6G0NyM-GOzBHU9dB%3Dw152-h86-k-no!7i2688!8i1520!4m13!1m7!3m6!1s0x4796c8daab82f9af:0x538b85a8eb23fadb!2s9+Rue+du+Bassin+de+l’Industrie,+67000+Strasbourg!3b1!8m2!3d48.5858131!4d7.7973832!3m4!1s0x4796c8daa8337c07:0xfe79d40ff098f0c2!8m2!3d48.5854816!4d7.7974169">Google.
#52
Moi j’ai plutôt l’impression que l’intérieur s’est complètement embrasé, et que l’extérieur a plutôt admirablement résisté : https://lafibre.info/images/ovh/202103_incendie_ovh_strasbourg_7.jpg
#52.1
Toutes les photos sur LaFibre pour se faire une idée.
Le plancher de toute la structure extérieure est bien en bois.
À noter cet excellent commentaire prémonitoire.
#52.2
J’avoue que le commentaire est pas mal à postériori
#52.4
Je dirais même « dévastateur »
.
.
Le rapport est que la sécurité incendie a été négligée dans les 2 cas.
#52.3
Oui, ce sont des planchers bois.
Mais les façades n’ont pas brûlé, donc absolument aucun rapport avec la tour Grenfell que tu citais. Pour t’en convaincre, compare l’état des façades :
https://static.actu.fr/uploads/2021/03/20210310-091754.jpg
https://fr.wikipedia.org/wiki/Incendie_de_la_tour_Grenfell#/media/Fichier:Grenfell_Tower_fire_morning.jpg
OVH a sans doute merdé, plancher bois, sans doute pas de sprinklers, grands volumes sans portes coupe-feu, tout ça est probablement très mal conçu pour la résistance au feu, mais ça n’a aucun rapport avec le revêtement de façade de la tour Grenfell.
#52.5
Punaise jamais j’aurais imaginé que c’était comme ça leur datacenters.
#52.6
Sachant que le bois (enfin certains bois) résiste mieux au feu que pas mal d’autres matériaux comme l’acier et le béton, là comme ça je dirais que ça ne suffit pas à expliquer quoi que ce soit
#52.7
Installer des matériaux combustibles correspond à un facteur de risque majeur supplémentaire quand il n’existe pas de politique de sécurité incendie appropriée comme ici (c-à-d sans éléments de détection et de réponse actifs).
#52.8
Je n’ai pas le détail de l’installation, donc je ne m’aventurerai pas à faire une quelconque analyse, qui ne relève de toute façon pas de ma spécialité. Je tiens juste à préciser que la simplification bois = problème avec le feu n’est pas valable. Ça me parait important de rappeler que le béton et l’acier résistent moins bien au feu que certains bois, du moins sur les éléments structurels.
#52.10
ouais mais non, le bois est moins conducteur que le béton ou l’acier
ça brule okay, mais ça laisse plus de temps aux pompiers pour intervenir
#52.9
T’embête pas à débattre avec lui, c’est un troll ^^
#53
RIP mon soyoustart à SBG2
Pris en promo, j’ai bien peur de ne pas retrouver la même offre facilement…
Bon j’ai pas perdu grand-chose, merci proxmox.
#54
Je savais pas que SYS était aussi sur SBG…
J’ai vraiment eu du bol, j’ai qq dizaines de machines chez eux.
#54.1
C’est peut être nouveau, je l’ai pris en juillet dernier, une offre sympa avec connexion 500Mb/s (Intel Xeon E5-1620v2 - 32GB DDR3 ECC 1600MHz - 4x 2To HDD SATA Soft RAID) pour 38€ j’étais content ^^
Et dire que je voulais mes serveurs dans le même datacenter à la base… c’est pas si mal en fait.
edit prix : c’est bien 38€ après vérification
#55
C’est stress mais j’avoue c’est excellent.
Ma sauvegarde vrack backup storage n’a pas l’air touché, le serveur répond. par contre pour des raison de sécurité on ne peut s’y connecté depuis une IP autre que celle du dédié qui lui n’est plus disponible….
Une idée ? On mets la pression sur OVH pour un accès ?
#56
D’après les DNA, le feu s’est déclaré (ou a été détecté) à 00h47 et les pompiers n’ont pas pu combattre correctement le feu du fait de l’absence d’accès pompier sur les façades.
En tout cas, vu de l’extérieur, ces datacenter font vraiment TRES cheap et les photos postés dans le thread font assez peur niveau respect de la sécurité. Si OVH a pu obtenir des certifications ISO 27xxx, je crois que ces certifications ne veulent pas dire grand chose.
C’est une raison de plus pour la société de ne pas être introduite en bourse au risque d’un vrai accident industriel. Il leur faut vraiment tout reprendre de A à Z sur la sécurité physique et ça va pas être facile car les datacenter européens et américains ont dû être construit de la même manière de façon low cost…
Question subsidiaire : Pourquoi les entreprises françaises ont beaucoup tendance à ne pas être sérieuse et misent sur la réduction des coûts au lieu de miser sur le savoir-faire et la fiabilité ?
#56.1
Clair que concernant les 2700x je me demande comment cela a pu passer…
#56.2
En même temps, les procédures d’homologation où tu paye un cabinet qui te vend la prestation d’homologation, ça ne me semble pas bien fiable. De même pour les procédures où cocher des cases et écrire une justification en 500 caractères est suffisante…
Rien ne vaut une homologation par l’Etat, une revue par les paires, par des experts indépendants type expert judiciaire ou assermenté, éventuellement par les compagnies d’assurance, un classement public par des ONG, ou encore un bon vieil audit à faire soi-même qui est toujours le plus efficace.
#57
Même constat
#58
Source ?
Par que les fenêtres dotés d’un point rouge sont les accès pompier. On en voit pas mal sur SGB2 :
https://lafibre.info/images/ovh/201306_ovh_strasbourg_sgb2_construction.jpg
#58.1
Comme indiqué, source les Dernières Nouvelles d’Alsace (DNA) : https://www.dna.fr/faits-divers-justice/2021/03/10/strasbourg-important-incendie-dans-une-entreprise-situee-sur-un-site-seveso-au-port-du-rhin
#58.2
Ok, donc ce n’est pas une absence d’accès pompier sur les façades.
#58.3
Moi j’en sais rien, je n’ai rien à voir avec tout ça, je suis juste un citoyen lambda et un lecteur de Nextinpact, mais je lis ce que les DNA rapportent du responsable des pompiers sur place, et celui là dit que les pompiers n’ont pas pu avoir accès au bâtiment (visiblement sur les images pas d’accès en façade), et n’ont pas pu couper l’électricité.
#59
question naïve : des données ont été perdues ?
#59.1
Elles sont dans les nuages maintenant oui… Enfin ça dépend s’il s’agit d’un serveur dédié et s’il est dans un DC qui a brûlé. Sur du dédié il n’y a aucune sauvegarde de la part d’OVH
#60
Ils ont dû recevoir quelques alerte de CPU overheating…
#61
La morale de cette histoire est de ne pas mettre vos backup et vos espaces de stockage chez OVH et de privilégier un hébergeur plus fiable pour faire cela.
#61.1
Euh … ou de mieux gérer ses sauvegardes ? Pour rappel, dans le cadre de la location d’un serveur dédié, c’est au client de gérer ses sauvegardes et PRA … et chez l’ensemble des hébergeurs soit dit au passage…
Si des données vitales d’une entreprise sont perdues suite à la perte d’un serveur, c’est le sysadmin de l’entreprise qu’il faut blâmer, pas l’hébergeur.
#62
Pour peu qu’il y ait eu des onduleurs et des batteries, la plupart des matériaux ne tiennent de toutes façon pas. C’est pour ça qu’il faut construire les bâtiments en briquettes allume feu bio (qui nécessitent une boîte d’allumettes entière pour en allumer un après l’avoir trempé dans de l’essence
)
#63
Le but des systèmes coupe-feu dans un bâtiment est uniquement de retarder la propagation du feu pour permettre la fuite, pas l’arrêter complètement (à moins qu’il ne démarre tout juste, c’est rarement possible sans intervention externe tant qu’il reste du combustible).
Donc pas la peine d’être aussi cynique dans la réponse…
#64
Une détection précoce des départs d’incendie avec coupe circuit électrique automatique et système d’évacuation de l’oxygène devrait permettre d’éviter ce genre de catastrophe.
C’est certainement cher, mais quand on héberge des données, la sécurité y compris incendie devrait être la première des obsessions…
#64.1
bon les experts calmez vous ! notre dame de paris possédez une détection par aspiration et analyse laser. c’est très très efficace et çà coute a peine 5000 euros et des tube en PVC. mais cela n’empêche pas de bruler.
le stockage de rouen qui est partie en fumée possédait un/des sprinkler, les tours de new york aussi. Il faut bien saisir qu’une fois partie un incendie c’est très difficile à arrêter. les cables M0 ou M1 brule quand même dans ce genre d’incendie.
les extinctions à gaz FM 200 sont efficace uniquement au départ pour étouffée le feu et pas pendant 6h, dans le cas de ovh si tous les système se déclenche au fur et a mesure, cela ne fera que ralentir la propagation pas l’arrêter. un peu comme le titanic
.
et je n’ai jamais vu de sprinkler dans un data center peut être que cela va évoluer de ce coté. tous les datacenter du monde vont vérifier leur système incendie dans les prochaine semaine.
j’ai déjà vu du FM 200 avec les cartouches interne non connecté
après un test réel cela ne fonctionnais pas. pendant 15 ans l’installation vérifié 2 fois par an par le fabricant ne déclenché pas. car le test ne percute pas les réservoir on vérifie juste que le signal arrive 
#64.3
Les tests de FM200 ne se font jamais en réel, le gaz est dangereux pour les personnes, et ça salope tout le matériel…
Donc tu fait inspection visuelle des équipements, des dates des bonbonnes, de leur connections et tu fait un test de fonctionnement inhibé.
#64.4
Ce qui sera une bonne raison de faire évoluer les pratiques :)
Pendant un temps les tests d’alimentation de secours pas groupe consistait à démarrer les groupes. Et puis à force de voir des infra tomber car l’automate n’arrivait pas à “switcher d’alim” voir ne démarrait pas correctement les groupes ils ont évolué vers des tests grandeur nature, je coupe l’alimentation et je vérifie que le switch se fait et la montée en charge reste stable. Ensuite retour à la normale.
Faudra innover dans les tests d’incendies, surement avec des moyens avancés de simuler et d’agir sur des feux “tests”
#64.5
On a l’approche SCE (Safety Critical Element/Equipment) qui commence à bien faire son chemin (en tout cas dans l’industrie qui me concerne) qui consiste à identifier les équipements qui INpactent la sécurité des personnes et l’intégrité des assets.
Ca va de capteurs de températures aux alimentations ondulées en passant par les EPI etc.
Tu définis par type d’équipements, des minima opérationnels et des tâches de Maintenance/Inspections pour vérifier/prouver que tu atteints ces minimas. Ces tâches sont en sus de la maintenance préventive/prédictive ordinaire.
Les rapports de ces tâches sont ensuite synthétisés et estimés par fonction.
Ca peut être aussi simple qu’un tableau de bord avec des sémaphores tricolores (vert le fonction est assurés, jaune la fonction est dégradée, rouge la fonction subit une dégradation critique)
Chaque niveau de sémaphore implique une chaine de décision et de déblocage de fonds pour restaurer la fonction le plus rapidement possible.
Ce tableau de bord peut être consulté de manière journalière, hebdo etc
Certains organisme de certifications (Bureau Veritas etc) demande même un rapport détaillé de ces actions pour vérifier que l’usine est surveillée. Ils ont le droit de suspendre l’agrément d’exploitation si ce n’est pas le cas.
Tout est question de stratégie d’entreprise, de législation etc …
#64.6
on a eu le droit à ce genre de test chez orange et ben je confirme que les groupe on pas démarrer et la moitié des serveur citrix et vdi à disparu d’un coup ca fait bizarre avec 95% des collaborateurs en télétravail :)
#64.7
Whoa.. et t’est architecte maintenant?
Merci pour ceci d’une part.
Merci encore
A tous ceux qui se sont vu être béni par la divine grâce de l’omniscience près de chez vous pour nous relater l’idiotie rampante de ce monde tout en repeignant le plafond de la chapelle Sixtine en multitâche du fait de cette lévitation soudaine…
Avant de faire un énième commentaire du genre peut être faudrait il se pencher sur de vraies informations. L’usage des matériaux dépends d’un certain nombre de facteurs.
500kg x 4 baies x 10 travées x 2 rangées. On atteint les doigts dans le pif des dizaines de tonnes. Dans le cas présent: dans les 40 tonnes pour une surface de 20x20m.
Quand bien même tout ne serait pas plein etc… ça fait quand même des charges NON négligeables. Et je doute fort qu’un cabinet d’architecte se risque à valider un projet (sur plusieurs étages) en mettant des matériaux insuffisants. Non seulement car il engage sa responsabilité sur l’objet mais aussi car il y a tout simplement des réglementations sur le sujet qui sont ma foi bien contraignantes. Quand bien même on a un tas de désordre de tout genre en bâtiment et en exploitation des DC. Il n’en est pas moins que ce n’est pas du grand n’importe quoi non plus. C’est la vie des bâtiments.
Je ne dis pas qu’il n’y a pas de bois mais que s’il y en a; le matériaux doit répondre d’exigences relativement drastiques (imputrescible, essence de densité x, test de résistance etc.). Et que c’est peut être tout simplement un plancher en périphérie de la structure centrale qui sera faite avec d’autres matériaux plus résistants. Et cela ne veut pas dire que cela ne vont pas brûler ou se ramollir en cas d’incendie (voir le commentaire de smileyn).
Ce que la plupart visiblement ne voit pas, c’est que ce n’est pas une friteuse qui crame à la maison. Ce sont des sommes d’énergie qui amènent des réactions bien plus violentes que cela et qui de part cette puissance donne un temps très court pour des dégâts gigantesques.
Donc l’évaluation au doigt mouillé par les experts… S’il vous plaît, plutôt que de faire du sensationnel merci d’apporter des informations tangibles. Comme un permis de construire avec les fiches matériaux etc…
Parce qu’elles se prennent pour des boites américaines.
#64.8
Écrit-il en faisant pire : un pâté de suppositions avec 0 rapport sur le sujet…
#64.9
Quelle constance sur l’hasardeuse localisation de la plaque.
Planck n’a qu’à bien se tenir.
#64.10
Les fameux « experts » ne sont pas ceux qu’on croit : pas plus qualifiés que le commun des mortels, mais poseurs assez prétentieux pour désigner comme tels toute personne qui s’aviserait à donner un avis afin de le et donc la disqualifier à bon compte tout en usant de ce ton paternaliste de supériorité factice qui sied aux cuistres.
#64.11
Whoa. C’est beau quand tu parles de toi. Comme quoi l’expression : l’hôpital qui se fout de la charité peut prendre tout son sens d’une marnière si inattendue.
Ce n’est clairement pas l’humilité qui va t’écorcher le coin du bec. Encore moins la maîtrise des sujets que tu abord… sur lequels tu trolles avec une constance inébranlable. C’est tellement facile de te reprendre que tu finis par y arriver toi même sans le savoir.
Priceless.
#64.12
Écrit le pontifieur arrogant qui, tout comme l’autre bêcheur, est justement visé pour pondre du commentaire « je vous prends de haut les “experts” et donc voilà ma pseudo expertise à la noix ». Alors que les participants ont seulement donné leur humble avis sur des problème techniques, comme tout un chacun est en droit de le faire.
Mais ma phrase était sans doute trop complexe à déchiffrer.
Prends ton boulet, et vas jouer dans le bac à sable avec les autres gamins.
#64.13
Comme je le dis c’est l’hôpital qui se fout très largement de la charité.
T’en a pas marre de troller sans arrêt?
Je ne suis clairement pas le seul ici à en avoir marre.
Genre… change de vie. Ou ché pas. Décède ou un truc du genre.
Tu nourris plus d’ignorance flagrante que de bon mot ou de bon sens la plupart du temps (petite note d’espoir il s’entend).
EOT
#64.14
Je suis certaine que l’ironie mordante de la situation dans laquelle tu t’es fourrée ne t’échappe pas.
#64.2
Un système de ce genre ne sera jamais “automatique”, il faut forcément une activation manuelle / s’assurer que personne n’est présent en salle…
#65
Ca me fait marrer les gens qui disent “faut pas sauvegarder chez OVH, etc”. Faut juste pas mettre les sauvegardes / replicate dans les mêmes zones. Si en France on a 3 DC c’est pas pour rien ^^
Et est-ce qu’il y a eu la même réflexion quand AWS a pris feu ? Quand on respecte pas les principes de redondance, on assume la perte de ses donnés
#65.1
Ca c’est un raisonnement de techos avec sa petite règle de 3, mais ils y a des obligations légales en matière de sécurité, et la première étant le RGPD et visiblement OVH a sur le coup contrevenu à ses obigations de sécurisation des données car parmi celles qu’il hébergeait, il devait y avoir statistiquement de très nombreuses données à caractère personnel, voir sensibles et un certain nombre ont été détruites.
Biensûr qu’il faut sauvegarder et redonder ses données, mais choisir pour ce faire des hébergeurs non-fiables, c’est être irresponsable par rapport à ses obligations légales.
Ce genre de mentalité ne va certainement pas conduire les acteurs du marché à augmenter leurs standards de sécurité puisque pour certains, seuls le nombre de points de rendondance comptent, même si dans le lot nous avons des datacenter entiers qui partent en fumé.
#65.3
Le RGPD parle de sécurisation sur l’accès plutôt non ?
Là elles sont détruite donc de risque d’accès frauduleux.
#65.2
Encore faut-il pouvoir choisir, dans mon cas mes 2 serveurs sont à roubaix parce que la dispo n’était que là.
(pas dans la même salle mais bon…)
#66
Bah quand je définis une adresse de contact, c’est pour être contacté … En l’occurrence je n’ai pas eu de souci pour recevoir le mail d’alerte comme quoi je me suis connecté à mon espace client. Si le client met tous ses oeufs dans le même panier c’est son problème, l’hébergeur n’a pas à se poser la question.
(c’était mon cas jusqu’à il y a 4 mois, j’ai mis mes mails chez Infomaniak car l’auto hébergement pour cette partie est un poil trop contraignante)
Pour le coup mes backups sont sauvées car elles sont sur le site de Gravelines. A moins que la centrale nucléaire ne pète, je suis tranquille pour le moment. Et de toute façon je pense qu’on aura d’autres soucis si c’était le cas.
#67
Merci de préciser le rapport avec le RGPD?
#67.1
Quel lien ? La sécurité physique des données, les responsabilités du sous-traitant et celle du responsable de traitement vis-à-vis des sous-traitants qu’il choisit.
Je vous renvoi vers le dossier de NextInpact sur les articles concernés : https://www.nextinpact.com/article/28047/106168-le-rgpd-explique-ligne-par-ligne-articles-24-a-50
Article 28
Sous-traitant
Lorsqu’un traitement doit être effectué pour le compte d’un responsable du traitement, celui-ci fait uniquement appel à des sous-traitants qui présentent des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées de manière à ce que le traitement réponde aux exigences du présent règlement et garantisse la protection des droits de la personne concernée.
Le sous-traitant ne recrute pas un autre sous-traitant sans l’autorisation écrite préalable, spécifique ou générale, du responsable du traitement. Dans le cas d’une autorisation écrite générale, le sous-traitant informe le responsable du traitement de tout changement prévu concernant l’ajout ou le remplacement d’autres sous-traitants, donnant ainsi au responsable du traitement la possibilité d’émettre des objections à l’encontre de ces changements.
Le traitement par un sous-traitant est régi par un contrat ou un autre acte juridique au titre du droit de l’Union ou du droit d’un État membre, qui lie le sous-traitant à l’égard du responsable du traitement, définit l’objet et la durée du traitement, la nature et la finalité du traitement, le type de données à caractère personnel et les catégories de personnes concernées, et les obligations et les droits du responsable du traitement. Ce contrat ou cet autre acte juridique prévoit, notamment, que le sous-traitant:
a)
ne traite les données à caractère personnel que sur instruction documentée du responsable du traitement, y compris en ce qui concerne les transferts de données à caractère personnel vers un pays tiers ou à une organisation internationale, à moins qu’il ne soit tenu d’y procéder en vertu du droit de l’Union ou du droit de l’État membre auquel le sous-traitant est soumis; dans ce cas, le sous-traitant informe le responsable du traitement de cette obligation juridique avant le traitement, sauf si le droit concerné interdit une telle information pour des motifs importants d’intérêt public;
b)
veille à ce que les personnes autorisées à traiter les données à caractère personnel s’engagent à respecter la confidentialité ou soient soumises à une obligation légale appropriée de confidentialité;
c)
prend toutes les mesures requises en vertu de l’article 32;
d)
respecte les conditions visées aux paragraphes 2 et 4 pour recruter un autre sous-traitant;
e)
tient compte de la nature du traitement, aide le responsable du traitement, par des mesures techniques et organisationnelles appropriées, dans toute la mesure du possible, à s’acquitter de son obligation de donner suite aux demandes dont les personnes concernées le saisissent en vue d’exercer leurs droits prévus au chapitre III;
f)
aide le responsable du traitement à garantir le respect des obligations prévues aux articles 32 à 36, compte tenu de la nature du traitement et des informations à la disposition du sous-traitant;
g)
selon le choix du responsable du traitement, supprime toutes les données à caractère personnel ou les renvoie au responsable du traitement au terme de la prestation de services relatifs au traitement, et détruit les copies existantes, à moins que le droit de l’Union ou le droit de l’État membre n’exige la conservation des données à caractère personnel; et
h)
met à la disposition du responsable du traitement toutes les informations nécessaires pour démontrer le respect des obligations prévues au présent article et pour permettre la réalisation d’audits, y compris des inspections, par le responsable du traitement ou un autre auditeur qu’il a mandaté, et contribuer à ces audits.
En ce qui concerne le point h) du premier alinéa, le sous-traitant informe immédiatement le responsable du traitement si, selon lui, une instruction constitue une violation du présent règlement ou d’autres dispositions du droit de l’Union ou du droit des États membres relatives à la protection des données.
Lorsqu’un sous-traitant recrute un autre sous-traitant pour mener des activités de traitement spécifiques pour le compte du responsable du traitement, les mêmes obligations en matière de protection de données que celles fixées dans le contrat ou un autre acte juridique entre le responsable du traitement et le sous-traitant conformément au paragraphe 3, sont imposées à cet autre sous-traitant par contrat ou au moyen d’un autre acte juridique au titre du droit de l’Union ou du droit d’un État membre, en particulier pour ce qui est de présenter des garanties suffisantes quant à la mise en œuvre de mesures techniques et organisationnelles appropriées de manière à ce que le traitement réponde aux exigences du présent règlement. Lorsque cet autre sous-traitant ne remplit pas ses obligations en matière de protection des données, le sous-traitant initial demeure pleinement responsable devant le responsable du traitement de l’exécution par l’autre sous-traitant de ses obligations.
L’application, par un sous-traitant, d’un code de conduite approuvé comme le prévoit l’article 40 ou d’un mécanisme de certification approuvé comme le prévoit l’article 42 peut servir d’élément pour démontrer l’existence des garanties suffisantes conformément aux paragraphes 1 et 4 du présent article.
Sans préjudice d’un contrat particulier entre le responsable du traitement et le sous-traitant, le contrat ou l’autre acte juridique visé aux paragraphes 3 et 4 du présent article peut être fondé, en tout ou en partie, sur les clauses contractuelles types visées aux paragraphes 7 et 8 du présent article, y compris lorsqu’elles font partie d’une certification délivrée au responsable du traitement ou au sous-traitant en vertu des articles 42 et 43.
La Commission peut établir des clauses contractuelles types pour les questions visées aux paragraphes 3 et 4 du présent article et conformément à la procédure d’examen visée à l’article 93, paragraphe 2.
Une autorité de contrôle peut adopter des clauses contractuelles types pour les questions visées aux paragraphes 3 et 4 du présent article et conformément au mécanisme de contrôle de la cohérence visé à l’article 63.
Le contrat ou l’autre acte juridique visé aux paragraphes 3 et 4 se présente sous une forme écrite, y compris en format électronique.
Sans préjudice des articles 82, 83 et 84, si, en violation du présent règlement, un sous-traitant détermine les finalités et les moyens du traitement, il est considéré comme un responsable du traitement pour ce qui concerne ce traitement.
Article 32
Sécurité du traitement
a)
la pseudonymisation et le chiffrement des données à caractère personnel;
b)
des moyens permettant de garantir la confidentialité, l’intégrité, la disponibilité et la résilience constantes des systèmes et des services de traitement;
c)
des moyens permettant de rétablir la disponibilité des données à caractère personnel et l’accès à celles-ci dans des délais appropriés en cas d’incident physique ou technique;
d)
une procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement.
Lors de l’évaluation du niveau de sécurité approprié, il est tenu compte en particulier des risques que présente le traitement, résultant notamment de la destruction, de la perte, de l’altération, de la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées d’une autre manière, ou de l’accès non autorisé à de telles données, de manière accidentelle ou illicite.
L’application d’un code de conduite approuvé comme le prévoit l’article 40 ou d’un mécanisme de certification approuvé comme le prévoit l’article 42 peut servir d’élément pour démontrer le respect des exigences prévues au paragraphe 1 du présent article.
Le responsable du traitement et le sous-traitant prennent des mesures afin de garantir que toute personne physique agissant sous l’autorité du responsable du traitement ou sous celle du sous-traitant, qui a accès à des données à caractère personnel, ne les traite pas, excepté sur instruction du responsable du traitement, à moins d’y être obligée par le droit de l’Union ou le droit d’un État membre.
#67.2
Pavé Caesar je te salue
#67.4
Toujours en revenir au texte, c’est l’essentiel, mais c’est vrai qu’il y a eu un petit problème sur la prise en compte des BBcode et notamment le gras (les petites étoiles).
Non, elle concerne la sécurité, l’inaltérabilité, la disponibilité des données, y compris contre les risques accidentels dont l’incendie, mais ça pourrait aussi être le cas avec la destruction par infiltration d’eau.
La logique du texte est la suivante : Si vous recueillez des données personnelles, vous devez vous mettre en mesure de parfaitement les sécuriser, et de vous aider pour cela d’une analyse fine des risques qui vous permet de prendre les mesures nécessaires.
Vous avez des datacenter qui présentent un manquement à la sécurité incendie et qu’un incendie détruit votre datacenter ? Et bien vous avez failli à l’obligation de sécurité que vous avez vis à vis du responsable de traitement et vous êtes condamnables à ce titre.
#67.5
Ce n’est pas que l’hébergeur qui est responsable, le service doit aussi mettre en oeuvre des procédures propres de backup. Sinon ça serai trop facile de ce décharger sur l’hébergeur dans ce cas là.
On leur donnera l’importance qu’elles ont ou pas mais si OVH peut justifier de l’obtention des certifications adéquate, ca le décharge de ça.
Ne jamais mettre tous ces oeufs dans le même panier.
#67.6
Les deux sont obliglatoire, point. Et votre backup, il n’empêche pas à des données personnelles de devenir inaccessibles, n’empêche pas une perte lorsque des données sont corrompues, ou non comprise dans votre dernier backup accessible.
L’obtention d’une certification ne dédouane de rien du tout, surtout lorsque les faits montre que derrière ces certifications il n’y a rien de solide.
Au mieux, la certification a dû vous faire progresser si elle est faite sérieusement, et doit vous permettre d’apporter des éléments montrant que vous respectiez vos obligations, rien de plus.
Si les faits démontrent que votre certification est au niveau d’une blague carambar…
#67.7
Je ne partage absolument pas cette analyse :)
Je confie des données personnelles à un prestataire, en choisissant une offre non-backupée , et/ou en construisant mon infra avec les offres de ce prestataire, sans prévoir de redondance dans ladire infra => ça n’est en rien la responsabilité du prestataire, mais bien la mienne, qui n’ai pas choisi une offre / construit une infra adaptée à la criticité de mon besoin (si un backup ou un PRA était vital).
#67.8
La responsabilité d’OVH pourrait effectivement être engagée si ils agissaient en tant que sous traitant, au sens du RGPD. Or, quand on regarde l’article 4, le sous-traitant est la personne “qui traite des données à caractère personnel pour le compte du responsable du traitement”. Et dans le cas de l’hébergeur, surtout sur un hébergement dédié, ce n’est pas le traitement qui est sous-traité.
#67.9
Si votre prestataire dans l’offre technique qu’il vous propose n’assure pas ses obligations de sécurité physique et logique (l’incendie c’est physique !), il est alors condamnable.
Vous n’êtes pas d’accord avec ça, mais vous ne faites pas la loi et le texte et son interprétation officielle est clair là dessus. C’est notamment pour ça qu’on fait des analyses de risque et qu’Ebios et d’autres méthodes existent !
#67.10
condamnable à la hauteur du préjudice, faut-il encore que ce préjudice soit estimable dans le cas des VPS privés.
pour les entreprises je dis pas, mais c’est à la charge des assureurs des entreprises de couvrir le préjudice puis de se retourner contre OVH en fonction des résultats de l’enquête non ?
#67.11
Il y a plusieurs fondements sur lesquels la société pourra avoir des comptes à rendre :
Responsabilité contractuelle, obligation de sécurité, préjudice causé.
Responsabilité délictuelle : négligence, préjudice causé.
RGPD : Les obligations de sécurité physique n’ont pas été respecté, des traitements de données ont été réalisé par les responsables de traitements sur des moyens techniques loués à OVH qui devient sous-traitant. Là pas besoin de préjudice, le non-respect s’il est démontré suffit à la condamnation. Ensuite il est possible d’intenter une action au civil pour condamner sur la base du non-respect du RGPD et du préjudice causé.
Responsabilité potentielle sur la base du droit social vis à vis de la sécurité de ses employés.
Pénal pour négligence, et heureusement qu’aucun employé n’est mort dans l’incendie, sinon c’est directement en correctionnel voir la cour d’assise pour les dirigeants de la société.
#67.3
La sécurité physique des données est à comprendre dans le sens « accès physique d’un tiers non autorisé aux données »; comprendre « éviter qu’un stagiaire puisse accéder au serveur, se brancher et dupliquer les données ».
Rien à voir avec les mesures anti-incendie présentes ou non sur le site …
#68
Données détruites = Respect du RGPD. Il n’y a plus de données personnelles, il n’y a plus de données du tout !
#69
Plus exactement, les données personnelles sont parties en fumée, et la fumée est devenue accessible à tout le monde, peut-on considérer que les données sont devenues accessibles à tout le monde ?
#70
Les offres d’OVH s’adressent aussi à des particuliers/autoentrepreneurs… Qui pour la plupart n’ont ni les connaissances ni les moyens de mettre en œuvre un PRA.
Quand on commande un VPS sur ovh, il propose une offre snaphsot et une offre sauvegarde automatisée, et c’est à peu près tout. Si jamais ces sauvegardes sont dans le même datacenter que les machines, est-ce vraiment la faute de l’acheteur ?
Oui, si c’est une boîte de 500 personnes spécialisées dans l’IT qui a fait ça, je ne dirais pas la même chose.
#71
Surment le gouvernement qui soutient Azur et Amazon cloud derrière tout ça pour empêcher le cloud Français de montée en puissance .
Depuis les années 50 ans les USA sont en guerre commercial contre la France …
#71.1
Justement, sur ce point, le RGPD est là pour faire prendre conscience aux acteurs français qu’il faut devenir bon dans le domaine de la sécurité autour des données personnelles, et il doit faire monter le niveau en faisant réaliser des analyses des risques et in fine les investissements nécessaires et ainsi se montrer au niveau des mastodontes américains, qui loin d’être parfait, ont certainement une longueur d’avance à ce sujet (notamment parce que là bas, les procès peuvent faire TREEEES MAL)
De manière beaucoup plus générale, les français doivent comprendre qu’on ne devient pas leader mondiale en institutionnalisant amateurisme et low-cost (c’est pas spécialement vis à vis d’OVH, je parle généralement d’une certaine mentalité qu’on retrouve dans pas mal de boites françaises).
#72
Des sprinklers traditionnels, non. Mais des sprinklers pour brouillard à haute pression, si.
#72.1
alors c’est pas du sprinkler c’est du brouillard d’eau c’est super différent tu en conviendra :)
#73
MDR! Je suis tellement habitué à lire “Virtual Rack” que j’étais complètement passé à côté de la blague
#74
,
#75
Y a une update les amis, SBG1 4 salles HS / 8 salles OK
#75.1
La question étant : Que veut dire HS/OK?
HS = data morte et irrécupérable ou injoignable?
OK = serveur UP et accessible ou juste data sauvée?
#75.2
HS = détruite
OK = intégrité OK mais faut remonter une alim et un réseau
Après j’ai cru voir qu’OVH proposait un backup FTP des données sur un autre site. Par contre je ne sais pas dans quel offre il est inclut ni si c’est une option très chère. S’ils ont des backup (même /24h) ils devraient pouvoir sauver quasiment tout, si c’est une option bah fallait lire toutes les lignes et s’occuper sois même du backup ^^
#75.3
https://twitter.com/olesovhcom/status/1369598998441558016?s=20
https://twitter.com/olesovhcom/status/1369592437585412097?s=20
il est précisé “no ETA”, comprendre “intégrité des serveurs OK” mais pas de remise en lignes avec quelques jours voir semaines j’imagine …
#75.4
Yep faut remonter les alimentations elec entièrement il semblerait et checker les salles réseau avant tout redémarrage (et remonter une salle réseau dans SBG5) il parle de 1 à 2 semaines rien que pour ça.
#75.5
il va y avoir une enquête (même pour déterminer que le feu est accidentel) du coup 1 à 2 semaines, une fois que les bâtiments seront jugés sécures (propres de toutes traces de suie etc.) et que l’instruction en aura libéré l’accès.
au doigt mouillé je dirais 6 mois minimum …
#76
Justement, pour le moment on ne peut pas blâmer OVH complètement. Le client qui prend une offre sans service de backup, il a choisit, c’est à lui de couvrir les risques.
J’ai raté un truc ou rien n’indique qu’OVH a perdu quelque donnée que ce soit de la partie sauvegardée/redondée? Dans ce cas OVH satisfait à ses obligations.
Et je ne prends pas OVH pour des amateurs - sinon, que dire quand les services MS tombent parce que quelqu’un n’a pas renouvelé à temps un certificat ou quand tout s’écroule parce que quelqu’un s’est planté dans la config du reverse proxy? OVH ne me paraît pas plus amateur que Amazon, Google ou Microsoft (travaillant avec des outils Ms, j’ai surtout des anecdotes Ms, mais je peux en sortir des vieilles HP comme par exemple de livrer 50 ordinateurs avec tous la même adresse MAC au même client)
#77
Le côté positif c’est que les consultants de qualité en DR et en PRA vont pouvoir augmenter leurs tarifs même s’ils étaient déja absolument indécents.
J’approuve
#78
Pas de cynisme dans ma phrase, juste un blague par rapport à la pensée que j’ai eue le jour où j’ai utilisé ce genre de briquettes : “c’est des allume-feu ou des matériaux anti-feu ?! On pourrait peut être en faire des constructions”
#79
Non c’est normal, et encore heureux que l’enquête n’écarte pas le contexte et la piste criminelle direct juste par anticomplotisme. Encore heureux également que la piste accidentelle ne soit pas écartée d’emblée juste par complotisme.
#80
Ok il a brûlé.
D’un autre côté, vu son emplacement, au beau milieu d’un fleuve, la probabilité de sinistre et spécialement d’inondation me semble conséquente.
#80.1
S’ils sont a coté d’un fleuve c’est que le risque d’inondation par ce fleuve est nul. Le risque feu est difficile a maitriser mais le risque inondation ce n’est que quelques regles de base. Si ton élément critique le plus bas est 10 metres au dessus de la plus grande crue tu es relativement tranquille du point de vue inondation.
#81
Je comprends pas que ça rende des serveurs indisponibles, dans le cloud les données ne sont pas répliquées à plusieurs endroits, un peu comme un torrent ?
#81.1
Ce n’est pas parce qu’ils parlent de OVHcloud, que c’est du cloud !
Plus sérieusement, le cloud, c’est des serveurs, données, services,… qui ne sont pas chez toi et que l’on accède par Internet.
Ce terme vient du fait que l’on représente souvent Internet par un nuage.
#81.2
Ce dont tu parle ça ressemble plus à service distribué, très complexe et couteux à mettre en place.
Globalement le cloud, tu paye pour un serveur virtuel (qui tourne avec d’autres serveurs virtuels sur un serveur physique), et tu met complètement de côté la gestion du matériel que tu laisse à la charge de ton prestataire. L’avantage étant que tu peux facilement augmenter la puissance de ton serveur (changement d’abonnement en gros) sans avoir à racheter un nouveau serveur physique et gérer la migration : ton prestataire s’en occupe pour toi.
Ton contrat peut inclure un service de backup (journalier par exemple), qui dans ce genre de cas te permet de charger ta dernière sauvegarde dans un nouveau serveur virtuel (qui tourne sur un serveur physique dans un autre DC) : si le serveur de secours est préconfiguré et n’attends que le chargement de la backup pour décoller, on peut appeler ça de la redondance à froid.
Tu peux aussi faire de la réplication avec redondance à chaud: tes données sont écrites simultanément sur 2 (ou +) serveurs (physiques ou virtuels), mais tu ne les lit que depuis 1 seul. Si celui sur lequel tu lis les données tombe, le trafic est redirigé sur le 2e. Ça se fait plus ou moins automatiquement et de façon transparente (avec un léger délai le temps que le système se rende compte que le serveur principal est down, et que les équipements réseaux redirigent le flux)
Dans le cas d’un service distribué tel que je l’entends, les données sont écrites sur les 2 (ou +) serveurs, et le système de redirige continuellement sur l’un ou l’autre pour les lire, en fonction principalement de la charge du réseau.
#82
Du coup quelle est la différence entre le cloud et un serveur classique si un incendie sur un seul serveur met tout HS ?
#82.1
c’est un abus de langage, il faut différencier le serveur physique (rack matériel dans une armoire) et serveur virtuel (un serveur matériel peut incorporer plusieurs serveur virtuel)
et encore y’a plein de nuances
là ce qui a brulé c’est pas un serveur mais bien tout le “data center” soit le bâtiment qui contient tout ces serveurs plus les auxiliaires (réseau, alimentation, refroidissement etc …)
#83
Je ne connais pas assez OVH pour me prononcer mais chez son concurrent online la sauvegarde est payante et ce n’est qu’un simple FTP. C’est à la charge du client de faire des sauvegarde et il y à aucune aide du service technique.
Chacun fait donc dans son coin son script de sauvegarde…
Mais avoir une sauvegarde des données c’est juste 50% du travail pour remettre un serveur en ligne. il faut aussi avoir un autre serveur de disponible. Bien souvent pour avoir accès à ce type de service il faut bien attendre au moins une semaine.
Pour résumer, l’avantage d’un mutualisé c’est de pouvoir facilement automatiser ce genre de délire mais tu va raquer car un abonnement par site, alors que sur du dédié tu aura les mains dans le cambouis mais tu pourra avoir plusieurs site pour un seul serveur.
A mon humble avis les hébergeurs de dédiés devraient proposer une solution clef en main pour la gestion de la sauvegarde. Surtout à l’heure de la fibre ou tu récupère plusieurs gigas en quelques secondes.
#84
Oles : Update 4pm
We plan to restart SBG1+SBG4+the network by Monday March,15 and SBG3 by Friday March,19.
In RBX+GRA we have the stock of new servers, pcc, pci ready to be delivered for all the impacted customers. Of course for free. We will add 10K servers in the next 3-4 weeks.
#85
Mais pour le serveur FTP de backup mis à disposition par OVH aux clients y a t-il des infos sur la dispo de ces backups ?
S’ils sont dans le même datacenter que les serveurs qu’ils sauvegardent ça crain.
#85.1
Bah j’ose espérer qu’OVH respecte la règle d’or du backup : 3-2-1
#85.2
Moi, pour avoir accès au FTP de backup, il faut s’y connecter avec la machine qui est backup…
C’est complètement con.
Je fais comment maintenant? –”
#85.3
Tu ne peux pas, via le manager, configurer les adresses IP qui y ont accès ?
#86
Bon courage à tous ceux qui ont perdu des serveurs ou des données, c’est pas cool.
#87
Logiquement un serveur de backup devraient être dans un datacenter différent. Mais de toute façon plus tes données sont critique et plus tu te dois de les sauvegarder régulièrement.
Pour avoir bossé pas mal de dans dans le domaine du web il est clair que la sauvegarde ( et la sécurité ) est vraiment le talon d’Achille de pas mal de “boite”. Mais je ne jette pas forcément la pierre car franchir le pas est très difficile car très couteux.
D’un côté t’a un site web avec 5 pages qui te coutera genre 600€ + 30€ l’année chez un “artisant”. De l’autre une boite te proposera la même chose pour 6000€ + 150€ l’année.
En théorie ça devrait fonctionner comme ça :
T’a un serveur principal qui devrait être relié à un serveur de backup.
Il devrait y avoir 3 types de backup. Le premier devrait être une image du disque dur, le deuxième une image des programmes et le troisième une exportation des données. Chaque type de sauvegarde ne devrait pas être lancé à la même fréquence. Question de temps et de poid.
Tu dois également avec un serveur secondaire qui est un clone du serveur principal comme ça si ton serveur principal est down le service est automatiquement basculé sur le secondaire.
Après ces absences de fonctions c’est ce qui permet théoriquement d’avoir des couts plus faible que sur du mutualisé. Sauf que quand il arrive ce genre de merde et que ça touche un datacenter entier tu peut faire fuire un maximum de client même si pas inpactés.
A mon humble avis il doit y avoir un paquet d’artisan web et de clients en PLS.
#88
Oui, c’est exactement ce que j’étais en train de vérifier à l’instant. Pour les serveurs dédiés ciblés entreprise, OVH inclut un service de backup baptisé “Backup Storage” bien plus rapide qu’un FTP classique. Sauf que le Backup Storage du mon serveur principal à RBX7 est juste à côté à RBX3. Le serveur de backup est à GRA2 (pour éviter les problèmes comme celui de Strasbourg) et son Backup Storage est aussi à RBX3. Contrairement à un serveur, on ne peut pas choisir le lieu du Backup Storage… Donc dans un scénario comme celui de cette nuit, tout partirait en fumée.
Bon, comme je fais moyennement confiance au Backup Storage, j’ai aussi des FTP. Apparemment, ils sont tous soit à GRA1 soit à GRA2. Là encore on ne peut pas choisir le site du FTP…
#89
Gandi sur Twitter qui enfonce le clou : “Pensée solidaire pour toutes celles et ceux qui vont passer quelques jours, voir quelques semaines à gérer la situation”
#90
J’espère que RBX ne va pas se prendre une météorite cette nuit.
#91
Oui je suis d’accord c’est très.. Très con.
Edit : peut être pour éviter une authentification et rendre plus simple l’écriture du script de sauvegarde par leur clients ?
#92
Sur ma console client. Tout va bien alors !
(ah merde, le serveur ping pas…)
#93
Ah les experts en sécurité incendie sur ce site… tmtMachtFrei entre autres, qui est a la fois paysan, chercheur, vétérinaire, pharmacien, expert en climat et maintenant expert EHS industriel.
Vous pensez VRAIMENT que personne n’a fait d’audits du site ? Ni les assurances, ni les pompiers locaux, etc. Sérieux ?
#93.1
bah au point où sont les choses, ouai personne a vérifié :o
#94
Je vais être mauvaise langue mais vous avez pas remarqué une chute des spams aujourd’hui ?
Bonus : Image de l’agonie d’un pauvre petit serveur : https://twitter.com/Skunnyk/status/1369638092810895366
(attention cette image peux choquer certaines personnes)
#94.1
Vu que je n’ai reçu aucuns mail sur ma boite pro … effectivement, jolie chute des spams :)
#95
Un nuage… de fumée, en effet!
Ça risque de leur faire bien mal commercialement, en tout cas, si la conception incendie de tous leurs bâtiments permet un tel développement d’incendie.
#96
@Equilibrium: même en étant un ardent défenseur du RGPD, je pense qu’en l’espèce RGPD est totalement hors sujet.
Dans le cas d’une cyberattaque avec perte de données, RGPD serait effectivement au cœur de la cible.
Dans le cas de l’incendie chez OVH, il s’agit avant tout de pertes (destructions) possibles de données (quelle que soit les dites données).
Le point a déjà été abordé dans plusieurs commentaires : hors les obligations contractuelles d’OVH, la responsabilité première quant aux données est du côté du client - qui est le détenteur des données - et qui est en charge - directement ou indirectement - de la gestion des systèmes hébergés chez OVH dans le cas de serveurs dédiés.
Je surpris de lire que des sites gouvernementaux ou institutionnels hébergés chez OVH ne fassent pas l’objet d’une géo-redondance sur deux sites distincts (pas dans deux data centres situés sur le même site).
En tout état de cause, ne pas dupliquer les sauvegardes (backup) sur un autre site est une faute professionnelle grave pour un responsable informatique (interne ou prestataire externe), quelque soit la taille de l’entreprise !!!
Plusieurs commentaires évoquent des Sprinkler comme système d’extinction automatique. Ne connaissant pas totalement la réglementation française, je ne peux pas juger ; néanmoins en Allemagne ou en Suisse, ce sont des systèmes à gaz rare qui sont utilisés, avec de nombreuses conditions associées afin de ne pas asphyxier le personnel pouvant être présent dans les locaux concernés lors du déclenchement du dispositif.
Il est mentionné dans les médias que les pompiers ne pouvaient pas couper l’alimentation électrique. Je pense qu’il s’agit d’un raccourci journalistique. L’alimentation du site a très certainement pu être coupée rapidement, en revanche les onduleurs n’étaient peut-être pas accessibles du fait de l’incendie.
Je suis client d’OVH et je leur souhaite beaucoup de courage pour redémarrer et reconstruire.
#96.1
Le RGPD n’est absolument pas hors sujet, il s’applique dès que des données personnelles sont traitées et ici impactés.
Une mythologie s’est développée chez les acteurs de l’informatique leur faisant croire que son application se limitaient aux cas malveillants type cyberattaque, ce qui est complètement faux. La perte accidentelle de données, et le fait d’avoir été négligeant sur la sécurité, cela cause un manquement au texte et pourra être sanctionné.
#97
A priori il y a des mauvais élèves concernant les sauvegardes…
https://nofrag.com/les-serveurs-europeens-de-rust-touches-par-une-panne-majeure/
#98
Ca me semble évident que si, une entreprise de cette taille là avec ces risques là a fait forcément un plan d’intervention avec les pompiers et s’est fait auditeur par les assurances pour déterminer les clauses de la prime. Sûr a 99.99%.
Un accident ca arrive, même chez les entreprises paranoiaques de l’EHS
#99
Je suis dans ce cas pour un client .
Le service en question dit « backup storage » est en gros un ftp mais qui n’accepte d’être accéder que par l’Ip du dédié auquel il est contractuellement rattaché…
Résultat : mon backup répond au Ping OUF 😅
Par contre pas possible de récupérer la data depuis mon ip fixe chez moi…
J’ai demandé à ovh de mettre mon IP perso en liste blanche mais vu la cata et les délais de réponse… l’es client sont contents quoi 🤓
#100
Je ne suis pas d’accord : il faut arrêter de laisser croire que n’importe qui peut s’improviser “informaticien”.
Ce n’est pas parce que j’ai fait une cabane en bois dans le jardin pour les chats que je suis entrepreneur de BTP.
Ce n’est pas parce que l’on a mis une guirlande électrique sur le sapin de Noël que l’on est électricien.
L’énorme mensonge des “nouvelles technologies” (terme que j’exècre) est de faire croire depuis près de 30 ans que n’importe qui peut faire n’importe quoi.
Les informaticiens doivent faire des efforts de professionnalisme : moins de bidouille, plus de résilience sur le long terme, et il faut arrêter de courir après les pseudo-innovations et autres buzz marketing.
Les vrais autodidactes motivés et rigoureux sont toujours les bienvenus.
Tous les autres sont priés de reprendre leurs seaux et leur pelles pour retourner jouer dans leur bac à sable.
À force de faire n’importe quoi au niveau informatique, on met en danger de nombreuses entreprises ainsi que les données qui vont avec.
Ne pas savoir que faire des sauvegardes est juste vital, ignorer l’importance des tests réguliers des procédures de restauration des données, ne pas faire régulièrement des exercices de PRA, prouvent seulement que de nombreux responsables (informatique, management, PDG) sont totalement incultes et, en conséquence, qu’ils ne méritent pas leur job.
Une informatique raisonnée peut réellement améliorer significativement les performances d’une organisation.
Néanmoins, il faut également accepter qu’une informatique performante a un coût !!!
#100.1
Très juste.
#101
La même chez moi. J’ai un statut normal pour le serveur, alors qu’il a fumé. Hébergement sur SBG2.
Et je suis d’accord avec toi, ce n’est pas normal d’apprendre l’information par des tiers. Ils ont nos mails pour nous contacter, Ca sert à ça.
#102
Si vos serveurs sont si critiques, pourquoi n’avez vous pas mis en place du monitoring ?
@All: les PRA doivent être formalisés, testés et vérifiés.
Les personnels concernés doivent être formés, et des exercices réguliers doivent être réalisés.
Les PRA se définissent sur la base des besoins métiers (business) et sur la base de véritables - et sincères - analyses de risque.
Tout ce que je lis ici me donne l’impression qu’il n’y a pas grand monde qui a fait “ses devoirs à la maison” avant l’incident; cf. les serveurs ftp de backup non accessibles.
Si tu veux la paix, prépare la guerre !!!
L’informatique au quotidien - y compris les aspects liés à la cybersécurité - c’est la guerre !!!
J’anime une conférence sur la cybersécurité demain - 2021-03-11 - et voici au moins les deux messages que je vais passer aux participants :
If you think good architecture is expensive, try bad architecture.
(Brian Foote & Joseph Yoder)
Plan for the worst, hope the best!
#102.1
On est au delà de préparer le DRP dans le cas présent, mais dans celui où le DRP s’exécute.
Communiquer est aussi une des composantes majeures de la gestion de crise. Quand t’apprends dans les médias qu’un DC de ton prestataire a cramé et non directement par lui, c’est regrettable.
J’aurais reçu le communiqué présent sur le site OVH.com à mon adresse de contact, j’aurais été satisfait.
Fort heureusement, à titre perso j’avais des sauvegardes et comme c’est un serveur personnel je n’ai pas d’enjeu business.
#103
Ma seule inquiétude avec OVH est le manque d’informations sur certains points.
Par exemple, j’ai un Hosted Exchange 2016. La FAQ précise qu’un backup quotidien est réalisé vers un autre serveur… d’accord, mais où ? Dans le même bâtiment ? Car l’incendie peut invalider le backup lui-même du coup…
Il faudrait que je vois comment réaliser une sauvegarde concrète du contenu, cela même si j’ai toujours gardé des réflexes dignes du POP (mes mails sont déplacés dans un dossier local dans Thunderbird quand je veux les garder, donc c’est à moi de gérer…) mais si je passe un jour au full IMAP, je vais devoir m’y coller.
J’ai subi une fuite de gaz à ma résidence la semaine dernière (me faisant donc penser à devoir faire héberger des données critiques quelque part sur Internet) et maintenant je vois un incendie comme cela. C’est déstabilisant
Il faut avouer qu’un peu comme beaucoup, je n’imagine pas une seconde qu’un évenement de ce type puisse survenir dans un datacenter vu le caractère critique d’une telle structure. On se dit que FORCEMENT des précautions sont prises blablabla… mais visiblement ça n’empêche rien.
Le résultat, RUST EU est complètement perdu, d’autres s’y sont aussi cassés les dents.
Bref, il faut que je travaille ça un de ces jours.
#104
Faut croire que non… Pourtant, toute boite qui a qq dizaines de serveurs dans une salle en a(vait).
Si cela pouvait calmer la fumisterie de tout coller dehors…
#105
Bon ben pour ma part un dédié à SBG2 , RIP
Par contre j’avais prévu le coup, le serveur de sauvegarde est à RBX, mais bon, par contre, faut que je trouve un serveur de remplacement, pas évident :)
Étonnant pour Rust EU qu’ils n’aient pas de sauvegardes…
#105.1
On peut pleurer ensemble, SBG2 - Rack: 72B45 RIP.
Par contre après relecture de mon contrat (SYS, je précise), je n’ai pas eu l’impression de voir si un remplacement sera fait. En attendant, je suis en train de réfléchir à l’idée souscrire à un autre dédié chez un autre hébergeur et si celui-ci est remplacé, ça me permettra de faire un cluster Proxmox et gagner un peu plus de résilience.
On verra dans la semaine les infos qui seront communiquées en ce sens, s’il y en a.
#106
Arf! Les serveurs pour la consultation ZFE “Grand”-Paris semblent avoir contribué à une hausse de la pollution à Strasbourg:
https://zfe-planclimat-metropolegrandparis.jenparle.net/
“L’incendie des serveurs d’OVH à Strasbourg a des conséquences sur le fonctionnement de ce site : les images et les documents en téléchargement ne sont plus accessibles.
Nous avons adapté les fonctionnalités qui restent opérationnelles pour que vous puissiez contribuer en attendant que l’environnement graphique soit rétabli.
Nous vous tiendrons régulièrement informés de l’état de la situation, notamment au travers de la page suivante : https://jenparle.statuspage.io/
Nous vous remercions de votre compréhension.”
L’Escrologie sur un nuage… noir!
#107
Mais tous les utilisateurs d’OVH ne se prétendent pas informaticien. J’ai une connaissance (que j’avais envoyée chez OVH pour remplacer une solution bien pire). Elle vivote comme “webmaster” pour héberger des petits sites vitrines associés à des espaces collaboratifs. Son boulot, c’est de mettre les données en forme, pas l’hébergement. Elle est capable de faire les MAJ nécessaires du serveur et des applications web, et c’est à peu près tout. Quand ça se complique je fais un peu de bénévolat, mais je ne vais évidemment pas y passer mes journées.
Elle n’attend évidemment pas d’OVH une garantie de service avec les pénalités qui vont avec pour faire appliquer le contrat. Mais soyons clair, si une fois par hasard ses sites sont indisponibles quelques jours, personne ne s’en offusquera.
Par contre, quand elle prend une option sauvegarde quotidienne, j’ose espérer qu’elle ne va pas se rendre compte que caché derrière 20 pages de petites lignes il y avait écrit que la sauvegarde était au même endroit que les serveurs et qu’OVH n’est responsable de rien. Bon en vrai je pense qu’elle a aussi des sauvegardes chez elle de la partie vitale, mais sous une forme qui ne va pas être drôle à restaurer.
Après on peut dire qu’il faudrait interdire à ces gens d’exister et passer par des SSII qui demandent plus de 30K€ pour monter un pauvre site drupal et son intranet, Hébergement/maintien en condition non compris. Et pour avoir vu le résultat, ça ne m’a pas paru si pro que ça… Et si le client final n’est pas lui même spécialiste et n’impose pas à son prestataire un contrat aux petits oignons avec les ressources humaines pour le faire appliquer, il risque d’avoir des surprises. Ah zut, il faut carrément interdire tout usage de l’informatique aux TPE, EURL…
#108
Le monitoring ne fait pas tout. Il donne une indication (le serveur est indisponible). Avoir une information de la part d’OVH indique une chose : le serveur n’y est pour rien, et il est inutile de vouloir tenter de le rebooter/remonter. Dans ce cas, on gagne du temps dans le PRA puisqu’on peut passer directement à l’étape suivante, comme la réinstallation sur un serveur tout neuf par exemple.
Il indique également que leurs équipes seront très certainement surchargés, d’une part pour le traitement de l’incident en lui-même, et d’autre part, pour le traitement de toutes les demandes qui peuvent y être liés.
C’est le principe de l’analyse des risques. Une analyse est et reste théorique jusqu’à ce qu’un véritable incident survienne. Et s’il y a des manquements, il faut en tirer des enseignements. C’est tellement facile sortir un “yakafokon” une fois les problèmes survenus. On a beau imaginer tous les scénarios inimaginables, il y en aura toujours auxquels on ne sera pas préparés.
Je vais prendre un exemple. J’ai des VPS. Des services non critiques. Je les ai pris il y a quelques années. A cette époque, et comme le relate 0/us/vps/vps-classic.xml" target="_blank">webarchive, les vps étaient sauvegardés toutes les semaines pour les besoins internes d’OVH en cas d’incidents. Ce n’est pas une notion que j’ai réussi à retrouver aujourd’hui sur leur site. Au contraire même, leur FAQ précise qu’ils ne sont pas sauvegardés ! Mon erreur ici ? Ne pas avoir regardé l’évolution des conditions d’utilisations des VPS. Il a fallu ce malheureux incident pour que je m’en rende compte.
Je l’aurais su, j’aurai changé mon PRA pour l’adapter en conséquence. J’ai bien une sauvegarde de mes données, mais pas une sauvegarde de la configuration entière du serveur. Ce n’est pas grave, ça peut attendre quelques jours.
Maintenant, j’en tire des enseignements. Mise à jour du PRA pour sauvegarder la configuration des serveurs, ET vérifier régulièrement les éventuels changements dans la politique des services utilisés.
#109
Ça va faire les affaires de 2crsi (autre boîte de Strasbourg!) et de son management toxique…
https://www.channelnews.fr/blade-en-redressement-judiciaire-octave-klaba-interesse-2crsi-affecte-101951
https://www.rue89strasbourg.com/enquete-2crsi-salaries-sideres-brutalite-direction-199376
#110
Encore en vert mercredi 10 à 21h45… je comprends mieux pourquoi je trouve jamais la panne de mes clients sur travaux.ovh.net.
Juste hallucinant !
#111
J’apprécie beaucoup le RGPD et en suit même un ardent défenseur. Mais ici, je ne vois pas comment on peut affirmer dès maintenant tout cela.
Déjà, pour clarifier les choses et être sûr que l’on parle bien des mêmes sujets, le RGPD intervient ici vis-à-vis de la violation de données, qui, comme tu le rappelles, ne se limite pas aux cyberattaques, mais englobe également la perte de données, que ce soit la destruction (sujet qui nous occupe ici) ou l’égarement (par ex. perte d’un ordinateur ou d’un disque dur dans le train).
Un élément important à prendre en compte c’est le côté temporel. Dans le RGPD, la perte de données est la perte définitive. La violation de données ne fait pas référence à l’indisponibilité temporaire.
Tout cela dit, prétendre que les obligations de sécurité physique n’ont pas été respecté, c’est y aller très fort. On ne connait pas les causes de l’incendie. On ne connait pas les mécanismes de sécurité en place, ni s’ils ont fonctionnés ou dysfonctionnés.
Est-ce qu’il y a eu perte de données ? En voyant que SBG2 est parti en fumée, et une partie de SBG1, je pense que l’on peut affirmer que oui. Mais c’est la seule chose qui puisse l’être actuellement. Prétendre que les obligations n’ont pas été respectées comme vous le faite est quel que peu prématuré.
Et il ne faut pas oublier une chose très importante. On peut prendre toutes les mesures de sécurité et de protection que l’on veut, elles n’ont pas pour but d’empêcher les pertes, mais de diminuer leur probabilité.
Enfin, qualifié OVH de sous-traitant au sens RGPD est quelque chose de discutable. OVH ne connait pas la nature des données qui peuvent être sur ses serveurs, et ce n’est pas parce qu’OVH réalise la maintenance desdits serveurs qu’il peut être qualifié comme réalisant un traitement sur les données (dont le caractère personnel n’est même pas avérés, même s’il y en a), sachant que le seul traitement qu’il lui serait éventuellement opposable est la conservation… sur une machine qu’il met à disposition !
#111.1
Je n’affirme rien, j’explique quels sont les fondements probables pour une situation comme celle-ci.
Sur la réalité des manquements, je n’en sais pas plus que le quidam qui s’intéresserait un tant soit peu au sujet.
Ce que je vois, c’est que le bâtiment fait cheap, l’intérieur aussi (voir les photos visibles publiquement) et le fait que les pompiers ont indiqué qu’ils n’avaient pas pu avoir accès aux locaux via la façade comme cela (doit ?) être le cas.
Et visiblement, la sécurité incendie a été déficiente, sinon l’incendie aurait pu être limité à une ou plusieurs salles ou un étage. Là tout un bâtiment a cramé et une partie d’un autre.
Au vu de ce faisceau d’élément, il est raisonnable de penser qu’il y a possiblement eu négligence à un certain niveau et que l’état de l’art en matière de sécurité incendie en datacenter n’a pas été respecté.
Et dans ce cas, oui, il est tout à fait possible de retenir un manquement au RGPD vis à vis des obligations de sécurité du sous-traitant sur les données personnelles que traitaient les machine détruites par le feu.
Après, je ne suis pas un procureur, je débat sur un fait divers porté à la connaissance de tous.
#111.2
J’adore les gens qui se disent simple quidam et pense tout savoir sur tout.
Un bâtiment peut être moche et sobre et fait en matériaux ultra-efficaces.
Si tu veux juger OVH, ce qui apparemment te tient à coeur, attends au moins le rapport d’enquête et le rapport de retour d’expérience.
#112
Petite mise à jour (10/03/21 21:03) sur la page :
http://travaux.ovh.net/?do=details&id=49484
#113
La hauteur du Rhin à Strasbourg fluctue relativement peu, c’est quasiment canalisé, avec de nombreueses écluses et zones d’innondation contrôlées en amont de la ville pour limiter les fluctuations de niveau à Strasbourg.
Cette zone est considérée comme à faible risque, même en cas de défaillance de certains systèmes de protection contre les crues : https://www.bas-rhin.gouv.fr/content/download/27877/192210/file/Note-PPRI-VF-web-144dpi.pdf (page 115, l’emplacement d’OVH est au niveau du premier embranchement en remontant le cours du Rhin à partir du haut de la carte)
Sinon OVH n’aurait de toute façon jamais eu un permis de construire à cet endroit.
RBX3 et RBX7 sont dans deux bâtiments bien distincts, avec même une rue entre les deux. Peu de chances qu’un incendie se propage de l’un à l’autre.
Faudrait voir si RBX3 est aussi utilisé comme backup pour RBX5 et RBX6, là il y a un vrai risque.
C’est la responsabilité d’OVH uniquement s’il a vendu des offres garantissant la sauvegarde des données et a failli dans cette garantie. Dans le cas contraire, le faute incombe au client, qui a stocké des données chez OVH en sachant qu’elles n’étaient pas sauvegardées : c’est au donneur d’ordre de s’assurer que l’offre proposée par le sous-traitant est conforme à ses obligations, surtout quand le sous-traitant ne connait pas la nature des données…
#114
N’inversons pas les choses, on peut tout à fait enquêter pour connaitre les causes de cet incendie, en se basant sur des faits et c’est normal, mais pas parce que quelqu’un trouve étrange que cela arrive au moment où il est question qu’OVH soit introduit en bourse.
#115
Je suis très loin du “yakafokon”. Je suis dans l’industrie depuis 32 ans et je fais des analyses de risques depuis le premier jour : d’abord en sécurité des procédés (y compris les aspects automation), ensuite en qualité et conformité réglementaire pharmaceutique.
Ce qui me désespère, c’est le manque d’honnêteté intellectuelle lors de choix techniques et organisationnels.
Tout comme la pandémie, les attaques informatiques et les incidents informatiques même conséquents sont prévisibles. On ne sait pas “quand cela se passera”, mais on peut être sûr que cela arrivera. Il faut donc se préparer en conséquence.
J’anime des formations depuis plus de 20 ans. Dans de nombreuses formations, j’alerte les participants sur la nécessité de planifier correctement (y compris vérification et exercices réguliers) la continuité opérationnelle et les activités de reprise d’activité. Je passe - trop souvent à mon goût - pour un “fondamentaliste” de la sécurité : “les risques sont seulement théoriques, cela n’arrivera jamais ! … Ce n’est pas possible que cela puisse un jour se produire …”.
De même, j’ai alerté dès la fin des années 2000 sur les risques associés à l’utilisation insuffisamment maîtrisée des solutions cloud, tant en ce qui concerne la disponibilité (y compris sur le long terme) des applications, que par rapport à la protection des données. La seule réponse régulièrement entendue est : “tu ne peux pas aller contre les évolutions technologiques”.
Cependant la principale question n’est pas d’aller contre les évolutions technologiques, mais de maîtriser pour le meilleur les moyens technologiques disponibles.
Tout cela se raisonne, se prépare, et se vérifie régulièrement.
#116
Je vais dire tout haut ce que tout le monde pense tout bas : c’est un excellent exercice pour les administrateurs des entreprises impactées pour tester si leur plan de reprise d’activité était au point ! (backups, redondance, etc.) Notamment chez OVH.
#117
Pourtant, écrire “RGPD : Les obligations de sécurité physique n’ont pas été respecté” me semble très affirmatif !
Et pourtant…. vous partez d’hypothèses non vérifiées, vous faites des suppositions, et vous en tirer des conclusions. Vous êtes vous posés des questions ? Comment l’incendie a-t-il démarré ? Est-il accidentel ou volontaire ? Pourquoi le feu s’est-il propagé si vite ? Pourquoi les pompiers ont eu du mal à intervenir ? Quel était le système anti-incendie en place ? A-t-il fonctionné ? Combien de temps les pompiers ont-ils mis pour venir sur place ? Combien de temps entre le début de l’incendie et sa détection ? etc… et il y a encore plein de questions de ce genre.
Prenons juste cet exemple. Déjà, en tant que simple quidam, vous arrivez à faire mieux que des experts en vous basant uniquement sur des photos pour déterminer la résistance au feu du batiment. Quels sont les matériaux utilisés ? Fondent-ils ? Sont-ils inflammables ? Sont-ils homologués ?
Concernant les pompiers (je n’ai vu nul part le témoignage de pompiers sur l’accès impossible mais cela ne veut pas dire qu’il n’en existe pas), vous êtes vous posé la question de savoir pourquoi ? Est-ce que le bâtiment était mal conçu ? Est-ce qu’ils n’avaient pas le matériel adéquat ? Est-ce que le passage était bloqué par un véhicule ou des travaux ? Pourtant, sans savoir, vous tirez déjà une conclusion.
Donc non, vous ne savez rien, car pour l’instant, personne ne sait rien, si ce n’est qu’il y a eu un incendie. Il y aura très certainement des enseignements à en tirer, mais il est bien trop tôt pour cela devant le manque d’éléments.
#118
OHV ne traite pas des données personnelles, c’est le client qui traite des données, peut-être personnelles. OVH fournit juste un hébergement.
#119
Je confirme que le nombre de spams a été grandement réduit
En fait je n’en avais pas tant que ça , mais maintenant je n’en ai plus du tout !
Quant à tous ces experts sur PRA et PCO je vous conseille de devenir consultants
Sur grosses entités on facture entre 1000 et 2000€ la journée.
Bonne chance
#120
“Informaticien”, ca veut surtout absolument rien dire. un ingé informatique, un développeur, un développeur web, un technicien micro, un webmaster et une secrétaire de direction sont tous des “informaticiens”, vu qu’ils travaillent tous sur informatique…
#121
Il y a quand même de quoi rester dubitatif, devant un tel autodafé numérique. On avait déjà entendu parler de “fuites” de canalisations ou de début d’incendie dans des baies, mais j’ai beau cherché dans ma mémoire : je n’ ai pas souvenir avoir déjà entendu qu’un bâtiment entier de datacenter soit parti en fumée + un début de second. Dans le genre, c’est quand même un (triste) record, surtout pour un site qui a ouvert ses portes en… 2012 !
Alors je ne sais pas si certaines des solutions avancées par d’autres ici sont réalistes et réalisables pour accroître la sécurité incendie. Mais dire qu’on ne peut rien faire / que c’est la fatalité / qu’on n’aurait pas pu faire mieux, c’est quand même trop facile. Quand vous payez 100€ / mois du serveur dédié, vous attendez la sécurité incendie qui va avec, et pas que le DC crame à la première étincelle venue !
Bref, on va encore attendre de voir ce qu’ils récupèrent de SBG1 pour tirer le bilan définitif, sûrement dans 2 semaines. Mais après une merde pareille, ils ont intérêt à la jouer soft au niveau de la relation client.
#121.1
Je crois que tu n’as jamais visité un ou deux anciens datacenters vétustes comme celui d’equinix par exemple. Et dans les exemples grosse fuite d’eau à l’étage (genre on avait 50 cm de flotte quant même) et qui a ruisselé dans tout le batiment en continue. Des exemples comme ça j’en ais plusieurs sur des interventions sur sites.
#122
Si j’ai fabriqué une belle cabane en bois pour mon jardin je suis normalement capable de faire une plus grande cabane en bois dans le jardin d’un pote. Et théoriquement je suis aussi capable d’en faire une à n’importe qui moyennant finance.
Le problème en fait c’est qu’il te faudra limite engager un entrepreneur en BTP “légalement” pour faire une grande cabane de jardin pour un homme. Généralement les prix sont tellement élevés qu’ils seront juste rédhibitoire pour le clients.
Après tu sais la plupart des clients sont au courant de ce qu’ils auront. Je ne serais pas entrepreneur BTP et si ils veulent une cabane jardin de 2 étages je refuserais ou alors je lui expliquerais bien les risques encourus.
Comprend bien qu’a un moment donné il faut bien ce lancer dans la partie et que tu ne choisis pas forcément quand. Comprend aussi que bien souvent un projet est très limité dans le temps.
#123
Attends, sérieux, je ne travaille pas dans la sureté industrielle, juste, je connais un peu les datacenters.
Et forcément, un tel accident pose la question du «et si cela nous arrivait»?
Et bien, là, il y a des capteurs de température dans le datacenter, qui sonnent l’alarme en cas de montée, car il y a d’énormes bonbonnes d’argon. Du coup, l’équipe qui est d’astreinte doit aller vérifier, et si il y a un incendie qui n’aurait pas déclenché l’ouverture des gaz, un gus peut les déclencher manuellement.
Ou faire évacuer le bâtiment si l’élévation de température (typique d’un réseau de clim’ qui s’est fait arrêter sans se poser de question, oui vécu) entraine une alarme de surpression des bombonnes.
Du coup, question de béotien: comment un aussi gros datacenter, homologué en plus, peut ne pas avoir de système anti incendie fiable?
#123.1
Aucun système n’est fiable a 100%. Aucun.
Question de béotien : comment le WTC a pu prendre feu ?
Dans ma boîte aussi on est parano sur l’EHS en général, et pourtant souvent il y a de gros accidents. On manipule des gros courants, du chimique, du biocontaminé, des grosses énergies sous forme de vapeur, etc. Crois moi qu’on a l’EHS sur le dos même pour aller pisser, à tel point que c’en est souvent ridicule.
Tout ce que tu sais faire c’est limiter le risque au maximum, et avoir un plan d’action prédéfini quand malgré tout une grosse crasse survient.
Perso je ferai comme dit un peu plus haut : vu que personne ne sait rien, je laisserai à OVH le bénéfice du doute et j’attendrai des conclusions d’experts sérieux.
#123.2
Les procédures sont là pour palier aux imperfections (en principe)
Je crois que nous sommes quelques uns à être impatients de décortiquer les conclusions de l’enquête, présentant l’enchainement des événements ayant conduit à ce braséro 2.0 ;)
J’espère juste que, pour préserver l’image de marque de OVH, cela ne soit pas consécutif à une mauvaise consolidation des sécurités parce qu’il fallait de l’argent pour financer leur expansion rapide… (suggestion 100% perso et 100% au doigt mouillé, je n’en sais absolument rien, et me garde de les accuser de quoique ce soit)
#124
Tout dépend quel est le périmètre concerné par la certification ISO 27001. Il n’y a peut-être que le DC de Roubaix dans le périmètre.
#125
le Service interministériel des Archives de France avait audité en 2019 ce site et pris en compte une moindre protection incendie. Il l’utilisait pour ses projets -évidemment- redondés/répliqués/sauvegardés sur d’autre sites.
Les archivistes sont bien plus paranoïaques que les informaticiens sur la préservation des documents papiers ou numériques !
#126
Et forcément, un tel accident pose la question du «et si cela nous arrivait»?
En fait ce n’est pas très important car cela n’est jamais testé ( on ne met pas le feu à une salle machine pour tester les systèmes incendie)
Il y aura beau avoir des étiquettes de certif et des normes machin chose , le fait est qu’on ne teste pas
La question plus pertinente AMHA c’est et si ça avait été un crash d’avion sur le batiment comment pouvait-on s’en sortir , quelles sont les solutions de redémarrage?
Comme l’a dit quelqu’un ici, peu importe si cela a l’air cheap , les assurances, les clients ont fatalement vérifié que le site était conforme et dans les normes,
#126.1
C’était moi.
Et franchement j’hallucine de voir tous ces pseudo experts de mes … accuser sans preuve en mode complotiste ou “tous des nazes tte façon, sauf papa et moi” alors que franchement, il suffit de réfléchir 3 secondes pour avoir la quasi certitude que des gens sérieux (assurances, pompiers, gros clients) font correctement leur job dans ce pays, l’un des plus riches et des plus sérieux du monde s’il fallait le rappeler.
A Tombouctou avec des creve la faim payés au lance pierre et sans budget j’aurais pas forcément dit la même chose, mais a Strasbourg faut être sérieux un minimum, quand meme
#126.2
Merci
On est tout à fait d’accord
J’ai visité des sites avec systèmes de piscine inversée à vannes pour contrer des zones inondables
Vérifié les trajectoires d’avion au cas ou , controllé le traffic de produits nocifs sur les wagons de chemin de fer en cas de déraillement à proximité, etc etc..
Les plans de la municipalité en cas de légionelose ou de danger Seveso pour les accès aux sites
d’hébergement
Tout ça pour faire de vrais PCO et PRA informatiques .
Je ne nie pas qu’on a éliminer certains sites , mais généralement sur des sites de cette ampleur ça se passait bien
Alors quand je lis tout ça j’ai un peu la nausée mais avec de l’humour car au moins ça conforte dans l’avenir de ce métier
#126.3
Ben si, c’est un peu testé quand même, via de la dispersion de fumée, pour vérifier le bon fonctionnement des capteurs, alarmes et actionneurs (en mode test, je te l’accorde) ;)
#126.4
En théorie il n’y a aucune différence entre la théorie et la pratique, en pratique il y en a
( c’est pas de moi
mais c’est vrai 
)
#126.5
perso j’aime bien la formulation suivante :
“[quelle est / tu connais] la différence entre la théorie et la pratique ? en théorie y’en a pas …”
#127
Notre Dame a bien brûlé à cause d’un mégot de cigarette, alors un datacenter peut aussi brûler à cause d’un mégot de cigarette. Vilain complotiste va !
#128
Il faudra attendre les conclusions de l’enquête pour savoir les causes de l’incendie. Rien ne peut être écarté.
Il y aura des choses à apprendre et comme le dit Octave Klaba : c’est la première fois en 21ans qu’ils font face à une telle crise.
Après les compétences sont là pour remonter au plus vite l’infrastructure. OVH a la maitrise complète de ses installations vu qu’ils font du sur mesure depuis des années.
Un exemple de leur communication de hier soir :
#129
A voir la cause effectivement, toute fois j’ai l’impression que les pannes sont assez courantes chez ovh.
Il y a un an ou deux c’était tout un datacenter coupé parce qu’un groupe électrogène n’avait pas voulu repartir.
Je veux bien que ça soit la faute à pas de chance, mais quand on met tout bout à bout la question peut se poser.
C’est peut-être un choix volontaire de réduire les coûts de fonctionnement en misant sur le fait que les gros problèmes arrivent rarement et coûtent moins cher que d’essayer de les anticiper au mieux?
Après idem je suis curieux de connaitre la cause à l’origine du problème. Tout est possible, problème d’alimentation/câble mal serré etc.
#129.1
Pour avoir des machines hébergées autant chez OVH que d’autres hébergeurs de tailles plus ou moins importantes, je peux te certifier qu’il y a des soucis partout. C’est juste qu’OVH étant le plus gros français, le nombre de clients potentiellement touché est forcement le plus important.
Lorsque mon hébergeur local tombe (perte accès internet au niveau du DC, perte d’alimentation également), je sais que je n’en entendrai pas parler car il est beaucoup trop petit.
#130
A partir de ce jour, je déclare que le 10 Mars sera le jour du “World Restore Day” (bah oui on a bien le world backup day…), ou a défaut le “World PRA Test Day”
Je trouve que beaucoup s’écharpent sur des sujets pourtant simple :
Sujet 1 : Le bois dans la construction du DC… pourquoi pas, c’est moins dangereux que l’acier vis à vis de toute l’électricité qui se balade, c’est plus modulable, c’est à lui seul un retardateur de feu contrairement au béton, et c’est beaucoup plus pratique aux pompier pour l’accès que le béton (on peut tout péter…
), et on a de très bons retours dans la construction. Je ne jette pas la pierre, on va dire pas de chance pour OVH.
Sujet 2 : Extinction incendie. Je pense qu’une boite comme OVH n’à pas fait l’impasse sur ce genre de chose. Ah oui c’est même indiqué dans leur page RGPD. De toute manière sur ce genre de site c’est obligatoire par le Code du Travail. Après que les systèmes n’aient pas été suffisant c’est une autre histoire… Malheureusement on ne le sait que trop tard le plus souvent, sachant que l’eau et le feu sont les éléments les plus imprévisibles.
Sujet 3 : Les serveurs privés, sont privés, à chacun de se démerder… sinon on prends du mutualisé. Et si la perf ne conviens pas, il y a plein d’autres hébergeurs qui font un bon boulot et qui sont aussi en France voire Europe. Donc sujet clos, chacun doit prendre l’infra a la hauteur de ses compétences. Perso j’ai monté vite fait des sites vitrines pour des amis, j’ai pas eu envie de gérer les serveurs comme je le fait pour le boulot, donc j’ai collé des Mutu ou des CloudWeb. Pour le coup c’est OVH qui gère et qui se démerde pour le PRA. Pour info Octave a bien précisé qu’ils allaient faire le maximum pour refournir des infrastructures dans les jours suivant l’incendie sans parler de la reconstruction d’un DC.
Sujet 4 : Les CGV qui changent sur les VPS (sauvegardé puis non), il faut se connecter au moins une fois par an pour valider les nouveaux contrats dans le manager OVH, et surtout les lire… bon je suis pas certain que tous le monde le fasse, mais OVH est iso sur ce sujet. Après j’avoue c’est casse pied car ca oblige à revoir notre infra. D’un autre coté, sur des machines sur lesquels OVH n’à qu’un accès en terme d’infra et non de soft, j’ai toujours backupé ailleurs… (je suis peut être parano mais bon…)
Sujet 5 dont personne ne parles : Vous vous rendez compte tout de même qu’ils vont reconstruire un DC temporaire en moins de 15j, en partant des auxiliaires jusqu’aux baies elles même? Perso ca me scotch… On peut toujours les traiter d’amateurs, mais j’en connais peu qui feraient un tel boulot en étant amateur…
#130.1
beaux rappels.
J’ajoute que beaucoup ici parlent de gaz inerte, d’argon, mais il faut rappeler plusieurs points.
Initialement un DC a des objectifs de redondance énergétique, réseau, climatique, ainsi qu’une sécurité élevée sur les accès physiques.
Dans le même temps, on a commencé à transformer des immeubles de ville en datacenter. TH2 boulevard Voltaire est un excellent exemple avec ses salles sur plusieurs étages. Là pas de place à la fantaisie. Climatisation, groupe froid sur le toit, groupe électrogène en sous sol avec des cheminées, etc.
Bien des datacenters construits d’office pour cet usage fonctionnent de la même façon mais à plat et en périphérie de ville.
On s’est alors dit qu’on pouvait peut-être refroidir plus intelligemment et efficacement les salles.
Sur ce modèle on concevait il y’a 40 ans des salles capables d’accueillir des gros systèmes, avec d’immenses faux plancher (parfois un mètre) contenant des circuits de refroidissements à eau.
Certain ont alors commencé à vouloir réduire la consommation d’énergie avec de l’eau passant au travers d’échangeurs avec une eau elle circulant à l’air libre parfois même sur des fontaines et autres plans inclinés maximisant l’échange avec l’air.
Dans tout les cas pré-cité, les salles sont fermées, et il est effectivement possible d’envoyer un gaz inerte après avoir laissé le temps aux éventuels bipèdes ou autres mammifères d’évacuer
Au fil des ans, le Power Usage Effectiveness (PUE) est devenu la priorité lors de la conception.
Et qu’est ce qui consomme dans un datacenter autre que les serveurs (pour lesquels on ne peut rien faire hormis suivre l’évolution des finesses de gravure et la réduction du TDP, ou mettre en place DRS sur son infra VMware si on est casse-cou…)
LE REFROIDISSEMENT !
Tandis que certains ont continué dans la voie classique de la climatisation, les acteurs de l’hébergement ont cherché comment éviter la clim à tout prix.
OVH est connu pour ses avancées sur le watercooling en masse, avec des racks dont l’arrière ressemble avec ses clarinettes à eau et ses tuyaux en plastique transparents à une ferme de canabis
Celà demande cependant l’aménagement des serveurs avec des waterblocks, ce qui augmente les coûts d’autant qu’OVH propose du dédié, donc une large gamme hétérogène de hardware.
Une autre piste est le free cooling où l’on ventile fortement les salles afin de renouveler l’air fréquemment. On garde la clim pour les jours chauds.
Mieux que le free cooling, le refroidissement adiabatique permet de faire évaporer de l’eau via une membrane spécifique, transférant les calories au passage. Rien de nouveau, les bédouins du désert font presque la même avant qu’on commence à transformer leur sable en CPU…
C’est le choix retenu par scaleway sur ses derniers DC avec une réserve d’eau glacée pour les jours difficiles.
Pendant ce temps là chez OVH, on a poussé le free cooling à l’extrême, ouvrant au grand jour les salles avec du grillage et parfois du simple plexiglass pour protéger des tableaux électriques.
Mais ça marche, même plus besoin de faire tourner les ventilateurs la plupart du temps.
OVH a alors imaginé utiliser l’air chaud lui-même pour créer un courant d’air ascendant, créant une dépression aspirant de l’air frais et ainsi de suite. C’est le concept du DC OVH de Beauharnois au Canada, une cheminée au milieu de la tour. Et il y’en a des tours dans ce DC.
Repensez maintenant aux consignes de bases lors d’un incendie, alerter, FERMER LES FENETRES ET PORTES, humidifier un linge pour bloquer les fumées sous la porte, se déplacer au sol, etc.
à votre avis, avec du free cooling open bar, à quel moment on peut arrêter la propagation d’un incendie dans une structure se voulant être une cheminée naturelle ?
Et le capitaine des pompiers le dit lui-même, c’était une cheminée.
C’est un datacenter, pas une industrie possédant des produits inflammables. Donc pas le même niveau d’équipement qu’une usine automobile par exemple.
On en vient à la question de la séparation entre les bâtiments. Je rappelle à toutes fins utiles qu’on a banni eu Europe les maisons à colombage suite à leur capacité de transmission des flammes. Et à l’époque y’avait pas de plan local d’urbanisme.
OVH s’implante en bordure de grandes villes, ça facilite l’accès à différents postes sources RTE ainsi qu’aux opérateurs. La pression foncière est alors un argument de plus pour construire à la verticale et empiler. Et également sacrifiant les distances élémentaires de sécurité entre des bâtiments.
Pendant ce temps là, regardez les DC des grandes banques du pays, en plein propriété. Ils sont situés généralement à plus de 25 km des grandes villes, sur des terrains immenses. Les bâtiments y sont espacés. Alors oui, l’arrivée électrique et réseau sont plus chers et plus longs à faire venir. Mais le résultat est la conservation d’un modèle à plat, ou un incident a peu de chances de ravager l’ensemble du site (tant que le voisin ne stocke pas du nitrate d’ammonium…)
Vous pourrez les trouver une partie de ces DC de banques autour de Lieusaint, Chelles, Chartres, Castre, Albi,… Généralement pas loin d’une autoroute ou d’une voie ferrée pour faciliter l’accès aux opérateurs.
En résumé OVH a un modèle extrêmement efficace, mais la concentration des actifs verticalement et horizontalement a peut-être été faite à outrance.
L’enquête abordera forcément les matériaux, la problématique de l’accès aux étages via l’échelle pompier, la trop longue période avant la désactivation intégrale de l’électricité, la présence (supposée) de batteries au sein même des pods d’hébergement alors qu’elles ont leur place dans un local sous gaz inerte.
La conception de DC reste l’occasion d’expérimenter, certains envoient des calories dans le chauffage urbains, d’autres pompent l’eau d’un lac comme le ferait une centrale nucléaire,…
Mais l’expérimentation a peut-être trouvé là une limite.
Mais comme dans beaucoup de domaines, l’aéronautique, la sécurité routière, la construction de ponts, de stades, de gratte-ciel, c’est le retour d’expérience qui enrichi les projets futures.
Et saluons un point, les mesures d’alerte et de retardement ont permis aux équipes d’évacuer à temps, et c’est à celà qu’elles servent au minimum sur un site ne représentant pas de risque industriel pour la population.
#130.2
Très beau point que je survalide.
Les options de sauvegarde existent, à chacun de savoir s’ils en ont besoin ou pas, personnellement pas besoin car je fait autrement, donc je ne vois pas l’intérêt de payer un outil qui ne me sert pas. De la à dire “c’est pas sauvegardé, j’ai tout perdu”….et bien c’est clairement pas la faute de OVH, mais de celui qui n’à pas voulu cocher les bonnes options.
Question coût :
Mais oui forcément ce sera plus rapide, car je serais tout seul dessus… Bref ce n’est ni comparable, ni le même besoin.
D’autant que sur un mutu perf ou un cloudweb je n’ai absolument pas les soucis que tu mentionne avec justement des wordpress installés sur des ces mutu (quant à prestashop ils conseillent l’offre perf a minima). Et attendre 30min pour une nouvelle BDD ca ne vaut que lorsqu’on crée un hébergement complet, sinon en moins de 5 minutes c’est fait.
#130.5
Alors j’ai été voir les offre d’ovh et je propose mon méa culpa ! Les prix ont sacrément baissés et en théorie selon les fiches technique l’offre de base mutualisé équivaut plus ou moins à un dédié chez online.
Je me demande même si ça vaudrait pas le coup que je passe chez eux en mutualisé car je ne suis plus dans le métier depuis quelques années, j’ai plus que 3 sites vitrines encore actifs.
#130.3
Très bon rappel, my 2 cents :
Cherchez des infos sur le frigo à cannette du désert, une chaussette humide, une cannette, et hop par la fenêtre du pickup qui roule. Vous aurez les bases du refroidissement adiabatique et du free-cooling. (marche aussi avec les pots de terre cuite et un tissu humide d’ailleurs pas con les habitants des pays chauds)
J’ajoute aussi que les systèmes de protection incendie sont pas qu’à la charge d’OVH mais aussi de son assureur qui va valider et imposer ses propres contraintes, de mémoire j’avais entendu des solutions par brouillard d’eau chez OVH + détection laser (le gaz tue, le brouillard d’eau étourdi un humain mais ne le tue pas)
Il reste qu’aucun système n’est parfait et qu’on ne sait pas ce qui à causé le soucis. Rien ne dit que le/les feux a/ont pris dans une salle. Un câble rongé par un rat qui fait court circuit et prend feu dans un mur c’est arrivé (la SNCF à fait tomber le réseau de la gare Montparnasse comme ça une année) et si le feu se répand dans un mur toutes vos solutions, gaz ou vaporisation seront sans effet car le feu sera extérieur à la zone.
Au final vous aurez toujours un risque, les solutions anti feu des datacenters sont drastiques mais le risque zéro n’existe pas et tout n’es pas maitrisable. Même une panne d’un système fortement contrôlé. Souvent ils ont pour but de ralentir le sinistre le temps d’acheminer de plus gros moyens (murs anti feu). Comme dit par JCLB quand l’espace est contraint c’est plus compliqué de ségréger le sinistre.
Au final ne pensez pas qu’ils n’avaient pas de solution anti incendie fiable, robuste et efficace. Ils en avaient une, il faut maintenant identifier les/la faille dans la protection, zone non couverte, panne, problème “exotique”,… Et ils en tireront les conclusions et je peux vous assurer que les assureurs du secteur iront voir leurs clients avec ces conclusions pour vérifier leurs installations quelqu’en soit le prix.
Un désastre ça arrive, Un Datacenter est conçu pour résister à un feu et pourtant… Un avion est conçu pour ne jamais s’écraser et pourtant… un rover martien pour se poser sur mars et pourtant… l’ENA pour former des gens intelligents pour servir l’intérêt général et pourtant …
#130.4
Ça vaudrait limite le coup que tu fasses une pige pour Nxi, passionnante ton explication!
#131
Ayé !
Premier Spam depuis 2 jours … des cartouches d’encre
Le coupable dans mon bureau
#132
je me suis fait la même réflexion ! perso, au doigt mouillé, je voyais au moins 6 mois pour remettre en route rien qu’à cause de l’enquête.
La ville de Strasbourg voir la région doit certainement tout faire pour aider OVH à redémarrer en se posant les bonnes questions au niveau des procédures administratives.
#132.1
Exact
Sur des catastrophes majeures, il y a aussi des deals spéciaux, avec les fournisseurs, les intervenants etc
Un excellent exemple ( sur une autre échelle) est le tremblement de terre de San Francisco ( en 89 je crois) ou les entreprises de reconstruction des autoroutes et ponts avaient signé des contrats de fins de travaux avec la ville sur 90 jours ou 100 jours
mais ça donne une idée de ce qui peut être fait dans des moments aussi critiques
Avec 1 million de dollars d’amende par jour de retard et 1 million de dollars de bonus par jour d’avance.
Les boites finissaient les travaux avec 10 ou 20 jours d’avance en moyenne
( bon il est sûr que les règles d’embauche ne sont pas les même
Correction c’était San Francisco plutot que Los Angeles il me semble
#132.2
N’oublions pas qu’ils ont la techno du DC dans le conteneur, comme initié sur SBG1 et massivement utilisé dans BHS, pour du temporaire il y a moyen qu’ils aient quelques conteneurs en rab quelque part…
En revanche je viens de voir plusieurs photos, SBG1 a bien souffert, il y a quelques conteneurs carbonisés en effet. Et d’après ce que j’ai pu voir à droite à gauche sur le net, la structure du bâtiment SBG2 avec les “cheminées intérieure” (comme le RBX4) pour la dissipation de la chaleur aurait pu favoriser la propagation en empêchant les pompiers d’accéder au centre du bâtiment. (ca reste que supposition) Peut être une piste à étudier sur l’amélioration du concept… genre “piscine centrale”
#133
J’ai bossé dans une entreprise de poutres en lamellé collé.
Sur un chantier d’un grand hall sport, alors qu’on avait installé nos poutres il y a eut un incendie sur les engins de chantier en dessous (élévateurs, générateurs, nacelles, réserve de carburant etc)
ça a bien chauffé et les pompiers n’ont pas pris de risque donc ils ont juste arrosé de loin.
Les poutres, on pouvait les raboter et les remettre en place ça serait passé crème
y avait même pas 1cm de bois extérieur qui avait un peu cramé.
Bon vu les assurance etc on a recommencé le taf, mais on en a gardé un morceau d’une comme exemple.
#134
Mon appartement est privé et pourtant quand j’en emménagé je n’ai pas changé la serrure… Si je décide de changer la serrure je peut le faire moi même ou payer un mec et je ne suis pas obligé de changer la porte.
Tu peut très bien rajouter un outil dans le panneau d’admin pour gérer ça. Mais comme je le disais plus haut c’est du cheap donc tout est raboté au maximum niveau cout et si tu veut des options tu paye.
Ce qui n’est pas normal c’est qu’un dédié à 10€ par mois sois 10 fois plus rapide avec 10 fois plus de stockage qu’un mutualisé à 25€ par mois… Et qu’il faut environ 50€ par mois pour s’approcher de la puissance et du stockage d’un dédié sur du mutualisé.
Et je ne parlerais même pas de l’optimisation… Un site avec 10 visites par mois va ce retrouver mutualisé sur un dédié avec que des sites qui ont eux aussi 10 visites par mois. Comme ça ils peuvent en caler un maximum pour le moins cher possible et vendent ça à prix d’or.
Tente d’installer un blog wordpress et / ou une boutique prestashop sur du mutualisé OVH tu verra c’est méga lol. Ce qui est encore plus lol c’est de demander a ton amis le prix du site chaque année à cause de l’hébergement.
Le moment le plus lol c’était les 30 minutes d’attente pour la création d’une nouvelle BDD. Non je déconne, le plus LOL c’était les 8 secondes de temps de chargement quand je passais le site en mode debug qui désactive les caches et optimisation pour dépannage.
#135
Pour le dernier point, je suis désolé mais tu te fourvoie, l’ENA n’à jamais eu cette vocation.
l’École nationale d’administration a pour principes fondateurs de démocratiser l’accès à la haute fonction publique et de professionnaliser la formation des hauts fonctionnaires. On a jamais parlé d’intelligence
#136
Pour des poutres de gymnase en lamellé/collé, ça ne m’étonne pas que cela résiste bien. Même sur une charpente traditionnelle bien moins largement dimensionnée qui a pris feu en général les grosses poutres sont toujours là, sans même parler de chêne multi-centenaire qui a pu en connaître plusieurs.
Par contre, une charpente industrielle en résineux ou les planchers, ça ne fait pas long feu et en prime il en faut peu pour les allumer (une VMC mal entretenue/encrassée dont le bobinage moteur chauffe, même avec un disjoncteur de 2A en face, y suffit trop souvent dans des constructions n’ayant pas 5 ans).
Plancher bois sur structure métallique, je pense qu’on est quand même plus proche du second cas que du premier. Je dirais même que le résultat en atteste: C’est un choix de rapidité de montage et d’économie. L’avantage, c’est que cela va permettre de reconstruire vite également.
Mais in-fine, les clients pourraient quand même être tentés d’aller voir ailleurs après avoir compté leurs pertes, vu que cette conception a l’air courante chez OVH. Plus encore pile à un moment ou le e-commerce est pour beaucoup le seul moyen de maintenir une activité.
Bref, il va sans doute falloir ramer pour rassurer et améliorer la situation de l’existant.
#137
Les community managers (aka agents d’influence) d’OVH n’ont pas pu empêcher l’incendie. Mais ils travaillent dur sur nextinpact pour juguler les critiques envers leur boite.
Et qu’il faut plaindre les pauvres personnels d’OVH, et les pauvres pompiers. Oin oin oin. Par contre, les clients qui n’ont pas fait de sauvegarde et qui n’ont pas bien lu leur contrat, ben, c’est des pauvres cons et qu’ils aillent se faire voir. Ils n’avaient qu’à apprendre à lire. Non, ce qui est important c’est le pauvre OVH. Et ces pauvres dirigeants. Oh, je n’aimerais pas être à leur place. Ça doit être terrible pour eux. Oh oui ma bonne dame, ils doivent vivre des heures bien dures.
Et bien sûr, un incendie comme ça, ça peut toujours arriver. La faute à pas de chance. Ne nous faisons pas les juges du pauvre OVH mes bien chers frères.
#137.1
Sans être pour ou contre OVH, ceux qui se plaignent n’avaient simplement pas fait dans les règles de l’art (soit par non connaissance, soit par incompétence, soit par fénéantise). C’est pour cela qu’il existe des professionnels accessoirement, même si personne n’est exempt d’une erreur.
L’art s’apprends, parfois à nos dépends, et pleurer ne changera rien.
OVH est dans le même cas, ca n’aurait pas du brûler, il n’y aurait pas du avoir autant de dégats, peut être ont ils fait des erreurs, peut être pas. Mais eux je ne les entends pas pleurer, et dire “C’est la faute de X ou Y qui aurait du résister au feu” ou “C’est la faute des pompiers qui n’ont pas su éteindre le feu, pourtant c’est leur job”.
Les torts sont donc partagés. Même si j’ai plus d’empathie pour OVH car le feu est plus difficilement maîtrisable et anticipable qu’une simple sauvegarde, qui relève elle du bon sens.
#138
Ça c’est sûr, mais l’idéologie anticomplotiste arrive à me faire peur, comme si on était capable de cacher et fermer les yeux sur des méfaits, complots, malveillances, de peur d’“alimenter le complotisme”. Les criminels sont aux anges avec une telle façon de penser qui se répand.
Faut arrêter aussi avec les “faits”, c’est pas ça l’enjeu, l’enjeu ce sont les questions qu’on choisit de poser pour les rassembler, ces faits. Et on peut omettre (sciemment même) de poser les questions menant aux faits intéressants, ça arrive évidemment.
#139
OVH ne semble pas mettre à disposition publiquement son certificat ISO-27001, donc pas moyen de contrôler le SoA… Sur le blog d’OVH CLoud, il est fait rférence à Roubaix, avec volonté (?) d’étendre cela aux autres DC dont Strasbourg et autyres sites France. Si quelqu’un a l’info, je suis preneur.
#140
Le communiqué vidéo d’Octave Klaba indique qu’une intervention venait d’être effectuée sur deux onduleurs de Strasbourg 2… et à l’arrive des pompiers ces deux onduleurs ont été identifiés comme point chaud par la caméra thermique.
Selon lui tout a été filmé et il sera possible de déterminer la chronologie précise des événements afin d’en tirer les enseignements nécessaires dès que les images seront accessibles.
L’assureur de la boîte des onduleurs doit commencer à transpirer
#141
Heu, il est quand même sensé assurer l’hébergement des données ou serveur qu’on lui confie, pas leur destruction !
#141.1
Tout dépend de l’offre, perso j’ai des serveurs où ils me doivent juste l’infrastructure, le reste c’est nous qui gérons, le jour où la machine crash, j’en crée une nouvelle avec une image et ça repart en 5minutes. Tout dépend des besoins.
#142
Vidéo explicative d’Octave KLABA le 11/03/2021 à 16H01 :
https://www.ovh.com/fr/images/sbg/index-fr.html
#143
Cela dépend des offres.
Un hébergement, oui, un serveur bare métal on est simplement sur de la location d’un serveur.
La redondance, ça coûte cher. Si le client ne prends pas une offre redondée, c’est son choix pas celui d’ovh. Et heureusement, car cela permet une grande flexibilité aux clients suivant les besoins, et cela permet aux personnes n’ayant que peu besoin de sécurité de leur donnée de disposer de serveurs à petit prix.
#144
Non, j’ai déjà check….j’ai ouvert un ticket aujourd’hui, mais je ne pense pas avoir la réponse dans l’immédiat…
J’espère que mon collègue a mit en place un script de sauvegarde quand il a mit la VM en place avant mon arrivé.
Là je ne peux même pas vérifier, ça m’énerve.
#145
Je ne suis pas certain de comprendre tout ce que tu expliques, mais dans le cas dont on discute, à priori il va y avoir une enquête des pompiers à minima, pour remonter jusqu’au départ de l’incendie, déterminer sa source. En fonction de ça, il y aura peut-être une enquête criminelle ou pas. Après, quand tu parles d’omettre sciemment de poser des questions, tu sembles poser tout de suite comme affirmation que des gens veulent masquer ou déformer des choses. Direct dans le complot donc, de ma compréhension. Partant de là, on ne peut plus faire confiance à personne non? En ce qui me concerne, ce n’est pas ma façon de fonctionner.
#145.1
D’autant qu’après avoir vu la vidéo d’octave, on pencherais pour une défaillance ou mauvaise maintenance d’onduleur. Ce qui reste encore à prouver biensur.
#145.2
C’est la mienne, et heureusement qu’il y a les deux, parce que toi tu es handicapé par tes biais (de confirmation etc.) pour réfléchir à des hypothèses de complots, et moi je suis handicapé pour réfléchir à des hypothèses accidentelles.
Bon en réalité c’est plus nuancé que ça mais tu vois l’idée. Faut arrêter d’opposer les deux, et en même temps il faut se discipliner pour ne pas partir dans des délires et se contenter de poser des questions et d’accepter les réponses trouvées.
#146
Artificialiser les sols en construisant tout à plat, c’est pas forcément le modèle le plus intelligent de construction… (surtout que j’en déduis de tout ce que tu as écrit avant que ça nécessite plus de refroidissement actif donc un PUE plus élevé).
Les centrales pompent plutôt dans les rivières (le flux est naturel et dilue la montée en température si l’eau chauffée est rejetée en aval).
En sûreté, personne ne garantit ça (ou alors c’est un charlot). Le maximum est fait pour que les probabilités d’un incident soient les plus faibles possibles, et le maximum est fait pour que les conséquences d’un incident soient les plus limitées possibles. C’est d’ailleurs, dans le domaine tout autre qu’est la sûreté nucléaire, sur ça et donc le fait que jamais un rapport d’EDF, de l’ASN ou de l’IRSN ne prétendra qu’il ne peut rien arriver (c’est impossible à prouver) que jouent les ONG anti.
#146.1
Bien vu pour les rivières et les centrales, Un DC peut se contenter d’un lac suffisamment grand. Le volume de calorie à évacuer est largement plus faible. Une centrale sans évaporation sur la côte de la manche aspire environ 40m3/s d’eau de mer. Facebook a par exemple étudié ça en Scandinavie, avant de se rabattre sur du free cooling en Suède à (préparez UTF-8) Luleå.
L’histoire rappelle d’ailleurs celle d’OVH à Strasbourg qui a en quelque sorte “repris” la consommation d’énergie d’une industrie. Facebook a lui récupéré les arrivées d’une sidérurgie.
https://www.theguardian.com/technology/2015/sep/25/facebook-datacentre-lulea-sweden-node-pole
En 2015 AliBaba a d’ailleurs construit un DC refroidit via l’eau d’un lac.
Si l’on se focalisait réellement sur l’artificialisation des sols on commencerait par avoir des magasins multi-étage à la place des innombrables hangars de zones commerciales type hyper, bricolage, magasin de sport,.. dont la surface construit chaque mois dans le pays doit dépasser celle de la totalité des DC.
Et si le multi-niveau permet de fédérer le refroidissement, il est plus beaucoup plus cher à la construction. (Le vrai multi niveau avec plancher, pas les racks empilés au fenwick d’OVH).
#147
Heureusement, les DC n’ont pas 4 à 20 GWth à refroidir !
Je sais pas ce qu’on trouve de si intéressant à construire de ces trucs partout d’ailleurs (les Chinois, par exemple, n’aiment pas du tout ce modèle)
C’est vrai que les banques manquent de moyens financiers ;-)
#148
Merci.
#149
Si tu veux quelque chose d’un peu plus “abouti” en terme de perf pour du wordpress, je te conseille de regarder du coté d’Infomaniak aussi, qui n’est pas beaucoup plus cher, mais avec une offre mutualisée spécialisé sur Wordpress plutôt efficace.
#150
Un systeme chez nous est devenu indisponible hier a cause de cet incendie.
Maintenant c’est rétabli
#150.1
Nous aussi, notre prestataire n’avait pas de serveurs sur SGB1 mais sur SBG2, SBG3 ou SBG4 et aussi sur Roubaix par contre ils ne font rien pour l’instant pour que l’on ait de nouveau accès à l’application qui est indisponible et attendent paisiblement qu’OVH redémarre ce qui n’a pas brulé prévu pour le 19mars…
#151
Une question au sujet des VPS. J’en ai un qui a totalement disparu de mon interface admin. Du coup, je ne peux même pas savoir où il était situé. Suis-je le seul dans ce cas ?
Pour info, le VPS est bien entendu injoignable !
Comme il était un peu à l’abandon depuis début février (rien de critique, VPS de test pas utilisé actuellement), je ne sais pas si c’est lié à l’incendie ou si cela date d’avant
#151.1
As tu souvenir du DC exact? car normalement c’était noté dans la liste des instances VPS.
Ensuite, vu que toute l’infra SBG est à l’arret, ce n’est pas forcément anormal de le voir disparaitre.
EDIT : Je viens de vérifier, il semblerait que les VPS soient sur SBG1. En espérant que ce ne soit pas dans la zone qui as été touchée…
#151.2
Non je ne m’en souviens pas. Et comme il n’apparait pas dans la liste de mes VPS, ben je ne peux pas avoir l’info. Pour mes autres VPS, pas de souci par contre !
Après, effectivement, vu la situation, ce n’est pas forcément étonnant. Mais dans leur FAQ, il est précisé comment voir dans quel datacenter se trouve l’instance… quand elle est listée !
Et le DC n’apparait pas non plus sur les factures, ni sur les mails de déploiement du VPS…
#151.3
Oui la zone SBG a totalement disparu excepté dans les quotas
#151.4
D’accord merci ;)
#152
Si tu as besoin de simples vitrines sans traitements derrière, tu peux éventuellement le faire aussi en site statique (avec un outil comme Hugo, Jekyll, etc).
Ca demande très peu de ressources et le contenu peut être hébergé sur un ObjectStorage (qui coûte quasi que dalle) avec une instance light qui fait office de frontal. Et les sources sur un Git.
Dans la mesure où je suis actuellement en train de reconstruire le serveur perso que j’ai perdu chez eux, je suis en train de mettre en place cette optique justement où je réserve le serveur web aux applications en ayant vraiment besoin, et le reste du contenu statique sera stocké sur l’object storage. Le coût est nul du moment que le stockage ne dépasse pas le GB, sinon c’est facturé 0.01€HT/GB/mois, ce qui reste dérisoire. (mes backup dessus me coûtent 2€ par mois)