Sinds jaar en dag voeren systeem beheerders installaties uit van (server) systemen. Dit gaat steeds handiger en sneller. De installatie programma’s worden steeds beter en er zijn allerlei methoden om “op afstand” te installeren. Maar het handwerk staat op het punt te verdwijnen. Met de acceptatie van virtualisatie en de opkomst van cloud computing stellen organisaties andere eisen aan het beheer van server systemen.
Virtualisatie
De noodzaak om hardware beter te benutten en sneller te kunnen reageren op verzoeken van (interne) klanten heeft gezorgd voor een brede acceptatie van virtualisatie. Ongeacht of dit nu een commerciële variant betreft of dat het virtualisatie is gebaseerd op Open Source Software, beiden leveren de mogelijkheid de hardware te partitioneren. Daarnaast biedt virtualisatie extra voordelen zoals de mogelijkheid een draaiend virtueel systeem te verplaatsten naar andere hardware. Hierdoor wordt het mogelijk onderhoud op de hardware uit te voeren zonder dat daarvoor downtime noodzakelijk is.
Onbedoelde effecten van virtualisatie Virtualisatie maakt het mogelijk dat heel snel overcapaciteit van de hardware gebruikt kan worden om nieuwe systemen te installeren. In veel organisaties werkt dit ook zo. Dit proces van "voldoen van aanvragen voor systemen" komt hiermee los te staan van het inkoopproces van de hardware. Vaak zijn dit daadwerkelijk gescheiden processen. Onbedoeld effect hiervan is wel dat er bij het "voldoen aan de aanvraag" geen toets voor de inkoop meer is. Mijn stelling is dan ook dat dit in het voordeel van hardware fabrikanten werkt omdat er een ongecontroleerde groei aan systemen kan ontstaan. Na verloop van tijd is van veel systemen ook niet meer bekend waarvoor ze precies waren en wie daarop aangesproken kan worden om te achterhalen of ze verwijderd kunnen worden.
Natuurlijk kent virtualisatie haar beperkingen. Naast een (kleine) performance overhead vanwege de virtualisatie zelf, kunnen natuurlijk nooit meer resources aan een virtueel systeem toegekend worden dan de maximale capaciteit van het betreffende stuk hardware. Als gevolg hiervan wordt het ontwerp van grote omgevingen zo gemaakt dat er wordt uitgegaan van meerder “kleine” (virtuele) systemen. Technieken die hierbij gebruikt worden zijn meerder applicatie- / webservers en loadbalancers. Hierdoor wordt het mogelijk 20 webservers in te zetten waarmee (bijvoorbeeld) de resources van drie hardware matige servers benut worden. Op deze wijze kan de capaciteit van een omgeving geschaald worden, dit wordt “scale out” genoemd. De brede acceptatie van virtualisatie leidt dus simpel gesteld tot de noodzaak meer (kleine) systemen te moeten beheren.
Shared storage
Het toepassen van virtualisatie – en vooral het willen kunnen benutten van alle mogelijkheden – leidde tot de brede acceptatie van shared storage. In veel organisaties is de invoering van virtualisatie daarom gekoppeld geweest aan het gebruik van shared storage in de vorm van een SAN of NAS. Door enerzijds de server systemen (systeem disk) en de data (data disk) op gescheiden delen van het SAN te plaatsten en anderzijds virtualisatie toe te passen is de server volledig hardware onafhankelijk geworden.
Tegenstrijdige technieken? Soms lijkt het alsof we tegenstrijdige technieken gebruiken. Met behulp van virtualisatie kan hardware gepartitioneerd (in kleine stukken verdeeld) worden. Tegelijkertijd maken we gebruik van vele "kleine" (virtuele) systemen die we middels technieken als loadbalancers en proxy's samen laten werken als een grote omgeving. Hoewel dit tegengestelde technieken lijken is dit uiteindelijk niet het geval. De combinatie van deze technieken maakt dat we omgevingen volledig vrij van de hardware kunnen schalen, zowel kleiner, maar ook groter dan de fysieke hardware. Uiteindelijk is deze flexibiliteit een belangrijk "einddoel". Hierdoor kunnen omgevingen klein gestart worden en kunnen ze naar gelang de vraag van de organisatie (of klanten) mee groeien (schalen).
Inmiddels zijn de zaken die bepalend zijn voor een specifiek systeem van elkaar te scheiden, te weten:
- hardware (resources als CPU, memory en disk opslag)
- het operating systeem
- de feitelijke configuratie van het systeem
- de data
De logische scheiding van de bovengenoemde zaken heeft grote gevolgen voor het management van server systemen. Omdat er veel gelijksoortige systemen te beheren zijn, is het voor de hand liggend om deze centraal te beschrijven en geautomatiseerd te beheren. Bovendien is het ook wenselijk de deployment van systemen willen automatiseren. Logische systemen zijn feitelijk niets anders dan een operating systeem met een specifieke configuratie en bijbehorende data. Een en ander wordt nog eens versterkt door de opkomst van cloud computing. Hierbij wordt “elasticiteit” aan het concept toe gevoegd hetgeen nog eens extra de noodzaak voor geautomatiseerde deployment en management benadrukt. Eigenlijk is er hier sprake van het totale “life cycle management” van systemen, het geautomatiseerd beheren van systemen van begin tot einde.
Wegwerp IT
Er zijn verschillende producten waarmee het geautomatiseerd beheren van systemen geregeld kan worden. Het snel kunnen activeren van extra capaciteit (bijvoorbeeld extra webservers uitrollen) versterkt de elasticiteit van cloud computing. Net zo makkelijk als nieuwe (extra) systemen uitgerold kunnen worden t.b.v. piekbelasting, kunnen ze daarna weer opgeheven worden als de piek voorbij is. De installatie media, configuratie en data blijven bestaan en kunnen wederom gebruikt worden bij een volgende piek. Je zou wel kunnen spreken van “wegwerp IT”. Deze manier van werken staat haaks op het handmatig beheren van individuele servers zoals dat traditioneel binnen veel organisaties nog gedaan wordt.
Bijkomende voordelen Doordat de (configuratie van) systemen beschreven zijn in het deployment systeem, kunnen snel nieuwe - identieke - systemen uitgerold worden. Deze systemen zijn dus exact gelijk aan elkaar (m.u.v. van namen en adressen). Feitelijk zijn hiermee systemen dus ook perfect gedocumenteerd. De vastgelegde configuratie beschrijft precies welke software geïnstalleerd is, welke versie het van die software betreft en welke instellingen gehanteerd worden. Dit is een zeer bruikbaar principe als er bijvoorbeeld testsystemen nodig zijn of na een eventuele hack poging. Een systeem kan eenvoudig opnieuw uitgerold worden, waarbij men er zeker van is dat die identiek is aan de originele server.
Open Source voorbeelden
Er zijn natuurlijk verschillende commerciële producten te verkrijgen waarmee het geautomatiseerd managen van (virtuele) systemen geregeld kan worden. Vanwege de grote invloed van Open Source Software op cloud computing (de meeste public clouds zijn gebouwd op basis van Open Source Software) zijn er ook veel Open Source Software alternatieven beschikbaar. Gedacht kan worden aan Red Hat Satelite, of de ontwikkel versie daarvan, SpaceWalk. Voor wat betreft het uitrollen van systemen kan Cobbler gebruikt worden en management kan worden gedaan middels Puppet of Ansible.
Versiebeheer Als de configuratie van een systeem eenvoudig beschreven kan worden (middels een takst file), dan is het maar een kleine stap deze configuratie in het versiebeheer op te nemen. Hiervoor kan bijvoorbeeld GIT gebruikt worden. Eenmaal versiebeheer toegepast, is zowel beschreven wie, wat, en waarom heeft gewijzigd, maar kan er ook een rollback worden gedaan naar een "oude situatie". Een dergelijke manier van werken sluit goed aan bij een systematiek als ITIL.
Het is te verwachten dat de verschillende tools steeds dichten naar elkaar groeien. Zo maakt Cobbler inmiddels deel uit van Spacewalk en wordt OpenStack door Red Hat gebruikt als basis voor hun Red Hat CloudForms. Overigens heeft Red Hat een management-laag aan Cloudforms / OpenStack toegevoegd waarmee systemen over verschillende cloud omgevingen heen beheerd kunnen worden. Dit is buitengewoon interessant wanneer je bijvoorbeeld gebruik wilt maken van zowel een private cloud (dat bijvoorbeeld op OpenStack gebaseerd is) en een public cloud (Amazon bijvoorbeeld) om pieken op te vangen.