Skift af SAN-switch førte til nedbrud i visumsystem

Illustration: Statens IT
Opdateret. Visumsystemet VIS database blev ødelagt under et skift af en SAN-switch, og systemet er nu nede på ubestemt tid.

Visumsystemet VIS gik ned i søndags, da Statens IT skulle skifte en SAN-switch - man ved dog endnu ikke præcis, hvad der er gået galt.

»Vi tror, der er opgraderet en firmware, og så er der et eller andet, der der er gået helt galt,« siger Martin Pedersen, der er digitaliserings- og driftchef i Udlændinge-, Integrations og Boligministeriet.

Ét er dog sikkert

»Vi kan konstatere at vores database er ødelagt, og vi ikke kan genskabe den,« siger Martin Pedersen og fortsætter:

»Derfor laver vi en ny tom kopi af databasen og parallelt nogle recovery-forsøg. Så vi arbejder i flere spor på at komme op så hurtigt som muligt.«

Nedbruddet i visumsystemet betyder, at visumbehandling og digital kontrol af visum er sat i stå på ubestemt tid.

Det skriver ministeriet i en pressemeddelelse, hvor de også oplyser, at det derfor ikke er muligt for politiet at gennemføre digital kontrol af visum ved Danmarks ydre Schengengrænser.

Kan udstede visum igen imorgen

I øjeblikket arbejder Martin Pedersen og hans hold som sagt på at genskabe databasen, lige som de parallelt henter backups ind. Dog tror han, at de i løbet af i dag og senest imorgen kan få den tomme kopi af databasen op at køre, som betyder at det igen vil blive muligt for ambassader at udstede visum.

Politiet må dog som sagt vente længere og bruger derfor andre metoder:

»Ved ind- og udrejse af Danmark sker der kontrol af visumpligtige passagerer ved opslag i en række nationale og internationale registre for at undersøge om personen eller passet er efterlyst. På nuværende tidspunkt foretager politiet endvidere en skærpet fysisk kontrol af dokumenternes ægthed og gyldighed.Den skærpede kontrol berører kun passagerer, som behøver visum for at kunne indrejse i Danmark/Schengen-området, og det ventes ikke at give en nævneværdig længere ventetid,« skriver Rigspolitiet.

Der vil løbende blive orienteret om status på visumsagsbehandlingen på nyidanmark.dk.

Sidste nyt

Vi har forsøgt at få svar på nogle af Version2 læsernes spørgsmål blandt andet om, hvilken SAN-switch, man har skiftet, samt hvilken database og hvilken formodet firmware opgradering, der er tale om.

Statens IT kan dog ikke udlevere de tekniske oplysninger af 'sikkerhedsmæssige årsager', skriver de til Version2.

Martin Pedersen kan dog oplyse, at ministeriet ikke havde en spejling af databasen, fordi man er igang med at flytte servere og systemer over i statens IT.

»Vi havde ikke to på grund af transitionen. Vi vil lave lave et spejlet system og det lå i planlægningsprogrammet, så det var uheldigt, at det var lige nu det skete,« forklarer han.

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

...med lidt oplysninger om hvilke switche og hvilket storage og evt. firmware versioner....og hvilken database samt hvorfor det skulle være "umuligt" at genskabe fra backup.

Vi andre opgraderer med jævne mellemrum vores FC switche (og vores storage) og kan have interesse i disse oplysninger.

  • 4
  • 0
Lars Andersen

Ja, det er nærmest en tradition at give SAN skylden, når en eller anden har fumlet. Det har jeg oplevet flere gange...
Man giver den mest "mystiske" komponent skylden, så er der en forklaring, og man kommer videre.
SAN, og så med trumf på "firmware opgradering". Helt sikkert.

  • 9
  • 0
Mads Jakobsen

Jeg forstår ikke hvorfor man som ansvarlig tekniker og myndighed sørger for at have en eller anden afprøvet(!) plan for hvordan man kommer tilbage til en virkende tilstand. Det skriger jo amatørisme det her, og er da så pinligt for landet her.

På grund af det ret lave informationsniveau kan der jo være formildende omstændigheder jeg ikke er klar over, men så er næste kritikpunkt jo bare det ringe informationsniveau.

Mon politkerne og embedsmændende ville acceptere noget lignende hvis det var en ekstern der havde leveret noget tilsvarende. Næppe....

  • 7
  • 0
Jan Christiansen

Billedet indikere da nu meget godt, at systemet er driftet af Statens-it. Så det er nok næppe NNIT som drifter det. Det kan dog godt være udviklingen som NNIT står for.

Ud over det, har jeg ikke hørt om andre systemer driftet af Statens-it skulle være gårt ned, hvilket undre mig.

De fleste ting køres virtuelt, så hvis et system går ned ved en san opgradering, burde der være flere. Men her gætter jeg, da jeg ikke kender det tekniske setup her.

Ang. at have en tilbagerulningsplan. Det er ikke så nemt ved en opgradering af san'et. Hvis der opstår korruption, er det jo alle systemer som ligger på san'et der skal være en plan for, og det kan være ret meget.

Man kan så argumentere for, at bør haven en generel plan for alle systemer, som også er testet. Det er bare ikke en nem opgave, da den involvere at dataejere er med i forløbet. Men jeg er da enige i at det ikke er en valid undskyldning.

Jeg kan bare sige, at når vi beder dataejre hos os om at teste, så er testen meget hurtig og mangelfuld. Det kan resultere i, at fejl først bliver opdaget meget sent, hvor det er umuligt at genskabe data.

  • 3
  • 0
Joe Sørensen

Er dette ikke noget der kan ske ved alle former for storage. Uanset mærke.

Jeg har prøvet noget tilsvarende for 10 år siden. Her måtte vi køre nogle dage på backuppen fordi en RAID controller i SANet korrumperede diskene. Det trak hele skidtet ned. Heldigvis havde vi en ( under 24 timer gammel ) backup af hele SANet på en stor NAS.

Her snakker vi kun om et SAN, med en kapacitet på ca 16TB og 4-5 TB af det på backup NASen, så der var kun tale om et lille SAN. ( Og ret stor NAS ). Jeg ved ikke hvad man gør i dag, hvis en større SAN går ned.

  • 0
  • 0
Jan Svarrer Sølvsten

Kom nu V2! I må virkelig stramme op omkring begreberne - og at læne sig op af Dipeee.com som kilde er lidt tyndt...

Når man taler om et SAN er det UDELUKKENDE transportlaget af data - deraf navnet Storage Area Network - ligesom vi har et LAN, som er et Local Area Network.

Der hvor data gemmes (FYI Joe Sørensen et'al) kaldes et storage system, som kan være forbundet til at SAN via FC (Fibre Channel) eller til et LAN - disse storagesystemer kaldes typisk for NAS (Network Accessed Storage). De 2 store forskelle på de to er:

1) SAN transporterer såkaldte block-level devices uden filstruktur intelligens - denne ligger i serveren.
2) Ved NAS storage ligger filsystem intelligensen i selve NAS storage systemet.

Det er forresten ikke NNIT der drifter infrastrukturen hos SI - Så at skyde på dem er lidt for nemt.

  • 2
  • 0
Joe Sørensen

Tak for rettelsen. Det var selvfølgelig en RAID kontroller i et af vores SAN tilsluttede storage enheder. Og teknisk set gik SANet heller ikke ned. Den korrumperede data så vi tog alle servere af den.

Der er IMHO meget Forvirringen omkring SAN. Derfor er jeg interesseret i at høre detaljerede war stories om emnet som fx denne. Det er tit at jeg høre fra andre virksomheder, tit kommunale virksomheder, at de intet har kunnet udfører på en arbejdsdag fordi SANet har været nede, igen. Og som it kyndig tænker man: Gad vide hvad det SAN nu fik skylden for.

Jeg kan forestille mig at SI folkene har stået med samme symptomer, som vi havde dengang vi havde det nedbrud. Vi bemærkede at vi havde korrupte data på flere forskellige LUNs. De var opstået samme dag ( håbede vi! ). Vi kendte ikke til omfanget af problemet. Vi kunne ikke udelukke at det skete på alle LUNs. Men der var ikke nogen røde lamper, ud over at programmer ikke kunne læse de data den selv havde skrevet.

Det startede selvfølgelig med at en enkelt database instans begyndte at snakke om checksum fejl. Før man finder årsagen til dette, sker det igen for en anden database. Vi kørte et check program, som finder at ingen database instanser kunne parse sine binlog filer. Og så begyndte panikken at sprede sig.

Løsningen blev at vi tog alle servere af SANet ( ved at pille begge netkabler ud hele vejen ned ), fordi så var der i hvert fald ikke mere der blev ødelagt. Vi havde en NAS ( som faktisk er en Intel baseret server med lokal storage, så det skal jeg nok ikke kalde den ). Dens primære opgave var at hente data fra snapshots fra flere forskellige LUNs. Den sørger for inkrementel backup, upload til remote backup og duplikering. Men i vores procedure for situationer som denne, udnyttede vi at den indeholder den nyeste kopi af alle data. Vi får serverne til at mount'e den rigtige mappe via NFS og et par tricks. Så nu er der noget der kører. Dog med dag gamle data.

Inden vi fandt årsagen, havde vi en del mistanke til switche. Og kabling. Vi brugte iSCSI og derfor Ethernet i SANet. Men det vidste sig at kabling og switche ikke var en del af problemet. Vi havde også en mistanke til at det var den software der styrer og overvåger SAN løsningen. Vi intet om hvad denne software faktisk lavede, eller kunne. Altså ud over at definerer LUNs. Og det ved jeg sådan set stadig ikke.

Det viser sig, at det er alle diske, der sidder på en og samme RAID controller som nogen gange skriver forkert. Faktisk fejler de individuelle diske ikke noget, det var "bare" controlleren. Den sendte simpelthen de forkerte adresser til disken, så den rigtige data en gang imellem havnede det falske sted. Det var sådan at alle LUNs der holder data fra database serverne havde spredt sig lige over alle næsten alle fysiske diske. Dermed hurtigere performance. Så selv om det kun er 6 SAS diske der skriver forkert, så går det ud over alle database instanserne. De opdager det bare ikke, fordi næsten al data er i ram på serverne. Så ved normal drift er databaserne næsten write only.

Og hvad lærte jeg så af det. Tjo, jeg fandt ud af at det ikke kun er database softwaren der cacher. Der er også cache i storage enhederne, igen på selve RAID controllerne inde i storage enhederne og også på selve SAS disken. Men jeg lærte også at det er fedt at have en lød procedure klar, som ikke betyder at du skal flytte TB-vis af data.

Hvis du har læst her til, må du også være interesseret i war stories. :-) Har du selv en storage war story at dele?

  • 5
  • 0
Peter Vangsgaard

Inden man går igang med at pille ved storage bør man tage nogle forholdsregler så man hurtigt kan komme i prod igen, om det er at have en slave eller bare en anden form for backup, det er underordnet, det er tiden for hvor hurtigt systemet er tilgængeligt igen der er kritisk.

  • 2
  • 0
Jimmy Christiansen

Inden man går igang med at pille ved storage bør man tage nogle forholdsregler så man hurtigt kan komme i prod igen, om det er at have en slave eller bare en anden form for backup, det er underordnet, det er tiden for hvor hurtigt systemet er tilgængeligt igen der er kritisk.


Og test derefter regelmæssigt at recovery fra backup rent faktisk virker.

På samme måde som man tester at ens UPS virker. Og rent faktisk stadig har den kapacitet der skal til for at lukke systemerne rent ned/nødgenerator starter.

  • 0
  • 0
Bent Jensen

Backup er ikke nok, en versionskontrol med mulighed for tilbage rulldning er også vigtigt. Det er backup hvis den gemmes løbende som en dag, uge, månede og år.
Ellers risikere man som her at have en backup med krypteret eller korupte data.

Dropbox er et fint eksempel på dette. og hvorfor de også har mindre plads, og er noget dyre end konkuranterne.

Backup af gamle og store data mægter. Versionkontrol og løben backup af det man arbejder i.

  • 0
  • 0
Christian Kraft

Ok, hvad skete der med opsøgende journalistik her, eller missede jeg en nye historie? Troede man på at de ville have systemet oppe at køre dagen efter? Faktum er dog at systemet stadigt, efter nu 15 dage, stadigt er nede. Kan "berolige" alle med at de fra Statens IT STADIGT siger at systemet burde virke i morgen, det var så igår...
I al fald er nu mindst 4000 ramt af nedbruddet og systemet er stadigt ikke oppe at køre, bl.a. fordi, som flere allerede spåede tidligt, at backuppen ikke virkede.
Mit gæt er over titusinde allerede er påvirket, da selv hvis systemet skulle komme op at køre idag, så kan de ikke nå at fjerne puklen af ansøgninger (inklusiv den ansøgning fra min egen asiatiske kæreste igennem 6 år, og som vi indleverede for fem uger siden, den normale tid er 3 uger men vi burde rejse om 6 dage, og systemet er stadigt nede som sagt). Dertil skal vi så addere de tusinder som har klargjort de faktisk hundredevis af nødvendige papirer som skal til for et visum, og som de seneste uger er taget, mange gange fra fjernt og evt andre lande, til en dansk ambassade for at finde ud af at de sågar end ikke kunne indgive deres visumansøgning. Kontorerne har været lukkede i mindst to uger! De 4000 handler KUN om dem der er i systemet allerede men da kndleveringskontorerne har været lukket de sidste 2 uger oven i købet, så er tallet mindst det dobbelte). Vi taler dermed givetvis om over 10.000 turister, forretningsrejsende, kærester og koner til danske statsborgere som ikke kan rejse til danmark denne sommer. Ifølge kilder så har man omkring 124.000 visum ansøgninger årligt, og da dem som indgav en ansøgning for uger siden ikke får visum og da de ikke 5 uger efter tager ansøgninger ind fra nye rejsende (so. Måske skal rejse om en måned), så er tallet 4000 ikke gyldigt...
Dette betyder store udgifter for de rejsende, da man først skal have en flybillet, Forsikring, hoteller, visagebyr m.m inden man overhovedet kan ansøge om visum, så vi snakker allerede om hundrede af millioner af kroner som er tabt af de rejsende (kunderne), og hvad vi, dette gøre for de rejsendes lyst til nogensinde at komme til danmark? Men det betyder også tab for turismen og erhvervslivet i danmark, her skal der beregninger som jeg ikke kan lave for at finde ud af hvad det fx koster for fx turismen og erhvervslivet i danmark at der kommer til at mangle omkring 10000 personer der kunne have brugt penge i danmark eller som måske skulle have været til vigtige møder. I mit private tilfælde så betyder det at vi med meget stor sandsynlig ikke kommer til danmark i år et perspnligt tab på omkring 20.000 kroner, gang det op med sikkert 10.000 berørte, og her taler vi tabet alene for "kunderne". Læg dertil manglende møder i erhvervslivet og hvad de rejsende ville have lagt a penge i danmark under deres ophold. Læg endeligt dertil Danmarks "brand" som turistland, hvor mange turister tror i som mister 20.000 kroner i år vil igen vælge danmark som destination? Hvor mange fx kinesiske forretningsmænd som skulle være kommet hertil for vigtige møder eller for at investere i danmark vil nu sende deres fly til et andet land hvor alt stadigt virker? Naturligvis umuligt at beregne konsekvensen af dette nedbrud, men det er ikke billigt. Og hvad er så svaret fra myndighederne og de ansvarlige. Stilhed. Seneste opdatering fra fx stort set alle danske ambassader er nu to uger gammel, ligesom dette indlæg. Version 2, vågn op, vi taler om en skandale der i værste fald kan koste over en milliard danske kroner, plus et stort stød i Danmarks brand som et land man gider rejse til, og jeg ser INTET her. Intet, jeg savner journalistik i danmark i den skjulte men måske (anden) værste IT skandale i år, men jeg ser stort set intet. De fleste medier har intet haft siden 28/29 april, hvor nogen lovede at problemet var løst i morgen. De lover de stadigt, men intet sker!

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