Masterproef SLA s en Datacenters

Masterproef SLA’s en Datacenters

Studiegebied Industriële wetenschappen en technologie Opleiding Master in de industriële wetenschappen: Elektronica-ICT Afstudeerrichting Informatie- en Communicatietechnologie Academiejaar 2008-2009

Ken Van Rafelghem

SLA’s and Data Centers

Ken Van Rafelghem

Voorwoord Beste lezer, Toen ik deze masterproef koos, had ik in gedachten later misschien in een datacenter te gaan werken. Ik zat enkel nog met 1 simpele vraag bij het lezen van de titel, wat waren nu die SLA’s, ik had er nog nooit iets van gehoord of gezien. Ondertussen ben ik, een jaar later in kennis gegroeid en sta ik op het punt af te studeren. De masterproef is een theoretische studie, van SLA’s in datacenters, waarbij ik mijn eigen bevindingen en bedenkingen heb neergeschreven, naargelang ik er meer en meer over las. Het is een onderwerp dat nog niet veel is aangekaart, en dat maakt het iets waarover je tegelijk hopen informatie, en eigenlijk geen informatie vindt. In deze masterproef heb ik geprobeerd om mijn ondervindingen gestructureerd over te brengen, en hoop ik dat u, beste lezer, er de informatie die u zoekt uit kunt halen. Als afsluiter van dit voorwoord, zou ik mijn promotoren willen bedanken: Mijn interne promotor: ir. Jan Devos Van de HOWEST – Departement PIH Mijn externe promotor: ir. Wim Boone Van het bedrijf Ingenium n.v. te Sint-Andries, Brugge Voor hun steun, begeleiding, informatie en feedback die ik tijdens het schrijven van mijn masterproef ontvangen heb.

Page | i


Ken Van Rafelghem

Inhoudsopgave Voorwoord ......................................................................................................................................... i Inhoudsopgave................................................................................................................................... ii Lijst van Afbeeldingen en tabellen .................................................................................................... iv Inleiding .............................................................................................................................................v 1

CobIT voor Service Level Agreements in Datacenters .................................................................1 1.1

1.1.1

Delivery & Support......................................................................................................3

1.1.2

Monitor & Evaluate ................................................................................................... 15

1.2

3

Wat betekent dit specifiek in Service Level Agreements? ................................................... 17

1.2.1

Delivery & Support.................................................................................................... 17

1.2.2

Monitoring & Evaluate .............................................................................................. 28

1.3 2

Wat zijn SLA’s en wat zegt Cobit? ......................................................................................2

Besluit: CobIT: yes or no ................................................................................................... 29

SLA’s ....................................................................................................................................... 30 2.1

Wat zijn SLA’s .................................................................................................................. 30

2.2

Waarom zijn SLA’s in datacenters nodig ........................................................................... 30

2.3

Wat staat er in SLA’s ......................................................................................................... 31

2.3.1

Inhoud ....................................................................................................................... 31

2.3.2

Definities ................................................................................................................... 32

2.3.3

Randvoorwaarden (uitzonderingen) ............................................................................ 32

2.3.4

Meting ....................................................................................................................... 33

2.3.5

Prijscorrectie/penalty’s ............................................................................................... 33

2.3.6

Rapportering .............................................................................................................. 34

Onderlinge invloeden van SLA’s op verschillende niveaus ........................................................ 35 3.1

Opdeling van SLA’s in verschillende niveaus .................................................................... 35

3.1.1 3.2

Definities ................................................................................................................... 37

Key Performance Indicators(KPI’s) ................................................................................... 38

3.2.1

Facility KPI’s............................................................................................................. 38

3.2.2

Hardware KPI ............................................................................................................ 39

3.2.3

Networking KPI’s ...................................................................................................... 41

3.2.4

Application KPI’s ...................................................................................................... 42

3.2.5

SaaS en Cloud computing KPI’s ................................................................................ 42

3.3

Onderlinge invloeden......................................................................................................... 43

3.3.1

Facility & Hardware laag ........................................................................................... 43 Page | ii


Ken Van Rafelghem

3.3.2

Hardware & netwerk laag .......................................................................................... 45

3.3.3

Netwerk en applicatie / SaaS / Cloud computing lag ................................................... 45

3.4

Besluit onderlinge invloeden.............................................................................................. 46

Besluit .............................................................................................................................................. 47 Literatuurlijst .................................................................................................................................... vi

Page | iii


Ken Van Rafelghem

Lijst van Afbeeldingen en tabellen Afbeeldingen Figuur 1 Overzicht geselecteerde processen uit CobIT ........................................................................2 Figuur 2 datacenter activiteiten in verschillende niveaus volgens stijgende uitbesteding .................... 35 Figuur 3 Onderlinge invloeden tussen facilities en hardware 1........................................................... 43 Figuur 4 Onderlinge invloeden tussen facilities en hardware 2........................................................... 44 Figuur 5 Onderlinge invloeden tussen facilities en hardware 3........................................................... 44 Figuur 6 Onderlinge invloeden tussen hardware en networking ......................................................... 45 Figuur 7 Onderlinge invloeden tussen networking en Applicaties, SaaS en Cloud computing 1 ......... 45 Figuur 8 Onderlinge invloeden tussen networking en Applicaties, SaaS en Cloud computing 2 ......... 46

Tabellen Tabel 1 Definities van gebruikte terminologie in het piramide model ................................................ 37

Page | iv


Ken Van Rafelghem

Inleiding Deze masterproef is uitgevoerd in samenwerking met Ingenium n.v. uit Brugge. Ingenium, dat al sinds 1966 bestaat, is een ingenieursbureau voor technische uitrusting in gebouwen, dat technische uitrusting samenbrengt met vormgeving, bestemming en functies van een gebouw. Zij houden zich voornamelijk bezig met consultancy, engineering, en commissioning. De aanleiding tot het schrijven van deze masterproef komt uit de trend van de hedendaagse IT infrastructuur om door de alsmaar toenemende apparatuur steeds groter en complexer te worden en zo dus, ook het beheer ervan. Het gevolg hiervan is dat steeds meer bedrijven gaan kiezen om hun IT-infrastructuur uit te besteden naar datacenters. Deze trend zorgt dat er een grotere verantwoordelijkheid komt te liggen op de schouders van de datacenter-managers. Daar ook de meeste moderne computertoepassingen bedrijfskritisch zijn met navenante data, is het zeer belangrijk dat afspraken tussen klant en data center zeer duidelijk vastgelegd zijn. Het contract tussen de leverancier (het datacenter) en de klant(het bedrijf) wordt dan een Service Level Agreement (SLA) genoemd. Hoewel men kan stellen dat er 2 soorten datacenters zijn: deze in eigen beheer en datacenters voor collocatie die als dienst geleverd worden, wordt in deze masterproef gefocust op externe datacenters. Allereerst is er vanuit academisch standpunt, gekeken hoe CobiT, een framework van best practices voor IT management, zich positioneert tegenover de eisen van Service Level Agreements in Datacenters. CobIT is een framework is dat opgebouwd is aan de hand van ervaringen uit de praktijk, en aangezien een datacenter uiteindelijk toch een eerder praktische aangelegenheid is, hebben we hier dan ook voor gekozen. In een tweede fase is er gekeken naar SLA’s in de praktijk. Wat zijn SLA’s en wat is de specifieke opbouw van een SLA? Wanneer we SLA’s van verschillende bedrijven vergelijken, zien we dat deze er telkens anders uitzien. Dit is niet anders bij SLA’s voor datacenters. Ten slotte is er een studie gebeurd naar de onderlinge invloed van SLA’s op verschillende niveaus in datacenters. Daarvoor is er eerst een opdeling van de datacenter services in verschillende niveaus gebeurd volgens stijgende graad van uitbesteding. Daarna is er nog eens van dichtbij naar de verschillende KPI’s (Key performance indicators) gekeken en naar de onderlinge invloeden over tussen de lagen onderling. Uiteindelijk trekken we dan uit de conclusies van elk deel een besluit. Het doel van deze masterproef is een klant die een bepaalde service contracteert bij een datacenter te laten weten waar hij rekening moet houden, teneinde een goed datacenter te kiezen voor zijn data. Page | v


1

Ken Van Rafelghem

CobIT voor Service Level Agreements in Datacenters Om te beginnen is er een theoretische studie gemaakt van de belangrijke zaken in een datacenter die noodzakelijk zijn om goede Service Level Agreements te kunnen opstellen. Om hier structuur aan te geven hebben we gebruik gemaakt van een framework. Aangezien we in datacenters toch voornamelijk in een praktische wereld zitten en CobIT wat meer praktijk gericht is dan ITIL, hebben we uiteindelijk gekozen om CobIT als framework te gebruiken. De ‘Control Objectives for Information and related Technology’, kortweg CobIT genoemd, is een verzameling van ‘best practices’ verdeeld over 34 processen ondergebracht in 4 beheersdomeinen. Van de 4 beheersdomeinen: •

Plan & Organise

•

Acquire & Implement

•

Deliver & Support

•

Monitor & Evaluate

zijn vooral de processen in Deliver & Support en Monitor & Evaluate van belang voor de Service Level Agreements in Datacenters. Wanneer men zich ook gaat bezig houden met het daadwerkelijk managen van een datacenter, zal ook rekening gehouden moeten worden met een aantal processen uit de andere twee beheersdomeinen (Plan & Organise en Acquire & Implement)

Page | 1


Ken Van Rafelghem

1.1 Wat zijn SLA’s en wat zegt Cobit? Een Service Level Agreement of SLA is een overeenkomst tussen klant en leverancier (hier: het datacenter) waarbij een garantie gegeven wordt een bepaald niveau op een bepaalde service te leveren. Hierop wordt dieper ingegaan in het tweede deel van deze masterproef. Voor het opstellen van Service Level Agreements moet volgens CobIT rekening gehouden met volgende processen: Figuur 1 Overzicht geselecteerde processen uit CobIT

Page | 2


Ken Van Rafelghem

Hieronder volgt proces per proces een overzicht van wat CobIT zegt over de processen uit Deliver & Support en Monitor & Evaluate die van toepassing zijn op datacenters. 1.1.1 Delivery & Support Allereerst bekijken we de beschrijving van elk proces uit CobIT en halen we de belangrijke punten uit. Vervolgens passen we deze punten toe op datacenters. Alle processen zijn uitgekozen, net omdat ze van toepassing zijn op datacenters en hun invloed hebben op SLA’s. In 1.2 bekijken we dan de invloeden die deze processen hebben op SLA’s. DS1 Define and Manage Service Levels Beschrijving: Efficiënte communicatie tussen het IT management en de klanten betreffende vereiste services wordt mogelijk gemaakt door een gedocumenteerde definitie en akkoord over de IT services en service levels. Dit proces bevat ook monitoring en rapportering van behaalde resultaten van de service levels aan de belanghebbenden. Dit proces laat toe IT services en de gerelateerde bedrijfsnoden op 1 lijn te brengen. Key points: •

Gedocumenteerde definitie van services en service levels

•

Akkoord tussen bedrijf en klant

•

Monitoring

•

Rapportering behaalde resultaten aan belanghebbenden

Hoe gaat dit in datacenters: Dit proces is het enige proces in Deliver & Support dat direct gelinkt kan worden aan SLA’s in datacenters. Wat hier zeker benadrukt moet worden is dat monitoring en rapportering in een datacenter zeer belangrijk is. De klant wil namelijk weten waarvoor hij betaald, en zonder monitoring is het uiteraard niet mogelijk een deftig rapport te schrijven.

Page | 3


Ken Van Rafelghem

DS2 Manage Third-party Services Beschrijving: Er is een nood aan garanties dat de services geleverd door derden (leveranciers, verkopers en partners) voldoen aan bedrijfsnoden, dit vereist een efficiënt proces voor het beheer van derden. Dit proces wordt gerealiseerd door het duidelijk definiëren van taken, verantwoordelijkheden en verwachtingen in overeenkomsten met derden, evenals het herbekijken en monitoren van de efficiëntie en naleving van dergelijke akkoorden. Het doeltreffend managen van services van derden minimaliseer het risico geassocieerd met leveranciers die niet voldoen aan de voorop gestelde eisen.

Key points: •

Duidelijk definiëren van taken, verantwoordelijkheden en verwachtingen

•

Herbekijken en monitoren van efficiëntie en naleving van akkoorden

Hoe gaat dit in datacenters: Een datacenter gaat grotendeels op zichzelf kunnen functioneren. Het is echter afhankelijk van derden voor zijn 2 grootste noden: stroom en internet. Indien een externe firma ingehuurd wordt voor het fysische beveiligen van de faciliteiten valt dit hier uiteraard ook onder. Hiervoor is het dan ook noodzakelijk dat het zorgt dat zijn Service Level Agreements met zijn leveranciers in orde zijn (daarin staan de taken, verantwoordelijkheden en verwachtingen gedefinieerd Via de rapportering die zij dan krijgen kunnen ze zien hoe goed de akkoorden nageleefd zijn en indien nodig beslissen van leverancier te veranderen.

Page | 4


Ken Van Rafelghem

DS3 Manage Performance and Capacity Beschrijving: De noodzaak om performantie en capaciteit van IT resources te beheren vereist een proces om deze periodiek te herbekijken. Dit proces omvat het bepalen van toekomstige noden gebaseerd op de belasting, de opslag en de contingentie vereisten. Dit proces geeft zekerheid dat de informatiebronnen die de bedrijfsnoden ondersteunen continu beschikbaar zijn.

Key points: •

Periodiek herbekijken performantie en capaciteit

•

Bepalen toekomstige noden

Hoe gaat dit in datacenters: Het is noodzakelijk om op reguliere tijdstippen te kijken hoeveel capaciteit het datacenter nog aankan. Dit geldt voornamelijk voor de capaciteit van de stroomvoorziening, beschikbare ruimte, of de CRAC(computer room air conditioning) het aankan een grotere warmtehoeveelheid te koelen, of er genoeg bandbreedte is voor piekmomenten, etc. Daarnaast moet er ook gekeken worden hoe goed de huidige infrastructuur werkt, of bepaalde servers performant genoeg draaien, … Door dit periodiek te monitoren, kan een trend vastgesteld worden en kunnen toekomstige noden ingecalculeerd worden, waardoor problemen in de toekomst vermeden kunnen worden.

Page | 5


Ken Van Rafelghem

DS4 Ensure Continuous Service Beschrijving: De noodzaak om continue IT services te leveren vereist ontwikkeling, onderhoud en testen van IT continuïteitsplannen, gebruik van offsite back-up opslag en het geven van periodieke training in het continuïteitsplan. Een doeltreffend continuïteitsproces minimaliseert de waarschijnlijkheid en impact van een grote onderbreking van IT services op belangrijke functies en processen.

Key points: •

Ontwikkeling, onderhoud en testen van continuïteitsplannen

•

Offsite back-up opslag

•

Periodieke training in het continuïteitsplan

Hoe gaat dit in datacenters: Een datacenter is een bedrijf, dat technisch gezien in staat moet zijn heel het jaar door altijd draaiende te blijven. Hiervoor is het belangrijk dat er continuïteitsplannen opgesteld worden om de continuïteit van o.a. faciliteiten, servers, en aangeboden services te kunnen garanderen. Dit is de eigenlijke kernbezigheid van een datacenter, dus moet dit uiteraard perfect werken. Teneinde dit te kunnen verwezenlijken, is het belangrijk dat het datacenter personeel alle continuïteitsplannen perfect beheerst, en dat er beschikt kan worden over offsite back-ups zodat er, wat er ook gebeurd altijd beschikbare data is.

Page | 6


Ken Van Rafelghem

DS5 Ensure Systems Security Beschrijving: Het behoud van de integriteit van informatie en bescherming van IT onderdelen, vereist een proces voor het beheren van de beveiliging. Dit proces zorgt onder andere voor het creëren en onderhouden van IT beveiligingstaken, verantwoordelijkheden, policies, standaarden en procedures. Het beheer van beveiliging omvat ook het monitoren en periodiek testen van de beveiliging en het implementeren van correctieve acties voor geïdentificeerde incidenten of zwakke plekken in de beveiliging. Doeltreffend beheer van de beveiliging beschermt alle onderdelen van de IT, teneinde de impact van deze incidenten of zwaktes op de business te minimaliseren.

Key points: •

Creëren en onderhouden IT beveiligingstaken, verantwoordelijkheden, policies, standaarden en procedures

•

Monitoren en periodiek testen beveiliging

•

Geïdentificeerde incidenten of zwaktes corrigeren

Hoe gaat dit in datacenters: Een datacenter beheert vaak bedrijfskritische data, het is dus van belang dat deze zo veilig mogelijk beheerd wordt. Om dit te verwezenlijken moeten duidelijke afspraken gemaakt worden over hoe de faciliteiten, fysische hardware en data beveiligd worden. Hiervoor zullen bewakers, IT-managers, etc. een bepaalde verantwoordelijkheid krijgen, die ze volgens vastgestelde regels moeten uitvoeren. Op deze manier wordt het risico dat er iets fout gaat drastisch verminderd. Wanneer door testen of incidenten zwakke punten geïdentificeerd worden, worden deze zo vlug mogelijk gecorrigeerd.

Page | 7


Ken Van Rafelghem

DS7 Educate and Train Users Beschrijving: Om een doeltreffende opleiding te geven aan alle gebruikers van IT systemen, inclusief deze binnen de IT, moeten de noden aan training binnen elke gebruikersgroep geïdentificeerd worden. Bovendien, vereist dit proces ook dat er een strategie voor doeltreffende opleidingen gedefinieerd en uitgevoerd wordt, en dat de resultaten gemeten worden. Een doeltreffende training verhoogt het efficiënt gebruik van technologie door het aantal gebruikersfouten te verminderen, de productiviteit te verhogen en de overeenstemming met cruciale controls, zoals veiligheidsmaatregels, te verbeteren.

Key points: •

Noden aan training in elke gebruikersgroep identificeren

•

Strategie voor doeltreffende opleiding definiëren en uitvoeren

•

Meting van resultaten

Hoe gaat dit in datacenters: Een datacenter dat de mogelijkheid geeft tot collocatie zal nooit homogeen zijn, aangezien de klanten de mogelijkheid hebben hun eigen servers daar te plaatsen. Aangezien de werknemers kennis moeten hebben van o.a. alle verschillende types servers, is het logisch dat er regelmatig bijscholingen georganiseerd worden. De resultaten hiervan zijn dan meetbaar aan de hand van bv. de terugval van interventietijd, of de snelheid waarbij mensen bij de helpdesk geholpen worden.

Page | 8


Ken Van Rafelghem

DS8 Manage Service Desk and Incidents Beschrijving: Om een snelle en doeltreffende respons te geven aan vragen en problemen van IT gebruikers is een goed ontwikkeld en goed uitgevoerd beheer van de helpdesk en het incident management proces. Dit proces omvat het opzetten van een helpdesk functie met registratie, incident escalatie, trend en bron oorzaak analyse en resolutie. Ook een verhoogde productiviteit, door middel van een snelle oplossing van vragen van de gebruikers bevat bedrijfsvoordelen. Bovendien kan het bedrijf oorzaken aan de bron adresseren (zoals bv. Slechte gebruikerstraining) dankzij efficiënte rapportering.

Key points: •

Opzetten helpdesk o Registratie o incident escalatie o trend analyse en resolutie o bron oorzaak analyse en resolutie

Hoe gaat dit in datacenters: Een bedrijf dat zijn servers onderbrengt bij een datacenter, verwacht met vragen en problemen terecht te kunnen bij een helpdesk. Deze helpdesk moet dus in staat zijn om vragen en problemen te registreren, incidenten die gemeld worden te escaleren en door te geven aan de technici. Van veel voorkomende problemen kan dan een vaste oplossingsmethode opgesteld worden.

Page | 9


Ken Van Rafelghem

DS9 Manage the Configuration Beschrijving: Om de integriteit van de hard- en software configuraties te garanderen, vereist het opzetten en onderhouden van een accurate en complete configuratie bibliotheek. Dit proces houdt ook in dat in het begin configuratie informatie verzameld wordt, er baselines opgesteld worden, configuratie informatie geverifieerd en ge-audit wordt, en de configuratie bibliotheek geüpdate wordt wanneer nodig. Doeltreffend configuratie management vergemakkelijkt een grote beschikbaarheid van systemen, minimaliseert productieproblemen en lost problemen vlugger op.

Key points: •

Opzetten en onderhouden accurate en complete bibliotheek

•

Configuratie informatie verzamelen, verifiëren en auditen.

•

Baselines opstellen

•

Configuratie bibliotheek updaten wanneer nodig

Hoe gaat dit in datacenters: In een datacenter heeft men honderden, duizenden verschillende servers staan, verspreid over verschillende zalen, in verschillende racks. Allemaal met verschillende hardware en een verschillende configuratie. Aangezien een technicus op het moment dat een probleem gemeld word, met bijvoorbeeld een kapotte netwerkkaart, moet weten over wat type server het is, welke kaart het is, zodat hij deze onmiddellijk kan meenemen. Zo zal hij ook de zaal, het rack en de locatie van de server in het rack, alsook de configuratie van de netwerkkaart moeten weten. Deze gegevens worden dan ook allemaal bijgehouden in een soort configuration log/ bibliotheek.

Page | 10


Ken Van Rafelghem

DS10 Manage Problems Beschrijving: Het doeltreffend beheren van problemen vereist het identificeren en classificeren van problemen, analyse van de oorzaken aan de bron en oplossing van problemen. Het proces van probleembeheer omvat ook het formuleren van aanbevelingen voor verbetering, onderhoud van records met problemen en het herzien van de toestand van correctieve handelingen. Een doeltreffend probleemmanagement proces maximaliseert de beschikbaarheid van systemen, verbetert service levels, vermindert kosten, en verbetert de tevredenheid van klanten.

Key points: •

Identificeren en classificeren van problemen

•

Analyse oorzaken aan de bron

•

Oplossing van problemen

•

Formuleren van aanbevelingen voor verbetering

•

Onderhoud van records met problemen

•

Herzien toestand correctieve handelingen

Hoe gaat dit in datacenters: Wanneer er zich problemen voordoen in een datacenter, dan moet de interventie gedocumenteerd worden, evenals de vermoedelijke oorzaak en de oplossingswijze. Dit is afkomstig van de grote nood in datacenters om te monitoren. Op deze wijze, kan men de volgende keer dat een probleem zich voordoet zich beroepen op het vorige gevonden oplossingsmethode. Wanneer het een wederkerend probleem bedraagt wordt uiteraard naar een permanente oplossing gezocht.

Page | 11


Ken Van Rafelghem

DS11 Manage Data Beschrijving: Het efficiënt managen van data vereist het identificeren van de vereisten van die data. Het data management proces omvat ook het opzetten van doeltreffende procedures om de media bibliotheek, de back-up en recovery van data, en het correcte verwijderen van data te beheren. Doeltreffend beheer van data helpt bij het garanderen van de kwaliteit, stiptheid en beschikbaarheid van de data.

Key points: •

Identificeren vereisten van data

•

Opzetten doeltreffende procedures om media, back-up en recovery en verwijderen van bestanden te beheren

Hoe gaat dit in datacenters: Een datacenter manager zal zeer goed rekening moeten houden met de vereisten van zijn data: is het videodata, dat gestreamd moet worden? Of gaat het gewoon om documenten die af en toe opgevraagd worden. Vooraleer hij toestemt om bepaalde data toe te laten zal hij dus eerst moeten checken of hij nog de nodige capaciteit heeft om die server met data te huisvesten. Bovendien moet er altijd een goede back-up en recovery aanwezig zijn in een datacenter, aangezien het de bedoeling is de klant zo min mogelijk downtime te garanderen. Om te voorkomen dat er iets mis gaat tijdens het maken en stockeren van back-ups of tijdens de recovery van data, zijn vaste procedures nodig.

Page | 12


Ken Van Rafelghem

DS12 Manage the Physical Environment Beschrijving: Bescherming voor het computermateriaal en personeel vereist goed ontworpen en beheerde fysieke faciliteiten. Het proces voor het beheer van fysische faciliteiten omvat het definiëren van vereisten voor de fysieke site, het selecteren van toepasselijke faciliteiten en doeltreffende processen ontwerpen voor het monitoren van omgevingsfactoren en het beheren van fysieke toegang. Doeltreffend beheer van de fysieke omgeving vermindert onderbrekingen van het bedrijfsleven omwille van schade aan computermateriaal en personeel.

Key points: •

Definiëren van vereisten voor de fysieke site

•

Selecteren toepasselijke faciliteiten

•

Monitoren omgevingsfactoren

•

Beheren fysieke toegang

Hoe gaat dit in datacenters: Van een datacenter wordt verondersteld dat het de meeste incidenten kan doorstaan zonder onderbrekingen. Indien er risico is op aardbevingen of overstromingen, dan moet de datacenter manager zorgen dat het datacenter daar tegen bestand is. Ook moet het fysieke toegang tot het datacenter beheerd worden, zodat er geen onbevoegden binnen kunnen komen, dit kan bijvoorbeeld met een elektronische kaart of door een bewaker aan de ingang te zetten. Daarnaast moet ook intern de omgeving beheerd worden, zoals het plaatsen van racks, de servers in de racks, de koeling, het brandblussysteem, stroomtoevoer etc.

Page | 13


Ken Van Rafelghem

DS13 Manage Operations Beschrijving: Volledig en precies verwerken van data vereist doeltreffende datamanagement procedures en diligent onderhoud van hardware. Dit proces omvat het definiëren van operating policies en procedures voor het doeltreffend managen van geplande gegevensverwerking, bescherming van gevoelige output, monitoren van de performantie van de infrastructuur en het garanderen van preventief onderhoud van de hardware. Doeltreffend operations management helpt de integriteit van data te behouden en verlaagt vertragingen en de kosten van de IT operations.

Key points: •

Operating policies en procedures definiëren voor o Doeltreffend managen geplande gegevensverwerking o Bescherming gevoelige output o Monitoren performantie van infrastructuur o Garanderen preventief onderhoud hardware.

Hoe gaat dit in datacenters: Dit is een proces dat normaal gezien dagdagelijks aanwezig moet zijn in een datacenter. Zowel het managen van de gegevens, als het beschermen van de data, als het monitoren wordt uitgevoerd in een datacenter, Wanneer men problemen heeft met een bepaald stuk hardware, of merkt dat het problemen begint te geven zal men dit hoogstwaarschijnlijk ook preventief vervangen door en nieuw stuk, teneinde enkele weken later niet met een uitval te zitten vanwege dat kapotte stuk.

Page | 14


Ken Van Rafelghem

1.1.2 Monitor & Evaluate

ME1 Monitor and Evaluate IT performance Beschrijving: Efficiënt beheer van IT performantie, vereist een monitoring proces. Dit proces houdt onder meer het definiëren van relevante performantie indicatoren, systematische en tijdige rapportering van de performantie evenals onmiddellijk handelen bij uitwijkende waarden.

Key points: •

Definiëren performantie indicatoren

•

Systematische en tijdige rapportering performantie

•

Onmiddellijk handelen

Hoe gaat dit in datacenters: In een datacenter worden ook key performance indicators vastgesteld. De performantie van deze onderdelen wordt zeer nauwkeurig gemonitord aangezien het datacenter bepaalde cijfers moet halen om hun SLA’s na te leven. Dit wordt in het volgende punt wat meer uitgelegd (1.2)

Page | 15


Ken Van Rafelghem

ME2 Monitor and Evaluate internal Control Beschrijving: Het opzetten van een efficiënt intern beheer voor IT vereist een goed gedefinieerd monitoring proces. Dit proces omvat het monitoren en rapporteren van uitzonderlijke gevallen, resultaten van zelfbeoordelingen en reviews van derden. Één van de kernvoordelen van het monitoren van het intern beheer is dat er zekerheid bestaat betreffende doeltreffende en efficiënte handelingen alsook dat alles overeenstemt met de wetten en afspraken die erop van toepassing zijn.

Key points: •

Monitoren en rapporteren o Uitzonderingen o Zelfbeoordelingen o Reviews van derden

•

Zekerheden betreffende o Doeltreffend en efficiënt handelen o In orde zijn van wettelijke eisen en afspraken

Hoe gaat dit in datacenters: Zoals eerder al vermeld, is monitoring altijd een noodzaak in een datacenter, als er zich dan een uitzondering voordoet, kan er gekeken worden of het om een toevallige gebeurtenis ging, of dat het iets was dat echt aan een mankement of slechte organisatie te wijten is. Op deze manier gaat men aan een soort zelfherstel doen, en de fouten er beetje bij beetje uithalen. Net door dit registreren van allerhande informatie en ernaar te handelen, kan men efficiënter en doeltreffender handelen wanneer zich iets voordoet, en is men ook zeker dat zaken zoals bv. het brandafweersysteem wettelijk in order zijn.

Page | 16


Ken Van Rafelghem

1.2 Wat betekent dit specifiek in Service Level Agreements? Nu we de Key points van elk proces gevonden hebben en gecontroleerd hebben of deze daadwerkelijk ook van toepassing waren op datacenters, gaan we dit ook doen voor SLA’s. Indien dit ook lukt, betekend dit dat CobIT een volwaardig framework is voor het beheer van SLA’s in datacenters.

1.2.1 Delivery & Support

DS1 Define and Manage Service Levels Key points: •

Gedocumenteerde definitie van services en service levels

•

Akkoord tussen bedrijf en klant

•

Monitoring

•

Rapportering behaalde resultaten aan belanghebbenden

Hoe beïnvloed dit SLA’s: Service levels zijn contracten die afgesloten worden tussen verschillende partijen, dit houdt in dat beide partijen tevreden zullen moeten zijn en overeenkomen over wat er in het contract moet staan. Tot voor kort was dit veel te eenzijdig en werden de SLA’s gewoon aan de klant opgelegd, waarbij deze weinig tot geen inspraak had. Dit is nu aan het veranderen. Wat er ook zeker afgesproken moet worden is wat er gerapporteerd wordt, wanneer het gerapporteerd wordt en aan wie het gerapporteerd wordt. Het heeft geen zin om alles te rapporteren, als er maar 3 van de 200 dingen die gemeten worden van interesse zijn voor de klant. Teneinde dit te kunnen rapporteren moet er natuurlijk gemonitord worden. Het monitoren is een zeer belangrijk onderdeel voor het datacenter en voor het garanderen van een bepaald niveau van service. We zullen dit dus nog vaak zien terugkeren.

Page | 17


Ken Van Rafelghem

DS2 Manage Third-party Services Key points: •

Duidelijk definiëren van taken, verantwoordelijkheden en verwachtingen

•

Herbekijken en monitoren van efficiëntie en naleving van akkoorden

Hoe beïnvloed dit SLA’s: Wanneer een bedrijf afhangt van derden om een bepaalde service te leveren, dan kan dat bedrijf geen betere service leveren dan het niveau van service geleverd door die derden. Dit betekent dus dat het zeer belangrijk is om ook met derden duidelijke en klare afspraken te maken over hun niveau van service (SLA’s), en duidelijk te definiëren wat hun taken, verantwoordelijkheden en verwachtingen zijn. Omdat deze derden bepalen welk niveau van service er geleverd wordt, is het ook van belang hen continu te evalueren, om te zien of zij zich wel aan de afspraken houden en eventueel, indien het niet zo is, een andere leverancier te zoeken.

DS3 Manage Performance and Capacity Key points: •

Periodiek herbekijken performantie en capaciteit

•

Bepalen toekomstige noden

Hoe beïnvloed dit SLA’s: Een ander zeer belangrijk aspect bij het opstellen van SLA’s voor datacenters is dat er rekening gehouden moet worden met de (toekomstige) performantie en capaciteit. Dit is niet alleen belangrijk voor de klant, zodat deze weet dat zijn SLA’s nageleefd zullen worden, maar ook voor het datacenter: als zij periodiek de capaciteit van onder andere de beschikbare stroomvoorziening, beschikbare ruimte, koeling en de performantie van de servers controleren, zal het hen niet voorvallen dat ze een klant een SLA geven om enkele racks in hun datacenter te plaatsen, om dan tot de conclusie te moeten komen dat de CRAC (computer room air conditioning) niet krachtig genoeg meer is om alles gekoeld te houden, er niet genoeg ruimte beschikbaar is in het datacenter of dat de backup generatoren in geval van stroompanne niet genoeg stroom kunnen leveren voor het hele datacenter. Als ze dit periodiek bekijken kan er daar rekening mee gehouden worden en met het oog op de toekomst uitbreiden.

Page | 18


Ken Van Rafelghem

DS4 Ensure Continuous Service Key points: •

Ontwikkeling, onderhoud en testen van continuïteitsplannen

•

Offsite back-up opslag

•

Periodieke training in het continuïteitsplan

Hoe beïnvloed dit SLA’s: Als datacenter is het zeer belangrijk om te allen tijde te draaien. Als er een onderbreking van service is telkens er zich een incident voordoet, dan zullen de beloofde service levels niet gehaald worden. In geval van een effectieve onderbreking van service, moeten er plannen en situatieschetsen zijn waarop er teruggevallen kan worden om zo snel mogelijk de te leveren service opnieuw op gang te krijgen. In het geval van datacenters wordt dit in grote mate al gedaan door het ontdubbelen van hardware, netwerk, facilities, zelf in die mate dat alles wat op 1 datacenter draait ook op een tweede datacenter draait in het geval het eerste datacenter het om de een of andere reden zou begeven. Wanneer er een onderbreking van service is, zijn er 3 dingen belangrijk: •

De responstijd

•

De interventietijd

•

De resolutietijd

Als er voor deze 3 dingen een actieplan is uitgestippeld en dit gekend is door de werknemers, dan zal de service in een zo kort mogelijke periode weer draaien, wat de naleving van de SLA’s enkel ten goede kan komen. Indien de werknemers echter niet op de hoogte zijn van wat ze moeten doen wanneer een dergelijk falen zich voordoet, dat is het ook nutteloos van de actieplannen op te stellen. Hier wordt dus duidelijk hoe belangrijk het is om periodieke trainingen te doen met de werknemers, zodat zij altijd op de hoogte zijn, evenals hen van tijd tot tijd te testen.

Page | 19


Ken Van Rafelghem

DS5 Ensure Systems Security Key points: •

Creëren en onderhouden IT beveiligingstaken, verantwoordelijkheden, policies, standaarden en procedures

•

Monitoren en periodiek testen beveiliging

•

Geïdentificeerde incidenten of zwaktes corrigeren

Hoe beïnvloed dit SLA’s: Datacenters beheren vaak bedrijfskritische data voor bedrijven. Het staat dus zonder meer dat de beveiliging van de data en het datacenter van zeer groot belang is. Als bijvoorbeeld in de SLA staat dat het onderhoud van de servers door de klant zelf gedaan wordt, dan moet duidelijk afgesproken worden in welke delen van het datacenter hij zich mag begeven. Ook de communicatie over het netwerk tussen klant en datacenter is van groot belang en zal vastgelegd moeten worden in de SLA. Indien het een directe leased line van de klant naar het datacenter is, is er niet zo’n groot probleem maar als de data over het internet gaat, dan moet deze zeer goed beveiligd zijn, om het risico te verlagen dat de data onderschept en misbruikt worden. Het opstellen van specifieke taken, verantwoordelijkheden, policies, standaarden en procedures voor de beveiliging van de systemen/data zorgt ervoor dat er niet per ongeluk ergens een veiligheidslek gelaten wordt. Uiteraard moet ook dit gemonitord en getest worden en eventuele ontdekte zwakke plekken/gaten, zoals antivirus programma’s of firewalls die niet geüpdate worden, gecorrigeerd worden, evenals het beveiligen van fysieke toegang tot de systemen.

Page | 20


Ken Van Rafelghem

DS7 Educate and Train Users Key points: •

Noden aan training in elke gebruikersgroep identificeren

•

Strategie voor doeltreffende opleiding definiëren en uitvoeren

•

Meting van resultaten

Hoe beïnvloed dit SLA’s: Datacenters zitten vol hightech apparatuur en redundante faciliteiten die zeer veel geld kosten. Het is dan ook vanzelfsprekend, dat het personeel goed opgeleid moet zijn om hiermee te kunnen werken. Dit proces hangt ook grotendeels samen met het volgende proces: manage service desk and incidents. Het is een noodzaak dat iedereen in een datacenter weet waar hij mee bezig is en wat hij aan het doen is. Hiervoor is het dan ook belangrijk van trainingen te organiseren zodat de vaardigheden van de werknemers up-to-date blijven. Dit geldt natuurlijk niet alleen voor de helpdeskmedewerkers, zodat deze klanten efficiënter kunnen helpen, maar ook voor bijvoorbeeld de technici die het onderhoud en de incidenten van de servers, faciliteiten (koeling, bekabeling, het netwerk, stroomtoevoer, …) e.d. afhandelen. Als gevolg hiervan gaan de interventietijden en resolutietijden dalen, wat een betere naleving van de SLA’s als gevolg heeft.

Page | 21


Ken Van Rafelghem

DS8 Manage Service Desk and Incidents Key points: •

Opzetten helpdesk o Registratie o incident escalatie o trend analyse en resolutie o bron oorzaak analyse en resolutie

Hoe beïnvloed dit SLA’s: Het is belangrijk dat de klant iemand kan bereiken die hem kan helpen/te woord kan staan wanneer hij een probleem heeft. Hiervoor is de service desk zeer belangrijk. Deze mensen moeten weten waarover ze praten, en de klant kunnen helpen met eventuele problemen, evenals het in gang zetten van de afhandeling van een incident. De registratie van incidenten is belangrijk, zodat eventuele trends daaruit kunnen afgeleid worden via monitoring, evenals de oplossingswijze in een databank kan ingegeven worden, zodat de resolutietijd de volgende keer een stuk lager zal zijn. Als er een effectieve trend zit in een bepaald type incident, kan er ook een bronanalyse uitgevoerd worden zodat het eventueel permanent verholpen kan worden. Ook belangrijk is dat indien de service desk de klant niet kan helpen met een probleem, zij het incident kunnen escaleren, zodat het probleem bij mensen met een grotere technische kennis terechtkomt. In een SLA zal voornamelijk bepaald worden welke ondersteuning de klant van de servicedesk verwacht, welke resolutietijd er aanvaardbaar is, first of second line support, of de interventies 24/24 7/7 moeten gebeuren of enkel gedurende de werkuren, etc.

Page | 22


Ken Van Rafelghem

DS9 Manage the Configuration Key points: •

Opzetten en onderhouden accurate en complete bibliotheek

•

Configuratie informatie verzamelen, verifiëren en auditen.

•

Baselines opstellen

•

Configuratie bibliotheek updaten wanneer nodig

Hoe beïnvloed dit SLA’s: In een datacenter is het van zeer groot belang om gestructureerd tewerk te gaan. Er moet een lay-out en een configuratie bibliotheek opgesteld worden waarin duidelijk gedefinieerd staat van wie welke kooi in het datacenter is, welke servers daar staan, welke hardware erin zit, hoe de servers geconfigureerd zijn. Indien er dan een server het begeeft, wegens kapotte hardware of iets niet werkt wegens een slechte configuratie, kan dit veel vlugger verholpen worden indien we onmiddellijk weten welke hardware we nodig hebben, waar de server ergens staat en wat zijn huidige configuratie is. Indien er dan iets verandert, is het natuurlijk van groot belang dat deze wijziging ook in de bibliotheek doorgevoerd wordt, teneinde te vermijden dat we ons de volgende keer op slechte data baseren. Telkens er iets wijzigt aan de bibliotheek, bijvoorbeeld een ander type netwerkkaart in een server, een server die van plaats in het rack, of van rack veranderd of de configuratie van een firewall veranderd, is het van groot belang dat deze wijzigingen eerst grondig gecontroleerd en geverifieerd worden, vanwege voorgenoemde reden.

Page | 23


Ken Van Rafelghem

DS10 Manage Problems Key points: •

Identificeren en classificeren van problemen

•

Analyse oorzaken aan de bron

•

Oplossing van problemen

•

Formuleren van aanbevelingen voor verbetering

•

Onderhoud van records met problemen

•

Herzien toestand correctieve handelingen

Hoe beïnvloed dit SLA’s: Dit is nog een proces dat grotendeels vast hangt aan manage service desk and incidents. De uitvoering van de eerder vermeldde processen, Manage Service Desk and Incidents en Educate and Train Users, zal samen met dit proces van belang zijn wanneer men resolutie, respons- en interventietijden vastlegt in de SLA. Een goede uitvoering van dit proces zal trouwens ook het aantal fouten en problemen doen afnemen, wat de SLA’s nogmaals ten goede komt.

Page | 24


Ken Van Rafelghem

DS11 Manage Data Key points: •

Identificeren vereisten van data

•

Opzetten doeltreffende procedures om media, back-up en recovery en verwijderen van bestanden te beheren

Hoe beïnvloed dit SLA’s: De manier waarop data in een datacenter beheerd wordt is natuurlijk van zeer groot belang. Dit gaat van ontdubbelen, naar back-ups op een offsite locatie nemen, naar het beveiligen van die data. Indien de klant hier specifieke eisen voor heeft, dan kan dit in de SLA vastgelegd worden. Hiervoor is het dus van belang dat men weet wat voor data men heeft. Als het bijvoorbeeld streaming videodata betreft, zal daar in de SLA rekening mee gehouden moeten worden door genoeg o.a. genoeg bandbreedte toe te wijzen.

Page | 25


Ken Van Rafelghem

DS12 Manage the Physical Environment Key points: •

Definiëren van vereisten voor de fysieke site

•

Selecteren toepasselijke faciliteiten

•

Monitoren omgevingsfactoren

•

Beheren fysieke toegang

Hoe beïnvloed dit SLA’s: Ook met het beheer van de fysische omgeving zal rekening gehouden moeten worden bij het opstellen van de SLA. Wanneer een klant vraagt een bepaalde applicatie voor hem te draaien, zal gezorgd moeten worden dat de server waarop de applicatie draait voldoende stroom krijgt en degelijk gekoeld is zodat er geen vermindering van service is, omdat bijvoorbeeld de server oververhit is geraakt. Ook wanneer een klant enkel en alleen een aantal m² of een kooi wil huren om zijn servers in te plaatsen, en zelf verantwoordelijk wil zijn voor zijn eigen service, zullen duidelijke afspraken gemaakt moeten worden over o.a. de stroomtoevoer naar de servers, de koeling, eventuele beveiliging met elektronische kaart tot de kooi waarin de servers staan, etc.

Page | 26


Ken Van Rafelghem

DS13 Manage Operations Key points: •

Operating policies en procedures definiëren voor o Doeltreffend managen geplande gegevensverwerking o Bescherming gevoelige output o Monitoren performantie van infrastructuur o Garanderen preventief onderhoud hardware.

Hoe beïnvloed dit SLA’s: In een SLA zal in geval van gevoelige data ook gedefinieerd moeten staan hoe deze beveiligd wordt vooraleer ze zomaar de cloud ingestuurd wordt. Ook moet er afgesproken worden wie, in het geval dat de klant zijn servers zelf beheerd, het onderhoud van de hardware doet en bijvoorbeeld preventief stukken vervangt omdat de laatste rapporten een gebrekkige performantie aantonen.

Page | 27


Ken Van Rafelghem

1.2.2 Monitoring & Evaluate

ME1 Monitor and Evaluate IT performance Key points: •

Definiëren performantie indicatoren

•

Systematische en tijdige rapportering performantie

•

Onmiddellijk handelen

Hoe beïnvloed dit SLA’s: SLA’s worden op deze performantie indicatoren afgesloten. Dit zijn zaken zoals QoS, availability, responstijden en interventietijden, bandbreedte, … Het monitoren en rapporteren hiervan is dan ook van groot belang, aangezien de klant wil weten dat datgene waarvoor hij betaald in zijn SLA, ook daadwerkelijk nagekomen wordt. Wanneer er bij deze performantie indicatoren iets faalt, zal er onmiddellijk gehandeld moeten worden, of loopt men het risico dat het service level niet gehaald wordt en er penalty’s betaald zullen moeten worden.

Page | 28


Ken Van Rafelghem

ME2 Monitor and Evaluate internal Control Key points •

Monitoren en rapporteren o Uitzonderingen o Zelfbeoordelingen o Reviews van derden

•

Zekerheden betreffende o Doeltreffend en efficiënt handelen o In orde zijn van wettelijke eisen en afspraken

Hoe beïnvloed dit SLA’s: Dit heeft een eerder indirecte invloed op SLA’s. Door zelf aan permanente zelfevaluatie te doen, is eer een veel grotere mogelijkheid, dat fouten ontdekt worden voor ze problemen beginnen te geven. Uiteraard moet er gehandeld worden als een klant melding geeft van problemen, zelf als zijn SLA dit niet dekt, want uiteindelijk zorgt dit ervoor dat het datacenter in zijn geheel beter draait.

1.3 Besluit: CobIT: yes or no Allereerst hebben we uit CobIT een aantal processen geselecteerd te hebben waarvan we dachten dat deze van toepassing zouden zijn op zowel datacenters als Service Level Agreements. Vervolgens hebben we deze processen dan ook stuk voor stuk vergeleken met zowel een datacenter als met Service Level Agreements, en hun invloeden hierop bekeken. Hieruit bleek dat deze processen zich stuk voor stuk rond zowel datacenters, als Service Level Agreements lieten plaatsen. We kunnen dus concluderen dat CobIT inderdaad een kader biedt om Service Level Agreements in datacenters te behandelen.

Page | 29


2

Ken Van Rafelghem

SLA’s Wanneer in het dagelijkse leven een bepaalde afspraak gemaakt wordt, gebeurd dit meestal mondeling, zonder er al te veel bij na te denken. Als deze afspraak echter niet nageleefd wordt zal de benadeelde, hoewel een mondelinge overeenkomst ook een geldige overeenkomst is, het zeer moeilijk hebben om dit te bewijzen. Een rechtstreeks gevolg hiervan is dat voor belangrijke afspraken contracten worden afgesloten, afspraken vastgelegd op papier en ondertekend door beide partijen. Wanneer deze afspraken betrekking hebben tot het leveren van diensten en services van een bepaald niveau, spreken we van Service Level Agreements, afgekort, SLA’s.

2.1 Wat zijn SLA’s SLA’s of Service Level Agreements, zijn dus contracten tussen leverancier en klant waarin een bepaald soort service en service niveau worden vastgelegd. Aan de hand van deze contractueel vastgelegde afspraken kan de klant dan effectief bijhouden/meten of hij krijgt waarvoor hij betaalt. In de SLA wordt ook een deel voorzien met vooraf afgesproken vergoedingen voor de klant, wanneer de voorwaarden niet gehaald worden. Het doel van SLA’s is dan ook niet het verzamelen van vergoedingen maar het hebben van een stok achter de deur in geval de geleverde kwaliteit niet voldoet aan de onderling gemaakte afspraken.

2.2 Waarom zijn SLA’s in datacenters nodig Door het steeds complexer wordende IT infrastructuur vinden veel bedrijven het moeilijker en moeilijker om hun eigen serverpark nog zelf te beheren. Door de groeiende complexiteit van de IT infrastructuur, moet er meer en duurder personeel(gespecialiseerd) ingezet worden om het beheer hiervan te doen. Daarbovenop komt ook nog eens dat de servers niet alleen krachtiger geworden zijn over de jaren maar ook meer en meer energie verslinden. De oplossing bij uitstek voor veel bedrijven is dus hun serverpark/ IT infrastructuur te gaan uitbesteden. Aangezien we hier echter spreken over het uit handen geven van een serverpark waarop heel wat bedrijfskritische applicaties draaien en niet over het uitlenen van een boek aan de buurman, zijn hier zeer duidelijke afspraken voor nodig. Dat is waar de Service Level Agreements in het plaatje komen.

Page | 30


Ken Van Rafelghem

2.3 Wat staat er in SLA’s Hoewel een SLA geen gedocumenteerde vaste vormgeving heeft, kan men er doorgaands een 6-tal vaste onderdelen in terugvinden. Het staat de klant of leverancier (hier: het datacenter) echter volledig vrij daar onderdelen aan toe te voegen naar eigen noodzaak. 2.3.1

Inhoud Een eerste punt dat teruggevonden wordt is: ‘Inhoud’. Hierin wordt gedefinieerd waarover het Service Level Agreement specifiek gaat, m.a.w. waarover hier een contract wordt opgemaakt. Een voorbeeld hier zou een SLA rond availability zijn, in welk geval er wordt neergeschreven dat het gaat over een SLA voor een bepaalde availability (op voorhand besproken tussen het datacenter en de klant), voor een specifieke applicatie, voor een specifieke applicatie, etc. Zeker belangrijk om ook te vermelden is over welke periode de availability gemeten wordt. Om dit duidelijker te maken wordt hieronder een voorbeeld gegeven. Availability: Hierin wordt bepaald hoeveel procent van de tijd de aangeboden service/dienst beschikbaar is. Ook mag men hier niet vergeten te vermelden over welke periode deze availability berekend wordt. Een availability van 99.5% per maand(3u43min), of een beschikbaarheid van 99.5% op jaarbasis (1 dag 20u 38minuten) maakt een groot verschil uit. Een kleine downtime van een bedrijfskritisch proces kan heel erg zijn, maar het is binnen een aanvaardbare periode opgelost, terwijl een langere downtime rampzalig kan zijn. Een klant zal dus afhankelijk van hoe kritisch een proces is en hoe goed onderbrekingen opgevangen kunnen worden, niet alleen een bepaald niveau van service moeten kiezen maar ook laten vastlegging over welke periode dit valt.

Page | 31

SLA’s and Data Centers 2.3.2

Ken Van Rafelghem

Definities Om misverstanden te vermijden moet elke term die gebruikt wordt in de SLA eenduidig gedefinieerd worden, zodat in geval van discussie er geen dubbelzinnige interpretaties kunnen optreden. Zo zal in het geval van availability, om verder te gaan met het voorbeeld, onder andere gedefinieerd worden wat men exact bedoeld met downtime, met andere woorden aan welke voorwaarden voldaan moet zijn eer er van een downtime gesproken kan worden. Zo kan er bijvoorbeeld vastgelegd zijn dat de downtime pas begint te lopen op het moment dat de klant, de leverancier om de hoogte brengt van het defect. Het kan echter ook zijn dat, indien het een zeer bedrijfskritisch proces is er wordt vanuit gegaan dat de leverancier het zelf monitored en dus onmiddellijk ziet als er iets misloopt. In dat geval zal dit waarschijnlijk in aparte een SLA vastgelegd zijn (monitoring).

2.3.3

Randvoorwaarden (uitzonderingen) Uiteraard kan een datacenter niet altijd alles onder controle hebben. Hiervoor wordt dan een lijst met uitzonderingen(exclusies) opgesteld, waarvoor geld dat als deze aan de oorzaak liggen van een verlaagde beschikbaarheid, er geen penalty’s betaald zullen moeten worden aan de klant. Dit kan onder andere een downtime zijn veroorzaakt door een: •

Virus

•

Commando van de klant zelf

•

Schade aan de hardware door de klant zelf

•

Overmacht

• … Wanneer deze lijst opgesteld wordt moeten natuurlijk geen onlogische oorzaken gedefinieerd worden. Zo zou een datacenter dat bijvoorbeeld op een vulkanisch eiland gevestigd is, een vulkaanuitbarsting niet als randvoorwaarde moeten zetten, de klant zou dit nooit ondertekenen.

Page | 32


Ken Van Rafelghem

Meting Voor elk van de gecontracteerde services/diensten, moet bepaald worden hoe gemeten wordt, ter controle van de minimaal vastgelegde beschikbaarheid. Men moet dus vastleggen in onderling overleg met de klant of de metingen gedaan worden met de meetsystemen van het datacenter, of een derde partij de metingen moet uitvoeren. Ook de gevoeligheid van de systemen zal gedefinieerd moeten worden. Voor de data van de metingen moet ook gedefinieerd worden hoelang deze bewaard moet worden, en hoe ze bewaard wordt Deze metingen liggen aan de basis van de boetes die vereffend worden wanneer een SLA niet nageleefd kan worden.

2.3.5

Prijscorrectie/penalty’s In het geval dat het niveau van service vastgesteld in de SLA niet behaald wordt, worden er boetes uitgedeeld, er zijn verschillende manieren in gebruik voor het ‘uitbetalen’ van boetes, bijvoorbeeld door het bedrag als korting te rekenen bij de betaling van de volgende periode. Deze penalty’s moeten automatisch uitbetaald worden zonder dat de klant hierachter moet vragen. Ook zijn er specifieke zaken die vastgelegd kunnen worden, bijvoorbeeld een stijging van de te betalen boete bij elk terugkerend voorval binnen een bepaalde periode. Ook kan er gekeken worden hoe de overschrijding beboet wordt, is dit een procentueel gehalte, of wordt er per tijdseenheid gekeken. Als een probleem zich voordoet en een watervaleffect creëert, wat wordt er dan beboet? Enkel het probleem, of alle SLA’s die hierdoor hun quota niet gehaald hebben?

Page | 33


Ken Van Rafelghem

2.3.6 Rapportering Ten slotte wordt dan ook nog vastgelegd in welke mate de klant op de hoogte moet gehouden worden van de stand van zaken betreffende, onder andere de beschikbaarheid van zijn gecontracteerde services. Dit kan gaan van een maandelijks rapport tot toegang tot een website waar de klant zelf live de status van de service en diens geschiedenis kan nakijken. Ook het bereik van de rapportering kan hierbij variëren. Algemeen kunnen we 2 soorten rapporteringen onderscheiden.

2.3.6.1

Algemene rapportering De algemene rapportering is de rapportering die de klant na elke door hem eerder vastgelegde periode krijgt. Hierin zal onder andere het behaalde niveau van de service over de gemeten periode vermeldt staan.

2.3.6.2

Specifieke rapportering In de specifieke rapportering zal de klant meer gedetailleerde data gerapporteerd krijgen. In plaats van enkel een rapport te krijgen over het behaalde niveau van service kan de klant ook andere informatie vragen zoals, bijvoorbeeld: •

Performance o Afhankelijk van hoe kritisch de applicatie is kan hier voor een kortere rapporteringperiode gekozen worden, gaande van per kwartaal, tot wekelijks, dagelijks, of zelf opgedeeld per tijdsperiode van een werkdag: Piekuren/daluren, kantooruren, etc.

•

Usage o Hoeveel mensen gebruiken het de applicatie, volstaat de huidige server, netwerkverbinding o Overzicht van gemiddeld verbruik over de loop van de dag.

•

Maintenance o In geval de klant hierom vraagt, kan hel telkens er onderhoud gebeurd, een verslag ontvangen van het verloop van het onderhoud, of er zich al dan niet problemen hebben voorgedaan en zo ja, welke problemen, waar ze zich hebben voorgedaan, en ten slotte, of ze al dan niet opgelost zijn, of nog steeds voorkomen.

Page | 34


3

Ken Van Rafelghem

Onderlinge invloeden van SLA’s op verschillende niveaus

3.1 Opdeling van SLA’s in verschillende niveaus Om een overzichtelijke voorstelling te kunnen geven van de SLA’s die noodzakelijk zijn om als datacenter een goede Service te kunnen bieden aan de klant, kunnen deze als volgt gestructureerd worden: Cloud Computing

SaaS

Applications

• Databases • Web applications • ERP/CRM/…

Networking

• Network • Security

Hardware / Servers / Storage

Facilities

• Co-location • Dedicated • Storage • Virtualisation • Physical location • Cooling • Backup power

Figuur 2 datacenter activiteiten in verschillende niveaus volgens stijgende uitbesteding

Deze niveaus zijn gedefinieerd, volgens stijgende nood aan uitbesteding van de klant. Om even een idee te geven van de eisen van de klanten op elk niveau, zijn er onderstaande voorbeelden: •

Facilities niveau: o De klant wil wel nog zijn eigen IT infrastructuur gebruiken en beheren, maar heeft er op zijn bedrijf de ruimte niet voor. De klant wenst ook beschikbaarheid van stroom, koeling en een veilige fysieke omgeving voor zijn IT-apparatuur.

•

Hardware/servers/storage niveau: o De klant heeft ruimte tekort en zou bovendien graag besparen op personeel om het serverpark van het bedrijf te onderhouden. o De verwerkingscapaciteit is te laag in het bedrijf zelf en ze zouden graag uitbesteden en consolideren via virtualisatie

Page | 35


Ken Van Rafelghem

•

Networking niveau: o De klant vereist een zekere bandbreedte(website) en security (confidentiële informatie) voor de applicaties die hij in het datacenter heeft draaien.

•

Applicatie niveau: o De klant brengt een CD/DVD met een applicatie binnen en verwacht dat deze op korte termijn beschikbaar is

•

SaaS niveau: o Bovenop software die de klant zelf gebruikt wil hij ook gebruik maken van een bepaalde applicatie, maar hiervoor enkel betalen de dagen/weken/maanden dat hij deze gebruikt.

•

Cloud Computing niveau: o De klant wil zijn applicaties laten draaien, en schalen naargelang het gevraagde verbruik, maar wil ook effectief alleen de gebruikte eenheden (netwerk, storage en processing power) hiervan betalen.

We stellen vast dat, hoe hoger de service die we contracteren zich bevindt, hoe meer we afhangen van alle onderliggende lagen. Een applicatie bijvoorbeeld zal niet goed draaien als de onderliggende hardwaren niet goed draait. SaaS en Cloud computing zullen niet goed werken als er een slechte QoS of te weinig bandbreedte is.

Page | 36


Ken Van Rafelghem

3.1.1 Definities In onderstaande tabel kunnen de definities van de gebruikte terminologie die in het piramidemode gebruikt wordt, gevonden worden. Tabel 1 Definities van gebruikte terminologie in het piramide model

Facility

Gecontroleerde locatie waar bedrijfskritische systemen beheerd worden, en waar gestreefd wordt een zo hoog mogelijke systeem en software availability te leveren.

Hardware hosting •

Colocated

De klant huurt (rack)space in het datacenter, om zijn eigen servers/racks te plaatsen

•

Dedicated

De klant huurt/leased servers van het datacenter waarop hij zijn eigen applicaties laat draaien.

•

Virtualisation

Het virtueel draaien van meerdere servers op een zwaardere server door middel van een hypervisor

Applications

Software die draait op de servers die in het datacenter geplaatst zijn.

SaaS

Software draaiend op de servers in het datacenter, waarbij (per eenheid) voor het gebruik van de software wordt betaald.

Cloud computing

Bij cloud computing draait alles ‘in the cloud’. De klant weet niet waar het staat. Het is van overal, altijd toegankelijk over het internet, op voorwaarde dat de klant een access device heeft.

Page | 37


3.2

Ken Van Rafelghem

Key Performance Indicators(KPI’s) In het volgende stuk gaan we laag per laag kijken naar de key performance indicators die zich op de verschillende lagen bevinden, en vaststellen waarom dit net de key performance indicators zijn, en hierop SLA’s worden afgesloten.

3.2.1 Facility KPI’s Op facility niveau worden vooral over volgende zaken afspraken gemaakt: •

Fysische beveiliging

•

Stroomvoorziening(naar de hardware toe)

•

Back-up stroom

•

Koeling

Wat fysische beveiliging betreft zullen afspraken gemaakt moeten worden met betrekking tot de aanwezigheid van brandafweersystemen die aanwezig zijn in het datacenter, welke beveiliging er is tegen inbraak, is dit een bewaker, een alarm, beveiliging van de deuren met een elektronische pas of een camerabewakingssysteem. Uiteindelijk gaat het toch om gevoelige data die in het datacenter bewaard wordt, en kan men het zich niet permitteren deze in een praktisch onbewaakt datacenter achter te laten. Veel datacenters bevinden zich net om die reden in een normaal uitziend gebouw. Ook voor stroomvoorziening naar de servers toe moeten afspraken gemaakt worden aangezien sommige servers meer stroom trekken dan andere, en, wanneer we dit doortrekken naar racks, sommige racks dus veel meer stroom gebruiken dan andere. Er zal dus vastgelegd moeten worden welk stroomverbruik de klant nodig heeft, alsook definiëren of hij een ontdubbelde voeding wenst in zijn datacenter. Naar back-up stroom toe zal er moeten gekeken zijn wat hiervoor aanwezig is, of dit ontdubbelt is. Ook zal er gezorgd moeten worden dat, indien er met 2 verschillende circuits gewerkt wordt, het ene circuit het andere niet overlaad wanneer er één van de twee faalt. Ten slotte moet op facility niveau ook rekening gehouden worden met de koeling, aangezien deze een rechtstreekse invloed heeft op het aantal servers of componenten die falen.

Page | 38


Ken Van Rafelghem

3.2.2 Hardware KPI Op hardware niveau moet vooral rekening gehouden worden met volgende zaken: •

Componenten

•

Opslag

•

Responstijd

•

Resolutietijd

•

Availability

•

Performantie

•

Back-ups

•

Opslag van de back-ups

•

Onderhoud

Allereerst moet rekening gehouden worden met de componenten. Alle componenten hebben een bepaalde failure rate. Met het oog op het behalen van een bepaald service level, moet er dus gezorgd worden dat er reserveonderdelen aanwezig zijn, aangezien, men geen tijd heeft om een onderdeel te bestellen wanneer het kapot gaat. Er zal dus moeten gekeken en vastgelegd worden wie zorgt voor de aanwezigheid hiervan: de klant of het datacenter. Indien hiervan wordt afgezien, zal een datacenter zijn SLA’s betreffende availability in ieder geval moeten verlagen. Ook naar opslag toe moeten afspraken gemaakt worden: op welk type medium moet dit gebeuren, snelle of trage schijven, in al dan niet in raid, welke soort raid. Dit is toch wel belangrijk aangezien de klant toch wel de opslag bij het datacenter huurt en ervoor betaald, wanneer men, om een voorbeeld te geven, voor raid 1 zou kiezen, dan heeft men nood aan 2 schijven in plaats van 1 schijf. Daarnaast is er natuurlijk ook de mogelijkheid de data op te slaan op een NAS of SAN. De keuze zal afhangen van de voorkeur van de klant en de adviezen van het datacenter, al naar gelang het soort data waarover het gaat. Naar responstijd toe zullen afspraken gemaakt moeten worden betreffende wanneer deze ingaat: hetzij wanneer de klant het datacenter op de hoogte brengt, of het datacenter dit zelf tijdens het monitoren opmerkt, hetzij op het moment dat een probleem zich voordoet. De responstijd is de tijd die aan het datacenter gegeven wordt om technici ter plaatse te krijgen en aan de herstelling te beginnen. Eenmaal de technici ter plaatse zijn begint de resolutie- of interventietijd. Ook hier moeten afspraken gemaakt worden naar de maximaal toegestane duur van de interventie. Natuurlijk zal de klant rekening moeten houden dat als zijn eisen te Page | 39


Ken Van Rafelghem

nauw zijn, het datacenter deze misschien niet kan leveren en de klant naar een ander datacenter zal moeten stappen. De vorige 2 onderdelen hebben een directe impact op de availability, en worden hier dan ook meestal ingecalculeerd. Als zowel de responstijd als de resolutietijd zeer laag zijn, en dit wordt nageleefd, dan zal de totale availability van de servers zeer hoog zijn. Hier geldt echter, net als bij alle andere SLA’s, hoe hoger, hoe duurder Ook naar performantie toe zullen SLA’s afgesloten moeten worden. Zeker nu we in een periode van virtualisatie komen, waarbij men meerdere servers gaat consolideren op 1 enkele zware server, zou de performantie van de hardware die u gebruikt wel eens in gedrang kunnen komen omdat u deze met verschillende andere gebruikers ‘deelt’. Ofwel moet er dus een SLA afgesloten worden naar performantie, waarbij een bepaald minimum gegarandeerd wordt, ofwel zal de klant een server voor zichzelf moeten behouden die performant genoeg is voor de doelstellingen waarvoor hij bestemd is. Een zeer belangrijk punt waarover zeker afspraken gemaakt zullen moeten worden is het nemen van back-ups. Zeker wanneer de servers van de klant betreft die door middel van collocatie in het datacenter geplaatst zijn. Deze afspraken houden in dat er vastgelegd wordt hoe vaak, door wie, en op welke manier er back-ups genomen worden. Ook moet er een herstelplan opgesteld worden voor het geval er zich iets voordoet, zodat het systeem onmiddellijk terug up-and-running is. Samengaand met het vorig punt, is de opslag van de back-ups. Hoe moet deze gedaan worden, gebeurd dit op CD/DVD/Blue ray? Of op een externe harde schijf. Worden deze back-ups aan de klant gegeven of bewaard het datacenter deze op een veilige plaats. Een verlies van back-up data kan zeer schadelijk zijn en het is dus zeer belangrijk om deze op de correcte manier te behandelen. Als laatste punt van de hardware laag, staat onderhoud. Hier wordt vastgelegd wie instaat voor het onderhoud van de server, In de meeste gevallen zal dit het datacenter zijn, maar soms kan het zijn dat (bv. Wanneer de server in collocatie in het datacenter staat) de klant hiervoor verantwoordelijk is.

Page | 40


Ken Van Rafelghem

3.2.3 Networking KPI’s Wat betreft het netwerk moet rekening gehouden worden met volgende zaken: •

Bandbreedte

•

Dubbele internet provider (ev. Ook aan kan van de klant)

•

Security

•

QoS

•

Connectiviteit

Afhankelijk van de gewenste of benodigde bandbreedte zal een SLA afgesloten moeten worden. Wanneer de bandbreedte niet groot genoeg is zal er een bottleneck ontstaan, wat leidt tot een ‘trage’ verbinding. Daarnaast valt het ook te vermelden dat er rekening moet gehouden worden met een ontdubbelde internetprovider, zowel aan datacenter als aan de kant van de klant. Zodat wanneer de ene provider zich in moeilijkheden bevind, de andere het gewoon kan overnemen. Vervolgens is ook de security van het netwerk belangrijk. Het datacenter mag dan nog zo beveiligd zijn, als een hacker, door gewoon mee te luisteren de pakketjes kan onderscheppen dan heeft alle fysische beveiliging van servers en toegang tot data geen zin. Hier moet dus vastgelegd worden hoe de data beveiligd wordt. De QoS of Quality of Service van het netwerk en de netwerkverbinding tussen klant en leverancier is ook van belang. Hier wordt dan afgesproken wat onder andere een toelaatbare packet loss is, welke delay er gangbaar is en welke afwijkingen hier tegenover acceptabel zijn. In het geval van streaming audio of video data zal ook rekening gehouden moeten worden met jitter. Hoe laag deze verschillende onderdelen gehouden kunnen worden, bepaald hoe hoog de SLA op Quality of Service zal kunnen zijn. Ten slotte is er natuurlijk ook nog de connectiviteit. Ofwel is er verbinding, en dan komen alle andere vermelde factoren in rekening, ofwel is er geen verbinding en dan wordt de SLA rond connectiviteit beïnvloed.

Page | 41


Ken Van Rafelghem

3.2.4 Application KPI’s Op applicatie niveau moet met volgende zaken rekening gehouden worden: •

Patch/update management

•

Performance

•

Availability

Wat performance en availability betreft kan het redelijk kort gehouden worden. Deze zijn namelijk allebei afhankelijk van de hardware en netwerk laag, en zullen dus onder normale omstandigheden niet in gedrang komen zolang er goede SLA’s afgesloten zijn op voorgenoemde niveaus, en deze nageleefd worden. Natuurlijk kan de performantie en availability van een programma ook afhangen van de geschreven code, maar daar zal het datacenter niet veel aan kunnen doen. Voor patch/update management kan ook een SLA afgesloten worden. Hier wordt dan in vermeldt wie de patches en/of updates uitvoert, en binnen welke periode deze uitgevoerd moeten worden.

3.2.5 SaaS en Cloud computing KPI’s Op niveau van SaaS en Cloud computing moet naar volgende zaken gekeken worden: •

Performance

•

Availability

Zowel Performance als availability zijn voor beide niveaus zeer belangrijk: De software draait dan wel in het datacenter, maar ze moet gebruikt kunnen worden alsof de computer vlak naast de gebruiker staat. Ook de availability is uiteraard van groot belang, aangezien dit eigenlijk applicaties zijn, alleen wat hoger op de uitbestedings piramide.

Page | 42


3.3

Ken Van Rafelghem

Onderlinge invloeden

Wanneer een klant binnenkomt in een datacenter met een DVD waarop software staat die hij binnen een zo kort mogelijke termijn in gebruik wil nemen, zal hij bij het afsluiten van zijn SLA’s zeer goed op verschillende onderdelen moeten letten. Vroeger was het de gewoonte om SLA’s apart aan te bieden, dat had echter nadelen, aangezien er daardoor geen rekening gehouden werd met de onderliggende lagen. We ondervinden echter dat de services die zich hogerop in de piramide bevinden afhankelijk zijn van alle deze op onderliggende lagen. Hieronder worden per 2 lagen de onderlinge invloeden weergegeven.

3.3.1

Facility & Hardware laag

Figuur 3 Onderlinge invloeden tussen facilities en hardware 1

De aanwezigheid van stroom en koeling hebben een directe invloed op de componenten, de opslag en de performantie van de hardware. Componenten die niet genoeg stroom krijgen, bijvoorbeeld omdat de voeding van de server niet sterk genoeg is, zullen soms nog wel werken. Ze zullen dit echter meestal niet, of slecht doen. Een computer in rust trekt niet dezelfde hoeveelheid stroom als een computer die op volle toeren aan het draaien is, en het laatste dat we willen is dat de server op piekmomenten uitvalt. Ook de koeling is zeer belangrijk. In een freecooling test uitgevoerd door Intel, werd aangetoond dat alleen al het overschakelen van een gewone CRAC (computer room air conditioning) naar het free cooling systeem (warme lucht wordt vervangen door buitenlucht), de failure rate van de servers steeg van 3.8% naar 4.5%. Indien er geen koeling of slechte koeling zou zijn, zou dit cijfer nog veel hoger liggen.

Page | 43


Ken Van Rafelghem


Back-up stroom is van cruciaal belang in een datacenter. Indien de UPS-batterijen falen op het moment dat er zich een stroompanne voordoet, of de gensets (dieselgeneratoren in een datacenter) raken niet opgestart voor de UPS leegloopt, dan heeft dit een onmiddellijke invloed op de responstijd, de resolutietijd en zoals we hieronder gaan zien, de availability. Wanneer zich een stroompanne voorzien en de back-up stroom vangt dit op, creëert dit een zekere timewindow waarin het probleem opgelost kan worden. Anders zit men onmiddellijk met server downtime, en dan moeten de technici van het datacenter, een probleem proberen op te lossen dat niet in hun handen ligt, binnen de gestelde resolutietijd.


Zoals hierboven al even kort werd aangehaald, heeft de aanwezigheid en correcte werking van back-up stroom een directe invloed op de availability van de hardware. Dit geldt niet enkel voor de back-up stroom maar ook voor gewone stroom (anders heb je de back-up stroom niet nodig), brandbeveiliging en koeling. Al deze zaken kunnen, in het geval er iets mee misloopt een negatieve impact hebben op de availability van de hardware.

Page | 44


Ken Van Rafelghem

Hardware & netwerk laag

Figuur 6 Onderlinge invloeden tussen hardware en networking

Tussen de hardware en de networking laag vinden we 4 verschillende onderdelen die elkaar beïnvloeden: Aan de ene kant hebben we de performance en de componenten van de hardwarelaag, en dan spreken we over de netwerkkaart, de kabels, de hubs en de routers. En aan de andere kant de QoS(Quality of Service) en de connectiviteit. Net als bij de stroom is het hier logisch dat als de component bijvoorbeeld kapot is, de connectiviteit en dus de QoS ook er simpelweg niet meer zullen zijn. De performantie heeft echter ook een invloed op de netwerklaag. Een slechte router zal bijvoorbeeld de QoS serieus naar beneden halen, zij het door packet loss, jitter, …

3.3.3

Netwerk en applicatie / SaaS / Cloud computing lag

Figuur 7 Onderlinge invloeden tussen networking en Applicaties, SaaS en Cloud computing 1

Wanneer we applicaties gaan draaien in een datacenter, zal de gebruiker van die applicaties, het zij de klant het zij een derde persoon, deze applicaties moeten gebruiken over het netwerk of het internet. Wanneer er dan te weinig bandbreedte voorzien is, waardoor er een bottleneck gecreëerd wordt, of er een slechte QoS is, zal de performantie van de applicatie in kwestie dramatisch dalen. Het is dus zeer belangrijk dat deze nauwkeurig gemonitord worden.

Page | 45


Ken Van Rafelghem

Figuur 8 Onderlinge invloeden tussen networking en Applicaties, SaaS en Cloud computing 2

Zoals hierboven vermeld, verloopt alle communicatie met de applicaties over een netwerk / het internet. Indien er dus geen verbinding is, beïnvloed t dit de availability van de applicaties in kwestie. Een redundante ISP kan hierbij zeker helpen, aangezien een onderbreking van service door 1 ISP, opgevangen kan worden door de andere en de availability blijft bestaan.

3.4 Besluit onderlinge invloeden Wanneer een klant een service wil contracteren op een bepaald niveau, dan zal hij zeker moeten informeren bij het datacenter naar de stand van zaken van de onderdelen, waarvan we hier net aangetoond hebben dat ze grote invloeden hebben op hogere lagen. Indien bij deze onderdelen geen maatregelen genomen zijn om deze te minimaliseren of tegen te gaan, dan zal de klant er best nog eens over nadenken vooraleer hij een SLA afsluit bij dat datacenter. Uiteindelijk kan een datacenter dat geen maatregelen neemt tegen dergelijke voorvallen, geen SLA’s garanderen van 99.8%.

Page | 46


Ken Van Rafelghem

Besluit Eerst hebben we uit CobIT een aantal processen geselecteerd te hebben waarvan we dachten dat deze van toepassing zouden zijn op zowel datacenters als Service Level Agreements. Vervolgens hebben we deze processen dan ook stuk voor stuk vergeleken met zowel een datacenter als met Service Level Agreements, en hun invloeden hierop bekeken. Hieruit bleek dat deze processen zich stuk voor stuk rond zowel datacenters, als Service Level Agreements lieten plaatsen. We kunnen dus concluderen dat CobIT inderdaad een kader biedt om Service Level Agreements in datacenters te behandelen. Bij het opdelen van de datacenter services in verschillende niveaus en het bekijken van de invloeden tussen de niveaus onderling, kunnen we alleen maar besluiten dat wanneer een klant een service wil contracteren op een bepaald niveau, hij zeker zal moeten informeren naar de stand van zaken van de onderdelen op iedere laag van het piramidemodel. Indien het datacenter voor die onderdelen geen maatregelen genomen heeft om deze te minimaliseren of tegen te gaan, zal de klant er best nog eens over nadenken vooraleer hij een SLA afsluit bij dat datacenter. Kijken we uiteindelijk naar het totaalplaatje, dan kan er geconcludeerd worden dat terwijl men in de praktijk graag SLA’s van 99,8% gebruikt dit eigenlijk veel te hoog gegrepen is. De kans dat meerdere problemen zich simultaan voordoen is reëel. Bijgevolg is een service level voorschotelen aan een klant dat enkel het niveau beslaat waarop zijn services zich bevinden zonder rekening te houden met de onderliggende niveaus, niet erg realistisch We kunnen concluderen dat service levels niet apart, maar als totaalpakket moeten aangeboden worden. Bij een totaalpakket moet er echter wel rekening gehouden worden met alle niveaus tot en met het niveau waarop de klant zijn services wil hebben. Om het service level van het totaalpakket te berekenen, moeten alle service levels van alle niveaus met elkaar vermenigvuldigd worden. Het bekomen service level zal lager uitvallen maar wel een stuk realistischer zijn. Als advies aan de klant kunnen we alleen meegeven dat hij voor hij zijn bedrijfskritische software uit handen geeft aan een datacenter, hij best eens nagaat hoe goed het datacenter in kwestie voldoet aan de geselecteerde processen uit CobIT, en of er genoeg aandacht besteed wordt om de kans op falen van de meest cruciale onderdelen uit de piramide te minimaliseren

Page | 47


Ken Van Rafelghem

Literatuurlijst Wustenhoff, E. (2002) Service Level Agreement in the Data Center, [Online], Available: http://whitepapers.zdnet.com/abstract.aspx?docid=93964 [14 Oct 2009]. Cohen, K. (2006) Top ten considerations for data center SLAs, [Online], Available: http://searchdatacenter.techtearget.com/tip/0,289483,sid80_gci1196419,00.html [20 Oct 2009]. du Busquiel, P. (2008) Welke SLA’s voor SaaS-contracten?, [Online], Available: http://www.datanews.be/nl/business-ict/63-92-1749/welke-sla-s-voor-saas-contracten-.html [21 Oct 2009]. Atwood, D. & Miner, J.G. (2008) Reducing Data Center Cost with an Air Economizer, [Online], Available: http://www.intel.com/it/pdf/Reducing_Data_Center_Cost_with_an_Air_Economizer.pdf [18 May 2009]. Wainewright, P. (2008) SaaS and the renewal Question, [Online], Available: http://blogs.zdnet.com/SAAS/?p=617&tag=nl.e539 [15 Dec 2009]. vreg. (2007) RAPP-2007-5: De kwaliteit van de dienstverlening an de elektriciteitsdistributienetbeheerders in het Vlaamse Gewest in 2006, [Online], Available: http://www.vreg.be/vreg/documenten/rapporten/RAPP-2007-5.pdf [4 May 2009]. Heller, M. (2004) Six Smart Strategies for handling the Help Desk, [Online], Available: http://www.cio.com/article/32177/Six_Smart_Strategies_for_Handling_the_Help_Desk [4 May 2009]. Schroeder, B. & Gibson, G.A. Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?, [Online], Available: http://www.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html [4 May 2009]. WindowsITPro. (2007) The Shocking Truth about Hard Disk Drive Failure Rates, [Online], Available: http://windowsitpro.com/article/articleid/95965/the-shocking-truth-about-har-diskdrive-failure-rates.html [4 May 2009]. APC. (2003) Battery Technology for Data Centers and Network Rooms: VRLA Reliability and Safety, [Online], Available: http://whitepapers.technrepublic.com.com/abstract.aspx?docid=137959 [4 May 2009]. Garbani, J.-P. (2004) Best Practices For Service-Level Management, [Online], Available: http://whitepapers.techrepublic.com.com/abstract.aspx?docid=131573 [18 Oct 2008]. Page | vi


Ken Van Rafelghem

TechRepublic. (2004) Sample SLA: Outsourced help desk, [Online], Available: http://downloads.techrepublic.com.com/abstract.aspx?docid=173809 [17 Oct 2008]. TechRepublic. (2001) Sample SLA for application support, [Online], Available: http://downloads.techrepublic.com.com/abstract.aspx?docid= 173833&promo=100511 [17 Oct 2008]. Zhen, J. (2006) SLA 101: What to Look for in a Service-Level Agreement, [Online], Available: http://whitepapers.techrepublic.com.com/abstract.aspx?docid=253257&promo=100511 [5 Nov 2008]. Leopoldi, R. (2002) IT Services Management: A Description of Service Level Agreements, [Online], Available: http:// www.itsm.info/SLA%20description.pdf [5 Nov 2008]. Harris Kern Enterprise Computing Institute. (2005) Criteria for a service level agreement, [Online], Available: http://downloads.techrepublic.com.com/abstract.aspx?docid=172939 [11 Nov 2008]. TechRepublic. (2006) Service level agreement for internal business units, [Online], Available: http://downloads.techrepublic.com.com/abstract.aspx?docid=173727 [24 Oct 2008]. Frame Relay Forum. (1998) Service Level Definitions Implementation Agreement, [Online], Available: http://whitepapers.zdnet.com/abstract.aspx?docid=3480 [30 Oct 2008]. Goretzki, W. (2007) ‘Datacenter Management Technology’, Avocent Corporation [Powerpoint], Unavailable [28 Oct 2008] BELTUG. (2006) SLA recommendations from the users’ viewpoint, [Online], Available: http://www.beltug.be/news/552/BELTUG-paper_SLA_recommendations/ [14 Oct 2008] ETSI. (2002) ‘User Group; Quality of telecom services; Part 3: Template for Service Level Agreements (SLA)’, [Online], Available: http://electronics.ihs.com/document/abstract/SSIIVAAAAAAAAAAA [14 Oct 2008] Fellows, W. (2008) Partly Cloudy: Blue-Sky Thinking About Cloud Computing, Available: http://www.the451group.com/ice/ice_detail.php?icid=619 [10 Oct 2008] Longbottom, C. & Szubert D. (2008) Data centre asset planning, Available: http://www.quocirca.com/pages/analysis/reports/view/store250/item20971/ [16 Oct 2008] GDCM. (n.d.) Using ITIL to Coordinate Services to the Business, Available: http://www.gdcm.com/presentation-downloads.html [28 Oct 2008]

Page | vii

Masterproef SLA s en Datacenters

Recommend Documents