3
Bandbreitenprobleme beim Schreiben in die VM
Hallo,
wir haben ESXi 5 auf 2 identischen Primergy RX200S6 im Cluster. Als Storage ist eine extrne Terrastation über NFS angebunden. Die komplette ESX-Umgebung läuft über einen seperaten GBit-Switch (2x Host 1x Storage 1x Backup-Storage & der vCenter-Host). Es laufen insgesamt 4 virtuelle Maschinen auf den Hosts. Bei 2 der 4 VM's gibt es erhebliche Bandbreitenprobleme beim Schreiben in die VM, wobei es völlig irrelevant ist ob sie einzeln auf einem Host betrieben werden, oder alle gleichzeit (sowohl Host 1 hostet 3 VM's und Host 2 hostet 1 VM, als auch 3 VM's abgeschaltet und nur noch eine in Betrieb). Die Lesegeschwindigkeiten sind völlig normal (~100MB/s von allen VM's). Die Schreibgeschwindigkeiten der 2 Problemkinder liegt im Schnitt bei 1-2MB/s, wobei oft aussetzer entstehen und ein paar Sekunden gar nicht mehr übertragen wird. Die Schreibgeschwindigkeit der 2 VM's die in Ordnung sind, ist in etwa gleich der Lesegeschwindigkeit. Wenn ich von einem Client im Netz eine Netzwerkfreigabe eines Problemkindes und eines funktionierenden Servers parallel aufrufe (beide laufen zu dem Zeitpunkt auf dem selben ESX-Host) und eine 500MB-Datei auf die Freigabe der VM's schreibe, zieht der funktionierende sauber durch, wobei das Problemkind schwächelt und teilweise sogar bis auf 100KB/s abfällt (mal von den zweitweise auftretenden Stillständen abgesehen). Was aber kurios ist: Wenn ich mich Remote auf einem der Problemkinder befinde (RDP oder Teamviewer) und dann den gleichen Lese-/Schreibtest auf den zuvor benutzten Client durchführe (also genau umgekehrt), sind sowohl Lese- als auch Schreibwerte vollkommen in Ordnung! Die ganze angelegenheit wäre bei Weitem nicht so tragisch, wenn gerade die 2 benannten Problemkinder die wichtigen Server wären! Hier eine kurze Zusammenstellung der VM's:
1: SBS2008 64Bit - 14GB Ram - CPU 2Sockets 4Kerne dynamisch < Problemkind
2: Win2k3 32Bit - 4GB Ram - CPU 2Sockets 4Kerne dynamisch < Problemkind
3: Win2k8 R2 64Bit - 6GB Ram - CPU 2Sockets 4Kerne dynamisch < alles OK
4: Win7 64Bit - 3 GB Ram - CPU 2Sockets 4Kerne dynamisch < alles OK
Die ESXi Host sind je mit 2x 1GBit NIC's ausgestattet.
Alle Systeme sind auf 1GBit Vollduplex konfiguriert (VM, Hosts, Router).
Ich habe bereits sämtliche verfügbaren Treiber für den Netzwerkadapter getestet, ohne Erfolg.
Anpassungen in der Leistung der VM bringen auch keinen Erfolg.
Priorisierungen bei CPU, RAM und Festplatten zu Gunsten der 2 Problemkinder bringt auch nichts.
Die 2 NICS der Hosts sind je 1 für Verwaltung und vMotion und 1 für den Datenverkehr konfiguriert.
Ein Engpass auf der externen Storage und den ESXi-Hosts kann ich ausschließen.
Ich bin mitlerweile schon so weit in der Registrierung der Problemkinder rumzuspielen (LANMAN etc.).
Hoffe mir kann jemand helfen.
Gruß
wir haben ESXi 5 auf 2 identischen Primergy RX200S6 im Cluster. Als Storage ist eine extrne Terrastation über NFS angebunden. Die komplette ESX-Umgebung läuft über einen seperaten GBit-Switch (2x Host 1x Storage 1x Backup-Storage & der vCenter-Host). Es laufen insgesamt 4 virtuelle Maschinen auf den Hosts. Bei 2 der 4 VM's gibt es erhebliche Bandbreitenprobleme beim Schreiben in die VM, wobei es völlig irrelevant ist ob sie einzeln auf einem Host betrieben werden, oder alle gleichzeit (sowohl Host 1 hostet 3 VM's und Host 2 hostet 1 VM, als auch 3 VM's abgeschaltet und nur noch eine in Betrieb). Die Lesegeschwindigkeiten sind völlig normal (~100MB/s von allen VM's). Die Schreibgeschwindigkeiten der 2 Problemkinder liegt im Schnitt bei 1-2MB/s, wobei oft aussetzer entstehen und ein paar Sekunden gar nicht mehr übertragen wird. Die Schreibgeschwindigkeit der 2 VM's die in Ordnung sind, ist in etwa gleich der Lesegeschwindigkeit. Wenn ich von einem Client im Netz eine Netzwerkfreigabe eines Problemkindes und eines funktionierenden Servers parallel aufrufe (beide laufen zu dem Zeitpunkt auf dem selben ESX-Host) und eine 500MB-Datei auf die Freigabe der VM's schreibe, zieht der funktionierende sauber durch, wobei das Problemkind schwächelt und teilweise sogar bis auf 100KB/s abfällt (mal von den zweitweise auftretenden Stillständen abgesehen). Was aber kurios ist: Wenn ich mich Remote auf einem der Problemkinder befinde (RDP oder Teamviewer) und dann den gleichen Lese-/Schreibtest auf den zuvor benutzten Client durchführe (also genau umgekehrt), sind sowohl Lese- als auch Schreibwerte vollkommen in Ordnung! Die ganze angelegenheit wäre bei Weitem nicht so tragisch, wenn gerade die 2 benannten Problemkinder die wichtigen Server wären! Hier eine kurze Zusammenstellung der VM's:
1: SBS2008 64Bit - 14GB Ram - CPU 2Sockets 4Kerne dynamisch < Problemkind
2: Win2k3 32Bit - 4GB Ram - CPU 2Sockets 4Kerne dynamisch < Problemkind
3: Win2k8 R2 64Bit - 6GB Ram - CPU 2Sockets 4Kerne dynamisch < alles OK
4: Win7 64Bit - 3 GB Ram - CPU 2Sockets 4Kerne dynamisch < alles OK
Die ESXi Host sind je mit 2x 1GBit NIC's ausgestattet.
Alle Systeme sind auf 1GBit Vollduplex konfiguriert (VM, Hosts, Router).
Ich habe bereits sämtliche verfügbaren Treiber für den Netzwerkadapter getestet, ohne Erfolg.
Anpassungen in der Leistung der VM bringen auch keinen Erfolg.
Priorisierungen bei CPU, RAM und Festplatten zu Gunsten der 2 Problemkinder bringt auch nichts.
Die 2 NICS der Hosts sind je 1 für Verwaltung und vMotion und 1 für den Datenverkehr konfiguriert.
Ein Engpass auf der externen Storage und den ESXi-Hosts kann ich ausschließen.
Ich bin mitlerweile schon so weit in der Registrierung der Problemkinder rumzuspielen (LANMAN etc.).
Hoffe mir kann jemand helfen.
Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 183085
Url: https://administrator.de/contentid/183085
Printed on: April 16, 2024 at 08:04 o'clock
3 Comments
Latest comment
Moin,
schau dir die Geschichte doch mal mit esxtop an (Guter Startpunkt: http://www.yellow-bricks.com/esxtop/ ), damit lassen sich Bottlenecks recht schnell erkennen.
lg,
Slainte
schau dir die Geschichte doch mal mit esxtop an (Guter Startpunkt: http://www.yellow-bricks.com/esxtop/ ), damit lassen sich Bottlenecks recht schnell erkennen.
Ich habe bereits sämtliche verfügbaren Treiber für den Netzwerkadapter getestet, ohne Erfolg.
Innerhalb 2003er/2008er VMs hab ich immer mit den vmxnet3 vNICs die besten Ergebnisse erziehlt.Die 2 NICS der Hosts sind je 1 für Verwaltung und vMotion und 1 für den Datenverkehr konfiguriert.
Würde ich (bei so minimaler NIC Ausstattung der Hosts) nicht unbedingt konfigurieren. Ich würder eher die 2 NICs an einen vSwitch hängen und dort dann je eine Portgruppe für vMotion/Managenemt und eine für VM Traffic machen. Hat den Vorteil, das alle Funktionen von der Redundanz und der Bandbreite profitieren. Die NICs solltest Du dann, wenns der Switch kann, als LAG/Etherchannel konfigurieren.lg,
Slainte
Hallo wer immer Du bist,
hast Du eine Buffalo Terrastation als NFS-Server für dir ESX-Hosts angebunden ?
Welche hast Du in verwendung ?
Welche Switche hast Du im Einsatz ?
Mach doch bitte mal einen Netzwerkplan, was ist wo und wie angeschlossen.
Ein Bild oder auch zwei sagen mehr als tausend Worte.
Gruß
Anton
hast Du eine Buffalo Terrastation als NFS-Server für dir ESX-Hosts angebunden ?
Welche hast Du in verwendung ?
Welche Switche hast Du im Einsatz ?
Mach doch bitte mal einen Netzwerkplan, was ist wo und wie angeschlossen.
Ein Bild oder auch zwei sagen mehr als tausend Worte.
Gruß
Anton
Danke schonmal für die Tipps. Vorweg nun laufen plötzlich ALLE VMs so langsam!
Ja, es ist eine Buffalo Terastation Pro in Rackausführung im Einsatz. Ich habe nun erneut mehrere Tage Tests hinter mir und kann die ganze Angelegenheit glücklicherweise stark eingrenzen.
Da ich Anfangs auf 2 Test-VM's gute 100MB/s Durchsatz hatte (sowohl Lesen, als auch Schreiben), schloss ich im Kopf die Terastation als mögliche Fehlerquelle aus.
Nach Tests mit der vOps Suite von vKernel (kann ich nur empfehlen) musste ich jetzt leider feststellen, dass es zu hohen Festplattenlatenzen bei der Terastation kommt (Peaks >1500ms, teils sogar 2000ms, Durchschnitt ~400ms).
Was mich nun wundert, das die Terastation anfangs so super lief und nun derart stark schwächelt ... (neuste Firmware).
Ich hab testweise eine "einfache" Iomega mit Raid 1 und den gleichen Festplatten eingehängt und als NFS-Server konfiguriert. Bei beiden lief nur ein und die Selbe VM (Kopie) mit seperatem Hostnamen und IP.
Der Durchsatz ist zwar auch nicht berauschend aber immernoch 3-4 mal besser (und das obwohl die Terastation im Trunk-Mode mit 2x1GBit/s und Lastenausgleich läuft, entgegen der Iomega mit nur 1x1Gbit/s!) ! Und konstant wohlgemerkt, nicht so gestückelt wie bei der Terastation. Hoffe das gute Ding hat nach nun mehr 2 Monaten keinen Knacks weg.
Hätte natürlich auch Plattenbedingt an zu wenig IOPs liegen können, aber da beide NAS-Systeme in etwa gleich bestückt sind, kann man die Terastation wohl eher in die Rubrik "Mist" einordnen.
Ich lass den Beitrag noch 1-2 Tage offen. Vielleicht fällt ja noch jemanden etwas zur Terastation ein, bevor ich das "gute" Stück ersetze.
Gruß
Edit:
@SlainteMhath: Die Portkonfiguration ist wie folgt: Nic0 Datentransfer VMs und als Fault-Tolerance für vMotion und Service - Umgekehrt für NIC1. Denke das passt so ganz gut.
Ja, es ist eine Buffalo Terastation Pro in Rackausführung im Einsatz. Ich habe nun erneut mehrere Tage Tests hinter mir und kann die ganze Angelegenheit glücklicherweise stark eingrenzen.
Da ich Anfangs auf 2 Test-VM's gute 100MB/s Durchsatz hatte (sowohl Lesen, als auch Schreiben), schloss ich im Kopf die Terastation als mögliche Fehlerquelle aus.
Nach Tests mit der vOps Suite von vKernel (kann ich nur empfehlen) musste ich jetzt leider feststellen, dass es zu hohen Festplattenlatenzen bei der Terastation kommt (Peaks >1500ms, teils sogar 2000ms, Durchschnitt ~400ms).
Was mich nun wundert, das die Terastation anfangs so super lief und nun derart stark schwächelt ... (neuste Firmware).
Ich hab testweise eine "einfache" Iomega mit Raid 1 und den gleichen Festplatten eingehängt und als NFS-Server konfiguriert. Bei beiden lief nur ein und die Selbe VM (Kopie) mit seperatem Hostnamen und IP.
Der Durchsatz ist zwar auch nicht berauschend aber immernoch 3-4 mal besser (und das obwohl die Terastation im Trunk-Mode mit 2x1GBit/s und Lastenausgleich läuft, entgegen der Iomega mit nur 1x1Gbit/s!) ! Und konstant wohlgemerkt, nicht so gestückelt wie bei der Terastation. Hoffe das gute Ding hat nach nun mehr 2 Monaten keinen Knacks weg.
Hätte natürlich auch Plattenbedingt an zu wenig IOPs liegen können, aber da beide NAS-Systeme in etwa gleich bestückt sind, kann man die Terastation wohl eher in die Rubrik "Mist" einordnen.
Ich lass den Beitrag noch 1-2 Tage offen. Vielleicht fällt ja noch jemanden etwas zur Terastation ein, bevor ich das "gute" Stück ersetze.
Gruß
Edit:
@SlainteMhath: Die Portkonfiguration ist wie folgt: Nic0 Datentransfer VMs und als Fault-Tolerance für vMotion und Service - Umgekehrt für NIC1. Denke das passt so ganz gut.