Cloud i brug. Migrering af NemHandel til kommerciel cloud infrastruktur

Transkript

1 Cloud i brug Migrering af NemHandel til kommerciel cloud infrastruktur

2 02 Indhold > Executive Summary NemHandel Tidligere drift Mål med migrering af driften Business Case Ny driftsleverandør Holdt Business Casen? Sikkerhed Konklusion Appendix: Fakturablanketten på AWS Appendix: Skalering af Fakturablanketten Appendix: Områder der blev vurderet før projektet startede Appendix: AWS ønsker og problemer Kontaktoplysninger

3 03 Executive Summary > I forsommeren 2009 besluttede IT- og Telestyrelsen (ITST) at evaluere driften af de centrale services i NemHandel infrastrukturen. Valget stod mellem at investere yderligere i den eksisterende driftsinfrastruktur eller helt at genoverveje driften. Begrebet Cloud computing var ved at boble op til mediernes overskrifter og lokkede med at opfylde nogle af vores ønsker på centrale områder: En dynamisk skalerbar infrastruktur til NemHandel produktionsmiljøet med en ren forbrugsbaseret prismodel. Mulighed for udviklings- og testmiljøer der var kloner af produktionsmiljøet, men som udviklingsteamet havde fuld kontrol over. Og dette leveret til en væsentlig lavere pris! Det blev besluttet at lave en business case på at migrere driften af den centrale NemHandel infrastruktur til Amazon Web Services (AWS), der hurtigt skilte sig ud som værende en af de mest modne leverandører på Cloud computing området og som tilbød den palette af infrastruktur driften af Nem- Handel krævede. Business casen kiggede isoleret på migrering af driften af produktionssystemerne og estimerede at en flytning ville koste kr , der ville være tjent hjem på 14 mdr. grundet en månedlig besparelse på driften på kr Migreringen af driften blev afsluttet i juni 2010 og projektet kom til at koste kr Den kraftige overskridelse skyldes primært investeringer på områder, der ikke var med i det oprindelige projektgrundlag og dermed ikke med i estimatet. Disse investeringer var primært i produktionsmodning og ville skulle have været afholdt selvom driften var forblevet i det gamle miljø.

4 04 > En mindre del af overskridelsen er dog AWS relateret og skyldes en kombination af mangel på erfaring med AWS og mangel på modenhed af AWS miljøet. En præcis opgørelse af denne omkostning har ikke været mulig, men det vurderes til at have været i størrelsesordenen kr At omkostningerne var væsentlige skyldes ikke problemernes omfang, men at de opstod i forbindelse med idriftsættelsen og ikke under udviklingsfasen - håndtering af problemer under idriftsættelse er generelt dyrere. Selve driften er billigere end estimeret i business casen, dels fordi AWS i mellemtiden har sænket prisen med % på de anvendte services, dels fordi den anvendte infrastruktur er dimensioneret mindre end antaget i business casen. Desuden er der lavet en aftale med en dansk driftsleverandør, hvilket samlet gør at den månedlige omkostning for driftsmiljøet vil være på ca. kr Dette giver en tilbagebetalingstid på investeringen på 28 mdr. Business casen fokuserede isoleret på driftsmiljøet, men som vi vil komme ind på senere, ligger der også væsentlige besparelser på udviklings- og testmiljøer samt staging miljøet. Disse besparelser er dog ikke blevet kvantificeret. I forhold til de ikke økonomiske mål er det lykkedes at få et driftsmiljø, der effektivt skalerer i forhold til det varierende forbrugsmønster NemHandel har. Derudover er det lykkedes af få udviklings- og testmiljøer, der er meget fleksible og som udviklingsteamet har fuld kontrol over, men som samtidigt er baseret på images fra produktionssystemet. Dette begrænser væsentligt risikoen for fejl ved overgangene fra udvikling til test til staging til endelig produktion.

5 05 Nemhandel > NemHandel er en national dansk infrastruktur til udveksling af forretningsdokumenter (for eksempel fakturaer og ordresedler) mellem såvel offentlige som private virksomheder. Udgangspunktet er en bekendtgørelse fra 2005, hvor det fastlægges at alle fakturaer til det offentlige skal sendes elektronisk i et fastlagt XML baseret format. Bekendtgørelsen er blevet opdateret i 2010 og pålægger offentlige myndigheder at kunne modtage gennem NemHandel infrastrukturen senest den 1. maj Målsætningerne med NemHandel er at fjerne barriererne for elektronisk handel i Danmark dels gennem at drive omkostningerne ned og dels ved at reducere de tekniske barrierer for specielt mindre virksomheder. 1. Et NemHandelsregister hvor alle der anvender NemHandel skal registrere, hvilke dele af Nem- Handel der understøttes f.eks. hvilke forretningsdokumenter der kan modtages. Alle offentlige myndigheder skal være registreret i dette register inden 1. maj Et system kaldet Fakturablanketten til indtastning af fakturaer rettet mod virksomheder, der sender få fakturaer til det offentlige. Fakturablanketten tilgås gennem Virk.dk. 3. En gateway til det såkaldte VANS netværk, der sikrer at brugere af NemHandel i en overgangsfase kan sende til alle offentlige modtagere. Udvekslingen af forretningsdokumenter i NemHandel foregår direkte mellem afsender og modtager, men NemHandel infrastrukturen indeholder alligevel tre centrale komponenter, hvor IT- og Telestyrelsen står for driften:

6 06 > Figur 1: Antal sendte fakturaer per måned Fakturablanketten VANS Sep okt nov dec jan feb mar apr maj jun jul aug Sep okt nov dec jan feb mar apr maj jun jul aug Sep okt nov dec jan feb mar NemHandel blev lanceret i efteråret 2007 og ovenstående figur viser udviklingen i antal sendte meddelelser i NemHandel siden da. Den gule kurve angiver antal sendte fakturaer fra Fakturablanketten og den blå kurve angiver antal sendte fakturaer gennem den offentlige gateway til VANS. Som figurerne antyder, har der været et konstant forøget pres på de centrale driftssystemer, hvilket har gjort at kapaciteten løbende har måttet udvides.

7 07 > Samtidig er presset på driftssystemerne kendetegnet ved et meget varierende mønster. Nedenstående figur viser antallet af brugere på Fakturablanketten henover et døgn. Og den næste figur viser antal brugere henover en måned, der tydeligt viser et begrænset pres på systemerne i weekender og et øget pres på % i de første hverdage efter et månedsskifte. Figur 2: Antal brugere per time Figur 3: Antal brugere per dag MARTS 2010 APRIL

8 08 Tidligere drift > Driften af Nemhandelsregisteret og Fakturablanketten blev tidligere leveret af en traditionel hosting leverandør via en SKI rammeaftale 1. Denne aftale dækkede den egentlige drift men ikke områder som slutbruger (first level) support og vedligeholdelse af applikationer. Rammeaftalen definerede en række ydelser, som man kunne vælge ud fra og desuden kunne man vælge, hvilket SLA niveau man ville have per ydelse; Guld/Sølv/Bronze (typisk for en server). Det var i høj grad som et fast menukort og hver service var som en black box service med en SLA. Som kunde giver rammeaftalen en vis tryghed man antager at rammeaftalen dækker ens behov og under alle omstændigheder gør jeg som de andre. Den grundlæggende pointe er, at hvis man vælger ikke at bruge en rammeaftale, er der pludselig en masse driftsmæssige overvejelser man bliver tvunget til at tage stilling til. Desuden er der som offentlig kunde nogle udbudsregler, der skal tages højde for, som man slipper for med SKI rammeaftalen. Den største kilde til frustration med den tidligere drift lå i den manglende fleksibilitet i rammeaftalen. Specielt havde vi svært ved at få differentieret produktionsmiljøet fra staging, udviklings- og testmiljøerne. For staging, udviklings- og test- miljøer kunne vi vælge en lavere SLA (Bronze), men alle ændringer til miljøerne var alligevel underlagt de samme ITIL procedurer som for produktionsmiljøet. Det betød at det var både langsomt og omkostningstungt at ændre i disse miljøer. Og dette var både de direkte omkostninger til driftsleverandøren men også de mere skjulte omkostninger i udviklingsteamet, der måtte tage højde for disse afhængigheder i planlægningen. Dette betød i praksis, at vi havde et lokalt udviklings- og testmiljø og at staging miljøet ikke blev etableret af omkostningsmæssige grunde. Men des 1 Driften af den offentlige gateway håndteres af tredje part. Flytning af denne drift blev ikke evalueret dels fordi driften er tidsbegrænset (til den 1. maj 2010) og dels pga. afhængigheder til nogle interne systemer hos driftsleverandøren.

9 09 > mere disse miljøer afviger fra produktionsmiljøet des større er chancen for at problemer opdages for sent i processen i visse situationer efter produktionssætning. Dette er selvfølgelig for sent både ud fra et omkostnings, tidsmæssig og driftsmæssig synspunkt. Endelig skal det nævnes, at produktionsmiljøet ikke kunne betragtes som endeligt i drift, da der ikke var etableret vandtætte skodder mellem drift og udviklingsteamet. Når systemer skulle opdateres blev der lavet et servicevindue, hvor SLA en blev fjernet og udviklingsteamet fik adgang til produktionssystemet. Dette nævnes her, da en del af omkostningen ved migreringen dækker etableringen af egentlig drift mere om dette senere.

10 10 Mål med migrering af driften > Udover en forventet omkostningsreduktion til selve driften var målene med migrering af driften: Der var kapacitetsmæssige problemer med det eksisterende miljø og disse skulle løses. Vi ville have et miljø, der skalerede dynamisk med det egentlig forbrug og ikke et miljø der skulle dimensioneres efter højeste belastning. Samtidigt skulle det skalere gnidningsfrit i takt med det forventede øgede træk på systemerne over tid (se kurverne fra tidligere). Det skulle være muligt at have udvikling og test miljøer, der lignede produktionsmiljøet, men udviklingsteamet skulle bevare den fulde kontrol over miljøerne. Vi skulle have et staging miljø uden at prisen for dette var i samme størrelsesorden som produktionsmiljøet. IT- og Telestyrelsen ønskede at gå foran og få erfaringer med Cloud computing.

11 11 Business Case > Business casen kiggede snævert på en migrering af selve produktionsmiljøet og tog ikke andre elementer ind såsom andre miljøer, vedligehold af applikationer eller slutbruger support. Desuden tog beregningerne udgangspunkt i en migrering til AWS. AWS blev valgt ud fra en forventet modenhed af services samt deres udbud af services, herunder at de tilbød både Windows og Unix/Linux baserede servere. Vores eksisterende produktionsmiljø bestod af i alt 9 servere, der dækkede både Fakturablanketten og NemHandelsregisteret. Hvis vi skulle blive i dette miljø skulle Fakturablanketten udvides med én server og NemHandelsregisteret med tre servere. For at kunne sammenligne før og efter, blev der derfor taget udgangspunkt i et miljø med 13 servere 2. Heraf var der to databaseservere med DBA samt udgifter til storage, netværk og load balancing. Hele produktionsmiljøet havde en Guld SLA. Den samlede månedlige omkostning til dette produktionsmiljø ville beløbe sig til kr En udfordring vi havde, var at finde ud af, hvordan vi skulle sammenligne den ydelse vi fik med den ydelse AWS tilbød. Vi kunne regne ud, at den tilsvarende infrastruktur hos AWS ville komme til at koste ca. kr per måned 3, men hvilke ydelser fik vi brug for yderligere og hvem kunne levere dem? Figur 4: Estimerede driftsomkostninger ved skift til AWS SLA (SKI/Guld) kr/md? AWS infrastruktur (SLA) kr/md 2 Omkostninger til etablering af de 4 nye servere er ikke indregnet. 3 Vi regnede på 1 års reserverede instanser da forventningen var, at driftskontrakten ville løbe et år af gangen.

12 12 > Vi identificerede de manglende ydelser til at være: Figur 5: Forudsete yderligere driftsomkostninger Overvågning/monitorering af applikationer og ressourcer AWS har en service til ressourceovervågning, men man skal selv agere og AWS har ingen kendskab til selv applikationen Databaseadministration og herunder backup procedurer Vedligehold herunder sikkerhedspatching af servere og opdatering af applikationer Support funktion ved driftsforstyrrelser og ændringsanmodninger 4 Estimatet for at få dækket disse ydelser var på kr per måned. Den samlede pris for drift på AWS infrastruktur ville derfor komme op på kr per måned mod tidligere kr per måned. SLA (SKI/Guld) kr/md Drift (Maintenance, monitorering, DBA) Support ( kr.) AWS infrastruktur (SLA) (7.000 kr.) kr/md 4 Ændringer der ligger udover hvad der kan anses som almindelig drift afregnes separat både efter den gamle og den nye aftale.

13 13 > Selve migreringen af applikationer blev estimeret til kr der skulle dække: Applikationsmæssige ændringer nødvendige pga. ændret platform/infrastruktur Applikationsmæssige ændringer nødvendige for at udnytte skalerbarheden hos AWS Etablering og dokumentation af nyt driftsmiljø Etablering af procedurer for overvågning, backup og vedligeholdelse Planlægning og udførelsen af selve migreringen herunder datamigrering Med en investering på kr og en månedlig besparelse på kr ville investeringen være tjent ind på kun 14 mdr. Figur 6: Investeringsafkast i kr per måned (ROI ~ Return On Investment) mdr.

14 14 Ny driftsleverandør > Udover den rent tekniske migreringsopgave var opgaven at finde en leverandør, der kunne levere de resterende ydelser til driften. Vi var som udgangspunkt ikke interesseret i et mere kompliceret aftalekompleks, hvor den eksisterende aftale ville blive erstattet med to nye aftaler. Derfor gik vi efter en aftalemodel, hvor vi stadig havde en kontrakt med en driftsleverandør, der så bare købte infrastrukturen gennem AWS i stedet for at have den stående in-house. Vi startede med at gå til vores daværende leverandør for at undersøge muligheden for, at de udvidede deres forretning med drift baseret på AWS infrastruktur. Der var stor forståelse for vores målsætninger, men det mundede ud i, at leverandøren var interesseret i at møde vores krav baseret på deres eksisterende infrastruktur herunder det at kunden selv kan administrere infrastrukturen (selfprovisioning). Leverandøren blev fravalgt dels fordi den ydelse altså endnu ikke eksisterede, men også en forventning om at leverandøren over tid ikke ville kunne konkurrere hverken funktionalitetsmæssigt eller prismæssigt med AWS. Den største barriere vi mødte hos potentielle leverandører var en usikkerhed om, hvordan leverandøren skulle levere en given SLA baseret på en infrastruktur leverandøren ikke selv havde fuld kontrol over. Visse leverandører opfattede dette som den største udfordring, mens andre opfattede AWS som bare noget andet infrastruktur. Valget faldt på en leverandør, der netop opfattede AWS som bare en anden type infrastruktur, og som var interesseret i at få erfaring med Cloud computing. Rent aftalemæssigt adskiller driftsaftalen sig umiddelbart kun på to punkter fra en traditionel driftsaftale. For det første er der angivet en SLA for selve infrastrukturen, der vil være den til enhver tid gældende SLA som AWS har. AWS er at betragte som en underleverandør til vores driftsleverandør og underleverandørens SLA afspejles direkte i vores driftsaftale.

15 15 > For det andet er der prismodellen. En traditionel driftsaftale tager ofte udgangspunkt i dimensioneringen af infrastrukturen herunder antallet af servere. Den dynamiske skalering hos AWS, hvor servere startes og stoppes dynamisk efter behov, udfordrede denne model sammen med at visse infrastruktur services potentielt erstattes at platform services f.eks. at en database server erstattes af en dataservice. Desuden havde vi som kunde et ønske om en let gennemskuelig prismodel. Løsningen blev den meget simple, at driftsleverandøren for sine ydelser tager 150 % af AWS ydelsen. Det skal også nævnes, at prismodellen har en skævvridning af kunde og leverandørens incitamentsstruktur. Leverandøren har en økonomisk interesse i at dimensionere infrastrukturen opad (f.eks. større servere). Det er selvfølgelig i sidste ende kunden, der er ansvarlig for at dimensionere infrastrukturen, men i praksis sker dette på baggrund af rådgivning fra leverandøren, så modellen kræver en grundlæggende tillid mellem kunde og leverandør. Som kommentar til prismodellen skal nævnes, at leverandøren tog det forbehold at modellen skal reevalueres efter 6 måneder, da prismodellen ikke har været afprøvet tidligere.

16 16 Holdt Business Casen? > Fakturablanketten blev sat i drift i april 2010 og NemHandelsregisteret i juni Som tidligere nævnt blev omkostningerne til migrering estimeret til kr De samlede omkostninger til projektet endte på kr Den kraftige overskridelse skyldes primært investeringer i produktionsmodning, der ikke var med i det oprindelige projektgrundlag og dermed ikke med i estimatet: Tabel 1: Den reelle business case efter implementering Der er taget bevidste valg om arkitekturmæssige forbedringer herunder en konsolidering på en mere homogen og forventet mere driftsstabil platform. En væsentlig del har været omkostninger til modning til drift herunder dokumentation af produktionsmiljøet og definition/dokumentation af driftsprocedurer. Disse omkostninger ville det have været nødvendigt at afholde selvom driften var forblevet i det gamle miljø. Der er blevet rettet fejl som også skulle have været rettet i det gamle miljø. Estimeret i business casen Realiseret Samlede migreringsomkostninger - AWS relaterede migrationsomkostninger - omkostninger grundet arkitekturmæssige forbedringer Kr Kr Kr Kr Samlede månedlige driftsomkostninger - infrastrukturomkostninger - support- og driftsomkostninger Kr Kr Kr Kr ROI (Return On Investment) 28 måneder

17 17 > En mindre del af overskridelsen er relateret til højere omkostninger til opsætning/tilpasning af applikationer til AWS miljøet og skyldes en kombination af mangel på erfaring med AWS og mangel på modenhed af AWS miljøet. En præcis opgørelse af disse AWS relaterede omkostninger har ikke været mulig, men det vurderes til at have været i størrelsesordenen kr At omkostningerne var væsentlige skyldes ikke problemernes omfang, men at de opstod i forbindelse med idriftsættelsen og ikke under udviklingsfasen - håndtering af fejl under idriftsættelse er generelt væsentlig dyrere end under udvikling. Som nævnt kan disse omkostninger tilskrives en kombination af manglende erfaring med AWS og umodenhed af AWS f.eks. i form af begrænset dokumentation og deciderede fejl. I forbindelse med fejl er vurderingen, at der er blevet brugt mere tid end normalt på isolering af fejlene. Der var fejl hvor AWS var mistænkt som kilden, men det viste sig at være applikation eller platform, men der var også eksempler på det modsatte. En af konklusionerne var, at det var nødvendigt at tegne abonnement på AWS premium support i guld udgaven med 24x7x365 support. Dette var ikke en omkostning vi havde indregnet i business casen, men guld supporten har været nødvendig for at få løst nogle af de problemer, vi løb ind så effektivt som muligt. Til gengæld er den månedlige omkostning til AWS infrastrukturen lavere end antaget i business casen. Dette er på trods af, at der er kommet en ekstra server til, men skyldes dels at den resterende infrastruktur er dimensioneret mindre end først antaget og at AWS priser er faldet % afhængig af servicen. Den månedlige omkostning til infrastrukturen vil være ca. kr Hvis vi dertil lægger omkostning til AWS premium gold support 400 $/md og 150 % til driftsleverandøren vil den månedlige driftsomkostning være på ca. kr

18 18 > Dette er lavere end antaget i business casen (kr ) og med disse tal vil investeringen på kr være tjent hjem på 28 mdr. Så på trods af de væsentligt højere omkostninger til migreringen har der været en fornuftig business case i flytningen til AWS, selv når omkostningerne til produktionsmodning er indregnet. Og business casen har set isoleret på produktionsmiljøet. Hvis der inkluderes staging, udvikling og test miljøer vil denne være væsentlig bedre, men vi har ikke præcise tal for de tidligere omkostninger, dels fordi vi ikke havde etableret staging miljøet og dels fordi omkostninger til de lokale udviklings- og testmiljøer ikke har kunnet adskilles fra andre projektomkostninger. Dog skal det siges, at det ikke kan udelukkes, at der kunne have været en tilsvarende business case ved migrering til en anden traditionel driftsleverandør. Fordelene ved det meget skalerbare miljø og fordelene ved udvikling, test og staging miljøer ville dog ikke umiddelbart kunne opnås.

19 19 Sikkerhed > Sikkerhed er et emne, der debatteres meget i forbindelse med Cloud Computing, og vi var selvfølgelig bevidste om dette. En vurdering af sikkerheden må altid tage udgangspunkt i en risikoanalyse 5 af de konkrete systemer. Denne analyse skal afdække, hvad der er dine største risici og dermed, hvad det er, der skal beskyttes. Afhængig af de risici der identificeres, bliver det så mere eller mindre relevant om driften er cloud baseret eller ej. I vores tilfælde blev applikaktionsmæssige fejl vurderet til at have høj risiko, da konsekvensen af applikationsfejl kunne blive både dyre og resultere i manglende tillid til systemerne. Derfor var et indsatsområde at stramme op på test og deployment procedurer. At mindske risikoen for tab af data fra NemHandelsregisteret blev også prioriteret, hvorfor backup procedurerne blev skærpet og der bliver gemt lokale kopier af backuppen hos driftsleverandøren. Overordnet set kan det være svært som almindelig kunde at vurdere, hvordan cloud computing påvirker sikkerheden for dine systemer, men det er det også ved traditionel hosting. Men ved at lave en risikoanalyse får man væsentlig bedre mulighed for at prioritere, hvilke områder der skal kigges nærmere på. I forhold til drift alternativerne er der sikkerhedsmæssige fordele og ulemper ved cloud computing, men ved at tage udgangspunkt i en risikovurdering undgår man at ryge den fælde, at man enten kun ser de potentielle fordele eller ulemper ved cloud computing. Et område som oppetiden af specielt NemHandelsregisteret blev også prioriteret, men her giver både de tekniske og økonomiske muligheder i cloud computing os en fordel. 5 Inden for den offentlige sektor skal sikkerhedsstandarden DS484 følges og denne foreskriver gennemførelsen af en risikoanalyse.

20 20 Konklusion > Set ud fra en økonomisk betragtning har der været en god business case i migreringen af NemHandel infrastrukturen til AWS. Der kan selvfølgelig altid argumenteres for, at den ydelse vi kom fra ikke kan direkte sammenlignes med den vi får nu, men som almindelig kunde kan det være svært at se forskel. Hvis en traditionel hosting leverandør leverer merværdi, skal leverandørerne være i stand til at konkretisere denne merværdi og kommunikere den effektivt. Set ud fra et udviklings- og vedligeholdelsesperspektiv har teamet i dag en væsentlig højere grad af fleksibilitet end tidligere og vores påstand er, at der ligger en stor besparelse i at få reduceret de skjulte omkostninger i et udviklingsteam til administration af udviklings- og testmiljøer. De største udfordringer har ligget i manglende kendskab og til dels umodenhed af AWS services. Der har været deciderede fejl og manglende dokumentation, men support aftalen har fungeret rimeligt og der er blevet fulgt op på tingene dog nogle gange med lang respons tid. Desuden kan der ligge en udfordring i at acceptere de begrænsninger, der ligger i en hyldevare som AWS. Hvis de involverede parter i projektet har været vant til fuld fleksibilitet i infrastrukturen, skal man være bevidst om dette når man evaluerer, om man vil bruge de af AWS tilbudte services. Samtidig skal man dog være bevidst om, at brugen af de proprietære AWS services vil gøre det dyrere eventuelt at migrere væk fra AWS igen. Sidst, men ikke mindst, kan der være en stor mental afstand til AWS. Når der opstår problemer kan man ikke lige ringe til sin account manager og lægge pres på. Det kan være svært at differentiere sig som kunde Jeg er bare én blandt mange i en meget broget AWS kundeportefølje!, men her er abonnementet på guld premium support med til at skaffe dig fokus som kunde.

21 Appendix: 21 Fakturablanketten på AWS > Figuren på følgende side viser infrastrukturen hos AWS, der understøtter NemHandel Fakturablanketten Indgående requests fra slutbrugeren bliver fordelt til front end serverne af en load balancer baseret på AWS servicen Elastic Load Balancing. Til load balanceren er der knyttet auto scaling, der sørger for at starte og stoppe front end servere efter behov (se appendix om skalering). Præsentationslaget består af et antal front end servere baseret på et OpenSolaris 32 bit AMI (standard/lille instanser). Til at holde state på sessionerne anvendes Terracotta, der er installeret på samme OpenSolaris version og samme instans type. Præsentationslaget anvender servicelaget, der udstiller et antal web services. Udover serveren, der udstiller web services, er der en RASP afsender server og en administrativ server. Alle disse er baseret på samme OpenSolaris version som ovenfor på standard/lille instanser. Databaseserveren kører MySQL på en 64 bit udgave af OpenSolaris og WC2 instansen er en standard/stor. Under arbejdet med migreringen blev servicen Relational Database Service tilgængelig i EU zonen og det overvejes at skifte til denne service senere. Alle firewalls er baseret på Security Group konceptet dvs. vi har ikke selv etableret nogen firewalls.

22 Appendix: 22 Fakturablanketten på AWS > Figur 7: Infrastrukturen hos AWS, der understøtter NemHandel Fakturablanketten

23 Appendix: 23 Skalering af Fakturablanketten > Skaleringen af NemHandel Fakturablanketten er opnået gennem auto-skalering af front-end serverne. Selve konfigurationen af denne auto-skalering gik der noget tid med at få optimeret. De regler vi aktuelt bruger er: Der skal være minimum en og maksimum fire front-end servere Hvis CPU forbruget overstiger 50% over en periode på 5 min startes en ny server Hvis CPU forbruget er under 10% over en periode på 5 min slukkes en server Der er en cool-down periode på 10 minutter efter hver aktion (start/stop), hvor disse kriterier ikke evalueres Figur 8: Brugere per døgn sammenholdt med CPU forbrug Figur 9: Brugere per uge sammenholdt med CPU forbrug Man Tir Ons Tor Fre Lør Søn Figuren viser antal brugere over et døgn (den røde linje) sammenholdt med det samlede CPU forbrug. CPU forbruget er vist per server, hvor hver front-end server har sin egen farve. Ovenstående figur viser det samme for en uge. Bemærk hvordan visse servere får lov at leve over flere dage.

24 Appendix: 24 Områder der blev vurderet før projektet startede > De følgende områder blev overvejet inden migreringsprojektet blev sat i gang og parallelt med udarbejdelsen af business casen. De fleste af disse områder vil være relevante, hvis man overvejer at anvende en cloud leverandør af infrastrukturen (Infrastructure as a Service IaaS): Kan leverandøren levere den relevante infrastruktur? Dette er selvfølgelig oplagt, men især ved migrering af eksisterende løsninger kan det hurtigt blive aktuelt, om det der leveres er tilstrækkeligt. IaaS er en hyldevare som man må tilpasse sig. Hvordan håndteres monitorering, notificering og håndtering af driftsforstyrrelser? Hvordan håndteres monitorering af systemerne og hvem håndterer eventuelle driftsforstyrrelser? Cloud leverandøren leverer muligvis services, der hjælper med overvågning af infrastrukturen, men hvad med applikationen? Kan leverandøren levere tilstrækkelig driftsstabilitet? Cloud leverandøren har selvfølgelig en SLA på infrastrukturen, men er denne tilstrækkelig og hvordan dokumenterer de overholdelsen? Er der desuden mulighed for bod? Hvordan håndteres backup? Er backup en service der leveres eller er man selv ansvarlig for dette? Og er det relevant at sikre sig kopier af backup, der ikke ligger hos cloud leverandøren?

25 Appendix: 25 Områder der blev vurderet før projektet startede > Er det nødvendigt med DBA og hvem leverer dette? Er database funktionalitet en service eller er man selv ansvarlig for denne og dermed DBA? Hvordan vedligeholdes platformen? Hvordan vedligeholdes herunder sikkerhedspatches hele applikationsinfrastrukturen inklusive operativsystem, database, applikationsserver, mm. Hvordan laves dokumentation og ændringshåndtering? Hvordan dokumenteres miljøet og hvordan laves der ændringshåndtering (change management)? Hvilken support er nødvendig? Hvilken grad af support er nødvendig for infrastrukturen og kan cloud leverandøren yde denne? Og hvem skal supportere applikation og resten af infrastrukturen herunder software platformen? Er der behov for at tilføre infrastrukturekspertise? Kan cloud leverandøren yde bistand ved opbygning af infrastrukturen eller er der behov for at få tilføjet infrastrukturekspertise på anden vis?

26 Appendix: 26 AWS ønsker og problemer > Nedenfor er opsamlet problemer og ønsker til forbedring af AWS som er samlet op undervejs i processen. Uhensigtsmæssigheder/Ønsker til forbedringer: Ingen konsoladgang til instanserne og dermed ikke adgang til at se om en instans faktisk booter eller om den smider fejl At en instans ikke genstarter når den går ned Hvis en instans dør (fysiske nedbrug f.eks.) så er den væk for altid Elastic Load Balancer servicen kan ikke sættes op med IP restrictions - samt den IP man ser på klient maskinerne er load balancerens IP og ikke den ægte klient IP. Elastic Load Balancer servicen er meget dum og kan ikke finde ud af prioritering af trafik til servere (f.eks. efter svartid). Problemer: Langsom genstart af instanser i det hele taget har været nødt til at forsøge at reboote igen (op til 10 gange) Problemer med at starte officiel AMI med Open- Solaris 64 bit i eu-west-1a zonen (15 dage) Læs her 6 Problem med at starte egen MySQL AMI i begge zoner i EU. Der har været mange forsøg fra AWS, hvor man mener at have lavet quickfixes, men disse har ikke virket. Load balancer døde og sendte ikke trafik videre. Vi var nødt til at genetablere load balancer. For tidlig indmelding af server i load balancer - anerkendt fejl af AWS Læs her 7 Uhensigtsmæssig konfiguration af load balancer med flere availability zones gav lejlighedsvis lange svartider vores fejl, men dårligt dokumenteret Kontakt til server mistet blev reetableret via AWS support Læs her 8 Lejlighedsvis problem med at en instans ikke starter rigtigt Læs her 9 6 developer.amazonwebservices.com/connect/thread.jspa?threadid=42867&tstart=0 7 developer.amazonwebservices.com/connect/message.jspa?messageid=170733# developer.amazonwebservices.com/connect/thread.jspa?messageid=173452&# developer.amazonwebservices.com/connect/message.jspa?messageid=169954#169954

27 > Kontaktoplysninger For yderligere oplysninger, kontakt: IT- og Telestyrelsen Holsteinsgade 63 DK-2100 København Ø Telefon: Fax: