Versuch eines Virtualisierungs-Servers

Also ich schaff auf meinen Servern 21-27MB/s.
Jedoch benutz ich nur die Pakete von Lenny und keine selber kompilierten.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
ich hab einen Gast als Fileserver laufen, ein LVM-Volume dient als Platte, welche per virtio eingebunden ist.

Hab die per nfs freigegeben und will vom Host diverse Dateien hinkopieren, aber das geht sowas von lahm, max 13MB/s und je länger es läuft, desto langsamer wirds.
Die CPU-Auslastung am Host ist auch am Anschlag, deswegen ist es vielleicht so lahm.
 
Also ich hab auch eine recht hohe CPU-Auslastung. Ich werd mal schaun ob ich noch ein paar MB rausholen kann wenn ich dem Gast mehrere CPU zur Verfuegung stelle.
 
Ich wüde mit netio mal schauen was so theoretisch zwischen den beiden überhaupt möglich ist. Dann ein wenig NFS Tuning betreiben um das bestmögliche heraus zu holen, Mountparameter async,noatime,nodiratime und verschiedene rsize und wsize mal probieren...
 
Also ich habe mal meinem Gast noch eine CPU zugewiesen und es ging ein paar MB schneller, aber ich muss dazu sagen dass ich meine Tests mit SCP gemacht habe, welches natuerlich die CPU etwas mehr auslastet als NFS.

Iperf Host-Gast
Code: 
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.06 GBytes    910 Mbits/sec
 
Code: 
Server:~# iperf -c 192.168.1.8
------------------------------------------------------------
Client connecting to 192.168.1.8, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.15 port 57791 connected with 192.168.1.8 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec    724 MBytes    607 Mbits/sec

etwas Reserven scheinen noch irgendwo zu stecken.
 
ok, nachdem der Netzwerkspeed so dermaßen lahmt, hab ich die Versuche mit kvm usw. eingestellt und betreibe den Server solo, nur eine Windows-VM läuft noch mit nebenbei.

der Plattenzugriff in meiner VDR-VM mit der durchgereichten PCI-Karte lag auch nur bei 7MB/s, daher ist die auch erstmal gestorben
 
Zuletzt bearbeitet:
Eigentlich schade, aber da kann man nichts machen.
Leider gibt es im Moment noch keine Virtualisierungsloesung die die komplette Funktionalitaet einfach zur Verfuegung stellt. Bei Xen macht einem meist der alte Kernel einen Strich durch die Rechnung (weshalb ich eigentlich zu KVM gewechselt habe) und bei KVM sollte man alle Bestandteile (kvm, libvirt, virtinst) am besten von Hand bauen, da die Entwicklung in grossen Schritten voranschreitet und die Distributionen die neuen Pakete einfach nicht so schnell einbinden.
 
Ja, die Zeit von Xen scheint vorbei zu sein, kvm wirds wohl in Zukunft machen.

Ich würde ja auch alles von Hand kompilieren, aber wenn es schon an libvirt scheitert wie bei meinen Versuchen, dann hat man auch irgendwann keine Lust mehr.
 
lud schrieb:
Bei Xen macht einem meist der alte Kernel einen Strich durch die Rechnung .
Zum Vergrößern anklicken....

kis:~# uname -a
Linux kis 2.6.26-1-xen-amd64 #1 SMP Mon Dec 15 20:07:26 UTC 2008 x86_64 GNU/Linux

so alt ist der nun auch nicht ;)

Xen ist immer noch sehr wichtig oder wie sieht es mit drbd/heartbeat und kvm aus?
 
nein, apt-get install linux-image-2.6.26-1-xen-amd64

Hast du ein HowTo für kvm? Wie ich sehe macht ihr das über xml dateien. Gibt es ein Tool dafür, welches mir die erstellt, wie zum Beispiel die xen-tool für xen?
Hab mich schon länger nicht mehr mit kvm beschäftigt, nur am Anfang wo es noch neu war.
 
Zuletzt bearbeitet:
Mirko76 schrieb:
ok, nachdem der Netzwerkspeed so dermaßen lahmt, hab ich die Versuche mit kvm usw. eingestellt und betreibe den Server solo, nur eine Windows-VM läuft noch mit nebenbei.

der Plattenzugriff in meiner VDR-VM mit der durchgereichten PCI-Karte lag auch nur bei 7MB/s, daher ist die auch erstmal gestorben
Zum Vergrößern anklicken....

Wenns es dich beruhigt, ich bin seit gestern dabei zwischen 2 LPARs (logischen Partitionen, sprich virtuellen Maschinen) auf ner älteren p595 1,7TB an Daten über das virtuelle Ethernet zu verschieben, die kommt auch nicht über 40MB pro Sekunde heraus gerade :heul:
Wäre ja auch zu schön wenn alles immer gleich und zufriedenstellend klappt...

kvm habe ich immer per Hand gestartet mit dem Rattenschwanz an Optionen, gibts das mit den xml Files schon länger :confused:
 
ich hab immer Batch-Dateien geschrieben für meine kvm-Gäste, da das mit den xml´s nicht so wirklich geklappt hat.

eventuell probier ich nochmal Xen, wenn der 2.6.26er Xen-Kernel stabil läuft.
 
BBR schrieb:
kis:~# uname -a
Linux kis 2.6.26-1-xen-amd64 #1 SMP Mon Dec 15 20:07:26 UTC 2008 x86_64 GNU/Linux

so alt ist der nun auch nicht ;)

Xen ist immer noch sehr wichtig oder wie sieht es mit drbd/heartbeat und kvm aus?
Zum Vergrößern anklicken....
aber läuft der auch als Dom0? weil die lenny kernel haben nur DomU Support
 
Das Problem an diesen Xen Kerneln ist, das die Patches fast nur noch von Novell gemacht werden. Alle anderen Distributionen, sogar RedHat(Fedora) haben die Arbeit an Xen Patches zurueckgefahren und mit einer brauchbaren Integration in den Vanilla Kernel ist nicht vor Ende diesen Jahres zu rechnen. Bis dahin wird KVM weiter munter im Vanilla Kernel weiterentwickelt.

libvirt ist aehnlich zu den xen-tools, nur mit dem Unterschied das es neben KVM auch XEN und openVZ verwalten kann.
 
lud schrieb:
Das Problem an diesen Xen Kerneln ist, das die Patches fast nur noch von Novell gemacht werden.
Zum Vergrößern anklicken....

glaube nicht das Novell was mit dem Debian Kernel zu tun hat.

Sicher wird kvm weiterentwickelt, aber bei xen schläft man auch nicht. Man hat nur halt das Kernel Problem.

Wie schon gesagt, sieht es im Moment gerade was Hochverfügbarkeit angeht noch schlecht für kvm aus. Bis jetzt ist mir noch nicht bekannt das kvm mit heartbeat zusammenarbeitet.

Außerdem muss ich sagen, ist die Performance von kvm nicht so toll im Vergleich zu xen. Kann sein, dass sich das schon wieder etwas getan hat. Muss kvm noch mal wieder testen.

Habt ihr ein kleines howto zu kvm und den xml Geschichten? Was ich bei kurzer Suche gefunden habe sind nur die normalen kvm bzw qemu Befehle für VMs.

Edit:

Die xml's werden nur in Verbindung mit libvirt genutzt bzw durch libveit?
 
Zuletzt bearbeitet:
BBR schrieb:
glaube nicht das Novell was mit dem Debian Kernel zu tun hat.

Sicher wird kvm weiterentwickelt, aber bei xen schläft man auch nicht. Man hat nur alt der Kernel Problem.
Zum Vergrößern anklicken....

der Port von Xen auf 2.6.26 für Debian beruht zum Großteil auf den Patches von Novell. Daher hieß es bis vor einer weile auch noch das lenny kein Dom0 Support bekommt.
 
was habt ihr für CPU´s in euren Kisten? Ist mein X2 3800+ zu schwach für eine anständige VM-Lösung?
 
meine beiden test maschinen sind 2 AMD X2 4400+
Aber da laufen auch nur je 3 VMs (Debian) drauf.

Aber was verstehst du unter einer anständigen Lösung? Was bzw wieviel willst du virtualisieren?
 
will 2-3 Debian-Gäste laufen haben und einen Windows-Gast.
Inwiefern könnte eine schnellere CPU oder mehrere Kerne die Gäste (Netzwerkspeed, Plattendurchsatz) beeinflussen?

Hab beim Host jetzt einen angepassten 2.6.28er Kernel am Laufen, jetzt hab ich endlich zwischen Host und Gast 860Mbit Netzwerkdurchsatz, mal sehen, was das wirklich bedeutet.
 
wenn ich montag wieder auf der AArbeit bein, dann bau ich je noch eine windows maschone und teste dann den durchsatz.

Aber das ganze läuft halt per xen.

Edit:

irgendwie ist iperf seltsam. Auf unserem Cluster bekomme ich ganz schlechte Werte und das kann nicht sein.

Mit welchen Werten hast du getestet?
 
Zuletzt bearbeitet:
mit den default-Einstellungen.

hab aber trotzdem noch per NFS einen schlechten Durchsatz zum Gast, nur 80Mbit beim Schreiben einer 4GB-Datei, obwohl mir iperf 880Mbit angezeigt hat.
 
Zuletzt bearbeitet:
Mirko76 schrieb:
mit den default-Einstellungen.

hab aber trotzdem noch per NFS einen schlechten Durchsatz zum Gast, nur 80Mbit beim Schreiben einer 4GB-Datei, obwohl mir iperf 880Mbit angezeigt hat.
Zum Vergrößern anklicken....

du schreibst ja jetzt auch auf die Platte, also ist der Wert garnicht mal so falsch. iperf misst ja nur die netzwerk-performance.
 
Gut möglich, aber sind die Platten im Gast wirklich so lahm?
 
Also du kannst deine Plattenperformance mal durch Erstellen einer Datei testen, oder mit hdparm.

Code: 
dd if=/dev/zero of=/verz_mit_genuegend_platz/test bs=M count=5000
hdparm -tT /dev/vda

Beide Tests am besten mehrmals laufen lassen, die Werte haben bei mir stark geschwankt.

Zur CPU:
Dein Dual Core reicht fuer die paar Gaeste allemal.
 
Das hat mit dem Gastsystem nicht zutun, Platten sind allgemein lahm.

Edit:

Mirko76 schrieb:
mit den default-Einstellungen.

hab aber trotzdem noch per NFS einen schlechten Durchsatz zum Gast, nur 80Mbit beim Schreiben einer 4GB-Datei, obwohl mir iperf 880Mbit angezeigt hat.
Zum Vergrößern anklicken....

bist du dir ganz sicher hast du Mb beim schreiben meinst und nicht MB?

Meine Platte auf der arbeit (schon etwas alt *g*)

hdparm -tT /dev/sda

/dev/sda:
Timing cached reads: 1932 MB in 2.00 seconds = 966.72 MB/sec
Timing buffered disk reads: 236 MB in 3.00 seconds = 78.64 MB/sec

dd if=/dev/zero of=/tmp/test bs=1024k count=5000
5000+0 Datensätze ein
5000+0 Datensätze aus
5242880000 Bytes (5,2 GB) kopiert, 84,1896 s, 62,3 MB/s
 
Zuletzt bearbeitet:
hier mal mein Test mit Bonnie auf dem Server:

bonnie.JPG


Test auf mein Logical Volume auf dem Server:
dd if=/dev/zero of=/media/backup/test bs=1024k count=5000
5242880000 Bytes (5,2 GB) kopiert, 71,0982 s, 73,7 MB/s

Jetzt das Logical Volume, was im Gast gemountet ist per virtio:

5242880000 Bytes (5,2 GB) kopiert, 345,488 s, 15,2 MB/s

und die Platte hda im Gast:

4003954688 Bytes (4,0 GB) kopiert, 193,606 s, 20,7 MB/s

Wieso kommen beim Schreiben mit NFS vom Server zum Gast nur 8MB/s an?
Es wird zwar Anfangs mit 15MB/s geschrieben, aber zum Ende der Übertragung landet man bei 8MB/s.
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh