Whitepaper
Het Druk-op-de-knop Datacenter
Het Druk-op-de-knop Datacenter Wat je al een jaar of dertig kent voor eenduidige platforms begint nu eindelijk in beeld te komen voor de huidige multiplatformwereld: één grote pool aan netwerkbandbreedte, CPU-capaciteit en opslag welke naar wens te segmenteren is naar alle applicaties en omgevingen die het nodig hebben. En dat gaat veel verder dan alleen maar ‘virtueel gaan’: een hypervisor installeren is een eerste stap maar helpt je weinig verder als je vast zit aan legacy netwerken en opslag . Je doel is om alle hardware ondergeschikt te maken aan softwarematig configuratiebeheer. Als je zo’n private cloud-tot-in-de-botten wilt, dan heb je een aantal moderne bouwstenen nodig die in dit paper uitgewerkt woren. De ITIL-loop Juist met drukken-op-de-knop moet je erg uitkijken welke knoppen welke gevolgen hebben, en vandaar dat je eerst een korte ITIL-herhalingsoefening krijgt. Juist vanuit ITIL, hét raamwerk voor datacenterbeheer, is het mogelijk om te bepalen welke functies aan welke groepen gebruikers moeten worden toegekend en hoe alles kan samenwerken. Bijgaand het waarschijnlijk bekende ITIL-schema: De hoofdgebieden van ITIL hebben echt te maken met gescheiden te houden groepen personeel, en datacenters hebben op dit vlak best wel wat weg van de werelden binnen een ouderwets degelijke fabriek van tastbare produkten. Service Design is voor de ‘witteboordenbeheerders’ van de informatiedienstenfabriek: partijen die in een soort bedrijfsbureau de SLA’s opstellen en de inventory koppelen aan kostenplaatjes en doorbelastingen. Service Operation is dan het echte ‘blauweboordenwerk’, met de Windows/Linux/SQL/http- beheerders die als een kunstenaar precies weten hoe storingen opgelost moeten worden en installaties foutloos gescript worden doch niet persé sterk zijn in rekenwerk en doorbelasting. Daartussenin vind je de Service Transition: het grensgebied tussen deze twee werelden, met o.a. de CMDB (Configuration Management Data Base) en alle afspraken rond change management en tests voordat een nieuwe deployment toegestaan wordt. De lus in het schema, Design-Transition-Operation, is er niet voor niets. Nadat je een dienst zoals ‘applicatie X’ of ‘testmachine Y’ live hebt gebracht is het de kunst om te bepalen of alles naar wens (dus binnen de Service Level Agreement) functioneert en zonodig bij te sturen. Eerst maar het verhaal voor een produktie-applicatie, daarna zie je wat nuanceverschillen voor testsystemen. Vallend onder de Operation-fase hanteer je meetinstrumenten voor dit SLA-bewaken: tools die kijken hoe de CPU- en diskbelasting is bijvoorbeeld, of robot-browsers danwel netwerkafluisteraars die analyseren wat de responstijd van een scherm is. De kunst is om zodra er een SLA-grenswaarde overschreden wordt automatische akties te hebben klaarstaan: bijvoorbeeld een extra VM bijplaatsen, of liever nog op fijnmazig niveau die hulpbron (bandbreedte, CPU, opslag) die de flessehals vormt opschalen. Of andersom, bij
onderbelasting kunnen er hulpbronnen vrijgegeven worden. Het schalen op hulpbron- inplaats op VM-niveau kan natuurlijk alleen als je een goede relatie bepaald hebt tussen de diverse componenten van de applicatie; dat heet bijvoorbeeld ‘responsetime triage’ om precies te zien welke schakel in de keten hoeveel milliseconden eist, en die metingen relateer je dan weer naar de diverse belastingsmetrieken. Deze korrigerende aktie wordt vervolgens klaargezet in Service Transition. Mogelijk voor volautomatische uitvoering, bijvoorbeeld bij een 24 x 7 drukbezette website; en mogelijk als workflow waar een witte- en/of blauweboordenbeheerder nog een druk op de knop moet plegen en keuzen kan maken. En de Service Design fase zit in deze interactie ‘meer aan de zijlijn’; natuurlijk moet uiteindelijk ook de SLA worden bijgesteld en doorbelasting aangepast maar dit zijn aktiviteiten voor de iets langere termijn. Let wel: de korrigerende aktie die uiteindelijk wordt doorgezet stopt niet bij het heralloceren van resources. Bij elk stuk nieuwe opslag, elke nieuwe VM, moeten ook scripts gedraaid worden die de applicatie optimaal gebruik laten maken ervan; dus bijvoorbeeld database-herzonering, installatie van een 3-tier applicatie inclusief loadbalancer-settings en noem maar op. En het spiegelbeeld geldt bij neerschaling, ook dan moet o.a. het loadbalancer-script worden aangepast om de niet meer bestaande node te verwijderen. Om het verhaal kompleet te maken nu de verschillen voor ontwikkel- en testsystemen, waar de blauweboordenbeheerders dus een heel andere verantwoordelijkheid hebben dan het leveren van een ‘applicatieservice’. Hier gaat het niet om uptime en performance van een bepaalde applicatie maar om het simpelweg aanwezig zijn van een bepaalde VM inclusief resources. De datacenter-beheerders zijn met hun ‘control pane’ ook alleen maar aanspreekbaar op die buitengrenzen plus een korrekte versie van de operating system stack (Windows, Linux etc. en daarbovenop misschien bepaalde middleware zoals een JEE-server). Wat er binnen gebeurt, inclusief allerlei installaties, is het ‘data plane’ en in superuser-modus toegewezen aan de ‘gebruikers’ die hier toevallig systeemontwikkelaars en testers zijn. Het hele concept van Service Operations, Transition en Design blijft echter bestaan – alleen het niveau van wat de ‘Service’ is gaat minder diep. Daardoor is de trigger voor aanpassing ook geen performancemeting, maar begint die veelal met een verzoek van een gebruiker in de Service Transition workflow; al kun je ook prima werken met ‘tijdelijke resource-huur’, dus een VM die voor pakweg 48 uur klaarstaat en daarna volautomatisch vanuit het beheertool opgeruimd wordt tenzij tijdig een change request-workflow gestart wordt. Gezien de discipline in ontwikkel- en testland is dit tijdelijke model zelfs aan te bevelen ter voorkoming van aanzienlijke aantallen weeskind-VM’s die niemand gebruikt maar waar ook niemand gevonden kan worden die fiat geeft voor opschoning. Gevolgen voor de resources De juiste architectuur qua ITIL-gebruik heb je nu, maar deze door laten werken tot aan alle bouwstenen eist nogal wat meer dan juiste procedures en ITIL-beheertools. Zoals gezegd, met legacy-hardware zoals een gewone set Intel bladeservers met standaard Ethernet switching en standaard DAS disks red je het écht niet - hoe geavanceerd de hypervisor en beheertools ook mogen zijn. En we lopen dit met je langs per hoofd-bouwsteen: rekenkracht, netwerk en opslag. De eerste oftewel de CPU-capaciteit is primair een spel tussen de hypervisor-bouwer en de vendoren van de Intel/ AMD-gebaseerde serversystemen. De chipbakkers en chipsetbouwers daaromheen bepalen hoe een multicore-CPU kan worden opgedeeld en juist weer in tandem geschakeld kan worden met andere CPU’s, en het is vervolgens de kunst van de hypervisor-bouwers om die functionaliteit zo fijnmazig en overhead-loos mogelijk ter beschikking te stellen aan de VM’s. Dat gaat niet met in de mainframe- en RISC-wereld populaire begrippen zoals MIPS maar met
referentie-CPU’s zoals een 5 GHz singlecore, en jouw VM krijgt dan bijvoorbeeld de kracht van 10 referentie-CPU’s toegewezen wat fysiek misschien slechts een halve 8-core Xeon is. Elk der vier grote hypervisoren heeft hierin zijn eigen pro’s en cons: VMware Vsphere, Microsoft Hyper-V, Citrix XenServer en Red Hat KVM. De tweede factor, netwerkbandbreedte, is daarentegen een spel waar jij als datacenterbeheerder veel strakker moet toezien op de gekozen componenten. De sleutelterm is ‘software-defined networking’, dus componenten die zich allemaal via de juiste API’s laten configureren. Natuurlijk moet je kiezen voor een datacenter-backbonebus met voldoende bandbreedte voor alle mogelijke 3-tier applicaties, maar die moet vooral erg API-instelbaar zijn naargelang je druk-op-de-knop wensen. Zaken om o.a. op te letten zijn strak bandbreedtebeheer en QoS (Quality of Service) op je core switching network, enige invloed ook op het gedrag naar de ‘edge’ toe, en volledige integratie tussen de switching in de bekabeling en binnen de hypervisor. Dus je hebt softwarematige switches nodig zoals de Cisco Nexus 1000V of Citrix OpenvSwitch-gebaseerde tools, met een console die deze bestuurt tegelijk met het ITIL configuratiebeheer van je gewone hardwareswitches. En dit alles natuurlijk weer samenwerkend met de hypervisorconsole omdat die de nieuwe VM- provisioning en overbodige VM decommissioning doet en tegelijk ook het netwerk moet meenemen. En let wel: of je storage nu een apart fiberchannel-kanaal gebruikt of bijgeprikt zit op dezelfde Ethernet-achtige backbone, bandbreedte en QoS naar de opslagdisks toe is zo mogelijk nóg belangrijker dan bandbreedte tussen de servers en werkstations. En tot slot de opslag. Hier zit het onderscheid wat voor jouw beheerders relevant is niet zozeer in de techniek maar in de haalbare SLA. Dus naast aantal Tera- of Gigabytes bijvoorbeeld responstijd, fouttolerantie (RAID), backup/ replicatie en bij dit alles steeds een kostenplaatje. Fysiek moet een goed gekozen softwarebeheertool in staat zijn om zowel je nieuwe superflexibele SAN- en NAS-schijven van hetzelfde merk als het opslagbeheertool aan te sturen als, met niet al teveel verlies aan functionaliteit, al je andere opslag: dus DAS (inclusief SSD disks) en NAS en SAN van diverse merken. En een ‘logisch volume’ dat aan de VM wordt aangeboden kan liefst zelfs medium-overstijgend zijn, bijvoorbeeld een 2 Tb disk waarvan 1.5 Tb op SAN-LUN x staat en 0.5 Tb op NAS y. En dit legt eisen op aan zowel het beheertool als aan alle nieuw bij te kopen opslaghardware, die moeten ‘software-defined storage’ ondersteunen. Omdat we zometeen nog wat dieper op een voorbeeld produkt hierbij ingaan heb je toch wel enige extra technische kennis nodig. Het basisonderscheid tussen NAS en DAS/SAN blijft bestaan: bij NAS biedt de server zelf een soort ‘volume’ aan, en bij DAS/SAN biedt de hardware diskblokken aan die jouw hypervisor of clientOS tot volumes omzet. Maar omdat in een druk-op-de-knop datacenter het uiteindelijk om opslagvolumes binnen een VM gaat (van een 3-tier server of een SQL databasemachine) is dat basisonderscheid minder relevant geworden, de opslagbeheersoftware mag dit afschermen. Ook is het daardoor minder relevant geworden hoe de hardware bereikt wordt, mits je vanuit de software vooral het wat kunt bepalen in de vorm van de vereiste SLA. De discussie hierboven over enerzijds ‘data center Ethernet fabric’ zoals een Juniper Qfabric of Brocade Ethernet Fabric en anderzijds fiberchannel of FCOE/iSCSI (bijprikken op een legacy server-Ethernet) is niet relevant mits je opslagbeheertool alles kan aansturen, en steeds opslag voor je kan alloceren met de juiste bandbreedte en latency. En ook de exacte opslaghardware mag niet uitmaken, zoals gezegd moet het tool alle grote merken ondersteunen. Dus aan opslagnetwerkkant o.a. Brocade, Cisco en Juniper, en als overallplatforms o.a. NetApp en EMC maar ook systeemintegratoren-met-eigen-hardware zoals HP, Dell en Oracle. Het beeld over resources in een datacenter is natuurlijk gebaseerd op een in-house systeem, wat met het juiste virtualisatieniveau een private cloud genoemd kan worden. Maar er is wel degelijk synergie mogelijk met de public cloud, en dan specifiek met IaaS (Infrastructure as a Service), wat in principe private VM’s zijn binnen een publiek datacenter. En een aardige extra eis voor je hypervisor, en voor allerlei beheertools inclusief het opslagbeheertool, is
dat ze relatief transparant ook IaaS hulpbronnen kunnen alloceren voor je datacenter. Dat zal relatief makkelijk gaan als je hypervisor van VMware of van Microsoft is, omdat beide vendoren ook eigen IaaS cloud-tools leveren; en wat moeilijker met Citrix en Red Hat, omdat ze bruggen moeten slaan met ander-merk clouds zoals Amazon EC2 of het groeiende OpenStack. Maar onthoud steeds dat CPU, opslag en netwerk uit de cloud tóch anders qua gedrag is dan lokale private cloud-hulpbronnen. Bij CPU valt dit nog mee omdat de gebruikte protocollen veelal rekening houden met distributed locations, maar voor opslag-in-de-cloud is de latency altijd beduidend groter dan voor lokale opslag. En datzelfde cloudnetwerk zorgt ook voor een ander netwerkgedrag van je applicaties dan wanneer alles in-house zou zijn. Dus ook al dekt je software-defined storage en software-defined networking ook bepaalde stukken cloud, het verschil in onderliggende hulpbronnen is en blijft relevant!
Voorbeeldinvulling van software-defined storage: NetApp Data ONTAP Om handen en voeten te geven aan het druk-op-de-knop datacenter krijg je de nodige details over een excellent voorbeeldprodukt specifiek aan de opslagkant: NetApp Data ONTAP. Het is een ‘storage operating system’: een softwarelaag die draait op hun eigen controller appliance, en volledig via de browser bediend wordt dus welk Justenough-OS er onder de motorkap aanwezig is telt verder niet. Voor een gratis tesamen met wat VMware-tools te downloaden evaluatieversie is de host zelfs gewoon een VMware server, niet de eigen NetApp appliances. Data ONTAP bedient zowel alle nieuwe en bestaande NetApp SAN en NAS apparaten als een behoorlijk aantal devices van andere merken, mits die maar de open opslagstandaarden volgen. Belangrijke concepten binnen Data ONTAP zijn:
• Storage VM’s, wat een groep opslagcapaciteit met een bepaalde SLA is. Die wordt dan weer als één fysiek volume-blok ter beschikking gesteld aan de hypervisor, welke er weer logische VM’s binnen zal gaan maken. SVM’s doen voor opslag wat hypervisoren voor servers doen: ze ontkoppelen data-opslag van specifieke hardware, en kunnen bijvoorbeeld ook data verhuizen zonder dat de hypervisor-werking zelf zichtbaar beïnvloed wordt. Een soort ‘Storage Vmotion’ dus.
• Clustering. Niet alleen in de zin van samenvoegen van diverse devices tot één logisch geheel maar ook in de zin van ingebouwde redundantie. Natuurlijk met de hogere RAID-levels binnen 1 disksysteem maar ook met reguliere mirror-replicatie tussen disks of snapshot-backups, zodat ook een lage Recovery Time Objective en Recovery Point Objective deel zijn van het opslagbeleid.
• Deduplicatie en compressie, om ruimtebesparingen te realiseren • Cloning, wat met name voor ontwikkel- en testscenario’s maar ook voor pakweg Virtual Desktop Infrastructure
essentieel kan zijn. Natuurlijk bieden de hypervisoren zelf al elementen van deduplicatie en cloning, maar het mooie van Data ONTAP en vergelijkbare appliance-aangepaste tools is dat veel van het werk kan worden uitbesteed aan de NAS/ SAN hardware zelf – dus beduidend sneller gaat dan pakweg een ‘clone’ operatie op gewone DAS opslag in een VMWare Wintel/Lintel machine.
• De optie om ook opslag buiten het datacenter mee te nemen, met de Data ONTAP Edge optie. Deze kan DAS disks in bijkantoor-servers op afstand beheren, maar ook IaaS opslag van Amazon EC2. Let wel dat elk software-defined-storage produkt, ook Data ONTAP, slechts een bouwsteen is van je grotere drukop-de-knop-datacenter geheel; hiernaast heb je dus nodig een hypervisor, software-defined-networking en tot slot beheertools die dit alles tot één ITIL-proces aaneensmeden.
Weg met de hardwarebeperkingen maar niet met de organisatiestruktuur! Okay, het beeld zou nu enigszins kompleet moeten zijn. Een druk-op-de-knop datacenter betekent dat je veel flexibeler kunt omgaan met alle resources: niet alleen de serverhardware maar ook de opslag en de netwerkbandbreedte. Maar scheiding van taken tussen de diverse beheerclubs blijft even essentieel als voorheen: tussen witteboordenbeheer en blauweboordenbeheer, en ook tussen verantwoordelijkheden voor elke ‘ laag’ in de applicatiestack. Juist nu er geen server geleverd wordt maar een VM, en het netwerk deels binnen de hypervisor zit, moet je duidelijk afspreken wie er waarvoor verantwoordelijkheid draagt: hypervisor, VM inclusief OS, middlewarestack, opslag, netwerk en tot slot specifieke applicaties die erbovenop draaien. Maar als die afspraken er zijn en je geavanceerde tools zoals hierboven in handen hebt dan is IT-as-a-service een heel stuk dichterbij gekomen…
