Prosjektplan UH-intern IaaS

Transkript

1

2 1 Bakgrunn Prosjektmål Overordnet framdriftsplan Budsjett Organisering prosjekt Risiko Andre opplysninger... 9 Begreper UH-sky Page 2

3 1 Bakgrunn Planen beskriver hvordan prosjektet skal utvikle IaaS som en byggeblokk for framtidig leveranse av IT-infrastruktur i sektoren. Den første aktiviteten er å levere en IaaS basistjeneste ferdig dokumentert og klargjort for framtidig produksjonssetting innen 15. juni Tilleggsaktiviteter som er nødvendig for å få en komplett løsning er også beskrevet. Disse aktivitetene er det nødvendig å utrede mer hvis de skal kunne settes i gang som foreslått i februar/mars Tjenestene som inngår som basis er: - Compute - Blokkbasert lagring, tilgjengelig som disk for compute - Objektbasert lagring, tilgjengelig over nettverk som API 1.1 Avgrensninger - Det leveres ikke tradisjonell backup, men mulighet for replikering av instanser til andre lokasjoner. - De andre aktivitetene i prosjektet bygger videre på basistjenesten for å tilby konsum av et komplett spekter infrastruktur-tjenester for hele sektoren. - Leveransenemålene i kapittel er beskrevet, men estimater mht. tid og kostnader inngår ikke i prosjektplanen. 1.2 Forutsetninger - Det er en forutsetning for gjennomføring etter tidsplanen at prosjektet har tilgjengelig den kompetansen som kreves. o Minst 3 personer må jobbe 100% i prosjektet for å kunne levere innen tidsfristen o Minst 50% stillingsandel må benyttes for å kunne levere innen tidsfristen o Ved bruk av stillingsandel er dedikert arbeidstid i blokker på minst 3 dager en forutsetning for å ikke svekke leveringsevnen. - Prosjektet trenger minst 6 måneder fra Lokasjonskomplett til leveringsdato for aktivitet 2.1. Dette betyr at hvis målet om levering 15. juni skal nås må investering i utstyr skje i Dersom dette skjer i 2015 vil leveringsdato for 2.1 forskyves tilsvarende i tid, fra 15. august siden juni og juli ikke medregnes. Eksempelvis, dersom Lokasjonskomplett nås i februar 2015 vil leveringsdato bli 15. oktober UH-sky Page 3

4 2 Prosjektmål Prosjektet skal levere en IaaS som en byggeblokk for framtidig leveranse av IT-infrastruktur i sektoren. Aktiviteter i prosjektet: - Utvikle en basis IaaS-plattform (Beskrevet og estimert) - Integrasjon av autorisasjon og autentisering (Beskrevet og estimert) - Videreutvikle IaaS for tradisjonell infrastruktur (Kun beskrevet) - Utrede og foreslå løsning for felles PaaS (Kun beskrevet) - Utrede og foreslå mulige felles SaaS-løsninger (Kun beskrevet) - Utrede og spesifisere en konsum-fokusert portal (Kun beskrevet) Aktivitetene er beskrevet som målbærende historier. Historiene benytter seg av følgende definisjoner: - Tjenesten - Basis IaaS, inklusive alle underliggende tjenester - Bruker - En bruker er en person i UH-sektoren som er gitt tilgang til å administrere instanser for en leietaker. En leietaker representerer en organisasjonsenhet i sektoren. - Administrator - En administrator er en person med ansvar for og tilgang til alle tjenestens systemkomponenter. En administrator har ikke automatisk tilgang til en leietaker sine ressurser. - Liten instans - En instans gitt ressursene 1 vcpu, 4gb RAM og 10gb disk - Stor instans - En instans gitt ressursene 4 vcpu, 16gb RAM og 100gb disk 2.1 Utvikle en basis IaaS-plattform (Beskrevet og estimert) - Tjenesten skal levere kapasitet tilsvarende ~750 små instanser eller ~275 store instanser og 100 tb lagring fordelt likt på tre geografisk spredte lokasjoner - Tjenesten skal levere en "proof of concept" PaaS-løsning med tre standardiserte utviklingsmiljø - Tjenesten skal levere et "proof of concept" for drift av minst en felles tjeneste (SaaS) - Tjenesten skal levere data som kan benyttes som faktureringsgrunnlag. Data som leveres baseres på en tilhørighetsmodell hvor bruker tilhører en organisasjon, som igjen gir en fakturakode. - Tjenesten skal dokumentere og muliggjøre utvidelse av basisplattformen til bruk i HPC-spesifikke miljø - En bruker skal kunne starte en ny instans umiddelbart etter første gangs innlogging. Instansen skal være tilgjengelig innen 60 sekunder. - En bruker skal kunne opprette, oppdatere og slette instanser i tjenesten fra et grafisk konsoll i nettleseren, via API eller på kommandolinja - En bruker skal kunne velge om en instans startes opp med persistent lagring eller ikke - En bruker skal selv kunne legge til mer disk for sine instanser, innenfor tildelt kvote - En bruker skal kunne plassere en instans på en av tre geografiske lokasjoner. Valget skal kunne tas på bakgrunn av behov for redundans, geografisk nærhet eller andre faglige hensyn. - En bruker skal kunne velge at en instans replikeres automatisk for å øke beskyttelsen mot katastrofe-utfall - En bruker skal kunne overvåke og vurdere kvalitet og ytelse i tjenesteleveransen kontinuerlig - En administrator skal bruke tofaktor autentisering for tilgang til tjenesten sitt administrasjonsgrensesnitt UH-sky Page 4

5 - En administrator skal kunne utvide kapasitet, gjøre endringer og utbedre feil i alle deler av tjenesten sin infrastruktur ved hjelp av automatisert utrulling, konfigurasjon og feilsøking 2.2 Integrasjon av autorisasjon og autentisering (Beskrevet og estimert) Før IaaS-tjenesten kan settes i produksjon er det nødvendig med en løsning for sentral autorisasjon og autentisering av brukere. Brukere inn i systemet må identifiseres med tilhørighet og faktureringsinformasjon og knyttes til riktig prosjekt/leietaker. Denne aktiviteten må utrede en modell for hvordan person- og organisasjonsdata fra FEIDE kan integreres i IaaS-tjenesten. Utredningen skal dokumentere et forslag til løsning så godt at det vil være mulig å estimere et utviklingsløp for den foreslåtte løsninga. Begrensninger i modellen som velges må beskrives. Forslag til og kostand for mer avanserte modeller med f.eks brukere og prosjekter på kryss av institusjonene skal belyses. En vurdering av samarbeid og integrasjon med UNINETT sitt prosjekt FEIDE Connect skal gjennomføres. - En bruker skal kunne autentisere seg via FEIDE og knyttes mot tilhørende leietaker i tjenesten - En bruker sitt FEIDE-passord skal ikke lagres i systemet 2.3 Videreutvikle IaaS for tradisjonell infrastruktur (Kun beskrevet) Basis IaaS er planlagt realisert med bruk av OpenStack, et rammeverk for å bygge en skalerbar, elastisk og moderne infrastruktur. Tradisjonell workload - her forstått som vanlige virtuelle maskiner med tilstand - egner seg i utgangspunktet ikke veldig godt i OpenStack. Vi tror at mange potensielle brukere ønsker seg at IaaS-tjenesten også kan levere dette. Aktiviteten integrerer en løsning for tradisjonell workload med basisplattformen for IaaS. Openstack benyttes som bruker-rettet API og tilgangsløsning slik at konsument-siden av IaaS-plattformen blir enhetlig. Løsningen kan bruke eksisterene virtualiseringsinfrastruktur hos institusjonene - i første omgang via ledig kapasitet, senere via utvidelser. Et bærende prinsipp for denne aktiviteten vil være å søke at felles drift og felles ansvar videreutvikles til å omfatte den delen av IaaS-løsningen som tilbyr 'tradisjonell workload'. Siden eksisterende infrastruktur er forskjellig hos institusjonene vil det også være forskjellig hvilke hardware-ressurser som kan gjøres tilgjengelig. Lisenser er et spørsmål som må utredes. 2.4 Utrede og foreslå løsning for felles PaaS (Kun beskrevet) Flere miljøer i sektoren ønsker en PaaS-tjeneste levert på toppen av IaaS-plattformen. Per i dag er det så vidt vi kjenner til kun UNINETT sitt Nova-prosjekt som har erfaring med en PaaS-tjeneste. Denne aktiviteten må utrede hvilken form en felles PaaS-løsningen skal ha og foreslå en løsning. Løsningen må beskrives og kostnads-estimeres. UH-sky Page 5

6 2.5 Utrede og foreslå mulige felles SaaS-løsninger (Kun beskrevet) Flere av tjenestene internt i sektoren leveres allerede per i dag som SaaS. Det er naturlig å se på om disse kan integreres i felles IaaS. Aktiviteten bør gå aktivt ut i fagmiljøene for å se om det er andre SaaS-lignende løsninger som sektoren ønsker seg. Tidlige eksempler på slike tjenester kan f.eks være programvare knyttet til undervisning eller lab-aktiviteter. Er f.eks SPSS som en tjeneste mulig? 2.6 Utrede og spesifisere en konsum-fokusert portal (Kun beskrevet) For en helhetlig løsning for IaaS- og PaaS-løsninger i UH-sektoren trengs en konsum-fokusert portal. En slik portal vil kunne presentere alle IaaS- og PaaS-tjenester. Funksjonelt er det behov for: - Chargeback. Automatisk fakturering basert på forbruk av ressurser - Støtte for mange virtualiserings- og skyløsninger, inkludert evt. private løsninger på institusjonene og eksterne skyer (f.eks. Amazon) - Mulighet for å flytte og kopiere instanser mellom eventuell lokal sky, felles sky og ekstern sky - God oversikt over allokerte ressurser i de sky- og virtualiseringsløsningene man bruker Det finnes produkter som dekker funksjonalitet som er beskrevet over og en portal bør ta utgangspunkt i ett av disse produktene. Utvikling av en portal vil være løst knyttet til IaaS-prosjektet men det er naturlig å vente med eventuell oppstart av dette til basisplattformen er funksjonelt ferdigutviklet. For en helhetlig løsning for IaaS- og PaaS-løsninger i UH-sektoren trengs en konsumfokusert portal. En slik portal vil kunne presentere alle IaaS- og PaaS-tjenester. UH-sky Page 6

7 3 Overordnet framdriftsplan Følgende beskriver framdrift og mulige starttidspunkt for aktivitetene i prosjektet. Aktivitet Dato Oppstart 2.1 og 2.2 Nå Ferdig minimumsprodukt, 2.1 En av tre lokasjoner har en fungerende fysisk Oktober 2014 installasjon (2.1) Ingen garantier for oppetid eller lagring av instanser Lokasjonskomplett, (2.1, fysisk, fungerende installasjon uten oppetidsgarantier, Desember 2014 på tre lokasjoner) Funksjonskomplett 2.1, Alle funksjonelle mål tilgjengelig, ingen Februar 2015 oppetidsgarantier Inkubasjonsperiode 2.1, Pre-produksjon, feilretting og justering, Eksterne Juni 2015 testkunder skal gis tilgang, Best effort oppetid og lagring, 2.1/2.2 Dokumentasjon, beskrive evt. videre utviklingsbehov Starte nye aktiviteter: 2.3, 2.4, 2.5., 2.6 Juni 2015 Ferdig levert 2.1 og Budsjett Her estimeres personressurser og direktekostnader. Finansiering/inntekt omtales også. 4.1 Ressurser Prosjektets kompetanseprofil kan oppsummeres til senior/spisskompetanse på følgende: - Alle: Automatisering/programmering - Alle: Operativsystemer, OpenStack og virtualisering - 1 person spesialisert mot distribuert, programvare-basert lagring - 1 person spesialisert mot database - 1 person spesialisert mot programmerbare nettverk (SDN) Denne kunnskapen finnes i sektoren men leveringsevne og -hastighet er avhengig av at de rette personene er tilgjengelig. UH-sky-prosjektet vil stå for den administrative prosjektledelsen. Videre er det foreslått 1 stilling hver fra UNINETT, USIT, UIB, UIT og NTNU. Andre i sektoren med tilgjengelige ressurser vil også ha mulighet til å knytte seg til prosjektet. Mht. aktivitet 2.2, "Integrasjon av autorisasjon og autentisering": Aktiviteten er todelt; utredning og utvikling. Den enklest mulig fungerende løsningen er estimert til mellom 200 og 300 timer. Dersom leveransemålet endres til en mer kompleks modell vil personellbehovet øke. UH-sky Page 7

8 Ressursbehovet for leveranse av den tekniske plattformen er estimert til 5 stillinger. Ressurs Timer Prosjektledelse 300 Fagkompetanse fra universitetene og UNINETT (Inkl. punkt 2.2.) TOTALT Kostnader Investeringsbehovet for et minimumskjøp av kapasitet som vil gi full funksjonalitet er bergenet til omlag 4,5 millioner totalt for tre lokasjoner. Dette innkjøpet vil gi et et grunnlag for videre utvidelse av prosessorkraft og lagring i blokker. Som eksempel vil doblet investering i dette gi dobbel kapasitet. Det er spesifisert 2 switcher, 3 compute-servere og 5 storage-noder per lokasjon. Denne størrelsesorden er nødvendig for å kunne eksponere og teste all funksjonalitet og redundans en ønsker som del av et framtidig produksjonsmiljø. Dersom kostnaden oppleves høy er det faglig sterkt ønskelig ikke å redusere investeringen per lokasjon men heller gå ned på antallet lokasjoner. To lokasjoner vil gi samme grad av testmuligheter men til samlet redusert kostnad. Nødvendig utstyr pr lokasjon: Beskrivelse Kostnad 3 lokasj. 2 router-switcher (Linux-basert adminstrasjon) management-noder (overvåkning, installasjon) compute-noder (72 prossesorkjerner) storage-noder (60 disker) SFP+ fibermoduler TOTALT En framtidig avgjørelse om produksjonssetting av kapasiteten som dette utstyret gir vil medføre lisenskostnad for OpenStack. Lisensen gir sikkerhetspatching og en stabil produksjonsplattform, grovt estimert til inkl moms totalt for tre lokasjoner. Modellen med tre lokasjoner legger til grunn at utvidelser skjer samtidig og i samme hastighet på hver lokasjon. Dette er nødvendig for å sikre at leveransekvalitet, design for katastrofe-utfall og høy tilgjengelighetsgrad opprettholdes. Alle kostnader er cirka-priser inkludert MVA. 4.3 Finansieringskilder/inntekter - Institusjonene finansierer timene på ressursene som går inn i prosjektet. - De fire universitetene går inn med ¼ hver på investeringer Finansiering og inntekter knyttet til forvaltning og videre utvikling estimeres som en del av prosjektet UH-intern IaaS i samarbeid med prosjektet "Porteføljeutvikling". UH-sky Page 8

9 5 Organisering prosjekt Styringsgruppe: UH-sky sin styringsgruppe Prosjekteier: UH-sky v. Kristin Selvaag Prosjektleder: Jan Ivar Beddari Prosjektdeltakere: Ressurser som beskrevet, men ikke navngitt i kapittel Risiko Utstyret vil ha en levetid på minst fire år. Risiko for tap av investeringer hvis prosjektet skulle feile eller avsluttes, er lav fordi alt utstyret vil kunne inngå i den daglige driften lokalt. Avvik på framdriftsplanen (3 måneder eller mer) grunnet manglende tilgang på nøkkelpersoner, uforutsette komplikasjoner og samarbeidsutfordringer, er svært sannsynlig. Avvik på kostnadsestimater til utstyr har lav sannsynlighet, men forvaltningskostnader er ikke estimert og det gir usikkerhet rundt kostnadene etter implementering av teknisk plattform. 7 Andre opplysninger Tilleggsspørsmål rundt leveransemålene i prosjektet: 7.1 Støtte for Windows En basis Windows-basert instans krever betraktelig mer av kapasitet i tjenesten enn en basis Linuxinstans. Prosjektet tar sikte på å støtte Windows-instanser på best mulig måte. Testing i prosjektet vil legge grunnlaget for den tekniske løsninga som velges. Prosjektet vil teste Windows-instanser som store instanser med persistent lagring og måle ytelsen på dette versus våre tradisjonelle virtualiseringssystemer. Dersom problemer avdekkes rundt dette vil prosjektet synliggjøre disse så raskt som mulig. 7.2 Lisensiering av instanser Prosjektet tar ikke opp kostnad for lisensiering av instanser. Leietakere i systemet må selv sørge for at hver instans de oppretter i systemet har lisens. Eksempelvis gjelder dette Microsoft Windows og Red Hat Enterprise Linux. UH-sky Page 9

10 I en sektor-eid IaaS kan det være mulig å kjøpe felles 'site' lisenser for operativsystem slik at en slipper å telle og betale for instans-lisenser per institusjon. Totalt sett vil sektoren kunne spare penger på en slik løsning. Prosjektet har ikke satt av ressurser til å utrede dette. 7.3 Utregning av kapasitet - Fysiske CPU cores tilgjengelig 2x12 core x3 noder x3 lokasjoner = 216 cores - Virtuelle CPU tilgjengelig 216 cores 4x oversubscription = 864 virt core (vcpu) - Tilgjengelig RAM, ingen oversubscription 512gb x3 noder x3 lokasjoner = 4608gb (minus compute host overhead) - Liten instans 1 vcpu, 4gb RAM, 10gb disk = kapasitet ~750 instanser - Stor instans: 4 vcpu, 16gb RAM, 100gb disk = kapasitet ~275 instanser UH-sky Page 10

11 Begreper Definisjonene er hentet fra NANSen-rapporten. IaaS Muligheten til å leie prosessorkraft, lagring, nettverk og andre fundamentale maskinressurser hvor kunden er i stand til å opprette, lagre data og/eller kjøre vilkårlig programvare. Dette inkluderer operativsystem og applikasjoner. PaaS Muligheten til å rulle ut applikasjoner laget av forbrukeren i en skyinfrastruktur med støtte for et eller flere programmeringsspråk med varierende rikdom i underliggende funksjonsbibliotek og knytning lisensbetingelser. Her forholder ikke forbrukeren seg direkte til operativsystem eller lagring, men muligens til forskjellige ferdiglagde konfigurasjoner for applikasjons-hosting. SaaS Muligheten til å bruke tilbyders applikasjon som kjører i en skyinfrastruktur og er tilgjengelig fra et utvalg av tynnklient-grensesnitt som for eksempel en nettleser, og/eller apper på nettbrett og mobiltelefoner. Med unntak av helt brukerspesifikke innstillinger styrer ikke brukeren av tjenesten de underliggende elementene i skyinfrastrukturen eller eventuelle rammeverk applikasjonen er bygget i. UH-sky Page 11