Læs KMD's forklaring på tab af Roskildes 82.000 filer: Hardwarefejl ramte 107 servere

30. maj 2018 kl. 10:2332
Læs KMD's forklaring på tab af Roskildes 82.000 filer: Hardwarefejl ramte 107 servere
Illustration: KMD.
107 servere blev ramt af den hardwarefejl, der store bededag kostede Roskilde Kommune seks års dokumenter. Version2 har fået KMD's interne redegørelse for forløbet.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

»2 Hitachi 10k RPM SAS diskdrev gik fredag den 27. april kl. ca. 03.30 offline med 4 minutters mellemrum. Den første disk melder uoprettelig fejl, og kort tid herefter melder den disk, der burde kunne overtage automatisk, ligeledes fejl.«

Et nedbrud hos KMD kostede store bededag Roskilde Kommune mere end 82.000 filer knyttet til borgernes sager med det offentlige, og i en intern redegørelse, som Version2 har fået aktindsigt i, forklarer KMD de tekniske årsager.

»Hitachi storage-systemet er derfor ude af stand til at genbygge paritet og opretholde driften. Raid 5 diskgruppen crasher dermed, og efterfølgende sætter SVC00002 storage controlleren hele storage gruppen offline, hvilket resulterer i, at 107 servere mister forbindelsen til deres diskdrev. Af disse 107 servere er 3 af dem Roskilde Kommunes KMD Care servere.«

Som Version2 tidligere har beskrevet, havde nedbruddet kun konsekvenser for Roskilde Kommune, der som eneste kunde ikke kunne få genskabt sine data.

Artiklen fortsætter efter annoncen

Det skyldes forkert kodning af et skræddersyet backup-setup, der betød, at Roskilde Kommunes filer blev opbevaret permanent i en temporær folder, hvorfra der også skulle tages backup. Det strider dog mod KMD's standardprocedure, og derfor skete det aldrig.

»KMD foretager backup af alle kørende Care-servere. Standardpolitikken for backup er at ekskludere temporære foldere, idet disse har karakter af foldere, hvor dokumenter kun befinder sig kortvarigt, eller foldere, som tømmes jævnligt, fx dagligt,« hedder det i redegørelsen.

KMD har dog taget sagen til efterretning og sørget for, at Roskilde kan få genskabt data ved et lignende nedbrud.

»Den temporære folder er blevet omdøbt, således at den ikke er omfattet af standard backup-politikken om eksklusion af temporære folder. Backup er idriftsat og testet – både for validitet og indhold,« hedder det i redegørelsen fra KMD til Roskilde Kommune.

På trods af en udførlig beskrivelse af den fejlslagne backup fortæller den fem sider lange redegørelse dog intet om, hvorfor de to diskdrev gik offline 27. april, hvilket er årsagen til at den ikke-fungerende backup blev nødvendig.

32 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
32
31. maj 2018 kl. 13:46

@Mogens Lysemose

En hotspare disk er en disk der ikke er en del af det Raid sæt hvor data ligger.

Det er en tom disk der er allokeret til at gå ind og overtage for en disk der dør i en eller flere Raid sæt på din storage løsning.

Derfor er forklaringen KMD er kommet med også ret tydeligvis skrevet af en der enten ikke er teknisk velfunderet da et Raid 5 fint kører videre med en død disk og en fejl på den disk der er ved at køre rebuild ,alternativt er det et forsøg på at skjule det faktiske forløb.

31
31. maj 2018 kl. 13:40

Mange glemmer at RAID5 o.lign. "kun" beskytter mod disknedbrud. RAID-controlleren og SAN-systemet kan derfor sagtens være "single point of failure". I stedet for at beskytte sig mod at en eller to diske bryder ned, var det endnu bedre at beskytte alle single points of failure; Den dyre løsning kunne være et spejlet SAN på forskelige lokaliteter. Det beskytter mod de fleste nedbrud, f.eks. hardware defekt internt i SAN, elektrisk overspænding eller underspænding (sker alt for ofte), lyn, brand osv. Men så skal SAN altså også have redundante netforbindelser osv.

28
30. maj 2018 kl. 23:28

Kan du ikke lige uddybe hvordan det kan lade sig gøre, at RAID 10 overlever at to diske dør, hvis det er sat op med 4 diske? (Hvis der er flere diske end to hver gruppe, så bliver det ikke særlig pladseffektivt).

Visse producenter (Compellent) har lavet en løsning hvor der bliver skrevet 2 kopier af data i raid 10, det koster lidt ekstra plads men giver lidt ekstra sikkerhed.

--  Single-redundant: Protects against the loss of any one drive. Single-redundant tiers can contain any of the following types of RAID storage:

  • RAID 10 (each disk is mirrored)
  • RAID 5-5 (striped across 5 disks)
  • RAID 5-9 (striped across 9 disks)  Dual-redundant: Protects against the loss of any two disks. HDDs larger than 1.9TB should use dual redundancy, and in some cases it is mandated. Dual-redundant tiers can contain any of the following types of RAID storage:
  • RAID 10 dual mirror (data is written simultaneously to three separate disks)
  • RAID 6-6 (4 data segments, 2 parity segments for each stripe)
  • RAID 6-10 (8 data segments, 2 parity segments for each stripe) --

Hvis du vil læse mere står der mere info omkring deres raid her:https://en.community.dell.com/cfs-file/_key/telligent-evolution-components-attachments/13-4491-00-00-20-44-20-59/Understanding_2D00_RAID_2D00_with_2D00_SC_2D00_Series_2D00_Storage_2D00_Dell_2D00_2016_2D002800_3104_2D00_CD_2D00_DS_2900.pdf?forcedownload=true

27
30. maj 2018 kl. 22:51

Punktum.

Raid levere falsk tryghed, og er ofte mere medvirkende til fejl, end de reder.

Raid er ikke backup.

26
30. maj 2018 kl. 22:44

Det vil sige på et RAID 5 fejl en disk, Hotsparen tager over og fejler så.
Men det vil sige at RAID 5 forsat er drift men bare degraderet og hvad så, eller betyder det at en disk fejl under genskabelse af hotspare og blot journalisten har været upræcis med formuleringen.

En disk fejler. Systemet begynder at genopbygge indholdet på en hot spare. Inden processen er færdig, så fejler endnu en disk. Det er ikke hot spare der fejler.

Det er ikke ualmindeligt på grund af det ekstra load genopbygning medfører.

RAID 6 ville have redet situationen da forskellen til RAID 5 er at førstnævnte kan klare to samtidige fejl. Man skal bare huske at det er en afvejning af omkostninger. Hele systemet kan stå af på grund af lynnedslag, brand, vandskade, hardware eller software fejl, svigt af køleanlæg, strømafbrydelse, sabotage etc, og hvornår er det mere sandsynligt end at X diske står af?

Den egentlige fejl her er at backuppen ikke er blevet testet tilstrækkeligt.

25
30. maj 2018 kl. 22:18

Personligt bruger jeg altid RAID 6 eller RAID 10 DM altså begge noget som kan tåle at der dør 2 diske.

Kan du ikke lige uddybe hvordan det kan lade sig gøre, at RAID 10 overlever at to diske dør, hvis det er sat op med 4 diske? (Hvis der er flere diske end to hver gruppe, så bliver det ikke særlig pladseffektivt).

Hvis begge diskene der dør er i den samme RAID 1, så dør den, og så falder hele RAID 0'en fra hinanden. Med mindre jeg har misforstået det fuldstændigt.

24
30. maj 2018 kl. 22:05

Hvis der skal ske en fejl som rammer på RAID 5 så er det endnu en disk i gruppen og ikke hotspare disken som skal fejle, hvis hotspare disken fejler under genopbygning så vil systemet bare tage en anden hotspare disk og bygge op på den.

23
30. maj 2018 kl. 21:57

Hvis der er tale om at backup systemet ikke virkede da det brugte procedurer som ikke var godkendt af KMD, så kan jeg ikke se hvordan det kan have være testet.

Kan Version2 bekræfte om der er blevet lavet restore tests af backup systemet?

Hvis der har været lavet recovery tests kan jeg forestille mig at det skyldes at servicen er blivet flyttet, og at man gik ud fra at beckup systemet stadig virkede. Er det mon tilfældet?

22
30. maj 2018 kl. 21:37

Forskellen på RAID 5 og RAID 6 er netop at RAID 6 kan tåle at tabe 2 diske.

Personligt bruger jeg altid RAID 6 eller RAID 10 DM altså begge noget som kan tåle at der dør 2 diske.

21
30. maj 2018 kl. 18:02

Der er en ting jeg ikke forstår i kommentarsporet. Der står følgende: Den første disk melder uoprettelig fejl, og kort tid herefter melder den disk, der burde kunne overtage automatisk, ligeledes fejl

Det vil sige på et RAID 5 fejl en disk, Hotsparen tager over og fejler så. Men det vil sige at RAID 5 forsat er drift men bare degraderet og hvad så, eller betyder det at en disk fejl under genskabelse af hotspare og blot journalisten har været upræcis med formuleringen.

Men ja ved rebuild tider over 1-2 time bør man have RAID6, da 2 times MAX belastning kan rive andre med i graven, når de har nået en hvis alder. For mig er det mere ufatteligt at man har tilladt et sådan design. Angående batch. De der køber tryghed ved at lave en total support aftale havner jo i denne situation da de ingen kontrol har med hvad der gøres med SAN'et og det opdager man jo først den dag alt er galt.

20
30. maj 2018 kl. 17:52

Du køber en server der er designet til det typiske formål, driftstabilitet. Hver producent har sin udgave af firmwares der ikke nødvendigvis spiller fint sammen med andre producenters (bugs), selvom en række standarder skal overholdes. Du sætter ganske givent stabilitet over styr, når to eller flere producenter har været inde over. Ligeledes kan du eksempelvis tage HP's ILO der kan advare i god tid ved mulig harddisk nedbrud, men gøres kun fordi du sætter en HP harddisk i. HP nægter også at supportere systemer/delkomponenter, der ikke er deres egne. Hvilket er fuldt forståeligt - de aner ikke hvad der er programmeret i firmwaren.

Flere forskellige batch mindsker ikke nødvendigvis, kan omvendt gøre det værre. Typisk virker et batch eller ej. Derfor et total system nedbrud - restores fra backup; eller pletvis nedbrud der kan forplante sig til mange systemer med mix af batch. Personligt har jeg selv haft et batch hvor 3 ud af 4 døde, mens andre batch 2-4 bare køre der ud af.

19
30. maj 2018 kl. 17:16

"Kørte systemet med samme batch af diske/producent?" Da 107 servere gik ned, har det været afviklet på et SAN. Fx et HDS san. HDS leverer således SAN'et og diske - her vælger du ikke selv. Til gengæld giver, afhængig af aftale, leverer SAN leverandør typisk en oppetidskontrakt og tager det ret seriøst.

Med dobbelt diskfejl redder hverken RAID5 eller RAID6 dig.

18
30. maj 2018 kl. 16:04

Er det kun mig der syntes det er dybt uprofessionelt at to diske, kan give mere end et-hundrede-og-syv servere problemer? Hvor (måske flere) Roskilde kommune mistede 82.000+ filer.

Hvordan kan man dog have et system der er så dårligt til at rede sig selv, og hvordan kan man dog finde på at koble mere end 100+ servere op imod det.

Jeg vil stadig MEGET gerne se et diagram over hvordan dette "backup" system er designet og tiltænkt.

17
30. maj 2018 kl. 16:01

For mig er det uprfessionelt at begynde at blande forskellige harddisk producenter i en server. Der holder man sig til producentens muligheder. Du betaler typisk ekstra for harddisk firmwaren, men så er du også sikker på det spiller sammen. Har du tiden, kan du godt købe forskellige batch, selvom det ikke giver meget mening. Hvad gør det hvis du først køber 3 diske, derefter 2 og det er de sidste 2 der ryger i RAID5. Så er systemet utilgængeligt alligevel.

Hvad består det uprofessionelle i? ikke at være loyal over for producenten? Hvad er det specifikt at en given firmware i samme kaliber diske fra forskellige producenter gør at man skal holde sig til samme producent?

I min tid med drift af hardware(20+år) og det står helt for min egen regning har jeg endnu til gode at opleve noget negativt ved netop at blande producenterne i samme boks.

Forskellige batches produceret på forskellige tidspunkter mindsker ganske simpelt din risiko for fejl på hardwaren, big numbers game, ganske simpelt.

Men ville nu aldrig køre Raid 5 af netop den årsag at risikoen for et dødt system ved en død disk der tage en anden disk med i faldet under restore er alt for stor.

15
30. maj 2018 kl. 14:48

fakta: diskfejl sker tit; fakta: dobbelt diskfejl sker ikke sjældent, de er ofte forårsaget af én disks fejlen, som sker tit,

Jep. En klassiker er, at det ekstra load fra resilvering efter første nedbrud får den næste disk til at brænde af.

På trods af en udførlig beskrivelse af den fejlslagne backup, fortæller den fem sider lange redegørelse dog intet om, hvorfor de to diskdrev gik offline 27. april.

Der er ikke er noget specielt i, at to diske brænder af samtidigt. Det sker altså i den virkelige verden, og ofte giver det ikke mening, at betale for yderligere redundans, når der er tale om ikke-kritiske systemer.

Disse diske består af metal-skiver, der snurrer rundt med 167 omdrejninger per sekund tætskrevet med data, mens skrivehoveder konstant raser frem og tilbage henover dem. De kører i årevis med temperaturer der svinger i takt med load, en mere eller mindre stabil strømforsyning, diverse smårystelser og accelerationer og decelerationer når de starter og stopper. Stålkassen udenom skal skærme for skiftende lufttryk, krybestrømme, magnetfelter og soniske luftbølger.

Det er et udtryk for fantastisk ingeniørarbejde at diske holder mer end en enkelt dag under de arbejdsvilkår.

14
30. maj 2018 kl. 14:24

RAID5 er en opvejning af tilgængelighed, pris og pladskrav. Det giver ikke mening med RAID6, 10 mv. hvis restoretiden ikke er lang og kunden kan acceptere denne nedtid (RTO).

Det har du også helt ret i.

Min pointe gik isoleret på den anden vinkel, indenfor konceptet "tilgængelighed", "raid" og "diske" ; fakta: diskfejl sker tit; fakta: dobbelt diskfejl sker ikke sjældent, de er ofte forårsaget af én disks fejlen, som sker tit, ergo - raid-5 er ikke rigtig beskyttelse.

Jeg har endnu ikke oplevet en tripplediskfejl (men det har andre sikkert).

Så egentligt siger jeg, at personligt, subjektivt, for mig, så er raid-5 ikke beskyttelse i store disksystemer, på samme niveau som "raid er ikke backup" - og backup trumfer altid raid. :-).

Og den sidste blev jo så også pludseligt relevant her. :-)

13
30. maj 2018 kl. 14:11

For mig er det uprfessionelt at begynde at blande forskellige harddisk producenter i en server. Der holder man sig til producentens muligheder. Du betaler typisk ekstra for harddisk firmwaren, men så er du også sikker på det spiller sammen. Har du tiden, kan du godt købe forskellige batch, selvom det ikke giver meget mening. Hvad gør det hvis du først køber 3 diske, derefter 2 og det er de sidste 2 der ryger i RAID5. Så er systemet utilgængeligt alligevel.

RAID5 er en opvejning af tilgængelighed, pris og pladskrav. Det giver ikke mening med RAID6, 10 mv. hvis restoretiden ikke er lang og kunden kan acceptere denne nedtid (RTO).

Der er tale om en opsætningsfejl der naturligvis ikke må ske. Den kan være svær at spotte, idet backuppen køre igennem og restores kan udføres. Det kræver et samarbejde med kunden, da jeg ikke regner med KMD har adgang til Roskildes borgers personlige data.

11
30. maj 2018 kl. 12:51

De skal vel sende alle diskene fra den berørte raidgruppe inkl den defekte; filerne ligger jo spredt i stripes over dem alle. Det lyder som en bortforklaring så man kan vise man er handlekraftig postmortem.

Lidt gammel popmusik:

Den store fejl er imo. RAID-5 - jeg er selv tidligere, flere gange, kommet i dobbelt-disk-fejl scenarier, og det er relativt mange sikkert også; og det er der netop raid-6/10 til. Det giver netop den bonus, at man ikke er på katastrofens rand, hvis der ryger én disk, man kan godt holde til to diske ryger. Især diske der sidder ved siden af hinanden i diskhylder/delte backplanes har jeg en del gange oplevet det at én disk går i stykker, og den laver noget logisk støj, som får sidemanden til at skide sig midlertidigt. Raid-5 = død, Raid-6 = i live. Raid-10 - i live.

Hvis man som storage ansvarlig kører raid-5 bør man reevaluere ifht den situation. Den øgede kapacitet er der ingen der skænker en tanke når man taber småkagerne på gulvet.

Det er nemt at være bagklog, men det er jo ikke nye argumenter, og igen ses det, at det er super relevante argumenter.

10
30. maj 2018 kl. 12:47

Måske jeg er den eneste der syntes dette er en meget sjov linie (sarkasme kan forekomme)

"Roskilde Kommunes filer blev opbevaret permanent i en temporær folder" - Vel det er nok ikke første gang at noget temporært setup bliver gjort til en fast del af produktionen.

9
Redaktionschef -
30. maj 2018 kl. 11:21
Redaktionschef

Der er sendt en enkelt disk til Norge med henblik på forsøg på recovery, skriver KMD i redegørelsen. En virksomhed, der hedder Ibas.

Mvh Adam

7
30. maj 2018 kl. 10:51

Jeg må indrømme, at hvis det kan lade sig gøre, så synes jeg, at det er lidt af en frækhed at erklære dataene tabt, og vælte konsekvenserne over på borgerne.

Kan det tænkes, at det af en eller anden grund ikke kan lade sig gøre?

6
30. maj 2018 kl. 10:50

Det er normalt at diske fra samme batch står af indenfor relativ kort tid. Har selv observeret det 2 gange, hvor der indenfor få dage var fejl på disk 2 i samme RAID.

Man bør selvfølgelig oversmåge SMART eller lign, så man får indikationer lidt tidligere, og proaktivt kan skifte.

Man kunne også supplere med et moderne filsystem (eksempelvis zfs) og køre med 2 paritetsdiske.

Skal vi antage at de resterende diske i array IKKE er skiftet, men kører til de dør. Det er jo billigere.

3
30. maj 2018 kl. 10:44

Send diskene til et professionelt recovery firma og få hevet filerne ud. Lyder som en standardopgave for sådan et firma.

2
30. maj 2018 kl. 10:37

Jeg ville aldrig bygge et sådan setup af diske fra samme batch. Måske samme producent, men med stor afstand imellem produktionsdatoerne, så man sikre at den fejl der evt. rammer en disk ikke også er til stede på de resterende diske.

Også gerne diske som har været i "burn-in" i forskellig tid, for dermed at give en tidsmæssig afstand mellem levetidsfejl, - hvis vi antager at der er super styr på kvaliteten fra producenten.

K

1
30. maj 2018 kl. 10:32

Er det bare mig der går med livrem og seler når det gælder sådan et setup?

Kørte systemet med samme batch af diske/producent?

Jeg ville aldrig bygge et sådan setup af diske fra samme batch. Måske samme producent, men med stor afstand imellem produktionsdatoerne, så man sikre at den fejl der evt. rammer en disk ikke også er til stede på de resterende diske.

Nu når det er noget så standard som 10k RPM SAS diske, så er det "nemt" at finde diske fra andre producenter at blande sit array med.

Men oplys mig gerne, hvis der i dag er andre grunde til at vælge samme batch diske/producent til noget så kritisk?