Fejlramt loadbalancer sendte NemID til tælling trods redundans

Selvom der bliver anvendt redundans i systemet bag NemID, var det ikke nok til at holde systemet oppe, da en loadbalancer stod af som følge af en softwarefejl.

Det var en netværkskomponent, der 21. oktober lukkede og slukkede for adgangen til det digitale Danmark fra klokken 08.31 om morgenen til klokken 09.45 samme morgen. I dette tidsrum var det ikke muligt at anvende NemID.

Digitaliseringsstyrelsen har nu modtaget en foreløbig redegørelse på baggrund af episoden fra NemID-leverandøren Nets, hvor det fremgår, hvad der foranledigede NemID-nedbruddet.

Det er er endnu uklart, hvad der præcist forårsagede fejlen, men ifølge redegørelsen er der mistanke om, at nedbruddet kan skyldes en softwarefejl i netværkskomponenten, som fordeler trafikken mellem systemerne bag NemID, fortæller Carsten Møller Jensen, vicedirektør i Digitaliseringsstyrelsen.

»Det er en loadbalancer, der er sat op, så selvom der er meget høj belastning, så opleves svartiden lav,« siger han.

Carsten Møller Jensen forklarer, at systemet bag NemID er bygget op med redundans, altså så systemerne kan tage over for hinanden, skulle noget gå galt i det ene system.

»Det er vigtigt at slå fast, at de kritiske komponenter inde i systemerne er dubleret. Så hvis komponenter sætter ud, kan vi skifte over. Det er et redundant system,« siger han.

Læs også: NemID nede: Trafik kommer ikke ind til Nets

Imidlertid er det også loadbalanceren, der fordeler trafikken mellem de redundante systemer. Og da netværkskomponenten blev ramt af fejl, betød det, at trafikken ikke blev videresendt til nogle af de bagvedliggende systemer. Først da det ene system af blev koblet af, kunne borgerne igen koble på banker, offentlige selvbetjeningsløsninger og andre NemID-afhængige tjenester.

»I forbindelse med nedbruddet fejlsøger man og gennemfører en ændring, så al trafikken ryger over på det ene (redundante, red.) system. NemID-systemet er dimensioneret på en sådan måde, at man selv med maksimal belastning kan afvikle det hele på det ene system,« siger Carsten Møller Jensen.

Det er endnu uklart, hvad der skulle have forårsaget softwarefejlen i loadbalanceren. Det skal en nærmere redegørelse opklare, så lignende fejl på den måde også kan undgås, forklarer Carsten Møller Jensen.

Ikke en egentlig backup-løsning

Men selvom der altså er flere bagvedliggende systemer, der kan tage over for hinanden, så den kritiske digitale samfundsstruktur kan holdes flyvende, så kan en fejl i netværket foran systemerne altså stadig medføre nedbrud.

I dag er serverne og systemerne bag NemID etableret på to fysisk adskilte adresser. En måde at gøre løsningen mere fejltolerant på kunne være at opbygge det, Carsten Møller Jensen kalder en ‘egentlig back up-løsning’, som er helt uafhængig af den nuværende løsning, og som der uden videre vil kunne skiftes til, skulle den primære løsning blive ramt af fejl.

»Så er det ikke længere kun et redundant system, men en egentlig backup-løsning. Og sådan en er der ikke i øjeblikket, siger Carsten Møller Jensen og fortsætter:

»Når vi ikke har købt en egentlig backup-løsning, er det, fordi vi sammen med Nets har vurderet, at omkostningen ved at opbygge en backup-løsning vil være så store i forhold til risikoen, at det ikke vil stå mål med nødvendigheden.«

Han henviser i den forbindelse til de nuværende oppetider for NemID, der ligger tæt på 100 pct. Til og med august i år var oppetiden for NemID således på 99,82 pct.

Når det er sagt, anerkender Carsten Møller Jensen også, at NemID - blandt andet i kraft af, at Digital Post er blevet obligatorisk - spiller en stadig større rolle som samfundskritisk infrastruktur. Og dermed er konsekvenserne også større, når systemet var nede i dag, end de var, da systemet blev lanceret.

»Betydningen er så stor i dag, at det er at sidestille med kritisk infrastruktur. Og det er derfor vigtigt, at det har høj oppetid og acceptable svartider,« siger han.

Og derfor er Carsten Møller Jensen heller ikke afvisende over for, at en egentlig backup-løsning kan komme på tale i forhold til NemID's afløser, som Digitaliseringsstyrelsen arbejder med i øjeblikket.

Hvornår danskerne kan forvente at kunne klikke sig rundt i forskudsopgørelsen med NemID 2.0, er dog endnu uvist. Et forsigtigt bud fra Carsten Møller Jensen er 'i slutningen af 2018.'.

Arbejder med bedre kommunikation og ITIL

Digitaliseringsstyrelsen arbejder i øjeblikket med at forbedre effektiviteten og professionaliseringen i it-systemforvaltningen af de fællesoffentlige løsninger, som styrelsen har ansvaret for. I den forbindelse er der også fokus på kommunikationen, når der eksempelvis er nedbrud i NemID-systemet.

Arbejdet med kommunikation er et led i en længerevarende effektiviseringsproces, der blev iværksat i starten af 2015 og er sat til at løbe frem mod slutningen af 2017.

»Noget af det, der er et omdrejningspunktet for effektiviseringsprogrammet for 2015, er kommunikationssiden,« siger Carsten Møller Jensen og fortsætter:

»Det er virkelig afgørende, at vi ved, hvordan vi kører processen, når der faktisk er nedbrud. Både ud mod slutbrugerne, men også ud mod myndigheder og andre, der er afhængige af løsningen.«

Et nedbrud som det, der i oktober ramte NemID, bliver betegnet som 'major incident', fortæller han:

»Vi går ind og vurderer, hvilken betydning den har for de enkelte interessenter, og hvordan vi skal informere dem.«

En af de platforme, Digitaliseringsstyrelsen bruger til at informere om NemID-nedbrud, er digitaliser.dk. Carsten Møller Jensen forklarer, at denne platform står over for en relancering med nyt design, større brugervenlighed og tydeligere driftsinformation for alle de fællesoffentlige systemer. Relanceringen forventes at finde sted i løbet af 2016.

I forbindelse med effektiviseringsarbejdet frem mod slutningen af 2017 har Digitaliseringsstyrelsen også indført processer for ITIL (Information Technology Infrastructure Library). De skal være med til at sikre ensartede arbejdsgange i styrelsen og en bedre udnyttelse af it-ressourcerne, fortæller Carsten Møller Jensen.

Du kan læse mere om Digitaliseringsstyrelsens arbejde med at effektivisere forvaltningen her.

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

der tænker at i skal da også have to load balancere for at kunne kalde det redundant?

Mantraen hedder no single point of failure. Så jeg håber at de også har to routere og to netværksopkoblinger, helst til to uafhængige internet leverandører.

  • 16
  • 0
Svend Nielsen

Er jeg den eneste der tænker at i skal da også have to load balancere for at kunne kalde det redundant?

Jeg tænkte nøjagtig det samme. Det svarer jo til at sige at en bil er redundant i forhold til kørsel fordi den har 4 hjul.

Faktisk er load ballanceren nok mere udsat end de servere den skal fordele trafikken til, så det er helt ubegribeligt at man ikke har gjort den redundant. Det er en ommer - og pinligt er det.

  • 8
  • 0
Danni Lundgren

Jeg er virkelig rystet over, at så vigtig en del af netværket ikke er redundant. Det er jo dybt uacceptabelt, især da redundans og backup er alfa-omega i så stor en netværksstruktur. Når NemID er en så central del af vores samfund, så skal det simpelthen være i orden.

  • 4
  • 0
Christian Nobel

.. hvis man forestillede sig en model, hvor man i stedet havde en ægte digital signatur og brugeren selv havde magten over sin egen nøgle.

Så kunne der være flere uafhængige CA'er, og.....

Nåeh nej, forkert land til den slags drømme.

  • 13
  • 1
Carsten Hahn

Hvis der er to loadbalancers så skal der jo en loadbalancer foran loadbalancerne og så er vi lige vidt.

Loadbalancers (og routere) er tit årsagen til problemer, og grunden er typisk at loadbalancers og routere ofte nægter at fortælle at de har problemer. De er sådan lidt for stolte til at indrømme at de ikke gør deres job ordenligt, og derfor sker der ikke failover til den redundante dims som står lige ved siden af og er klar til at tage over.

  • 5
  • 7
Henrik Madsen

.. hvis man forestillede sig en model, hvor man i stedet havde en ægte digital signatur og brugeren selv havde magten over sin egen nøgle.

Så kunne der være flere uafhængige CA'er, og.....

Nåeh nej, forkert land til den slags drømme.

Er det ikke sådan de har det i Norge.

Er der ikke noget med at i Norge får NemID stryg af konkurrencen fordi NemID er noget skod i forhold til. ?

Derudover ville den løsning du foreslår også have den fordel at den kunne bruges som digital signatur løsning og ikke som idag hvor NemID bruges til digitale underskrifter, selvom den reelt set ikke ER en digital signatur løsning.

Bliver spændende at se hvordan det bliver der i "slutningen af 2018(*)", det kan jo være det bliver så godt at man skal have "NemID" til den tid

(*) I anførselstegn fordi offentlige projekter jo oftest skrider voldsomt i forhold til planen.

  • 5
  • 0
Lars Andersen

Nej, sådan er det ikke. Der findes flere måder at lave renundans, den simpleste måde er at have en failover loadbalancer. Den overvåger den primære, og hvis den er nede, omkonfigurerer den sit netværksinterface, så den modtager data. (Dette bruges i mindre skala linux baserede løsninger)

Man kan også få switche til det, og for mange penge leverer Cisco m.fl avancerede løsninger til formålet.

  • 6
  • 0
Thomas Hedberg

Kan vi ikke snart blive fri for disse indlæg fyldt med gætterier og pegen fingre uden at have skyggen af belæg for det?

Jeg har ikke nogen konkret viden om dette setup, men jeg kan ikke forestille mig at NETS ikke kører med et redundant setup på deres load balancere. Alt andet er utænkeligt.

Men nogle gange sker der bare nogle semi-uforklarlige ting som få er i stand til at forudse og øget kompleksitet i form af redundans i alle led kan nogle gange med til at forstærke det.

Sidste gang jeg selv sad med et besynderligt problem og hvor redundansen fejlede var det servernes indbyggede netkort (broadcom nics) der pludseligt begyndte at oplyse andre mac adresser end dem de var født med og tilmed nogle der tilhørte andre enheder på nettet. Jeg kan godt afsløre at det tog mere end et par minutter at troubleshoote og finde udsagen til fordi det var så langt nede i stakken og bare ikke lige der man kigger først.

Jeg har troubleshootet på clustering software der rev servere ned pga. hukommelses læk, netværks udstyr herunder routere og switches hvor arp tabellen blev korrupt og andre "freak" incidents der rev næsten alt ned. Det er ikke fordi firmaerne ikke havde investeret alt i at være oppe eller folk var dumme, men nogle gange virker IT bare ikke ordenligt.

  • 8
  • 3
Niels Callesøe

Alle systemer kan blive ramt af fejl. Også de mest redundante. Men det er alligevel helt rimeligt at beskæftige sig med om systemet er designet "godt nok".

Hvis der, som det antydes i artiklen, kun er 1 load-balancer til at fordele trafikken over det "redundante" system, så er det ikke redundant. Fordi load-balanceren er et single point of failure, der oven i købet er enkelt at undgå. Hvis det er tilfældet, er det etableret af amatører.

Men da systemets arkitektur ikke er offentlig, er det svært at sige med sikkerhed, ud fra de sparsomme oplysninger i denne artikel.

  • 2
  • 0
Carl-eddy Skovgaard Larsen

Nu er det jo mange år siden, men i 1984-1995 var jeg medansvarlig for det system der styrede Dankortsystemet. Det var en anden tid, men vi havde en ret simpel backupløsning der faktisk virkede.
To computere talte med hinanden på en meget simpel måde 'pinger', og for at pingen kunne genereres skulle der være aktivitet mange steder i systemet.
Hvis backupsystemet ikke fik et 'ping' i 15 sekunder tog det over. Selve swithen mellem de to systemer tog 30-40 sekunder, så det ville give en nedetid på i alt op imod 1. minut.
Selvsagt er et minuts nedetid ikke godt, men i praksis føltes det for kunden blot som en teknisk fejl ved et køb, der så blev gennemført ved næste forsøg.
Det skete omkring 5 gange i løbet af de 10 år systemet kørte 24/7. og virkede hver gang. Blot en ide til noget der virkede allerede for 30 år siden, og IKKE krævede en loadbalancer, men selvsagt var lidt dyrere i hardware.

  • 5
  • 0
Ivo Santos

Et andet ting af vel at stort set alle har glemt den gamle sætning.

"Keep it Simple Stupid"

Uden at kende til deres opsætning, så gætter jeg på at systemerne er fyldt med 'bloatware', og hvad ved jeg, at det vel muligvis kunne være et af årsagerne til deres problemer, og så er designet vel så over kompliceret at det vel også er årsagen, det var den tanke jeg umiddelbart fik efter at have læst artiklen.

  • 0
  • 0
Svend Nielsen
  • 3
  • 0
Baldur Norddahl

Hvis der er to loadbalancers så skal der jo en loadbalancer foran loadbalancerne og så er vi lige vidt.

Ud over det der allerede er nævnt, så kan man gøre brug af ECMP (Equal Cost Multi Path) routing. Dine routere fordeler simpelthen trafikken mellem dine load balancere. Og de gør det på en måde så at alle pakker fra en TCP forbindelse havner på samme load balancer. Det er stateless og kan performe i terabit klassen.

Hvis routerne og load balancerne bruger BFD eller tilsvarende fejldetekteringsprotokol, så kan et sådant setup have failover på 50 ms eller mindre. Og det er active-active så i normal drift har du ikke noget dyrt hardware til at stå og lave ingenting.

Hvis routerne kan fungere som en load balancer, behøver man så en load balancer? Næh i mange tilfælde kan man klare sig uden. Man skal bare have noget godt overvågning, så at en dårlig node kan blive sparket ud hurtigt. Men den hemmelighed hører du ikke fra sælgeren af hundedyre load balancer løsninger :-)

Man kan få en switch med 24x 10G og 4x 40G for cirka 30.000 og med support for ECMP. To af dem og du burde være mere end godt kørende. Hvis du blot skal levere trafik i 1G klassen, så kan man også få switche til under 10.000 der kan det samme.

  • 12
  • 0
Erik Jensen

Uha nej. Round Robin DNS er noget snot at bruge i et så vigtigt system. Det er i dag ikke værd at bruge, i gamle dage måske som en "fattigmands loadbalancer", men I dag ville man f.eks. bruge HAProxy med Heartbeat.
Problemet med "round robin DNS" er at ikke alle overholder TTL på din DNS, hverken DNS servere eller klienter. Selv om du har sat en lav TTL har nogen bevist i tidens løb lavet en override for at optimere deres DNS servere.
Der bliver ved med at komme trafik til den forkerte node rigtig lang tid efter TTL er udløbet.
Kan overhovedet ikke anbefales.

  • 6
  • 0
Martin Larsen

Det er rigtigt at DNS Round Robin ikke er perfekt og der er muligvis bedre løsninger. Jeg argumentere også kun for at bruge det til at route mellem 2 eller flere load balancers.

Det jeg mener er at det er en lavpraktisk (og stort set gratis) løsning som havde virket for 97-99% af brugerne i den ene times nedetid de har haft. Og så er den født redundant. Nogle gange forsøger vi at løse problemer ved at kaste yderligere kompleksitet efter det. Problemet er bare at den kompleksitet ofte skaber nye problemer. Der er også software de switche som også kan fejle, og software på load balanceren med failover fejler også. DNS har ikke det problem da det er distribueret, afprøvet og simpelt, og jeg vil derfor stadig se det som en god måde at route trafik mellem 2 eller flere isolerede setups. Hvis i kigger lidt på de cloud applikationer der bliver designet nu, så benytter mange DNS til at distribuere load og lave fejltolerence.

Tradeoffs er helt rigtigt at der havde været en lille procentdel hvor det ikke vil virke, og der er selvfølgelig noget tid før det reagere.

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