De evolutie naar de cloud brengt een nieuw vakgebied in het datacenter: analytics. We zullen moeten gaan grasduinen in grote hoeveelheden data willen we onze cloud-diensten kunnen besturen ten aanzien van elastici-teit, consumptie en beveiliging.
Geen eenvoudige stap, want het is niet de ‘sexy’-analytics die we kennen in de reguliere big data-wereld. Want je gaat grasduinen in minder tot de verbeelding sprekende data met it-termen als cpu utilization en cpu wait, memory swap en active versus consumed memory, disk latency en disk read, netwerkverkeer, packet drops en transmit rate.
Analytics omvat het kijken naar data, het ontdekken van ‘meaningful patterns’ in gegevens, om op basis hiervan besluiten te kunnen nemen. Analytics is een multi-dimensionele discipline. Het start met het verzamelen van data, het meten, het detecteren en analyseren. Deze data groepeer je, visualiseer je, en gebruik je om te reageren op wat je ziet. Je gebruikt wiskunde om gegevens met elkaar te correleren, patronen te ontdekken, en gedrag te modelleren in beslismodellen. Met deze beslismodellen kun je uitvoering van eenvoudige acties laten plaatsvinden op het portaal van de cloud vendor of op het technische platform van je eigen private cloud.
In een hoog-geautomatiseerde cloud-omgeving kun je het capacity management automatiseren. Met behulp van analytics kun je je omgeving automatisch laten tunen. Denk aan een server die automatisch meer resources krijgt toegewezen, elke maandagochtend als specifieke gebruikersload hoog is.
Naast deze beslismodellen, met name gericht op dynamisch gedrag van de hardware, software en dienstencomponenten, is basaal verbruiksmanagement van de ingekochte cloud componenten een onderdeel van datacenter-analytics. Een soort shopping-analyse.
Want in een cloud-based datacenter bestel je op basis van een catalogus. Het is een consumptie model. De catalogus geeft de eenheden van bestelling, en de te bestellen smaken: databases, servers, netwerken, storage en meer. Zaak om deze consumptie in grip te houden, items die niet gebruikt worden ‘af’ te bestellen. Te vergelijken met het traditionele capaciteitsmanagement, maar veel complexer, vooral vanwege de ingewikkelde prijsmodellen die er achter zitten. Het capaciteitsmanagement zullen we dus moeten verrijken met een modelleerstap, daarnaast sneller besluiten omdat het traditionele bestelproces geen automatische rem meer is.
Naast capaciteitsmanagement als aandachtsgebied voor een datacenter analytics-team, zal ook aandacht nodig zijn voor performance management. De eindgebruiker zal namelijk ook in cloud omgevingen twijfels hebben over de kwaliteit van de geleverde dienst. Na deze primaire aandachtsgebieden zullen we al snel gedrag op de verschillende plekken in het datacenter gaan correleren en optimaliseren, daarnaast onverwacht gedrag (anomalieën) proberen te verklaren en uit te sluiten.
Wordt datacenter analytics daarmee hot?
Waarschijnlijk niet – de traditionele it-wereld leeft op bij incidenten, bij het blussen van brandjes. De it-beheerder voelt de adrenaline die de brandweerman ook voelt bij het rennen om een code rood op te lossen door slim te crunchen om de oorzaak van een datacenter-down te vinden en fixen. Adrenaline die hij niet voelt bij het proactief voorkomen van incidenten door middel van analytics.
Analytics vormgeven in een cloud-omgeving is dus lastig. Het is niet sexy, en we moeten nog veel leren. Van oudsher zijn we bezig met technologie op hardware en software gebied, daarnaast met beheerprocessen. Nu is het tijd onszelf bekend te maken met analytics tooling en te bepalen welk analytics platform we neerzetten, welke api’s we aanspreken om data naar onze analytics omgeving te brengen. En hebben we analisten nodig die business-rules opstellen, algoritmes gebruiken om te voorspellen en te correleren, die de juiste dashboards creëren om vanuit die overload aan data die we binnenhalen de juiste stuurbesluiten te kunnen distilleren.
Eerst dat maar op orde krijgen, pas daarna nadenken over hot maken.
Marianne Faro en Jeroen Jacobs van Itility
De auteurs
Marianne Faro is principal consultant bij Itility. Zij geeft leiding aan het competence center Analytics binnen Itility.
Jeroen Jacobs is projectleider en consultant bij Itility en expert bij Computable voor het topic cloud computing.
Jeroen (en Marianne),
Waar gaat dit over?
Een Service Knowledge Management Systeem correleert gegevens vanuit verschillende bronnen, veelal redelijk gestructureerd omdat normalisatie al gedaan is. Niet onbelangrijk in het kader van de compliance is het koppelen van de levensduur van de service aan de levensduur van de onderliggende technologie, het spook van legacy zit niet in de schaalbaarheid maar de vervangbaarheid.
Ik krijg het er zowaar koud van… datacenter down , tuurlijk!
Compliancy is inderdaad nog een goede toevoeging en erg belangrijk bij zowel bij service knowledge management / Big Data analyses.
Jeroen,
Voor wie heb je dit artikel geschreven?
1- Je klanten? Wat maakt het hen uit hoe je deze zaken ingericht hebt? Ze willen diensten volgens hun SLA.
2- Voor collega`s die een dc inrichten? Leuk! Maar ga er rustig vanuit dat zij ook in hun architectuur hier rekening mee hebben gehouden.
Dus…..leuk artikel maar ik heb er als klant niks aan 🙂
@Reza:
Feit blijft wel dat er dit soort zaken ingericht worden en er zijn ook wel degelijk organisaties die een deel in eigen regie hebben waar dit stuk er eentje van kan zijn.
Daarnaast SLA’s ja… maar ontkennen zul je vast niet dat er nog steeds veel organisaties zijn die ook toch graag wel eens een blik in de keuken werpen 😉
@Jeroen
Het lijkt me handig om eerst je doelgroep te bepalen en dan pas je artikel er op richten. Je gooit naar mijn mening een aantal dingen door elkaar.
1- In je artikel heb je het over Cloud-based datacenter en ook cloud leveranciers. In dit geval kan mij als klant geen salami schelen hoe je je datacenter ingericht hebt. Ik neem je dienst (X-aaS) maar af volgens afspraak (lees SLA);
2- Als een organisatie een deel van dit soort zaken in eigen regie houdt/heeft dan vraag ik me af waarom ze de rest ook niet doen! Dit stuk is best essentieel en vereist bepaalde kennis en ervaring. Als een organisatie zich met dit stuk bemoeit dan zouden ze voldoende kennis in huis moeten hebben om dit te begrijpen en zich er mee te bemoeien.Wat hebben ze dan aan een cloud-leverancier?
Ik vind nogmaals je artikel interessant voor datacenter-leveranciers en niet voor de afnemers en klanten.
Tsja… Service Level Agreements blijken met name in de cloud vaak ‘leveranciersvriendelijk’ te zijn door exoneratieclausules, de erosie van de inspanningsverplichting naar de afnemer doordat aansprakelijkheid afgeweerd wordt. Betreffende Service Level Objectives wijs ik graag op normalisatie vooraf, bij het opstellen hiervan dient dus rekening gehouden te worden met de volgende aspecten:
Bereikbaar
Herhaalbaar
Meetbaar
Begrijpelijk
Aanvaardbaar
Betreffende het meten van de gezondheid wijs ik op reeds lang bestaande normalisatie middels Common Information Model (DMTF). Een incident is dus de onderbreking van een (afgesproken) service, een event een gestructureerde notificatie waarbij op basis van de ‘severity’ een actie gedaan wordt. Het genie beheerst de chaos maar misschien mag ik wijzen op initiatief CADF, een datamodel dat tot doel heeft om genormaliseerde events te produceren:
https://wiki.openstack.org/w/images/e/e1/Introduction_to_Cloud_Auditing_using_CADF_Event_Model_and_Taxonomy_2013-10-22.pdf
Voor mensen die baat hebben bij reactief beheer – en dus in wegwerp architecturen denken – misschien niet interessant maar als we term Cloud-Based vervangen door Software-Defined dan zullen we dus moeten werken aan een interoperabele oplossing om zodoende te voorkomen dat we steeds dezelfde fouten maken. Organisaties worden namelijk gedwongen om een kijkje in de keuken te nemen omdat je dus de compliance niet uit kunt besteden, het is geen snackbar waar je op de sticker van smaakpolitie kunt vertrouwen.