Store flyttedag med to petabyte data og nye mainframes hos KMD

Illustration: KMD
KMD har netop overstået en flytning af to petabyte data, da de skulle opgradere deres mainframes - og hvordan gør man så det, når både e-Boks og sygehuse er afhængige af adgang til den mainframe?

I oktober nattens mulm og mørke står 20 teknikere klar i en kælder under KMD’s store kontorer i Ballerup. Foran dem står KMD’s to meter høje zEnterprise EC12-mainframe og summer.

Ved siden af står dens lige så høje efterfølger, IBM z13, tavs. Flytningen er nødvendig, fordi KMD vil øge kapaciteten samt følge med udviklingen inden for mainframe-sikkerhed.

Når servicevinduet begynder lige om lidt, og mainframen slukkes, har teknikerne 6 timer til at flytte kabler mellem computerne – og samtlige kommuner, e-Boks-systemet og en række hospitaler er afhængige af, at den flytning sker problemfrit.

»Der er hundredvis af kabler, der skal flyttes, og pladsen bag maskinerne er trang. Så vores teknikere står skulder mod skulder og skal flytte de her kabler helt præcist og efter farvekoder, så de rigtige LPAR’er tilsluttes,« siger Jon Prehn et år efter flytningen. Han var KMD’s tekniske projektleder på flytningen.

Servicevinduet startede kl. 23, så de fleste af tjenesterne på mainframen var ikke i brug.

Alligevel var hver eneste handling fra IP-ændringer til kabelflytning skemalagt til minuttet for at mindske nedetiden for de sygehuse, der stadig brugte mainframen om natten til at planlægge vagter.

»Man kan ikke planlægge sig ud af alt. Vi havde enkelte kabler der var sat skævt i, og andre med signalproblemer, så vi måtte overskride servicevinduet med 1,5 time,« må Jon Prehn indrømme.

Det mærkede brugerne heldigvis ikke noget til, og den nye mainframe summede tilfreds videre. Nu manglede KMD ‘bare’ at flytte de to petabyte data, som kunderne havde lagret på den gamle mainframes harddiske og tape-miljøer.

Harddiske og kilometer af bånd

Indersiden af et tapesystem hos KMD. Illustration: KMD

Det er svært at copy-paste petabytes af data mellem to harddiske, og migrationen til nye harddiske hos KMD har taget længere end et halvt år.

»Vi tilslutter de nye disksystemer til kundernes eksisterende partitioner, så kunden en overgang har adgang til både nye og gamle diske, og så løber vi ellers samtlige logiske diske på de gamle systemer igennem og kopierer datasæt en for en til de nye systemer,« siger Jon Prehn.

»Endelig flytter vi pointers til datasættenes nye lokation, og så kan vi sætte de gamle diske offline,« siger han.

1,4 petabyte data blev flyttet på denne måde, men at flytte de 0,6 petabyte, som lå på magnetisk tape, var en længere saga. Selvom flytteprojektet egentlig er afsluttet, så er tape-migrationen stadig i gang.

»Det er simpelthen, fordi der er så store mængder data, som skal flyttes. Så det bliver vi nødt til at gøre lidt endnu,« siger Torben Linér, der er project executive hos IBM og KMD’s partner i flytteprojektet.

Teknisk foregår flytningen ellers som med harddiskene, og de gamle bånd, som især bruges af kunder, der skal opbevare deres data i årtier, mountes på det gamle system, læses og overskrives på bånd i det nye system.

Mainframen dør ikke

Jon Prehn og Torben Linér er enige om, at flytteprojektet, som strakte sig over et år, er forløbet uden større komplikationer eller problemer for kunderne på grund af grundig planlægning.

»Grunden til, at vi fik succes med flytningen, er den minutiøse plan, vi lagde for flytningen, og at den blev fulgt,« siger Torben Linér.

»Ja det er foregået helt militært, og vi skulle være helt præcise. Det gjorde så også, at der opstod en holdånd blandt teknikerne om at få den nye mainframe op at køre,« uddyber Jon Prehn.

Mainframe-opgaverne er svindende hos KMD, og mange kunder efterspørger i stedet cloud-løsninger. Alligevel har virksomheden stadig en betydelig mainframe-forretning.

Da KMD sidste år valgte at indgå et partnerskab med IBM, som nu driver hele mainframe-delen af forretningen, var det bl.a., fordi de havde svært ved at rekruttere nye mainframe-teknikere, mens de gamle efterhånden gik på pension.

Og mange har da også spået mainframens undergang.

»Man har sagt, at mainframen dør, i alle de tyve år, jeg har været hos IBM, og det gør den altså ikke. Dens måde at processere volumemener af transaktioner på er helt unik, og julehandlen samt alle andre handler, som kører gennem de store banker, kræver den slags teknologi,« siger Torben Linér.

»Der er en diftsikkerhed og sikkerhedsopsætning, som du ikke får på en distribueret serverplatform, og hvis du sammenligner antal incidents, så er det lavere på en mainframe. Det er solid, kendt teknologi, og det er derfor, den stadig er der,« slutter 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
Alexander Tange Journalist

Hej Claus.

KMD selv forklarer, at de stadig ønsker at følge med udviklingen indenfor mainframe teknologi og nye sikkerhedstiltag på trods af de svindende opgavemængder.

Når data fra f.eks. forsikringskunder skal lagres på mainframen i 30 år af lovgivningshensyn, så er det klart, at KMD er nød til at holde den data sikker på trods af, at indtaget af nye kunder på maskinen falder.

Jesper Frimann

Jeg ved godt mainframes er robuste og sån', men advarede CFCS ikke meget eksplicit mod at lægge for mange ting på een maskine efter CSC kludrede i det?

Nej.
Det var datatilsynet, og jeg tror du må tænke på den her:

https://www.datatilsynet.dk/afgoerelser/afgoerelsen/artikel/vedroerende-...

Sektion 3.1 og 3.2

Mit personlige take er, før man begynder at snakke om fysisk adskillelse af Partitioner eller virtuelle maskiner, så er der en myriade af andre ting, der skal gøres før man går igang med dette.
For lets be real, det drejer sig jo om at få så meget sikkerhed for pengene som muligt, og fysisk adskillelse er ikke billigt.

CFCS anbefalinger vdr. Mainframe sikkerhed er her:

https://fe-ddis.dk/cfcs/CFCSDocuments/Mainframesikkerhedsanbefaling.pdf

Og er .. ja ikke forkerte eller noget, men måske ikke så detaljerede, at de rigtig kan bruges til noget i praksis rent teknisk.

// Jesper

Morten Siebuhr
Joe Sørensen

En mainframe er ligesom et VMWare cluster. Selv hvis du ikke forventer at bruge VMWare om 5 år, så skal du opdaterer den og alle maskiner der kører på den, så længe de kører på den.

Jeg har også haft fornøjelsen af at forbinde til en ftp på en mainframe hos CSC. Det er ved at være et par dage siden efterhånden og de data tilhørte i øvrigt ikke politiet. Men måske samme mainframe alligevel.

Den gang undrede det mig at deres styresystem ikke havde været opgraderet i dette årtusinde. At de brugte ftp uden kryptering. At de konfigurerede deres firewalls sådan at vi kunne vi få adgang til ret meget mere end den ftp på den IP. Fx kunne vi forbinde til en ikke krypteret telnet, som gerne ville fortælle lidt om den mainframe på sin login skærm sammen med noget ascii-art.

Problemet er jo ikke at man har flere LPAR på samme mainframe. De her fejl er lige så store, hvis hver service er installeret på her sin white-box server. Man skal opdaterer sine styresystemer. Man skal ikke give alle gæster ukrypteret adgang til hele ens produktionsnetværk. Heller ikke selvom det er via VPN. VPN betyder jo bare at min desktop virtuelt bliver flyttet ind på produktionsnetværket og man kan derfor forbinde til alle services. Og her lader man gæsterne aflevere data ukrypteret. Så bare knæk en service på en server og man kan lytte til al data på hele netværket. Fra alle services og til alle services. Både data fra mainframes og white-box servere.

Jesper Frimann

Sjovt. Jeg tænkte lige omvendt - at fysisk adskillelse (x64-bokse og net) vil være et rimeligt billigt sted at starte.

Det er jo ikke fysisk adskillelse af en mainframe. En fysisk adskillelse af en mainframe er 2 eller flere mainframes. Og det er dyrt.

Du har i dit statement allerede lavet en portering af, det der i dag kører på Mainframen til.. en x86-64 platform. Og så er det jo ikke rigtig en mainframe mere.
Så ja.. man kan da lave en portering og så der kan man så begynde at diskuttere om sikkerhed og pris på en virtualizeret infrastruktur og en distribueret. Men det er og bliver et andet ballgame.

// Jesper

Mads Hjorth

Jeg tænker at mainframen har (eller måske havde) sin berettigelse der hvor mange processer skulle have adgang til samme hukommelse – for at sikre konsistens.

Men i artiklen lyder der til at være vedligeholdelsesmæssige fordele også. Altså man kun skal opdatere styresystemet på en maskine.

De andet argument handler nok mere om om hvilken viden der er til stede i driftsafdelingen, end om hvilken teknologi der vælges :-)

Og det første argument har jeg umiddelbart svært ved at få til at passe på de applikationer der nævnes. Hverken e-boks eller julehandel kræver vel egentlig at de forskellige transaktioner har kendskab til hinanden...

Morten Fordsmand

Business case er ofte et sammenrend af:
Nye features f.eks. inden for kryptering
Bedre performance
Og at spare penge man kan f.eks læse at der skiftes til andre diske og tapeteknik, noget der álmindeligvis bruger mindre strøm og plads i maskinstuen.

I øvrigt er det at kunderne efterspørger applikationer i skyen ikke ensbetydende med at brugen af mainframeapplikationerne ikke vokser.

Jørn Thyssen

En mainframe er konstrueret således at et breach i en LPAR ikke åbner adgang til andre LPARs, selvfølgelig under forudsætning af at den er konfigureret korrekt. Derfor var mainframe den første egentlige private cloud for mange år siden. Derfor behøver KMD ikke flere mainframes til at servicere mange kunder.

Jeg kender ikke størrelsen af KMDs mainframes men jeg gætter på at de har et lavt to-cifret antal kerner. Hvis man skulle afvikle samme workload på den nu snart 40 år gamle x86 teknologi ville det formentlig kræve tusindvis x86 kerner. Virtualiseringsgraden og -effektiviteten er meget høj.

Allan Ebdrup Blogger

Jeg kender ikke størrelsen af KMDs mainframes men jeg gætter på at de har et lavt to-cifret antal kerner. Hvis man skulle afvikle samme workload på den nu snart 40 år gamle x86 teknologi ville det formentlig kræve tusindvis x86 kerner. Virtualiseringsgraden og -effektiviteten er meget høj.


Har du en kilde der beviser denne påstand (ikke fra IBM)? De undersøgelser jeg har lavet af det (for 6-7 år siden) viste at det nærmere er den anden vej rundt: at en enkelt Intel core har mere kraft end en enkelt mainframe core, og at prisen for den samme ydelse som tommelfingerregel er ca. x100 på mainframe.
Hvis det du siger var sandt, så ville google, facebook og alle de andre store jo bruge mainframes, det gør de ikke.

Michael Cederberg

Hvis man skulle afvikle samme workload på den nu snart 40 år gamle x86 teknologi ville det formentlig kræve tusindvis x86 kerner.

Dagens x86 (eller mere præcist x64) arkitektur har ikke meget tilfælles med den oprindelige 8086/88 arkitektur. Din argumentation er uvederhæftig.

Har du en kilde der beviser denne påstand (ikke fra IBM)? De undersøgelser jeg har lavet af det (for 6-7 år siden) viste at det nærmere er den anden vej rundt: at en enkelt Intel core har mere kraft end en enkelt mainframe core, og at prisen for den samme ydelse som tommelfingerregel er ca. x100 på mainframe.
Hvis det du siger var sandt, så ville google, facebook og alle de andre store jo bruge mainframes, det gør de ikke.

Det lyder meget rigtigt. Man skal dog huske at man ikke bare kan lave en core-to-core sammenligning i og med mainframen har yderlige processorer. Men det kompenseres nemt for ved blot at smide endnu flere billige general purpose x86/x64 processorer efter problemet. Det er nemmere og mere fleksibelt.

Ydermere er det sådan at stort set alle de problemer som mainframes traditionelt har løst, sagtens kan løses på flere mindre maskiner hvis man blot partitionerer opgaven. Hvis man blot kigger på hardware, så vil en cluster af relativt små maskiner altid være billigere end en stor maskine. Det gælder både når clusteren konkurrerer med andre store x86 maskiner eller med mainframen. Clusteren har dog større driftsomkostninger. Man kan også diskuterer hvad ”relativt små maskiner” er – i min bog er det i dag ca. 8 core maskiner hver med 64GB RAM …

Jørn Thyssen

Beklager det sene svar. Jeg havde glemt denne tråd :)

Processorerne til z har højere clock frekvens og mere memory end x64. Men z er special designet til at håndtere data intensivt heterogent workload, eksempelvis databaser og transaktioner.

Historisk set var der ikke brug for høj clock frequency da I/O dominerede for sådanne workload. Men i takt med at kunder bruger z platformen til eksempelvis Linux og Java, så er clock freqency steget og er i dag over 5 GHz.

Jeg har ikke indsigt i de workloads som google, Amazon etc afvikler, og dermed afgøre om de ville give mening at afvikle på z platformen.

For 6-7 år siden var clock frequency dog relativt høj. Ved du hvilken generation du kiggede på i din sammenligning?

Jørn Thyssen

En 50 år gammel mainframe har lige så lidt at gøre med en ny som 8086 har med nyeste x64. Det forhindrer dog ikke de fleste i at omtale mainframe som legacy og gammel teknologi uden at gøre opmærksom på at x86 også er gammel teknologi.

Det er ikke altid muligt eksempelvis at partionere databaser så man kan afvikle det på mindre maskiner.
Desuden har mainframe et stort forspring inden for disaster recovery og clustering.

Michael Cederberg

Processorerne til z har højere clock frekvens og mere memory end x64.

Jeg medgiver at z processorerne kan fås med ca. dobbelt så høj clockfrekvens som x64. Det giver så teoretisk en fordobling af hastigheden, men realistisk nok noget mindre set i lyst af at RAM'en ikke følger med i hastighed.

x64 maskiner kan fås med lige så meget memory man ønsker ... man skal bare have den tykke tegnebog frem når man kommer over en hvis tærskel. Men det er den samme tegnebog man altid skal have fat i når man vælger mainframe.

Men z er special designet til at håndtere data intensivt heterogent workload, eksempelvis databaser og transaktioner.

Hvad gør z specielt godt til det? Hvor er det at z systemer udmærker sig ved den type opgaver?

Det er ikke altid muligt eksempelvis at partionere databaser så man kan afvikle det på mindre maskiner.

Det er ganske rigtigt. Men i min karriere har jeg set ganske få af den slags eksempler. Banker og flyselskaber er traditionelt steder hvor man ser mainframes og ingen af stederne har jeg set opgaver som kræver gigantiske OLTP databaser.

Jeg erkender at løsninger der er skrevet til mainframes ikke blot kan flyttes til mere moderne arkitektur - bl.a. fordi de er skrevet til en monolitisk arkitektur. Men nye løsninger der designes kan ofte opnå lineær skalabilitet - både på performance og omkostningssiden - ved at vælge ikke-monolitiske løsningsmønstre. Herunder sharding/partitionering af data i et database cluster.

Desuden har mainframe et stort forspring inden for disaster recovery og clustering.

Hvori består dette forspring?

Jørn Thyssen

Hej Michael,

Mainframes leveres i dag med min 1.5TB RAIM (RAID RAM) som standard, men hardwaren er givetvis dyrere end x86. Jeg følger ikke længere med i alle nørd-detaljer, men for få siden var der flere og større caches på processoren, så man undgår at vente på RAM. PRISM Hypervisoren sørger for at workload scheduleres på samme processor så man får udnyttet caches bedst muligt.

Der er specifikke hardware instruktioner for hypervisoren, dedikerede processorer til eksempelvis I/O, og mange andre tricks. x86 chip fabrikanterne forsøger givetvis at implementere lignende ting i deres processorer, så forskellen bliver sikkert mindre i fremtiden.

Clustering på mainframe skalerer stort set linært. Det er ikke lykkedes andre leverandører at lave noget tilsvarende. De fleste mainframe kunder kører to- eller fire-vejs cluster spredt ud over to datacentre med 5-10kms afstand. Dette sikrer mulighed for rullende opgradering af hardware og software uden nedetid, samt transparent fail over ved lokale nedbrud. Nogle kunder er begyndt at tilføje et tredje data-center længere væk (nogle gange 1000+kms afstand). På grund af lysets hastighed kan man så ikke længere vedligeholde data synkront, og man må derfor leve med RPO > 0.

Danske mainframe-kunder (som er relativt små set på verdensplan) afvikler typisk mange millioner SQL forespørgsler i sekundet og tusindevis COMMITs per sekund i peak mod titusindevis af tabeller, hvoraf de største tabeller har mere end 10 mia. rækker.
Google har sikkert flere søgninger per sekund, men de driver ikke en bank-virksomhed hvor data-integritet (ACID) er ret vigtigt.

Du rammer nok meget godt i din kommentar om at løsninger skrevet til monolitisk arkitektur ikke flyttes nemt til andre platforme. Der er en del kunder som har forsøgt en 1:1 migrering til en formodet billigere platform hvor det typiske resultat er at man har brændt en milliard kroner af på en lige så kompleks og dyr platform -- eneste forskel er at man nu er fastlåst til leverandør X i stedet for IBM. Samtidigt lå alt innovation stille i de 5+ år som projektet varede... Så skulle man bide i det sure æble og fuldstændig redesigne arkitekturen og begynde forfra. Det kan så godt være man kan bygge et billigere system med samme dyder som mainframen. Men det ændrer ikke på at man må vedligeholde to systemer sideløbende indtil alle gamle systemer er afviklet.

Når man hører noget negativt om mainframe, så skyldes det ofte kunder som har "efterladt" deres mainframe i årevis uden at opgradere hardware og/eller software (herunder security patches).

Michael Cederberg

Mainframes leveres i dag med min 1.5TB RAIM (RAID RAM) som standard, men hardwaren er givetvis dyrere end x86. Jeg følger ikke længere med i alle nørd-detaljer, men for få siden var der flere og større caches på processoren, så man undgår at vente på RAM. PRISM Hypervisoren sørger for at workload scheduleres på samme processor så man får udnyttet caches bedst muligt.

Det samme kan man få andre steder og billigere.

Der er specifikke hardware instruktioner for hypervisoren, dedikerede processorer til eksempelvis I/O, og mange andre tricks. x86 chip fabrikanterne forsøger givetvis at implementere lignende ting i deres processorer, så forskellen bliver sikkert mindre i fremtiden.

Bortset fra dedikerede processorer til I/O kan man få det samme hos Intel. Jeg anser I/O som en simpel ting som ikke kræver separate processorer. Dette komplicerer blot softwaren. Og som sagt kan man bare smide flere billige x64 cores efter problemet ... de kan så bruges til noget fornuftigt på de tidspunkter hvor der ikke er behov for I/O.

Clustering på mainframe skalerer stort set linært. Det er ikke lykkedes andre leverandører at lave noget tilsvarende.

Her er jeg ude på dybt vand, for jeg ved ikke hvad der specifikt ligger i begrebet "clustering på mainframes". Men clustering af Windows/Linux Intel servere skalerer også lineært. Dog skal det erkendes at softwaren ser radikalt anderledes ud når den er skrevet til et cluster environment. Men man kan fint lave et cluster af 1000 computere hver med 32 kerner.

De fleste mainframe kunder kører to- eller fire-vejs cluster spredt ud over to datacentre med 5-10kms afstand. Dette sikrer mulighed for rullende opgradering af hardware og software uden nedetid, samt transparent fail over ved lokale nedbrud. Nogle kunder er begyndt at tilføje et tredje data-center længere væk (nogle gange 1000+kms afstand). På grund af lysets hastighed kan man så ikke længere vedligeholde data synkront, og man må derfor leve med RPO > 0.

Det samme gør man hver dag på Windows og Linux. Det er dog ikke alle applikationer der er skrevet til dette.

Danske mainframe-kunder (som er relativt små set på verdensplan) afvikler typisk mange millioner SQL forespørgsler i sekundet og tusindevis COMMITs per sekund i peak mod titusindevis af tabeller, hvoraf de største tabeller har mere end 10 mia. rækker.

SQL queries i stor skala er ikke noget problem. Det er et simpelt problem og det kan alle større database systemer klare også i et cluster setup. Commits er en anden sag, men jeg har ikke set noget der indikerer at mainframes skulle være bedre på dette område ... snarere tværtimod. Brug af store tabeller eller mange tabeller er et "ikke problem" for alle større database systemer. Der er dog stor forskel på hvilke management faciliteter databasen stiller tilrådighed. Men jeg har selv "ejet" databaser på Intel platformen med mere en 100 mia. rækker i nogle tabeller uden at det var noget problem.

Google har sikkert flere søgninger per sekund, men de driver ikke en bank-virksomhed hvor data-integritet (ACID) er ret vigtigt.

ACID på hele databasen er ikke vigtigt i de fleste situationer - også i banker. Registrering af forretningstransaktioner foregår bedst i mange små databaser i stedet for en stor megadatabase. Det giver bedre resiliency og performance. Og når forretningstransaktion registreret sker næsten alt i batch operationer hvor ACID er mindre vigtigt - ofte vil en fejl betyde at man genkører et større batch.

I mine øjne er ACID en overvurderet dinosaur fra fortiden. I de fleste tilfælde har man kun begrænset brug for ACID og det sætter en masse unødvendige constraints på databasen. Fx. forhindrer ACID i relationelle databaser sharding.

Når man hører noget negativt om mainframe, så skyldes det ofte kunder som har "efterladt" deres mainframe i årevis uden at opgradere hardware og/eller software (herunder security patches).

Her er min negative liste om mainframes og den har intet med opgradering at gøre:

  • Hardwaren er dyr
  • Software der fungerer godt i mainframes skal skrives specielt til mainframes
  • Udviklingsværktøjer er ringe i forhold til resten af software verden
Log ind eller Opret konto for at kommentere