Onderwerp: voordeel van KVM en opzichte van chroot

In een productie omgeving heb ik nu een server staan waarop een aantal chrooted progamma's draaien.

- Squid
- Apache
- Pound

Deze omgevingen zou ik zelf willen migreren naar een KVM oplossing ipv een chrooted oplossing. Ik heb namelijk het idee dat een KVM oplossing veiliger is dan een chrooted omgeving.
Verder maakt het het beheer een stuk gemakkelijker, het is dan namelijk mogelijk om een VPS op te pakken en later op een andere server te plaatsen (mocht dat nodig zijn).

Verder heb ik mijn twijfels bij het draaien van squid in een gevirtualiseerde oplossing, kan KVM goed overweg met kleine ethernet pakketjes?

Oorspronkelijk geplaatst door asusk7m550

Verder maakt het het beheer een stuk gemakkelijker, het is dan namelijk mogelijk om een VPS op te pakken en later op een andere server te plaatsen (mocht dat nodig zijn).

Dat is inderdaad 1 van de grote voordelen.

Verder heb ik mijn twijfels bij het draaien van squid in een gevirtualiseerde oplossing, kan KVM goed overweg met kleine ethernet pakketjes?

Jahoor, geen enkel probleem, wij draaien nameservers (recursor en auth) binnen KVM omgevingen en ik denk dat die nog kleinere pakketjes gebruikt.

Wij hebben KVM in productie draaien en de performance van KVM is zeer goed, ook met kleinere packets. Wel is het zo dat je natuurlijk veel meer overhead hebt ten op zichte van chroot, al is het alleen maar omdat je extra Linux kernels gaat draaien enzo. Maar zolang de huidige server nog lang niet op z'n max zit, hoef je geen merkbaar verschil in performance te verwachten.

En vergeet daarbij dan ook niet om VirtIO te gebruiken voor je disken en NIC's, dat scheelt ook nog een stuk in je I/O.

Welke distributie was je van plan te gebruiken? RHEL5 (Vanwege je sig gok ik RHEL) heeft volgens mij al wel KVM, maar de meeste recentere kernels hebben een stuk betere VirtIO ondersteuning, die zijn dus wel aan te raden.

Het wordt waarschijnlijk Debian 5.0. Gelukkig ben ik van alle markten thuis .

Kun je dan niet beter voor Ubuntu 10.04 LTS kiezen, of zijn er redenen dat Ubuntu geen optie is? De KVM versie in die Ubuntu is een stuk recenter en daarmee is de performance en stabiliteit ook veel beter. En je hebt gewoon lange ondersteuning, waarschijnlijk zelfs langer dan Debian 5.

Ubuntu is zeker ook een alternatief. Hoewel de Debian releases naar mijn idee toch iets stabieler zijn dan de ubuntu LTS versies.

Tevens zal Debian 6 binnenkort uitkomen en waarschijnlijk recentere software dan Ubuntu 10.04.

Over de ondersteuning heb je zeker gelijk. 1 jaar ondersteuning nadat de volgende versie released is, is zeker niet wenselijk.

Het eerste wat mij te binnen schoot is ook de overhead. Dit is geen grote issue als de CPU's de virtualisatie goed ondersteunen en voldoende cores en memory aanwezig zijn. Dat neemt de overhead niet weg uiteraard maar maakt de impact wel minder merkbaar. Misschien dat het zelfs zo is dat er beter met meerdere cores wordt omgesprongen dan wanneer een chrooted omgeving ingezet wordt, maar dat is een aanname van me, dit zou je moeten testen.

Oorspronkelijk geplaatst door Magus

Het eerste wat mij te binnen schoot is ook de overhead. Dit is geen grote issue als de CPU's de virtualisatie goed ondersteunen en voldoende cores en memory aanwezig zijn. Dat neemt de overhead niet weg uiteraard maar maakt de impact wel minder merkbaar. Misschien dat het zelfs zo is dat er beter met meerdere cores wordt omgesprongen dan wanneer een chrooted omgeving ingezet wordt, maar dat is een aanname van me, dit zou je moeten testen.

Met een goede moderne server denk ik dat je in beide gevallen eerder de I/O limiet zult halen dan de CPU/RAM limiet. Helaas is het van te voren lastig te bepalen op welk moment je die limiet precies zult bereiken (CPU/RAM is beter te voorspellen/bepalen).

Oorspronkelijk geplaatst door Mark17

Met een goede moderne server denk ik dat je in beide gevallen eerder de I/O limiet zult halen dan de CPU/RAM limiet. Helaas is het van te voren lastig te bepalen op welk moment je die limiet precies zult bereiken (CPU/RAM is beter te voorspellen/bepalen).

Bij onze clusters merken we inderdaad dat altijd de I/O limiet als eerste wordt bereikt. Grootste probleem is gewoon altijd random I/O, of je moet SSD's pakken, maar zelfs dat is niet zaligmakend. Dus hoe meer VM's aan het rammen zijn op je storage, hoe eerder je problemen zult krijgen.

Het is wel zo dat bij KVM de host ook schijfcaching doet. Dus hoe meer geheugen er vrij is op de hosts, hoe meer cache er kan worden gebruikt. Ga je dan op de host meer VM's plaatsen, dan zul je automatisch ook meer I/O krijgen en dat zal het geheel ook weer meer vertragen.

Al met al is het dus inderdaad lastig te zeggen

Dick, voor de linux vms kun je de access time voor zowel de dirs als files uit zetten. Dit scheelt twee handelingen op je filesystem als een file opgevraagd wordt.

Oorspronkelijk geplaatst door Mikey

Dick, voor de linux vms kun je de access time voor zowel de dirs als files uit zetten. Dit scheelt twee handelingen op je filesystem als een file opgevraagd wordt.

Klopt, zo zijn er nog wel wat kleine dingetjes die je kunt tunen, zoals de keuze voor een andere I/O scheduler op de gastsystemen. Alsnog zien wij dat over het algemeen je I/O de limiet gaat zijn en niet je CPU.