Virtuozzo vs. Xen?

Bachsau

Member
Leutz, ich bin Einsteiger auf dem Gebiet der vServer und musste mich deshalb erst mit den gängigen Techniken vertraut machen.

Ich habe noch mit keiner der beiden Techniken gearbeitet, tendiere aber immer mehr dazu, eine Xen-Lösung zu buchen.

Virtuozzo-Angebote sind wohl günstiger, auf kosten der Tatsache, dass man sich die volle CPU-Leistung mit anderen teilt, ebenso wie den Kernel. Wenn also jemand plötzlich den Server verstopft, hab ich das Nachsehen, und ich selbst muss ständig Rücksicht nehmen. Richtig?

Xen virtualisiert die Hardware, ich bekomme feste CPU-Leistung zugeteilt und bin für meine Serverleistung selbst verantwortlich. Was andere tun wirkt sich nicht auf mich aus. Dafür kostet es auch ein Bisschen mehr. Richtig?

Oft unterscheiden Provider auch zwischen VPS und VDS. Was hat es damit auf sich?

Ich würde mich über ein paar Empfehlungen / Erfahrungen / Erklärungen freuen.
 
Dafür kostet es auch ein Bisschen mehr. Richtig?
Ja so in etwa. Xen lässt sich nicht wirklich überbuchen. Die Ressourcen die du der VM zuweist "verschwinden" vom Hostsystem.
Bei Virtuozzo ist der Hoster flexibler. Deswegen sind diese in der Regel bei gleicher Ressourcenzuweisung wesentlich preiswerter.
Virtuozzo VEs mit 8GB Ram zu bekommen ist mittlerweile kein Problem mehr. Bei Xen wird es da schon schwierig, weil du da bei vielen Hostern schon ein halbes Hostsystem belegst. :p

Oft unterscheiden Provider auch zwischen VPS und VDS. Was hat es damit auf sich?
Auch manchmal als RootDS bezeichnet, bezieht sich in der Regel auf eine exaktere Zuweisung der Ressourcen. Die Unterscheidung findest du vorallem bei Virtuozzo Angeboten. Technisch liegt der Unterschied in der Nutzung von cpuunits und cpuunits+cpulimit.
Das ist mehr ein Marketing Mittel, als dass da ernsthafte technische Unterschiede dahinter stecken. ;)

Ob nun Xen oder Virtuozzo hängt von deinen Bedürfnissen und deinem Geldbeutel ab.
Das Nadelöhr ist immer die Festplatte. Bei Virtuozzo musst du damit rechnen, dass du dir diese mit vielen anderen Kunden teilst. Bei Xen passen in der Regel prinzipbedingt nur ein Bruchteil der Anzahl von Virtuozzo Kunden auf ein Hostsystem. Daraus resultiert auch die entsprechende I/O-Auslastung.
Ob das nun besser oder schlechter ist, muss man im Einzelfall betrachten. Leute die Xen VMs mieten, haben in der Regel höhere Leistungsansprüche und produzieren damit auch mehr I/O Last.
D.h. es könnte praktisch gar kein Unterschied zwischen der I/O Last von 100 Virtuozzo oder 3 Xen Kunden geben. ;)
 
Wenn also jemand plötzlich den Server verstopft, hab ich das Nachsehen,
Das Problem tritt bei allen Virtualisierungsloesungen auf. Waehrend es aufgrund der eingesetzten Isolierungstechnik bei OpenVZ akuter ist, so kann unter allen Virtualisierungsloesungen jedem Container / jeder virtuellen Machine eine gewisse Prioritaet gegenueber anderen zugeordnet werden.

Xen virtualisiert die Hardware, ich bekomme feste CPU-Leistung zugeteilt und bin für meine Serverleistung selbst verantwortlich.
Virtualisierung ist nicht vollstaendig richtig, man nennt es para-virtualisierung; du erhaelst direkten Zugriff auf die echte Hardware mit ein paar Einschraenkungen und Abaenderungen. (So ist RAM-Block 0 nicht gleich Hardware-Ramblock 0 und die CPU darf nicht ausgeschaltet werden)
Auch unter XEN kann eine virtuelle Machine eine andere ausbremsen, dies gilt aber nur wenn sie zumindest einen Prozessor teilen und es kein VDS ist fuer die Rechenleistung, IO-maessig (RAM-Zugriff, Festplatte, Netzwerk) ist es natuerlich immer der Fall.
Allerdings hilft dir keine superschnelle CPU wenn deine MySQL-Datenbank 5 Sekunden zum Antworten braucht weil die Festplatte ausgelastet ist....

Oft unterscheiden Provider auch zwischen VPS und VDS. Was hat es damit auf sich?
Bei einem VPS "streiten" sich alle Kunden um die Rechenleistung waehrend der Hypervisor nur Prioritaeten aber keine Grenzen setzt.
Bei VDS erhaelst du eine CPU-Leistung welcher meist der Rechenleistung einer entsprechend hochgerechneten Pentium4 (Netburst) entspricht garantiert.
Sollte allerdings die Machine ueberladen sein so ist diese Garantie vom Host nicht einhaltbar und du erhaelst natuerlich weniger.
 
Also ist es mit Virtuozzo genau so möglich, garantierte Leistungen festzulegen?

Ich will eventuell zu hostingparadise.de. Ab nächsten Monat soll es dort auch Xen-VDS Angebote geben.


Ob nun Xen oder Virtuozzo hängt von deinen Bedürfnissen und deinem Geldbeutel ab.
Für welche Bedürfnisse wäre denn z.B. was die bessere Lösung?
 
Last edited by a moderator:
Also ist es mit Virtuozzo genau so möglich, garantierte Leistungen festzulegen?
In Theorie ja, in Praxis ist die Grenze nicht ganz so fix wie es immer garantiert wird. Hier Details zu OpenVZ cpuunits: http://wiki.openvz.org/Resource_shortage#cpuunits (englisch)

Für welche Bedürfnisse wäre denn z.B. was die bessere Lösung?
OpenVZ produziert weniger Overhead durch die Verwaltungsmechanismen, erlaubt also mehr Leistung. Des weiteren ist es bezogen auf die Ressourcenzuteilung bedeutend flexibler und -wie du schon bemerkt hast- als vServer guenstiger zu haben.

Xen erlaubt dir den Betrieb eines komplett eigenen Betriebssystems (kannst zb sogar Windows darunter installieren) und komplette Kontrolle ueber den Kernel, seine Module und die Parameter. Es aehnelt von der Flexibilitaet her eher einem echten Rootserver.
 
Leider führt das mehr an Leistung in der Praxis wohl dazu, dass der Provider sich denkt: "Schön, dann kann ich ja mehr Kunden drauf packen". Das macht den Vorteil dann auch wieder zunichte. :(

Die meisten Provider bieten ja Testmonate an. Wie/womit kann ich die Systemleistung umfassend zu testen?
 
Last edited by a moderator:
Virtuozzo-Angebote sind wohl günstiger, auf kosten der Tatsache, dass man sich die volle CPU-Leistung mit anderen teilt, ebenso wie den Kernel. Wenn also jemand plötzlich den Server verstopft, hab ich das Nachsehen, und ich selbst muss ständig Rücksicht nehmen. Richtig?

Wenn man OpenVZ unter einem RedHat Kernel einsetzt, kann man auch dort die CPU für VEs limitieren. Wenn also ein Kunde theoretisch auf einem 8-Kerner 800% erzeugen würde, kann man die Maschine via CPULIMIT auf einen Kern (oder weniger beschränken). Dann bleiben immer noch 7x 100% für andere Maschinen. Unter Debian/Ubuntu funktioniert das allerdings nicht.

Ansonsten war bei allen gemieteten VEs, die ich hatte (XEN/Linux-Vserver/Virtuozzo bei kleinen und grossen Providern), immer IO das Problem.

Ein typischer Quadcore mit 8 GB RAM auf 2x SATA RAID1 limitiert iotechnisch halt irgendwann, obwohl RAM und CPU noch weit weg davon sind. Das Hostsystem will ja auch noch was zum knabbern haben...

Bachsau said:
Die meisten Provider bieten ja Testmonate an. Wie/womit kann ich die Systemleistung umfassend zu testen?

Hängt vom Einsatzgebiet mit ab. Bei OpenVZ kannst Du die Beancounters kontrollieren und relativ schnell feststellen, wo es hakt. Ein Pauschalrezept gibt es nicht, hier spielt auch der praktische Einsatz eine Rolle. Host Europe veröffentlich z. B. die Virtuozzo Parameter, anhand derer kann man sich schonmal einen Überblick über die Eckdaten verschaffen.

Ich habe 1-2 Webseiten, die etwas Rechen-/RAM-Leistung brauchen, anhand derer ich die das serverseitige Antwortverhalten im Einzelfall gut bestimmen kann. Für Lasttests gibt es Tools wie z. B. ab.
 
Last edited by a moderator:
Ja, das stimmt natürlich - die Frage ist bloss, wer von den kleinen/privaten einen "Asbach"-Kernel aus dem OpenVZ Repo einsetzt, wenn er ihn schön neu und glänzend aus dem Standard Repo bekommt. Und die grossen Hoster wie HE haben RHEL laufen.
 
Ich hätte sonst überlegt, irgendeine Benchmark-Software drauf zu schmeißen, die richtig einheizt, die 'ne Minute oder so laufen zu lassen, und zu gucken, was raus kommt.
 
Die Kunst ist es ja, die Werte richtig zu interpretieren. Erstens musst Du dazu wissen, was der Bench genau macht und zweitens musst Du die Ergebnisse in diesem Kontext bewerten können.

Solche Benchmarks sind oft generisch und nicht unbedingt übertragbar in ihren Ergebnissen. Wenn Du bei OpenVZ z. B. 3 GB Burst-RAM bei 2 GB garantiert hast, aber für Deine Anwendung(en) eine zu kleine kmemsize, kommst Du gar nicht in die Verlegenheit, den RAM auch nur annähernd auszulasten, da der Hostkernel vorher schon die Prozesse killt.

Für andere Anforderungen kann dieses Setup wieder ausreichend sein und man hat keinen Problem mit der kmemsize.
 
kmem...hä? :confused:

Wieso killt der kernel Prozesse, wenn der RAM nicht voll ist? Jetzt arbeite ich seit zwei Jahren mit Linux-Büchsen am Desktop, aber mit sowas musste ich mich noch nie rumschlagen. :(
 
Last edited by a moderator:
Das ist OpenVZ-spezifisch.

Im kmem landen Teile/Datenstrukturen von Prozessen, die nicht swapbar sind, also in jedem Fall im RAM vorgehalten werden müssen. Diesen Parameter kann man auf dem Hostsystem für jedes VE konfigurieren.

Ist die kmemsize zu klein und das VE forkt trotzdem weiter munter Prozesse (z. B. Apache-Anfrage bei zu hoher MaxClients-Einstellung), von denen ein Bereich in den kmem muss aber nicht mehr kann, fängt der Kernel des Hostsystems an, in dem VE alles zu killen, was unterhalb des VE-Init Prozesses läuft. Das ist unabhängig davon, was via vmguarpages definiert wurde.

Im Prinzip kann man dann den Container neustarten, der ist erstmal im Eimer.

Es gibt hier eine ganze Menge Leute, die die Grundlagen wesentlich fundierter und technischer erklären können...
 
Last edited by a moderator:
Ich muss wohl mit dem Handbuch anfangen. :(

Warum setzt man die kmensize nicht = der zugesicherten RAM-Kapazität?
 
Last edited by a moderator:
Müsste ich mal ausprobieren, was dann passiert, vor allem in Hinblick auf den Gesamtverbrauch des VE.

Wenn man alleine ist bzw. der Host nur wenige Maschinen hat, geht das sicherlich. Aber die Kiste lässt sich dann halt nicht mehr an die Wirtschaftlichkeit buchen: Wenn jeder Kunde genauso viel nicht-swapbaren RAM bekommt, wie garantiert zur Verfügung steht, kann ich auch nur soviele Maschinen minus Verbrauch Hostsystem minus Verwaltungsoverhead draufbuchen, wieviel RAM physisch zur Verfügung steht.

Da ein Grundkonzept von VZ die Nutzung von Swap ist, wird dieses dann ad absurdum geführt.

Meistens ist es aber gar nicht nötig, soviel kmem zu reservieren. Bei einem 2 GB VE bin ich bei ca. 50 PHP fcgi Prozessen mit 40 MB kmemsize am Anschlag, mit 80 MB kmemsize geht es gut (oder 15-20 fcgi-Prozesse weniger).
 
Aber die Kiste lässt sich dann halt nicht mehr an die Wirtschaftlichkeit buchen: Wenn jeder Kunde genauso viel nicht-swapbaren RAM bekommt, wie garantiert zur Verfügung steht, kann ich auch nur soviele Maschinen minus Verbrauch Hostsystem minus Verwaltungsoverhead draufbuchen, wieviel RAM physisch zur Verfügung steht.

Hostingparadise teilte mir in einer E-Mail mit:
bei unseren VPS sind es exakt so viele [Kunden], wie Arbeitsspeicher allokiert wurde, also z.B. auf einem Node mit 32 GB Ram maximal 30 VPS mit je 1GB Ram.

In der FAQ heißt es:
Werden VPS Server bei Hostingparadise überbucht?
Nein, nein und nein. Wir überbuchen weder den RAM, noch die Festplatten und auch nicht die Prozessoren. Wir wissen das einige Anbieter eine Überbuchung praktizieren, vorallem wenn die Hostsysteme auf PC-Systemen oder alter Hardware basieren, da deren Prozessoren nur 24 GB Ram unterstützen. Wir sind der Meinung das günstige Angebote nicht zu Lasten des Kunden und der Leistung gehen dürfen.

Demnach müsste ich mir über diesen Bereich keine Sorgen machen, oder? :)

Der Betreiber ist bei Webhostlist mit 10/10 bewertet!
 
Last edited by a moderator:
Back
Top