Virtualisatie moet efficiënter

Gepubliceerd: Maandag 11 augustus 2008

Virtualisatie op basis van volledige virtuele machines is inefficiënt. Het domweg kopiëren van complete besturingssystemen kost te veel geheugen.

Toon volledig artikel

Anonymous Coward op Maandag 11 Augustus 2008 18:46

hmm, op het gevaar af weer een hoop onbegrip over me af te roepen het volgende.

Memory Overcommit is geen "goede feature" maar een simpele methode om te doen alsof er meer geheugen aanwezig is dan er daadwerkelijk beschikbaar is. In de hoop dat er meer geheugen beschikbaar komt geeft het systeem alvast toegang. In een tijd dat oude hardware geschikt moest worden gemaakt voor nieuwe software deed Linux daar goede zaken. meestal werkte het. Linux kon op die wijze gebruik maken van feitelijk niet bestaande systeembronnen.
Er is echter een groot nadeel, als er onvoldoende geheugen beschikbaar is dan kikt het systeem er een proces uit. Er zijn wel allerlei hulpmiddelen bedacht ( OOM killer) om grote problemen te voorkomen maar onderstaande anekdote blijft feitelijk nog steeds gelden.

An aircraft company discovered that it was cheaper to fly its planes with less fuel on board. The planes would be lighter and use less fuel and money was saved. On rare occasions however the amount of fuel was insufficient, and the plane would crash. This problem was solved by the engineers of the company by the development of a special OOF (out-of-fuel) mechanism. In emergency cases a passenger was selected and thrown out of the plane. (When necessary, the procedure was repeated.) A large body of theory was developed and many publications were devoted to the problem of properly selecting the victim to be ejected. Should the victim be chosen at random? Or should one choose the heaviest person? Or the oldest? Should passengers pay in order not to be ejected, so that the victim would be the poorest on board? And if for example the heaviest person was chosen, should there be a special exception in case that was the pilot? Should first class passengers be exempted? Now that the OOF mechanism existed, it would be activated every now and then, and eject passengers even when there was no fuel shortage. The engineers are still studying precisely how this malfunction is caused.

In de opeenvolgende Linux kernels zijn stees dfiepgaander aanpassingen gemaakt om de grootste nadelen tegen te gaan en om de belangrijkste misdragingen te voorkomen maar de feitelijke achitecturele fout blijft m.i gewoon bestaan en zal uiteindelijk ook tot structurele aanpassingen moeten leidden. Gezien het feit dat de huidige generatie hard en software moeiteloos grote hoeveelheden geheugen aan kan en gezien het grote aantal ontwikkelaars zal dit ongetwijfeld opgelost worden. In gevirtualiseerde omgevingen zijn echter voor met name XEN grote problemen te verwachten met de huidige insteek vrees ik.

4 / 8

Anonymous Coward op Maandag 11 Augustus 2008 19:41

Dit is inderdaad een issue dat lange tijd in Linux gezeten heeft, en er zover ik weet nog steeds in schijnt te zitten (of is het inmiddels verholpen?). Ik heb er alleen nog nooit iets van gemerkt. Is er een testscenario bekend om Linux te dwingen een 'passagier' uit het 'vliegtuig' te knikkeren? Ik zou dat wel eens willen zien gebeuren namelijk, puur uit interesse.

Verder geeft het artikel me het kriebelige gevoel dat we het wiel opnieuw aan het uitvinden zijn. Hadden de mainframes die we in de jaren '80/'90 allemaal vervingen dit niet al lang grotendeels allemaal opgelost? Helaas heb ik er zelf nooit mee mogen werken, maar dat ging toch ook over het partitioneren van een groot systeem en het dynamisch toekennen van resources? Dat PC's dit nu ineens ook allemaal maar moeten kunnen, had ik lachwekkend gevonden als het niet zo serieus werd genomen. De x86-architectuur, inclusief x86-64, is helemaal niet bedoeld om te virtualiseren. Daar zijn betere kandidaten voor zoals de IBM zSeries, maar die worden verkocht als mainframes en zijn qua imago natuurlijk niet Web2.0 genoeg.

3 / 3

Anonymous Coward op Maandag 11 Augustus 2008 19:50

Op mezelf reageren is misschien niet zo fraai, maar je kunt dit in Linux 2.6 aan/uitzetten met een sysctl. Als volgt:

sysctl -w vm.overcommit_memory=2

Weer wat geleerd vandaag! ;-)

3 / 3

Anonymous Coward op Maandag 11 Augustus 2008 19:56

klopt die optie is ook toegevoegd om specifieke problemen te voorkomen. Door de lage prijzen voor memory was het gebruik om dat verder uit te breiden waardoor de OOM killer weinig werk had. In virtuele omgevingen neemt het memorygebruik sterk toe waardoor dit soort afwegingen ineens weer actueel worden.

Een korte google zoektocht naar OOM killer problemen en Memory overcommitt zorgt al snel voor erg veel probleem meldingen. Het is dus nog steeds een issue.

0 / 4

RobSanders op Maandag 11 Augustus 2008 19:43

Ik kan het alleen maar met je eens zijn. Memory overcommit lijkt een goed principe, totdat je de resources nodig hebt. In die zin in is DRS van VMware een (geavanceerd) lapmiddel om het probleem tegen te gaan.

0 / 4

Eric_ op Maandag 11 Augustus 2008 21:45

Nou wordt hier toch fatsoenlijk gediscussieerd, waarom zijn er nou van die druiloren die alleen maar minnen kunnen uitdelen. Probeer dan eens zelf een "bijdrage" te brengen die ook aansluit op het onderwerp.

@SED: Die vergelijking met vliegtuigpassagiers is erg goed. Had die nog nooit ergens gelezen.

2 / 6

Bolleke op Maandag 11 Augustus 2008 22:47

Het is zeker een goede discussie, maar ik ben het niet eens met de standpunten en anekdote van SED :)

Namelijk: wat is het alternatief? De vergelijking gaat namelijk op 1 punt heel erg mank, en dat is toevallig de eerste zin. (Nou ja, eigenlijk niet toevallig waarschijnlijk, maar dat terzijde ;)). In noodgevallen (lees: onvoldoende geheugen /en/ swap space) kan het noodzakelijk zijn dat er processen worden afgeschoten. Waarom? Om het systeem draaiende te houden. Liever een draaiend systeem dan geen systeem, tenslotte. Tenminste, dat is de onderliggende gedachte. Als dat niet zou gebeuren zou het systeem crashen en zou helemaal niks meer draaien. Is dat dan wat je zou willen?

Je kunt wellicht tegenwerpen dat het beter zou zijn als het OS niet op die manier resources zou toewijzen. Tja, wellicht. Dan gaan we terug naar de oude C-dagen waar elke applicatie zelf verantwoordelijk was voor z'n geheugen. Mooie tijden, maar al snel onpraktisch als je veel apps hebt die zich misschien niet allemaal even netjes gedragen.

Over welke processen je wel en welke je niet kunt afschieten kun je hele discussies voeren, maar het komt in feite neer op waar een machine voor gebruikt wordt. Een overbelaste server zal met liefde apache-procesjes afschieten als die het probleem veroorzaken (dDos aanval), maar zal z'n ssh-daemon laten draaien zodat de admin erbij kan om het op te lossen. Een desktopmachine zal b.v. een achterlijk groot plaatje dat in The Gimp wordt ingeladen en die het probleem lijkt te veroorzaken eerder killen dan wat idle openstaan OOo instanties met wellicht onopgeslagen werk. Ik zie het probleem niet zo, al zal het vast eleganter kunnen als je het vanaf de grond kunt opbouwen.

Los daarvan heeft dit verder 0,0 te maken met het topic: hoe zorg ik dat gedeelde Dll's in mijn VM's van XP home, pro en Vista ook echt gedeeld worden? Of de gelijke stukken van een Debian en Ubuntu VM? Want daar zou hem de winst in kunnen zitten. VMWare maakt images die in feite 1 grote blob zijn, en dat is als je het intensief toepast inderdaad inefficient.

3 / 3

Anonymous Coward op Maandag 11 Augustus 2008 23:46

Ik begin me af te vragen of de overcommit van VMWARE dezelfde is als de overcommit van Linux.

Als ik meer diepgaande artikelen lees dan lijkt het erop dat VMWare het aantal beschikbare VM's binnen een bepaalde geheugenruimte poogt uit te breiden met een soortgelijk mechnisme alsook Linux gebruikt: overcommit. Het gaat dan uit van de gedaxchte dat niet alle VM's tegelijk volledig actief zijn en is feitelijk een aanvulling op het gegeven dat een VMware server vaak 1 op 10 tot 1 op 15 keer meer VM draait dan fysieke servers die vervangen zijn.
( al is daar heel wat marketing taal bij)

Het overcommit gegeven van Linux is een aanpassing van hoe een unix systeem werkt, door op ale vragen naar geheugen "'ja"" te antwoorden. Unix heeft daar een veel beter uitgewerkte oplossing voor

a user-space program reserves (virtual) memory by calling malloc(). If the return value is NULL, the program knows that no more memory is available, and can do something appropriate. Most programs will print an error message and exit, some first need to clean up lockfiles or so, and some smarter programs can do garbage collection, or adapt the computation to the amount of available memory. This is life under Unix, and all is well.

Feit is dat bij hoog geheugen gebruik de overcommit tegen de fysieke grenzen aan loopt en dan moet ingrijpen. Dat kan onder linux alleen door een kill van een proces te forceren ( en onder diverse kernel varianten gaat dat dan ook nog eens zonder enige waarschuwing)Daarvoor is de OOM killer in het leven geroepen, met als bijverschijnsel de anecdote die ik hierboven al aanhaalde.
VMWare heeft een totaal pakket van maatregelen die dat moeten voorkomen. ( zie bronartikel bijv) Het lijkt erop dat men daarvoor het begrip overcommit gebruikt in een iets andere context. Al zijn de gevolgen sterk overeenkomstig .

0 / 2

Bolleke op Dinsdag 12 Augustus 2008 20:19

Als ik meer diepgaande artikelen lees dan lijkt het erop dat VMWare het aantal beschikbare VM's binnen een bepaalde geheugenruimte poogt uit te breiden met een soortgelijk mechnisme alsook Linux gebruikt: overcommit.
Dat is niet hoe ik het begrijp. Het idee is vlgs mij dat je niet voor elke VM een afgebakende BLOB hanteert, maar deelt wat gedeeld kan worden. Als jij b.v. 5 WinXP VMs draait op 1 machine kun je allerlei DLL's best delen (simpel voorbeeld).
This is life under Unix, and all is well.
Dat is veel te simpel. Dit gaat ervan uit dat elk programma zelf verantwoordelijk is voor z'n geheugen - common practice toen iedereen nog in C of zelfs assembler schreef, maar tegenwoordig not done meer. Het idee is dat je het OS laat bepalen of er nog geheugen is of niet. Daarom hebben OSen ook swap space: dat is voor als de overcommit het verkeerd heeft ingeschat. Je hebt gewoon een pool geheugen (zeg 1GB) en daaruit kun je als applicatie putten. Natuurlijk is het dom programmeren als je ervan uitgaat dat je die hele gig voor jezelf gaat hebben, maar soit. Als het op is gaat het OS swappen, daar hoeft de applicatie zich niet meer druk om te maken.
Er is pas een probleem als je /ook/ geen swap space meer hebt. Tja, dan moet het OS een keuze maken: BSOD of iets killen? Wat zou jij doen?

(Hint: zo werkt Windows ook. Al kiest die iets vaker voor de BSOD :P)

0 / 0

Phoenix op Maandag 11 Augustus 2008 22:01

Voor de volledige scheiding van applicatie's op 1 machine heeft VMware waarschijnlijk ook de technologie van THinstall gekocht, een stap in de goede richting.
(Link & Info: www.thinstall.com)

2 / 2

wniehof op Dinsdag 12 Augustus 2008 09:29

Thinstall (hernoemd door VMware tot Thinapp)is niet vergelijkbaar als hoe bijvoorbeeld Parallels dit aanpakt.
Met Thinapp zal je ook bijvoorbeeld (voorlopig in ieder geval) geen Exchange of SQL kunnen virtualiseren op een OS.

Het gaat hier meer om het virtualiseren van gebruikers applicaties.

Verder ben ik het in grote lijnen zeker met het artikel eens. Bij hypervisor oplossingen is het onlogisch om iedere keer een geheel nieuw OS te moeten draaien per machine. Dit neemt niet alleen extra resources in beslag maar zal ook beheerd moeten worden.
Echter gaat virtualisatie de laatste wel iets verder dan pure consolidatie en het draaien van zoveel mogelijk (virtuele) machines op een stuk hardware. Het gaat ook om portabiliteit van virtuele machines, denk bijvoorbeeld aan virtual appliances of VDI waarbij de virtuele desktops ook offline (lokaal) kunnen draaien.