VMware-Forum

Kurz zur Vorgeschichte, ich habe mir ein neues Mainboard gekauft und habe meinen gesamten ESXi Datastore vorher heruntergeladen via vSphere Client.

Danach habe ich ESXi 5 neu installiert und wollte nun wieder alles hochladen, aber ich habe ein seltsames Problem - der Upload von den großen vmdk Files auf meinen ESXi Datastore ist extrem langsam nur max. 2 MB/s

Meine Konfig:

Intel DB65ALB3 Board
Intel Pentium G630T
16 GB DDR3 Ram
LSI Logic SAS3041E-R (Raidcontroller)
Intel Gigabit CT (Gigabit Netzwerkkarte)
2x Samsung Spinpoint F3 @ Raid 1 (dort ist auch ESXi 5 installiert)
2x WD HDD's Hotplug

Beim hochladen mit dem vSpere Client und auch mit Veeam FastSCP habe ich max. 2 MB/s, das hochloaden der vmdk's dauert so ewig. Was mache ich falsch, bzw. was muss ich einstellen das es schneller geht? Normal kann das doch nicht sein?

P.S. Der damalige Download der vmdk Files via vSphere Client ging mit ~ 50-60 MB/s.

hast du mal geguckt ob auf dem neuen Mainboard die Netzwerkkarte richtig erkannt wird mit der vollen geschwindigkeit?

Ja es steht die exakte Bezeichnung und "1000 Voll" im Status. Die Intel Netzwerkkarte wird auch von ESXi unterstützt.

Merkwüdig.
Ich habe mal eben eine 20GB und eine 80GB große vmdk runter und rauf geladen sowohl via ssh als auch via sphere client.

Das Downloaden geht fix, aber der Upload ist hinkt sehr stark mehr al 5MBit sind nicht drinnen und auch bei einer vollen 1GBit/s Verbindung.

Hingegen wenn ich 150-200MB große files in den Datastore lade, dann lädt er die in beide richtungen mit voller leistung.

Mal wieder eine Neuigkeit. Habe es dann am nächsten nochmal probiert (ESXi neu gestartet) und hatte dann 18-20 MB/s... ist zwar auch noch weit weg von 50-60 MB/s beim Download, aber immerhin besser als konstante 2 MB/s. Seltsam ist es trotzdem.

Für alle die hier drüber stolpern und gerne eine Lösung hätten (den Original-Threadersteller wird's vermutlich nicht mehr interessieren - aber es kommt sicher der ein oder andere per Google hierher der damit kämpft):

Das liegt mit sehr großer Wahrscheinlichkeit am deaktivierten Write Cache des LSI SAS3041E-R. Diesen kann man bei diesem Controller auch im BIOS-Konfigurationstool nicht aktivieren!

Wie es trotzdem geht steht hier: http://kb.vmware.com/kb/2001946

Mit deaktiviertem WriteCache ist die Performance des 3041E unter aller Sau. Wenn man 18MB/s hat muss man schon froh sein. Ich hab da eher so 10MB/s in Erinnerung bis ich rausgefunden hatte was da los ist.

Prinzipiell ist dein Gedanke nicht verkehrt, aber der SAS3041E-R hat keinen Write-Cache.
Das einzigste was man reaktivieren könnte, wäre der Plattencache und den würde ich auch nur reaktivieren, wenn der Host in eine USV eingebunden ist.

Stimmt, ist vermutlich der Cache der Festplatten gemeint bei der Einstellung.

Wieso es so schlimm sein soll den anzuhaben sehe ich allerdings nicht ein: An jedem 1-Disk Desktop System ist der auch an und die Wahrscheinlichkeit das das Dateisystem nennenswert kaputt bei einem Stromausfall ist auch dort sehr sehr gering.

Sehe nicht den geringsten Grund warum das anders sein sollte bloß weil die Platten nun doppelt (RAID1) am LSI hängen statt einzeln am Motherboard.

Wenn auf die Platte geschrieben wird und du eine Spannungsschwankung durchleben darfst, kommen verlorene Partitionen vor, aber weit häufiger bleibt selbst unter NTFS noch Datenmüll zurück.
Bei einem Raid1 kommt noch hinzu, welche Platte bereits Schreibvollzug gemeldet hatte und welche Platte nachher Master beim Rebuild wird. Falls der HW-Controller bei einem Raid1 von der falschen Platte das Rebuild anstößt, ist das Raid wieder konsistent, aber trotzdem sind entweder nur Daten verloren gegangen oder schlimmer, es wurde nur Datenmüll geschrieben.
Der Plattencache ist auch nicht wie der RAM eines HW-Controller ECC-gesichert. Ohne ECC oder eine vergleichbare, andere RAM-Absicherung kannst du aber überhaupt nicht sicher sein, daß der Plattencache keine Daten verfälscht bzw Bits gekippt sind und selbst die Verbindung Sata-Controller und Platte ist nicht abgesichert, denn sowas wurde erst mit SAS spezifiert. Zum ZFS-Einsatz komme ich noch.


Du bist hier im ESXi-Bereich und bewegst dich somit auch auf Server-Niveau. Das schließt in meinen Augen sämtlichen Desktop-Kram (und erst recht diese Extreme-Edition bzw Enthusiasts-Plattformen) aus, denn da werden äußerst selten ECC-RAM und HW-Raidcontroller eingesetzt, falls ECC-RAM überhaupt unterstützt wird. Auch den ganzen OC-Müll (Intels Z-Chipsätze) willst du beim ESXi-Einsatz nicht haben, da kommt es allein auf stabilen Betrieb an und du hast bei virtualisierten Systemen eher zuwenig RAM als zu wenig verfügbare Kerne. In der VMware-Welt gilt die Devise: "Nur soviel (vRAM, vCPU, vDISK) wie nötig und nicht wie möglich." Von daher sind Singlecore-VMs keine Seltenheit und manche erweiterten Funktionen sind zumindest bei VMware nur mit einer Singlecore-VM überhaupt aktivierbar.
Da sich VMs zur Laufzeit durch den gesamten RAM bewegen, machen sich Speicherfehler dadurch in kürzester Zeit in allen laufenden VMs bemerkbar. ECC-RAM kann zumindest 1Bit-Fehler korrigieren und bei 2Bit-Fehlern den Host anhalten. Letzteres ist im professionellen Bereich immer besser, als mit falschen Daten weiterzurechen. Wenn dir auf einem Desktop-Rechner nur Word oder Libreoffice wegen eines Speicherfehlers abstürzt, ist das für dich nur ärgerlich. Falls der ESXi aber eine VM zur Maschinensteuerung oder für Finanztransaktionen ausführt, kannst du dir solche einfach zu verhindernden Fehler nicht leisten. Um bei beiden genannten Beispielen zu bleiben, entweder würde dann die Produktion stillstehen oder falsche Summen transferiert werden. Beides wird mit hoher Warscheinlichkeit die Fragen nach Haftbarkeit inklu Regress und Vorsatz aufwerfen.


Das der ESXi auch auf vieler Whitebox-HW läuft, ist ein glücklicher Zufall, der so aber nicht bestehen bleiben muß. Beispielsweise wurde bei vSphere5.5 viele HW auf "veraltet und unsupportet" gesetzt. Schau dir mal im KB-Eintrag Devices deprecated and unsupported in ESXi 5.5 (2056935) an, was dort stellenwiese (Intel 82598EB 10Gig-Ethernet) für HW abgeschrieben wird.

Kommen wir abschließend zu ZFS. Für ZFS ist ECC-RAM eigentlich die Voraussetzung, es läuft auch ohne. ABER, beim Scrubbing/Resilvern werden ja Prüfsummen für Daten und Metadaten verglichen und wenn dort ein nichterkannter Bitfehler auftritt, werden vollkommen korrekte Daten kaputtrepariert.

Dayworker hat geschrieben:Wenn auf die Platte geschrieben wird und du eine Spannungsschwankung durchleben darfst,

Dafür habe ich bei mir zumindest eine Spezialgerät verbaut was bei zu großen Spannungsschwankungen abschaltet anstatt sie durchzureichen. Das nennt sich "Netzteil".

Dayworker hat geschrieben:kommen verlorene Partitionen vor, aber weit häufiger bleibt selbst unter NTFS noch Datenmüll zurück.

Wieso sollte auch bloß weil der Strom weg ist die Festplatte plötzlich die ersten Sektoren und damit den MBR überschreiben? Das hört sich jetzt eher nach Ammenmärchen an als nach technischem Verständnis.

Dayworker hat geschrieben:Bei einem Raid1 kommt noch hinzu, welche Platte bereits Schreibvollzug gemeldet hatte und welche Platte nachher Master beim Rebuild wird.

Die Warscheinlichkeit ist groß das beide Platten in einem ähnlichen Zustand sind und selbst wenn nicht... Die Warscheinlichkeit das die EINE Platte die nachher als Master für den Rebuild genommen wird in einem halbwegs konsistenten Zustand ist, ist auch nicht schlechter als wenn es nur eine einzige Platte geben hätte.

Dayworker hat geschrieben:Der Plattencache ist auch nicht wie der RAM eines HW-Controller ECC-gesichert. Ohne ECC oder eine vergleichbare, andere RAM-Absicherung kannst du aber überhaupt nicht sicher sein, daß der Plattencache keine Daten verfälscht

Du kannst Dir auch nicht sicher sein das der Schreib/Lesekopf keine Daten verfälscht oder die Magnetspindel nicht kaputt ist. Die Warscheinlichkeit das das kleine bisschen RAM in einer Festplatte plötzlich kaputt geht dürfte um mehrere Größenordnungen unter der Warscheinlichkeit eines mechanischen Defekts liegen (und auch deutlich unter der von Downtime/Datenverlust durch einen Fehler des Admins).

Dayworker hat geschrieben:Falls der ESXi aber eine VM zur Maschinensteuerung oder für Finanztransaktionen ausführt,

Nicht jeder ESXi Server steuert eine KFZ Produktionsstraße oder die NYSE. Komm mal wieder runter von deinem hohen Ross, ich glaub Dir schon das du ganz ganz toll bist und sehr wichtige Server verwaltest, ist schon ok Chekov.

Dayworker hat geschrieben:Beispielsweise wurde bei vSphere5.5 viele HW auf "veraltet und unsupportet" gesetzt. Schau dir mal im KB-Eintrag Devices deprecated and unsupported in ESXi 5.5 (2056935) an, was dort stellenwiese (Intel 82598EB 10Gig-Ethernet) für HW abgeschrieben wird.

Ein kurzes Blicken auf die SATA/IDE/RAID Controllerliste die jetzt "unsupported" sein wird lässt fast keine wirklich aktuelle oder wirklich relevante Hardware erkennen. Der eine Intel Controller den ich eben mal per Zufall ausgewählt habe aus der Mitte der Liste hat sich als PCI-X Gerät herausgestellt.

Wüsste nicht was man hier hinterherweinnen möchte, es sei denn man betreibt ein Hardware-Museum. Und selbst wenn: Das Zeug geht ja nicht auf magische Weise kaputt bloß weil VMware kein Lust mehr hat Hardware deiner Großmutter offiziell zu supporten.