Virtualisatie is in. Iedereen doet het. Je kunt geen vakblad meer openslaan, geen leverancier meer spreken of het gaat over virtualisatie. Speelt dit ook in uw bedrijf? Is de meest gehoorde vraag. Jan-Paul Krijgsman probeert hierop antwoord te geven.
Virtualisatie zou het loskoppelen moeten zijn van de software (OS'en) van de hardware waardoor de infrastructuur flexibeler wordt. Voordelen die genoemd worden van virtualisatie zijn hardware consolidatie, hogere beschikbaarheid, flexibeler toewijzen van hardware resources aan applicaties en vereenvoudigd beheer van de omgeving. Dit alles met een directe besparing in kosten. Maar is dit ook zo? Dit hang zeer af van het uitgangssituatie.
Hardware consolidatie
Ideaal zou zijn dat door het loskoppelen van de hardware en software laag we langer zouden kunnen doen met de bestaande hardware. Helaas is dit niet zo. Veelal is de huidige hardware niet geschikt om te dienen als onderlaag in de virtualisatie. Het verschil in stepping van de cpu's zorgt ervoor dat het flexibel toewijzen van resources (VMotion) niet werkt. De steppingcycli moeten gelijk zijn. Wil je dus virtualiseren, dan zul je uniforme hardware moeten gebruiken. Veelal worden daarom blade servers aangeboden. Alleen: de ontwikkeling in hardware staat niet stil, toch?
Hoe kunnen we toekomstige snelle processoren inzetten in onze virtualisatie omgeving als deze straks een andere steppingmechanisme hebben? Een door een leverancier aangeboden oplossing is de volgende: Koop een blade-rack met daarin ruimte voor (stel) twaalf blades en vul deze met vier blades van hetzelfde type. Stijgt volgend jaar de behoefte aan servercapaciteit, koop er dan volgend jaar bijvoorbeeld vier blades bij. Zijn deze van een nieuw type ruil dan de oude blades in en vervang deze door vier nieuwe. Herhaal dit kunstje het jaar daarop. Rekent je mee? Vier plus acht plus twaalf blades voor een uiteindelijke situatie van twaalf state of the art blades. Een investering van honderd procent meer hardware dan noodzakelijk. Niet echt geweldig voor de business case.
Resources
Veelal heb je de omgeving ingericht op maximale piekbelasting per server. Het patroon zal verlopen als in de nevenstaande figuur. Gemiddeld levert dat een belasting op van zo'n vijftien tot twintig procent van je cpu capaciteit.
Door zorgvuldige keuze van cpu-kracht per applicatie/OS combinatie draait het systeem echterzonder hickups. Hickups ontstaan als u gedurende enkele seconden de processorcapaciteit op honderd procent staat of je I/O de maximale throughput haalt. Dodelijk voor de acceptatiegraad van je gebruikers.
Je kent vast ook wel de momenten op een dag dat de infrastructuur zwaar belast wordt: 's ochtends als iedereen zijn of haar pc aanzet en de businessapplicaties opstart, de e-mail opent en de eerste documenten van de fileservers trekt. Je domain controllers, dns-servers en business applicaties worden dan zwaar belast om alle inlog en opstart acties te verwerken. In een gevirtualiseerde omgeving wil je natuurlijk niet dat door de stapeling van meerdere virtuele servers op één hardware doos dit soort piekmomenten en hickups ontstaan.
VMotion zal op een gegeven moment ingrijpen en servers gaan verplaatsen. Dit gebeurt echter vaak nadat de cpu-power al op honderd procent staat. De eerste hickup heb je te pakken. Je kunt dit natuurlijk voorkomen door van te voren na te denken over de verdeling van virtuele servers over de beschikbare hardware. Maar was nu niet het doel van virtualisatie dat we de software laag los gingen koppelen van de hardware? Dit soort planningszaken maken de inrichting van de omgeving complexer. Denk hierbij ook aan toekomstig toe te voegen virtuele servers. Waar passen deze het beste? Hoe voorkomen we interferentie en wat is het maximaal aantal servers per hardware-doos die we willen toestaan? (zie ook het hoofdstuk compliance) Hoe verdelen we die servers zo optimaal mogelijk? Wanneer hebben we resources te kort?
Verwerkingskracht
Het implementeren van DRS en VMotion levert een flexibele toewijzing van processorkracht op aan het besturingssysteem (OS) en aan de applicatie(s) in dat OS. Helaas is het nog vaak zo dat de meeste van de applicaties slechts kunnen omgaan met één cpu of op zijn best met twee. Licenties van bijvoorbeeld MS SQL zijn beperkt tot een aantal cpu's. Het toevoegen van meerdere verwerkingseenheden zal geen performance verbetering opleveren. Dit betekent dus dat de maximale cpu-kracht die je in de infrastructuur hebt bepalend is voor de performance van de applicatie.
Vergeet niet dat de hypervisor ook zo'n vijftien procent cpu-kracht verbruikt. Zit je applicatie dus al tegen de maximale kracht aan (op de piekmomenten!) dan lever je door te virtualiseren vijftien procent ruimte in. Bij infrastructuren met verschillende cpusnelheden ben je dus genoodzaakt om applicaties toe te wijzen aan de juiste hardware (lees cpu's), wil je het vlotte verloop kunnen garanderen. Een reden te meer om òf de hardware te standaardiseren òf complexe toewijzingen van tevoren te bepalen.
Compliance
Een document van Microsoft over licentieproblematiek in virtualisatieland leert dat MS OS licenties gebonden zijn aan de hardware. Heb je bijvoorbeeld twee stuks hardware met ieder twee virtuele OS'en er op èn maakt je gebruik van VMotion/DRS om ervoor te zorgen dat bij hardware-uitval de OS'en naar de andere server kunnen, dan heb je volgens Microsoft vier operating licenties per hardware doos nodig. Tel je mee? Twee productie systemen op doos-1 twee en op doos-2 twee ‘reserve', maar ook op doos-2 twee en op doos-1 twee ‘reserve'. Dat maakt het totaal van acht server OS-licenties in plaats van de vier echt noodzakelijke voor de productieomgeving. Overhead honderd procent. Niet een geweldig item voor je business case.
Daarnaast wil je natuurlijk wel compliant zijn. Oplossing zou kunnen zijn om meerdere applicaties per OS toe te passen om de overhead te minimaliseren. Maar waarom zouden we die dan weer willen virtualiseren? Veel it-managers hangen de één business applicatie per OS systematiek aan om het beheer zo eenvoudig mogelijk te houden.
Hoge beschikbaarheid
Traditionele methoden om hoge beschikbaarheid van je applicaties te waarboren is het inzetten van cluster technologie of het inzetten van fout tolerante hardware (als je de in-memory transacties niet kwijt wilt raken). Binnen je virtualisatie omgeving kunt je HA implementeren. Dan ben je echter alleen verzekerd tegen het vastlopen van je OS. Je kunt (op dit moment) niet monitoren op services binnen je operating systeem. Wilt je dat toch, dan moet je de, toch al complexe cluster technologie, virtualiseren. Daarbij is het natuurlijk verstandig om de twee nodes van het virtuele cluster op twee verschillende hardware-dozen te draaien.
Documentatie van de leveranciers leert dat dan een extra, fysieke, netwerkaansluiting tussen de servers nodig is voor de hardware. We koppelen de hardware laag dus niet los van de software! Het is ook niet mogelijk om VMotion technieken te gebruiken èn je moet goed oppassen hoe je de connectie met je san legt (RAW in plaats van Virtual). Last but not least: de documentatie leert dat de virtuele cluster OS'en alleen van lokale storage (DAS) kunnen opstarten. Kortom: complexe cluster technologie is nog complexer en staat zeker niet los van de hardware. Dus ook geen toewijzing van extra resources als de services deze nodig hebben. Je zult de hardware doos moeten upgraden.
Stel je de eis aan de business-applicatie dat de in-memory transacties bij een hardwarestoring niet verloren mogen gaan, dan is fout tolerante hardware vooralsnog de oplossing. Een aanbieder van fout tolerante hardware leert ons dat de managementsoftware van de virtualisatie laag eigenlijk op deze hardware moet draaien. Er is immers slechts één instantie van deze management software en dus per definitie een SPOF. Wil je een betrouwbare virtuele omgeving? Koop dan blades en relatief dure fout tolerante hardware.... Ziet je de business case al vorm krijgen?
Beheer
Je kent vast wel de vervelende storing ‘het systeem reageerde zo traag'. Heel vervelend omdat je moet uitzoeken wat de veroorzaker is van deze klacht. Is het een slecht geschreven routine of database query? Is het de toevallige combinatie van factoren als piekbelasting èn een zware query tegelijk draaien? Was je netwerk druk? Et cetera. Ga je nu virtualiseren, realiseer je dan dat er vragen bijkomen: draaide het OS op een server met voldoende processor capaciteit? Immers VMotion kan je server dynamisch verplaatsen. Welke andere OS'en draaide er tegelijkertijd met die van de probleemapplicatie? Wat was hun processorbelasting? Was de gezamenlijke I/O naar disk niet te hoog? Hoe zit het met het gezamenlijke geheugengebruik? Natuurlijk levert de virtualisatielaag tools om hier antwoorden op te vinden. Het zoeken naar de oorzaak wordt er echter niet eenvoudiger op. Hoe meer vragen je moet stellen hoe meer antwoorden je moet vinden voordat je iets kunt uitsluiten.
Een ander, in mijn ogen grootste, gevaar van virtualisatie zit in één van de grootste voordelen van virtualisatie: het gemak waarmee een server in de lucht getild kan worden. Je zult een sterk change management proces moeten implementeren om een wildgroei aan virtuele servers te voorkomen. Gezien de bovenstaande complexiteit zeer zeker noodzakelijk. De snelheid waarmee een virtuele server vervangen kan worden door een nieuwe is fantastisch.
Echter het gevaar bestaat dat de controle op de goede werking van een applicatie na bijvoorbeeld een OS-patch verslapt. Immers: we hebben het zo in de lucht, maar ook zo weer uit de lucht als het niet goed is. Dus waarom uitgebreid testen? De gebruikers echter zullen snel constateren dat er niet goed getest is en daarover klagen. Je kunt door de virtualisatie echter de voorgaande situatie vrij snel herstellen en een nieuwe poging wagen. Er is echter al wel een verstoring veroorzaakt. Zonder goed change-/patch-management en versiebeheer van de virtuele servers loopt je het gevaar slordig te worden en daarmee de gebruikers onnodig te frustreren. Een niet te onderschatten probleem.
Conclusie
De vele voordelen van virtualisatie hebben ook hun schaduwzijde. Het zou best eens kunnen zijn dat je de zaken goed op orde hebt. De juiste processorcapaciteit voor de business-applicaties en servers al dan niet in cluster vorm, fout tolerant of redundant om de omgeving zo stabiel mogelijk te laten draaien. Denk dan goed na of, en waarom, je wilt gaan virtualiseren.
Begrijp wel, ik ben geen tegenstander van virtualisatie. Ook mijn technisch hart gaat sneller kloppen van de mogelijkheden. Virtualisatie is iets dat er komt en waarschijnlijk niet meer weg gaat. Dus eens zullen we op de trein moeten springen. Toch krijg ik er wel een groot hype gevoel bij. Immers planning en beheer worden complexer waarbij je de vraag moet stellen of de beheerders dat aankunnen. Er is nog geen loskoppeling van software en hardware. De investeringen in licenties en hardware zullen stijgen als je voorbij de initiële investering kijkt. Nog even los van de investering in de virtualisatiesoftware zelf.
Als in de toekomst de hypervisor in hardware ingebakken wordt en het inderdaad niet meer uitmaakt welke hardware je kunt combineren; de licentie problematiek aangenamer wordt (en waarom zou Microsoft dat doen?); we kunnen monitoren op service niveau binnen de operating systemen en, wat mij betreft, we de juiste security features in de virtualisatie laag kunnen inbouwen, dan gaat het echt wat worden met de virtualisatie van onze productieomgevingen. Tot die tijd zullen de hardware prijzen dalen, zal de hardware energie-zuiniger worden en zullen de prestaties stijgen. En zetten we virtualisatie in op onze ontwikkel-, test- en acceptatieomgevingen.
Aanvulling auteur:
Dit artikel heb ik een jaar geleden geschreven. Inmiddels weet ik dat delen achterhaald zijn door de ontwikkelingen in de virtualisatie branch. Zo heeft Microsoft onlangs zijn licentiepolitiek aangepast, overigens na het uitbrengen van de eigen hypervisor. Bert heeft volkomen gelijk als hij zegt dat VMotion niet de reden moet zijn van virtualiseren. Echter als je virtualisatie aan het bestuderen bent zie je dat dit soort extra zaken naar voren worden geschoven als 'meerwaarde' elementen om klanten over de streep te trekken. Al met al hangt het (financiele) succes van virtualisatie toch af van de verhouding van het aantal te consolideren servers op 1 hardware doos. Wat iedereen dan onmiddelijk aanvoelt is het toegenomen risico wat je loopt: immers 1 HW storing levert je een grote uitval op van al je virtuele servers. En dan komt vmotion onmiddellijk weer in het spel.... (of je moet fout tolerante servers inzetten.)
In een kleine omgeving als de onze is het moeilijk om de vereiste consolidatieniveaus te halen met behoud van redundancy, high availability en service graad (capacity en beschikbaarheid).
Ik blijf er nog bij dat virtualisatie op een hybride HW omgeving voorlopig nog niet echt aan te raden is. Je ziet toch vaak dat goede business cases gebaseerd zijn op nieuwe HW onder de omgeving. Maar wat met de opkomst van nieuwe HW? Het downwards compatible maken van HW geeft wel een gevoel bij mij van: waarom zou ik de nieuwste HW kopen als ik het in 'legacy' mode zou moeten gaan inzetten? {Dit is een gevoel en niet gebaseerd op onderzoek.}
Zoals eerder gezegd: ik ben geen tegenstander van virtualisatie, in tegendeel, ik denk dat dit een geweldige ontwikkeling is die helaas nog in de kinderschoenen staat (gaat ons nooit hard genoeg...).
Jan-Paul Krijgsman,
Manager ICT Department De Ruiter Seeds
bron: http://www.computable.nl/artikel/ict_topics/virtualisatie/2727569/2333390/zin-en-onzin-van-virtualisatie.html
Geen opmerkingen:
Een reactie posten