Brand verwoest datacenter van Franse provider OVHcloud

Een brand bij OVHcloud in Frankrijk heeft een datacenter van het bedrijf in Straatsburg verwoest. Een tweede datacenter is deels getroffen en twee andere datacenters zijn nog offline. Die komen vandaag ook niet online volgens het bedrijf.

Brand bij OVHcloudIn de vroege ochtend van woensdag was er een groot incident bij het SBG2-datacenter van OVHcloud in Straatsburg, schrijft OVHcloud-oprichter Octave Klaba op Twitter. Volgens hem ontstond het vuur in het gebouw en was de brandweer snel ter plaatse, maar kon de brand niet onder controle gekregen worden. Het is niet bekend waardoor de brand is ontstaan.

De brand heeft ook impact op de nabijgelegen datacenters SBG1, SBG2 en SBG3. Volgens Klabe is SBG1 ook deels verwoest en koelt de brandweer de andere gebouwen met water om die te beschermen. Om 7:20 uur woensdagochtend was de brand onder controle. SBG3 en SBG4 zouden nog in orde zijn, maar omdat de datacenters niet toegankelijk zijn, worden die vandaag niet herstart. Klaba adviseert klanten hun noodherstelplannen te activeren.

OVHcloud biedt wereldwijd tal van cloudhostingdiensten aan en is ook actief op de Nederlandse markt. Het bedrijf heeft tientallen datacenters verspreid over Europa, Noord-Amerika en Azië.

Update, 08:22: Volgens een Franse lokale nieuwswebsite waren er zo'n 100 brandweerlieden en 43 brandweerauto's aanwezig. Het datacenter dat volledig is verwoest, is vijf verdiepingen hoog en heeft een grondoppervlak van 500 vierkante meter. De site toont ook beelden van de bluswerkzaamheden.

Datacenters van OVHcloud
SBG3 en SBG4 staan nog niet op dit overzicht van OVHcloud

Door Julian Huijbregts

Nieuwsredacteur

10-03-2021 • 07:52

252

Submitter: RemyWD

Reacties (252)

252
244
128
24
0
91
Wijzig sortering
Wel een behoorlijke ravage.. Zie link.
Ziet er ook wel wat rommelig uit daar. Lijkt ook wel op werkzaamheden aan de koeling. Zie dak links waar het er op lijkt dat een deel van de koeling verwijderd en of in onderhoud is.
https://media.datacenterd...cloud_sdis_3.original.jpg
Vindt het er sowieso maar allemaal cheap uitzien daar
Inderdaad. Echt een bende. We mogen in Nederland dan weer blij zijn met onze DC's gok ik zo.
als ik die container stacks zie, met energie en materiaal density.... Geen enkele zinnige verzekeraar zou dat geaccepteerd hebben !
Laten we hiervan leren ! Gezien instabiliteit wereld zullen de risico's toenemen: zie de herhalende en recent microsoft hacks , intrusions door RU en CH etc
Ik heb mijn klanten geadviseerd om de ICT "robuustheid" direct te verbeteren: 1 centre en 1 cloud is geen cloud ! En: IT Security dient integraal gemonitored te worden.
Lijkt op de foto idd erg rommelig maar weten niet hoe eea er voor de brand uitzag. En containers worden heel vaak gebruikt voor generatoren en 'container based DC' model wordt ook door partijen als microsoft gebruikt. Dat op zichzelf (dc in containers) zegt niets over betrouwbaarheid of veiligheid.
Iets wat er super uitziet kan slecht zijn en iets wat rommelig lijkt kan juist prima kwaliteit zijn. ... we zullen PIR moeten afwachten voordat wij, als 'stuurlui op de wal' wat zinnigs kunnen concluderen
Geografische spreiding kan een oplossing zijn voor dergelijke grote incidenten, maar ik ben benieuwd of dat klanten zich bewust waren van het feit dat deze 4 datacenters effectief naast elkaar staan.
Nee want het is cloud dus maakt het voor het gross van de gebruikers niet uit omdat ze via marketing wordt verkocht "dat hun data altijd en overal beschikbaar is".
OVHcloud is de nieuwe naam van OVH. Je kunt daar ook bare metal afnemen.

Als jouw bare metal server in het betreffende dataventer draaide, en je hebt zelf geen backups gemaakt, dan heb je nu een enorm probleem.
Het probleem is veel groter dan alleen maar een backup. Je hebt ook niet zomaar een bare metal server ergens anders op het moment (o.a. schaarste). Maar het probleem is veel breder dan dat. Bijvoorbeeld je externe IP's zijn via BGP naar dat specifieke datacenter gestuurd. Als een cdir block dus als meerdere klanten die daar gebruik van maken allemaal een andere oplossing (fysiek DC) kiezen heb je daar serieuze uitdagingen.
Tevens zit je soms met licenties die hardware specifiek zijn.
Externe leased lijnen (ik neem aan dat de Meet-me-room ook uitgevallen is)

Al deze problemen zijn op te lossen maar als dit de core van je bedrijf is heb je niet veel tijd voordat de schade dusdanig groot is dat het toch geen zin meer heeft. HA en DR zijn complexe scenario's waar je goed over moet nadenken en waarbij bovenstaande uitdagingen maar een paar zijn in een lange lijst van functionals en non-functionals.
In ieder geval weer een bewijs dat je je kostbare data niet in een cloud moet opslaan
Je kan het prima in de cloud opslaan, alleen is het niet verstandig om het enkel in de cloud op te slaan.

Het is sowieso verstandig om van kostbare data op meerdere plekken een backup te hebben.
Juist in de cloud ... maar niet in hetzelfde datacenter.
Inderdaad. Op je zolderkamer is veel beter.
Ja, ik vraag me af sowieso in hoeverre OVH backups maakt van bijvoorbeeld de VPS'en.
Ze zeggen wel dat je altijd zelf een backup moet maken (en dat doen we uiteraard ook), maar ik heb altijd het idee dat ze dat vooral zeggen omdat ze niet willen dat je hen gaat bellen om bestanden terug te zetten en dergelijke. Dat snap ik heel goed, want dan heb je elke dag een paar duizend tickets met mensen die om allerlei bestanden vragen en daar niet voor betalen. Je kunt ook betaalde back-upopties bij hen nemen namelijk.

Maar ik heb toch wel het vermoeden dat ze wel een backup (images) maken/hebben voor het geval van zo'n brand, of zou dat ook niet?
OVH heeft geen backups in het standaard pakket en ze lijken me te goedkoop daarvoor. Je kan het wel bijkopen maar als dat vervolgens op dezelfde locatie staat dan schiet je daar niet veel mee op. Bij de duurdere aanbieders zijn automatische backups wel steeds vaker inbegrepen. Een aantal hier in Nederland maken elke 2-6 uur een live snapshot die naar meerdere regio's kunnen worden gedupliceerd.

Maar dan nog moet je ook zelf offsite backups maken. Het liefst bij een andere aanbieder, netwerk en regio. Als het bedrijf een fout heeft gemaakt of failliet gaat dan wil je niet zelf ook helemaal opnieuw moeten beginnen. Zo kan ik op dit moment niet in mijn OVH dashboard komen, laat staan bij mijn dev vps backups. Dus als die vps in SBG2 had gestaan dan had ik nu niet in een andere regio kunnen restoren en was de data vermoedelijk kwijt geweest.

Eigenlijk is OVH helemaal niet geschikt voor productie. De support is om te huilen als je al support krijgt, vaak worden tickets na 48u gewoon gesloten zonder reactie, de beveiliging is beperkt (geen firewall op IPv6), er wordt soms dubbel gefactureerd, soms maandenlang helemaal niets en dan ineens alles in een keer maar is het totaalbedrag te hoog. En dan nog dat chaotische controlpanel. Het voelt als een budgethoster die veel te snel is gegroeid en het eigenlijk niet aankan. Dat kan ook niet voor die lage tarieven. Deze brand is dan ook geen grote verrassing. Ik denk dat er intern heel wat bezuinigd wordt.
Tip: Als je wat zoekt vind je op de OVH support een chat. Altijd snel mee geholpen geweest. Ook telefonisch altijd onmiddelijk geholpen geweest. Tickets zijn inderdaad een ramp.

Backup die gratis is (maar wel zelf te beheren) is altijd op dezelfde locatie maar wel in een ander gebouw.
Zo heb ik servers in RBX7 draaien en de backup ervan draait in RBX3.. en sinds vandaag toch ook maar een instance in Gravelines :+

Qua facturatie nooit problemen gehad in de 15 jaar dat ik er klant ben.

[Reactie gewijzigd door Lord_Palethorn op 23 juli 2024 12:29]

Kostentechnisch verwacht ik niet dat ze in het geheim backup's maken.
privacy-gewijs ook niet
Om die reden als je backups maakt liefst naar een ander datacenter en dan ook nog eentje die er niet naast zit maar toch een heel stuk verder.
Mijn vps provider draait iedere avond een backup n aar andere locatie. Die download ik dan s'nachts naar mijn nas.
Zou mijn provider failliet gaan en je komt niet meer aan de backups heb je ze ook nog lokaal.
Da's leuk als dit om een paar gig gaat.. zodra je met een paar TB aan data zit is het niet evident, zelfs naar een extern datacenter duurt (te) lang dan..
Backup kun je natuurlijk 1x per week alles en de rest alleen gewijzigde bestanden doen.

Als jij TB aan data hebt neem ik aan dat je een aardig groot bedrijf bent en dat je dan sowieso je data niet op 1 locatie wil hebben staan. Zou dan al logischer zijn om dat op 2 locaties te hebben. Wat doe jij als groot bedrijf met TB aan data als je server uitvalt of het datacenter zoals nu in de fik gaat.

Uiteindelijk heeft alles een prijskaartje maar dagen offline zijn kan dan wel eens heel duur worden.
Denk nu al veel bedrijven die geen backup hebben of zoals jij zegt backup in hetzelfde datacenter. Moet je kijken wat dat kost nu alle data weg omdat het niet extern stond.
Uit ervaring met OVH's backup opslag die je bij elke dedicated machine krijgt, kan ik je vertellen dat het toch best snel gaat. Ik push elke nacht ca 2TB aan gecomprimeerde en versleutelde data naar de OVH backup opslag. Ik heb dan ook wel machines met dubbele 3gbit verbindingen.

Deze backup data staat daar puur voor snelle ultimate-disaster recovery naar klaarstaande (en eventueel extra uit te rollen) noodservers in een andere OVH locatie (maar toch mooi op mijn private netwerk daar) en heeft daarom niet een hoge retentie. Deze standaard backup opslag staat overigens netjes in een andere OVH locatie (Gravelines servers hebben backupruimte in Roubaix). Geen idee of dit ook zo was voor SBG want daar heb ik geen servers.

Ja, en uiteraard ga ik ervanuit dat ook deze backup opslag kan falen. Dus wordt alle backup data ook dagelijks naar twee andere offsite locaties gestuurd met lange retentie en regelmatig getest op volledigheid en bruikbaarheid. Ik weet alleen wel dan dat de restore iets langer zal duren, maar ook dat scheelt niet veel.

@Lord_Palethorn
Dank je voor de toevoeging! Ik heb het OVH gevraagd, maar logischerwijs richten ze nu alle aandacht op de echt getroffen klanten. Mijn backup staat ook in RBX3.

[Reactie gewijzigd door Strebor op 23 juli 2024 12:29]

Alle backup staat in Roubaix bij OVH. Ik heb servers in Roubaix-7 en de backup gaat naar Roubaix 3. Ik heb dan ook een extra backup naar Gravelines geactiveerd. Gaat allemaal behoorlijk snel idd. Ik heb een paar weken terug een test gedaan naar backblaze Amsterdam en dat was een ander verhaal. Backups staan dus op een andere locatie maar wel nog steeds met dezelfde provider. Voor mij wel “ok” maar niet perfect..
Helaas is het niet altijd zo goed geregeld, genoeg bedrijven/beleidsbepalers die dit onnodige kosten vinden.

Op de een of andere manier wordt IT nog altijd als support zien, terwijl het juist voor veel bedrijven core-business is (webshops, communicatie van/richting klant, magazijnbeheer, CRM, ERP, ..) en dus veel verder gaat dan enkel ondersteuning (in/buiten bedrijf).
Psies. Naast backups via Dropbox, heb ik op kantoor een kluisje met een handjevol externe harde schijven die ik roulerend gebruik. Heel mooi die cloud, maar brick-and-mortar (of in dit geval ijzerroest en gebakken zand) is ook niet verkeerd. En de kluis is aan de verwarming geketend.
Als jouw bare metal server in het betreffende dataventer draaide, en je hebt zelf geen backups gemaakt, dan heb je nu een enorm probleem.
Een tijd geleden gekeken of OVH voor mij interessant zou zijn; ze zijn/waren(?) over het algemeen goedkoper dan de rest, al heb ik uiteindelijk door de slechte (support/up-time) reviews dit bedrijf destijds niet gekozen.

Een nieuwe VPS opzetten is nog niet zo eenvoudig, zeker niet bij kleine(re) websites/shops. Deze hebben nu dus ook een groot probleem, denk dat hun (recente) data en setup mogelijk niet te recoveren is.

Overigens zijn er ook veel resellers van OVH, denk dus dat de impact groot is.
Een nieuwe VPS opspinnen is met de juiste tooling zeer weinig werk. Als je alles met het handje in elkaar beun is het inderdaad niet eenvoudig.
Kun je wat meer toelichten over de tooling? Bedoel je dan docker met bijbehorende compose files of?
Ansible, chef of puppet zijn populaire tools. Ik gebruik zelf vaak Ansible voor provisioning van nieuwe servers, maar ook updates van aspecten van bestaande servers en het is na de eerste investering zeer de moeite waard.
Bij een VPS denk ik dan eerder aan zaken als puppet/chef/ansible/saltstack.
Buiten de al genoemde opties, de meeste installaties komen neer op de juiste packages en configs, dat kun je evt. ook nog wel bereiken met een simpel bash script waarmee je ~50-99% van het werk al klaar hebt. Ik had ooit een dedicated server bij SyS (dochter/zusteronderneming van OVH) waarbij nogal wat stapjes nodig waren om de bridge routing op te zetten bij een nieuwe VM, en dat had ik ook volledig gescript in bash. Ik hoefde alleen een eerste script over te plakken in de console (volledig script was die console niet goed genoeg voor) die eerst een gehardcode tijdelijke link legde met een shared hosting die ik ergens anders had, daar het volledige script pakte, en dan alles automatisch configureerde op basis van een aantal parameters. Voor mensen die gewoon een VPS hebben voor een enkele website is dat meer dan genoeg.
Ja maar dan ben je ook wel een enorme pannekoek of was die data net belangrijk en valt het probleem dus wel meer. Niks daar tussenin.
Het bedrijf heeft klanten o.a. via Twitter geadviseerd om hun Disaster Recovery Plan in werking te stellen en er waren serieus mensen die vroegen hoe ze dat moesten doen dus ik ben er bang voor :/ :P
Dat is enkel het geval voor saas diensten en dan nog zal elke goede provider kunnen aantonen hoe ze redundantie verzeker van hun software.

Bij paas of iaas zal er altijd gesproken worden over redundantie, gezien het dan de keuze is van de klant.
Ja niet zo handig, wij draaien ons platform op Azure maar onze database maakt gebruik van geografische redundante backup opslag. Mocht er een bom op gegooid worden kunnen we hem alsnog restoren, maar zijn inderdaad dingen waar je wel rekening mee moet houden.
Alle serieuse cloudpartijen zeggen daarom ook: 1 cloud is geen cloud, en je SLA geld dan ook niet als je slechts in 1 fysieke region host, overigens is het meestal wel zo dat elke cloud region ook een aantal fysieke scheidingen heeft met eigen noodvoorzieningen en beschermingen.
Zie de kaart OHVcloud in het artikel hier boven. Ze zitten dus wel geografisch gespreid. Dat de 4 gebouwen/datacenters in eenzelfde stad dan bij elkaar liggen, lijkt mij echter niet onlogisch.
Ze liggen haast tegen elkaar aan zie ook Twitter video van het blussen

[Reactie gewijzigd door prakka op 23 juli 2024 12:29]

Dan interpreteer je de video verkeerd. Je ziet daar twee aan elkaar gebouwde torens met kleurige gevelpanelen, waarvan de linker in brand stond. Dat zijn echter niet SBG1 en SBG2, maar de twee torens van SBG1 (in Google Maps aangeduid als OVH Strasbourg). SBG2 staat tweehonderd meter noordelijker.
Google Maps zit daar helaas fout. Een andere bron (foto 5 is het duidelijkst) geeft aan dat SBG1 bestaat uit de containers op de voorgrond (ja, de containers), dat het compleet uitgebrande gebouw SBG2 is, en dat SBG3 daar vlak achter er tegen aan staat.

[Reactie gewijzigd door dcm360 op 23 juli 2024 12:29]

Dan interpreteer je de video verkeerd. Je ziet daar twee aan elkaar gebouwde torens met kleurige gevelpanelen, waarvan de linker in brand stond. Dat zijn echter niet SBG1 en SBG2, maar de twee torens van SBG1 (in Google Maps aangeduid als OVH Strasbourg). SBG2 staat tweehonderd meter noordelijker.
Dan let je niet helemaal op, 200 meter afstand is namelijk genoeg om wel te kunnen voorkomen dat een andere datacenter in brand raakt. En er is toch echt sprake van dat de brand die in SBG2 begon en SBG2 daarmee volledig in de as gelegd heeft, ook een deel van SBG1 (4 van de 12 rooms) beschadigd zijn geraakt door diezelfde brand. Als alles zover uit elkaar had gelegen, was er niet ook nog een onderzoek nodig geweest om de impact op SBG3 en SBG4 in kaart te brengen en was het koelen van SBG3 en SBG4 ook niet uit voorzorg nodig geweest.

Het staat dus wel wat dichter op elkaar dan die 200 meter.
Blijft toch de vraag waarom dit in het artikel staat:
De brand heeft ook impact op de nabijgelegen datacenters SBG1, SBG2 en SBG3.
Als het impact heeft staan ze schijnbaar toch niet ver genoeg uit elkaar.
Hier hebben we nog wat extra foto's.
https://twitter.com/xgarreau/status/1369559995491172354

SBG2 is echt compleet uitgebrand. Dat er schade is aan SBG1 kan ook zijn door kortsluiting op het hoogspanningsnet, waterschade, etc. Bizar.
Kun je toch ook amper een datacenter noemen dit. Paar op elkaar gestapelde zeecontainers. En het dan ook nog 'verkopen' als 3 datacenters, omdat er een metertje lucht tussen zit.

SBG1 is dan blijkbaar letterlijk niet meer dan 3 zeecontainers op elkaar. SBG2 en SBG3 lijkt heel wat, maar dat 'pand' is hol. Het zijn dus containers in een vierkantje gestapeld.
Kun je toch ook amper een datacenter noemen dit. Paar op elkaar gestapelde zeecontainers. En het dan ook nog 'verkopen' als 3 datacenters, omdat er een metertje lucht tussen zit.
Het is echt wel meer dan een paar zeecontainers hoor: https://baxtel.com/data-center/ovh-strasbourg-campus

Dit is trouwens de normale manier om dit aan te geven, het zijn gewoon losse gebouwen, vandaar ook SBG1, 2 & 3. Ze zijn ook totaal niet verlegen om dit gewoon aan te geven als je er naar zoekt.

Als de prefix nou totaal anders was kan ik het inzien dat het in de buurt van misleiding komt, maar daar is geen spraken van.

Als je 2 gebouwen hebt (ook al zijn deze naast elkaar) is het gebruikelijk om hier DC1 en DC2 van te maken. Soms gebeurt dit zelfs als er bijvoorbeeld een 2e vloer bijgebouwd word!

[Reactie gewijzigd door smiba op 23 juli 2024 12:29]

Als je 2 gebouwen hebt (ook al zijn deze naast elkaar) is het gebruikelijk om hier DC1 en DC2 van te maken. Soms gebeurt dit zelfs als er bijvoorbeeld een 2e vloer bijgebouwd word!
Als dat gebruikelijk is, lijkt mij dat een slecht gebruik. Zo niet misleiding naar je klanten toe. (Of 't nu bij dit bedrijf of een ander bedrijf zo is.)
Dus omdat het niet van (gewapend)beton is, is het plots geen datacenter? Volgens mij is er tot op heden nog nooit ergens iets gedefinieerd waaraan een datacenter precies moet voldoen qua bouw.
Volgens mij is er tot op heden nog nooit ergens iets gedefinieerd waaraan een datacenter precies moet voldoen qua bouw.
Er zijn vast wel ergens gedefinieerde best practices (zoals ISO) te vinden voor datacenters. Bij een snelle zoektocht op Google kom ik bijv. ISO-standaarden tegen inzake het 'green' zijn van een datacenter.
Er zijn vast wel ergens gedefinieerde best practices (zoals ISO) te vinden voor datacenters. Bij een snelle zoektocht op Google kom ik bijv. ISO-standaarden tegen inzake het 'green' zijn van een datacenter.
True, en als je jezelf aan de ISO-standaarden houdt zal er nooit vooruitgang komen. Was het een slimme zet van OVH om deze datacenter danig grootschalig in te zetten binnen enkele jaren? Ik weet het niet, vooral als ik terugkijk in het verleden (5 jaar) waarin het aantal incidenten enorm is geweest.

Maar zonder praktijk testen en ervaring kom je ook niet tot uitbreidingen van of het ontstaan van nieuwe ISO-certificeringen/standaarden etc.
Aan de bouw foto's te zien zijn SBG2 en 3 geen containers meer (SBG1 is idd letterlijk containers gekoppeld en gestapeld)
Volgens mij word het helemaal niet als 3 datacenters verkocht. Je kan bij het afnemen alleen kiezen voor de locatie Strasbourgh in het algemeen, in welke van de 3 fysieke gebouwen je daarna terecht komt heb je geen zeggen over.
Inderdaad erg bizar, ziet er erg eng uit op die foto's. :|

Je kunt wel alles als verloren beschouwen, vraag mij hardop af of SBG1 ook geheel vervangen moet worden. Zo te zien is OVH wel groot, maar één/wellicht meerdere datacenter vervangen, doe je niet snel tussendoor.
Sbg3 is maandag weer in de lucht
Sbg4 volgende week vrijdag
De site is blijkbaar ook nauwelijks afgeschermd door fatsoenlijk dubbel-hekwerk, gracht etc. De graffiti op de buitenmuur is gewoon te zien. Was er dan überhaupt wel bewaking? Ook te zien, de "uitbreiding" (of noodstroomvoorziening) die in losse containers naast het gebouw staat.
Ziet er niet erg professioneel uit.
Hoeft ook niet, als je er als klant gewoon vanuit gaat dat het goedkoop is en dat het soms fout gaat.
De site is blijkbaar ook nauwelijks afgeschermd door fatsoenlijk dubbel-hekwerk, gracht etc. De graffiti op de buitenmuur is gewoon te zien. Was er dan überhaupt wel bewaking?
De datacenters staan op een beveiligd eigen terrein met meer dan wat hekwerk.
De graffiti staat dus achter de muren, als je goed kijkt zie je het Ovh logo en ovh.com staan, is dus zelf gedaan.
In tegenstelling tot hun eerste datacenter in Roubaix wat in een oud pand is ondergebracht, is Straatsburg geheel nieuwbouw naar eigen ontwerp.
Hoe de beveiliging van hun datacenters eruit ziet: https://youtu.be/3QpvgQBstzQ

[Reactie gewijzigd door Madshark op 23 juli 2024 12:29]

leuke video vooral rond 1:35 een shot van een paar seconde van een brandblusser, tja dat heeft niet geholpen dus.
En het automatische sprinkler systeem. Mensen die daar 24/7 zijn. Niets wat ze ontgaat. Een hoop leuke praat in één filmpje, maar niks heeft dit kunnen voorkomen. Bijzonder.
Niets wat ze ontgaat.
Het is dan ook niet verboden om te liegen in reclame. Sterker nog... het wordt juist (in het algemeen) aangemoedigd.
Alleen daarom al heb ik een gloeiende hekel aan zo'n beetje alle vormen van reclame. (Niet zozeer specifiek de reclame in dat filmpje.)
Tussen liegen en dingen mooier maken dan ze zijn zit een verschil.
Nee, daar zit geen verschil tussen.
hilarische commentaar in dat filmpje:
So that means SBG2 wasn't a fire. It was server to cloud migration
Is dat niet een container die ervoor staat?
Als ik het filmpje bekijk lijkt het meer alsof er een verbouwing gaande was.
Die containers lijken me bouwketen.
Als je naar andere beelden kijkt zoals hier: https://www.lepoint.fr/fa...-03-2021-2417135_2627.php
of op twitter: https://twitter.com/olesovhcom/status/134260524446781441

Ga je zien dat het geen bouwkeet is, Ze hebben ervoor gekozen om hun gebouwen te bouwen met containers. (of toch de kantoorruimte naast het datacenter)
Die containers is letterlijk het 1e datacenter van die site.
Ziet er niet erg professioneel uit.
Hoeft ook niet, als je er als klant gewoon vanuit gaat dat het goedkoop is en dat het soms fout gaat.
Of als het redundant en intern veilig genoeg is ingericht, transparant richting de klant.

Hoe vaak is een tank een 'onbeschermd' datacentrum ingereden?
De graffiti in het filmpje spelt "ovh.com". Ik denk dat de firma die zelf heeft laten aanbrengen.
Of dat er professioneel uitziet is natuurlijk een andere vraag. Maar over smaken en kleuren valt niet te twisten.
Ik heb bij zoveel datacenters gezien dat de noodstroom buiten in zeecontainers zit. Er is vaak geen ruimte voor in het pand en het heeft wat voordelen om buiten containers met noodstroomvoorziening te hebben staan. Je kan ze een stuk makkelijker vervangen (zijn complete units) en modulair uitbreiden en de koeling / afvoer van rookgassen gaat een stuk eenvoudiger.

Dat is niet iets waar ik de professionaliteit van een datacenter aan zou afleiden. Zaken als hekken e.d. kan je niet zien op deze foto's en video's en dus geen oordeel over vormen. Ik ken deze datacenters niet verder, maar neem aan dat dit er echt wel is.
Anoniem: 1302638 @localhost10 maart 2021 08:19
Captain Hindsight to the rescue.
Ik vind het design van het datacenter nogal budget ogen imho :X
Het zal ongetwijfeld aan de voorschriften hebben voldaan (of niet gezien het feit dat het helemaal afgebrand is/lijkt), maar hier in zowel in NL als in FR heb heb robuuster ogende DC's gezien.
Het hele idee achter OVH was volgens mij ook zo goedkoop mogelijke datacenters neerzetten.
Als je bijvoorbeeld dit topic leest: [OVH] Goedkope dedicated servers, ervaringen?
Zie je dat ze volledig fysieke machines voor ong. 3 euro per maand aanboden.

Dus ja dan kan je verwachten dat ze op andere dingen gaan besparen om de kosten te drukken.
Helaas heeft het dan wel weer een dusdanig grote impact dat er hoogst waarschijnlijk geen fatsoenlijke blusinstallatie heeft zoals je verwacht bij een normaal datacenter.
Onzin. OVH is een competente club met technisch goede en een beetje eigenzinnige mensen. Ze hebben tegen de verdrukking in een mooi bedrijf opgebouwd. Verdrukking, omdat in Frankrijk eigenlijk alles wat met Internet te maken had moeilijk gemaakt werd door France Telecom en de rest van het Franse establishment. Octave Klaba is een immigrant die buiten de gevestigde orde viel, niet op de juiste scholen en universiteiten zat en die door hard werken iets moois gebouwd heeft. Octave snapt ook echt de engineering die zijn bedrijf doet. Hij staat bekend als eigenzinnig, maar dat moet wel in Frankrijk, anders kom je nergens.
Hij en Xavier Niel van Iliad zijn voorbeelden voor de hele Franse internet scene.
Sorry hoor, maar dat SBG1 bestaat letterlijk uit aan elkaar gekoppelde zeecontainers met dakbedekking erop, en SBG2 en SBG3 zijn vierkante holle geraamtes van ijzer met houten vloeren en een beetje dun blik er tegen aan (lijken zelfs geen sandwich isolatie panelen te zijn), de blusinstallaties zijn compleet met water.
De stroomvoorziening is voor deze zaken ook zo ingericht dat ze nu t 400kv deel moeten herbouwen en tot die tijd mogelijk de andere DC's op die site ook down zijn.

Dit zijn gewoonweg enorme budget keuzes die tot onder het bare minimum niveau gaan dat je wel degelijk over de competentie een opmerking mag maken (en dat die ook terecht is)
...houten vloeren...
Een paar belangrijke primaire regels voor data-centers:
-Zet backups altijd ver weg van de niet-backups. En maak ook backups van de backups. En ook die 2e backup uiteraard ver weg van de backup en de niet-backups houden.
-Gebruik zo weinig mogelijk brandbare materialen. Zeker bouwtechnisch. Alleen als het ècht niet anders kan, brandbare materialen gebruiken (iets wat ze bijv. ook in de vliegtuigindustrie nog steeds niet voormekaar hebben).
-Nodig elke x maanden de brandweer uit (betaal ze) en laat ze alles bekijken en beoordelen. Nodig elke keer een ander fire-department uit. En vooral: luister naar ze. Als ze dat hadden gedaan, hadden ze vast geen houten vloeren.
-Kijk ook goed naar andere mogelijke externe invloeden, zoals mogelijke overstroming, stormschade, etc. Huur specialisten in om je miljoenenbedrijf regelmatig te laten checken. Trouwens... met 'gezond boerenverstand' moet je al een heel eind kunnen komen.

Ja, de hostingkosten worden dan een fiks percentage hoger. Jammer dan. Alleen al vanwege die houten vloeren (als die constatering klopt) lijkt het mij niet onlogisch dat ze rechtszaken aan hun broek krijgen.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 12:29]

Met de houten vloeren klopt, dat zie je op meerdere foto's gewoon terug.

https://twitter.com/oleso...17311014511194112/photo/1
Hier zie je de bouw van SBG2, achter op de foto's zie je SBG1 (de zee containers) en voorop zie je het enige stukje beton, de connectie tussen SBG2 en SBG3.

https://twitter.com/olesovhcom/status/335448359525552128
ook SBG2 tijdens de bouw en daar zie je de houten vloeren zitten (later is er nog wel iets overheen gegaan overigens).

Of het echt strafbaar is dat weet ik niet.
An sich omdat er weinig personen verblijven denk ik niet dat er grote eisen zijn op gebied van branddoorslag etc en mag het vast wel.

Echter of het dan heel slim is om 3 relatief brandgevaarlijke (want als dit brand, dan gaat alles zie je nu ook) DC's zo kort op elkaar te zetten, en oa je basis 400KV infra zo er naast te zetten dat die verloren gaat? dat is misschien wat onhandiger.

Verder kan het low-budget bouwen een keuze zijn die prima te rechtvaardigen is als je op zulke schaal opereren kan, maar wel een keuze die lijkt mij beter bekend moet zijn bij je klanten en die moeten in hun design dan rekening houden met server plaatsing, locatie, geoscheiding etc etc.
Of het echt strafbaar is dat weet ik niet.
Waarschijnlijk niet; over het algemeen zal een gedupeerde door een rechter al snel gewezen worden op de 'eigen verantwoordelijkheden'. Van leugens in reclame (over zekerheid van de datacenters) zal een rechter al snel zeggen dat dat 'normaal gebruik' is in de reclamewereld, en dat je er vanuit moet gaan dat er wordt gelogen in de reclame.
Of het echt strafbaar is dat weet ik niet.
Waarschijnlijk dus niet (volgens de meeste rechters); maar als er veel bedrijven zware financiële schade hebben, lijkt mij de kans groot dat er rechtszaken volgen.
Okee, I'll bite. OVH is een eigenzinnige club. Waarom is het dan onmogelijk dat ze om prijstechnische (='disruptieve') redenen bepaalde keuzes hebben gemaakt bij de bouw van hun datacenters die de veiligheid wellicht niet ten goede zijn gekomen? Lijkt me juist in het straatje 'eigenzinnig' passen.
De stelling van @richardboer is dat omdat ze goedkoop zijn, het dus logisch is dat ze geen fatsoenlijke blusinstallatie hebben. Dit bestreed ik.

In je reactie stel je, dat ik wel degelijk ongelijk kan hebben en dat dit mogelijk volgt uit mijn eigen reactie. Hiervoor wijs je op mijn gebruik van het bijvoeglijk naamwoord 'eigenzinnig' en daar hang je je hele antwoord aan op. Dan vergeet je echter dat er meer in de reactie staat. Er stond voor eigenzinnig een ander bijvoeglijk naamwoord dat je vergeet; "competente". Competent betekent "bevoegd" en "bekwaam". Het is een bijvoeglijk naamwoord dat gebruikt wordt om aan te geven dat de persoon of organisatie, waar met het zelfstandig naamwoord 'club' naar verwezen wordt, goede keuzes en afwegingen maakt bij de uitvoering van hun werkzaamheden. In dit geval is OVH een 'competente club'. Daarmee wil ik zeggen dat ze bekwaam zijn. Bekwaam betekent onder andere dat ze de brandbeveiliging van hun datacenters op orde hebben. Een bekwame organisatie maakt redelijke afwegingen tussen kostenbesparingen en noodzakelijke investeringen voor brandveiligheid en andere veiligheidsvoorzieningen.

Dat betekent niet dat deze brand en haar gevolgen niet het gevolg kunnen zijn van een keuze van iemand binnen OVH of haar leveranciers. Dat kan wel degelijk het geval zijn. Fouten worden soms gemaakt, zowel bij ontwerp als bij beheer. Er is tot nu toe geen signaal dat wanneer OVH een keuze moet maken tussen veiligheid en het besparen van kosten, dat de beslissing dan vooral valt in de richting van (onverantwoorde) kostenbesparing.

Goedkoop, competent en eigenzinnig sluiten elkaar niet uit en zijn vaak het gevolg van elkaar.
Sorry, maar als een datacenter anno 2021 zo in de fik vliegt en daarnaast ook nog een naastgelegen gebouwen kan beschadigen ben je dus voor wat betreft brandveiligheid niet competetent. Er kan altijd brand uitbreken maar niet op deze schaal.
Als Equinix AM3 en AM4 in de fik vliegen zullen we je zeker vragen om je wijsheid met ons te delen.
Als die net zo in de fik vliegen als deze bij OVH moeten zich wat mensen daar gaan schamen. Daar heb je mijn "wijsheid" niet voor nodig.
... Dat kan wel degelijk het geval zijn. Fouten worden soms gemaakt, zowel bij ontwerp als bij beheer.
Bij elk bedrijf worden fouten gemaakt. En vaak dagelijks. Hoe groter het bedrijf, hoe meer fouten er dagelijks worden gemaakt. (Het hangt natuurlijk ook een beetje van je definities af; zoals de definitie van het woord 'fout'.)
Blijkbaar hebben ze toch iets met bouwen niet volgens de voorschriften gedaan. Ik snap niet wat er uberhaupt brandbaar is in een DC. Wij mogen geen karton of andere dingen mee naar binnen nemen en er zijn brandmelders en branddeuren, alle gaten dicht gesmeerd, kabels tussen ruimtes die brandveilig zijn etc... Hoe kan dit en het gebouw er naast zo'n brand veroorzaken?
Ik heb meerdere keren gehoord dat er blussingen zijn geweest in een DC en dat ook daar schade ontstaat maar ik heb het nog nooit zo gezien.
Kunnen verschillende redenen voor zijn.

Een paar jaar geleden is bij een grote Belgische telecom provider een hele room in de fik gevlogen doordat men een blussing had laten afgaan in een room door verkeerd onderhoud. Daardoor waren de blusflessen leeg. Even later, tijdens de lunch, was er in een andere room een echte brandmelding maar waren de flessen leeg. Je kan maar zoveel barrières hebben...

Onderzoek zal het uitwijzen, tot dan heeft roepen geen zin.
Overigens lijkt beton me even brandbaar als een ijzeren container ;)
Ja dat brand wel.... Ongelofelijk...
Printplaten en kabels branden heel lekker hoor.
zoo..dat schept een nieuwe dimensie aan deze OVH brand..
Het hele idee achter OVH was volgens mij ook zo goedkoop mogelijke datacenters neerzetten.
Als je bijvoorbeeld dit topic leest: [OVH] Goedkope dedicated servers, ervaringen? Zie je dat ze volledig fysieke machines voor ong. 3 euro per maand aanboden.
Die servers waren al meerdere malen over de kop gegaan qua prijs en daardoor kostte deze ook geen ruk meer, dataverkeer is voor OVH extreem goedkoop gezien ze hun eigen pijplijnen hebben. En qua elektriciteit is het ook niet veel boeiends aangezien ze enorm groot inkopen.

Dus die € 2,99 excl. BTW per maand was inderdaad een schijntje. Wat je daarnaast vaak ook zag gebeuren is dat van die € 2,99 gebruikers de wensen voor een betere server steeds verder toenamen waardoor ze uiteindelijk betere servers gingen bestellen. Niet voor niets is zelfs vandaag de dag bij Isgenoeg / Kimsufi, het merendeel van de servers in Europa gewoonweg niet beschikbaar en loopt het knetterhard.
Dus ja dan kan je verwachten dat ze op andere dingen gaan besparen om de kosten te drukken.
Helaas heeft het dan wel weer een dusdanig grote impact dat er hoogst waarschijnlijk geen fatsoenlijke blusinstallatie heeft zoals je verwacht bij een normaal datacenter.
Of de blusinstallatie liet het af weten, of wacht dacht je van te weinig capaciteit om de hele boel snel en voldoende van water te voorzien en uitbreiding te beperken?

Een slecht bedrijf? Totaal niet! Al bijna 20 jaar minstens één Dedicated Server bij hen maar zeker geen partij die zich onder doet van een partij in Nederland die voor het zelfde aanbod minstens het 3-voudige vraagt.
Ik kan niet voor Duitsland spreken, maar in Nederland zijn er duidelijke regels met betrekking tot brandveiligheid van diverse soorten gebouwen. Dat men goedkoop is staat dan ook los van de minimale eisen van de overheid, ik vermoed dat dit in Duitsland niet anders is. Sterker nog gezien mijn ervaring met Duitse normen in de Nederlandse bouw zou het me niet verbazen dat deze doorgaans hoger zijn.

Bij dergelijke projecten (ik heb ooit een tender gehad voor een data center) wordt er zelfs rekening gehouden met de hoeveelheid brandbare materieel per x m2. Zodra je daar overheen gaat moet deze worden gecompartimenteerd. Het interessante aan dit is dan ook dat dit dus los staat van wat de data center eigenaar wilt, deze eisen kunnen best wel eens haaks staan op wat practisch is in de uitvoer. Zo zie je bijvoorbeeld in grote warehouses brandscheidingen met aparte locaties voor deuren voor noodroutes. Wederom deze worden in samenspraak met de brandweer vastgesteld.

Uiteindelijk is dit dan ook koffiedik kijken wat precies is gebeurd. Misschien stond er tegen de richtlijnen in een grote hoeveelheid brandstof voor de nood generatoren, misschien waren nood uitgangen opengezet vanwege gemak. Wie weet, dit zal zeker door de verzekering verder worden uitgezocht.
Duitsland
Straatsburg ligt al een tijdje in Frankrijk

[Reactie gewijzigd door cracking cloud op 23 juli 2024 12:29]

Daar heb je gelijk in, maar dit complex ligt langs de Rijn, die daar de grens vormt tussen Frankrijk en Duitsland. Het scheelt dus letterlijk maar tweehonderd meter. Dat neemt niet weg dat alle normen en richtlijnen voor dit datacenter volledig Frans zullen zijn.
Al heeft het daarna nog periodes gekend dat anderen het daar niet helemaal mee eens waren :X
Ondanks duidelijke regels is er toch regelmatig brand. Er kan altijd vanalles misgaan...
Het hele idee achter OVH was elke cloud provider is volgens mij ook zo goedkoop mogelijke datacenters neerzetten.
Fixed that for you.
Bij aws en azure zoeken ze ook manier om zo snel en efficiënt mogelijk een datacenter te bouwen.
factcheck: onjuist Als je naar AMS1 en AMS2 Middenmeer centres - zelfs van buiten - kijkt, zie je dat ze het grondig hebben aangepakt. MSFT , T-Mobile , Goofle en AWS zitten daar niet voor dubbeltje op 1e rij..
Microsoft maakt gebruik van generaties van datacenters en met elke generatie is het de bedoeling dat de kosten naar beneden gaan en de installatie deployment snelheid omhoog.
ok, zal zo zijn. Wat betekent dit svp?
Maar de complexen in Middenmeer zijn allemaal laagbouw en stikken van de airco. Zijn niet over 1 nacht ijs gegaan daar..
Toevallig heb ik enkele maanden terug een virtuele rondleiding gekregen in het datacenter van Middenmeer en de keus voor laagbouw is een economische keuze. Laagbouw is goedkoper en minder complex. In de laatste generatie gebruiken ze ook geen traditionele airco, maar gewoon buitenlucht.

Het idee is simpel. Marketing en besparen van kosten.
Ja, de SBG locaties wel, maar OVH heeft vele locaties waar ze datacentra hebben, ook in andere Franse steden. Als jij dus zelf servers afneemt van hen en dan denkt dat omdat je verdeeld zit over SBG1 en SBG2 je de nodige spreiding hebt, dan heb je zelf je huiswerk niet gemaakt.
Ik vind dit ook wel een tikkeltje misleiding van OVH. SBG1 en SBG2 staan letterlijk tegen elkaar aan. Dat zal vrijwel iedereen zien als 1 locatie. Dat OVH het ziet als 2 aparte datacenters vind ik ver gezocht en riekt naar misleiding.. Groter voordoen dan je bent.. Veiligheid insinueren van gescheiden locaties terwijl die er niet is. Etc.
en SBG3 idem, die zit compleet gekoppeld met een tussenliggende gebouw.
Het is heel normaal om datacenter gebouwen apart te benoemen, ook al staan ze naast elkaar. De prefix SBG geeft al weg dat de gebouwen op hetzelfde terrein staan.
Een beetje architect doet altijd onderzoek naar de fysieke lokaties, en kijkt uiteraard ook naar de opzet van het terrein.
Als professioneel ICTer behoor je dat dus uit te zoeken, vind je dat allemaal maar verwarrend en misleidend, dan ben je gewoon incompetent in je werk.

En jah, dankzij lage prijzen, diensten op prepaid basis zonder contractsduur en een 24*7 oplevering van servers, is de drempel erg laag. Dit trekt een berg clueless hobby professionals aan, die nu allemaal lopen te huilen dat ze geen fatsoenlijk disaster recovery hebben, want hun enige backup (if any) stond 10 meter verderop |:(
Waarom is dat niet logische zo werken bijna alle grote clouds,

Als je kijkt naar AZURE is dat ook zo en moet je je bewust zijn van hoe de GEO regions werken wil je DC onafhankelijk kunnen opereren en schalen.

Als je machines in EU west en EU Noord hebt staan dan heb je spreiding zit je alleen in EU west heb je kans dat ze op de zelfde kaast draaien tenzij je availability groups hebt dan staan ze ook binnen het DC uit elkaar.

Probleem is alleen dat veel klanten niet uitgaan van een dergelijke situatie en daardoor de extra kosten niet willen nemen van de GEO verspreiding.

Het feit dat jij je drukt maakt over de locatie en setup van de hardware betekend al dat e niet bezig bent met cloud.

Als je het hebt over private hosting dan geld eigenlijk het zelfde je zou je niet druk moeten maken over de grote alleen over de afstand tussen je 2 servers. zolang dat maar +100KM is zit je save, Ik ken maar weinig steden in de wereld waar je boven de 100km nog in de zelfde stad zit.

[Reactie gewijzigd door Scriptkid op 23 juli 2024 12:29]

Probleem is alleen dat veel klanten niet uitgaan van een dergelijke situatie en daardoor de extra kosten niet willen nemen van de GEO verspreiding.
Heeft natuurlijk alles te maken met je bedrijf en hoe afhankelijk je bent van een cloud server.
Belangrijk is denk ik als je maar op 1 server zit dat je dagelijks een backup maakt naar een backup server die wel in een geografisch andere locatie zit of je download vanuit je lokale nas iedere dag de backup op de server.
Waarom is dat niet logische zo werken bijna alle grote clouds,
Ik heb geschreven niet onlogisch ;) Waarmee ik dus bedoel dat hij mij wel logisch lijkt dat de datacenters in eenzelfde stad naast elkaar liggen ;)
Het feit dat jij je drukt maakt over de locatie en setup van de hardware betekend al dat e niet bezig bent met cloud.
Ik maak mij er niet druk over, het was ook maar een reactie op iemand anders :P
Maar van redundante geografische spreiding hebben ze dan weer niet gehoord.
Het zal vast in de voorwaarde staan denk ik? Als je dit en dit kiest dan heb je dit en dit aan redudantie en dit zijn de risico’s.

Zoals Microsoft aangeeft in Azure dat je binnen een Azure Region meerdere datacenters hebt die geografisch in dat werelddeel verspreid zijn, maar je bent zelf verantwoordelijk om je Azure Resource in een availibility zone te zetten. Doe je dit niet dan zal je resource binnen 1 datacenter draaien en ben je enkel beschermd tegen het uitvallen van hardware.

Een availibility zone is een verzameling van een aantal fysiek gescheide en geografische verdeelde datacenters binnen een Azure Region.
Een availability zone is bij AWS alleen fysiek gescheiden. Met geen specificatie over hoe groot die isolatie is. Onze interpretatie is dat het verschillende gebouwen zijn, die best naast elkaar kunnen staan.

Dit is effectief het equivalent van een brand die vier AZs in een regio raakt...
Een availability zone is bij AWS alleen fysiek gescheiden. Met geen specificatie over hoe groot die isolatie is. Onze interpretatie is dat het verschillende gebouwen zijn, die best naast elkaar kunnen staan.
Het is idd niet exact gespecificeerd, maar dit zegt AWS erover:

If an application is partitioned across AZs, companies are better isolated and protected from issues such as power outages, lightning strikes, tornadoes, earthquakes, and more. AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other.

Kortom: volgens mij kunnen meerdere AZ's dus niet bestaan uit gebouwen naast elkaar. Een brand zoals deze bij OVH zou dus niet meerdere AZ's plat moeten leggen.
In praktijk misschien niet, we hebben met Hurricane Katrina gezien hoe 'goed' een ramp zich kan verspreiden en hoeveel schade het kan aanrichten.

Denk de enige manier is geo-spreiding, maar dat zal ook voor velen duur en wellicht overkill zijn.
Een availability zone is bij AWS alleen fysiek gescheiden. Met geen specificatie over hoe groot die isolatie is. Onze interpretatie is dat het verschillende gebouwen zijn, die best naast elkaar kunnen staan.
Dit statement klopt voor geen meter.
AZs are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other.
Bron: https://aws.amazon.com/ab...nfrastructure/regions_az/
Dus van many km tot max 100 km.
Dat is dan een recente toevoeging. Zal het ook doorgeven aan degene die de immersion days verzorgde :).
Dat is dan een recente toevoeging. Zal het ook doorgeven aan degene die de immersion days verzorgde :).
Ook dit klopt niet, dit is helemaal geen recente toevoeging. Dit zit al jaar en dag in de AWS certificering en staat ook al sinds jaar en dag zo op de website.

Herleidbaar stond het er al in april 2019:
http://web.archive.org/we...nfrastructure/regions_az/
Is mij verkeerd uitgelegd voor een SA tijdens een immersion day. Daar ontstond zelfs discussie over hoe kritisch je meaningful distance moest lezen.
Ja inderdaad, bij MS is het echt verdeeld over de gehele Azure Region. Een Azure Region is een verzameling van datacenters op een wereld deel. Per wereld deel hebben ze meerdere Regions, dus mocht je het niet vertrouwen binnen 1 region kan je ook nog zeggen ik pak er 2.
OVH is geografisch gezien redelijk verspreid. Feitelijk hebben ze in Strasbourg 1 datacenter, maar fysiek zijn het 4 losse gebouwen.
Dus niet: https://status.us.ovhcloud.com/

Firefighters were immediately on the scene but could not control the fire in SBG2.
The whole site has been isolated, which impacts all our services on SBG1, SBG2, SBG3 and SBG4.

Het is dus 1 site en stroom is uitgeschakeld naar 1 2 3 4.

De gebouwen staan wel uit elkaar maar schijnbaar toch niet ver genoeg en zitten ze allemaal op dezelfde hoofdstroomaansluiting.

[Reactie gewijzigd door bbob op 23 juli 2024 12:29]

De gebouwen staan wel uit elkaar maar schijnbaar toch niet ver genoeg en zitten ze allemaal op dezelfde hoofdstroomaansluiting.
Dit weten we denk ik niet, dit kan best komen uit een andere bron - al gok ik ook van niet.
Ze zitten volgens ovh zelf op 1 stroomkabel die men uitgeschakeld heeft. ovh is de bron
Als je op google maps kijkt zie ik alles op een soort schiereiland zitten.
50-100 meter ruimte is uiteindelijk niet veel, maar dat is een keuze.
Ook dat de hele site dus schijnbaar op 1 stroomkabel zit ook een keuze.
Begrijp het wel vanuit kosten is dichter bij elkaar goedkoper.
de kans dat dit gebeurt is klein maar nu het gebeurt is zie je de consequenties van een keuze.
Volgens een tweet moet het 400kv transformator deel opnieuw opgebouwd worden, dus die is ook niet heel redundant opgezet.
Lijkt me ook moeilijk op een schiereiland waar ze zitten. Tenzij er een stroomkabel vanuiit de andere kant uit het water komt. Idem voor alle internetverbindingen. Vraag met al of die ook in een ring zitten. Het kan op een schiereiland maar minder eenvoudig.
Dit soort situaties toont uiteindelijk de problemen aan hoe men het datacenter opgebouwd heeft. Als klant moet je je dan afvragen of dit de beste provider is. Aan de andere kant hoe had je dit kunnen weten ?
Kijk, op de schaal hoe OVH opereert kan t prima een valide keuze zijn om je systemen te repliceren over meerdere DC-Sites en zo uptime, availability etc te voorzien en per site gewoon de kosten enorm laag houden.

Ipv rackjes over meerdere DC''s schalen gewoon meerdere DC's in meerdere steden bouwen etc.
Maar dan moet je wel je replica en availability goed geregeld hebben.

Bare-Metal klanten zouden ook goed op de hoogte moeten zijn dat de systemen op low-cost locaties staan die een hoger dan normaal risico hebben (en dit in hun design opnemen)....
Wat je aangeeft is allemaal mogelijk maar heeft een prijskaartje. Het is aan de klant te bepalen wat hij wel of niet wil.

Ik heb ook een vps in de cloud draaien. openstack, data wordt 3x opgeslagen, bij hardware uitval op een andere node. Deze oplossing werkt goed als je alleen kijkt naar uitval van hardware.
Server down image op andere server.
1 storage server down blijven er 2 over.
Maar alles staat op 1 locatie.
Dat wil dus zeggen als er brand uitbreekt en hele DC down gaat heb ik een probleem.
Daarom iedere nacht een backup naar andere locatie.
Mijn NAS download ook die backup.
Dus als DC in vlammen opgaat moet ik de volgende dag andere server regelen, backup uploaden een klaar. Kan dus wel zijn dat ik 1/2 dag data verloren ben.
Stel mijn provider gaat failliet data geblokkeerd heb ik de data nog op mijn nas en kan snel op zoek naar andere aanbieder.

Zou ook dubbele vps op 2 locaties kunnen nemen waarbij veranderingen aan de ene meteen ook op de ander doorgevoerd worden. Zou 1 dc in vlammen op gaan neemt de nader het over.
Daar hangt natuurlijk een prijskaartje aan, in mijn geval kijkende naar omzet is de vraag of die keuze de meerprijs op jaarbasis waard is.

Probleem is echter dat het bij veel bedrijven stop met alleen website en het met backups al fout gaat.
Je zal dus goed moeten kijken naar jou situatie en wat er voor jou zinvol is.
Backupplan is sowieso standaard en een beetje hoster c.q aanbieder van diensten moet dat standaard aanbieden en implementeren.
"Wat je aangeeft is allemaal mogelijk maar heeft een prijskaartje. Het is aan de klant te bepalen wat hij wel of niet wil."

Dat is toch ook wat ik zeg ;-)
De low budget manier kan prima werken als bedrijf zijnde, alleen is de vraag of de eindklanten hier goed van op de hoogte waren.
Als ik moet gokken zullen veel eindklanten hier niet van op de hoogte zijn en of geen backups hebben of backup in hetzelfde datacentrum.
Grote kans dat heel wat resellers nu wat moeten gaan uitleggen.
Meestal weet je dat wel, maar data replication is doorgaans niet gratis en daar durven bedrijven wel eens op te besparen.
factcheck: Data Replicatie is tegenwoordig zeer goedkoop. De HDD kosten per Tb zijn tegenwoordig centen, dus waar praten we over?
Data replication is doorgaans je storage kost maal 2 en afhankelijk van de provider komt daar ook nog netwerk kosten bij.

Dat is zeker niet duur, maar dat hangt af van het volume en het soort van data. Het is uiteindelijk het bedrijf dat de keuze moet maken hoe belangrijk de data is.
Daarom kan je bijv. In Azure wordt onderscheid gemaakt tussen regions en availability zones. En kan je aangeven of je het redundant in de zelfde regio (zone) wilt opslaan of in een secundaire regio.

Volgens Microsoft is je secundaire regio minstens 100km verwijderd van je primaire.

Daar zit uiteraard wel een prijskaartje aan

[Reactie gewijzigd door GrooV op 23 juli 2024 12:29]

Bij geografische spreiding denk ik echt aan een geografisch gezien andere locatie. Gebouwen die naast elkaar staan noem ik eerder local redundant. Hoe dan ook kan je als klant vaak wel een keuze maken tussen de soorten replicaties en doe je dat ook bewust (hoop ik)
Dit idd, ik heb bij een bedrijf gewerkt waar wij 3 DC's hadden, alle drie op andere stroomnetten en isp's en een glaslijn tussen de drie locaties. In 6 jaar tijd is er 51 seconden downtime geweest en dat was gepland.

Ik zou zoiets (misschien minder extreem) toch wel verwachten bij een hosting provider met meerdere locaties. Wat ik mij vooral afvraag, waarom is dit niet het geval? Is dit alleen omdat de oplossing te duur is?
SBG1 t/m 5 zijn vooral gewoon uitbreidingen van één en het zelfde datacentre.

SBG => Strassbourg.
Het is één campus met meerdere 'gebouwen', maar het geheel kan je ook gewoon zien als één datacentre, met verschillende 'generaties' naast elkaar

[img]
https://cdn.baxtel.com/da...-Campus-in-Strasbourg.jpg
[/img]

Geografische scheiding is er doordat er alleen al in Frankrijk drie verschillende 'sites' zijn: Parijs en Roubaix.
Dat lijkt inderdaad meer op gestage uitbreiding van één locatie. In Roubaix nummeren ze kennelijk al tot 7 door, terwijl in Parijs de codes voor alle drie compleet anders zijn. Zouden dat dan wel echt losse datacenters zijn?

Op de foto's op die gelinkte nieuwssite zie je dat de helft van een gebouw eraan is. De andere zijde, met ongetwijfeld ook flinke schade, zal dan wel SBG1 zijn. Kun je naar mijn smaak niet met goed fatsoen een los datacenter noemen.

In de details elders spreken ze ook over één 'netwerk room' waar kennelijk 1t/m4 van afhankelijk zijn en waardoor ook 3+4 offline zijn. Tja.. dat is wel creatief tot 32 datacenters tellen dan..
Ja, het zijn er 4, maar ze zijn allen SBG. Als je deployt met het oog op failover/redundancy dan zou je die machines in RBX/GRA zetten.
Ik niet in ieder geval. Ik had toch wel gedacht dat ze iets verder uit elkaar stonden (als in op zijn minst een metertje of 50 of meer). Alleen daarmee voorkom je al voor een groot deel mee dat de anderen ook down gaan (door schade dan wel toegankelijkheid etc).
OVH heeft wereldwijd 25 datacenters
of dat klanten zich bewust waren van het feit dat deze 4 datacenters effectief naast elkaar staan
Je kiest gewoon een locatie als Strasbourg of Roubaix, dát is je geografische redundancy. Als iets al SBG1 en SBG2 genoemd wordt, kun je er min of meer vanuit gaan dat dat gewoon allemaal op 1 "campus" staat. Iets in dezelfde plaats is sowieso niet geografisch onafhankelijk te noemen, dus waarom je vindt dat klanten er bewust van hadden moeten zijn volg ik niet. Denk dat het de meesten dus niet eens boeit dat het er 4 waren, wat hen betreft is het gewoon 1 datacentre.
Wat ik me afvraag, aangezien de diensten van OVH vrij lage prijzen hebben, dit gevolg is hiervan? Had dit ook kunnen gebeuren bij een ander datacenter? Uiteraard kan het nooit 100% voorkomen worden, maar aangezien het OVH treft vraag ik me dit toch wel af.
OVH is vooral goedkoop vanwege massa bulk, ze kopen ontzettend veel servers in, alles gaat zoveel mogelijk geautomatiseerd, en zodoende verkopen ze heel veel. Het is de grootste serverhost van Europa en de nr. 3 in de wereld gebaseerd op het aantal servers.
Je kunt letterlijk midden in de nacht een high-end dedicated server bestellen en 10 minuten later staat hij voor je klaar. 30 minuten langer met een custom storage configuratie (er moet dan fysiek even een mannetje/vrouwtje wat HDD's/SSD's in je server schuiven)

Wat de oorzaak is van de brand komt vanzelf een keer naar buiten, maar een oorzaak vanwege een kosten besparing lijkt me stug. Als je hun datacenter ontwikkelingen een beetje volgt zie je dat ze redelijk innovatief te werk gaan en de boel goed op orde hebben.
Het 1e gebouw is opgebouwd uit zeecontainers die gekoppeld zijn met een dakbedekking erop.
het afgefikte gebouw (wat tegen SBG1 staat) is opgebouwd uit een ijzeren frame, houten vloeren en muren van dun blik, en SBG3 staat er tegenaan gebouwd aan de andere kant in een zelfde opstelling....
De blusinstallatie lijkt een kleine waterblus installatie geweest te zijn.

Deze brand en vooral de escalatie ervan is 100% te wijten aan de ontwerp en bouwkeuze van het gebouw, en aan de slechte compartimentering tussen SBG-1 en SBG-2, allemaal keuzes die gewoonweg budget keuzes zijn.
De oorzaak lijkt me niet aan de lage prijs te liggen, soms heb je gewoon pech. Het beperken van de gevolgen daarentegen..

Mijn idee zou zijn overal warmte camera's op te hangen en bij iedere temperatuur boven de 200 graden (neem aan dat de max temp van onderdelen nooit boven de 100 graden komt), automatisch de hele afdeling te vullen met CO2 of stikstof zodat alles direct dooft/gesmoord wordt en de schade beperkt blijft. Veel mensen zullen er toch niet rondlopen en een nooduitgang zou je bij een oppervlak van 500 vierkante meter toch binnen 30 seconden moeten kunnen bereiken zodat je niet stikt.
Het is te vroeg om over pech te spreken. Brand kan door meerdere oorzaken ontstaan, inclusief buiten een gebouw door opzet. Dan kan je nu wel gaan denken over mogelijke oplossingen maar dat heeft zonder oorzaak en bestaande preventie te kennen weinig zin. Laat ze dus eerst maar achterhalen wat de oorzaak is.
Ik spreek niet over de oorzaak of dit nu pech, opzet of iets anders was. Ik zeg enkel dat gezien het feit dat een heel data center is afgebrand, een tweede schade heeft en nog twee andere ook offline zijn, we kunnen concluderen dat hun preventie/bestrijdingsplan gefaald heeft.

De enige aanname die ik doe is dat daar blijkbaar op kosten bespaard is, zeker gezien het hier blijkbaar een low-budget aanbieder is. Als je genoeg bereid bent te betalen kunnen je bijna alle risico's tot bijna 0 terugbrengen (jaja,dat is theorie en uiteindelijk praktisch niet betaalbaar, maar waar ligt de grens)
Ik lees in je eerste allinea toch echt iets anders door je gekozen combinatie van onderwerp en woorden. Maar bedankt voor het uitleggen wat je wel zou bedoelen.
Ze hebben ook een hele grote groep resellers, veel hosting bedrijven hebben er wel een of meerdere servers staan.
Wat de oorzaak is van de brand komt vanzelf een keer naar buiten, maar een oorzaak vanwege een kosten besparing lijkt me stug.
Natuurlijk is het óók een kwestie van besparing. Houten vloeren in een serverpark... Tsss. Prima methode om een zeer snelle verspreiding van een beginnende brand te stimuleren.
Twijfelachtig. Een UPS - zeker met de capaciteit van een datacenter - blus je niet zomaar. Als je EV auto in de hens vliegt zal de brandweer die laten uitbranden in een container, omdat er niet tegenin te blussen is. Ik wil overigens niet impliceren dat dit is wat er met OVH gebeurde, de oorzaak is op dit moment nog niet bekend.

Ik ben zelf nauwelijks bekend met OVH. Ik weet wel dat ze een "budget" IaaS provider zijn. Met de prijzen die ze hanteren lijkt het mij dat ze wel ergens concessies op doen. Een ruwe gok na het zien van het filmpje waarin de brandweer aan het blussen is, ben ik geneigd aan te nemen dat de fysieke bouw niet evenredig is aan die van een high-end datacenter.

Het maken van offsite backups, zelf of bij een andere partij is best-practice. In een mission-critical omgeving zou ik persoonlijk ook een multi-DC setup willen realiseren, geografisch gescheden (zeker niet in dezelfde stad) en het liefst ook nog bij datacenters van verschillende partijen, met verschillende netwerkleveranciers.

Enfin, ik denk dat het neerkomt dat je niet kunt verwachten om voor een dubbeltje op de eerste rang te zitten :)
UPS in datacenters zijn in de overgrote gevallen toch wel gebasseerd op loodzuurbatterijen, deze hebben een gans ander brand profiel dan lithium batterijen die in een auto zitten (deze ontbranden vanzelf waneer het lithium warmer dan 150-270 graden krijgt of blootgesteld wordt aan zuurstof)

Loodzuurbatterijen branden doorgans niet, ze kunnen wel exploderen.

Vandaar dus dat de brandweer een auto gewoon laat uitbranden, er valt ook weinig anders aan te doen, eens de cel beschadigd gaat die telkens terug ontvlammen als er zuurstof bijkomt en door de thermal runaway valt bijna onmogelijk te voorkomen dat naburige cellen ook uitzetten en barsten en in contact komen met zuurstof.
Dit lijkt mij een gans ander verhaal in een datacenter.

[Reactie gewijzigd door Keneo op 23 juli 2024 12:29]

De accu's kun je in een aparte ruimte onderbrengen, de rest van de ruimtes zodra er een te hoge temperatuur is overspoelen met CO2 of N2.

Afgezien dat zonder zuurstof niets kan branden, zullen die CO2/N2 ook nog eens vloeibaar opgeslagen worden wat een koelende werking heeft als het overgaat naar gasvorm. (al kan een halve liter water al meer warmte opnemen dan een kubieke meter gas)
Je mist alleen dat bij kortsluiting een batterij nog steeds veel hitte kan creëren, zelfs als er CO2 aanwezig is. CO2 voorkomt alleen dat er brand uitbreekt, als je pech hebt is de schade echter nog steeds groot genoeg om het datacenter tenminste wel tijdelijk uit te schakelen

Mocht het lithium zijn kan de reactie vrijwel tot een halt geroepen worden door de ruimte vrij te maken van zuurstof... maar gaat gewoon doodleuk door zodra er weer zuurstof aanwezig is. (lithium zuurstof reactie). Dat is puur alleen als er een zuurstof reactie optreed trouwens, kortsluiting is het zelfde verhaal voor lithium en is nog lastiger. (Zelfs als alle elektrische energie er uit is, treed er de bovengenoemde reactie op)

[Reactie gewijzigd door smiba op 23 juli 2024 12:29]

Voor de duidelijkheid, ik heb een chemische en brandweer achtergrond, en heb ook wel basiskennis van elektrotechniek.

Laten we niet vergeten dat we het hier over een brand hebben, daar is hitte/ontstekingstemperatuur voor nodig en zuurstof. Zonder zuurstof is het gewoon wachten tot het is afgekoeld, of dat nu een minuut of een maand duurt. En ja daarbij zal er schade zijn, maar ik zeg toch ook nergens dat het datacentrum niet tijdelijk buiten werking zal zijn? Alleen dat het niet volledig hoeft af te branden (en aanliggende panden daarbij ook beschadigd/buiten gebruik stelt)
Ik weet wel dat bepaalde brands UPS systemen met Lithium batterijen uitvoeren. Het zou mij ook dan niks verbazen dat .........
Hoe denk je dat ze de capaciteit om duizenden servers minutenlang van stroom te kunnen voorzien opslaan?

(hint: antwoord in dit plaatje)
vliegwiel of een kleine accu... dat hoeft geen minuten te zijn.. net voldoende om de agregaat aan te krijgen
https://datacenterworks.n...-van-vliegwieltechnologie
Dit is incorrect, de oplossing van HITEC (oa) hier kan binnen 10 seconde actief zijn op volle kracht. Er hoeft alleen voor een korte periode een overbrugging te zijn, dit kan in dat geval met een vliegwiel

Een oud voorbeeld dat ik even snel vond: https://youtu.be/jZjgx4BADf8?t=176
Ik weet alleen niet waarom ik gedown-mod word? pietehrhi had het hier over ik citeer "vliegwiel of een kleine accu". Met een kleine accu slinger je niet eens diesel mee aan!

Ik had het ook niet over Dynamische (rotary's) UPSen. Alleen over de statische oplossing. Ik ben heel bewust van hoe een Hitec/Eurodiesel etc. werkt. Alleen is dit niet altijd de oplossing. Anders hadden de meeste datacenters wel voor een Hitec gekozen.
En alles bij elkaar noemen ze een No-break system.
Jij bent nooit in een datacenter geweest he? In het DC waar wij staan, en dat is maar een fractie van de hoeveelheid machines in het hier afgebrandde DC, staan twee aggregaten van elk 1750 KWh, dus 1.75MWh. Voorheen hadden ze 2x 900KWh en dat was niet meer afdoende, uitgaande van N+1. Dat soort vermogens los je niet op met een 'vliegwiel'. Bovendien duurt het afhankelijk van de modellen soms wel een minuut voordat een aggregaat vol vermogen kan leveren.
Toch ben ik benieuwd of het pand vroeger wel als datacenter gebouwd is? Of is het ooit omgebouwd daarvoor?
Ja, SBG1 is/was (4 van 12 rooms zijn geroosterd) een containerdatacenter. Dat was goedkoop en daarmee kon de vraag getest worden.
Deze vraag blijk overweldigend groot, dus heeft OVH SBG2 ontworpen en gebouwd. De vraag bleek groot genoeg om zelfs nog SBG3 te bouwen. Echter was al eerder meer capaciteit nodig, dus in containerdatacenter SBG4 geplaatst naast SBG3 om aan de vraag te voldoen.

SBG1 en SBG4 zouden na een grote stroomstoring overigens uit dienst genomen worden, maar of dat daadwerkelijk ooit gedaan is lijkt mij niet.

[Reactie gewijzigd door Groentjuh op 23 juli 2024 12:29]

Oh damn, dit gaat wel een voorbeeld zijn waarom je backups op een volledig andere site moet hebben.
Oh damn, dit gaat wel een voorbeeld zijn waarom je backups op een volledig andere site moet hebben.
OVHcloud heeft backups in andere datacenters hangen. Voor zover er nu bekend is, is er niks kwijt of onbereikbaar. Dus OVH heeft een prima backup oplossing dat functioneert.
toch las ik het volgende op Twitter:

We have a major incident on SBG2. The fire declared in the building. Firefighters were immediately on the scene but could not control the fire in SBG2. The whole site has been isolated which impacts all services in SGB1-4. We recommend to activate your Disaster Recovery Plan.

We recommend to activate your Disaster Recovery Plan impliceert niet dat er iets onbereikbaar zou zijn... en dat de provider het voor je gaat oplossen (?)
Ik lees toch echt "*your* Disaster Recovery Plan" wat volgens mij impliceert 'veel succes ermee'
ik lees het als "je bent nu van onze back-up afhankelijk dus als daar iets mee mis gaat is er geen extra backup meer bij ons - regel voor de zekerheid je back-up van je back-up"
mijn monitoring zegt anders dat de website al 8 uur uit de lucht is en ik kan geen backup herstellen omdat de interface van OVH overbelast is (en logisch natuurlijk).
Ik heb ook een server, gelukkig in Roubaix, maar daar zit zeker geen backup-mogelijkheid bij.
Dus ik snap wel dat ze benadrukken dat de getroffen klanten zelf moeten overstappen op hun disaster-plan.

Op Twitter lees ik ook een aantal berichten van getroffenen, maar de meesten van hen kunnen gelukkig snel uitwijken. Er zijn dus een hoop verstandige mensen die niet enkel op één server vertrouwen. maar goed, wel vervelend voor diegenen die dat wel doen.....
Ik moet je 100% gelijk geven maar ik denk dat heel wat klanten vertrouwen op de backups van hun provider.

Als het datacenter dan plots de fik in gaat dan vrees ik het ergste voor je backups, die zullen hoogstwaarschijnlijk op dezelfde fysieke locatie bijgehouden worden en zullen door de brand verloren zijn.
Ik mag toch hopen dat klanten met een serieuze business de 3-2-1 backup methode in het achterhoofd houden. Ongeacht of de IT-omgeving volledig zelf wordt beheerd of uit handen wordt gegeven.
Ze hebben meerdere locaties, hopelijk worden (meerdere) backups gemaakt naar bijvoorbeeld een ander land in de EU of daarbuiten.
Heftig! Ik ben benieuwd hoe dit komt. Normaliter zijn datacenters gebouwd met automatische blussing en ook materialen die niet willen branden. Vraag mij dan ook af hoe dit toch kan gebeuren.

Ook hoor je maar heel weinig dat datacenters in brand vliegen.
Ja zou inderdaad verwachten dat ze een Zuurstofreductie systeem hebben welke geactiveerd wordt als er brand is.
Afhankelijk van de oorzaak en het type brand kan dat onvoldoende zijn. Er bestaat geen oplossing die 100% goed werkt.
Als het bijvoorbeeld een groep Li-On cellen zijn: dat is zelfvoorzienend. Dat kan volgens mij zelfs branden in de ruimte...
Meest kwetsbare lijkt mij de UPS opstelling. Hoge vermogens, accu's etc. Dat kan wel een lastig te blussen zijn. Zeker omdat de zalen vaak een automatisch bussysteem hebben. Maar is pure speculatie, hopelijk komt OVH met meer info naar buiten.
Dat dus: Ik ga er een beetje van uit dat de accu's op basis van Li-Ion cellen zijn. Als die eenmaal beginnen dan is er geen stoppen aan.
Weer een sein dat vertrouwen op 'de cloud' toch de noodzaak heeft om het risico te spreiden. Dus fallback- en/of backup servers in een DC in een andere stad is een must.
Dit lijkt ook niet op een normaal datacentrum zoals we die in Nederland vaak zien. Het is een container datacentrum. Dat zijn volgens mij allemaal losse modules die samen een datacentrum vormen. Misschien zit daar meer brandbaar materiaal in en hebben die minder goede blusinstallaties?
Anoniem: 1301524 10 maart 2021 09:04
Als ik naar Digitalocean kijk, staat daar de optie “enable backups” voor je VPS. Zal gelijkaardig zijn bij OVH of andere VPS providers. Is dit dan in hetzelfde datacentrum? Want dan is het enkel bescherming tegen eigen fouten (db crash of per ongeluk drop table).

Ik vond van mezelf “geweldig” dat ik goedkoop een test infra had opgezet die schaalbaar is en snel, maar moest dit bij mij gebeurd zijn en het was echt productie stond ik nu te huilen. Dus dit zal de reden zijn waarom mijn “geweldige” infra toch niet zo geweldig en goedkoop kan zijn.
https://www.digitalocean.com/docs/images/backups/
Backups are taken once per week, and each backup is retained for four weeks. We store backups in the same datacenter as the corresponding Droplet.
Ok, goed om te weten. Dat is dus niet echt handig en ook niet echt een backup wat mij betreft. Heb wel wat serieuze sites enzo draaien bij Vultr, zo toch eens kijken hoe het daar met backups zit :*)

Edit:
UItgezocht: "Backups are stored in the same datacenter as the original instance on a separate, fault-tolerant storage system."
Mooi, gaan we dat maar even aanpassen.

[Reactie gewijzigd door MrMarcie op 23 juli 2024 12:29]

Zo zie je maar weer. Lijkt heel wat, is maar 1/3 opgelost.
Want iedereen (?) weet: 1 backup = 1/3 backup.
Ze hebben niet alleen VPSen, ze bieden vooral veel dedicated servers/bare metals aan. Veelal moet je dan voor backups betalen
Voor dedicated servers bij hun krijg je in de meeste, zo niet alle gevallen backup ruimte er bij maar moet je bijbetalen voor meer ruimte.

Ik kan zo niet vinden of die backups gerepliceerd worden naar andere locaties maar als ik dit zo lees had het niet uitgemaakt of het naar SBG-1 en SBG-4 gerepliceerd werd, die staan veel te dicht bij elkaar.

Echt belangrijke data kun je maar beter zelf repliceren. Kost nog steeds een berg maar zonder backup zitten kost meer.
Dat is waar maar dan moet je wel zelf je backups inregelen. En SBG1 en 2 zijn allebei beschadigt en 3 en 4 liggen plat dus een backup zou inderdaad alleen nuttig zijn geweest als die op een complete andere datacenter locatie stond
Wel even speculeren, maar in LIM-1 werd kort na de brand heel veel C13-C14 power cables vervangen vanwege problemen met de isolatie. Wel zuur dat een fout in de kabel zo'n heel datacenter heeft kunnen verwoesten.

http://travaux.ovh.net/?do=details&id=49017&
Lijkt mij erg sterk dat ze zo snel denken dat dit de oorzaak is en dat je direct zoveel voorraad stroomkabels in huis hebt van een ander type.
Dat is gewoon ongelukkige timing. Op deze pagina staat dat dat al gepland was op 2021-02-12. Het is vannacht toevallig uitgevoerd en afgerond.

[Reactie gewijzigd door Groentjuh op 23 juli 2024 12:29]

Je hebt gelijk, niet goed opgelet :-)
Hier zijn foto's hoe een OVH DC gebouwd wordt. Hout en golfplaten.

https://twitter.com/Medec.../1369618937063817219?s=20
Ja dan snap ik het wel zeker samen met de luchtverversing is het dan wel heel snel pret daar helpt die blussing niet tegen. Zeker niet vanwege het feit dat detectie met op de meeste conventionele manieren heel slecht werkt vanwege de hoge luchtsnelheden.
Hier heb je aspiratie detectie voor genaamd ASD of HSSD.
Klopt maar zelfs dan moet goed kijken waar je deze ophangt, wij hebben indertijd getest op de computerzaal hiermee. Was erg verrassend, maar aspiratie is eigenlijk mits goed gepositioneerd de enige goede methode. Maar bedenk wel dat het brandrisico in een goed ingerichte computerzaal minimaal is, zeker als er periodiek een thermische inspectie plaatsvind. Er is namelijk niet zo veel wat kan branden, en een electriciteits brand kan je alleen echt blussen door af te schakelen.
Dat is in Roubaix , niet in straatsburg
Ben benieuwd naar de oorzaak.

Moet overigens zeggen dat ik een VPS bij OVH heb draaien, die zonder onderbreking nog steeds in de lucht is. Dus ze hebben in ieder geval ook wat dingen goed geregeld (A)
Dat zal wel zijn omdat je VPS niet in de SBG datacenters draait... Ik heb er een paar, diegene die in RBX/GRA draaien werken inderdaad nog perfect, de VPS in SBG1 is niet te bereiken.

Op dit item kan niet meer gereageerd worden.