SSD unter ESXi5 - muss man etwas beachten?

[UrsDerBär]

Grösse der Files: 3gb und 18GB, war kein Unterschied.

Ich allokiere bei Desktop-SSD ca. 20-30% nicht. Die Enterprise-MLC-Teile (auch wenn das imho eigentlich ein Widerspruch ist) haben dies ja auch in etwa. Zusammen mit dem Trim-Support sollte die Leistung nicht allzu arg einbrechen.

Transferdaten: Jo das die erstunken und erlogen sind, ist ja allgemein bekannt. Trotzdem erreicht man mit ein paar Discs eine konstante Leistung die deutlich über dem ist, was normale Einsteiger-SAN's (die den Namen verdienen) erreichen. Burst-Leistung und Read welche für Programmstarts hilfreich sind, sind sogar um ein X-faches höher. Also View wird extremst beschleunigt, ne AccessDB fliegt auch fast wie ne SQL-DB. Insofern lohnt sich das imho schon.

Boot-Time bekomme ich kaum die Balken des LAdevorgangs mit bis ich ein Bild vom ESXi habe. Wirklich extremst schnell.

Interessieren tut mich noch was meine alten SLC's leisten. Denke die machen eine bessere Konstantleistung, vor allem bei kleinen Files. Nur haben die lediglich 32GB.

[UrsDerBär]

Noch etwas zu Plattencontroller: LSI schaltet SSD's direkt ohne die Verwendung des Controller Write-Cache durch. Es bringt also quasi gar nix wenn man nen Controller anstelle von HBA's einsetzt. Zumindest hat mir der Support dies so durchgegeben.

Ohne eigenen Kondensator in der SSD welcher noch alles wegschreibt ist also sowieso essig und SSD's auf stabile Stromversorgung angewiesen. Selbständiges Puffern der Backplane vermutlich auch eher gebastel.

[Dayworker]

Noch etwas zu Plattencontroller: LSI schaltet SSD's direkt ohne die Verwendung des Controller Write-Cache durch. Es bringt also quasi gar nix wenn man nen Controller anstelle von HBA's einsetzt. Zumindest hat mir der Support dies so durchgegeben.

Klingt auch logisch für mich. Der Write-Cache soll dem langsameren Medium etwas Zeit verschaffen und nicht als Bremse für ein schnelles dienen.

Ohne eigenen Kondensator in der SSD welcher noch alles wegschreibt ist also sowieso essig und SSD's auf stabile Stromversorgung angewiesen. Selbständiges Puffern der Backplane vermutlich auch eher gebastel.

In der von mir bereits genannten Intel SSD DC S3700 wird dieser Punkt unter Power Management als "Enhanced power-loss data protection" aufgeführt.
Auf der anderen Seite sind der Datenverlust bei Stromausfall bei SSD und HDD vergleichbar. Die entscheidende Frage ist nur, wie stark die Verwaltungsinformationen dabei beschädigt wurden. Im günstigsten Fall sind die Daten zwar alle weggeschrieben, aber die MFT noch nicht aktualisiert. Spätestens wenn einem 2mal aufgrund des Stromausfalls die Arbeit verloren geht, kommt man unweigerlich auf den Einsatz einer USV oder sollte sich zumindest damit beschäftigen.

Ich allokiere bei Desktop-SSD ca. 20-30% nicht. Die Enterprise-MLC-Teile (auch wenn das imho eigentlich ein Widerspruch ist) haben dies ja auch in etwa. Zusammen mit dem Trim-Support sollte die Leistung nicht allzu arg einbrechen.

Enterprise-MLCs haben sogar noch eine weit grössere Spare-Area, damit sie ihre angegebenen Endurance Targets erreichen. Intel listet für seine DC S3700 eine Endurance von "10 drive writes per day for 5 years" auf. In Abhängigkeit zur gelisteten Kapazität (100, 200, 400, 800GB) sind das immerhin zwischen 1.825PB und satten 14.6Petabyte.

[UrsDerBär]

In der von mir bereits genannten Intel SSD DC S3700 wird dieser Punkt unter Power Management als "Enhanced power-loss data protection" aufgeführt.

Das gabs meines wissens schonmal bei Intel und Sie sind kräftig auf die Nase gefallen. Hoffentlich ist das nun besser. War bei ner Desktop SSD
Winkom bietet das auch schon länger an, die haben aber chronisch Lieferungsschwierigkeiten gehabt.

Spätestens wenn einem 2mal aufgrund des Stromausfalls die Arbeit verloren geht, kommt man unweigerlich auf den Einsatz einer USV oder sollte sich zumindest damit beschäftigen.

Weigere mich eh irgendwas ohne gscheite USV einzurichten. Allerdings würde theoretisch ja schon ein abwürgen des Hosts ein Problem darstellen wenn die Backplane nicht unabhängig vom Schalter mit Strom versorgt wird.


Hab grad auch noch einen Test mit neuen 15k SAS-Disks gemacht (auch am HBA, deaktiviertem Schreibcache, RAID1, Freigabe als NFS). Die Schreibleistung bei grossen Files ist extrem unbeständig und geht Wellenlinienförmig hoch und runter von 2-10MB mit kleinen Ausreisser bis 30. Bei den kleinen Files konstant tief, teilweise gegen 0 (Anzeige Server 2012). Leseleistungsdifferenz wollen wir mal gar nicht von reden.
Das heisst, die SSD's machen da schon ziemlich viel aus, auch wenn die Herstellerdaten geschönt sind.
Klar würde man das mit einem Controller etwas ausliniearisieren können, aber ist der Write-Cache mal voll, kann auch dieser nicht mehr viel ausrichten. Dies ist bei nem Restore immer der Fall.

[lennier]

Hi,

meine Gadanken dazu ^^.
Ich hab jetzt in einigen ESX Servern Raid1 aus SSD´s und eine "langzeit" Testmaschine mit single SSD´s. Die langzeitmaschine läuft nun schon 2Jahre ohne Auffälligkeiten.
Die Produktivmaschinen haben natürlich auch SAS Platten für die Datenstores. Auf diesen sind auch die Snapshots und VM - Auslagerungsdatein.

Bei Thik Provisioning ist doch der Platz bereits vordefiniert also sollte sich die Reallocation in grenzen halten, und wenn man die Platten nicht bis zum letzten bit auslastet dürften diese doch relativ lang leben.

[UrsDerBär]

Der Gedanke stimmt nur beschränkt bzw. wenn die SSD selber über genügend Reserven verfügt oder Trim durch das OS welches die Daten verwaltet an die SSD weitergeleitet wird. Dazu muss dieses OS aber wissen welche Sektoren frei sind.

Wichtig ist einfach wie bei allem: vernünftiges Material und saubere Doku. Vernünftige SSD's skalieren zum Beispiel sehr gut. Das heisst verwende ich zwei in nem RAID-Verbund pro Datenset (RAID 10), erziele ich quasi die doppelte Leistung, bei drei dreifach usw. Das können sehr viele nicht gscheit. Die Intel DC S3700 kann das zum Beispiel vorzüglich, hat aber auch Ihren Preis. Mit nem SAS-Interposer wäre ein JPDO sogar Clusterfähig. --> Wie ehemalas Intel Modular Server


Ich habe jetzt einige SSD-Umgebungen am laufen. Mit Performance von der der ich mit meiner iSCSI SAN nur träumen kann. Bei allen muss ich mit gewissen Beschränkungen halt einfach leben. Kann ich in der Grössenordnung wo ich Umgebungen betreue aber sehr gut. Sind immer nur eine Handvoll Hosts.

Meist sieht das Setup ungefähr so aus:
- 1 Host mit nem LSI-HBA, durchgereicht an eine Storage VM
- Ein paar richtig gute SSD's, gespiegelt, Deduplizierung
- Die SSD's präsentiere ich dem Host als Datenspeicher
- Single CPU Socket, Höchste verfügbare MHZ, Möglichst hohe gute Kernzahl

Dazu nen klassischen kleinen Host mit klassischem RAID und SAS-Disks sowie ne kleine NAS. Dabei sichere ich auf den zweiten Host sowie auf die NAS.

Die ganze Komplexität lastet auf der Storage-VM, die richtigen VM's haben möglichst nichts kompliziertes aktiviert oder krude Setups. So können Sie auch einfach ohne Einschränkungen überall hingeschoben werden wo man möchte.

Das läuft extrem performant. Server und Clients, fast alles auf einer Maschine. Im Fehlerfall ist ein Backup dank der SSD's in 0,Nix zurückgespielt. Zudem ist die Lizenzierung in aller Regel entspannter.


Mein Fazit: Es ist nicht alles sinnvoll und auch nicht zwingend auf den ersten Blick, aber machen kann man das meiner Meinung nach schon, wenn man sie A den Konsequenzen bewusst und B entsprechende Absicherungen vorgenommen hat. Sonst läuft man früher oder später gnadenlos in den Hammer. Aber das ist immer so

[~thc]

@Urs: Mich interessiert rein akademisch, warum du dir die Mühe mit diesem komplexen Setup machst. Sind die VMs auf dem SSD-Datastore so I/O-intensiv, dass es sich lohnt? Bedingt die Struktur der VMs eine Deduplizierung und wie kannst du den Erfolg bzw. die Ersparnis einschätzen? Wenn ein Backup auf dem zweiten ESXi oder dem NAS liegt, warum ist es dann trotz des Flaschenhalses Netzwerk "schnell" zurückgespielt?

[UrsDerBär]

Wahnsinnig komplex finde ich das jetzt nicht. Ist nur ne Storage-VM dazwischen. Die VM's selber sind gewöhnlich.

Warum:
- Langsame Desktop VM's nerven jedermann. Word soll z.B. auf Knopfdruck da sein und nicht nach einer Gedenksekunde. Am liebsten so wie zu DOS-zeiten
- Dedupe Einsparung bei Desktops sind ca. 80-90%. Differenz sind eigentlich nur Nutzdaten der Server. Macht sehr viel Speicherplatz aus und bringt ne Menge Blocks in den RAM-Cache des OS.
- Inner-Host-Transaktionen sind extrem schnell. Macht sich vor allem bei typischen KMU Anwendungen, eher suboptimal programmierte Branchenlösungen usw. bemerkbar. Da bekommen selbst eigentlich viel zu grosse Access-Anwendungen Beine.

Backup/Rebuild:
Ein Full-Rebuild der ganzen Umgebung (selten wirklich notwendig) ist je nach Szenario logischerweise unterschiedlich schnell. Zwischen zwei Hosts bzw. deren Storage VM die z.B. mit 10gbit direkt verbunden sind, geht das sehr zackig. Read ist auch von Magnetplatten sehr schnell (wenn auf solche gesichert wird). Bei einem Brand hat man eh ganz andere Sorgen. Da spielen die paar Stunden um das ganze vom NAS oder Wechseldatenträger wiederherzustellen auch keine Rolle mehr.

Backup kann man je nach Anwendungen verschiedene Szenarien fahren. Herunterfahren der VM's und Fullcopy auf der StorageVM, Windows-Backup, Filecopy, dazu Anwendungsspezifische Vorgänge, Veeam oder was einem eben selber am besten gefällt.

Wenn Controller durchgereicht werden, kann auch nen schneller Rebuild innerhalb des gleichen Hosts gemacht werden. Einfach einen Backupdatenträger reinschieben und VM's sowie deren interne Backupplatten für den Rebuild rüberkopieren.

Der Hauptgrund neben der Performance sind aber eindeutig die Kosten. Das betrifft sowohl die Lizenzierung als auch die Hardware. Das Plus an Komplexität an der Software wird bei der Komplexität der Hardware teilweise eingespart. Zudem ist eine solch performante Lösung selten sinnvoll finanzierbar mit einer SAN. Zwei SAN sowieso nicht.


Aber eben, jeder wie er mag. Es gibt ne Menge die dagegen spricht, aber auch ne Menge dafür. Das man das nicht auf eine grössere Umgebung münzen kann, sollte auch jedem klar sein. Da hätte ich wohl auch lieber SAN-Spielzeuge mit SSD-Cache oder LinkedClones komplett im RAM.

[opa12]

Empfehlen kann man hier Corsair Performance Pro oder Plextor M3P.

Gibt es zu den aktuellen Modellen auch schon Erfahrungen?
Welche der aktuellen SSD haben einen sehr guten GC der "kein TRIM" verschmerzbar macht?
Aktuelle Auswahl wäre:
SanDisk Extreme PRO 480GB http://www.computerbase.de/2014-07/sand ... ro-test/8/
Samsung SSD 845DC EVO 480GB
oder spielt es bei den aktuellen SSD keine Rolle mehr?

Lg

[Supi]

Ohne eigene praktische Erfahrungen würde ich mal Radeon R7 oder OCZ ARC 100 / Vector 460 in den Raum werfen.

http://www.computerbase.de/2014-10/plex ... ungsabfall

Interessant dazu vielleicht auch:

http://www.v-front.de/2013/10/faq-using ... -esxi.html

http://www.purestorage.com/blog/direct- ... ere-6-0-2/

http://cormachogan.com/2015/05/07/vsphe ... p-changes/

[UrsDerBär]

Das dafür und dawider von Trim ist fast so alt wie die Massenverbreitung von SSD's selbst. Es gibt eigentlich nur eine gute Alternative/Ergänzung die ziemlich nah an einen Trim-Ersatz ran kommt: Sehr viel ungenutzten Speicher der nur für Verwaltungszwecke da ist. Das wiederum ist ein Gut welches bei SSD's meist nicht im Überfluss vorhanden ist.

Alles andere ist meiner Meinung nach Augenwischerei. Aber auch Trim ist nicht immer korrekt implementiert. Kann auch mal zu Datenverlust führen.
Dann kommt noch die mangelnde Latenz-Stabilität von vielen SSDs dazu welche eine genaue Leistungsangabe extrem erschweren wenn sie im RAID verwendet werden.

Generell würde ich daher empfehlen, nur SSD's/HDD's einzusetzen, welche auch grosse Hersteller in Ihren Cluster-Server und/oder SAN's verwenden. Die sind A meist haltbar und B müssen Sie in der Regel gewisse Mindestvorgaben erfüllen.

Sehr empfehlen kann ich Intel 520er Serie (dies nimmer gibt) sowie die DC3700. Kostet ordentlich Geld, hält aber auch was sie verspricht.

[opa12]

OK, dann werde ich es mal mit der SanDisk Extreme PRO 480GB probieren.
Die DC3700 bekomme ich nicht ins Budget

Werden soll es ein ESXI 5.5 Host für ein paar Test Server (Applikation und Datenbanken).
Host ist ein "alter" DL380 G6" mit 2 x Smart Array P410i (512MB Cache und BBU) geplant.

Da sollen dann jeweils 4 Stk SSD im Raid 10 an jeden der beiden Controller.

Zusätzlich brauchts dann noch einen Datensilo für die sonstige Daten und Maschinen bei denen die Performance keine große Rolle spielt.
Da hätte ich z.B.: an 4 Stk HGST Travelstar 7K1000 EA 1TB, SATA im Raid10 gedacht.

Dazu noch eine Frage, bei SSD am Raidcontroller bringt der WB Cache ja keinen Vorteil mehr und ist duch den Verwaltungsaufwand eher sogar ein Nachteil oder?
Kann am P410i den WB Cache pro RaidSet eingestellt werden oder nur pro Controller?

Lg Franz