Onderwerp: Schaalbaarheid/prestaties VPS's

VPS/VDS: Er wordt gesproken over gegarandeerd geheugen en CPU snelheid. Even voor alle duidelijkheid. Hoe kan je het beste de specs berekenen die voor je fysieke server nodig zijn?

Processoren zijn beperkt, maar ik wil wel kwalitatieve diensten bieden en dus bijv. minimaal een 2,8 Ghz. virtuele server aan kunnen bieden (als voorbeeld). Ik wil bijvoorbeeld minimaal 5 VPS servers draaien op de fysieke server, maar 5 x 2,8 Ghz. bestaat niet, dus begrijp ik het goed als de volledige CPU snelheid wordt verdeeld over die 5 VPS's? Tenminste, dat zou niet anders kunnen. Maar, heb je dan wel een 'echte virtuele' (sorry voor de term ) server met een 2,8 Ghz. processor?

Is dat ook precies zo bij het geheugen? Of moet het geheugen wat je over de 5 VPS's wil verdelen dan weer wel daadwerkelijk aanwezig zijn? Als je 2 Gb. gegarandeerd wil hebben op elke VPS (omdat je dat zelf wil, of omdat de klant dat wil en voor betaald), moet je dan in percentages het geheugen verdelen, of moet je dus die 5 x 2 Gb. = 10 Gb. in de fysieke kast hebben zitten? Kan dat trouwens? Even om het helder te krijgen... En over de harddisk ruimte hetzelfde.

Bij voorbaat dank.

Niet iedereen zal alles constant belasten, echter er is een kans dat op een moment er meer vraag is dan er beschikbaar is. Het zal een balans vinden zijn tussen die twee. Je kan niet garanderen dat er zoveel MHz beschikbaar is, doe je dit wel dan zal je inderdaad 5x2.8GHz moeten verzorgen.

Verschillende VPS implementaties staan overselling van RAM toe, anderen weer niet. In tegenstelling tot CPU zie je dat ram veel eerder vol gebruikt wordt, bijvoorbeeld voor caching.

Hoi,

Een virtuele server biedt een aantan voordelen die de host heeft. Je host moet immers zegge 8x zoveel data verwerken en heir dien je rekening mee te houden. De eerste bottleneck is dan ook je disk i/o. Gebruik dus een raid-5 array over minimaal 4 disks. Bij voorkeur SAS, maar Raptors doen het ook goed.

Zelf leveren wij uitsluitens managed servers en houden voor iedere VPS 1 core aan. Een dual Xoadcore Xeon bevat in ons geval dus 8 VM's. Je moet dus ook het geheugen hebben voor deze machines, al kost DDR2 geen drol gezien de dollarprijs. En voor geheugen geldt al jaren: hoe meer hoe beter.
Hier heb je meteen een probleem te pakken: 32 bits systemen doen het niet lekker met > 4 Gbyte geheugen. Draai je host dus op 64 bits om alles te kunnen adresseren zonder rare kernelpatches.

Overigens kun je ook makkelijk 16 VM's kwijt op de machines die wij gebruiken, zelfs 3 per core zou kunnen. Het ligt net aan de toepassingen die je gebruikt. Wij verkiezen echter een vaste core voor elke VM.

Verder _nooit_ overboeken op geheugen (zommige software laat dit helaas toe). En zorg dat iedere VM genoeg geheugen heeft. Je draait geen LAMP-DA-installatie op 128 Mb. Want dan krijg je weer een probleem dat de /swap te intensief gebruikt wordt en je disk-array is het traagste gedeelte in de server. Het ene hangt dus weer aan het andere.

Onze hosts:
Dual Quadcore XEON, Intel 5335LV (8x 2 Ghz.)
8 of 16 Gbyte DDR2 geheugen. FB of ECC
4x 146 Gbyte SAS disks in RAID-5. 15.000 RPM

Op deze configuratie draaien dus 8 VM's.

Oorspronkelijk geplaatst door Randy

8 of 16 Gbyte DDR2 geheugen. FB of ECC

Verder niet erg relevant, maar geheugen kan niet "FB of ECC" zijn - het zijn twee totaal verschillende dingen.

Oorspronkelijk geplaatst door Randy

Hier heb je meteen een probleem te pakken: 32 bits systemen doen het niet lekker met > 4 Gbyte geheugen. Draai je host dus op 64 bits om alles te kunnen adresseren zonder rare kernelpatches.

Dat is onzin. Uiteraard, je moet wel de juiste kernels gebruiken, maar om te stellen dat een 32-bit kernel "niet lekker draait" met meer dan 4GB ram is onzin.

Dat is niet volledig onzin. Met 32Bits kan je aan 1 thread nooit meer dan 4GB geheugen addresseren.

Daarom is 64Bits toch zeker wel aan te raden bij grote hoeveelheden geheugen. Ik snap ook niet waarom je uberhaupt nog 32Bits zou willen draaien?

Oorspronkelijk geplaatst door Wido

Dat is niet volledig onzin. Met 32Bits kan je aan 1 thread nooit meer dan 4GB geheugen addresseren.

Daarom is 64Bits toch zeker wel aan te raden bij grote hoeveelheden geheugen. Ik snap ook niet waarom je uberhaupt nog 32Bits zou willen draaien?

Net alsof je in een virtualisatie omgeving ooit een situatie hebt waarin 1 thread meer dan 4gb geheugen zou gebruiken.. Daarnaast heeft dat ook niets te maken met "niet lekker draaien".

Oorspronkelijk geplaatst door Apoc

Net alsof je in een virtualisatie omgeving ooit een situatie hebt waarin 1 thread meer dan 4gb geheugen zou gebruiken.. Daarnaast heeft dat ook niets te maken met "niet lekker draaien".

Ja, een database-server die 8GB geheugen krijgt toegewezen?

Ik zeg niet dat het vaak voor komt, maar het kan! De TS is er nu in ieder geval op gewezen

32Bits met PAE werkt prima, alleen zou ik het zelf nooit draaien.

Bedankt voor de heldere antwoorden.

Ik denk ook dat de ervaring zal moeten uitwijzen wat de 'ultieme' VPS configuratie is, maar ik ben toch wel voorstander om alles wat ruimer te nemen en zelfs een buffer te houden voor onverwachte momenten. Achteraf is een probleem meestal heel handig te verklaren, maar voorkomen is beter dan genezen en klanten te verliezen, denk ik dan.

Ik heb op dit moment een klant die 10 Gb. bandbreedte heeft gebruikt tot nu toe in deze maand, in een resellerpakket, naast andere klanten dus. Ik heb er nog geen goed gevoel over om dit resellerpakket om te zetten naar een VM.. Of heb ik dat helemaal mis? Complete resellerpakketten omzetten naar een VM.. lijkt me nog lastig te overzien, omdat veel verschillende klanten ook voor uiteenlopende cijfers kunnen zorgen op het gebied van dataverkeer en bandbreedte. Hoewel.. je kan natuurlijk de gemiddelden van de laatste maanden/jaar er op naslaan om de groei vast te stellen, alleen lijkt me dat met een VM toch net weer even een belangrijker iets. Zou je het aantal klanten kunnen voor een VM ook eigenlijk op basis van schijfruimte en bandbreedte kunnen plaatsen?

Wat heb je overigens naast je VM's aan extra specs nodig op de fysieke machine? Dus niet om een buffer te houden, maar om alles aan te sturen en te draaien?

In jouw situatie heb je 1 voordeel: de user is geisoleerd. Als zijn server brakke scrips heeft en onder attac ligt, heeft de rest van de resellers er geen last van.

Oorspronkelijk geplaatst door Randy

In jouw situatie heb je 1 voordeel: de user is geisoleerd. Als zijn server brakke scrips heeft en onder attac ligt, heeft de rest van de resellers er geen last van.

Ja, als je er voor kiest om die ene klant een eigen VM te geven. Maar het is ook niet uitgesloten om een heel resellerpakket in één VM te plaatsen, nietwaar?

Uiteraard is dit niet uitgesloten
Je vergroot je overhead wel een beetje waarschijnlijk, vaak zal een VM immers eigen services draaien, maar qua security en resourcelimits ga je weer een stuk vooruit.

Misschien nog wel intressant om te behandelen hoe doen jullie dat als zeg, de VM te klein geworden is voor de klant. hoe upgrade jullie die VM ? naar hogere specs ?

Oorspronkelijk geplaatst door RSDD

Misschien nog wel intressant om te behandelen hoe doen jullie dat als zeg, de VM te klein geworden is voor de klant. hoe upgrade jullie die VM ? naar hogere specs ?

Meer geheugen kun je zo toekennen. De disksets zijn in LVM dus die kun je ook vrijwel realtime vergroten. Extra cores toekennen aan een VM is ook geen probleem. Desnoods swappen we realtime naar een andere host.

Oorspronkelijk geplaatst door Randy

Meer geheugen kun je zo toekennen. De disksets zijn in LVM dus die kun je ook vrijwel realtime vergroten. Extra cores toekennen aan een VM is ook geen probleem. Desnoods swappen we realtime naar een andere host.

Dit is op basis van XEN ?

We gebruiken XEN (ent) en VMWare ESX met VMotion. Ligt een beetje aan de wensen van de klant.