Blog

Auto Deploy met VMware en Chef – Inleiding

Een oud IT probleem, waar elk systeem wel een keer tegenaan loopt, is dat van schaalbaarheid. Het ontwerpen van een goed werkend systeem is al een vak apart, maar om deze ook goed op de toekomst voor te bereiden is extra moeilijk. Het is de combinatie van software en architectuur, die ervoor zorgt dat een systeem valt of staat onder druk. In dit artikel wil ik mij vooral op de architectuur van een systeem storten en uitleggen hoe wij bij Cyso ervoor hebben gezorgd dat onze core applicaties op een platform staan dat zowel schaalbaar is als eenvoudig te onderhouden. Dit artikel richt zich vooral op het probleem met schaalbaarheid en het beschrijven van de concepten van de door Cyso gekozen oplossing.

Dit is het eerste deel in de serie over Cyso’s DevOps gerelateerde projecten, gefocust op automatic deployment van machines. Lees ook deel twee: Auto Deploy met VMware en Chef – Development omgevingen.

Waarom is schaalbaarheid moeilijk?

Als we kijken naar het achterliggende probleem bij schaalbaarheid, de oorzaak waardoor dit überhaupt een onderwerp van discussie wordt, is er vaak slechts één probleem. Er is een systeem dat op een gegeven moment niet meer voldoet. Dit kan plotseling ontstaan doordat het systeem ineens te maken heeft met een explosieve toename in populariteit, of geleidelijk als natuurlijk resultaat van een groeiend bedrijf. In beide gevallen is vaak de meest simpele oplossing om er meer hardware tegenaan te gooien. De manier waarop dit gedaan wordt, is afhankelijk van de architectuur van de applicatie. Gelukkig is het tegenwoordig een stuk makkelijker om een systeem te maken met de ontwikkelingen in virtualisatie en Configuration Management.

Meer ijzer

Enige jaren geleden waren bij Cyso onze eigen systemen meestal nog gebaseerd op fysieke hardware. Virtualisatie en Cloud technologie waren toen nog niet zo goed ingeburgerd als nu en hardware zorgde toen nog vaak voor een betere performance. In de tussentijd hebben de ontwikkelingen in virtualisatieland niet stilgestaan en kiest ook het overgrote deel van onze klanten voor virtuele infrastructuur. De voordelen en de flexibiliteit die virtualisatie met zich meebrengen helpen bij het oplossen van het schaalbaarheidsprobleem. Eén van de voordelen is dat het aanmaken van extra machines een kwestie kan zijn van een druk op de knop. Met VMware vCenter is het bijvoorbeeld mogelijk om een template te maken van een geconfigureerde machine, waarna deze binnen minuten omgezet kan worden naar een werkende virtual machine (VM). Het bijzetten van extra resources bij bestaande VMs is eveneens simpelweg een actie in de beheerinterface van vCenter. Met fysieke hardware is in beide gevallen een trip naar het datacenter noodzakelijk. De doorlooptijd van het aanmaken, configureren en in gebruik nemen van een machine kan met virtualisatie teruggebracht worden tot minuten, in plaats van uren of dagen. We hebben hier dan ook dankbaar gebruik van gemaakt bij het ontwerpen van een nieuw systeem voor onze core applicaties.

virtual_machine_templating

Alleen ijzer?

Met alleen (virtueel) ijzer zijn we er nog niet; een kale machine is ongeveer net zo handig als een auto zonder stuur. Op een kale machine zal een besturingssysteem geïnstalleerd moeten worden, voordat deze gebruikt kan worden. Daarna is het zaak om de applicaties te installeren die nodig zijn voor de machine om zijn taak te kunnen vervullen. Voor het gemak delen we de stappen die nodig zijn na het aanmaken van een kale machine op in twee delen: installatie en configuratie. Samen met het aanmaken van de machine zelf kan het proces van het aanmaken van een machine tot het in gebruik nemen ervan dus benoemd worden in drie stappen: aanmaken, installeren en configureren. Voor alledrie de stappen is een aparte oplossing te bedenken, welke afhankelijk kan zijn van het type systeem waarvoor de machine gemaakt wordt en de rol die de machine heeft binnen dat systeem.

Aanmaken van VMs

De eerste stap in het uitrollen van een nieuwe machine is het aanmaken van de machine zelf. Omdat we bij Cyso de meeste Cloud infrastructuur gebaseerd hebben op VMware, is dit logische keuze hiervoor. Van VMware hebben wij twee smaken: vCenter en vCloud. Beide platformen hebben hun eigen voordelen, en we hebben beide platformen gebruikt in een automatic deployment setup. vCenter laat zichzelf bijvoorbeeld goed configureren, en er is strakke controle mogelijk op de VMs die op vCenter draaien. Daarnaast biedt vCenter ook uitgebreide oplossingen voor high availability, wat voor bepaalde systemen een vereiste kan zijn.

vmware-vs-vcenter

vCloud onderscheidt zich door de eenvoudige opzet en het gebruiksgemak. In een setup waar de eindgebruiker mogelijk nog wat moet aanpassen aan de VMs, is de vCloud Director interface hier goed geschikt voor. Niet de volledige vCenter featureset is beschikbaar, controle over welke VM op welke fysieke machine leeft ontbreekt bijvoorbeeld en high availability kan alleen in algemene zin geconfigureerd worden, maar deze vereenvoudiging leent zich uitstekend voor de iets minder doorgewinterde gebruiker. Daarnaast heeft vCloud een goed uitgewerkte en gedocumenteerde API, wat voor het automatiseringsgedeelte van automatic deployment een uitkomst is.

Bij Cyso hebben wij vCloud gebruikt voor onze interne development omgevingen, en vCenter voor ons productieplatform. De keuze hiervoor sluit aan bij de voor- en nadelen die ik genoemd heb.

Installeren van VMs

Het installeren van een OS op de nieuwe machine heeft eigenlijk als direct doel om de volgende stap mogelijk te maken. Uitgangspunt is dat alleen datgene dat nodig is om de machine op te kunnen starten wordt geïnstalleerd. Voorbeelden hiervan zijn het OS zelf, netwerkinstellingen en benodigde systeem libraries. Alles wat nodig is voor de applicatie wordt in de configuratiestap geïnstalleerd. Hiervoor is gekozen zodat het resultaat van de installatiestap een VM is die voor zoveel mogelijk verschillende configuraties gebruikt kan worden.

Voor het installeren van de VMs hebben wij bij de eerder genoemde development omgevingen gekozen voor templates. Dit heeft als groot voordeel dat het aanmaken en installeren van de VM gedaan kan worden met één handeling. Binnen VMware is het mogelijk om een VM om te zetten naar een template, en deze template kan vervolgens gebruikt worden om exacte kopieën te maken met dezelfde data. vCloud gaat hier nog iets verder in. Het is namelijk mogelijk om na het uitrollen van de VM automatisch de hostname en netwerk configuratie in te stellen. Hiermee wordt voorkomen dat er IP conflicten ontstaan na het uitrollen van meerdere VMs vanuit hetzelfde template. Daarnaast kost het uitrollen van een VM vanuit een template slechts, in het ergste geval, enkele minuten, vergeleken met tientallen minuten tot enkele uren voor een handmatige installatie.

Het gebruik van templates heeft ook een groot nadeel: de templates moeten doorlopend voorzien worden van (OS) updates. In het geval van onze development omgevingen is dit niet zo’n groot probleem, omdat we hier maar te maken hebben met één template. Als deze methode echter grootschaliger toegepast moet worden, ontstaat vanzelf de wens voor meerdere verschillende templates. Bijvoorbeeld verschillende besturingssystemen (Ubuntu, CentOS en Windows) resulteren al in meerdere templates, en de verschillende versies maken dit alleen maar ingewikkelder. De voordelen van VMs moeten dus afgewogen worden tegen de nadelen die ontstaan zodra er (te)veel verschillende templates nodig zijn.

Een alternatief voor voorgedefinieerde templates, is het gebruik van een tool die voor elke nieuwe VM automatisch het gehele installatie proces doorloopt voor het OS. Hierdoor kan worden voorkomen dat de nieuwe VM al direct na uitrollen out of date is. Tevens kunnen er een aantal voorgedefinieerde pre-seed definities gemaakt worden, die de installatie van het OS kunnen beïnvloeden en aanpassen. Bij Cyso zijn we op dit moment onderzoek aan het doen naar de mogelijkheden van deze manier van installeren. Het lijkt erop dat de extra flexibiliteit ten koste gaat van slechts een iets langere doorlooptijd voor het installeren van het OS.

Configureren van VMs

De laatste stap in het automated deployment proces is het configureren van de geïnstalleerde VM. Voor deze stap zijn er veel tools beschikbaar. Bekende namen zijn CFEngine, Puppet en Chef. Bij Cyso hebben we vooralsnog gekozen voor Chef voor ons Configuration Management (CM) project, maar we houden onze ogen open voor met name ontwikkelingen aan Puppet. Zowel Chef als Puppet zijn geschikt voor wat we willen bereiken in de laatste stap: het configureren van de machine. Dit gebeurt bij beide tools door het definiëren van alle stappen die doorlopen moeten worden om de VM gebruiksklaar te maken. Dit kan zo diep en specifiek gaan zoals je zelf wilt. Voor dit artikel maak ik onderscheid tussen twee scenario’s:

  1. De machine wordt geconfigureerd tot een bepaalde rol en op dat moment overgedragen aan de klant.
  2. De machine wordt volledig afgeconfigureerd, inclusief het installeren van de applicaties en het up-to-date houden daarvan.
chef_scenarios

Denk bij het eerste scenario aan bijvoorbeeld een LAMP server. Een klant wil simpelweg een server afnemen, waarop de LAMP-stack staat, met daarop een aantal voorgedefinieerde gebruikers waaronder de applicaties komen te draaien. Het Chef proces neemt dit voor zijn rekening en levert een VM af waarbij de klant zelf zijn applicaties nog op de goede plek moet zetten. Pas daarna kan de klant de VM echt in gebruik nemen. Bij het tweede scenario verzorgt Chef ook deze laatste stappen en hoeft de klant niets meer zelf te doen.

Het verschil tussen deze twee scenario’s zit niet zozeer in hoe de machine geconfigureerd wordt, maar wel hoe de machine na configuratie in stand gehouden wordt. In het eerste scenario en voorbeeld zal het basis OS en de LAMP stack vallen onder het configuratiebeheer van Chef, hetgeen betekent dat aanpassingen gecontroleerd worden door de CM tool en ongeoorloofde aanpassingen weer teruggedraaid worden naar de originele staat. In het tweede scenario wordt ditzelfde gedrag ook uitgevoerd op de applicatie zelf, waardoor deze ook onder het configuratiebeheer valt.

Beide scenario’s zijn valide en hebben allebei hun toepassing. Het eerste scenario is breder inzetbaar en makkelijker toepasbaar, maar heeft als gevolg dat er handmatige acties nodig zijn om de applicatie draaiend te krijgen en up-to-date te houden. Het tweede scenario neemt dat allemaal uit handen, maar heeft als voorwaarde dat de applicatie zich automatisch laat uitrollen en automatisch geconfigureerd kan worden. Voor zowel onze development omgevingen als ons productieplatform hebben we ervoor gekozen om het tweede scenario te gebruiken. We hebben onze applicaties zodanig aangepast dat het mogelijk is om deze automatisch uit te rollen en te configureren.

Tot slot

Tot zover het kijken naar het probleem van schaalbaarheid op functioneel niveau. In een tweetal vervolg blog posts zal ik me richten op de specifieke details van de oplossing die we hebben gebruikt voor onze development omgevingen en het productieplatform.

Wil je op de hoogte blijven van de laatste ontwikkelingen op IT gebied. Meld je dan hier aan voor de nieuwsbrief.

Benieuwd naar de mogelijkheden? Let’s talk!

Cyso stories

29/04/2016

Optimale opslag van data met storage tiers

Bij het inrichten van een hostingoplossing is de keuze voor storage een belangrijk onderdeel.
22/03/2019

In 7 stappen naar een succesvolle delivery

Een belangrijk aspect binnen de hosting-branche is het managen van de processen rondom opleveringstrajecten van nieuwe klanten en migratietrajecten van bestaande klanten.
12/10/2023

Waarom is een Disaster Recovery strategie belangrijk?

Disaster recovery verwijst naar het proces van het herstellen van IT-systemen en gegevens na een onverwachte gebeurtenis

Interesse in een van onze diensten?

Wat is je vraag? Neem nu contact met ons op.

Wil je dat wij contact met jou opnemen? Laat je gegevens achter en wij bellen je terug.

Cyso contact