Images langsam

[cyberant]

Hallo zusammen,

ich habe das Problem, dass ich einen Server habe wo ca 16 VMWare images gleichzeitig laufen sollen. Im Moment laufen aber nur 6 Images gleichzeitig, da die performance in den Images einfach ab einer gewissen zahl stark einbricht.
Der Server ist ein Dual Prozessor Xeon L5520 mit 24 GB Ram - also Ram ist nicht voll und die CPU ist auch nicht ansatzweise ausgelastet im Taskmanager - trotzdem laufen werden die images sehr langsam sobald es sagen wir mal 10 auf einmal sind.
Liegt das am VMWare selbst oder könnte vl.die Festplatte verantwortlich sein - ist eine ganz normale 7200 U/min 1 Terrabyte...(läuft im Raid1 also sinds eigentlich 2)
Wieviel Images gleichzeitig kann man eurer Meinung nach gleichzeitig auf einer normalen Festplatte betreiben?
Also das Problem ist einfach das die virtuelle festpaltte in den images dann extrem langsam ist und das ganze OS einfach sehr sehr träge reagiert. Geht man allerdings auf dem Server selbst so ist der noch super schnell...

[Dayworker]

Verlinke mal bitte das "vmware.log" aus dem VM-Verzeichnis bei http://ifile.it und nein, Dateianhänge gehen hier nicht.

[continuum]

Hoert sich nach einem Linuxhost mit ext3 an ...

wie waers mal mit ein paar Angaben zum Host ....

[cyberant]

Hoert sich nach einem Linuxhost mit ext3 an ...

wie waers mal mit ein paar Angaben zum Host ....

Das ganze läuft auf einem Windows Server 2008 und benutzt wird VMWare Server 2.02. Es läuft aber nichts anderes als das VMWare auf dem Server (vl.zukünftig mal).
Hier das VMware log von einem der Images: http://ifile.it/qh4tnw5/vmware.log
Was steht dem im VMWare.log so interessantes?

[continuum]

Was steht dem im VMWare.log so interessantes?

Da steht all das drin was du uns bis jetzt verschwiegen hast

zB verwendest du monolithicSparse vmdks was sich sehr unguenstig auf die performance auswirkt ... shrinkst du die vmdks wenigstens einmal die Woche ?

Also als erstes wuerde ich mal die vmdks mit vmware-vdiskmanager in preallocated vmdks verwandeln. das wird einen deutlichen Performance Schub geben - danach sehen wir weiter ...

Aber besonders viel kannst du auch bei 10 VMs von einer Festplatte nicht erwarten.
Verteil die Last auf mehrere Festplatten

[Dayworker]

Ein Raid1 über den Chipsatzkontroller erzeugt meistens (HW-Raid-Controller sind eine andere Liga) keinen Geschwindigkeitsrausch bzw nur beim Lesen könnte es etwas schneller als ein einzelnes Laufwerk werden, da beim Schreiben die CPU die Konsistens beider Datenträger sicherstellen muß. Das Stichwort bei Google lautet dazu "Fake-Raid".
Wenn alle VMs noch mit auf dem Systemlaufwerk residieren und dazu auch noch als Sparse-Disks angelegt sind, ist das eindeutig unproduktiv. Wie Ulli schon sagte, verteile die Last auf weitere Platten. Oder du lagerst zumindest die VMs auf ein weiteres Laufwerk aus. Ein Raid5 macht mit einem Chipsatzkontroller auch gar keinen Sinn, es belastet die CPU nur noch zusätzlich mit der Prüfsummenberechnung.

Stichwort RAID-Verbund. Betreibst du den Host über eine USV wie ich?
Wenn nein, kann jedes RAID möglicherweise trotzdem einen Datenverlust bedeuten. Entweder weil ein Laufwerk schon einzelne Daten geschrieben hat (Re-Synchronisation der Daten erfolgt vom ersten oder zweiten Raid-Mitglied nach dem Reboot) oder weil der Schreibvorgang in der MFT (MFT=Master File Table, enthält eine Auflistung welche Datenblöcke zu welcher Datei gehören inklusive deren Attribute und Berechtigungen) abbrach (MFT eines Mitglieds ungültig/leer und ebenfalls Re-Sync nach Reboot).

[cyberant]

Ein Raid1 über den Chipsatzkontroller erzeugt meistens (HW-Raid-Controller sind eine andere Liga) keinen Geschwindigkeitsrausch bzw nur beim Lesen könnte es etwas schneller als ein einzelnes Laufwerk werden, da beim Schreiben die CPU die Konsistens beider Datenträger sicherstellen muß. Das Stichwort bei Google lautet dazu "Fake-Raid".
Wenn alle VMs noch mit auf dem Systemlaufwerk residieren und dazu auch noch als Sparse-Disks angelegt sind, ist das eindeutig unproduktiv. Wie Ulli schon sagte, verteile die Last auf weitere Platten. Oder du lagerst zumindest die VMs auf ein weiteres Laufwerk aus. Ein Raid5 macht mit einem Chipsatzkontroller auch gar keinen Sinn, es belastet die CPU nur noch zusätzlich mit der Prüfsummenberechnung.

Stichwort RAID-Verbund. Betreibst du den Host über eine USV wie ich?
Wenn nein, kann jedes RAID möglicherweise trotzdem einen Datenverlust bedeuten. Entweder weil ein Laufwerk schon einzelne Daten geschrieben hat (Re-Synchronisation der Daten erfolgt vom ersten oder zweiten Raid-Mitglied nach dem Reboot) oder weil der Schreibvorgang in der MFT (MFT=Master File Table, enthält eine Auflistung welche Datenblöcke zu welcher Datei gehören inklusive deren Attribute und Berechtigungen) abbrach (MFT eines Mitglieds ungültig/leer und ebenfalls Re-Sync nach Reboot).

Ja ich kenn das mit dem Fake Raid - ich will dadurch ja auch keine geschwindigkeit erreichen sondern Datensicherheit. Raid 5 will ich ja auch gar nicht. Außerdem ist die CPU belastung auch nciht kritisch.
Ich betreibe den Host über eine USV.
Aber wahrscheinlich brauche ich ja gar keinen großen Raid verbund ich werde einfach noch eine platte reinhängen bzw.mit dem 2ten onboard raid aus 2en wieder ein 2tes raid1 machen.
Wie kann ich mir am besten anzeigen lassen das die Festplatte am Limit arbeitet?
Ich habe bis jetzt nur Perfmon dafür benutzt - kann ich das damit eindeutig identifizieren? Oder gibts da ein besseres tool?

zB verwendest du monolithicSparse vmdks was sich sehr unguenstig auf die performance auswirkt ... shrinkst du die vmdks wenigstens einmal die Woche ?

Nein - sollte ich das? Was sollte ich den im meinen fall am besten anderes verwenden wenn nicht monolithicSparse?

[Dayworker]

Ich würde für das Host-OS eine 320er Platte, vielleicht auch wieder als Raid1, vorsehen und den 1TB-Raid1-Verbund erstmal nur zum Hosten der VMs nutzen. Ansonsten könntest du dir mal die VMs raussuchen, die eine hohe IO-Leistung haben und die auf einen weiteren Datenträger aufteilen. Eventuell reicht ja schon die Aufteilung von 8:8 auf jede 1TB-Platte. Bei der dann installierten Anzahl an Datenträgern könntest du ja fast einen richtigen HW-Raid-Controller installieren und dann alles darüber abwickeln.

Die v.Disks sollten bei ausreichend Platz auf dem Datenträger immer als "preallocated" angelegt werden. Ich bevorzuge da die Version in 2GB-Häppchen, dann läßt sich die VM auch mal schnell auf mehreren DVDs etc verpacken. Oder wenn der Platz begrenzt ist, sollte man zumindest die Sparse-v.Disks wöchentlich shrinken. Vermutlich bringt die Konvertierung in "preallocated" v.Disk schon soviel Schub, daß du dir vorerst die weitere Host-Aufrüstung sparen kannst.

[cyberant]

Ich würde für das Host-OS eine 320er Platte, vielleicht auch wieder als Raid1, vorsehen und den 1TB-Raid1-Verbund erstmal nur zum Hosten der VMs nutzen. Ansonsten könntest du dir mal die VMs raussuchen, die eine hohe IO-Leistung haben und die auf einen weiteren Datenträger aufteilen. Eventuell reicht ja schon die Aufteilung von 8:8 auf jede 1TB-Platte. Bei der dann installierten Anzahl an Datenträgern könntest du ja fast einen richtigen HW-Raid-Controller installieren und dann alles darüber abwickeln.

Die v.Disks sollten bei ausreichend Platz auf dem Datenträger immer als "preallocated" angelegt werden. Ich bevorzuge da die Version in 2GB-Häppchen, dann läßt sich die VM auch mal schnell auf mehreren DVDs etc verpacken. Oder wenn der Platz begrenzt ist, sollte man zumindest die Sparse-v.Disks wöchentlich shrinken. Vermutlich bringt die Konvertierung in "preallocated" v.Disk schon soviel Schub, daß du dir vorerst die weitere Host-Aufrüstung sparen kannst.

Kann man den monolithicSparse in preallocated verwandeln und auch wieder zurück?

[irix]

Kann man den monolithicSparse in preallocated verwandeln und auch wieder zurück?

Ja kann man.

Gruss
Joerg

[Dayworker]

...und bevor du fragst, der Befehl für eine einzelne vDisk-Datei dazu lautet:

Code: Alles auswählen

vmware-vdiskmanager -r source.vmdk -t 2 destination.vmdk

oder um mehrere in 2GB-Häppchen aufgesplittete vDisk-Dateien zu erhalten:

Code: Alles auswählen

vmware-vdiskmanager -r source.vmdk -t 3 destination.vmdk

Die ursprüngliche VMDK-Datei wird dabei nicht verändert, du gibst ja eine neue Datei an und die alte dient dann erstmal als kurzzeitiges Backup. Danach hast du dann noch 2 Möglichkeiten, entweder du benennst die neue VMDK-Datei wieder in die alte Bezeichnung um mit:

Code: Alles auswählen

vmware-vdiskmanager -n source.vmdk destination.vmdk

oder du mußt die VMX-Datei an die neue vDisk-Bezeichnung anpassen.

[cyberant]

...und bevor du fragst, der Befehl für eine einzelne vDisk-Datei dazu lautet:

Code: Alles auswählen

vmware-vdiskmanager -r source.vmdk -t 2 destination.vmdk

oder um mehrere in 2GB-Häppchen aufgesplittete vDisk-Dateien zu erhalten:

Code: Alles auswählen

vmware-vdiskmanager -r source.vmdk -t 3 destination.vmdk

Die ursprüngliche VMDK-Datei wird dabei nicht verändert, du gibst ja eine neue Datei an und die alte dient dann erstmal als kurzzeitiges Backup. Danach hast du dann noch 2 Möglichkeiten, entweder du benennst die neue VMDK-Datei wieder in die alte Bezeichnung um mit:

Code: Alles auswählen

vmware-vdiskmanager -n source.vmdk destination.vmdk

oder du mußt die VMX-Datei an die neue vDisk-Bezeichnung anpassen.

super danke
Und der Nachteil von diesen preallocated ist praktisch nur das es mehr festplattenplatz braucht oder?

[Dayworker]

Preallocated v.Disks werden bei der Erstellung immer in voller Größe angelegt, bei den heutigen HDDs mit 2TB sehe ich das jedoch nicht als Nachteil an. Sie zwingen einen eher sogar noch vorher über den Einsatzzweck nachzudenken und dann erst das System entsprechend einzurichten. Falls du mal einen Dateisystem-Check auf einer 2TB-Platte machen mußtest, weißt du wovon ich rede.

Vergiß nicht, daß bei VMware die Grösse einer v.Disk auf 960GB pro Controlleranschluß in der VM begrenzt ist. Mit IDE in der VM sind daher nur 4 Anschlüsse möglich und bei SCSI wären sogar max 45 Anschlüsse an 3 Controllern realisierbar. Natürlich sollte dann auch das Gast-OS mit solchen Größen umgehen können.