Kritisk it-infrastruktur gik i sort på trods af failover: Nu skal NNIT betale erstatning

Illustration: Hisam/Bigstock
NNIT skal betale erstatning til Digitaliseringsstyrelsen for ikke at leve op til et krav om oppetider i forbindelse med et datacenter-nedbrud i sommers, der sendte NemLog-in til tælling.

Hvordan kunne et væsentligt it-system gå i sort, selvom det var beskyttet med en sikkerhedsløsning, som netop skulle forhindre nedbrud?

Det spørgsmål har skurret hos Digitaliseringsstyrelsen, siden den offentlige login-portal NemLog-in gik i sort i en længerevarende periode i forbindelse med et datacenter-kollaps i juni måned.

Styrelsen har en aftale med leverandøren NNIT om, at NemLog-in skal beskyttes af en såkaldt failover-løsning. Det er en opsætning, som har til formål at forhindre nedbrud, og den virker ved, at NNIT har to ens driftsmiljøer til NemLog-in, som er placeret i to forskellige datacentre.

Med det sikkerhedsnet på plads havde styrelsen forventet, at NemLog-in kunne køre videre uden problemer på et andet datacenter, da det primære datacenter i Ballerup brød sammen en varm junidag på grund af for høje temperaturer.

Det skete bare ikke. I stedet bragede NemLog-in ned sammen med andre kritiske systemer og var slået omkuld over halvanden time efterfølgende.

Digitaliseringsstyrelsens vicedirektør Adam Lebech har siden undret sig over episoden.

»Da NemLog-in består af redundante driftsmiljøer, havde vi ikke forventet den længerevarende nedetid, vi oplevede på NemLog-in d. 30 juni 2019,« skriver han i en mail til Version2.

Failover burde ikke betyde nedetid

NemLog-in er en del af den offentlige digitale infrastruktur og Digitaliseringsstyrelsen betegner systemet som samfundskritisk infrastruktur. Systemet skal blandt andet sikre, at borgere og medarbejdere har adgang til alle offentlige myndigheders web-løsninger med ét enkelt login.

Ifølge Adam Lebech er formålet med det redundante driftssetup i flere datacentre, at man vil undgå, at såkaldte single point of failures sætter NemLog-in ud af spillet.

»Dette setup har til formål at sikre en høj tilgængelighed på løsningen i tilfælde af fejl, og skal desuden gøre det muligt at foretage failover uden nedetid og uden at overskride servicemål. Digitaliseringsstyrelsen havde derfor ikke forventet en nedetid ved denne type hændelse,« uddyber Adam Lebech i en mail til Version2.

Han tilføjer, at Digitaliseringsstyrelsen på nuværende tidspunkt er i dialog med NNIT omkring forebyggende handlinger og forbedringer, der skal mindske risikoen for, at lignende situationer kan opstå i fremtiden.

Brud på aftale

I kontrakten om NemLog-in har Digitaliseringsstyrelsen sat krav til, hvilke oppetider NNIT skal levere for systemet (se boks).

Disse krav til oppetider levede NNIT ikke op til i juni måned, da NemLog-in gik ned.

»NNIT skal sikre, at NemLog-in er tilgængeligt i henhold til de opsatte krav til driftstid og driftseffektivitet. Da NemLog-in havde en nedetid på 102 minutter den 30. juni, betyder det, at servicemålet omkring driftseffektivitet for juni måned ikke er overholdt,« slår vicedirektør Adam Lebech fast i mailen til Version2.

Fordi NNIT ikke har levet op til de såkaldte servicemål skal it-virksomheden betale kompensation til Digitaliseringsstyrelsen.

Verison2 har søgt aktindsigt hos Digitaliseringsstyrelsen i NNITs driftsrapporter for NemLog-in for at få oplyst, hvor store bodsbeløb, der er tale om. Oplysningerne om netop dette er blevet undtaget fra aktindsigt med henvisning til, at det »kunne skade NNITs virksomhed« at udlevere disse oplysninger.

Version2 har desuden været i løbende kontakt med NNIT i kølvandet på hændelsen, og i en mail til Version2 skriver virksomhedens pressekontakt, at failover-funktionerne trådte i kraft på kundesystemerne i overensstemmelse med det tekniske design.

»Afhængig af kompleksitets på de enkelte løsninger kan failover inkludere en nedetid, det afhænger af løsningens design, for det kan være nødvendigt at foretage kontroller, før failover gennemføres. Disse kontroller kan være nødvendige af hensyn til sikkerheden og for at holde data intakte,« skrive NNITs pressekontakt i en mail til Version2.

I en kommende artikel ser Version2 nærmere på, hvad det helt konkret var, der gjorde, at NemLog-in gik i sort, på trods af at der var opsat en failover-løsning.

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

Afhængig af kompleksitets på de enkelte løsninger kan failover inkludere en nedetid, det afhænger af løsningens design, for det kan være nødvendigt at foretage kontroller, før failover gennemføres.

Systemet var ifølge artiklen nede i halvanden time. Hvis det er forventet pga. kontroller, så er det ikke en failover løsning, nærmere en form for backup. Mere sandsynligt lukker pressekontakten bare varm luft ud og prøver at tegne et mudret billede.

  • 11
  • 0
mikkel Holm

Jeg synes nu mere det er skræmmende at det offentlige vælger kun at købe 99,9-99,5 procent opppetid til et så samfundskritisk system. Så gerne det komme i nærheden af de 5 nines.
Men man får jo ganske vist hvad der betales for - sikkert i dette tilfælde cold failover. Kalkulationen har dog ikke været helt god nok fra NNIT side, men synes nu ikke alene at kritiken kan rettes mod dem.
Hvilken politiker tager nu ansvaret fremadrettet og får forhandlet en bedre oppetid igennem?

  • 3
  • 3
Per Gøtterup

Det kan både gøres billigt og helt fuldautomatisk uden nedetid med et anstændigt design.

Jeg har efterhånden designet og implementeret et utal af løsninger med brug af CARP/pfsync under OpenBSD/FreeBSD hvor failover på tværs af datacentre kan ske helt uden så meget som det mindste pakketab. Brugere kan opleve at skulle logge ind igen, men ellers opdager de intet. Løsningen bør gemme data lokalt og synkronisere når alt er oppe igen.

Selv en relativt svag server (en i hvert datacenter) kan trække løsningen og OpenBSD/FreeBSD er gratis.

Mere om CARP her: https://www.openbsd.org/faq/pf/carp.html

  • 10
  • 3
Anne-Marie Krogsbøll

"Amatører": Hvis det er konklussionen, er det en alvorlig sag, for NNIT har så vidgt jeg ved også en afgørende rolle ift. Sundhedsplatformen. Ikke rart at tænke på, hvis den drives af amatører. Måske er der grundlag for en ekstra nøje gennemgang af, om noget lignende kunne ske i SP?

  • 1
  • 1
Mogens Lysemose

Begge centre i en failover løsning bør ikke være igang samtidigt - ideen med failover er vel netop et brugssystem og et standby system

Jeg har hørt om NNIT-designede løsninger hvor man kører halvdelen af services i hvert center, og ved failover overtager det center der er i luften så den halvdel fra det center der er nede.

Der er eksempler på løsning der kræver manuel "fallback", altså at man flytter de 50% tilbage, og det ikke sker automatisk.
Det giver f.eks. problemer ved korte nedbrud i først det ene og så det andet center.

  • 2
  • 0
Kenneth R.B.
  • 0
  • 0
Kenneth R.B.

Tak for svar, Kenneth R.B.

Hvad laver NNIT så?
https://www.version2.dk/artikel/breaking-epic-og-nnit-vinder-milliardsto...

Det kan du se på deres hjemmeside
https://www.nnit.dk/Sider/healthcare.aspx

NNIT er det første selskab, der har arbejdet som underleverandør for Epic ved en Epic-implementering, nærmere betegnet gennemførelsen af den danske Sundhedsplatform; med dybdegående kendskab til det danske sundhedsvæsen kombineret med +25 Epic-certificerede konsulenter, der arbejder som Application Coordinators og Application Managers, er NNIT godt rustet til at understøtte alle Epic-implementeringer. Derudover har NNIT en lang række Epic-certificeringer som står til garanti for, at kunderne kan have tillid til en professionel og stabil implementeringsprocedure. Gennem vores arbejde med Sundhedsplatformen har vi fået unik viden om Epic-implementeringer i en skandinavisk kontekst, set fra såvel kundens som Epics synsvinkel. Læs mere om Epic her.

Her link til, en af mange, artikel om Region Sjællands datacenter:
https://www.version2.dk/artikel/region-sjaelland-bygger-robust-datacente...

  • 0
  • 0
Anne-Marie Krogsbøll

Tak for svar, Kenneth R.B. Det er sikkert min manglende indsigt, der gør det, men åå hvad måde udelukker dine svar, at disse NNIT-problemer også kan være relevante ift. Sundhedsplatformen? Der henvises jo f.eks. direkte til NNIT i dit sidste link om datacentre.

  • 0
  • 2
Simon Mikkelsen

Men ros til digitaliseringsstyrelsen for at lave en kontrakt med bod/erstatning.....det kunne andre lære af

Det kom systemet da ikke til at virke af, så jeg siger stadig de fejlede totalt!

Digitaliseringsstyrelsens opgave var at holde NemId kørende og det skette ikke. At de får nogle penge af en underleverandør er rart for dem, men ikke mere. Bod har ikke vist sig som en ret effektiv metode til at få en leverandør til at gøre noget. Boden bliver inkalkuleret i prisen som en risiko. Er boden for stor byder ingen.

I stedet burde de have insisteret på at få failover testet så man kunne se at det virkede som forventet.

  • 6
  • 0
Maciej Szeliga

...så var problemet hos Interxion at kølingen forsvandt, dermed lukker maskiner, switche og storage tilfældigt og ikke nødvendigvis samtidigt ned og derfor går der kage i failover.
Det er en helt anden situation end når strømmen forsvinder og alt går ned på samme tid.

  • 2
  • 0
Baldur Norddahl

Hvor det er muligt bør man altid køre aktiv-aktiv. Det vil sige begge datacentre skal være i drift med load balancering. Når det ene fejler sker der intet failover, da det andet allerede er aktiv og simpelthen bare begynder at modtage mere trafik.

Systemer der er standby har en tendens til at fejle når der bliver brug for dem. Det gælder uanset om det er servere, nødgenerator eller andet.

Den bedste måde at være sikker på at det fungerer er ved at have det i aktiv drift.

Nem login lyder bestemt som et system der kunne designes redundant uden failover.

  • 4
  • 0
Baldur Norddahl

Så skal man lige huske, at load balanceren skal have failover også!

Nej det kan foregå med BGP og multihoming.

Hvis det er for omfattende, så er der billigere muligheder. Eksempelvis et system der overvåger tilgængeligheden af de første to og opdaterer DNS. Dette system køres fra et tredje sted som kan være en lille VM i skyen.

Du kan også bruge en ekstern load balancering som CloudFront. De klarer igen deres egen redundans med BGP metoden.

  • 0
  • 0
Hans Nielsen

Det er en helt anden situation end når strømmen forsvinder og alt går ned på samme tid.


Men vel stadig en fejl, som man burde have taget reageret på ?

Det kunnel vel lige så godt være et SAN, en Router, eller noget helt 3, som måske fejlet efter en firmwareopdatering.

Advarsler om høje tempertatur jskulle o have givet anledning til at man reageret

Det er godt at de ansvarlige ikke har et job i forsvaret, så var de nok blvet taget på sengen helt bogstaveligt.

  • 0
  • 0
Baldur Norddahl

kun er routeren og ikke loadbalanceren der går ned.
Med mindre du bygger de to sammen i en enhed. Og selv da er man ikke sikker

Kjeld jeg er ikke sikker på hvad du mener med det?

BGP er en protokol din router taler med din udbyders router. Med den kan du annoncere nogle IP adresser til udbyderen. Hvis din router går ned eller din router frivilligt trækker annonceringen, så holder udbyderen straks op med at sende trafik. Din router kan konfigureres til at overvåge server eller load balancer og hvis noget ikke fungerer kan routeren trække annonceringen af IP adresser.

Du kan have routere i flere datacentre der alle annoncere de samme IP adresser. Hvis udbyderen supporter equal cost multipath routing så får du automatisk en primitiv form for load balancering. Og ellers er der andre tricks til samme effekt.

Det kan også være at du tænker på problemet med en server der ikke er gået ned men fejler på anden vis. Det er et problem for alle redundante systemer. Overvågningen skal kunne detektere problemet for at der kan handles på det.

  • 1
  • 0
Baldur Norddahl

Også er vi netop tilbage ved at der skal være failover på load balanceren.

Nej? Hvordan skal det afhjælpe et problem du ikke kan detektere?

Prøv nu at høre her. Metoden kaldes for anycast og bruges af alle de største sites der findes. Nej det kræver ikke redundans på load balancer eller at du overhovedet har en load balancer.

DNS er et eksempel på et system der er fuldt redundant aktiv-aktiv uden load balancer og det skalerer bedre end det meste.

  • 1
  • 0
Kjeld Flarup Christensen

Nej? Hvordan skal det afhjælpe et problem du ikke kan detektere?


Jeg har oplevet anycast in action flere gange. Pisse irriterende af fejlfinde, når det kun er hvert tredje kald der fejler, fordi en ud af tre servere ikke virker korrekt.

Kan man ikke detektere en manglende service, så har man ikke løst problemet godt nok.

Måske går servicen ikke i helt i sort, men der vil være mange som generes.
Og som en krølle på det, så kan der gå lang tid inden fejlen rapporteres fra kunderne, fordi det virker jo en gang i mellem.

  • 0
  • 0
Baldur Norddahl

Kan man ikke detektere en manglende service, så har man ikke løst problemet godt nok.

Ja men det er et problem du altid har når der er mere end en server. Eksempelvis kunne det være at en nem login server altid afviser folk men i øvrigt fungerer samtidig med at de øvrige servere er helt fine. Det er der ingen load balancer eller anden teknologi der fanger.

Hvis din anycast router tillader en server der er defekt, så er det 100% din egen skyld ved mangel på overvågning. Præcis ligesom det vil være hvis du bruger en load balancer.

Hvis du føler dig mere tryg ved en load balancer, så køber du bare sådan en. Mange af dem kan snakke BGP og lave tricket med eller uden en router. Du bliver ved med at skrive at der skal bruges mere end én, og det er sandt, nemlig én per datacenter. Men du har i øvrigt mulighed for at have så mange du lyster. På grund af BGP melder de sig automatisk ind og ud. Der sker en automatisk load balancering af load balancerne på grund af ECMP (slå det op).

  • 2
  • 0
Steffen Carl Jacobsen

Jeg er enig i, at krav om 99,999 % rådighedsgrad er det rigtige, når der er tale om så samfundskritiske systemer. Der er jo ingen, der kan leve med, at samfundskritiske systemer kun holder 99,9 % oppetid. Det svarer en (måske jævnt fordelt) nedetid på næsten 9 timer om året!
Et Tier 4 system holder næsten 99,999 %, men jeg er måske ene om at mene, at det er den rigtige løsning til at opnå ekstremt høj rådighedsgrad. Med et par små ekstra tiltag, kan man også forholdsvis enkelt hente de sidste minutter for at nå 99,999 %.
Et Tier 4 datacenter udelukker jo ikke, at man kan lave SW failover til et andet datacenter, hvis det primære går ned, som man har mulighed for at gøre i Region Nordjylland. Det er bare ekstremt sjældent, at man får brug for det!!!
Jeg hører ofte, at Tier 4 er meget dyrere, så derfor vælges det fra, men det er ikke min erfaring.
Til gengæld betyder kravet i Tier 4 om autonom response ved alle fejl og følgefejl, og hot-hot drift, at man kan sove en hel del roligere med et Tier 4 end med et Tier 1-3 datacenter.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize