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.
Jan-Paul Krijgsman,
Manager ICT Department De Ruiter Seeds
Jan-Paul,
Een gezonde argwaan bij elke ICT-trend die naar hype ruikt is zeker op zijn plaats. Door dit soort artikelen blijft iedereen scherp. Echter, zonder te willen beweren dat virtualisatie alleen maar gouden bergen oplevert wil ik toch het punt van VMotion nuanceren.
Je redenatie gaat ongeveer als volgt: (1) virtualisatie maakt onder andere VMotion mogelijk, (2) VMotion biedt prachtige functionaliteit, (3) VMotion kent echter zijn beperkingen en dus (4) virtualisatie valt toch wel een beetje tegen.
Ten eerste zijn er vaak veel meer redenen om te virtualiseren. Denk bijvoorbeeld aan serverconsolidatie, het vereenvoudigd kunnen migreren van niet draaiende machines of de ondersteuning van verschillende operating systemen op dezelfde fysieke server. Dat VMotion zo tot ieders verbeelding spreekt leidt er soms toe dat de motivatie voor virtualisatie onnodig daaraan opgehangen wordt. Bij het onderkennen van de beperkingen slaat dit dan als een boemerang op je terug.
Ten tweede is het hele gebied van virtualisatie nog zodanig pril dat het samenspel tussen de hypervisor en de CPU tot nu toe nog niet op alle punten naar behoren functioneert. De CPU-fabrikanten onderkennen dat ook en zo hebben bijvoorbeeld zowel Intel als AMD hun CPU-architectuur zodanig uitgebreid dat toekomstige CPUs wel samen met de huidige generatie CPUs in een VMotion omgeving kunnen werken. VMware ondersteunt dit onder de naam Enhanced VMotion Compatibility en heeft daarvan een uitstekende Information Guide gepubliceerd (zie http://www.vmware.com/files/pdf/vmotion_info_guide.pdf).
Dus, ja VMotion kent zijn beperkingen, maar (1) dit is al aangepakt door zowel hardware als software leveranciers en (2) VMotion vormt slechts een van vele aspecten van virtualisatie.
Ik steun Bert in zijn bewering.
Je kunt d.m.v. virtualisatie weldegelijk hardware en software van elkaar loskoppelen.
Even uitgaande van virtualisatie met producten van Vmware, kan ik een fysieke server met Windows 2003 op bijv. een HP Proliant DL380G5 (Intel), eerst virtualiseren naar een Vmware ESX server draaiende op een HP Proliant DL385 (AMD). Na het wegslopen van specifieke HP-zooi, is de server gevirtualiseerd en tevens werkt deze nu op een heel andere CPU.
Nu koop ik een hele mooie nieuwe IBM server met 4 quad core Intel CPU’s en 128GB aan RAM en ook hierop installeer ik VMware ESX. Vervolgens migreer ik de gevirtualiseerde server probleemloos, mits deze uitstaat (coldmigrate), naar de IBM. Start de server op en tata … Geen problemen. Alles werkt alsof de server nog op een AMD-machine draait!
Vmotion is een technologie om de machine middels een hotmigratie te kunnen verplaatsen en staat in dit geval helemaal los of de betreffende server gemigreerd kan worden of niet.
In dit voorbeeld is de server VOLLEDIG onafhankelijk geworden van de hardware, mits dit x86 hardware blijft. Men is nog niet zover dat we ook onze Windows x86 installaties naar bijv. een Itanium ESX machine kunnen migreren.
Ondanks dat er inderdaad nog wat haken en ogen zitten aan _server_virtualisatie, moeten we ook niet stellen dat de “oude” wereld van “1-op-1” nu zo’n geweldige prestaties leverde. Om een voorbeeld te noemen: server migraties zijn nog steeds niet mijn favoriete bezigheid.
Het stadium waar servervirtualisatie zich op dit moment in verkeerd is die van puberteit. Net volwassen genoeg om mee te spelen in productie, maar nog niet volwassen genoeg om de volledige IT infrastructuur te dragen. Ook daar zal verandering in komen. Vendors zitten niet stil en zullen uiteindelijk ervoor zorgen dat ook servervirtualisatie volwassen wordt.
Op dit moment kun je voor veel bedrijven wel degelijk een goede business case maken om te virtualiseren. Ik ben het dus oneens dat servervirtualisatie alleen in OTA omgevingen gebruikt moet worden. Ook voor productie is servervirtualisatie wel degelijk geschikt. Business cases en succesvole realisaties met positief resultaat in overvloed.
Het blijft echter dhr. Krijgsman’s goed recht om hier niet voor te kiezen. Ik zou hem graag anders willen overtuigen 😉
Martijn Baecke
Technical Consultant Virtualisatie
Inter Access
Beste Bert, Martijn,
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
Beste Jan-Paul,
Wat men in het algemeen vaak doet en ik proef het hier ook is het focussen op de techniek. VMotion is maar een middel om iets te bereiken. Waarop baseer je dat virtualisatie op een hybride omgeving niet aan te raden is?
Virtualisatie is er al een tijdje sterker nog, bijna 90% van alle nederlandse bedrijven hebben minimaal 1 server virtueel draaien. Er zitten erg veel voordelen aan (natuurlijk ook nadelen). Nieuwe hardware kopen terwijl je je oude zooi erop laat draaien? Natuurlijk! Je wilt toch continuiteit van je huidige omgeving? Veel applicaties die op servers van vroeger draaiden kunnen niet meer op de huidige servers draaien. Met virtualisatie haalt men de verouderde hardware weg en plaatst men hiervoor een virtuele server voor terug. Met een virtual machine ben je hardware on afhankelijk.
Het vereist alleen een andere manier van naar dingen kijken. Het gevoel speelt daarbij een belangrijke rol. Virtualisatie is niet tastbaar. Je kan niet naar je server lopen en het zo een schop geven als hij het niet doet. Links om of rechts om zal virtualisatie steeds meer en meer zijn intrede doen in heel veel zaken op ICT gebied. Ik denk zeker dat de jongere generatie beheerders steeds meer en meer ook de virtuele technieken aangeleerd zullen krijgen, waardoor op termijn virtualisatie nog groter zal worden dan het nu is.
Met vriendelijke groet,
Laurens van Gunst
Pre-sales Consultant Virtualisatie
Wheldon Technologies
“bijna 90% van alle nederlandse bedrijven hebben minimaal 1 server virtueel draaien”
Waar komt dat getal precies vandaan? En “alle bedrijven”? Dus ook de bakker op de hoek? Ik weet niet, 100% van de bedrijven waar ik mee te maken heb doen helemaal niets met virtualisatie…
Virtualisatie en performance
Stel klanten kiezen voor hosting met virtuele server en de leverancier mag daar vervolgens je installatie op uitvoeren. De hostingpartij gaat voor de lage kosten, maar geeft aan dat de hardware voldoet aan de specificaties.
De specificaties zijn echter gebaseerd op echte hardware en niet virtuele hardware in een van zijn vele verschijningsvormen.
Probeer in deze situatie maar eens een performance probleem op te lossen en een vinger te duiden naar de probleem veroorzaker. Het is een enorm risico dat je als klant neemt. De hardwareomgeving voldoet niet aan de specs en als de performanceproblemen niet toe te wijzen zijn aan een specifiek softwareprobleem dan ben je nog niet snel klaar!
Bedenk dus goed waar je aan begint en zorg in ieder geval dat je bij je key business applicatie de leverancier een gecombineerd voorstel laat maken waarin de software en (virtuele) hardware zijn meegenomen anders heb je niet 1 aanspreekpunt voor je problemen.
Voor OTA en migratie van een bestaande omgeving is virtualisatie echter een zegen. Het wachten is op goede benchmarks en virtualisatie voorschriften van Business applicatie leveranciers.. zonder specs op dit gebied ben je als klant een pionier.. de vraag is of je dat wil met je key business applicatie.?!
Kees Brussen
Crimsonwing Promentum
Dit is de aloude discussie tussen beheerders en ontwikkelaars. Ontwikkelaars willen de applicatie zo performant mogelijk maken. Beheerders willen de applicatie zo eenvoudig mogelijk beheren.
Virtualisatie maakt het beheren van de servers inderdaad eenvoudiger. Het probleem is echter dat “goed beheer” niet de core business is. Beheer staat altijd in dienst van productie. Dus als vitualisatie ten koste gaan van de performance dan moet je het niet doen.
Als de produktie applicatie verouderd is en alleen nog op een virtuele omgeving kan draaien, dan heb je geen keus. Maar ook dan mag het niet ten koste gaan van de performance, en indien nodig kan dit opgelost worden met een virtuele omgeving die op een vaste fysieke server draait.
Virtualisatie voor OTA is prima.
Beste Jan-Paul,
Met betrekking tot je opmerking over virtualisatie in kleinere omgevingen bij een HW storing. Ik denk dat het herstel (door een herstart van bijvoorbeeld een 8 tal VM’s) nog altijd veel sneller is dan herstel (op vervangende HW) van een fysieke server, voor zover dat laatste je al lukt. Dus m.i. geeft Virtualisatie ook in dat opzicht altijd een behoorlijke verbetering van de kans op herstel bij een storing. VMotion is overigens bedoeld voor loadbalancing van capaciteitsvraag binnen een groep van (gelijke) VMware servers en heeft weinig of niets te maken met High Availability (bescherming tegen uitval).
Nu de praktijk bij een klant van mij:
V??r virtualisatie: 600+ servers, 70 racks, 250KWatt
N? virtualisatie: 150 servers, minder dan 30 racks, minder dan 120KWatt
Natuurlijk moet je beheerprocessen aanvullen en/of aanpassen, maar dat laat onverlet dat er inmiddels talloze zeer succesvolle resultaten beschikbaar zijn die aantonen dat Virtualisatie de hype ver voorbij is. Alleen al uit het oogpunt van ons aller verantwoordelijkheid tot -waar mogelijk- terugdringen van CO2 uitstoot dient virtualisatie bovenaan het projectenlijstje te staan van elke IT organisatie die er nog niet mee gestart is.
Met vriendelijke groet,
Jan-Thijs de Feijter
Consultant The Unit
Beste Jan-Paul,
Grappig om te zien dat een zoekopdracht “performance problemen virtualisatie” ca 5 jaar na publicatie van dit artikel, nog steeds bovenin de zoekresultaten van Google komt. De meeste van jouw stellingen zijn vandaag de dag nog steeds van toepassing, hoewel de performance pijn aanzienlijk kan worden verzacht door de vele oplossingen die momenteel beschikbaar zijn. Denk aan Fusion I/O, Nimble, Violin, Whiptail maar ook wat de verschillende SAN leveranciers aan optimalisatie hebben gedaan.
Desalniettemin vind ik het schrijnend om vast te stellen, ca 15 jaar na introductie van de eerste Intel Hypervisors (VMware), dat de oorzaak van de performance problemen nooit is weggenomen t.w. een designfout in de Hypervisor. Immers alle componenten van de server zijn gevirtualiseerd, maar storage in het geheel niet. Omdat geen enkele Virtuele Machine (VM) ‘weet’ wat er in de externe SAN/Storage gebeurt en de SAN niet weet welke prioriteiten de individuele VM’s t.a.v. storage verzoeken heeft, vormt dit fenomeen oorzaak #1 van alle Performance Problemen in Virtuele Server omgevingen. Dat probleem wordt dus nog steeds ‘buiten’ de hypervisor opgelost, terwijl het zo voor de hand ligt om het in de front-end (Hypervisor) op te lossen.
Op dit moment lijkt het erop dat Virsto (zie http://www.virsto.com) de enige is die dit op deze manier aanpakt. Ben benieuwd hoe snel dit voorbeeld wordt gekopieerd.