Is een VPS eigenlijk echt nuttig voor de klant?

[Trimmer]

Wij hebben in het verleden vaker enkele VPS'en ingesteld voor klanten met VMWare ESX, ESXi en met XEN. De laatste configuratie was op een dual quad core met 64Gb RAM met zo'n 6 VM's.

Toch kwamen wij telkens opnieuw terug van VM's omwille van performance.
Als een klant echt wat van het systeem wil benutten (bv een drukke website of een drukke DB server) dan gaat zo'n VM toch echt wel traag, veelal te traag.

De vraag is dus of jullie je VM's echt belasten, of dat jullie niet zo'n problemen ervaren?

Ik lees vaak dat men "near bare metal" performance haalt, maar dat is volgens mij toch ook enkel in de veronderstelling dat er slechts 1 VM draait en niet met real-world load?

[oehTie]

ik draai hier tussen de 8 en 24 vpssen per node. Op allemaal haal ik zeer goede performance. Near-bare-metal is de ultime situatie en daar zit ik niet ver onder. Als je echt heavy loaded sql servers gaat draaien denk ik dat een vm inderdaad niet optimaal is maar voor 20 webservers die allemaal een paar medium/kleine database-jes draaien is het geen enkel probleem.

[Spyder01]

Die performance problemen kom ik niet tegen met ESX(i). Het grootste probleem van traagheid is de disk I/O.

Met SAS schijven, voldoende geheugen en een goede (dual) Quad Core processor kun je probleemloos een aantal zware VM's draaien. Met S-ATA schijven ga je naarmate het aantal VM's toeneemt steeds meer performance problemen zien.

[Trimmer]

De laatste machine die ik beschreef was een RAID10 van 8 X25-E SSD's, dus ik denk niet dat de I/O een probleem was maar dat wij gewoon te zware dingen proberen in een VM?

[Spyder01]

De laatste machine die ik beschreef was een RAID10 van 8 X25-E SSD's, dus ik denk niet dat de I/O een probleem was maar dat wij gewoon te zware dingen proberen in een VM?

Wees eens wat exacter dan in wat je er op draaide, we hebben hier ook een applicatie in een VM draaien die zo`n 10.000 connecties per 5 minuten krijgt en daarbij een complete DB doorspit en informatie dumpt.

[Jesperw]

Ik herken me er niet echt in, maar het klinkt alsof je ergens een bottleneck hebt. We hebben op ons platform (dat bestaat uit 20 nodes) ook vaak een flink aantal VM's op een node, want er zij toch genoeg resources.

Daarbij draaien ook loadbalanced omgevingen met 500.000 bezoekers per dag voor grote bekende websites, terminal servers voor windows automatiseerders, zware database servers, enzovoort.

Toen we net begonnen dacht ik dat ik geen zware dingen op VM's moest gaan doen, maar daar dat bleek absoluut niet zo. Sterker nog, we bieden geen fysieke servers meer aan tenzij daar een hele goede reden voor is.

[rackhost.be]

het klinkt alsof je ergens een bottleneck hebt

de programmeur?

[Jesperw]

de programmeur?

Da's de meest voorkomende bottleneck in ieder geval

[Piwi-Web]

Da's de meest voorkomende bottleneck in ieder geval

En die zegt weer dat het aan de infrastructuur ligt En dan krijg je een wellus/nietus verhaal

[The-BosS]

De grootste reden die de meeste vergeten waarom veel dingen virtueel gedraaid worden is stroom verbruik. En je kan zelf zo zwaar gaan als je wilt in virtuele servers die je als dedicated niet zou kunnen, bvb volledige blade's tegenover clusters. Waar nij grote bedrijven vroeger 2 racks clusters stonden staat nu 1 bladeserver met 10 blades (dual quad cores), dit zal dus wel een reden hebben. Vergeet ook niet dat Microsoft zelf meer en meer virtueel begint te werken, al was het maar voor de HA die je bij gewoon dedicated niet hebt, tenzei met loadbalancer en extra kosten etc. Verder snap ik je redenering niet goed als ik zie dat bedrijven als Oracle en SAP hun infrastructuur zelf ook virtueel beginnen op te bouwen, en dit zijn niet de minste bedrijven kwa database verwerking.

Een bottleneck zal er altijd blijven bestaan is het niet de raid controller dan zijn het de harddisks of de netwerkkaart of de ... er zal wel altijd iets trager en vlugger zijn dan het ander, het is alleen de vraag hoe goed van je dit zelf op.

[aristo]

En die zegt weer dat het aan de infrastructuur ligt

En in de combinatie ligt dus de oplossing: Laat programmeur, systeembeheerder en gebruiker intensief samen aan het probleem werken.
Is het de VPS (wat ik niet denk) pak je dat aan. Maar meestal zal het een stapeling van kleine zaken zijn. Dingen die elk op zich niet zo'n probleem zijn, maar samen de zaak vast laten lopen.
En dat is dus niet altijd een kwestie van techniek, maar een kwestie van coaching en management.

Veel succes, vrgr Eef

[Jesperw]

En in de combinatie ligt dus de oplossing: Laat programmeur, systeembeheerder en gebruiker intensief samen aan het probleem werken.

Precies. Ik merk dat wij ook steeds regelmatiger code zitten te debuggen voor klanten als er performance problemen zijn. Dan kom je van die dingen tegen als eenvoudige websites die eerst een paar miljoen records binnen halen in PHP en er maar 1 laten zien. Geheugen vol, netwerk vol, bam.

[Trimmer]

Wees eens wat exacter dan in wat je er op draaide, we hebben hier ook een applicatie in een VM draaien die zo`n 10.000 connecties per 5 minuten krijgt en daarbij een complete DB doorspit en informatie dumpt.

Hoofdzakelijk websites, maar wel websites die heel druk zijn en veel van een DB vragen. Toch snel 1000 DB requests / sec of zelfs meer. Als webserver gebruikte we litespeed omdat apache te veel ram nam en we het ram in de VM's relatief beperkt hielden. (Doch, voldoende om MySQL te plezieren hoor)

[Trimmer]

Ik herken me er niet echt in, maar het klinkt alsof je ergens een bottleneck hebt. We hebben op ons platform (dat bestaat uit 20 nodes) ook vaak een flink aantal VM's op een node, want er zij toch genoeg resources.

Daarbij draaien ook loadbalanced omgevingen met 500.000 bezoekers per dag voor grote bekende websites, terminal servers voor windows automatiseerders, zware database servers, enzovoort.

Toen we net begonnen dacht ik dat ik geen zware dingen op VM's moest gaan doen, maar daar dat bleek absoluut niet zo. Sterker nog, we bieden geen fysieke servers meer aan tenzij daar een hele goede reden voor is.

Toch vreemd dat wij het hier keer op keer wel opmerken. Anders voorbeeld: als je nu een Windows Server 2008 op een server plaatst en dan via remote desktop werkt. Dan gaat dat redelijk vlot allemaal, maar als je de Windows Server 2008 in een VM plaatst, en dan via remote desktop werkt, merk jij het verschil dan niet? Want ik voel het verschil in responsiveness altijd, zelfs al draait er slechts 1 VM op de server (die windows dus) en die is dan zelfs idle.

Ik merk het altijd omdat de responsiveness net iets trager is dan wat ik gewoon ben. Het went wel hoor maar het is net wat trager.

[gjtje]

Nee, ook dat merken we niet.
We gaan hier zelfs alle fysieke terminal servers vervangen door virtuele machines, zeker omdat er nog veel 32bit machines nodig zijn voor TS en het enorm inefficiënt is dat je hardware hebt hangen waar je maar 4GB ram in kan duwen.

De snelheid van de UI in RDP is wel vaak gelinkt aan de snelheid van disk io heb ik gemerkt, ook al is het niet veel, er wordt eventjes iets met de disks gedaan.