Trods failover: Digitaliseringsstyrelsens systemer nede i timevis efter varmekollaps i datacenter

Kritiske it-systemer gik i sort under et stort datacenter-kollaps sidste søndag, selvom de var sat op med failover-løsninger. Ifølge NNIT, som varetager driften af systemerne, er det normalt med nedetider på trods af failover.

Det ramte den danske it-infrastruktur bredt, da et datacenter i Ballerup ejet af virksomheden Interxion brød sammen sidste søndag. DSB blev påvirket, de danske medier blev påvirket, og kritiske it-løsninger i det offentlige blev påvirket.

Blandt de ramte systemer var Digitaliseringsstyrelsens NemLog-in, som er en del af den offentlige digitale infrastruktur. NemLog-in skal blandt andet sikre, at borgere og medarbejdere har adgang til alle offentlige myndigheders web-løsninger med ét enkelt login.

Driften af det kritiske it-system står NNIT for. NemLog-in er sat op med en såkaldt failover-løsning. Det betyder, at NNIT har to redundante driftsmiljøer til NemLog-in, som er placeret i to forskellige datacentre.

I tilfælde af problemer i et af datacentrene, skal failover-proceduren sikre, at NemLog-in kan køre videre i det andet. Men da det ene datacenter – Interxions datacenter i Ballerup – gik ned som følge af et svigtende køleanlæg og en eksplosion af en defekt køle-slange, bragede NemLog-in alligevel ned.

Det forklarer Adam Lebech, der er vicedirektør ved Digitaliseringsstyrelsen, i en mail til Version2.

»NemLog-ins driftsmiljø består af redundante miljøer, altså dublerede eller spejlede miljøer, i to forskellige datacentre med geografisk uafhængige lokationer. Det gør, at driften kan fortsætte i tilfælde af nedbrud, og at såkaldte ’single point failures’ dermed undgås. Brugerne af NemLog-in oplevede dog alligevel i søndags (den 30. juni 2019, red.), at NemLog-in var utilgængelig i et tidsrum,« skriver han i mailen.

Afventer beskrivelse fra NNIT

Trods failover-processen medførte varme-kollapset i Ballerup-datacentret, at NemLog-in gik ned i over en halvanden time. Den foreløbige registrerede nedetid fra hændelsen sidste søndag viser ifølge Digitaliseringsstyrelsen, at systemet var utilgængeligt i perioden fra omkring 20:23 til 22:05.

Det er stadig uklart for Digitaliseringsstyrelsen, hvad der gjorde, at det kritiske it-system blev lagt ned af Interxions nedbrud, når nu trafikken på NemLog-in burde have kørt videre på et andet datacenter. Styrelsen venter derfor på en forklaring fra NNIT, som står for driften af systemet.

»Digitaliseringsstyrelsen afventer fortsat en beskrivelse (root cause analysis) fra NNIT af, hvorfor NemLog-in i dette tidsrum ikke var tilgængeligt,« skriver Adam Lebech i mailen til Version2.

»Failover kan inkludere en nedetid«

NemLog-in var ikke det eneste system, som NNIT drifter, og som trods failover-opsætning blev slået omkuld i forbindelse med Interxions nedbrud.

Et andet system hos Digitaliseringsstyrelsen, kaldet eID, var nede i to timer, og hos DSB var der problemer med salgssystemerne, som NNIT også står for driften af. Både DSB's systemer og eID kører med failover hos NNIT.

Version2 har kontaktet NNIT for at opklare, hvorfor flere it-systemer – trods en tilsyneladende failover-løsning – alligevel har været nede.

I et skriftligt svar til Version2 oplyser NNIT, at virksomheden i forskellig grad benytter sig af failover-systemer til deres kunder, hvor it-systemer automatisk skifter mellem forskellige datacenter-ressourcer i tilfælde af et nedbrud.

»NNIT har implementeret forskellige niveauer for failover til forskellige kunder og forskellige situationer, nogle er manuelle, nogle er automatiske. Omfanget af redundans varierer fra at omfatte løsninger, som beskytter udvalgte data, til komplette systemer,« skriver NNIT's pressekontakt i mailen.

It-virksomheden uddyber, at failover-systemerne satte ind under nedbruddet i Ballerup-datacentret, og at det er normalt, at der kan forekomme nedetid i forbindelse med failover-procedurerne.

»I forbindelse med hændelsen i Interxions datacenter trådte failover-funktionerne i kraft på kunde-systemerne efter behov. Afhængig af kompleksiteten på de enkelte løsninger kan failover inkludere en nedetid, det afhænger af løsningens design, og det kan af hensyn til sikkerheden og intakte data være nødvendigt at foretage kontroller,« skriver NNIT's pressekontakt.

På baggrund af svarene har Version2 stillet nye spørgsmål til, hvad der helt konkret er årsagen til, at der forekommer nedetid på op mod to timer i forbindelse med failover-processer hos NNIT. Version2 har desuden spurgt Digitaliseringsstyrelsen til, om styrelsen havde forventet, at failover-løsninger kan indkludere nedetider. Det er endnu ikke lykkedes at få svar, og styrelsen henviser til, at man foreløbig afventer en redegørelse fra NNIT.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Heino Svendsen

Staten "glemmer" at angive svar-/nedetider i en masse projekter. Om det er grundet inkompetence eller blot "vennetjenester", skal jeg lade ligge. Men... jeg har aldrig oplevet en kontrakt fra staten, hvor de var specificerede. Dog har der været mange "antagelser" og flygtige bemærkninger, som "rimelige grænseværdier"...

Sorry, Sonny Boy. I jura er der ikke SÅ store definitioner af "rimelige"...

Povl H. Pedersen

hvad man betaler for. Og når det er det offentlige der handler, så får man vel det halve til den hele pris, da det virker som om at det offentlige gerne vil betale.

Hvis man ikke har købt hot-standby med automatisk failover på hele løsningen, så får man vel heller ikke dette.

Alternativt kan man købe noget load balancing på tværs af datacentre, så en død server ikke vil kunne ses i andet end svartider. Men det er så en helt anden sikkerhed, og en hacker eller andet vil muligvis stadig kunne trække det hele ned.

Der er mange måder at designe det på. Og man overlever også en 4 timers nedetid. Så hvorfor betale for mere ?

Tobias Tobiasen

Jeg ville nu forvente, at et så kritisk system som Nem-Login kørte ægte redundans, dvs. som et fuldt distrubueret system.

Det her tyder på, at de ikke engang har haft hot-spare med automatisk omkobling.


Automatisk failover til et andet datacenter hos en anden leverandør tilføjer kompleksitet. Endda en kompleksitet der er svær at teste ordentlig.

Så inden man kaster sig ud i at at tilføje sådan en kompleksitet er det klogt at spørge sig selv om det øger oppetiden eller gør den mindre.
Jeg har set flere tilfælde hvor det setup der håndterede automatisk failover forårsagede nedetid.

Det er meget sandsynligt at et par timers nedetid når man mister et datacenter giver mindre nedetid set over flere år end den ekstra kompleksitet automatisk failover til et hot replacement datacenter vil give.

Morten Fordsmand

Jeg ville nu forvente, at et så kritisk system som Nem-Login kørte ægte redundans, dvs. som et fuldt distrubueret system.

Det her tyder på, at de ikke engang har haft hot-spare med automatisk omkobling

Nu mangler jeg fortsat at se et system der faktisk kombinerer fuldautomatisk failover med fuld datakonsistens. Eller sagt på en anden måde:

Du kan enten få konstant oppetid, bare se googles søgefunktion
Eller du kan få garanteret integriteten af dine data.

I øvrigt er det at have en effektiv failover løsning ved centertab afhængigt af at du tester den jævnligt, og det er måske ikke specielt nemt at få lov til at afprøve den slags på f.eks. Nemlog-in.

Tobias Tobiasen

“Nu mangler jeg fortsat at se et system der faktisk kombinerer fuldautomatisk failover med fuld datakonsistens. Eller sagt på en anden måde:

Du kan enten få konstant oppetid, bare se googles søgefunktion
Eller du kan få garanteret integriteten af dine data.”

Hvis man selv skal bygge det så er det ganske givet svært. Men i hvert fald en af cloud udbryderne har både konsistens og immun overfor tab et datacenter. De garanterer at data først er committed når det er gemt i mindst to datacentre. Med automatisk failover af services så får man begge dele.

Morten Fordsmand

Med automatisk failover af services så får man begge dele.

Er du nu helt sikker på det?
Problemet er at dine applikationer (i de overlevende datacentre) automatisk skal gå over og køre på den overlevende database instans, der i øvrigt skal skal være sikker på at det er sikkert at overtage rollen (prøv at google "split brain"). Ikke at det kan automatiseres langt hen ad vejen men helt sikkert det bliver det nu ikke.

Hvis man selv skal bygge det så er det ganske givet svært.


Ikke svært men dyrt, dog med ovenstående forbehold.

Tobias Tobiasen

Er du nu helt sikker på det?
Problemet er at dine applikationer (i de overlevende datacentre) automatisk skal gå over og køre på den overlevende database instans, der i øvrigt skal skal være sikker på at det er sikkert at overtage rollen (prøv at google "split brain"). Ikke at det kan automatiseres langt hen ad vejen men helt sikkert det bliver det nu ikke.


Ja. Det er jeg helt sikker på.
De løser det ved at bruge 3 datacentre. Split brain problemer undgåes ved at have mindst 51% af hjernen tilgængelig. Så hvis du har 3 datacentre så kan du tåle at miste 1.
Og applikationerne vil efter kort tid automatisk begynde at snakke med den nye database.

Rasmus Larsen

Nu er det altid farlig at gætte, men når jeg hører service navnet "NemLog-in", leder det mig hen på en service type der burde være designet aktiv-aktiv fra starten.

Hvis det virkelig bare er en, muligvis forkromet, authentikering eller authorization service, så er vi ovre i noget der bør kunne leve med "eventually consistent" og så ligger distribueret lige til højre benet.

Jan Heisterberg

Hændelsen rejser især TO spørgsmål:

  1. Hvad var den tekniske årsag til det længere varende, totale, ned brug af den nævnte systemer - som burde være fair-safe

  2. Hvad står der egentlig i de respektive kontrakter ?

Det er bare et partsindlæg, når NNIT skiver “det er normalt at ...”.
Hvis der i kontrakten står 99,9% oppetid, så kan enhver regne ud at 8760 timer * (100 - 99,9%) = 8,76 timer per år er acceptabelt.
Hvis der står 99,98%, så er det på kanten.

Log ind eller Opret konto for at kommentere