VGTogether samen werken in voortgangstoetsing
Programma Toetsing en Toetsgestuurd Leren PIJLER 1: Het verminderen van studie-uitval en werkdruk in het hoger onderwijs PIJLER 3: Nationale technische infrastructuur
Deliverable 3.1: Requirementsanalyse infrastructuur
Definitieve versie
Datum: Auteur:
23-12-2011 Frank van de Kamp
INHOUDSOPGAVE 1
Inhoudsopgave ..................................................................................................................... 2
2
Samenvatting ....................................................................................................................... 3
3
Inleiding ................................................................................................................................ 4
4
Wat betekent infrastructuur? .............................................................................................. 5
5
Analyse ................................................................................................................................. 5 5.1
Welke systemen moeten worden ondergebracht? ............................................................................... 5
5.2
OTAP ...................................................................................................................................................... 8
5.3
Welke resources zijn er nodig voor beheer? ....................................................................................... 11
6
Uitbesteden of zelf doen? .................................................................................................. 11
7
Kostenanalyse .................................................................................................................... 12
2
Deliverable 3.1
1
SAMENVATTING
Werkpakket 3 heeft tot doel om te komen tot een keuze van de technische, organisatorische en financiële opmaak van de centrale ICT-infrastructuur voor voortgangstoetsing. Deliverable 3.1 richt zich op een requirementsanalyse voor deze infrastructuur. In een uitgebreide analyse is gekeken naar: - de huidige situatie: welke bestaande systemen zijn er; - welke systemen komen erbij ten behoeve van het ICB-systeem; - welke onderdelen levert dat in totaal op en hoe kunnen deze worden geconsolideerd; Aangezien de definitieve keuze voor een ICB-systeem nog gemaakt moet worden, zijn de specificaties hiervan gebaseerd op een schatting. Ook is er nagedacht over de inrichting van een OTAP (Ontwikkel, Test, Acceptatie, Productie) omgeving. Deze inrichting heeft een aantal voordelen: - ontwikkelomgeving is dubbele functie: o onderhoud aan VOSYS blijft gewaarborgd door de installatie van de ‘oude’ ontwikkelsoftware; o nieuw te ontwikkelen software kan met nieuwe 64-bit ontwikkelsoftware; - test en –acceptatieomgeving kan worden gebruikt voor testwerkzaamheden zonder de ‘live’ systemen te raken; - productieomgeving moet toch al worden ingericht: hier worden alle ‘live’ systemen ondergebracht. Vervolgens is stilgestaan bij de afweging ‘uitbesteden of zelf doen’. Er is geconstateerd dat, gezien de huidige markt, het niet meer rendabel is om zelf hard- en software aan te schaffen en te gaan beheren. Externe partijen hebben zich gespecialiseerd in het beheren van andermans systemen en/of diensten. Het ontzorgt: één vaste prijs voor schaalbare rekencapaciteit inclusief beheer en personeelskosten, zonder de hoge aanschafkosten. Een bijkomend voordeel is dat de externe partijen gebruik maken van virtuele machines, en zo de meteen in de behoefte aan een virtuele 32-bit machine voor VOSYS kan worden voldaan. Derhalve is gekozen om ‘kant-en-klare’ (virtuele) machines af te nemen bij een externe partij in plaats van ze zelf aan te schaffen en te gaan beheren. Tot slot is er een inschatting gedaan voor wat betreft de kosten van de infrastructuur. Aangezien er is gekozen voor uitbesteding, zal er een vast bedrag per server per jaar betaald worden. Daardoor zijn de kosten redelijk constant, en daarnaast op voorhand redelijk goed in te schatten. In totaal worden 7 virtuele machines benodigd, die tegen gemiddeld €1000 per jaar kunnen worden afgenomen. Hier komt nog een eenmalig een klein bedrag bij aan Client Access Licenses voor het gebruik van VOSYS via Remote Desktop Services, naar schatting ongeveer €300.
3
Deliverable 3.1
2
INLEIDING
Werkpakket 3 heeft tot doel om te komen tot een keuze van de technische, organisatorische en financiële opmaak van de centrale ICT-infrastructuur voor voortgangstoetsing. Deliverable 3.1 richt zich op een requirementsanalyse voor deze infrastructuur. In deze analyse wordt gekeken naar in ieder geval de volgende punten: 1. Welke (bestaande) systemen moeten worden ondergebracht? 2. Welke technische eisen stellen deze systemen aan de infrastructuur? 3. Welke eisen stelt de gekozen ICB oplossing? 4. Besteden we zaken uit, of doen we het zelf? Op basis van deze requirements wordt daarnaast nauwkeurige beschrijving gegeven van de gewenste infrastructuur. Aangezien dit document moet worden opgeleverd voordat er een definitieve keuze is gemaakt inzake een ICB oplossing, worden de requirements van het toekomstige ICB systeem geformuleerd op basis van inschatting. Tot slot wordt een overzicht / inschatting gegeven over de kosten van deze technische infrastructuur. Ook in dit opzicht vormen de nog onbekende specificaties en requirements van het ICB systeem een onzeker factor. De uiteindelijke kosten voor de infrastructuur kan worden beïnvloed door de uiteindelijke keuze. In dit document wordt niet stilgestaan bij de inrichting van deze infrastructuur. Deze zal in werkpakket 4 worden uitgewerkt en uitgevoerd. De verdeling van de bestaande systemen en diens componenten verderop in dit document is op basis van inschatting en kan tijdens de uitvoering van werkpakket 4 veranderen.
4
Deliverable 3.1
3
WAT BETEKENT INFRASTRUCTUUR?
“Binnen de ICT wordt het woord "infrastructuur" gebruikt voor de verzameling voorzieningen die nodig is voor het transport van analoge en digitale gegevens (data). Hieronder vallen alle fysieke en technische middelen die 1 het elektronische signaal (als gegevensdrager), verplaatsen, verdelen en routeren.” Een ICT-infrastructuur dient dus vooral als basisvoorziening om een bepaalde dienst te kunnen aanbieden (bijvoorbeeld de opslag van data of het aansturen van alle telefoonverkeer). Infrastructuur bestaat enerzijds uit hardwarematige IT-componenten, zoals bijvoorbeeld een datacenter vol met servers, netwerkapparatuur en bekabeling, en anderzijds uit software die nodig is om bepaalde diensten en programmatuur te laten functioneren. De infrastructuur zal straks een platform zijn om bestaande of nieuwe systemen onder te brengen. Indien er in dit document wordt gesproken over infrastructuur, dan wordt hier de technische infrastructuur mee bedoeld.
4
ANALYSE
De requirements voor een centrale infrastructuur zijn te verdelen in 2 soorten: 1. Requirements voor de hard- en software (de fysieke materialen); 2. Requirements voor bemensing en kennis die nodig is om de infrastructuur draaiende te houden. In paragraaf 5.1 zal worden gekeken naar de requirements voor hard- en software, in 5.2 zal worden beschreven welke resources nodig zijn in de vorm van bemensing en kennis.
5.1 Welke systemen moeten worden ondergebracht? De infrastructuur zal onderdak bieden aan de bestaande systemen, te weten VOSYS en ProF, en het nog te selecteren ICB-systeem. Deze 3 systemen samen vormen straks de IT-ondersteuning voor de voortgangstoetsing binnen, maar ook buiten de iVTG. Om in kaart te brengen welke hardwarecomponenten er straks ondergebracht moeten worden in de infrastructuur, is per systeem gekeken naar de onderdelen:
VOSYS: O01
Vosys Database Een Oracle database met daarin: - tabellen; - users (gebruikersnaam/wachtwoord combinaties); 2 - packages (procedures in SQL) die nodig zijn voor de werking van de Vosys client (zie onderdeel O02); - indexen. De database draait op een Windows server die wordt gehost door ICTS, de interne ICT dienst van de Universiteit Maastricht.
O02
Vosys client De Vosys client, geprogrammeerd in Visual Studio 2003, gebruik makend van het .NET platform 1.1 met C# als programmeertaal. Besturingssysteem: Microsoft Windows.
1 2
Bron: http://nl.wikipedia.org/wiki/IT-infrastructuur
Een client (Engels) is een computerprogramma dat met een zogeheten server communiceert. 5 Deliverable 3.1
O03
MS Access Applicatie voor CAD Een front-end applicatie in MS Access, die via een 32 bits ODBC koppeling met de Oracle database communiceert. Besturingssysteem: Microsoft Windows.
O04
MS Access Applicatie voor RED Een front-end applicatie in MS Access, die via een 32 bits ODBC koppeling met de Oracle database communiceert. Besturingssysteem: Microsoft Windows.
O05
Vosys Rep(orter) Een in Delphi 5 ontwikkelde softwaremodule die via een 32bit ODBC koppeling communiceert met de Oracle database. Besturingssysteem: Microsoft Windows.
O06
Vosys Exporter Een in Delphi 5 ontwikkelde softwaremodule die via een 32bit ODBC koppeling communiceert met de Oracle database. Besturingssysteem: Microsoft Windows.
O07
TAB to XML Converter Een in Delphi 5 ontwikkelde softwaremodule die via een 32bit ODBC koppeling communiceert met de Oracle database. Besturingssysteem: Microsoft Windows.
De hierboven beschreven onderdelen en hun onderlinge verband worden weergegeven in afbeelding 1:
Afbeelding 1: Vosys Topologie (de pijlen geven de datastromen en hun richting aan)
6
Deliverable 3.1
ProF: F02
Import-rekenmodule
Een in Perl ontwikkelde module voor het importeren van VOSYS-data. Voor de berekeningen maakt het gebruik van het pakket Project-R. Besturingssysteem: Microsoft Windows.
F03
Werkdatabase
Een MySQL database, draaiende op een Linux server.
F04
Feedbackdatabase
Een MySQL database, draaiende op een Linux server.
F05
Gebruikersomgeving
Een in PHP en de open-source architectuur “Casco” ontwikkelde omgeving, draaiende op een Linux server.
F06
SurfFederatie-toegang
Een door SurfNet ontwikkeld en beheerd systeem dat studenten en medewerkers van aangesloten instellingen in staat stelt om, op de daarvoor geschikt gemaakte applicaties, in te loggen met hun instellingswachtwoord. Deze hoeft niet op de infrastructuur te worden ondergebracht.
ICB-systeem (nog niet geheel bekend) -
Een database-server Een webserver; ?
Het is niet vereist om elke server op een aparte (virtuele) machine te laten draaien. Dit biedt voordelen, omdat meerdere onderdelen zo samen binnen 1 (virtuele) machine kunnen worden geïnstalleerd. Zo kunnen bijvoorbeeld onderdelen die draaien op een Windows besturingssysteem samen worden geïnstalleerd op 1 Windows server. Ook de ProF database en webserver, die nu ook samen op een Linux-server draaien, kunnen straks worden gecombineerd. De rekenmodule van ProF, die draait op een Windows besturingssysteem, en slechts 4 maal per jaar (na de toetsen) wordt gebruikt voor de berekeningen, hoeft niet apart te staan maar kan worden gecombineerd met een andere component. Het combineren of onderbrengen van meerdere onderdelen op 1 systeem heet consolideren. Deze consolidatie heeft echter ook nadelen. Zo kunnen 2 database- of webservers prima naast elkaar draaien, maar als (één van) beide(n) sterk wordt belast kan dat invloed hebben op de prestatie en beschikbaarheid van (alle) onderdelen op die machine. Door een mogelijke groei van het gebruik van het systeem, ten gevolge van bijvoorbeeld het toetreden van een nieuwe faculteit tot de iVTG, of de afname van diensten door buitenlandse organisaties, kan de belasting van de systemen sterk toenemen. Om de stabiliteit en de beschikbaarheid te waarborgen kan er verandering optreden in de combinatie van onderdelen. Zo kan het gebeuren dat een onderdeel op een aparte server wordt ondergebracht. De verdeling van de onderdelen wordt dus in dit project gedaan op basis van het huidige gebruik van de systemen. De belasting van het nog te selecteren ICB-systeem, welke is ingeschat op ca. 200 gebruikers, is hierin meegenomen.
7
Deliverable 3.1
5.2 OTAP Om veranderingen in het systeem, welke nodig zijn voor (preventief) onderhoud of voor het oplossen van storingen, te kunnen doen zonder dat dit invloed heeft op het functioneren van de systeem en/of het gebruik ervan door de gebruikers is het raadzaam om veranderingen of updates aan een systeem eerst te testen in een omgeving die zoveel mogelijk lijkt op de ‘live’ omgeving. Mocht er namelijk iets mis gaan, dan heeft dit geen invloed op de echte systemen. Een omgeving die voorziet in zowel de ontwikkelsystemen als ook in een al dan niet geïsoleerde kopie van de ‘live’ omgeving wordt een OTAP omgeving genoemd. OTAP staat voor: -
-
-
Ontwikkel: In de ontwikkelomgeving wordt de (verandering aan de) software voor een website, computerprogramma of besturingssysteem gemaakt cq. geprogrammeerd; Test: De testomgeving is een omgeving die zo veel mogelijk lijkt op de echte systemen die dagelijks worden gebruikt. Om te kunnen zien of een verandering het gewenste effect heeft, en geen onvoorziene bijwerkingen vertoont, wordt een in de ontwikkelomgeving geproduceerd stukje software hier getest; Acceptatie: Indien de tests zoals gepland verlopen, wordt de software in de acceptatieomgeving geïnstalleerd zodat de gebruikers ermee kunnen testen en hun feedback kunnen geven op de veranderingen; Productie: In de productieomgeving staan de ‘live’ systemen, waarmee de gebruikers hun dagdagelijkse werkzaamheden uitvoeren. Pas als de gebruikers tijdens de acceptatie akkoord gaan met de verandering wordt de software uitgerold (geïnstalleerd) op de productieomgeving.
Oorspronkelijk komt deze opzet uit de softwareontwikkeling, maar is steeds vaker in de grotere ICTomgevingen te vinden. In de infrastructuur die binnen dit project opgeleverd gaat worden, worden deze omgevingen voor een deel ingericht:
Ontwikkelomgeving Om het bestaande systeem VOSYS te kunnen blijven beheren, kan het voorkomen dat er veranderingen moeten worden gedaan aan de programmacode. Die moeten worden gedaan met het softwarepakket waarmee VOSYS is gemaakt: Microsoft Visual Studio 2005. Daarom is het van belang dat dit softwarepakket, dat ook moet draaien op een 32-bit besturingssysteem, wordt opgenomen in de ontwikkelomgeving. Ook het pakket Delphi 5, waarmee enkele losse modules zoals VOSYS Rep en VOSYS Exporter zijn gemaakt, dient te worden opgenomen in deze omgeving. Daarnaast wordt er ontwikkelsoftware geïnstalleerd voor het ontwikkelen van 64-bit applicaties, omdat dit de nieuwe standaard wordt en zodoende de nog te ontwikkelen applicaties toekomstbestendig zijn. Hiervoor is de keuze gevallen op RAD Studio XE2 van Embarcadero. Deze vereist een 64-bit besturingssysteem. Doordat de ‘oude’ software op een 32 bit systeem moet blijven draaien, terwijl de nieuwe software juist een 64-bit systeem vereist, zijn er dus 2 virtuele machines nodig.
8
Deliverable 3.1
Daardoor ziet de ontwikkelomgeving er zo uit:
Testomgeving Zoals eerder beschreven is het belangrijk dat de omgeving waarbinnen wordt getest, zo veel mogelijk lijkt op de echte omgeving, namelijk de productieomgeving. Daarom is besloten om, indien er testwerkzaamheden gedaan moeten worden, een kopie van de productieomgeving te creëren. Door het gebruik van virtuele machines is het kopiëren (klonen) van één of meerdere systemen een koud kunstje. Het spreekt voor zich dat deze ‘dienst’ met de externe hosting-partij afgestemd moet worden. Dit houdt namelijk in dat we tijdelijk een aantal extra machines afnemen bij deze partij. Na de testwerkzaamheden wordt de tijdelijke omgeving weer opgeruimd (verwijderd). Financieel is dit een gunstige constructie. De kosten voor een permanente OTAP omgeving zijn niet gering en op deze manier betalen we enkel voor de periode dat we de extra machines nodig hebben. Het is belangrijk dat het beschikbaar stellen van deze extra machines goed met de externe partij wordt afgestemd. Het is goed mogelijk dat wij als klant/gebruiker deze machines zelf kunnen aanvragen/aanmaken middels een webgebaseerde beheersmodule. Indien dit niet het geval is, is het denkbaar dat de extra machines tijdig bij de externe partij worden aangevraagd, zodat ze bij werkzaamheden op tijd beschikbaar zijn. Voor een ontwerp van de testomgeving, zie afbeelding 1 onder ‘productieomgeving’.
Acceptatieomgeving Ook voor de acceptatiefase zullen we gebruik maken van de tijdelijke kopie van de productieomgeving. Indien noodzakelijk worden gebruikers van de systemen worden gevraagd om de verandering(en) te testen. Voor een ontwerp van de acceptatieomgeving, zie afbeelding 1 onder ‘productieomgeving’.
9
Deliverable 3.1
Productieomgeving De onder 5.1 genoemde systemen zijn samen de productieomgeving. Op basis van de eerder beschreven verdeling en consolidatie van componenten en rekenkracht, ziet het ontwerp van de productieomgeving er als volgt uit:
Afbeelding 1: Ontwerp voor technische infrastructuur in de productieomgeving Dit ontwerp kan dus door toename van gebruik en dus belasting van het systeem, dan wel door andere samenwerkingsverbanden, worden herzien en opnieuw worden ingericht.
10
Deliverable 3.1
5.3 Welke resources zijn er nodig voor beheer? De ‘resources’ die nodig zijn voor een centrale infrastructuur bestaan dus niet alleen uit technische spullen, maar ook uit een of meerdere personen die in staat zijn om de hard- en software te beheren. Beheer betekent zowel het oplossen als het voorkomen van problemen. In de praktijk bestaat het beheer dus zowel uit het oplossen van storingen en incidenten als het uitvoeren van preventieve handelingen. Een aantal handelingen die bij beheer aan bod komen zijn onder andere: - patching (installeren van (Windows) updates); - backup; - oplossen van incidenten en storingen; - (preventieve) vervanging van hardwareonderdelen; - Monitoring van systemen (bijv. op beschikbaarheid), verbindingen (bijvoorbeeld de internetconnectie met de buitenwereld) en/of processen (bijv. het backup-proces) De hoeveelheid werk is evenredig aan de omvang van de infrastructuur. In kleine omgevingen is het beheer vaak niet eens een dagtaak, en worden enkele personen belast met de verschillende beheerstaken, waarbij 1 persoon vaak meerdere taken op zich neemt. In grote omgevingen kan het voorkomen dat meerdere FTE’s zich bezig houden met één specifieke beheerstaak.
5
UITBESTEDEN OF ZELF DOEN?
Dat een bedrijf of instelling niet meer al haar IT zaken in eigen beheer heeft is de normaalste zaak van de wereld, en is meer regel dan uitzondering. Door de opkomst van cloud-computing (een computationele stijl waarbij ICT schaalbare en elastische mogelijkheden biedt die worden geleverd als dienst aan externe klanten 3 via het gebruik van internettechnologie ) en SaaS (Software as a Service), nemen steeds meer bedrijven of instellingen een dienst af bij een dienstverlener. Laatstgenoemde, meestal een externe partij, is gespecialiseerd in het soort dienst dat wordt aangeboden, en heeft daardoor de kennis en capaciteit om meerdere bedrijven hetzelfde werk en vaak de bijbehorende zorgen uit handen te nemen. Doordat het beheren de nodige kosten met zich mee brengt (denk bij een aantal servers aan beveiliging, koeling, blussing en onderhoud) is het financieel vaak gunstiger om de dienst uit te besteden of af te nemen, dan om hem zelf te beheren. Voorbeelden hiervan zijn: - Het beheer van de Email-servers door een externe partij; - Het beheer van de WAN-verbinding (netwerk tussen meerdere vestigingen van 1 bedrijf) door een externe partij; - Het uitbesteden van telefonie (mobiel en vast) door een telecomprovider. Bij afname van een dienst wordt bijna altijd in een zogenaamde SLA (Service Level Agreement) vastgelegd welke dienst tegen welke prijs wordt afgenomen. Hierbij worden specificaties als prijs, beschikbaarheid, kwaliteit, volume en ondersteuning beschreven. Deze SLA’s zorgen ervoor dat de afnemer krijgt waarvoor hij betaalt. Deze externe partijen, ook wel hosting-partijen of hosting-providers genoemd, hebben bijna altijd de beschikking over grote datacenters (zelf in eigendom, of een zaal gehuurd in een groot datacenter) waarin een groot aantal servers worden beheerd. Door de opkomst van de virtualisatie kunnen er in een datacenter veel meer servers worden ingericht en beheerd dan dat er fysieke servers aanwezig zijn. De afnemer, het bedrijf dat een server ‘huurt’ of ‘afneemt’, weet vaak niet eens of de server die hij ter beschikking heeft een fysieke of een virtuele server is. Dit is vaak niet eens interessant, omdat men een bepaalde capaciteit afneemt voor een bepaalde prijs. Hoe deze capaciteit wordt bereikt en gewaarborgd is een zorg voor de aanbieder, niet voor de afnemer. Gezien de wens om een centrale ICT-infrastructuur in te richten, verdient het niet de voorkeur om zelf als iVTG een aantal servers aan te schaffen en in richten om de nodige systemen te kunnen draaien.
3
Bron: http://www.computable.nl/artikel/ict_topics/saas/2978520/2333364/gartner-herziet-definitie-van-cloudcomputing.html#ixzz1f115LGcY
11
Deliverable 3.1
De combinatie van locatie en het gemak van uitbesteden heeft geleid tot de keuze om de benodigde servers af te nemen bij een externe partij. Deze keuze is bovendien erg gunstig voor het onderbrengen van VOSYS. Het onderzoek dat is uitgevoerd naar aanleiding van het in deliverable 2.1 gedefinieerde actiepunt A01: onderzoek naar 32/64 bit probleem, heeft uitgewezen dat alle (32-bits) gebruikersmodules van VOSYS (de standalone applicaties bij de gebruiker op de PC draaien) het beste kunnen worden ondergebracht op een 32-bits virtuele server. Doordat deze virtueel is, is er geen hardwareafhankelijkheid, en is de noodzaak voor 32-bits hardware daardoor niet meer van toepassing. In deliverable 2.3 zal dit verder worden toegelicht. Eventuele SLA’s, met daarin beschreven welk beschikbaarheidsniveau nodig is, worden uitgewerkt en vastgelegd in werkpakket 4, de implementatie van de infrastructuur. Omdat er geen businesskritische applicaties zullen draaien op de infrastructuur leert een inschatting op dit moment dat er derhalve niet gekozen gaat worden voor onnodig zware monitoring/redundantie. Dit betekent niet dat de beschikbaarheid en stabiliteit van de omgeving onbelangrijk is, maar dat er gezocht wordt naar een goede balans tussen beschikbaarheid en kosten hiervoor.
6
KOSTENANALYSE
Door het afnemen van een aantal virtuele machines betalen we een vaste prijs per machine. Deze prijs is inclusief alle kosten voor beheer (zie 6.3 voor meer details) en licenties voor een besturingssysteem, bijvoorbeeld Windows Server 2008 van Microsoft. De kosten per server op jaarbasis variëren van €500 tot €1500, afhankelijk van de opties die erbij worden genomen. Denk hierbij aan meerdere SLA mogelijkheden, variaties op beheer en monitoring etc. Gemiddeld genomen kan er voor €1000 per jaar een prima server worden ingekocht. De kosten voor de totale infrastructuur (O en P omgeving) komen dan op 7 * €1000 = €7000 per jaar, inclusief beheer en eventuele licenties. Voor het gebruik van VOSYS komen hier nog extra kosten bij. VOSYS wordt via Remote Desktop Services (voorheen Terminal Server) beschikbaar gesteld aan de gebruikers. Dit houdt kortweg in dat meerdere gebruikers op de server inloggen en gebruik maken van de daarop geïnstalleerde applicaties. Deze manier van werken vereist een zogenaamde Client Access License, meestal afgekort tot CAL. 4 Deze CAL’s zijn er in 2 soorten : - User-CAL: per gebruiker; handig bij bijvoorbeeld een vaste bezetting maar verschillende werkpleklocaties; - Device-CAL: per computer/apparaat; handig bij bijvoorbeeld wisselende bezetting maar vaste werkplekken. Omdat er in ons geval minder gebruikers zullen zijn dan computer van waaruit gewerkt kan worden, is de aanschaf van een user-CAL per gebruiker het meest gunstig. Naar schatting zullen dit ongeveer 5 gebruikers zijn. De kosten voor een pakket van 5 user-CAL’s bedragen ca. €300. Deze kosten zijn eenmalig.
4
http://technet.microsoft.com/nl-nl/library/cc753650%28WS.10%29.aspx 12
Deliverable 3.1
