Derfor bragede NemLog-in ned trods failover: Host forsøgte at bruge forkert storage

Illustration: Grafik: Lasse Gorm Jensen
En intern problemrapport fra NNIT kaster lys over, hvad der gik galt med den sikkerhedsløsning, som skulle forhindre nedbruddet af det kritiske it-system ved navn NemLog-in.

Tårnhøje temperaturer, kollapsede komponenter og et alarmsystem, der overså advarsler.

Det er forklaringen på, at et stykke kritisk it-infrastruktur kunne gå i sort i over halvanden time, på trods af at systemet var udstyret med et sikkerhedsnet, der netop skulle forhindre nedbrud.

Det viser en intern rapport, betegnet 'fortroligt', fra it-virksomheden NNIT. Rapporten beskriver, hvad det var, der gik galt søndag den 30. juni, da Digitaliseringsstyrelsens offentlige login-portal NemLog-in brød sammen, selvom den var sikret med en failover-løsning.

Version2 har fået aktindsigt i rapporten, hvor det fremgår, at en aktiv, men utilgængelig storage-løsning bevirkede, at failover ikke fungerede korrekt.

Læs også: Grafik: Sådan fejlede failoveren på NemLog-in

Forspillet

Forud for NemLog-ins nedbrud den varme juniaften havde der udspillet sig en kæde af begivenheder, der resulterede i, at den offentlige digitaliseringsløsning crashede, selvom løsningen på papiret burde være sikret med en failover-løsning.

NNIT står for driften af NemLog-in, og til det formål benytter it-virksomheden sig af et datacenter i Ballerup, som er ejet af datacentervirksomheden Interxion.

Om eftermiddagen denne sommersøndag eksploderede en defekt slange i køleanlægget hos Interxions datacenter. Vandet fossede ud af anlægget, der i alt rummede 100 kubikmeter vand, og kølesystemet blev sat ud af drift.

Det førte til, at temperaturerne steg markant i datacentret. I stedet for den normale temperatur på mellem 18 og 27 grader celsius blev der nogle steder målt temperaturer på over 40 grader.

En væsentlig del af datacentrets kunder og deres kritiske it-systemer gik i sort på grund af varmen.

Men hos Digitaliseringsstyrelsen havde man ikke forventet, at varmekollapset i datacentret ville få betydning for NemLog-in. Styrelsen havde nemlig aftalt med leverandøren NNIT, at det kritiske it-system skulle beskyttes af en automatisk failover-løsning.

Det vil sige, at driften af NemLog-in lynhurtigt ville skifte til et andet datacenter end Interxions i Ballerup, hvis der skulle opstå problemer.

Men de høje temperaturer satte også en stopper for, at den automatiske failover på NemLog-in gik i gang.

»Den meget høje temperatur medførte, at NemLog-in3’s (den seneste udgave af NemLog-in, red.) automatiske failover-løsning ikke blev aktiveret,« skriver NNIT i den fortrolige rapport.

Failover fejlede

I NemLog-ins driftsmiljø er alle serverne virtuelle, og de er placeret på fysiske hosts, der er sat op i cluster, som er spejlet mellem Interxions datacenter i Ballerup og et sekundært datacenter. De hosts har forbindelse til storageløsninger via fire SAN-switche.

Hverken host eller storage, der var placeret i Interxions datacenter, gik til at starte med ned på grund af varmen.

Derimod blev fire såkaldte transceivere påvirket af de høje temperaturer. Transceiverne sidder i hver deres SAN-switch, og de udgør en del af forbindelsen mellem host og storage.

De varme temperaturer førte til, at transceiverne i SAN-switchene fejlede, og derfor blev forbindelsen mellem host og storage i det overophedede datacenter afbrudt.

Host-løsningen Interxion registrerede, at der ikke var forbindelse til storage, og dette forårsagede en failover-proces, som førte til, at hosten på det sekundære datacenter blev aktiveret.

Men fordi den primære storage hos Interxions stadig var aktiveret, blev storage i det sekundære datacenter ikke aktiveret. Det bevirkede, at den nyaktiverede host i det sekundære datacenter forgæves forsøgte at få forbindelse via de varmeramte SAN-switche til den stadig aktive storage hos Interxion.

Og da forbindelsen mellem hosten i det sekundære datacenter og storage i primære datacenter gik via de kollapsede transceivere, var der altså ikke hul igennem til storage.

Først da temperaturerne faldt igen hos Interxion, og transceiverne begyndte at fungere igen, kom adgangen til den offentlige del af det digitale Danmark atter på benene.

Hændelsen den lune søndagsaften den 30. juni betød, at NemLog-in var nede i over halvanden time. Ifølge den fortrolige rapport fra NNIT startede nedbruddet klokken 22.23 og sluttede klokken 23.05.

Storage kan ikke tjekke forbindelsen

Version2 har været i løbende kontakt med NNIT's pressekontakt omkring sagen. NNIT er blevet forelagt Version2 beskrivelse af forløbet, som it-virksomheden efterfølgende har bekræftet.

I et mailsvar til Version2 erkender NNIT, at det manglende skift fra den primære til den sekundære storage har haft stor betydning for nedbruddet af det kritiske it-system NemLog-in.

Hvis storage-systemet i det sekundære datacenter havde sat ind i failoveren, hvor lang tid havde man da kunne risikere?

»Ingen, idet teknikken under normale omstændigheder ville have foretaget failover,« skriver NNITs pressekontakt i en mail til Version2.

Version2 har også spurgt, hvorfor den primære storage i Interxions varme datacenter ikke registrerede og meddelte, at al forbindelse til den var røget på grund af de svigtende transceivere, og at der derfor var behov for at aktivere den sekundære storage i det andet datacenter.

»Grundet protokollen har storage som udgangspunkt ikke mulighed for at verificere forbindelse opad i stakken, hvorimod hosts har mulighed for at verificere, om der kommer svar på forespørgsler, der sendes ned mod storage,« skriver NNIT's pressekontakt i mailen.

Kan ske igen

It-virksomheden forklarer videre, at man i kølvandet på hændelsen har »defineret en række præventive aktioner«, som vil blive drøftet med Digitaliseringsstyrelsen, der er kunden.

Men selvom de nye sikkerhedsforanstaltninger bliver sat i værk, vil de »præventive aktioner« ikke endegyldigt forhindre, at en lignende situation opstår en anden gang.

»En risiko for gentagelse er til stede, men må anses for betydelig reduceret ved effektuering af de præventive aktioner,« står der i rapporten.

Version2 har efterfølgende spurgt, hvorfor protokollen forhindrer, at storage har mulighed for at verificere forbindelsen. Derudover har vi spurgt, hvor mange systemer der i øjeblikket kører med en identisk failover-opsætning hos NNIT, samt hvilke »præventive aktioner« man helt konkret har fundet frem til for at forhindre, at der sker lignende hændelser i fremtiden.

NNIT er ikke vendt tilbage med svar inden redaktionens deadline.

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

Lader til at de har glemt stonith. Da disk performance må formodes at være væsentligt hurtigere såfremt, det sker lokalt, burde enhver failover af henholdsvis host eller storage automatisk medføre failover af ditto host eller storage, og som sidste udvej via stonith.

  • 7
  • 0
Axel Nielsen

Hvis ikke systemet (NemLogin server) er klar over at en fejl er opstået "udenfor" systemet (I dette tilfælde i datacentret), så kan det være svært at reagere før fejlen påvirker systemet i kritisk grad og dermed umuliggør funktionel failover.

En kritisk fejl som et stoppet kølesystem burde på en eller anden måde resultere i at samtlige kunder i datacentret fik besked (system) så de kunne reagere hensigtsmæssigt (safe shutdown, failover, etc) INDEN centret bryder sammen pga. varmen.

  • 6
  • 0
Mogens Lysemose

Umiddelbart giver grafen jo indtryk af de har beskyttet sig mod single points of failure og det er jo godt.
Men når man så læser forklaringen lyder det som om Storage er single point of failure alligevel, hvis den som her selv tror den har det godt men ikke har forbindelse til nogen hosts...
Det undrer hvorfor det ikke er opdaget ved tests hvor forbindelsen mellem hosts og storage fjernes.
Det er da uheldigt at der faktisk er failover men at nye hosts opgiver når de ikke kan nå utilgængelig Storage i det oprindelige center. Mon ikke det kunne løses teknisk.

PS V2: i har byttet om på start og sluttid :)

  • 4
  • 0
Henrik Madsen

Umiddelbart giver grafen jo indtryk af de har beskyttet sig mod single points of failure og det er jo godt.
Men når man så læser forklaringen lyder det som om Storage er single point of failure alligevel, hvis den som her selv tror den har det godt men ikke har forbindelse til nogen hosts...

Man må da vist også konkludere at køleanlægget er et "single point of failure"

Det lader jo til at der kun er een streng på det køleanlæg. Måske det havde været mere sikkert at købe 2 køleanlæg som var halvt så store i det jeg antager at "halv kraft" er meget bedre end "nul kraft"

I den ideelle verden købte man selvfølgelig 2 køleanlæg som hver for sig var store nok til at køle lokationen og så lod dem køre på skift en uge af gangen og med en aftale om få timers responstid, hvis et af anlæggene gik i stykker, samt automatisk failover til det andet system i tilfælde af svigt på det kørende system.

  • 1
  • 0
Morten Birkelund

Skal det laves helt optimalt snakker vi 2 køleanlæg begge på over dobbelt kapacitet af hvad det normale daglige behov er så de begge er aktive samtidig og begge kan håndtere alt kølebehov alene. Der skal så også være køleunits nok inde i datacenteret til at man kan tåle at tabe alle dem som er kablet på et køleanlæg. Og selv med dette setup vil man opleve at begge køleanlæg fejler samtidig, da det typisk er udefra kommende faktore som vejret der driller.

Det kan dog blive voldsomt dyrt at prøve at sikre noget 100% og så kan der stadig lande en meteor i det.

Jeg tvivler også på at de bliver ramt af samme problem igen, da de nu er blevet opmærksomme på at det kan ske og nok har taget højde for det fremover.

  • 2
  • 0
Axel Nielsen

Den primære fejl ift. NemLogin ligger hos NNIT.

Enhver "service" eller facilitet har i en eller anden grad single-point-of-failure (Meteornedslag f.eks.).

Kunsten er at redelegere behovene indenfor kort tid, når den fungerende facilitet går ned.

I dette tilfælde var redelegering afhængig af funktioner der lå indenfor den crashede facilitet

Uanset hvordan NNIT snor sig, så ligger fejlen ift. til den manglende failover ved dem og ingen andre!

edit: Rettelser

  • 5
  • 0
Victoria Hansen

Det er et helt standard tekst-bog eksempel på hosts (fysiske servere) der er redundant forbundet til et fibre-channel SAN via 2 (eller flere) fibre channel switche.

Pilene er fysiske kabler, typisk fiber.

Det er lidt fortegnet, typisk er det mindst 4 paths til SAN'et, 2 to hver switch.

I et så kritisk setup som deres, ville jeg nok bruge 4 switche i stedet for 2, givent at SAN'et har porte til det.

  • 2
  • 0
Victoria Hansen

Jeg finder det personligt meget underligt at 2-4 transceivere skulle fejle.
Jeg har sådan et setup i mit homelab, og over de sidste 2 somre har der adskillelige gange være over 40 grader i server rummet, og jeg har været oppe og vende ved 47c ambient en håndfuld gange, og serverne begynder at klynke længe inden hverken SAN eller switche gør, og jeg har hverken oplevet fejlede transceivere på 10GbE eller 8Gb FC, til trods for at transceiverene har været godt over 60c, det har kørt rock-solid.

Nogen der kender til fænomenet?

Ydermere, er det på mit SAN, samt SAN switche let at se om der er liv i transceiveren i den anden ende, det kan godt være linket er oppe, men der ikke kommer noget data igennem, men det tænker jeg er en så sær case, at det næppe sker 2-4 gange på én gang.

Noget helt andet er, med en system som aldrig idler, er det jo nemt at se aktiviteten på porten på SAN'et, hvis der ikke er trafik på nogle porte, er der sgu nok noget HELT galt og det burde trigge en warning et sted.

  • 7
  • 0
Baldur Norddahl

Én defekt slange springer og hele InterXion mister al køling.
En enkelt slange lægger centret ned - det kan da kun være Single Point of Failure. Uanset at der var dobbelt op på mange ting så skulle der kun en udløsende årsag til.

Den udløsende årsag var så ikke slangen men et overtryk i systemet forårsaget af problemer med styringen. Slangen springer som følge af overtrykket.

De har mulighed for at lukke af for dele af systemet. Det skete ikke på grund af menneskelige fejl. De kunne ikke følge med alle alarmerne.

Det er sket for faciliteter i meget højere klasse eksempelvis atomkraftværker. Det eneste forsvar er at designe dine systemer, så du ikke er afhængig af én lokation.

  • 2
  • 0
Mogens Lysemose

årsag var så ikke slangen men et overtryk i systemet forårsaget af problemer med styringen. Slangen springer som følge af overtrykket.

Jeg citerer:
https://www.version2.dk/artikel/interxion-direktoer-erkender-mystisk-kol...

Systemet er designet og trykprøvet til at kunne klare ti bar, og hvis trykket overstiger 6 bar, bliver der aktiveret en sikkerhedsventil, som skal forhindre yderligere stigning.

Men det nåede aldrig at ske. Allerede ved 4,8 bar – før sikkerhedsventilen skulle aktiveres – sprang en slange, som indgår i kølesystemet. Ifølge Peder Bank har den været defekt.

»Der var en fejl på slangen, som gjorde, at den kunne springe før sikkerhedsniveauet var nået. Der kom et hul på størrelse med en knytnæve i slangen, og nu har vi pillet den ud. Vi undersøger desuden, hvor den kommer fra, om der er andre af den slags, som skal udskiftes,« siger han.

Du har fuldstændig ret i at trykstigningen udløser problemet, men slangen er problemet: Da trykket er under sikkerhedsgrænsen burde slangen ikke springe.

  • 2
  • 0
Baldur Norddahl

Jeg citerer

Det er fint Mogens men jeg er kunde derude og har fået en noget mere uddybende forklaring. Det er ikke meningen at der skal være 4,8 bar. Det er væsentligt overtryk og det var stigende. Derfor var de allerede overbebyrdet med alarmer og det med slangen kom ind som en lavere prioritet der blev overset.

Man kan sige at ligesom hos NNIT så fejler systemet ikke som designet. I stedet for at en overtryksventil lukker vand ud, så er det en slange der springer. Det gør det sværere for teknikkere som har trænet til et andet scenarie.

  • 2
  • 0
Morten Fordsmand

Er som denne historie altid en sandhed med visse begrænsninger.

Om det så de 102 minutters nede tid er lidt eller meget i en force-majeur skal jeg ikke gøre mig klog på uden at kende mere til systemet, og I hvor høj grad NNIT havde udarbejdet procedure for at sikre driften efter et centertab.

Og husk i øvrigt at et datacenter sagtens kan betragtes som et SPOF, i hvert fald hvis man som jeg tænker i IT Servide Continuity.

  • 0
  • 0
Simon Lodal

Hvorfor opdagede det sekundære datacenter ikke bare at det primære var nede, og overtog hele driften?

Hvis det sekundære ikke overtager før det primære center fortæller at det går skidt, så har man ét stort single point of failure system. Man skal bare trække stikket mellem de to hjernehalvdele, så dør de begge. Er det virkelig sådan det er designet?

  • 3
  • 1
Asger Solvang

Hvorfor opdagede det sekundære datacenter ikke bare at det primære var nede, og overtog hele driften?

Har man automatisk failover er en typisk tilgang til dette at man har en tredie site, der har en slags "Observatør" rolle. De 3 sites kan nu kommunikere med hinanden om hvem der er "i live".

Et forsimplet eksempel er på dette er at falder den primære site ud pga. "hedeslag", så holder den op med at kommunikere med de to andre sites og de kan så blive enige om at aktivere standby siten.

Det er lidt mere kompliceret i virkeligheden. F.eks. behøves man ikke at kunne tale direkte med de 2 andre sites. Hvis man mister forbindelsen til en site kan man alternativt prøve at tale med den via den anden site, hvis denne forbindelse stadig virker.

  • 1
  • 0
Victoria Hansen

Der er varmere på bagsiden af racket end foran ... de 40 grader gætter jeg på var foran .... bagved var der nok væsenligt varmere

Selvfølgelig.
Men det er cold-aisle temperaturen der er vigtig, hot-aisle temperaturen vil altid være i den høje ende.
Og 40c i cold-aisle burde ikke være noget der får transceivere til at fejle (af alle ting), som nævnt har jeg selv "power testet" det, og serverene går ned først (hos mig anyway).

  • 0
  • 0
Jan Heisterberg

Du har vist ikke læst og især forstået mit indlæg, som du øjensynlig tror du besvarer.
Dir svar er korrekt, det havde jeg forstået. Pointen er, at tegningen IKKE illustrerer problemet - som bekendt er det, at fejlsignaler ikke kom frem til de rette komponenter.
Datavejene er irrelevante, når signalvejene fejler OG disse ikke kan benyttes korrekt.

  • 1
  • 1
Log ind eller Opret konto for at kommentere