UNDERBILAG 6-1 CSC PRINCIPPER OG FORUDSÆTNINGER FOR SLA- MONITORERING

Transkript

1 UNDERBILAG 6-1 CSC PRINCIPPER OG FORUDSÆTNINGER FOR SLA- MONITORERING LEVERING, DRIFT, VEDLIGEHOLDELSE OG SUPPORT AF ET PRAKSISSYSTEM REGION HOVEDSTADEN, REGION SJÆLLAND, REGION SYDDANMARK, REGION MIDTJYLLAND, REGION NORDJYLLAND, KOMBIT 15. NOVEMBER 2013 CSC Scandihealth A/S den 15. november 2013 Side 1 af 15

2 INDHOLDSFORTEGNELSE 1 Formål Grundprincip i SLA-monitorering Arkitektur og komponenter... 5 BAC Gateway (BAC GW)... 5 BAC Data Processing Server (BAC DPS)... 5 BAC Database (BAC DB)... 5 Business Process Monitor (BPM) Placering af BPM maskinerne I forsyningspunktet (standard) På slutbrugerlokationer (option) De syntetiske transaktioner Valg af transaktioner Måleresultater AVAILABILITY PERFORMANCE Percentil-beregning Måling af svartider Forudsætninger Teknik Monitordata, i kundens produktionsmiljø CSC Scandihealth A/S den 15. november 2013 Side 2 af 15

3 PRINCIPPER OG FORUDSÆTNINGER FOR AUTOMATISK MONITORERING AF AVAILABILITY OG PERFORMANCE AF SYSTEMER DER DRIFTES AF CSC SCANDIHEALTH A/S 1 FORMÅL Det primære formål med availability- og performancemonitorering er, entydigt og objektivt, at kunne dokumentere at CSC Scandihealth overholder kravene i den Service Level Agreement (SLA) der er aftalt med kunden, set ud fra en slutbrugers perspektiv. Formålet er altså ikke realtidsovervågning af servere, netværk og andre systemkomponenter, men derimod en retrospektiv monitorering og rapportering af systemernes tilgængelighed og svartider som oplevet af en slutbruger. Sekundært kan resultaterne af de løbende målinger, der danner grundlaget for SLA-Monitoreringen anvendes som et supplement til den traditionelle driftsovervågning, således af hvis et system har været utilgængeligt eller har haft forringede svartider i en periode, kan der rejses en alarm i overvågningssystemet. CSC Scandihealth A/S den 15. november 2013 Side 3 af 15

4 2 GRUNDPRINCIP I SLA-MONITORERING Den grundlæggende metode til SLA-monitorering er en række syntetiske transaktioner der udføres mod systemet der monitoreres med faste intervaller typisk hvert 5. minut. En syntetisk transaktion er et script, baseret på den anvendte protokol mellem klient og server, der indeholder de funktions-/servicekald som en virkelig klient ville generere ved udførelse af den pågældende brugertransaktion. En syntetisk transaktion emulerer således en virkelig klient, og afvikles fra en dedikeret server (en probe) i kunden miljø. Måleresultaterne sendes fra proben i kundens miljø tilbage til en central server hos CSC Scandihealth, hvor efterfølgende databehandling og rapportering foretages. CSC Scandihealth A/S den 15. november 2013 Side 4 af 15

5 3 ARKITEKTUR OG KOMPONENTER CSC Scandihealth anvender værktøjet HP Bussiness Availability Center (BAC) til SLA-monitorering. BAC består af en række delkomponenter: BAC Gateway (BAC GW): står for kommunikation med alle prober i kundernes miljøer (deployment af scripts og indlæsning af måleresultater). BAC Data Processing Server (BAC DPS): behandler måleresultater, beregner SLA status og genererer rapporter. BAC Database (BAC DB): lagring af måleresultater, SLA definitioner mv. Business Process Monitor (BPM): proben der afvikler de syntetiske transaktioner og sender måleresultaterne tilbage til BAC GW. Én BPM maskine kan monitorere flere forskellige systemer. Figur 1: Principskitse af SLA-monitorering BAC suiten indeholder desuden produktet SiteScope, der anvendes til komponent- og IsAlive-overvågning af et systems delkomponenter, fx en webserver, en webservice eller database. Dette produkt indgår pt. ikke i CSC Scandihealths SLA-monitorering. Dette er valg fordi en SLA-monitorering er overvågning af et systems svartider og tilgængelighed set ud fra et slutbrugerperspektiv. En SLA-monitorering har således fokus på slutbrugerfunktionalitet og ikke de enkelte delkomponenter i systemet. En komponentovervågning derimod, er en monitorering af et systems delelementer, med henblik på en hurtig og præcis reetablering af service i tilfælde af driftsfejl/-forstyrrelser og indgår derfor i den løbende driftsovervågning. CSC Scandihealth A/S den 15. november 2013 Side 5 af 15

6 4 PLACERING AF BPM MASKINERNE For at komme så tæt som muligt på den brugeroplevede svartid og tilgængelighed af et system skal BPM maskinerne placeres på samme lokation (netværkssegment) som de virkelige brugere. Hvis SLAmonitoreringen derfor skal være komplet, skal der placeres en BPM maskine på alle lokationer hvor der er brugere på det pågældende system. Hvis der er forskel på tilgængelighed og performance mellem de forskellige lokationer kan det kun skyldes lokale forhold, typisk netværkskonfiguration og båndbredde, og det er uden for CSC Scandihealths ansvarsområde, og er ikke omfattet af SLA en. SLA en fastlægger som udgangspunkt systemets tilgængelighed og performance i forsyningspunktet, det vil sige fra den eksterne snitflade på systemets applikationsserver(e) som alle systemets klienter kommunikerer med. 4.1 I forsyningspunktet (standard) CSC Scandihealth vil derfor som standard etablere SLA-monitorering af systemet i forsyningspunktet, og det vil sige at BPM maskinen opstilles på samme lokation som systemets applikationsserver(e). 4.2 På slutbrugerlokationer (option) Som en option kan CSC Scandihealth tilbyde, at BPM-maskiner på alle de slutbrugerlokationer som kunden ønsker der skal inkluderes i SLA-monitoreringen, med separat rapportering for hver enkelt lokation, men det vil altid være målingen i forsyningspunktet der er gældende i forhold til de aftalte krav i SLA en. CSC Scandihealth A/S den 15. november 2013 Side 6 af 15

7 Figur 2: Skitse af CSC Scandihealth SLA-monitorering Af flere grunde kan det anbefales at der også opstilles BPM-maskiner på alle, eller centrale slutbrugerlokationer hos kunden. For det første vil måleresultaterne herfra være det tætteste man kan komme på de brugeroplevede svartider og tilgængelighed, og det er dem der i det daglige er interessante for kunden. Endvidere vil det være langt nemmere ved de periodiske driftsstatusmøder mellem CSC Scandihealth og kunden at forholde sig til systemets svartider og tilgængelighed hvis der også foreligger måleresultater fra de forskellige slutbrugerlokationer. Endelig vil en forskel i måleresultaterne fra de forskellige slutbrugerlokationer, enten permanent eller varierende over tid, være et enestående grundlag for at optimering de lokale netværkskonfigurationer, og monitorere effekten af en eventuel ændring. CSC Scandihealth A/S den 15. november 2013 Side 7 af 15

8 5 DE SYNTETISKE TRANSAKTIONER Som nævnt emulerer en syntetisk transaktion en brugertransaktion udført i en virkelig klient af en virkelig bruger og er implementeret i et script, der indeholder funktions- og servicekald baseret på den anvendte protokol (fx HTML/HTTP, SOAP, CITRIX og TN3270). Scriptet genereres af værktøjet Vitrual User Generator (Vugen), der også er en del af BAC suiten, ud fra en optagelse af protokolkommunikation mellem en klient og systemet der skal monitoreres, samtidigt med at en virkelig bruger gennemfører brugertransaktionen. Figur 3: optagelse af syntetiske brugertransaktioner med værktøjet Vugen Efter optagelsen modificeres scriptet med henblik på automatisk og repetitiv afvikling og deployes til BPM maskinen, hvor det efterfølgende afvikles med faste intervaller. 5.1 Valg af transaktioner Valget af de brugertransaktioner der skal indgå i SLA-monitoreringen aftales med kunden og skal ikke udgøre en komplet funktionel test af hele systemet, men skal derimod være udvalgt således, at det samlede CSC Scandihealth A/S den 15. november 2013 Side 8 af 15

9 sæt af transaktioner med rimelig sikkerhed kan afgøre om systemet som helhed er fungerende og tilgængeligt. Udvælgelsen af transaktioner foretages ud fra følgende kriterier: Centrale og ofte benyttede transaktioner (logon anbefales altid at være en af transaktionerne) Særligt vigtige/kritiske transaktioner Ingen opdaterende transaktioner (se note nedenfor) Typisk 3-5 pr. kunde pr. system (aftales med kunden) Note: Da de syntetiske transaktioner udføres i produktionssystemer, anbefales det af sikkerhedshensyn kun at vælge Vis og Søg transaktioner. CSC Scandihealth A/S den 15. november 2013 Side 9 af 15

10 6 MÅLERESULTATER Når en transaktion afvikles af BPM maskinen kan der overordnet set være to udfald: OK: transaktionen blev gennemført uden fejl, og resultatet der returneres til BPM maskinen er det forventede (validering ok) FEJL: der opstod en fejl under gennemførsel af transaktionen. En fejl kan her underopdeles i følgende tre undergrupper: timeout: transaktionen blev ikke gennemført inden for et foruddefineret tidsrum teknisk fejl: der opstod en teknisk fejl i den funktion/service der blev kaldt i systemet der monitoreres validringsfejl: transaktionen blev gennemført uden timeout og tekniske fejl, men resultatet der returneres til BPM maskinen var ikke som forventet 6.1 AVAILABILITY Kun hvis transaktionen er OK regnes systemet der monitoreres som værende tilgængeligt, for så vidt angår den pågældende transaktion. BAC opsamler løbende måleresultater for hver enkelt transaktion, og beregner et samlet resultat for en periode, i første omgang for hver transaktion der indgår i monitoreringen. Ud fra de enkelte transaktioners resultater beregnes et samlet resultat for hele systemet efter en bestemt beregningsregel. Som standard anvendes beregningsregelen Group Average Value. Det betyder at den samlede tilgængelighed for hele systemet er lig med den gennemsnitlige tilgængelighed af de enkelte transaktioner. Monitoreringen af et system består at tre transaktioner og de individuelle transaktioners tilgængeligheder for en periode er: Logon 99,99% (Best Child) Vis personoplysninger 99,85% Vis kontaktoplysninger 98,45% (Worst Child) I dette tilfælde vil den samlede status for systemet være en tilgængelighed på 98.45% baseret på beregningsreglen Worst Child, 99,99% med Best Child og 99,34% Group Average Value (simpel middelværdi). Eksemple 1: Beregning af tilgængelighed Tilgængeligheden beregnes for en periode bagud i tid (seneste time, seneste dag, seneste uge, seneste måned etc.) Standard for de periodiske rapporter til CSC Scandihealths kunder er seneste måned. CSC Scandihealth A/S den 15. november 2013 Side 10 af 15

11 Eksempel 2: ovenstående viser et en tilgængelighedsgraf for en måned med en opløsning på én dag. Ud over at grafen viser tilgængeligheden for hver dag i måneden, kan man også se hvorledes tilgængeligheden er i forhold til kravet i SLA en. I dette tilfælde er kravet til tilgængelighed minimum 98%, symboliseret ved den vandrette røde linie benævnt Failed. Er søjlen over linien er kravet opfyldt og farven er grøn. Havde der været dage hvor tilgængeligheden havde været under 98% ville søjlen have været farvet rød. Det er muligt at have forskellige krav til tilgængelighed for dagen, ugen, måned, kvartal etc, men standard i CSC Scandihealth er kun ét krav til måneden. Det er endvidere muligt at have individuelle krav til tilgængelighed for de enkelte transaktioner, men standard er, at der er specificeret ét krav til hele systemet, og dermed et og samme krav til alle transaktioner. 6.2 PERFORMANCE Kun hvis transaktionen er OK indgår den målte svartid i beregningen af performance. Hvis en transaktion fx tager ekstremt lang tid og fejler med en timeout fejl, vil svartiden således ikke indgå i beregning af performance, idet transaktionen i dette tilfælde vil blive regnet for utilgængelig (og derned indvirke negativt på availability). Som for availability opsamler BAC løbende de målte svartider for hver enkelt transaktion, og performance beregnes på tilsvarende vis først for den enkelte transaktion, og dernæst for hele systemet vha. en beregningsregel, men beregningen er lidt mere kompliceret end ved availability. Det skyldes for det første at det ikke er muligt at bestemme den dårligste transaktion alene ud fra et absolut tal for svartiden, men kræver også en sammenligning med kravet til den pågældende transaktion. Eksemplevis er det ikke muligt at sige om en svartid på 2,8 sek. for en simpel transaktion er bedre eller dårligere end en svartid for en kompleks transaktion på 7,2 sek, før end de sammenlignes med de tilhørende svartidskrav på hhv. max 3 og max. 6 sek. Først da kan man konstatere at den første transaktion var god, og den sidste ikke. Dernæst er svartidskrav typisk specificeret som en percentilværdi, hvilket betyder at selvom en eller få enkelte CSC Scandihealth A/S den 15. november 2013 Side 11 af 15

12 svartider for en transaktion oversiger svartidskravet, kan percentilen godt være overholdt (se også afsnittet Percentil-beregning). Svartiden måles i sekunder, men performance beregnes som en procentuel værdi, der viser hvor mange procent af alle svartider for en transaktions der har overholdt svartidskravet. Her anvendes også beregningsreglen Group Average Value som standard ved beregning af performance for det samlede system. Eksempel 3: ovenstående viser en performancegraf en måned med en opløsning på én dag: Ud over at grafen viser performance for hver dag i måneden, kan man også se hvorledes performance er i forhold til kravet i SLA en. Her er kravet til performance at minimum 95% af alle svartider skal overholde de specificerede svartidskrav (svarende til 95-percentilen), symboliseret ved den vandrette røde linie benævnt Failed. Søjlens højde angiver hvor mange procent af de målte svartider der har overholdt svartidskravet for transaktionerne. Farven angiver om kravet er opfyldt. Det er muligt at have forskellige krav til performance for dagen, ugen, måned, kvartal etc, men standard i CSC Scandihealth er kun ét krav til måneden. Det er endvidere muligt at have individuelle krav til performance for de forskellige transaktioner, i form af forskellige percentiler, men normalt opgives svartidskrav altid ved samme percentil, typisk 95. Derimod er der normalt forskellige svartidskrav, afhængig af hvilken af de tre klasser transaktioner tilhører: simple, middel og komplekse Percentil-beregning Percentiler håndteres lidt specielt i BAC. Traditionelt beregnes en svartid ud fra en given percentilværdi som så kan sammenlignes med et svartidskrav. Fx kunne 95-percentilen for en transaktion være beregnet til 2.8 sek, som så kan sammenlignes med et svartidskrav på fx 3,0 sek. I BAC gøres det omvendt, idet CSC Scandihealth A/S den 15. november 2013 Side 12 af 15

13 man ud fra et svartidskrav beregner percentilen. I BAC specificeres fx et svartidskrav på 3,0 sek og en percentilværdi på 95. BAC optæller så hvor mange målte svartider der overholder svartidskravet, beregner hvor mange procent disse udgør af alle svartider (=søjlens højde), og sammenligner resultatet med percentilværdien på 95 (=søjlens farve). Hvis søjlens højde fx er 98,9%, betyder det, at 98,9-percentilen er 3,0 sek., eller sagt på en anden måde, så er 98,9 procent af alle målte svartider mindre end eller lig med 3,0 sek, og søjlens farve vil være grøn. Hvis søjlens højde fx er 94,5 vil søjlens farve med en percentilværdi på 95 være rød Måling af svartider De i BAC målte svartider for en brugertransaktion vil kunne være lidt mindre end de svartider en virkelig bruger vil opleve ved udførelsen af den samme brugertransaktion. Årsagen er, at det script der emulerer brugertransaktionen ikke indeholder alle klient-side tider til intern datamanipulation, opbygning af skærmbilleder o.l., men kun de udgående kald af funktioner og services mod backend systemet. Problemstillingen kan illustreres ved nedenstående eksempel på en logon transaktion. En brugertransaktion består typisk af et antal subtransaktioner. I tilfældet logon hentes fx også informationer om tilgængelige miljøer, rettigheder og klientopsætninger. Brugeren vil opleve en svartid der er summen af alle aktiviteterne i klienten og backend systemet, fra det øjeblik der klikkes på knappen LOGON til CSC Scandihealth A/S den 15. november 2013 Side 13 af 15

14 applikations hovedskærmbillede vises på skærmen. Det tilsvarende script vil kun indeholde de udgående servicekald, og den svartid BAC vil måle, er fra Subtransaktion A sendes af sted fra klienten (proben) til svaret fra Subtransaktion C er modtaget. Vugen recorderen registrerer inaktivitet i form af tænketid (Thinktime) og kunne derfor i princippet registrere tiderne 1, 5, 8, 11 og 12, men tænketid 1 før første, og tænketiderne efter sidste udgående transaktion ignoreres af Vugen. Tiderne 5 og 8 registreres kun hvis tiden er større end 1 sek., men det er næsten aldrig tilfældet idet de typisk er på få ms. Resultatet er derfor, at den svartid BAC reelt måler, er backend systemets svartid plus netværkstid. Forskellen på den i BAC målte svartid og den brugeroplevede vil i de fleste tilfælde være neglicibel, men ved SOA protokoller, så som SOAP og RMI, kan den i særlige tilfælde være flere sekunder helt afhængig af antallet af subtransaktioner, implementationen af klienten og størrelsen af klient PC en. Det er desværre ikke muligt på enkelt vis at bestemme hvor stor afvigelsen er, for var det tilfældet, kunne der nemt kompenseres herfor i scriptet ved manuelt at indsætte en tænketid. For protokollen HTML/HTTP afhænger afvigelsen kraftigt af hvor meget javascript der indgår i websiderne. For protokoller som RDP, Citrix og TN3270 vil de målte svartider være præcist som de vil opleves af en virkelig bruger, idet det her er muligt at måle tiden fra en brugeraktion iværksættes (fx klik på en knap) til et bestemt skærmbillede er vist. CSC Scandihealth A/S den 15. november 2013 Side 14 af 15

15 7 FORUDSÆTNINGER Følgende forudsætninger skal være opfyldt for at SLA-monitorering vha. BAC kan lade sig gøre: 7.1 Teknik 1. Der skal opstilles en BPM maskine i systemts forsyningspunkt, og hvis det ønskes, en eller flere BPM maskiner i kundens miljø på den eller de slutbrugerlokationer der skal indgå i SLAmonitoreringen. BPM maskinen kan være fysisk eller virtuel. 2. Der skal etableres netværksmæssigt adgang mellem BPM maskinerne i kundens miljø og systemet der skal monitoreres. Systemet kan være placeret hos CSC Scandihealth eller hos kunden selv. 3. Der skal etableres netværksmæssigt adgang mellem BPM maskinerne og BAC GW serveren hos CSC Scandihealth. 4. På BPM maskinerne skal der oprettes en lokal administratorkonto som kan anvendes af CSC Scandihealth ved installation af BAC software mv. 7.2 Monitordata, i kundens produktionsmiljø 1. I systemet, der skal monitoreres, skal der oprettes en monitorbruger ved navn cscmonitor som de syntetiske transaktioner kan logge på med. Monitor-brugeren skal have de fornødne adgange og rettigheder til at kunne afvikle de syntetiske transaktioner. 2. I systemet, der skal monitoreres, skal der oprettes en monitorpatient (testpatient) som de syntetiske transaktioner kan anvende, og monitorpatienten skal være beriget med de nødvendige testdata for at de syntetiske transaktioner kan gennemføres. CSC Scandihealth A/S den 15. november 2013 Side 15 af 15