Gepubliceerd: Donderdag 3 september 2009
Ondanks de grote verbeteringen die R2 van Hyper-V heeft ondergaan, qua functionaliteit blijft het ver achter bij VMware.
Toon volledig artikel
Dat ver achterblijven blijkt niet uit de rest van het artikel, dat doet dus een beetje raar aan hier.
Dat Vmware nog voorligt lijkt me duidelijk, maar de concurrentie zit ze op de hielen. Zowel XEN als HyperV hebben de achterstand voor een groot deel reeds ingehaald. De ontwikkelingen gaan snel!
Volgens Burton gaat het nog om drie punten: de mogelijkheid om herstarts van bepaalde VM's voorang te geven boven die van anderen, ondersteuning van tenminste twee vCPU's per guest en een fouttolerante beheerserver.
Kennelijk vind Burton de drie punten zo belangrijk dat ze het gemis typeren als "ver achter".
Maar je hebt gelijk, de concurrentie van Vmware zit niet stil. Over een poosje zullen de punten wel weggewerkt worden.
Wat nog sneller gaat is KVM. Houdt RedHat maar even in de gaten, want wat goed is komt snel. Redhat heeft Qumranet overgenomen.
Sommige stukken zijn (VDI tooling) nu nog op basis van windows only!, maar wordt dit jaar nog open source. SPICE protocol wordt/is open source
KVM werkt ook een stuk lekkerder stabieler dan VMWare of Xen. Voornamelijk omdat het een user-proces is onder linux ipv een dat een hyper-visor compartimenten probeert te switchen en dan in de tussentijd ook hardware probeert te virtualiseren, en de drivers in de main compartiment mogen er ook nog eens geen last van hebben...
Ik moet altijd wel lachen om stabiliteit van virtualisatieproducten.
Wij beheren VMware, Xen en Hyper-V voor klanten.
Elke maand is er wel een omgeving plat (en nee, niet onze schuld).
De paniek is groot, want alles draait hier dan op bij die klant.
Door virtualisatie creer je één grote "single point of failure" in je bedrijf.
En als je dan ook nog alles op een lekkere dure SAN hebt zitten, dan heb je nog een "single point of failure" erbij.
Je betaalt veel geld voor beiden (en bespaart natuurlijk op hardware en stroomkosten), maar dan heb je ook wat...
Vroeger had je alles verspreid over meerdere onafhankelijke servers en als er een probleem was met een server, dan was maar een beperkt gedeelte van de gebruikers getroffen.
De paniek is groot, want alles draait hier dan op bij die klant.
Door virtualisatie creer je één grote "single point of failure" in je bedrijf
Als dat zo is waarom dan virtueel (ik dacht dat juist de uptime daardoor verhoogt word)? (misschien een domme vraag maar toch graag een antwoord a.u.b.)
Elke maand een omgeving plat klinkt verschrikkelijk. Als ze echter 1000 klanten hebben valt het wel mee.
De keus qua beschikbaarheid is dat je minder afhankelijk bent van de koppeling tussen hardware en OS. Dus hardware stuk, OS start opnieuw op op de overige hardware.
Dat een SAN een single point of failure is, is niet waar. Die dingen zijn dubbel uitgevoerd (wanneer je daarvoor betaald). Dus ieder onderdeel an sich is zelfs geen SPOF. In de beredening dat een SAN een SPOF is, is het gebouw en de serverruimte ook een spof. Gebouw stuk, ICT stuk.
Virtualisatie bespaard op hardware (soms net niet, meestal wel) terwijl de beschikbaarheid toeneemt. Het kan echter wel stuk.
De aanbevolen oplossingen zijn verspreid over twee locaties. Kost wat maar dan heb je geen SPOF
Dat een SAN een single point of failure is, is niet waar. Die dingen zijn dubbel uitgevoerd (wanneer je daarvoor betaald).
De drive zijn raid 1, maar als er een probleem is met de onderliggende software dan gaat het ding ook plat.
Maar ik hoor het al: jullie hebben allemaal virtuele omgevingen die 100% uptime zijn (onderhoud niet meegerekend)?
De drive zijn raid 1, maar als er een probleem is met de onderliggende software dan gaat het ding ook plat
Ben je nu niet spijkers op laag water aan het zoeken? (gewone vraag)
Nee, ik ben gewoon eerlijk (maar het maar een mening van iemand die nu 13 jaar in IT werkt).
Virtualisatie is een modewoord, net zoals de SAN is.
Alles moet gevirtualiseerd worden en alles moet gemigreerd worden naar een SAN blijkbaar tegenwoordig.
In plaats van het risico spreiden over meerdere onafhankelijke servers moet nu alles draaien op één grote bak, die heel veel geld kost in aanschafkosten en supportcontracten.
Virtualisatie is een modewoord, net zoals de SAN is.
Alles moet gevirtualiseerd worden en alles moet gemigreerd worden naar een SAN blijkbaar tegenwoordig.
In plaats van het risico spreiden over meerdere onafhankelijke servers moet nu alles draaien op één grote bak, die heel veel geld kost in aanschafkosten en supportcontracten.
Dat idee heb Ik ook weleens! (En bedankt voor je reactie)
De aanbevolen oplossingen zijn verspreid over twee locaties. Kost wat maar dan heb je geen SPOF
Ik praat over bedrijven met een paar honderd medewerkers, dus een datacenter op twee locaties is veel te duur.
Ik moet altijd wel lachen om stabiliteit van virtualisatieproducten.
Wij beheren VMware, Xen en Hyper-V voor klanten.
Elke maand is er wel een omgeving plat (en nee, niet onze schuld).
De paniek is groot, want alles draait hier dan op bij die klant.
Door virtualisatie creer je één grote "single point of failure" in je bedrijf.
En als je dan ook nog alles op een lekkere dure SAN hebt zitten, dan heb je nog een "single point of failure" erbij.
Je betaalt veel geld voor beiden (en bespaart natuurlijk op hardware en stroomkosten), maar dan heb je ook wat...
Vroeger had je alles verspreid over meerdere onafhankelijke servers en als er een probleem was met een server, dan was maar een beperkt gedeelte van de gebruikers getroffen.
Juist met virtualisatie kun je dit soort problemen perfect (en goedkoop (inverhouding)) oplossen door een extra failover-omgeving te creeren...
Hyper V is ook niet gratis. Voor Hyper V heb je altijd nog een licentie voor Windows 2008 Server nodig. ;)
Maar je hebt wel de duurdere Windows licenties nodig. Alleen de standaard editie over hoger kan je als HyperV host gebruiken en dan mag je diezelfde licentie maar in 1 VM draaien. Voor iedere extra VM heb je een andere/extra licentie nodig. De enterprise editie mag je naast als host ook maximaal vier keer als guest installeren en pas bij de datacenter licentie is er geen beperking.
De enterprise editie mag je naast als host ook maximaal vier keer als guest installeren en pas bij de datacenter licentie is er geen beperking
De licentiebeperking van het OS met betrekking tot virtualisatie is niet gerelateerd aan je keuze van virtualisatiesoftware
Sorry hoor, maar als je voor 2 ton blade servers neer zet, wat maakt dan de aanschaf van wmware voor 10k nog uit. Dan heb je in ieder geval een fatsoenlijke oplossing, ten opzichte van de hardware investering verdien je die 23 keer terug.
10k is anders een hoop geld. Ik heb daar aardige bestedingen voor.
Je kan daar een mooie SAN met openfiler of freenas voor kopen.
Een tape library met CentOS is ook een leuke of een mooie auto etc.
Zo te horen hoef jij het dus niet uit eigen zak te betalen en geef je geld van een ander makkelijk uit.
Is het geheugenbeheeer van VMWare ook niet beter dan dat van de concurrenten? Als ik bijv 12 Gb in een server heb zitten waar van 2 GB voor het Host systeem (voor er commentara op komt, dit is fictief, rekent gewoon makkelijk), heb ik dus 10 Gb over voor de guests. Bij VMWare kan ik dan 5 guests installeren met 4GB Ram terwijl ik bij Xen 5 guests kan installeren met 2 GB. Is dit al achterhaald?
Overcommitten van resources is een vrijwel gegarandeerde weg richting flinke rampspoed. Virtualisatie kan heel handig zijn, maar gebruik het niet om te doen alsof je meer hardware in huis hebt dan er werkelijk in je serverhok staat. Je hele kaartenhuis dondert in elkaar bij een onverwachte piekbelasting, en op een of andere manier komen pieken vrijwel altijd onverwacht.
Er zit wel een rek in natuurlijk. Ik heb een ESX omgeving beheert war ik wel degelijk meer geheugen toegewezen heb dan er feitelijk in de machines zat. Je moet niet tot de grens gaan en dan is DRM ook handig. Ik heb graag de keus, en niet een "opgedwongen"limiet van de leverancier (goh, waar heb ik dat eerder gehoord :) )
Je mist het nut van ESX. Geheugen toegewezen aan een VM is niet gelijk geheugden dat weg is. ESX kan resources schakelen tussen VM's en je hebt bijna nooit een VM die *alle* resources in gebruik heeft.
Zo kun je gemakkelijk 4 VM's met elk 2 virtuele CPU's draaien op een machine met fysiek 4 CPU's. De kans dat alle 4 de cpu's allemaal tegelijk geclaimed komt in de praktijk weinig voor (ligt er natuurlijk aan wat de taken van je machines zijn).
En een beetje behoorlijk geconfigde server gebruikt vaak iets van 75% geheugen, stel je hebt 4 machines met 4 GB virtueel RAM, dan zou je dat op 12 GB fysiek kunnen draaien. (Al begint dat wel tricky te worden, hoor).
Maar d'r zit dus inderdaad wel wat speling op.
(Wat overigens wel funest is, is twee database servers met permanent gealloceerde bufferpools draaien op ESX. Stort echt helemaal in, tel daarbij de problemen met tick-timers op en je hebt een situatie waar 3 of 4x per week een offline DB hebt.(gelukkig is het een test omgeving))
Complete side track: Ik wou dat de problemen met VMWare ESX + Linux mbt. de tick-timer eens zouden verdwijnen.
VMware VSphere zit direct op de hardware. Hyper-V heeft altijd domein-0 als onderlaag. Ik betwijfel of Microsoft die hindernis weet weg te werken...
Hyper-V zit (bij mijn weten) ook direct op de hardware. Het OS wat je ziet (windows) is ook al gevirtualiseerd.
Hyper-V draait op Windows Server 2008. Dat is domein-0. Vsphere is de hypervisor die als dunne laag op de hardware zit. Daar zit ook het grote verschil in benadering en in performance.
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
