VMware-Forum

Hallo zusammen,

das AHCI auf 6.5 nicht mehr verwendbar ist, dürfte wohl schon allen bekannt sein.
Für diejenigen unter euch, denen das entgangen ist oder wer sich wundert warum selbst USB Sticks schneller sind als die HDD oder SSD am onboard Controller sei unter http://www.nxhut.com/2016/11/fix-slow-disk-performance-vmwahci.html?m=1 geholfen.

Aus gegebenen Anlass hab ich gleich mal einen größeren Test gemacht, der die Problematik von 6.0 und 6.5 aufzeigt.
Getestet wurde unter ESXi 5.5 6.0 und 6.5 im jehweils aktulellstem Build des ISO installers (ich habe nicht mit dem vCeter Updatemanager die Systeme auf den aktuellsten patchlevel gezogen - das kommt evtl. noch später).
Der Hypervisor ist auf einem USB Stick installiert um eventuelle Einflüsse auf den vmfs store abzuwenden.
Als Speicher stehen zwei SSD´s am Onboard Controller, ein SSD RAID1 auf einem Microsemi 6405E (ehm. Adaptec) und ein SSD RAID1 auf einem Broadcom 9341-8i (ehm. LSI, ehm. AVAGO) zur Verfügung.
Firmware der Controller ist auf Letztstand, das gleiche gilt für die Treiber.
Ergebnis:
gleich vorweg, ich hab keine definitiven Zahlen, da ich nur mit dem Datenspeicherbrowser ein 10GB File durch die Gegend geschaufelt habe und somit nur ungefähre Zeitangaben habe - die unterschiede sind jedoch so eklatant das das subjektive Ergebis aussagekräftig genug ist.
Getestet wurde der upload vom vsphere client pc (ssd quelle - 1Gbit Netzwerk) auf die 3 Stores und das Kopieren zwischen den Stores.

- ESXi 5.5

upload:
SSD: bester Wert (ausgenommen 6.5 mit workaround)
Adaptec: sehr gut
LSI "legacy Treiber": sehr gut
LSI "native Treiber": doppelt so langsam

copy:
SSD zu SSD: bei weitem nicht was SSD kann, aber erträglich
SSD zu LSI '"legacy Treiber": gut
SSD zu LSI "native Treiber": siehe upload
SSD zu Adaptec: gut
Adaptec zu LSI: noch nicht ganz die Katastrophe aber schon echt mühsam

- ESXi 6.0
upload:
SSD: sehr langsam
Adaptec: langsamer als 5.5
LSI:

copy:
SSD zu SSD: schneller als der upload
SSD zu Adaptec: noch gut
SSD zu LSI: langsam
Adaptec zu LSI: echt langsam

- ESXi 6.5
upload:
SSD: man wird alt (mit dem Workaround gehts um Welten besser)
SSD zu Adaptec: langsamer als bei 5.5 und 6.0, aber doch um einiges besser als LSI
SSD zu LSI: langsamer als bei 5.5 und 6.0

copy:
SSD zu SSD: eine Katastrphe
SSD zu Adaptec/LSI: ohne Workaround sehr langsam, Adaptec wie immer schneller.
mit Workaround
LSI zu Adaptec: gut
Adaptec zu LSI: sehr langsam

Fazit:
SSD im ESXi ist quasi nutzlos, lediglich bei random Read/Write könnten sie die Nase vorne haben, jedoch haben aktuelle Controller und Festplatten größeren cache und gute logik, das hier der preisliche Mehraufwand für SSD nicht rechnet, zumal man bei HDD gleichzeitig viel mehr Kapazität hat.
Das Adaptec schneller als der LSI ist mag zum Einen daran liegen das die Treiber besser sind, zum Anderen könnte ein Cache Vorteil vorliegen.
ESX 6.5 ist bei localem Storrage der langsamste im Vergleichstest (ausgenommen AHCI Workaround).
Beste Werte liefert 5.5 mit legacy Treibern.
Um bei aktuellen ESXi (6.0/6.5) annähernd in den Genuss einer normalen SSD Performance zu kommen, kann man eigentlich nur noch per iSCSI angebundenes NAS (da kann man die SSD´s zweckmäßiger einsetzen) verwenden.
Local Storrage ist obsolete, da in jeder Form ein NAS bereits bei 1Gbit Anbindung bereits 100% Performancezuwachs bringt (jumboframes steigern diesen Wert nochmals). Bei 10Gbit bleiben für den KMU Anwender keine Wünsche mehr offen.

Anmerkung:
10Gbit NIC´s von intel lieferten mit den std. Image Treiben auch sehr schlechte Ergebnisse, manchmal zu 6.0 release waren die Werte oft auf 10 - 100Mbit niveau. Neuere Treiber schufen nach und nach Abhilfe.

Was für SSDs kamen zum Einsatz?
Consumer SSDs verhalten sich im Raid-Verbund wegen ihrer nich linearen Datenrate "sehr interessant".

Verwendete SSD´s: Samsung 840, 840 pro
bei max 30mb write rate, egal ob raid oder nicht, ist es egal was man ansteckt.
Intel Software raid1 auf diversen MS Servern hat volle SSD performance bis 500MB/s, also darauf kann man sich nicht ausreden.
Die Lebensdauer der MLC´s v-nands ist ebenfalls höher als die des Gesammtservers - ich hatte die erste x25 von intel von 2010 - 2015 im Einsatz, da lief ein SQL Server drauf (bmd - ntcs).
Wenn also solche "consumer" SSD´s tatsächlich mal ein flaschenhals sein sollten, steig ich auf Consumer m.2/u.2 NVMe um ^^.
Das ganze gequake über "consumer" vs. enterprise geht mir auf den Senkel, es fehlt einfach die vernünftige Grundlage .

P.S.: Bei einem Kunden hab ich als Datenfriedhof eine 2,5" Notebook Platte (5400rpm) drin, die ist schneller als ne SSD (esx 6.0)

lennier hat geschrieben:Wenn also solche "consumer" SSD´s tatsächlich mal ein flaschenhals sein sollten, steig ich auf Consumer m.2/u.2 NVMe um ^^.
Das ganze gequake über "consumer" vs. enterprise geht mir auf den Senkel, es fehlt einfach die vernünftige Grundlage .

Da muss ich leider wiedersprechen. Das hat sehr wohl eine sehr einfach Grundlage.

Es gibt da ein paar wesentliche Rahmenbedingungen die mehr oder weniger allgemein gelten:
Cache:
1. Ist ein OS-Write-Cache abgeschaltet, sinkt die Performance
2. Wird Disk-Write-Cache abgeschaltet, sinkt die Performance auf unterirdische Niveau
3. SSD's benötigen in der Regel zur Funktion ihren internen Cache, kann also gar nicht wirklich abgeschaltet werden

Latenz
1. Die Latenz von Magnetdiscs ist extrem stabil bzw. schwankt zwischen einzelnen Reads/Writes nicht extrem, egal ob Consumer oder Enterprise (auch wenn die Enterprise in der Regel tiefer liegen)
2. Die Latenz von einzelnen Writes/Reads von SSD's innerhalb der selben Platte ist enorm von der Qualität der SSD abhängig

Performance:
1. Magnetdiscs sind im Serverbetrieb langsam. Ohne Cache liegen zwischen 400 und 900KB pro Sekunde an (100-225 IOPS à 4KB pro Sekunde). Das sind welten zu den angegeben sequentiellen Schreibvorgängen mit Cache
2. SSD's haben sehr viel mehr IOPs pro Platte, teilweise um x-tausende Faktoren

Sicherheit
1. Ohne Pufferung des Write-Caches gegen allfällig Stromprobleme (Netzteilausfälle, Computerabstürze, USV-Defekt usw.) sind die Daten im Cache ungeschützt
2. RAID insbesondere mit Parity ist auf gleiche "Versionstände" der Discs angewiesen, bei einer Einzelplatte ist das nicht vergleichbar tragisch
3. Ein Commit im RAID-Betrieb gibts erst wenn alle beteiligten Discs ihre Daten geschrieben haben
4. die Chips in "richtigen" Enterprise-SSD's sind von höherer Qualität so wie das normalerweise für die Mechanik von Magnetplatten der Fall ist. Zeigt sich auch sehr deutlich in den Rücklaufquoten. Die hochwertigsten SSD's von Intel fallen z.B. so gut wie gar nicht aus und weisen eine deutlich tiefere Write-Fehler-Toleranz auf. Zudem liegt Wahrscheinlicht überhaupt einen Write-Fehler zu produzieren sehr viel tiefer. Das ist einerseits ausgefeilten Algorythem als eben auch der Qualität der Chips an sich geschuldet.

Nun ist es nicht mehr weiter schwierig daraus abzuleiten warum richtige Enterprise-Discs einen enormen Vorteil bieten gegenüber Consumer-Discs. Insbesondere bei SSD's und RAID-Betrieb wo ein Write-Commit immer erst dann erfolgt, wenn alle beteiligten Partner ihr OK gegeben haben und Read's immer erst dann zu Verfügung stehen, wenn die Daten aller Discs ausgelesen wurden.

Ist nun also die Latenz breit und unregelmässig gestreut wie es bei Consumer SSD's üblich ist, dann kann die RAID-Performance ins bodenlose sinken. Insbesondere unter Last. Bei meinen Tests führte dies dazu, dass z.B. VM's auf ausgelasteten SSD-Consumer-RAID Verbünden (z.B. wegen Kopieraktionen auf anderen VM's) öfter mal eine Gedenksekunde hatten und das Nutzerfeeling auf VDI massiv getrübt wurde.
Dies obwohl die durchschnittliche Übertragungsrate eigentlich immer noch besser war als bei HDD's. Die durchschnittliche Latenz unter Last war aber teilweise exorbitant hoch und um ein vielfaches höher als auf den Magnetdiscs-Verbünden. Bei vernünftigen Enterprise-Discs konnte ich dieses Verhalten nicht beobachten. Auch in VDI VM's die auf Magnet-Discs lagern, konnte ich trotz vollständiger auslastung der Discs solche Gedenksekunden nicht beobachten. Ein Spiegelpartner auf einer Enterprise SSD zieht die Performance nicht signifikant runter und auch eine zusätzliche Disc im Stripe bringt nahezu eine lineare Skalierung anstatt eine Performance-Verschlechterung wie das in der Regel bei Consumer-Discs der Fall ist.

Ich persönlich habe lieber eine etwas tiefere Gesamtperformance dafür einen regelmässigen und vorhersehbaren Betrieb ohne Aussetzer. Ganz zu schweigen von der tieferen Ausfallquote die mir insgesamt weniger arbeit beschert.

Meines erachtens dürfen bei Consumer-Discs maximal zwei Discs bei einem Write beteiligt sein. Das geht nur mit RAID 10 und abgedrehtem Striping. Auch sollte die Übertragungsgeschwindigkeit pro VM irgendwie gedrosselt werden, damit die SSD's nicht völlig ausgelastet werden können.
Ich baue sowas trotzdem nicht. Auch nicht privat. Einfach weil ich kein Bock auf das gejammere habe und ich so wenig arbeit wie möglich mit den von mir aufgebauten Umgebungen haben möchte.

Hi,

die SSD Diskussion hat hier eigentlich nichts zu suchen, aber dennoch geb ich dir Recht, das hab ich aber auch Eingangs erwähnt. Für jeden Anwendugnszweck gibt es die Passenden gerätschaften.
Für meine Kundschaft langt die Consumer variante, hier passiert ausser dem Backup in der Nacht eigentlich nichts auf den Servern, und die Last ist meist auf zwei Raid1 verteilt - somit kann mir die nicht vorhandene Latzenz gestohlen bleiben, und der Kunde ist glücklich weil er sich´s leisten konnte (schon schwer genug alle 7 Jahre einen neuen Server an den Unternehmer zu bringen).

Mit meinem Artikel (wenn auch nicht durch aussagegräftiges Zahlenmaterial belegbar) wollte ich nur aufzeigen, daß sich die Performance bei vmware in den letzten Versionen enorm verschlechtert hat, und der Kunde zu NAS Lösungen gezwungen wird (wir sprechen hier immerin um Mehrausgaben im bereich von 2500€).
Die sogenannte Whitebox Lösung für Kleinunternehmer ist nicht mehr anwendbar, hier werden wir wohl in Zukunft verstärkt auf Hyper-V setzen müssen (auch wenn ich´s wie die Pest hasse).

Der Datastorebrowser ist meiner Meinung nach auch kein relevanter Performance-Indikator.
Dazu verhält er sich in den verschiedenen Versionen zu unterschiedlich ist nutzt auch längst nicht die mögliche Performance der Hardware, da VMware ihn anscheinend zu Gunsten der VMs ausbremst.