Herstel na brand in NorthC-datacenter duurt nog zeker drie dagen

Het gaat nog zeker drie dagen duren voordat alle klanten van het NorthC-datacenter weer operationeel kunnen worden, voorspelt het bedrijf. NorthC zegt dat de herstelwerkzaamheden na de brand op donderdag nog 72 uur kunnen duren.

NorthC heeft de eerste bevindingen gepubliceerd van een technisch onderzoek. "De werkzaamheden om de stroomvoorziening te installeren en de klantapparatuur gefaseerd weer van stroom en koeling te voorzien, nemen naar verwachting 72 uur in beslag. Het plaatsen van een groot aantal generatoren, UPS-systemen en verdelers, alsmede het trekken van ruim een kilometer kabel is een complexe operatie", schrijft het bedrijf.

Op vrijdagochtend liet het bedrijf al weten dat 'de rookontwikkeling op de zalen beperkt is gebleven'. NorthC wist toen echter nog niet wat de impact was.

Op donderdagochtend brak er een ernstige brand uit bij het datacenter van NorthC in Almere. Dat is een van de grotere datacenters van Nederland. Veel bedrijven en instanties, waaronder de Universiteit Utrecht en de Kamer van Koophandel, hadden last van die brand, omdat bepaalde systemen daardoor niet of slechter bereikbaar waren.

datacenter Almere. Bron: NorthC

Door Tijs Hofmans

Nieuwscoördinator

08-05-2026 • 16:14

88

Submitter: Xieoxer

Reacties (88)

Sorteer op:

Weergave:

Vanavond heeft NorthC aanvullende informatie gedeeld met betrekking tot het herstel van de redundante energievoorziening. Hierbij is aangegeven dat er sprake is van ontbrekende kritische componenten. Deze informatie is door Unica ICT gedeeld.

Op dit moment heeft NorthC haar crisispagina nog niet geüpdatet. Sindsdien heeft Unica ICT vier updates gepubliceerd over het herstel van haar dienstverlening en het herstel van de (redundante) energievoorziening door NorthC, blijkbaar heet NorthC andere prioriteiten.

NorthC en leveranciers staat voor een mega operatie om de energievoorziening betrouwbaar en redundant te herstellen en in korte tijd is mega veel werk verzet! mede omdat de 150 kV-elektra-aansluiting van Liander/TenneT is buiten bedrijf is (de kabelscheider in de Tennet/Liander schakeltuin aan de Strubbenweg is geopend). ter ondersteuning en vervanging van de energievoorziening wordt een groot scala aan Bredenoord en Aggreko aggregaten ingezet.

De technische installaties in het tweede (rechter) utiliteitsgebouw, waarin vier (nieuwe) noodstroomgeneratoren staan opgesteld lijkt onbeschadigd en zijn in bedrijf (rookpluim op de uitlaat). Daarnaast staan naast de rechter utiliteiten/serverruimte vier Bredenoord-generatoren van 2000 MVA en vier generatoren van 1000/1250 kVA geplaatst en gedeelte is inbedrijf.

Naast de linker serverroom zijn meerdere stijgers/loopbruggen geplaatst als kabeltrace en buiten staan 10 (aantal niet met zekerheid bevestigd) Aggreko 1250KVA generatoren en wordt hard gewerkt voor het aanleggen van de bekabeling en zijn hier de kritische componenten benodigd waardoor het herstel langer duurt.

Naast het afgebrande (linker) utiliteitsgebouw stonden De 2 stuks mobiele Luminus Solutions ~2500/3200KVA roterende UPS/generatoren welke naast de afgebrande (linker) utiliteitsgebouw stonden zijn verplaatst en het lijkt erop dat deze niet gebruikt worden voor (tijdelijk)herstel van de energievoorziening.
(Update 12 mei 15:30)
Het laatste onderdeel dat nodig is voor het herstarten van de stroom- en koelvoorziening wordt op dit moment geïnstalleerd. Daarmee zijn we in de afrondende fase van het technische herstel na de brand van vorige week.

Parallel hieraan bereiden we de inschakeling van de apparatuur van onze klanten voor. Onze account managers en technisch specialisten nemen persoonlijk contact op met al onze klanten in Almere om de inschakelprocedure en de volgende stappen voor morgen door te lopen.

Zo zorgen we voor een gecontroleerde en gecoördineerde herstart, cruciaal om het opstartmoment voor iedereen soepel te laten verlopen.
Dit soort dingen moeten helaas gebeuren om er wijzer van te worden; Bedrijven doen er goed aan om hun systemen redundant uit te voeren over meerdere datacentra (daar moet dan dus meer geld naartoe) en North-C zou misschien kunnen overwegen om dit soort technische ruimtes dubbel uit te gaan voeren, want dan kan je ze geheel afkoppelen tijdens onderhoud en calamiteiten. Bouwtechnisch in ieder geval knap dat de schade beperkt is gebleven tot deze ruimte. Kudo's voor de mensen die dit weekend met man en macht aan de werk gaan om alles weer in de lucht te krijgen!
Is dat zo? Dit is echt een 'freak accident' en de kans dat het nog een keer gaat gebeuren is minimaal. Er draaien duizenden DC's wereldwijd en alleen in NL al honderden.

Impact is groot, maar kans is héél erg klein. Kosten zijn enorm voor alles redundant over twee DC's uit te voeren. Vaak niet x2, maar eerder x4 als je alle testing van failovers ook goed wil doen.

Nee, ik zie niet snel gebeuren dat iedereen nu massaal alles dubbel gaat uitvoeren.
Maar de gevolgen zijn ook groot. Een hele universiteit die plat ligt, mensen kunnen daar niet eens de deur meer openen met hun toegangspas. Een rederij waar men de tickets niet meer kan scannen, wat tot vertragingen lijdt.

Je hoeft voor deze zaken heus geen hot spare te hebben draaien. Maar een off-site backup waarmee je het systeem op een andere plek binnen minuten of hooguit uren weer kan opstarten, lijkt me heel haalbaar zonder hoge kosten.

Overigens kan je ook vraagtekens zetten bij de architectuur van deze systemen. Zeker die toegangscontrole bij de UU: wie ontwerpt er nou een systeem waarbij dat afhankelijk is van een server die tientallen kilometers verderop staat? Ik heb toevallig jaren geleden gewerkt bij een bedrijf dat toegangscontrolesystemen maakte. Daar had elke lokale unit (die geloof ik tot 8 deuren kon aansturen) een lokale kopie van de toegangsrechten. Dus bij uitval van de server of het netwerk, bleef de deur gewoon open gaan.
Geen geo-redundancy afnemen is een keuze.
Het zal altijd een kosten/baten/risico overweging zijn. Als jouw bedrijfsvoering 1 week uit de lucht minder kost dan alles redundant uitvoeren is het kostentechnisch niet interessant genoeg om voor de redundante oplossing te gaan. En dan nog blijven er een hoop andere single-points of failure.

Het probleem is dat veel bedrijven hun processen/afhankelijkheden niet goed inzichtelijk hebben, dus te positief inschatten wat er gebeurd als bepaalde ICT voorzieningen niet beschikbaar zijn.

Ik heb er geen problemen mee wanneer een bedrijf niet voor een redundante oplossing gaat; als het maar goed overwogen is en er bijv. goede calamiteitenplannen beschikbaar zijn. Want als ze een hoop geld over de balk smijten voor een onnodig complexe/uitgebreide oplossing betaal je daar als klant altijd voor.
Het irriteert me een beetje dat iedereen meteen begint over dat "alles redundant uitvoeren" zo duur is. Dat is zo, maar je hoeft helemaal niet "alles redundant uit te voeren" om bestand te zijn tegen het uitvallen van een server of een heel datacenter. Als je zorgt dat je regelmatig een off-site back-up maakt en een script of playbook maakt om vanuit die back-up je server processen op een nieuwe omgeving op te starten, kan je de downtime al terugbrengen naar hooguit enkele uren. Het is niet zwart/wit, je hoeft echt niet alles redundant te maken. Maar ik vind het wel raar dat men vaak geen plan heeft liggen om de boel snel te herstarten op een nieuwe server als dat nodig mocht zijn.
Het probleem ie dat je wel een andere locatie moet reserveren. De goedkoopste oplossing is de servers plitsen over 2 lokaties en in geval van problemen met halve capaciteit draaien. En dan dus bij piekmomenten balen.

Maar eerlijk 4 dagen of line voor een universiteit is lastig, maar geen halszaak.
Een paar dagen eruit is geen probleem voor colleges geven of zo. Maar voor bepaalde onderzoeksopstellingen is het wel essentieel dat je in elk geval het gebouw/de zaal in kan komen. Denk aan dierproeven waar je op zijn minst de dieren wil verzorgen, of als je een kernreactor hebt draaien. Geen idee of ze daar niet extra voorzieningen voor hebben.
Wij zeggen hetzelfde, alleen op een iets andere manier. En ja, het irriteert me ook dat klaarblijkelijk in de reacties op deze brand er continue "geo-redundant uitvoeren" als een must gezien wordt. Voor de vluchtleiding van Schiphol moet je dat zeker doen. Voor een hoop andere zaken is het gewoon overkill. Toen ik zelf nog verantwoordelijk was voor een flinke omgeving hadden we gewoon de draaiboeken klaar liggen: als het hoofd DC niet beschikbaar is, dan gaan we op de secundaire lokatie door voor bepaalde accounts en functies. In de 15 jaar dat ik er gewerkt heb is het 0 keer voorgekomen dat het plan uit de kast getrokken moest worden - gelukkig maar - maar de plannen lagen klaar.
Die mensen die dat zeggen hebben vast een geo-redudant huis.
Ja duh! Wat ik ter discussie stel is of het de juiste keuze is.
Voor alle klanten van NorthC zal dit een goed evaluatiemoment zijn. Ongetwijfeld komt er meer geld en aandacht voor systemen die kritisch zijn gebleken voor redundantie. Er draaien vaak honderden diensten van een organisatie in zo'n datacenter, waarvan sommige van elkaar afhankelijk zijn. Achteraf is het altijd makkelijk praten.
Ik kom regelmatig in aanraken met deur- en pasjessystemen vanuit een IAM-perspectief (provisioning van accounts en permissies) en het valt mij op dat al die systemen werkelijk archaïsch zijn met een volslagen houterige architectuur. Om even een paar voorbeelden te geven:
- Toegang alleen bij te werken via een CSV die je ergens moest neerzetten
- Throttlen van requests naar het systeem naar maximaal 1 per aantal seconden omdat je anders de server onderuit trekt
- Accounts aanmaken in een database die qua datamodel uit 1960 lijkt te komen en waarbij de software wijzigingen gewoon soms niet oppakt
- Systemen zonder enige mogelijkheid tot koppeling (dus letterlijk een mail sturen naar de beheerder: ken deze toegang toe)

Het verbaast me dus helemaal niets dat die systemen totaal uitvallen. Goed om te lezen dat er blijkbaar ook systemen zijn met een lokale kopie op de kaartlezer. Ze zijn in de minderheid.
Het bedrijf waar ik toen werkte had in die jaren (begin van deze eeuw) al een keurige web-interface die draaide op ee degelijke unix-server. Was toen super vooruitstrevend.
Dat lijkt standaard te zijn voor systemen die buiten de IT afdeling om worden aangeschaft. Voor gebouwmanagement systemen hebben daar een handje van. Kan alleen op ijzer draaien, geen VM. Security best practices moeten worden gestopt anders werkt de software niet meer. En de directie heeft de handtekening gezet onder het koopcontract van die lift/hvac/camera's/sloten dus de software weigeren is geen optie.
Op de UU bleven de deuren ook gewoon open gaan. Er is weer een hoop klok / klepel op het internet.
Op nos.nl (toch niet echt een “willekeurige website”) staat:
De universiteit van Utrecht blijft morgen dicht. "Door brand in een datacentrum in Almere zijn er problemen met het netwerk, applicaties en websites van de Universiteit Utrecht. Dit heeft grote impact op het dagelijkse werk, onderzoek en onderwijs van en voor collega's en studenten", schrijft de onderwijsinstelling op zijn site.

De digitale systemen van de universiteit werken niet, evenals de toegangspassen. Medewerkers en studenten kunnen hierdoor werk- en studieruimtes niet in. "De noodzakelijke veiligheidsmaatregelen kunnen niet geboden worden", staat op de website van de universiteit.
Als je enige ervaring opbouwt met berichtgeving over zaken waar je zelf bij bent geweest danwel waar je meer van weet, zul je ontdekken dat in dergelijke berichtgeving doorgaans onvolkomenheden voorkomen. De NOS is daarop zeker geen uitzondering.
Je hoeft voor deze zaken heus geen hot spare te hebben draaien. Maar een off-site backup waarmee je het systeem op een andere plek binnen minuten of hooguit uren weer kan opstarten, lijkt me heel haalbaar zonder hoge kosten.
Een off-site backup is inderdaad niet zo duur, maar op welke andere plek ga je het dan opbrengen? Dan moet je dus ook ruimte en rekenkracht afnemen in een tweede datacenter. Als je een goedkope manier weet om dat te doen dan hoort mijn werkgever dat graag haha. Als je een groot IT landschap hebt kunnen die kosten in de tientallen miljoenen lopen, zeker met de huidige prijzen.
Ook de universiteit Utrecht heeft dat zo geregeld. Waar het fout gaat is dat die rechten automatisch snachts ververst worden, en dan kunnen mensen de volgende ochtend hun pas niet meer opladen met de huidige rechten
Nee, ik zie niet snel gebeuren dat iedereen nu massaal alles dubbel gaat uitvoeren.
In bijvoorbeeld de Azure cloud kun je gewoon aanclicken dat de storage 3 online kopieen heeft in evenzoveel gebouwen. En dat kan je dan weer offline (maar wel streaming) laten repliceren naar nog eens 3 kopieen in een andere regio/land. Storage is ook niet de grootste kostenpost (dat zijn de CPUs). De CPUs hoeven niet dubbel, die zet je pas elders aan als het nodig is. Dus valt allemaal best mee. Wel het draaiboek regelmatig goed oefenen voor het beste resultaat!
De vraag is wel dat als jij samen met alle andere klanten ineens duizenden CPUs gaat aanzetten in je fail-over DC bij Azure omdat een ander DC plat ligt deze CPUs überhaupt beschikbaar zijn.

Dan kan je leuk testen dat het werkt met een draaiboek maar dat zegt zeker niet over de beschikbaarheid tijdens een grote outage.
Sterker nog, het komt in de cloud zelfs wel voor dat er in een bepaalde regio uberhaupt specifieke diensten niet afgenomen kunnen worden. Bijvoorbeeld door een gebrek aan compute. Als je naar Azure kijkt heb je paired-regions waarbij Noord-Europa de regionpair is van West-Europa en visa versa. Drie maal raden wat er gebeurd als West-Europa uitvalt... Ken ook wel organisaties die kiezen voor zone-redundancy, maar geen geo-redundancy want als Amsterdam er uit ligt, dan ligt onze dienstverlening er toch al uit en hebben we al grotere problemen :P
Maar je hebt een enkele leverancier en als die een probleem hebben zoals wel eens is gebeurd bij aws, dan ben je ook weer niet klaar met die oplossing. Echte redundantie is een hoop werk.


Recent voorbeeld: cloud issue

[Reactie gewijzigd door demianmonteverd op 8 mei 2026 18:29]

en jij denkt dat er genoeg CPU is als er een AZ weg valt bij Azure of AWS?
Als jij geen garantie afkoopt vis je gewoon achter het net. Weg compute. (on demand = risico lopen in een dergelijk geval)
Ook als je wel garantie afkoopt, ben je alsnog de sjaak als het gewoon op is.
We weten niets over de oorzaak helaas, dus daarmee kunnen we ook niet concluderen of dit een uitzondering gaat zijn of dat er een ontwerpfout in de technische ruimte heeft gezeten waarmee wellicht ook andere datacentra een risico lopen. Een minimaal risico is tenslotte ook een risico die je in overweging moet nemen.

Mijn insteek was slechts het redundant uitvoeren van de technische ruimte, niet het compleet dubbel uitvoeren van een datacentrum, want die keuze is aan de klant.
We weten nog niks over de exacte oorzaak en eventuele ontwerp fouten. Een helft van mijn redundant uitgevoerde server setup staat hier ook en dat deel is de hele tijd online gebleven. Dus niet het hele dc is geraakt door een zeer grote brand in de technische ruimtes. En deel van het ontwerp lijkt in ieder geval wel naar behoren te werken dus.

Meer redundantie op DC level kost ook weer meer geld, terwijl eralsnogveel risico's boven zoals dat de brand wel was overgeslagen naar andere ruimtes op dezelfde locatie. De betere oplossing is toch echt je servers over meerdere geografisch gescheiden DCs verdelen.
Dit vind ik wel interessant. Een gedeelte van het Northc DC in Almere draait nog?
of snap ik dat verkeerd?
Het hele datacenter is op zwart gegaan. Ik mocht vandaag naar binnen om onder begeleiding onze suite te inspecteren samen met een collega. Alle suites van klanten zagen er compleet normaal uit. de brandlucht was er nauwelijks te ruiken zelfs, als je niet erop zou letten zou het niet opvallen.

Klanten met een eigen UPS hebben mogelijk langer uptime genoten. Mischien zelfs genoeg uptime tot het 'poweron' event wat straks komt.
Als die technische ruimte dubbeliitgevoerd was, moest alsnog de stroom er af vsn de brandweer. Krijg je alsnog rook die het datacentrum binnendringt. De kans verdubbelt.
Klopt wat je zegt, alleen was de stroom en koeling dan waarschijnlijk wel inmiddels terug geweest.

Een ander ding waar de datacenters over na kunnen denken is een grotere afstand tussen de technische ruimtes en de zalen. Dan is het risico van overslaan van de brand van de technische ruimte naar de zalen kleiner. Nu moest ook een deel van het gebouw waar de zalen in zitten worden nat gehouden.

Ook het scheiden van noodstroom en koeling kan helpen. Wanneer zoals nu de noodstroom in de brand is gevlogen, had in die bij een gescheiden ruimte voor de koeling voor minder problemen gezorgd.

Bij het ontwerp zijn zeker verbeteringen mogelijk. En wat de redundantie betreft, daar moet altijd een afweging gemaakt worden tussen risico’s en kosten. Wij hadden ook een lijnverbinding die slechts enkelvoudig was uitgevoerd i.v.m. kosten. Die hebben we binnen een uur of 8 kunnen omleiden via een vpn met hulp van de lijnleverancier. Dus die systemen zijn ook weer beschikbaar. Redundantie is een keuze en is altijd afhankelijk van hoe lang een systeem er uit mag liggen.

Wat voor de continuïteit nog wel een ding is, is dat de brandstof tank slechts 24 uur de noodstroom overeind kan houden. Dus als je daar naar kijkt, dan is er ook nog een uitdaging als je kijkt naar de scenario’s van de overheid voor 72 uur stroomuitval. Hoe krijg je dan aanvulling van de brandstof?

En ja, elke calamiteit zorgt weer voor nieuwe inzichten. Ik hoop dat men hiervan leert om het voor toekomstige calamiteiten weer robuuster te maken. Het blijft nu eenmaal techniek. En alle techniek kan falen.
We weten niets over de oorzaak helaas, dus daarmee kunnen we ook niet concluderen of dit een uitzondering gaat zijn of dat er een ontwerpfout in de technische ruimte heeft gezeten waarmee wellicht ook andere datacentra een risico lopen. Een minimaal risico is tenslotte ook een risico die je in overweging moet nemen.

Mijn insteek was slechts het redundant uitvoeren van de technische ruimte, niet het compleet dubbel uitvoeren van een datacentrum, want die keuze is aan de klant.
Juist omdat we niks weten is dit gel*l in de ruimte. Ik weet wie er bij betrokken zijn geweest bij het ontwerp en bouw. Er moet daar een ongelofelijke cluster fuck geweest zijn om dit te veroorzaken. 2x zo'n technische ruimte neerzetten kan 3x zo veel kans geven om het weer te laten gebeuren. Je werkt daar met heel veel brandstof en stroom. En dat moet, met 2 van die ruimtes, ook nog met elkaar communiceren. Je kan ook moeilijk een 2 tank met 1 miljoen liter diesel daar in de grond stoppen.

Ik verwacht eerder dat ze een mogelijkheid maken om de spullen die ze nu neerzetten makkelijker kunnen aansluiten aan de andere kant van het pand en een mogelijkheid om dat energiegebouw makkelijker te kunnen afkoppelen zonder dat de normale stroomvoorziening onderbroken gaat worden. Maar dit is ook puur speculatief.
En heel veel storingen komen juist door failover apparatuur. Wel goede offline backups, en terug zetten op een andere lokatie mogelijk maken.
Dat iis ook mijn ervaring. Dat heel veel problemen veroorzaakt worden door beveiliging. Daar reken ik de pasjes van UU opk toe. Maar ook brandblusinstallaties die ten onrechte afgaan en harddisks beschadigen. Machines in andere DC de achter firewall staan. Interne certificaten die verlopen etc. Allemaal problemen waar handigr neefjes met een NUC in de meterkast geen last van hebben
Nee, dit is (buiten de brand om) geen freak incident. Er kan altijd eens iets fout gaan met de stroomvoorziening. Mooi praktijk voorbeeld: in Amerika bij een van de datacenters waar ik jaren geleden bij betrokken was is bij onderhoud de sensor die meet dat de zaal zonder stroom komt te zitten foutief terug geplaatst... hierdoor registreerde de sensor dus niet dat de stroomaanvoer verdwenen omdat de ups'en het al hadden overgenomen... hierdoor werden de generatoren voor de noodstroom niet ingeschakeld en toen de ups'en leeg waren kan je wel raden wat er gebeurde - een mooi donker en oorverdovend stil datacenter :S

Het is voor bedrijven sowieso goed om eens beter stil te staan bij de redudantie van hun systemen. Uiteraard in gradaties: Disaster Recovery vs High-Availability + Disaster Recovery.

Neem het voorbeeld van de veerboot... die zou er best aan doen om een schaduw te draaien van de boekingen. Dit hoeft op zich niet eens real time gesync'ed te worden (met zeg een interval van een uur ben je maar beperkt data kwijt). In dat geval zouden ze dan bij een calamiteit in het datacenter wel lokaal nog de incheck kunnen laten doordraaien.

En ja - dat kost geld maar de uitval van je bedrijfsvoering kost ook geld.

[Reactie gewijzigd door gooos op 10 mei 2026 14:15]

Ik hoop vooral dat de druk nu niet terechtkomt bij de mensen die met man en macht werken aan het herstel van de dienstverlening, of bij de medewerkers die hinder ondervinden van de uitval. De echte discussie zou moeten gaan over de (financiële en strategische) keuzes die eerder zijn gemaakt rondom redundantie, fail-over en geo-redundante voorzieningen — of het bewust niet afnemen daarvan als dienst.
Inderdaad. Het is inmiddels een kwart eeuw geleden dat ik bij grote bedrijven werkte, maar "in mijn tijd" was een uitwijkplan standaard voor bedrijfskritische toepassingen. Ik leef inmiddels van de overuren die ik heb kunnen declareren bij de weekend testen van het rampenplan. Opa volgt dit nieuws met verbazing.
Tja het feit dat deze ruimte apart was vind ik al goed. Ok volgende keer elektra van het net scheiden van het gebouw met argegaten? En iets verder van het hoofd gebouw? En misschien ook nog compartimenten in het hoofd gebouw. En misschien ook na denken hoe een brand eenvoudiger geblust kan worden. Leerlingen trekken en verdergaan.
Het is zo makkelijk om te zeggen maar technische oplossingen zijn gewoon extreem lastig over multi site..

Kubernetes platform zou je zeggen verdeeld over 3 locaties. 1 down 2 over. Das leuk voor applicaties die stateless zijn maar zodra je in database landschap komt is dit gewoon echt heel moeilijk om consistent te houden en performance te blijven bieden.

Dan kom je in ibm db2 hoek of de gelijksoortige Oracle oplossing. Postgress heeft vast ook oplossingen tegenwoordig maar makkelijk is anders.
Zowel postgres als MariaDB (MySQL) hebben tegenwoordig HA oplossingen.

Leuk feitje: Een van de meer populaire open-source oplossingen vooor Postgres (Patroni) is ontwikkeld door Zalando (de schoen-verkoop site)
Zo hoorde ik ook eens over een online boekwinkeltje dat een wereldwijde public cloud heeft gebouwd en daar aardig succesvol in is
Dat zeg ik toch ook? Maar dat de oplossing er is betekent niet dat het makkelijk te implementeren is. Vaak zijn er latency requirements en zelfs al zit je in de categorie voor volledig synchroon over 2 of meer locaties is het ook storing gevoelig

daarnaast is vaak ook applicatie support nog wel een ding. Niet persee technisch maar in de vorm van wat een vendor wel of niet als ondersteund ziet.
Als je applicaties zoals je database software het niet ondersteunen, kun je toch alsnog gewoon je filesystem redundant maken, bijvoorbeeld met Portworx, Ceph of DRBD. Je kunt dan geen instant failover doen, maar zelfs al duurt het 1 of 2 minuten, dat is beter dan uren of dagen offline zijn.
Das vaak nog altijd async en biedt geen garantie op consistentie op je alternate site
Dat hangt nogal van de configuratie af. DRBD kan gewoon synchroon draaien (Protocol C), en Ceph/Portworx ondersteunen ook synchronous replication. Async replication wordt vaak gebruikt voor geo-redundancy vanwege latency, maar dat betekent niet dat die systemen per definitie eventual consistency zonder garanties bieden.
Ben toch benieuwd naar de oorzaak. Ik ben daar geweest, en het hangt vol met melders en sprinklers.
ben benieuwd of het echt binnen die tijd geregeld kan zijn, de blusoperatie is relatief lang geweest en er zal een hoop 'gesloopt' zijn om goed te kunnen blussen. wel goed om te lezen dat de afscheiding tussen de zalen goed gewerkt lijkt te hebben en de brand (schade) dan hopelijk ook tot 1 sectie beperkt kan zijn.
Wat ik begrijp is het datacenter zelf eigenlijk onaangetast. Het gaat alleen om de NSA ruimte (noodstroom).

Met een beetje goede wil en een stapel aggregaten van Bredenoord moet je dit relatief eenvoudig moeten kunnen fixen.
Ben wel benieuwd hoeveel kVA zo'n DC trekt in het licht van de dieselprijzen van tegenwoordig.
het is noodvoorzieningen. zolang de netspanning er op blijft maakt de brandstof prijs niet veel uit.
Daar maak je een aanname "zolang de netspanning er op blijft". De vraag is of deze aansluiting snel te herstellen is. Misschien eerst aggregaten om de dienstverlening op gang te krijgen, om vervolgens de primaire aansluiting te fixen.
Een netwerk/cluster van aggregaten synchrone te laten lopen onder zware last is lastig. En geeft een heleboel punten waarop het fout kan gaan. Waardoor de volledige energie voorziening onderuit gaat.

Zolang de voedingskabel nog bereikbaar is, is het beter en sneller een nieuwe hoofdverdeler op te bouwen. Dit is redelijk echt to recht aan. En hoeft niet opnieuw berekend te worden. De huidige tekeningen kunnen hier voor gebruikt worden. En dit is in 72 uur goed te doen. En een noodstroomvoorziening van aggregaten in een netwerk/cluster daar achter. Opbouwen en testen.

Daarna kan er begonnen worden met de sloop van het afgebrande stuk en een nieuwe noodstroomvoorziening opbouwen.


ps. een hoogspanningshuisje staat niet binnen. Dit is een apart huisje met een dikke trafo. Maar ook die kan in geval van nood binnen 24 uur vervangen worden door een tijdelijk versie.
ps. een hoogspanningshuisje staat niet binnen. Dit is een apart huisje met een dikke trafo.
NorthC Almere is nou juist hier een beetje een vreemde eend in de bijt. Ze hebben een directe aansluiting op het 150kV-net (meer details bij TenneT), en die kabels komen nou juist precies uit in de vleugel die hier is afgefikt. Een 150kV-trafo is niet iets wat je zomaar bij de bouwmarkt haalt...
Berichtgeving van vandaag lijkt anders. Zoals ik lees nu nog geen directe aansluiting op het reguliere stroomnet. Hoe kijk jij hier nu tegenaan?

"De tijdelijke, redundante stroomvoorziening in onze locatie in Almere is uiterlijk woensdag om 12:00 uur beschikbaar. Vanaf dat moment kunnen klanten hun systemen weer gecontroleerd inschakelen.

Dit is later dan de termijn die wij vrijdag 8 mei communiceerden. De reden is een vertraging in de levering van een kritiek component dat nodig is voor de redundante opbouw. Het onderdeel is vanuit de Europese leverancier onderweg en komt dinsdagochtend in Almere aan. Direct na aankomst starten onze technici met de installatie.

Wij bouwen de stroomvoorziening bewust direct redundant op, zodat de latere overgang naar het reguliere stroomnet zonder extra onderbreking kan plaatsvinden."


bron: LinkedIn post NorthC Datacenters 11-5-2026
Een component. Dat kan alles zijn. Aangezien ze direct een redundante stroomvoorziening gaan bouwen kan het zelfs een speciale schakelaar zijn.

Als het een hoogspanningscomponent zou zijn was dit naar alle waarschijnlijkheid wel vermeld. Dat het onduidelijk wordt gehouden lijkt het mij een component aan de klant zijde. Bot gezegd na de meter.
"NorthC benadrukt dat de huidige stroomvoorziening tijdelijk is en dat er nog geen aansluiting is op het reguliere stroomnet. Het datacenterbedrijf analyseert nu wel hoe het datacenter zo snel mogelijk aangesloten kan worden op het stroomnet. De huidige tijdelijke voorziening gaat dan als back-up werken. Het bedrijf zegt de oorzaak van de brand nog te onderzoeken en zegt nog niet te weten wanneer de conclusies klaar zullen zijn."

Lijkt erop dat er aggregaten staan te draaien.
Grappig genoeg kunnen we het bij dit DC vrij accuraat weten, want er is twee jaar terug een rechtszaak geweest over de capaciteit van hun stroomaansluiting.

Dus je antwoord: 6.5 MW, met toekomstige uitbreidingsplannen naar 15 MW.
ja dat moge duidelijk zijn, dan is de tijdelijke oplossing best wel recht toe recht aan, nu spelletje blame game voor wie de schade mag betalen, want de verzekeraar zal er vast geen zin in hebben.
Zuur natuurlijk, maar shit happens en gelukkig niemand gewond.

Mochten ze ergens vanaf willen vanwege rookschade dan sta ik wel open om het op te halen hoor.
Kunnen ze gewoon reinigen met "water" vandaag de dag :)
Godzijdank is er geen schade aan klantapparatuur op zaal. De Fortigates die wij daar hebben staan zijn nog net zo wit als voor de brand. Hopelijk is m'n HA cluster weer netjes in sync maandagochtend. :)
Helaas zit ook mijn huidige opdrachtgever (ik ben freelance) bij de getroffenen. NorthC heeft ons bijna elke 3 uur minimaal 1 keer, soms vaker, op de hoogte gehouden. Situatie is gewoon puur ruk en ook ik kan hieruit concluderen dat het bij de huidige opdracht niet geregeld zou zijn zoals het zou moeten. Helaas moeten ze het via deze weg leren, een kostbare les.

Mijn collega is vandaag binnen geweest en voor een powerspike hebben wij onze servers ontdaan van voeding. Zodra het gestabiliseerd is gaan we weer online, met betere fallbacks in andere centra. Apparatuur is gelukkig onbeschadigd gebleven, de spuitgasten hebben goed hun werk gedaan en de vooraf genomen maatregelen van NorthC lijken afdoende te zijn geweest.

TLDR: gewoon ruk — en doorrrrr.

[Reactie gewijzigd door ReSpawN op 8 mei 2026 18:01]

Ik hoor iedereen over redundantie etc van de getroffen diensten, maar dat is natuurlijk een ontwerp keuze van de partij die de dienst heeft draaien.

Maar waar ik niemand over hoor is dat het ontzettend knap is als ze dit na 72 uur weer draaiende hebben kijkend naar de ravage afgaand op de foto’s.

Schijnbaar was het allen de noodstroom ruimte maar natuurlijk lopen ook een deel van de live circuits daar langs anders kun je de omschakeling niet goed regelen.

als je dan op de foto’s in het NOS artikel ziet wat de ravage is dan vind ik dat ontzettend knap!
Wat ik wel bijzonder vind is dat die voorziening blijkbaar niet dubbel is uitgevoerd. Als ik het NOS-artikel quote:

[quote]
Het lijkt erop dat het vuur alleen heeft gewoed in de stroomvoorziening en de koeling van het datacentrum. Die zaten in een gebouw dat losstond van de servers, juist om te voorkomen dat brand kan overslaan.
[/quote]

Misschien te simpel gedacht, maar waarom is dat gebouw niet dubbel uitgevoerd met eentje aan de ene kant van het DC en eentje aan de andere kant. Ja vast een financiele keuze net zoals alle keuzes maar ik vind het toch wel apart. Geen redundante koeling klinkt als risicovolle keus.

[Reactie gewijzigd door Korvaag op 8 mei 2026 19:23]

Alle datacenters die ik ken hebben 1 NSA ruimte. Ze zullen er vast zijn, maar ik moet de 1e nog tegenkomen die 2 gescheiden NSA ruimtes heeft t.b.v. redundantie.
Was er geen foto van de schade?
Beelden (foto en video) vind je in dit artikel van de NOS.
dit zou in dit artikel ook erbij moeten staan. (site hopping zou niet nodig hoeven zijn ) :)
Gisteren nog discussie wat ze wel en niet moeten posten.. Van een techsite vind ik dat ze dit soort nieuws direct wel mogen posten met updates als live blog. En dan zie je zo'n nieuwsbericht als vandaag weer met oude content dan denk ik wel oke.. ze willen dus ook niet anders. En als je dan geen rechten hebt voor die afbeelding, dan stuur je er een iemand heen met live camera's en zet een livestream op of maakt zelf een foto.. En dit soort ramptechnieuws vinden we ergens ook wel weer mooi om te lezen, ook voornamelijk hoe snel ze reageren en de stroom weer kunnen herstellen etc..
edit:
En misschien zijn er wel medetweakers die wel fotos/videos hebben.. Vraag of benader die dan.. Nu krijgt de NOS weer een link waar vervolgens nog meer info te vinden is..

[Reactie gewijzigd door moonlander op 8 mei 2026 17:01]

Kees woont daar om de hoek dat stond in het vorige artikel..
Dus het leek mij niet echt heel veel gevraagd.
Deze stock foto vind ik echt een beetje vreemd gekozen, vooral omdat het om een brand gaat en je ziet hier een prachtig mooi nieuw en brandschoon gebouw.
Daarnaast was ik zelf gewoon erg benieuwd hoe het gebouw er nu uit zag, ook omdat ze stellen dat er geen data verloren is gegaan.
Sommige DC's hebben in de voorwaarden staan dat je niet mag fotograferen, als je bezoekt staat het ook vaak nog extra in de bezoekersvoorwaarden. Dus Kees mag dat mogelijk niet doen of voelde zich daar misschien nog aan gehouden (geen idee, maar las ergens dat tweakers direct/indirect iets deed met northc). Daarom zie je ook soms in sommige foto's die mensen maken in datacentra dat ze omgeving 'uitgummen' om te voorkomen dat racks/cages/etc. van andere partijen in beeld zijn. Waarschijnlijk mag dat ook eigenlijk niet, maar zo ver ik weet is nog nooit iemand daarop aangesproken.

N.B. weet niet meer wat er in de voorwaarden staat die opgaan voor nortch dc's.
Je mag gewoon fotos maken van dat pand, zolang je het maar niet vanaf hun prive terrein doet.
NOS heeft wel actueel foto,s van de situatie.

Vrij simpel de backup feed gebouw is afgebrand, kennelijk heeft het de main feed ook geraakt wat erg slecht geregeld is voor een datacenter en niet zou verwachten.

Er zijn geruchten dat een gedeelte van het datacenter online is gebleven.

Wil je actueel info dan zijn kanalen als Facebook/Twitter vaak sneller helaas.

[Reactie gewijzigd door mr_evil08 op 8 mei 2026 17:49]

Die foto van het afgebrande stuk is dus het 'transformator huisje' van het DC. De stroom aggregaten , ups'n en hoofd-energielijnen zijn dus wel echt gewoon volledig vernietigd door de brand.

NorthC heeft het in hun nieuwsbericht erover dat er 1km kabel opnieuw getrokken moet worden voor de hoofd voorziening.

https://www.northcdatacenters.com/nieuws/brand-in-ons-datacenter-in-almere/
Het datacenter beschikt over één (niet‑redundante) 150 kV‑aansluiting met twee transformatoren hoog->middenspanning transformatoren. In 2024 heeft NorthC een aanvraag gedaan om het gecontracteerde vermogen te verhogen van circa 6,5 MW naar 15 MW, maar deze is wegens netcongestie afgewezen. In de jaren daarvoor is het gecontracteerde vermogen meerdere malen verlaagd, vermoedelijk in lijn met de feitelijke vraag.

Op basis van recente observaties lijkt de locatie te zijn uitgebreid. Op luchtfoto’s is zichtbaar dat op het dak van het technische gebouw aan de achterzijde (jan. 2024) en tussen de datarooms (feb. 2025) meerdere extra koelunits zijn geplaatst, wat duidt op een toename van het koelvermogen en daarmee een hogere beoogde energievraag.

Daarnaast is op beelden van de brand zichtbaar dat achter het getroffen gebouw een tijdelijke noodstroomgenerator staat (container/trailer, ca. 1,5–2,5 MWe).

Gelet op de impact van het incident hoop ik dat NorthC de onderzoeksresultaten openbaar maakt. En de oorzaak van de brand en de elektrische bedrijfsvoering — inclusief de beschikbaarheid en borging van de N+2‑(nood)stroomvoorzieningen — transparant moeten worden toegelicht, voor nu blijft het speculatie op basis van de waarnemingen en afwachten op verdere berichtgeving.

Om te kunnen reageren moet je ingelogd zijn