drift och support
Sida 2 av 13 Innehåll 1 INLEDNING... 3 1.1 SYFTE... 3 1.2 OMFATTNING... 3 2 NULÄGE... 3 2.1 DRIFT OCH SUPPORT... 3 3 APPLIKATIONSDRIFT OCH CENTRAL SUPPORTFUNKTION... 4 3.1 DEFINITIONER... 4 3.2 KOSTNADSDRIVANDE OSÄKERHETSFAKTORER... 4 3.3 METODER... 5 4 SERVERDRIFT... 6 4.1 DEFINITION... 6 4.2 KOSTNADSDRIVANDE OSÄKERHETSFAKTORER... 6 4.3 METOD... 7 5 UNDERLAG FÖR KOSTNADSBERÄKNING AV SERVERDRIFT... 8 5.1 BELASTNING OCH TRANSAKTIONER... 8 5.2 VERKSAMHETENS KRAV... 10 5.3 DRIFTMILJÖER... 11
Sida 3 av 13 1 Inledning Ladoksystemet ägs och förvaltas idag av Ladokkonsortiet medan varje lärosäte själva ansvarar för drift och förvaltning av sin installation av Ladok. Nästa generation av studieadministrativt systemstöd är under utveckling i Ladok3-projektet. Det nya systemet kommer att användas som en gemensam installation vilket ställer krav på ett centralt ansvar för driften av Ladok. Projektet Förnyad förvaltning har ett uppdrag ta fram ett förslag på en förvaltningsorganisation, en rekommendation för framtida drift av Ladok samt en kostnadsuppskattning för både organisation och drift. 1.1 Syfte Syftet är att ge lärosätena en förståelse för vad som är kostnadsdrivande och vilka osäkerhetsfaktorer som finns kring. 1.2 Omfattning Detta dokument beskriver nuläget för arbetet med kostnadsuppskattning för applikationsoch serverdrift samt för central supportfunktion. Innan sommaren 2013 ska en kostnadsuppskattning redovisas för den nya förvaltningsorganisationen inklusive. Dokumentet skickas tillsammans med rapporten för ändamålsenlig drift till systemägare för Ladok och IT-chefer. Övriga primära målgrupper förvaltningschefer och Ladokansvariga. 2 Nuläge 2.1 Drift och support Varje lärosäte tecknar egna avtal med ett driftställe för drift av den egna installationen av Ladok. Driften för ett eller flera lärosäten sker vid ett av Ladokkonsortiets tre certifierade driftställen. Lunds Universitet ansvarar för drift åt 15 lärosäten, Uppsala Universitet 17 lärosäten och Umeå Universitet 6 lärosäten. De flesta lärosäten köper idag både applikationsdrift och serverdrift av sin driftleverantör. Det finns ingen gemensam definition av driftsformerna men i de enskilda avtalen är åtaganden definierade. Kostnaden för drift av nuvarande Ladok är i genomsnitt 479 000 kr/år för de 27 lärosäten som svarat i den enkät som skickades ut under 2012. En uppskattning av den totala driftkostnaden för nuvarande Ladok blir för 39 lärosäten 39*479 000 = 18,7 Mkr. Det är svårt att bedöma hur relevant den här uppskattningen är, dels för att alla lärosäten inte har svarat och dels för att en del av kostnaden (hantering av Noveau-klienter) inte är inkluderad för vissa lärosäten.
Sida 4 av 13 3 Applikationsdrift och central supportfunktion Definitioner på applikationsdrift och central supportfunktion återfinns i rapporten även i rapporten Ändamålsenlig drift. 3.1 Definitioner 3.1.1 Applikationsdrift Med applikationsdrift avses driftrelaterade arbetsuppgifter kopplat till applikationer och andra programvaror som är kopplade till dessa. Applikationsdrift omfattar driftleveranser för installation, drift, underhåll och övervakning av applikationsprogramvara och relaterad middleware 1 samt databaser. Arbetet inom delområdet omfattar teknisk hantering (analys, planering, utförande/åtgärd, installation, konfiguration, support, felsökning och problemlösning, uppföljning, dokumentering, rapportering) av omfattade programvaror, hantering av körningar för bearbetning av stora datamängder och certifikatshantering samt manuella informationsuttag. I den tekniska hanteringen ingår hantering av relaterad IT-säkerhet. Vidare ingår även inköp. Arbetet beskrivs och styrs vanligen av processerna incidenthantering, problemhantering, ändringshantering, installation och konfiguration, prestanda- och kapacitetshantering samt styrning av leverantör. 3.1.2 Central supportfunktion för Ladok Den centrala supportfunktionen ska hantera och kanalisera ärenden från de lokala supportfunktionerna, utvecklings- och driftsorganisationerna samt från den verksamhetsnära förvaltningen. Den blir då 2nd line support för Ladokärenden. Studenter och lärosätenas personal ska vända sig till lärosätets lokala supportfunktion för Ladok. Den lokala supportfunktionen kan sedan vid behov vända sig till den centrala supportfunktionen för Ladok. Den ska även hantera ärenden som kommer från utvecklings- och driftsorganisationerna samt från den verksamhetsnära förvaltningen. Den centrala supportfunktionen ska hantera fyra typer av ärenden: Beställningar (certifikat, manuella informationsuttag m m) Ändringsbegäran Fel Frågor 3.2 Kostnadsdrivande osäkerhetsfaktorer I dagens situation är inte lärosätena helt beroende av leverantören för support eftersom varje lärosäte har tillgång till sin egen installation. 1 Termen middleware används för att beskriva olika produkter som fungerar som en länk mellan två program.
Sida 5 av 13 3.2.1 Tillgänglighet Med en central installation och en central supportfunktion som till delar kommer att ersätta dagens lokala support kan kravet på tillgänglig support komma att öka. Vid kravutformningen för applikationsdrift ska kravet på tillgänglighet preciseras och beräknas. 3.2.2 Releasehantering Det är oklart hur mycket resurser varje ny release kommer att kräva. En jämförelse med befintlig Ladok går inte att göra eftersom det är en helt ny teknik. Det är viktigt att vid varje ny release resursplanera och följa upp resursåtgången. Detta ger mätetal som kan användas inför varje förvaltningsperiod. 3.3 Metoder Här redovisas de metoder som har valts och i vilket skede undersökningarna befinner sig. 3.3.1 Jämföra med befintligt Ladok De befintliga driftställena har uppskattat hur många timmar de lägger ned på applikations. Uppsala har en organisatorisk uppdelning av ansvarsområdena och anser sig ha en ganska bra uppfattning om antalet timmar medan Lund och Umeå har gjort en grov uppskattning då de inte organisatoriskt har delat på uppgifterna mellan applikations- och serverdrift. Dessutom kan det finnas olika uppfattningar i om vad som ingår i applikations- respektive serverdrift. Totalt beräknas att ca 10 000 timmar läggs ned på applikations. Resultat Det är svårt att jämföra systemen då de är uppbyggda på helt olika sätt. Det innebär att hanteringen av applikationerna inte kan jämföras. För nya Ladok kommer allt att ligga på serversidan och ska installeras, uppgraderas, konfigureras, driftas och övervakas centralt. Befintliga Ladok hanteras både av driftställena och av lärosätena. Beroende på ifall lärosätena använder sig av Nouveau-klienter eller av Terminal Server/Citrix utförs hantering endera av lärosätet eller av driftställena. Eftersom uppskattningen av antalet timmar endast avser driftställenas arbetsinsats kan inte en korrekt uppskattning göras. Applikationsdrift kräver framför allt personella resurser och den största kostnaden ligger därför i personal. En jämförelse med befintliga Ladok ger inte ett trovärdigt resultat och lämnas därmed. 3.3.2 Jämförelse med NyA Utredningen har kommit fram till att en jämförelse med NyA är mer relevant. Applikationerna har mer likheter med varandra ur ett driftsperspektiv och applikationsdriften ligger hos en part. UHR ansvarar även för support och delar av applikationshanteringen. En jämförelse har startat där UHR ska uppskatta en kostnad för de ingående delarna installation, drift, underhåll, övervakning och support. Därefter ska en jämförelse och uppskattning göras mot nya Ladok
Sida 6 av 13 4 Serverdrift Definition på serverdrift återfinns även i rapporten Ändamålsenlig drift. 4.1 Definition Serverdrift omfattar driftleveranser för kontinuerlig drift och övervakning av serverresurser driftleveranser för kontinuerlig drift och övervakning av lagringsmiljöer (SAN 2 /disk) samt säkerhetskopiering/återställning inklusive långtidsbackup hantering av teknisk kommunikation (e-post, nätverk, brandväggar, DNS 3, extern kommunikation från systemet) Arbetet omfattar teknisk hantering (analys, planering, utförande/åtgärd, installation, konfiguration, support, felsökning och problemlösning, uppföljning, dokumentering, rapportering) av driftmiljöns serverutrustning (hårdvara, operativsystem, systemprogramvara), av lagringsutrustning (hårdvara, systemprogramvara) och annan utrustning. Vidare ingår livscykelhantering, hantering av relaterad IT-säkerhet och inköp. Arbetet beskrivs och styrs vanligen av processerna incidenthantering, problemhantering, ändringshantering, installation och konfiguration, prestanda- och kapacitetshantering samt styrning av leverantör. 4.2 Kostnadsdrivande osäkerhetsfaktorer Det finns en mängd osäkerhetsfaktorer som inte kan uppskattas i dag och som kan påverka prestandan. Detta i sin tur kräver mera hårdvara som påverkar kostnaderna. 4.2.1 Mätningar I och med att applikationen inte är klar för användning kan inte mätningar göras idag. För att underlätta framtida prestandakrav är det viktigt att mätningar planeras och utförs så fort det är möjligt. För nya Ladok kan mätningar påbörjas dels efter produktionssättning av del 1 (årsredovisning) och dels i migrerings- och integrationstestmiljön (MIT-miljö). MIT-miljön används för att testa migreringen av data från befintligt Ladok till nya Ladok samt för att testa integrationer. Enligt tidplanen ska del 1 produktionsättas på lärosätena i oktober 2015. Systemet ska då födas med information från befintliga Ladok. När systemet är igång sker inmatning av information och då kan mätning av belastningen börja. Med kontinuerlig mätning kan sedan uppskattning av prestandakrav och belastning göras. Mätningar i MIT-miljön kan påbörjas i början av 2015. Tillsammans bör detta ge bild av grundbelastningen. 2 Storage Area Network används för att beskriva nätverk vars enda uppgift är att distribuera och lagra data 3 Domain Name System eller domännamnssystemet, är ett system för att förenkla adressering av datorer på IP-nätverk som till exempel Internet.
Sida 7 av 13 4.2.2 Användarbeteende Studenter och personal har tillgång till Internet via datorer, smartphones och surfplattor när som helst och därmed även nya Ladok och dess tjänster. Nya Ladok kommer att ge möjlighet för ett decentraliserat arbetssätt vilket kommer att betyda helt nya användarbeteenden. Idag går det inte att förutse hur arbetsprocesserna och användningen kommer att utvecklas. Beroende på hur systemet kommer att användas kommer det att ställa krav på prestandan. Ett användarbeteende kan loggas och det kan i sin tur ge underlag för analyser. 4.2.3 Tjänsternas användning De enskilda tjänsternas användning och belastning vid olika tidpunkter ger underlag för analys av prestandakrav. Även den trafik som genereras mellan olika tjänster kan mätas. 4.2.4 Integrationer Det är oklart hur lärosätenas integrationer kommer att se ut. Användningen av integrationsmöjligheterna kommer att påverka prestandan. En kontroll att användningen är relevant ska göras kontinuerligt. Här kan olika loggar användas som till exempel APIloggar, GUI-loggar och studentloggar. 4.2.5 Avbrottshantering Utifrån överenskomna servicenivåer kan mätningar av tillgänglighet både av den tekniska plattformen och av systemet. UHR har idag överenskomna servicenivåer för NyA som innebär övervakning kl. 07 22 alla dagar. Åtgärder görs på de larm som inkommer för att upprätthålla avtalade servicenivåer. Vid kravutformningen för serverdrift av Ladok ska detta preciseras. 4.2.6 Katastrofhantering Idag finns inget uttalat behov av katastrofhantering vid till exempel brand. Valet av nivå för katastrofberedskap påverkar kostnaderna. Vid kravutformningen för serverdrift ska kravet på redundanta miljöer vara preciserat. 4.3 Metod Ett antal parametrar för kostnadsuppskattning har identifierats och beskrivits. Efterhand har några lämnats medan andra har utvecklats. I kapitel 5 redovisas det underlag som för närvarande är tillgängligt och relevant för det fortsatta arbetet med kostnadsuppskattning.
Sida 8 av 13 5 kostnadsberäkning av serverdrift 5.1 Belastning och transaktioner Belastningstoppar kommer främst att vara i samband med kursregistrering: 10 jan 31 jan 20 aug 15 sept. Övriga belastningstoppar kommer att vara i de perioder när examen kommer att begäras och vid resultatredovisning I samband med antagningen kommer främst antagningssystemet att belastas och Ladok3 kommer påverkas i viss mån. Förmodligen kommer Ladok3 att användas mer (än nuvarande Ladok) för att kika på antagningen. Varje lärosäte kommer att ha en dedikerad uppföljningstjänst. Användningen av denna kommer att ha betydelse på belastningen. En direkt access dagtid kommer att öka belastningen. Större lärosäten kommer att utnyttja detta mer än de mindre, vilka i större omfattningen kommer att tanka ned data nattetid. En ansats till jämförelse med användningen av dagens LPW-tjänster har gjorts. Men den statistiken visar på orealistiska data vilken kan bero på andra användningsområden av tjänsterna. Med andra ord kan inte dagens användning av motsvarande tjänster användas för uppskattning av belastning. Nya Ladok består av ett antal autonoma tjänster, som tillsammans bildar systemet. För att få en uppfattning om belastning i systemet behöver man analysera de olika tjänsterna och de användningsmönster som gäller för dem. Nedanstående figur visar de hittills definierade olika verksamhetstjänsterna i Ladok. Varje tjänst kan ses som ett eget litet system med egen databas. Arkitekturen möjliggör distribuering av de olika tjänsterna över flera virtuella/fysiska servrar. Det är även möjligt att sätta upp flera parallella tjänster för att möjliggöra uppskalning av en enskild tjänst. Däremot använder de parallella tjänsterna gemensam databas. Dels görs olika anrop som resultat av användarinteraktion (sökning, läsning och uppdateringar) mot systemet och dels skickas meddelanden mellan tjänsterna som resultat av ändring som görs i tjänsterna.
Sida 9 av 13 I följande sektioner beskrivs vilka och antalet transaktioner i systemet på verksamhetsnivå som bör kunna hanteras för en antagningsomgång. Eftersom beskrivningen är på verksamhetsnivå kommer antalet transaktioner mot respektive tjänsts databas att vara större, en grov uppskattning kan vara med en faktor tre. 5.1.1 Studentinformation Har en belastningstopp i samband med antagningsperioder. Varje antagning (t ex student på kurstillfälle) genererar en fråga och skapar ibland en ny student. Antal frågor till Studentinformation om student: 400 000 st. Varje ny student resulterar i en händelse: 100 000 st. Anrop: 400 000 st. Händelser: 100 000 st. 5.1.2 Utbildningsinformation Har en belastningstopp i samband med antagningsperioder. Varje antagning (t ex student på kurstillfälle) genererar en fråga till Utbildningsinformation för att hämta motsvarande utbildningsidentitet. Antal frågor till Utbildningsinformation om utbildningar: 400 000 st. I Utbildningsinformation skapas och ändras utbildningar och skapar motsvarande händelser, försumbart i sammanhanget. Anrop: 400 000 st. Händelser: 20 000 st. 5.1.3 Studiedeltagande Studiedeltagande har en belastningstopp i samband med antagningsperioder. För varje antagning (t ex student på kurstillfälle) registreras en händelse och för varje ny student registreras en händelse. Hämtar händelser från Etablering för antagningar per omgång: 400 000 st. Hämtar händelser från Studentinformation om nya studenter: 100 000 st. Hämtar händelser från Utbildningsinformation om nya förändrade utbildningar, försumbart i sammanhanget. I och med antagningar ska studenten även gå in och registrera sig och därmed även söka upp och visa sin studiedeltagandeinformation: 400 000 st. Anrop: 400 000 st. Händelser: 500 000 st. 5.1.4 Resultat Har ingen större känd belastningstopp utan fördelar sig relativt jämt över läsåret. Resultat rapporteras in i olika omgångar i samband med tentamina, laborationer, etc. Antal dokumenterade resultat per år: 400 000 st. Hämtar händelser från Studiedeltagande om förändrade tillstånd: 400 000 st. Hämtar händelser från Studentinformation om nya studenter: 100 000 st. Hämtar händelser från Utbildningsinformation om nya förändrade utbildningar, försumbart i sammanhanget. Anrop: 400 000 st.
Sida 10 av 13 Händelser: 500 000 st. 5.1.5 Examen Har ingen större känd belastningstopp utan fördelar sig relativt jämt över året. Examina dokumenteras i olika omgångar utspritt över läsåret. Skapa antal examina per år: 100 000 st. Hämtar händelser från Resultat om dokumenterade resultat: 400 000 st. Anrop: 100 000 st. Händelser: 400 000 st. 5.1.6 Uppföljning När det gäller uppföljningsdelen kommer belastningen uteslutande vara beroende av vilket lärosäte som använder den och omfattningen på informationsuttaget. Vissa nämner att de kommer att spegla över hela databasen till lokalt datalager och där göra sina uppföljningar. Andra kommer kanske enbart att nytta den inbyggda årsredovisningen. Hämtar händelser från Resultat om dokumenterade resultat: 400 000 st. Hämtar händelser från Studiedeltagande om förändringar: 400 000 st. Hämtar händelser från Studentinformation om nya/ändrade studenter: 100 000 st. Hämtar händelser från Utbildningsinformation om nya förändrade utbildningar, försumbart i sammanhanget. Anrop: 20 000 st. Händelser: 900 000 st. 5.1.7 Etablering (Ladok Integration) Har en belastningstopp i samband med antagningsperioder. För varje antagning (t ex student på kurstillfälle) ställs mot Studentinformation en fråga och ibland skapas även en motsvarande ny student. Mot Utbildningsinformation en fråga om utbildningstillfälle och därefter skapas en antagningshändelse. Hämtar händelser på antagningar från NyA per omgång: 400 000 st. Hämtar nya studenter per omgång från Studentinformation: 100 000 st. Hämtar utbildningar från Utbildningsinformation: 100 000 st. Skapa händelser för varje antagning: 400 000 st. Anrop: 200 000 st. Händelser: 800 000 st. 5.2 Verksamhetens krav Ladok3-projektet har tagit fram icke-funktionella krav. Dokumentet innehåller en del krav som kan användas som underlag. Exempel på användbara krav: Kapacitet Skalbarhet Kommunikation Tillgänglighet Redundans
Sida 11 av 13 Distribuering Robusthet Loggning 5.3 Driftmiljöer Detta underlag grundar sig på ett antagande att vi under införandefasen mellan leverans 1 och leverans 3 har förutsättningar att analysera och mer i detalj uppskatta det verkliga behovet på kapacitet. Bedömningen är att konfigurationen ska ha tillräcklig kapacitet för denna period och baserat på erfarenhet kunna skalas upp vid behov. Nedan angivna underlag bör därför dubbleras för att säkerställa en tillräcklig budget för slutläget vid full drift åtminstone för produktionsmiljön. Alla miljöer som inte är angivna som virtuella är fysiska miljöer. Bedömningen baseras på Red Hat Linux miljö med 2 CPU och minst 4 kärnor av relevant serverhårdvara. 5.3.1 Leveransflöden Nedanstående figur visar de olika stegen i leverans av nya versioner och patchar, samt lärosätenas beroenden. Beroende på framtida ytterligare behov kan ovanstående flöde behöva kompletteras med fler miljöer. 5.3.2 Tillgänglighet Alla system behöver inte nödvändigtvis vara driftsatta samtidigt. Följande tidplan anger ungefärliga tider, kopplade till de olika leveranserna av Ladok, för respektive systems tillgänglighet. De exakta tiderna måste dock anpassas efter krav från den driftleverantör som väljs. Testmiljö ny version MIT-miljön tillgänglig från slutet av april 2013 Acceptanstestmiljö nov 2014 (inför första leverans till lärosätena) Utbildningsmiljö nov 2014 (inför första utvecklingsleverans) Akuttestmiljö oktober 2015 (inför första leverans till lärosätena) Produktionsmiljö - okt 2015 (inför första leverans till lärosätena) Testmiljö befintlig version - mars 2016 (inför första leverans till lärosätena)
Sida 12 av 13 5.3.3 Produktionsmiljö Den miljö som den dagliga produktionen arbetar i. Personal och studenter. Innehåller uppföljningsmiljöer för lärosätena 2 st. för GUI/API: 8 GB minne 2 st. för tjänster: 16 GB minne 2 st. för DB: 64 GB minne (redundanta master-master) 1 st. för integration, management, ldap: 8 GB minne 1 st. för Ladok DB: 64 GB minne 1 st. för Uppföljning DB: 64 GB minne Lagring: 10 TB disk totalt 2 lastbalanserare 5.3.4 Akuttestmiljö (verifikation/stagingmiljö) Används för att testa leveranser innan implementering i produktionsmiljö. Produktionslik. 2 st. för GUI/API 8 GB minne 2 st. för tjänster 16 GB minne 2 st. för DB 64 GB minne (redundanta master-master) (uppföljning och Ladok 2 ingår här) 1 st. för integration, management, ldap 8 GB minne Lagring: 10 TB disk totalt 2 lastbalanserare 5.3.5 Utbildningsmiljö Utbildning av användare sker i denna miljö. Utbildare både på lärosäten och i förvaltningsorganisationen.
Sida 13 av 13 1 st. för GUI/API 16 GB minne, GUI/API, tjänster, DB, 100GB disk 5.3.6 Acceptanstestmiljö Här godkänner förvaltningsorganisationen nya leveranser. Här görs även prestandatester. Kopia av produktionsmiljön? Fullstor? Alternativt inte fullstor, då görs prestandatester för att uppskatta prestanda i produktionsmiljön. 2 st. för GUI/API 8 GB minne 2 st. för tjänster 16 GB minne 2 st. för DB 64 GB minne (redundanta master-master) 1 st. för integration, management, ldap 8 GB minne 1 st. för Ladok DB 64 GB minne 1 st. för Uppföljning 64 GB minne Lagring 10 TB disk totalt 2 lastbalanserare 5.3.7 Testmiljö befintlig version Den miljö som används av lärosätena för att testa rättningar, integrationer och felsökning för aktuell produktionsversionen. 1 st. för GUI/API 64 GB minne, GUI/API, tjänster, DB, 10 TB disk. 5.3.8 Testmiljö ny version Den miljö som används av lärosätena för att testa rättningar, integrationer och felsökning till ny version. Den MIT miljö som sätts upp 2013 bör kunna övergå till denna miljö. 1 st. för GUI/API 64 GB minne, GUI/API, tjänster, DB, 10 TB disk. 5.3.9 Utvecklingsmiljöer Till detta kommer utvecklings-, test- och prestandatestmiljöer för utvecklarna, hanteras av utvecklingsorganisationen. 25 st. virtuella miljöer. 2 st. systemtestmiljö för prestanda/kapacitet och stabilitetstester 16GB 5.3.10 Övrigt Certifikatshantering Certifikat ska uppdateras mot varje lärosäte. Uppskattningsvis 200 certifikat/år och 0,5 Tim/st. Totalt ca 100 Tim/år Spårbarhet (loggning) Driver lagringskostnad, men inte mycket. På det stora hela är detta inte en stor kostnad.