464.000 domeinen zijn offline door brand OVHcloud-datacenter

Door de brand bij het Franse OVHcloud zijn 3,5 miljoen sites offline. Die zijn verspreid over in totaal 464.000 domeinen. De websites die offline zijn variëren van nieuwssites tot aan websites van overheden. Een deel van de sites komt inmiddels weer online.

Het ziet er niet naar uit dat de data uit het afgebrande datacenter van OVHcloud in Straatsburg hersteld kan worden. De provider zal daarom gebruik moeten maken van back-ups elders. Een deel van de websites is inmiddels weer online.

Veel getroffen sites zijn van het Franse top-level-domein .fr. Volgens een schatting van analist Netcraft betreft het 59.600 domeinen, 1,9 procent van alle .fr-domeinen volgens het bureau. Daarnaast zijn er ook 24.000 domeinen van .uk offline door de brand. Het merendeel van de sites dat offline raakte door de brand waren .com-domeinen. Het gaat bij die laatste categorie om 880.000 pagina's over 180.000 domeinen.

OVHcloud heeft op zijn website een update geplaatst over het incident. Het bedrijf verwacht dat het een aantal weken gaat duren voordat alle diensten weer in de lucht zijn.

De brand ontstond woensdagochtend. Bij de brand werd een datacenter van vijf verdiepingen met een grondoppervlak van 500 vierkante meter verwoest. Het is nog niet duidelijk wat de brand heeft veroorzaakt. Niemand raakte gewond bij de brand.

Reacties (114)

[Douweegbertje]

Wel een grappige titel. Dat die websites offline zijn heeft niets met een brand in een datacenter te maken. Dat is gebeurd door keuzes vanuit bedrijven, architectuur, management en overige facetten die daar invloed & impact op hebben. Een datacenter heeft geen invloed op het draaien van een website, die verantwoording heeft elke partij alsnog zelf.

Nu kan je mij weer een zeikerd vinden maar over het algemeen zie ik heel veel reacties op Twitter en overige mediums waarbij 100% verantwoording bij OVH wordt neergelegd. Nieuws outlets gaan hier in zekere mate in mee.

Want waarom is de titel niet: 464000 domeinen (?... wat dat dan ook is) hebben geen waarde gehecht aan redundantie in 2021 en hebben dermate trage/slechte processen dat ze na 24 uur nog niet online zijn.

[mcDavid]

Volgens mij heeft dit weinig met "zeiken" te maken, meer met een compleet losstaan van de realiteit. Er is een groot verschil tussen redundantie in je hardware, en een compleet datacenter kunnen laten afbranden zonder impact op je continuiteit. Dat eerste is vrij standaard, dat tweede is zéér ongebruikelijk, en voor de doorsnee website ook complete overkill.

Normaler is dat je voor disaster-recovery gewoon offsite-backups maakt van belangrijke data. Als er dan een ramp zoals deze gebeurt ga je die herstellen op een nieuwe/andere server. Maar dat kan een paar dagen duren. Normaliter ga je er vanuit dat je zo'n scenario nooit écht mee zult maken. Als dat toch gebeurt, en het is geen geval van overmacht (zoals een natuurramp), dan mag je dat de provider zéker wel aanmerken.

[tonkie_67]

Wat ik van diverse msgs op de paginas van de hoster begreep is dat er klanten waren die wel degelijk redundantie hadden met kopieen van hun virtuele infra in andere locaties maat ze konden geen wijzigingen via cloud dashboard maken agv de brand/uitval. Dus geen aanpassing van de dns of wijzigingen in de firewalls of redirects.
En die tools waren blijkbaar onvoldoende redundant: kan je de klant niet kwalijk nemen

[dusti]

klopt inderdaad:
wij draaien op 3 locaties bij ovh en het onbereikbaar zijn van het controlepaneel was ook onze grootste frustratie - na het vlot beschikbaar zijn van dat controle-panel waren we snel terug up&running

[tonkie_67]

Aan de ene kant fijn om te lezen dat het dus zeker niet perse de schuld van klanten/eindgebruikers is dat ze geruime tijd down zijn/waren (zie alle zure opmerkingen van iedereen die het beter weet) maar jammer voor jullie dat je ondanks alle redelijke maatregelen om redundant te zijn nog steeds ernstig getroffen te zijn.
Hoe refundant je ook bent, zelfs door meerdere onafhankelijke cloud providers te gebruiken: als het management paneel van je primaire provider niet werkt...
Je zal een eind kunnen komen door al je domein/dns beheer bij cloud a te draaien, primaire site bij cloud B en dr site bij cloud C
En zelfs dan loop je nog tegen problemen op als je alle beheer van cloud B niet beschikbaar is terwijl wellicht een deel van de back-end systemen op een ander DC draaien van cloud B en zelf nog wel draaien maar omdat beheerpaneel van cloud B down is je nog steeds tegen fail over problemen aanloopt.
En zon oplossing met geheel externe beheer cloud is voor 99.9% vd toepassingen overkill en zal ook niet altijd te implementeren zijn door cloud leverancier specifieke beperkingen die extern beheer moeilijk maakt.
En dan nog kan je problemen hebben doordat zakenpartners ook getroffen zijn door de brand...
Als je primaire SD-WAN orchastror en/of gateway bij OVH Syraatsburg draaide kan je sdwan boer wel alternatieve orchastrators en gateways elders hebben maar ook zij moeten eerst kunnen overschakelen en daar kan ook weer tijd in gaan zitten.
En zelfs als je elk jaar een full DR failover test dan is een echt incidemt niet te vergelijken... bij een dr failover test is iedereen voorbereid, heb je toegang tot alle beheertools etc.
En management zal echt niet 100% "echt" willen testen waarbij je plots alle toegang tot primaire site kwijt bent (incl beheer) en je moet starten vanuit laatste backup oid zodat je echt uit de lucht gaat....
Wellicht dat je dat met een beperkte test omgeving mag testen maar dat geeft geen garantie.
En als je zelf veel in prive cloud draait (ipv on prem) dan dikke kans dat je ook veel 3rd party cloud diensten gebruikt voor primaire processen: en die zijn vaak weer gekoppeld aan eigen backoffice systemen in je eigen cloud: en dat vereist veel coordinatie met hen.... en als jij een van velen bent die een noodwijziging wil doorvoeren omdat een hele grote DC is afgefikt.....

[wiseger]

Als je hersel van data een paar dagen duurt, dan kan je organisatie een paar dagen niet werken. Je gaat er juist wel vanuit dat je dit mee gaat maken, daarom doen bedrijven jaarlijks full-loss data centre recovery testen. Bij de getroffen partijen zit o.a. een bank. Die moet jaarlijks dit soort testen doen, is een verplichting van de toezichthouders. Het gaat er nu om hoe goed had de hoster de zaken op orde en kunnen ze waarmaken wat ze hun klanten beloofd hebben. We zullen het de komende dagen gaan zien.

[mcDavid]

uhh, ja voor een handjevol servers met super kritische infrastructuur zoals o.a. die van banken klopt dat inderdaad.

Maar voor de overige, zeg, 99% van de getroffen websites is het onzin om dusdanige geografische spreiding te hebben.

[dasiro]

Inderdaad, je klanten kunnen kiezen om niet over verschillende datacentra gespreid te worden, wat goedkoper is. Moest deze situatie zich toch voordoen, dan moet je nog wel hardware hebben om een offsite-backup op te kunnen restoren en met de huidige schaarste in hardware is dat niet ff van de plank genomen en in een idle rack geschoven. Klanten moeten voor dit soort diensten extra diep in de buidel tasten en vaak vinden ze dat de kost ook niet waard, dus zal de uitbater dit dan ook redelijkerwijs niet voorzien.

[n4m3l355]

Ik denk dat je je ook mag afvragen wat een gemiddelde website voorsteld. In domeinen klinkt het extreem echter als ze gemiddeld 4 pagina's per domein hosten, komt mij dit toch wel heel sumier over als website zijnde en kan ik me goed voorstellen dat dezelfde gebruikers die blijkbaar het leeuwendeel zijn, geen backups hebben van hun 4 pagina's. Let wel dit zijn gemiddelde dus de realiteit zal eerder zijn een klein aantal grote websites, en een gigantische massa single page sites.

[e.dewaal]

Dat die websites offline zijn heeft niets met een brand in een datacenter te maken.

Dat is wel erg kort door de bocht. Tuurlijk is het een keuze vanuit de eigenaar. Maar anderzijds, hoe groot is de kans dat een heel datacenter offline gaat? Misschien is het wel een ingecalculeerd risico? Waarom investeren in een tweede server als het goedkoper is dat een website een dag uit de lucht ligt?
Wat is de impact van een willekeurige lokaal bedrijf op het moment dat de website een dag uit de lucht ligt? Maakt het de plaatselijke kapper uit? Vervelend dat iemand de openingstijden niet kan vinden, of een formuliertje niet kan invullen, maar als dat morgen wel weer kan, wat is het probleem dan in kosten? De meeste mensen zullen in dat geval gewoon een dag wachten en echte directe impact is er dan niet.
De oorzaak is en blijft dat er brand was in het datacenter. Had de downtime voorkomen kunnen worden? Zeker, maar de oorzaak blijft hetzelfde en heeft er dus wel degelijk mee te maken.

[Reactie gewijzigd door e.dewaal op 23 juli 2024 14:25]

[TomR]

Met de huidige maatregelen en de reservatie eisen is een website zelfs voor een kapper, noodzakelijker dan ooit (iig in Nederland)

[Tomatoman]

Maar dat maakt het nog steeds twijfelachtig of de extra kosten van nóg meer redundantie - in dit geval via een ander datacenter - verstandig zijn. Bij verzekeringen is een algemeen uitgangspunt dat je alleen die risico’s verzekert die je niet zelf kunt of wilt dragen. Het risico dat een datacenter wekenlang jouw website niet kan hosten is zeer klein en de gevolgen zijn voor veel ondernemers te overzien; vanuit die gedachte is het onlogisch om extra geld uit te geven aan de extra ‘verzekering’ om een website ook nog eens bij een tweede datacenter onder te brengen.

[JackBol]

[...]

Dat is wel erg kort door de bocht. Tuurlijk is het een keuze vanuit de eigenaar. Maar anderzijds, hoe groot is de kans dat een heel datacenter offline gaat?

Groter dan 0.

Misschien is het wel een ingecalculeerd risico? Waarom investeren in een tweede server als het goedkoper is dat een website een dag uit de lucht ligt?

In dat geval hoeft er dus niet geklaagd te worden op OVH.

[JackBol]

Als je de SLA leest, zal je zien dat ze geen 100% uptime garanderen en zich indekken voor rampen.

Als je de illusie hebt dat je voor een paar euro de verantwoordelijkheid op hen kan afschuiven heb je het flink mis.

[OddesE]

Ik weet niet hoe redelijk ik het vind om het risico op brand onder rampen te scharen voor een datacenter. Ik denk dat brand een heel reel bedrijfsrisico is voor een datacenter. Koeling wordt niet voor niks gedaan namelijk. Oververhitting is een reëel probleem. En brand ook. Dus ja, als een heel datacenter afbrandt vind ik dat je ze daar wel degelijk op mag aanspreken. Ook als omgeving die risico loopt met een datacenter in de buurt. En de milieuschade die het oplevert met al die chemicaliën die in de lucht komen. Kijk een aardbeving is een ramp maar dit had voorkomen kunnen worden.

En je haalt twee dingen door elkaar. Aansprakelijkheid en verantwoordelijkheid. Als je je site bij hen gehost had kun je ze niet aansprakelijk stellen voor de schade die je hebt opgelopen. Nee. Maar alsnog is er maar een partij verantwoordelijk voor de brand(on)veiligheid van dat datacenter en dat is de beheerder van dat datacenter. SLA of niet verandert daar niks aan.

[Reactie gewijzigd door OddesE op 23 juli 2024 14:25]

[JackBol]

Ik doelde met verantwoordelijkheid het up houden van een website. Die garantie geven ze niet af.

Overigens kan het risico op brand hoger zijn, maar dat betekent niet dat het afbranden van een datacenter geen ramp is.

[Powermage]

Wel heel kort door de bocht.

Buiten de brand zijn ook andere "datacenters" (die ongeveer er tegen gebouwd stonden) ook offline gegaan, is de gedeelde stroomvoorziening niet op orde waardoor andere ook plat zijn en herstel heel lang duurt.

Ook zijn er bepaalde cloud diensten van OVH offline die wel redundant hadden moeten zijn als ik het goed begrijp, is de email dienst ook niet heel snel hersteld en schijnt support heel lang nodig te hebben om je IP adressen en backups beschikbaar te maken op andere locaties (als je dit dus afnam bij ze).

Dus ook mensen die wel bij OVH betaalde voor redundantie/backups etc hebben niet meteen herstel van hun diensten gehad.

[Orangelights23]

Mooie reactie - en belangrijk ook, het klopt. Elke organisatie neemt een risico door slechts één datacenter te gebruiken, voornamelijk uit kostenbesparing. En hoe lastig het ook is om de kosten te berekenen door uitval van een datacenter (en dus de keuze kunnen maken om een hot/warm/cold site te gaan gebruiken), laat zien dat dit soort scenario's zeker kunnen gebeuren.

[MrSnowflake]

Als die ondernemingen kappers, en buurtwinkels en zelfstandigen zijn, dan hebben die geen nood aan multiregio setup. Heeft niks met kostenbesparing te maken, maar goed financiëel beheer.

[Reactie gewijzigd door MrSnowflake op 23 juli 2024 14:25]

[bazzi]

nou nemen die zelf een servertje af denk je bij ovh? of betalen ze een hosting partij, die kennelijk alle eitjes in 1 mandje legde bij ovh...

[Wraldpyk]

Of ze nemen gewoon webhosting af daar, wat vrijwel niets kost. https://www.ovh.nl/shared-hosting/

[bazzi]

maar dan is ovh wel in mijn ogen in gebreken, want met webhosting verwacht je in elk geval dat je binnen 24u weer online bent... Budget hoster of niet.

[FreezeXJ]

Mag je best verwachten, maar dat soort verwachtingen zijn het papier waarop ze niet beloofd zijn (met boeteclausule) niet waard...

[bazzi]

Dat is duidelijk. Heb zelf een hosting bedrijf, dus misschien dat ik daardoor met een andere bril en verwachtingspatroon naar kijk. Maar is ook niet het budget markt sigment waar we in zitten ;-)
Laten we zo zeggen, multi datacenter (andere eigenaar), multi netwerk (eigen netwerk met meerdere uplinks op verschillende locaties en een totaal andere netwerk leverancier gescheiden van ons eigen netwerk) en backups over verschillende locaties, voor minder zou ik het zelf niet willen doen, ook omdat ik rustig wil slapen snachts ;-) (en nee geen bijzondere SLA's, juist niet want die zijn meestal toch geen reet waard. Geen enkele klant wordt blij als ze geld terug krijgen van een SLA (die meestal toch zwaar gelimiteerd is))

[Reactie gewijzigd door bazzi op 23 juli 2024 14:25]

[casberrypi]

Jij bent zelf een AS en doet je eigen BGP?

[bazzi]

Yes, maar ook een extra los netwerk die niet in de bgp mix zit

[qvotaxon]

Niet bij elke hoster, dat ligt aan de SLA. Bij ovh daar heb je wel een punt. Dit staat letterlijk op hun website:

Inbegrepen bij al onze producten
Dagelijkse back-ups van gegevens en on demand herstel

Ik heb geen zin om de voorwaarden door te lezen, dus zou kunnen dat er ergens staat dat dit on-site backups zijn. Maar dan vind ik wel dat deze tekst wat misleidend is.

[Orangelights23]

Dat klopt helemaal, ik had moeten schrijven dat het grotere organisaties betreft.

[MrSnowflake]

Dan geef ik je volledig gelijk 😁

[pegagus]

Zeikerd

Serieus: ik denk dat maar weinig bedrijven nadenken over dit soort zaken. De echt grote en serieuze bedrijven zullen dat wel doen, maar de talloze MKB-bedrijven en ZZP-ers met een website denken niet zo ver.

[CaptainCapslock]

Voor veel zal het ook een (semi-bewust) geaccepteerd risico zijn. Redundancy is veel werk; bij de minimale kans dat een datacentrum afbrandt accepteer ik dat mijn site een week offline is.

[patatman12]

Redundancy is veel werk;

Maar het allerbelangrijkste (of je nou high-available bent, of alleen een fallback hebt) zorg voor een goede disaster-recovery!
Het kan voor de meeste websites/bedrijven super simpel zijn door backups te maken van kritieke data waarmee je een groot gedeelte weer kunt opbouwen.

[Reactie gewijzigd door patatman12 op 23 juli 2024 14:25]

[Groentjuh]

Er zijn waarschijnlijk tussen die 464000 domeinen genoeg domeinen, die lang niet zo kritisch zijn dat een paar dagen downtime onacceptabel zou zijn. In het afgebrande deel stonden 34000 servers, maar totaal zijn er 84000 servers op die locatie.

Zoals het er nu uitziet komen als het goed gaat over een paar dagen tot anderhalve week 50000 servers gewoon weer terug. Als ik een gesloten café zou hebben en mijn websiteje is nu even een paar dagen plat en ik weet dat ie in het derde datacentrum stond dan is dat zo, toch? Over een paar dagen kom ie dan mogelijk weer terug.

Daarnaast zijn er genoeg organisaties, die geen problemen hebben met het uitvallen van een aantal servers, maar een heel DC verbrand is best wel een risico wat vele organisaties als zeer laag zouden beoordelen.

[wiseger]

Het bedrijf verwacht dat het een aantal weken gaat duren voordat alle diensten weer in de lucht zijn.

Waarom heb je het over een paar dagen? Het bedrijf heeft het over weken.

Overigens zijn er ook banken getroffen. Kennelijk zijn er ook problemen met partijen die wel redundantie hebben afgenomen.

[Reactie gewijzigd door wiseger op 23 juli 2024 14:25]

[Groentjuh]

Op Twitter staat in deze tweet, dat ze hopen op 15 maart SGB1 en SGB4 te herstarten. Op 19 maart hopen ze SGB3 te herstarten.

[Slavy]

OVHCloud biedt zelf ook Clouddiensten aan, dat wil niet altijd zeggen dat je zelf verantwoordelijk bent. Een Clouddient hoort redundancy te kunnen geven, je gaat mij niet vertellen dat er 464.000 domeinen zijn met het daarbij behorende aantal klanten die geen redundancy gebruiken of krijgen van OVHCloud. Sowieso moet zo een provider een pagina kunnen tonen dat het domein tijdelijk niet bereikbaar is.

Je kan de titel dus beter noemen "OVHCloudprovider kan 464.000 domeinen niet elders actief zetten".

Volgens mij geloof je iets te veel in dat Cloud altijd 100% waterdicht is en dat de oorzaak altijd bij de klant ligt. Nee dat is het niet, cloudoplossingen worden vaker mooier verkocht dan dat ze zijn, dat heet marketing.

[Reactie gewijzigd door Slavy op 23 juli 2024 14:25]

[Jooz]

Je reactie gaat over verantwoording. De titel van Tweakers over oorzaak en gevolg; datacenter afgebrand en hierdoor x-aantal sites offline.

Je reactie voegt iets toe, maar de titel is pakkend en kloppend, of het in deze tijd nog zo maar lopen wordt niet in twijfel getrokken door de titel.

[MrSnowflake]

Hoeveel kappers zitten wel niet bij die 464000 domeinen? Hoeveel buurtwinkels? Hondenkennels, scholen, zelfstandige loodgietsers.... Allemaal mensen die terecht een site hebben, maar voor wie een multi regio opzet ver boven hun noden ligt. Zij draaien sites die €500/jaar kosten design, hosting en onderhoud inbegrepen. Daar is geen budget voor multiregio. Die zitten ook allemaal in de 464000 domeinen.

En ook past de titel perfect bij het artikel: Er zijn 464000 domeinen onbereikbaar door de brand.

[Sharky]

Potatoe potatoe. De oorzaak van het uitvallen is de brand. Het gevolg van een gebrek aan redundantie is dat ze door de brand getroffen worden. Daarnaast heb je een hoop giswerk in je post; wellicht had men alle verantwoordelijkheid uitbesteed aan OVH en wist men niet beter.

[CPV]

Ik heb eerder gelezen, dat dit (gebrek aan redundantie) bekend was en dat de gebruikers dus met de voorwaarden akkoord gegaan zijn (als ze die doorgelezen hebben).
Hetzelfde gold voor de gratis STACK cloud storage, die eind vorig jaar door zijn hoeven ging.

[Reactie gewijzigd door CPV op 23 juli 2024 14:25]

[jdh009]

Klopt, ik ben klant geweest bij zowel Kimsufi (hun budgetmerk) als OVH en daar wordt bij beide, naar mijn mening, duidelijk aangegeven hoe de infrastructuur in elkaar zit en wat je wel en niet kunt verwachten als je een server huurt. Via de klantenservice willen ze best met je meedenken, maar dat is iets waar je, iig bij de pakketen die ik afnam, altijd zelf achteraan moest. Eventuele spreiding naar hun datacenter in Canada was prima te regelen.

[Reactie gewijzigd door jdh009 op 23 juli 2024 14:25]

[Echt niet.]

Wel een grappige titel. Dat die websites offline zijn heeft niets met een brand in een datacenter te maken. [...]

Dat is niet waar, het heeft er alles mee te maken. Het had inderdaad wel voorkomen kunnen worden.

[CPV]

Rampen kun je niet voorkomen, er kan ook een Boeing op neerstorten. Ons datacenter heeft daarom een full function mirror op een kleine 20 km.

[Echt niet.]

Ik bedoelde vooral dat men had kunnen voorkomen dat sites offline gingen. Rampen kunnen gebeuren inderdaad.

[CPV]

Een copy van mijn antwoord iets verderop:
Ik heb eerder gelezen, dat dit (gebrek aan redundantie) bekend was en dat de gebruikers dus met de voorwaarden akkoord gegaan zijn (als ze die doorgelezen hebben).
Hetzelfde gold voor de gratis STACK cloud storage, die eind vorig jaar door zijn hoeven ging.

[n9iels]

Vanuit een professioneel perspectief is dit uiteraard 100% waar, idealiter heeft elke website een een disaster recovery plan om binnen 24 - 48 uur weer up-and-running te zijn.

Vanuit praktische perspectief snap ik ook wel weer dat veel bedrijven niet een plan hebben wat hierop is uitgedacht. Eerlijk is eerlijk: mijn recovery plan zou ook iets zijn in de trant van: elke 24 uur een sync naar een fallback server. Deze fallback server zou ik dan technische/virtueel zo veel mogelijk scheiden om ransomware ed. te voorkomen. Ik denk echter dat weinig mensen hierbij de fysieke locatie ook in acht nemen. Veel cloud provider bieden hier services voor aan, maar die zijn meestal enkel van toepassing binnen hetzelfde datacenter. Zelf opzetten van en naar verschillende datacenters zorgt dan weer voor heel veel extra werk. Voor veel kleine websites of webbeheerders overbodig.

De schuld hierin is gedeeld: bedrijven/afnemers zouden ook lokale en off-side backups moeten hebben van cloud providers. Maar OVH zou wellicht backups moeten verdelen over de locaties (SBG-1/2/3/4) om zo risico's te voorkomen. Een soort RAID op heel grote schaal

[Reactie gewijzigd door n9iels op 23 juli 2024 14:25]

[swhnld]

Hangt af van de diensten die ze verkopen, de naam OVHcloud geeft een indicatie dat het breder kan zijn dan alleen 1 datacenter, dus dat na een brand alles weg is. Alles met cloud er in wordt verkocht als hoog beschikbaar....

[Midas.e]

Moet zeggen, de reacties op twitter van Octave waren mooi. Mensen die vragen waar ze "het disaster recovery plan" konden activeren. Helaas voor deze mensen en kleine bedrijven is dat vaak waar de kosten zitten. Hoe snel kan je inderdaad herstellen van complete loss of datacenter.

[Madshark]

Ik schreef het ook al in het vorige topic over dit onderwerp.
OVH is zeer laagdrempelig, de kosten zijn zeer laag, je kunt 24*7 producten bij ze afnemen, in 3 muisklikjes heb je een compleet voorgeïnstalleerde server met het OS, distro en hostingsoftware naar keuze.
Geen KvK nodig, ze ondersteunen iDeal, PayPal en nog een boel creditcards.

En dat alles werkt op prepaid basis, dus je zit niet vast aan contracten die je moet uitzitten. Je betaald voor een maand, krijg je 1 maand het product, betaal je hierna niet meer, stopt automatisch de dienstverlening. Vrijwel alle diensten hebben ook geen datalimieten of billing by traffic, dus ook geen dataverkeer rekeningen achteraf.

Deze enorm lage drempel heeft een hele boel hosting cowboys aangetrokken, zeg maar degenen die overal klanten proberen weg te trekken omdat hun prijzen vele malen lager zijn.
Zo ken ik er wel een paar.

Die gaan nu allemaal nat, want geen backups, of backups (bewust) gekozen in hetzelfde datacenter.
Als ze nou eens de moeite hadden genomen om de documentatie door te lezen, waren ze al door OVH gewezen op het feit dat het dringend advies is om je backups elders te laten opslaan.
Maarja, dat kost geld.

En dan kunnen ze nu wel gaan huilen bij OVH, maar je bent als klant altijd nog verantwoordelijk voor je eigen data, staat gewoon in de SLA. (en dat is niet alleen bij OVH zo, maar vrijwel overal)

[Reactie gewijzigd door Madshark op 23 juli 2024 14:25]

[OxWax]

Merkwaardig : ik dacht dat server rooms speciale blusinstallaties hadden met Halon gas?

[Lizard]

Sinds 1 januari 2004 zijn Halon blusinstallaties verboden in Nederland en België. En dus ws. ook in Frankrijk.

https://nl.wikipedia.org/wiki/Halon

[Reactie gewijzigd door Lizard op 23 juli 2024 14:25]

[Niet Henk]

Echter kan je een Halon blusinstallatie veelal direct over zetten op een gas dat wel mag, zoals Novec, Inergen of Argonite, die wel mogen. Welk gas wordt gebruikt is een detail, het gaat om of er een blusinstallatie is die afdoende werkt, want die moet er inderdaad zijn, en vaak is dat er dan ééntje die niet alsnog alle computers sloopt (dus geen sprinklers).

Maarja, het mag duidelijk zijn dat er geen blusinstallatie was die afdoende werkte, anders was het pand natuurlijk niet afgebrand. Waarom dat zo is, is een raadsel voor mij.

[Lizard]

Ben ik het helemaal met je eens, het lijkt erop dat ze (ovh) op de verkeerde dingen bezuinigd hebben?

Hier geven ze in 2017 (!) al aan dat ze van plan zijn om die containers uit te faseren: https://www.datacenterkno...-after-epic-outage-europe

[Calypso]

Dat is giswerk; er is nog niets bekend over de oorzaak. Er zijn genoeg scenario's waarin zo'n grote brand wel degelijk kan ontstaan (bijvoorbeeld als het niet in het pand is ontstaan en zo al te groot was om door de blusinstallatie bestreden te worden, wanneer er een explosie o.i.d. is geweest met een plotseling en groot vuur, of wanneer er ontwerp/denkfouten gemaakt zijn (denk aan de Vodafone brand in de regio Rotterdam een aantal jaar geleden)).

Ook heb ik in enkele datacentra rondgelopen waarin aangegeven wordt dat de blusinstallatie eerst een alarm genereerd zodat personeel ter plaatse nog een x tijd heeft om te gaan kijken voordat het automatische systeem gaat blussen. Kan allemaal een factor gespeeld hebben.

Achteraf is het altijd heel makkelijk te zeggen dat er op verkeerde dingen bezuinigd is; maar achteraf kijk je een koe in de kont. Mijn eerste reactie toen ik foto's zag was ook "hoe kan het dat de gebouwen zo dicht bij elkaar staan", maar kijk eens bij een aantal DCs in Amsterdam, dat is ook niet altijd dusdanig vrijstaand dat een naburige brand geen invloed heeft op...

[JayPe]

Los van het feit dat Halon 1211 al een tijdje niet meer gebruikt mag worden (enkele zeer specifieke toepassingen daargelaten), is het niet zo dat een blusinstallatie altijd voldoende is om een brand(je) te blussen.

[OxWax]

Alternatieven genoeg toch? Inerte gassen, ...Argonite, Argon, Inergen , stikstof.
500M2, is nu niet bepaald een klein 'serverkot'

[TMDevil]

Ik weet niet hoe de brand precies is begonnen, laat staan het pad van de brandhaard. Maar zodra de ruimte niet meer "lucht dicht" is, kan dat gas natuurlijk weg en heeft het geen nut meer.
Sowieso zorgen die gassen er alleen voor dat er geen nieuwe brand kan ontstaan.

Daarbij worden zulke installatie alleen in de datacenter ruimtes zelf geinstalleerd, niet in de gang, kantoor of receptie waar misschien wel de band is ontstaan.

[Powermage]

Deze locaties zijn opgebouwd met minimale eisen.
De vloeren zijn van hout, de muren van dun blik, etc etc.
De enige blus systemen die ovh neerzet zijn water-gebaseerd.

[mmjjb]

@Powermage Heeft u daar een bron voor?

Ik heb niks kunnen vinden waarop we kunnen vaststellen dat er enkel een water gebaseerd blus systeem is.

Voor de geïnteresseerden; wat drone beelden van de brand:
https://www.youtube.com/watch?v=Mwh4OB_Sb_c

----------
Update 15:56:
Sorry; u heeft helemaal gelijk. Zie onderstaande foto's; alles lijkt inderdaad van hout gemaakt te zijn; ziet er allemaal niet heel erg solide uit.

Duidelijke foto's:
https://twitter.com/oleso...27696824825692161/photo/1
https://twitter.com/oleso...27695437706452993/photo/1
https://twitter.com/oleso...20100441146925057/photo/1
https://twitter.com/oleso...45865100894289920/photo/1

[Reactie gewijzigd door mmjjb op 23 juli 2024 14:25]

[Powermage]

Als je de twiter feed van hem verder bekijkt zie je in de historie tweets waarin hij aangeeft dat ze water blus systemen gebruiken, en je zag ook her en der foto's ervan.

de houten vloeren etc zitten op de server-vloer plekken.
de tussencorridor (SBG2 naar SBG3) is van beton, de rest zie je dus al op je eigen foto's.

[Calypso]

Er is water en water... ik weet dat in de toenmalige Telecity DCs er ook gebruik gemaakt werd van water: water-verneveling. En daar hadden ze best goed over nagedacht...

[raymonvdm]

Het nadeel van een hoogbouw pand is natuurlijk dat het prima als schoorsteen functioneert en daardoor niet echt te bestrijden valt. Het lijkt erop dat de looppaden van hout zijn, maar verder een staal constructie met blik

[Suspiria]

HOUT
jeetje zeg. het enige wat nog mist(e) is een rieten dak......

[hackerhater]

Of erger: De noodgenerator-ruimte. Die diesel-voorraad brand niet makkelijk, maar als het eenmaal begint te branden.........

[Kevjoe]

Het is niet omdat je een blusinstallatie intern hebt, dat je daarom veilig bent voor brand.
In dit geval zat de brand al buiten en had gasblussing waarschijnlijk geen of weinig effect gehad.

Een brand die ontstaat kan je hiermee wel tegenhouden, een reeds bestaande brand zal zodra er een opening in het gebouw ontstaat snel voldoende zuurstof binnenkrijgen om alles toch nog plat te branden.

[_Thanatos_]

Gaat het nou om de hosting van de domeinnamen of (ook) de websites die erachter liggen?

In het eerste geval lijkt het me raar, omdat DNS juist zo decentraal opgezet is dat er in principe geen SPoF kan bestaan.

[VDCNathan]

Uit de inleiding: "Door de brand bij het Franse OVHcloud zijn 3,5 miljoen sites offline."

Lijkt me dus meer over de sites zelf te gaan, al kan het denk ik ook wel dat er nameservers in de betrokken datacenters staan, die dan ook down zijn.

[_Thanatos_]

Mja dat is de vraag dus, want "site is offline" kan in mijn ogen vanalles betekenen.

[blorf]

Zoveel mogelijkheden zijn er niet. Als alleen de nameservers die naar een serie dommeinnamen wijzen eruit liggen zijn kunnen ze de benodigde ip's gewoon uit cache halen en omleiden. Dus daar zit het probleem niet. De ip's reageren niet meer dus de servers, al dan niet virtueel, zijn down.

[Niemand_Anders]

Zelden kom ik op DNS records een TTL tegen van meer dan 86400 (24 uur). Daarna staan de gegevens niet meer in de cache en zal men proberen bij een authoritive nameserver het IP te resolven, maar als die offline is, dan lukt dat niet..

Zo hadden wij vroeger (2001) een foutje in ons firewall script staan waardoor onze DNS servers in verschillende datacenters onbereikbaar waren. BigBrother gaf aan dat de DNS service gewoon actief is (djbdns/tinydns daemon) en ik dat er weinig systeembeheerders welke een controle hebben op het aantal dns queries welke op een DNS server binnenkomt..

[blorf]

Wat? Dan doe je een request naar de DNS-server van een grote provider. Als die het ook niet meer weet is er een DNS-probleem. Overigens onthouden de meeste computers ook gewoon het laatste bekende werkende ip van eerder bezochte domeinen. Dan ben je er nog achter of de betreffende server echt down is of alleen het resolven van het domein niet meer werkt...

[Niemand_Anders]

Het betrof de website van een van de grootste Nederlandse (CD/DVD) websites destijds actief in vrijwel heel Europa. Die DNS gegevens waren bij alle providers netjes gecached. DNS cache servers mogen records niet langer bewaren dan de TTL aangeeft..

Problemen met DNS van populaire domeinen komen pas aan het licht nadat de TTL is verlopen.
Het waren de medewerkers van een website waarvan we een weer daarvoor de website naar productie hadden gebracht welke begonnen te klagen dat zij de website niet konden benaderen..

Zo'n 10 minuten nadat de melding bij ons was doorgegeven was het probleem opgelost. Vervolgens hadden we bij een 5de datacenter een enkele server neergezet welke eveneens monitoring ging doen..

Wij hadden nu een fusie met een partner voltooid en zij hadden twee datacenters en de firewalls/gateways op deze 4 hosting locaties moesten alle de andere locaties bereikbaar (via IPSEC) maken voor elkaar (offsite backups) en naar 3 kantoor locaties.. Iptables loste een heleboek problemen van ipchains op.. ipchain was stateless (dus geen connection tracking) en dat gaf veel problemen met onder andere active FTP en IPSEC esp/ah packets. Maar vergeleken was ipchains een gigantische verbetering over ipfwadm. Ik ben eigenlijk verbaasd dat iptables nog steeds de actieve firewall voor Linux is..

Als wij 20 jaar geleden de kennis van nu hadden gehad, hadden we heel erg veel anders gedaan. En niet alleen op systeembeheer vlak ;-)

[_Thanatos_]

Het kan ook zijn dat bijv de verbinding naar de nameserver niet werkt, terwijl die server én de website nog in de lucht zijn. De route ernaar kan verstoord zijn. De route naar de website kan ook verstoord zijn, ook al werkt ie nog. Voor een eindgebruiker die ziet "site is offline" is er dus maar één ding aan de hand, maar in het achterlandschap kan dat een plethora aan oorzaken hebben.

In het geval van een brandje is de oorzaak duidelijk, maar wát er dan precies verbrand is, is niet zo 1-2-3 duidelijk. Dat zijn aannames (die vaak correct zijn, maar toch aannames zijn).

Kan bijv ook zijn dat alleen de routers afgefikt zijn, of de netwerkkabels gesmolten zijn, of de stroomtoevoer afgesloten is. Dat heeft in de browser van de eindgebruiker, en voor de beheerders van al die websites, hetzelfde effect.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 14:25]

[ToolkiT]

De sites zelf, DNS wijst dus naar een server die afgefikt is..
Als de sites weer werkend zijn kan DNS naar het nieuwe IP wijzen..

[Prince]

Indien de mensen natuurlijk een eigen dns server draaiden op die server, dan ligt die ook uit. Initieel zal deze nog uit provider dns caches komen, maar eenmaal de lifetime voorbij is... welja, is het voorbij.

Vermoedelijk zullen er ook DNS Servers van OVH zelf gedraaid hebben, maar die zullen inderdaad wel syncen met servers op andere area's.

Wat kut wel voor OVH. Ik ben wel tevreden van hun diensten. Enkel het "je krijgt maar 1 ipv6 bij een VPS" snapte ik niet. Nu zit ik bij Contabo. Ondersteuning is minder, maar prijzen zitten wel goed...

[ToolkiT]

Ik denk niet dat er veel Authoritative DNS servers draaiden op OVH eerlijk gezegd..

[hackerhater]

Well de A-DNS voor de webserver zelf?
Dus de laatste hop in het resolven van de domeinnamen?
Die staan vaak op dezelfde server/in hetzelfde netwerk als de hosting-servers.

Als ik kijk naar mijn eigen server verwijst de DNS van de registar door naar onze eigen DNS server voor de eigenlijke resolving.

[Reactie gewijzigd door hackerhater op 23 juli 2024 14:25]

[eborn]

Maar daar heb je dan als het goed is ook 2 of 3 machines voor draaien. En die zouden eigenlijk in 3 verschillende 'zones' actief moeten zijn, om te voorkomen dat bij een outage van 1 server (of een AZ) alles offline is. Inclusief eventuele externe e-mail van de klant.

[hackerhater]

Tjah money money money.
In mijn geval is het mijn bedrijfs-website ed. Als die een dag eruit ligt is dat maar zo.

[Madshark]

Als je geen idee hebt waar je over praat, zeg dan gewoon niets.

[Prince]

Tenzij OVH opzettelijk een brand zou aangestoken hebben, zijn zij slachtoffer en is het spijtig voor hen.

Ze hebben in Europa 15 datacenters en wereldwijd veel meer.
Ze zijn de klanten aan op opzetten op deze andere datacenters.
Lees de site van ovh misschien ook even (hier)

De onsite-backups zijn (logisch) niet beschikbaar en ze gaan dus gebruik maken van de offsite backups. (staat zelfs in bovenstaand artikel).

[Light21M]

Vermoedelijk de webservers en databases die eruit zijn.

[Myri]

Het gaat om de sites alsook wat er ook van infrastructuur achter zat (database, storage, ...)
En als je dan geen region redundancy hebt aangezet, dan heb je nu brute pech want dan ben je dus de hele meuk kwijt. (exact de reden waarom cloud-providers region redundancy aanbieden)

[Oon]

Het overgrote deel van de websites gehost bij een goedkope host als OVH zal helemaal geen failover hebben. Er zijn enkele bedrijven die wel een goeie infrastructuur daar draaien, maar die zullen dan ook failover op een andere locatie hebben.

Dus de meeste websitse die hier geraakt zijn zijn gewoon volledig offline. Hopen voor de beheerders dat die zelf back-ups hebben van de data en de code netjes in versiebeheer hadden (buiten OVH), maar het is niet alsof OVH zelf iets doet voor het beschikbaar hebben van data op meerdere locaties, zeker omdat er ook veel fysieke servers geraakt zijn en niet alleen VPSen.

[Morkatog]

Ik denk dat je op de registratie van de domeinnamen doelt. Domeinen worden geregistreerd bij een overkoepelend register, dus met de registratie van de domeinen is niets aan de hand.

Stel dat de nameservers ook in rook zijn opgegaan, dan is dat ook niet het eind van de wereld (even het grote ongemak en evt financiële schade terzijde), want dan pas je simpelweg de nameservers aan van je domein naar andere en stel je daar je DNS-records in. Enige toelichting: als je een domein bezoekt, naar mailt, etc , wordt er gekeken op welke nameservers de DNS-records van dat domein staan. Daar worden dan de DNS-records opgevraagd. Die DNS-records verwijzen op hun beurt naar de servers waar de betreffende service (bijv. website, e-mail) op gehost wordt, bijvoorbeeld via IP-adressen.

Het grote probleem hier zit hem in websites die enkel op servers in dit datacenter gehost worden. Zonder off-site back-ups of een redundante oplossing zijn die daadwerkelijk weg. Ik weet niet of OVH off-site back-ups gebruikt voor webhosting, maar zou mij vrij logisch lijken van wel.

[_Thanatos_]

Er moet ergens een provider zijn die een DNS heeft draaien waar die domeinen leven, en het kan zijn, maar ik beweer niet dat dat zo is, dat de domeinen (de nameservers inderdaad, zoals je zegt) ook bij deze partij in beheer zijn.

Dat hoeft niet zo te zijn, maar het is ook niet verboden ofzo. Als jij Morkatog.nl registreert, ben je vrij om daarvoor je eigen nameserver te draaien

[Ynst2003]

Door de brand bij het Franse OVHcloud zijn 3,5 miljoen sites offline. Die zijn verspreid over in totaal 464.000 domeinen.

kan iemand mij het verschil uitleggen?
rekenen ze subdomein1.tweakers.net en subdomein2.tweakers.net als 2 losse sites en tweakers.net als 1 domein?

[_Thanatos_]

Ik denk het wel ja, want dat is doorgaans hoe je een webserver inricht. En misschien iets van maintenance-omgevingen op alternatieve poorten ook. Maar denk ook aan HTTP en HTTPS, wellicht rekenen ze dat ook als 2 sites op 1 domein.

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 14:25]

[Ynst2003]

wel een rare manieren van rekenen, want meestal zijn subdomeinen iets van img.tweakers.net / js.tweakers.net / forum.tweakers.net. Wat voor mij toch echt gewoon 1 site is.

[starfight]

Dat is 1 website, img, forum, db etc zijn aparte sites. Zie het als een industrieterrein met meerdere gebouwen die allemaal 1 bedrijf vormen magazijn, showroom en fabricage.

[pgerrits]

Dat is dus niet zo technisch. Het zijn aparte sites met het zelfde TLD. tweakers.net/forum, tweakers.net/js tweakers.net/img zouden wel de zelfde site zijn.

[hondvandeburen]

volgens mij wil je in jouw voorbeeld juist dat het fysiek ook aparte servers zijn om de lading te spreiden

[Blokker_1999]

Subdomeinen kunnen onderdeel zijn van een site of kunnen volledig andere sites zijn. Dat weet je niet. Het enige waar je zeker van kunt zijn is dat een subdomein door een andere webserver geserveerd kan worden en over het algemeen worden die dan ook als aparte sites geteld.

[batjes]

Maar je kan ook prima alles achter tweakers.net/ serveren vanaf andere servers, dat tweakers.net/nieuws van server A komt en tweakers.net/pricewatch van server B. Je kan ook Apache2 of Nginx als een soort proxy of load balancer gebruiken.

Beide gevallen zeggen niet direct iets over hoeveel servers ergens achter hangen en/of je het tot 1 website zou kunnen rekenen.

[Reactie gewijzigd door batjes op 23 juli 2024 14:25]

[Blokker_1999]

http/https zijn protocollen. Je bezoekt nog altijd dezelfde site, alleen met behulp van een ander protocol. Dat gaan ze dus niet als verschillende sites rekenen. Ik verwacht daarnaast niet dat ze volledige resources gaan ophalen maar sites in de eerste plaats monitoren met behulp van pings en dan komt http(s) niet eens van pas want dat is icmp.

[_Thanatos_]

Of je dat verschillende sites moet *noemen*, valt te betwisten. Het *zou* kunnen dat ze ze als twee sites rekenen, maar het zou ook kunnen van niet. We weten het gewoon niet.

[watercoolertje]

Je hebt het zelf al goed uitgelegd want dat is inderdaad zo

www. is ook gewoon een (imo overbodig) subdomein. Je kan dus www.site.com en site.com al rekenen als 2 sites, hoewel in de praktijk dat 99/100 keren dezelfde site is is het technisch gezien gewoon een andere.

[jordynegen11]

Ik wil toch even wat kwijt over hoe OVH de situatie aanpakt. Natuurlijk hier ben je nooit echt goed op voorbereid maar er zijn heel veel klanten die momenteel in onzekerheid zitten.

Momenteel is het zo dat SBG 3,4 en een deel van SBG1 In tact is. Echter kunnen klanten niet meer achteraf zien in welke locatie hun server staat omdat alle SBG diensten niet meer zichtbaar zijn in het paneel. Heel veel onzekerheid dus over de data van heel veel klanten.

Support van OVH reageerde altijd al pas na dagen en nu is het niet anders dus daar heb je ook niets aan.

Daarnaast is er veel onduidelijkheid over SBG 5 en 6 wat 'virtuele' locaties zijn. De CEO heeft alleen getwitterd dat "hij denkt" dat dit ondergebracht is in SBG3.

Nu lijkt het er ook op dat OVH enkel een branddetectie systeem heeft en geen brandpreventie systeem. Wat ik een zeer slechte zaak vind. Dit kan dus ook in een ander OVH DC gebeuren waar mijn servers wel staan.

Godzijdank stonden mijn servers niet in SBG en moet ook zeggen dat de updates van de CEO (ex-ceo?) gewaardeerd worden.

[Reactie gewijzigd door jordynegen11 op 23 juli 2024 14:25]

[3raser]

Ik denk dat het type datacentrum in dit geval veel zegt over de veiligheid ervan. Dit waren blijkbaar containerunits met servers. Geen compleet gebouw wat van de grond af was ingericht als datacentrum. Qua brandveiligheid valt daar waarschijnlijk een hoop te winnen.
Ik had er geen servers staan maar ik zou er na dit incident ook wel twee keer over nadenken. Ik snap dat dit iedereen kan overkomen maar het is nu OVH overkomen. Dat geeft ze gewoon een achterstand in vertrouwen.

[Madshark]

Ik had er geen servers staan maar ik zou er na dit incident ook wel twee keer over nadenken.

Afgezien van de brand, moet je imho altijd vanuit gaan dat een datacenter plat kan gaan, en daar je case op bouwen.
Nu is het een brand, maar er zijn nog 10tallen andere oorzaken waarom je server het niet meer doet in een DC. (natuurrampen, stroom, een vliegtuigongeluk, terroristische aanval, etc.etc.)
Al moet ik het verhaal van @jordynegen11 bevestigen, ze gaan wel goed om met de situatie.
Ik had wat failover IP diensten van ze afgenomen, en ik heb letterlijk nog geen minuut downtime gehad. Alles draait nog steeds, maar nu in Roubaix en Londen.
Wel houd ik mijn hart vast voor Roubaix, dat is een oudere locatie, en volgens mij nog steeds het centrale hart van hun netwerk.

[De Vliegmieren]

Overigens zijn de meeste commercieële Franse websites in het .com TLD (vraag me niet waarom), dus dat komt goed overeen met de statistieken van welke website niet bereikbaar zijn.

[DarkForce]

Het artikel lijkt vooral te gaan over hosting diensten zelf, daarbij wordt niet vermeld dat er ook meer dan genoeg bedrijven en individuen zijn die een server huren waarop ze één of meerdere websites draaien.

Ikzelf maar ook in mijn omgeving zijn er zat die een servertje huren voor persoonlijk gebruik en daarop wat eenvoudige websites van vrienden, familie, bekenden en kennissen draaien naast dat diezelfde servers ook voor wat kleinschalige back-ups van belangrijke thuisdata gebruikt wordt.

Of te wel, probeer het exacte aantal offline websites maar eens echt in te schatten met de op gehuurde servers gehoste websites. Dan zit je een heel stuk verder boven dat aantal.

[Fox3214]

Kan iemand mij het volgende uitleggen?

- Waarom is er geen fail-over situatie op geografisch niveau?
Veel datacenters kunnen een fail-over doen naar een andere streek, regio of zelfs land.
Is dit hier ook bij gebeurt, en spreken we over dat de genoemde domeinen geen juiste SLA hebben
gekozen?

- Als er geen geografisch redundantie aanwezig is, spreken we dan van een niet dekkende fail-over SLA?
In de plekken waar ik datacenters ben tegen gekomen, is er altijd spraken van een uitwijk locatie.

- Klopt het OVH cloud geen toegang heeft tot hun netwerk devices? Vandaar dat ze mogelijk geen fail-over kunnen doen?

[bertware]

Hangt dit niet gewoon af van de configuratie van de klant?

Ik heb ook een tijdje een dedicated bare-metal server gehad bij OVH voor €1,50 per maand. Ik had geen nood aan redundantie of backups op die server, maar als ik dat wou kon ik daarvoor bijbetalen (als ik het me goed herinner), of een tweede server nemen en het zelf configureren.

Ook in bijvoorbeeld AWS is het perfect mogenlijk om een site te hosten die offline gaat als er een datacenter afbrand. Geografische spreiding en dergelijke zijn eenvoudig mogelijk, maar als je zelf gewoon voor de goedkoopste bare-metal/VPS oplossing kiest heb je dat natuurlijk niet.

Het kan goed zijn dat OVH wel uitwijk locaties heeft om aan hun contractuele voorwaarden te voldoen (verhuur van een server), maar de data ben je dan alsnog kwijt als je niet voor een backup zorgde (door zelf te maken of voor te betalen)

[Fox3214]

Ja, het wordt meer meer duidelijk dat het eigenlijk gewoon een simpele baremetal provider is.

Het woord cloud provider vind ik dan ook niet gepast, als ik denk aan een cloud provider dan denk ik aan amazon, google of azure.

Thanks!

[Madshark]

- Waarom is er geen fail-over situatie op geografisch niveau?

Die is er wel, kun je zelf zo bouwen bij OVH, maar veel klanten hebben hier niet voor gekozen (want dat kost extra)

- Als er geen geografisch redundantie aanwezig is, spreken we dan van een niet dekkende fail-over SLA?

Ze bieden zelfs intercontinentale redundancy, maar net als mijn eerste antwoord, dat kost extra, en sommigen hebben hier dus niet voor gekozen.

- Klopt het OVH cloud geen toegang heeft tot hun netwerk devices? Vandaar dat ze mogelijk geen fail-over kunnen doen?

Zover mij bekend, (ik ben ook maar een doorsnee klant, maar wel met de failover opties, dus 0,0 last gehad van de brand), is ook een 400kv trafohuis afgebrand, en zitten ze dus simpelweg zonder stroom (again).
Dus alles wat fysiek in Strasbourg staat, is onbereikbaar, zowel op netwerk als server nivo.
Klanten die bij de andere datacenters zitten hebben verder geen issues.

[raymonvdm]

Redundantie kun je op vele manier bereiken elk met een ander prijs kaartje

OneShopStop: Je kunt er voor kiezen om alles bij 1 partij te hosten maar wat gebeurd er als die partij problemen heeft met hun core netwerk? Zijn dan alle datacenters offline of zijn alle datacenters losse entiteiten met eigen AS en peering / transit links.

Twin Datacenter Je kunt er ook voor kiezen om je spullen te plaatsen bij twee (juridisch) verschillende partijen waarbij je zelf kan kiezen vanuit welk datacenter je je content verstuurd op basis van BGP of DNS bijvoorbeeld. In geval van een storing moet je dan wel je DNS records kunnen wijzigen.

Als de datacenters elkaar fysiek raken moet je dan wel spreken van verschillende datacenters of het zien als 1 site. En hoe vaak komt het niet voor dat een DNS van een domein gehost wordt op 1 locatie of zelfs op 1 VPS waarbij de ns1/n2 van het domein gewoon dezelfde VPS zijn?

Voor een simpele website wil je dus je backup op een andere locatie hebben (gedownload naar huis/kantoor) waarbij je deze makkelijk kan uploaden naar een andere aanbieder, zonder dat je de eerste aanbieder nodig hebt om je backup te verkrijgen. Voordeel is dat je een kopie van deze backup ook weer in je staging omgeving kan gebruiken om bijvoorbeeld een wordpress update te testen :-)

p.s. Wat is eigenlijk de definitie van een "domein offline" is dat dat er geen levende nameservers meer zijn, of dat er geen webserver meer reageert?

[Reactie gewijzigd door raymonvdm op 23 juli 2024 14:25]

[larsg]

Volgens een filmpje op twitter van hun CEO zou het ontstaan zijn na een UPS onderhoud. Zo'n ding heeft hoge vermogens te verwerken dus die willen wel eens beginnen fikken...

Bizar wel dat ze samen met Atos een EU cloudprovider gaan opzetten. Atos opereert toch een klasse DC waar uptime belangrijker is.
Dat gezegd zijnde is softwarematig makkelijk genoeg failover in te stellen op een hoop cheape servers