NAP-IT AiO Storage Konfiguration (SLOG/L2ARC)

[Tandaril]

Hallo zusammen,

ich hatte vor geraumer Zeit bereits einen Topic eröffnet wo es um die Zusammenstellung eines neuen ESX Server mit NAP-IT als Storage VM ging:

[Kaufberatung] ESXi Hardware + napp-it VM

Die ersten Schritte sind erledigt und jetzt geht es um die Storage VM sowie das dahinterliegende Storage. Als Basis habe ich mir das NAP-IT AiO ova von gea gezogen und auch bereits ausgerollt.

Kurz Zum Aufbau:

• Die Storage VM liegt auf einer Intel Optane die als VMFS6 formatiert am ESX hängt
• Die Storage VM hat 16GB
• An die Storage VM ist bereits der onboard LSI Controller mit IT Firmware durchgereicht
• An dem Controller hängen 3 x WD RED 3TB als Storage

Die WD REDs sollen als RAIDZ-1 laufen und darauf am Ende die gesamten VMs liegen.
Die Intel Optane ist primär gewählt worden um SLOG und L2ARC zu implementieren.
Zusätzlich würde ich gerne den gesamten Pool auch noch verschlüsseln.

Um es gleich richtig zu machen würde ich euch gerne um Unterstützung bitten.


Für SLOG sowie L2ARC muss jeweils eine eigene HDD zu der Storage VM auf der Optane hinzugefügt werden, ist das korrekt?
Welche Größe sollte die SLOG Partition haben? Nachdem was ich gelesen habe sind 15GB passend, ist das korrekt?
Die L2ARC sollte ca. 5 x RAM betragen, was dann ca. 80GB wären? Passt das?
Worauf sollte ich achten, wenn ich den Pool erstelle und mit welchen Werten sollte dieser angelegt werden?

Habt Ihr da ein gewisses Best Practice?

Ich hoffe Ihr könnt hier etwas Licht ins Dunkel bringen.


Vielen Dank schon einmal im Voraus.


Viele Grüße
tandaril

 

[asche77]

VMs auf die WD Red ist ziemlich ungeschickt!

Spar dir den SLOG und L2ARC und packe die VMs direkt auf die optane (als virtual Disk an omnios durchgereicht).

Mehr RAM für die storage VM.

Backups der VMs kann napp-it dann ja auf die WD Red legen.

Das wäre in etwa best practice in deiner Konfiguration.

 

[zos]

Also meinem Verständnis nach ist es gerade an einem Pool mit herkömmlichen HDDs sinnvoll ein (Optane-) SLOG zu ergänzen. Idealerweise liegen VMs sicher direkt auf SSDs. Da, wie Tandaril schreibt, die Optane bewusst für SLOG / L2ARC gewählt wurde, vermute ich mal, dass diese nicht unbedingt genug Kapazität hat, um noch diverse VMs zu beheimaten. Außerdem wäre diese als virtual disk nicht unter primärer Kontrolle der StorageVM via durchgereichtem HBA. Sofern also keine weiteren SSDs für die VMs verfügbar sind wäre m. E. die Lösung HDDs + SLOG (20 GB) vetretbar. Wenn noch eine 4. WD Red 3TB verfügbar wäre, konnte man ein RAIDZ-10 daraus bauen, welches ich einem RAIDZ-1 vorziehen würde.

 

[asche77]

Mit den IOPS kann es halt eng werden bei Platten-RAIDZ ...
SLOG sollten schon ca 8-10GB reichen - der RAM schreibcache ist bei 16GB RAM ja auf 1.6GB beschränkt. Aber Trambahner, gea & co. wissen das besser.
SLOG und L2ARC werden dann in der Tat als eigene virtuelle disk an die storage VM durchgereicht.

 

[zos]

Da habe ich mich nicht präzise genug ausgedrückt: Mir ging es darum, dass die VMs auf einem separaten zpool unter Kontrolle der StorageVM liegen sollten. Das aber wäre für das SLOG / L2ARC bei nur einer vorhandenen Optane, auf der gleichzeitig auch die StorageVM liegt, unter ESXi nicht möglich, so dass SLOG / L2ARC hier nur als virtualle disk machbar sind.

 

[besterino]

ESXi kann (inzwischen) von durchgereichten NVMe Booten. D.h. du brauchst nur einen absoluten Mini-Speicher um die Settings der VM abzulegen und kannst dann die Storage VM direkt auf die Optane installieren und von dort Booten. Ggf. musst Du die dann in der StorageVM für SLOG und L2Arc partitionieren - damit kenne ich mich nicht gut genug aus.

Ich war selbst ganz überrascht & beeindruckt, als Windows nach ein zwei reboots (zur Geräteinitialisierung) als VM klaglos von einer m.2 NVME im Passthrough hochfuhr, auf der vorher Windows bare Metal installiert war.

In diesem Fall war also kein nerviger Umweg über Konvertierung p2v nötig. Nett!

 

[Trambahner]

@Tandaril: Nur zur Sicherheit: ein Slog ist >kein< Schreibcache, der den Schreibzugriff auf einen langsamen Pool beschleunigt. Schreibcache ist einzig der Dram-Puffer. Zwar werden dort Zufallszugriffe geclustert und dann so seriell wie möglich weggeschrieben, aber ein Plattenpool als Lager für OS-Images für VMs bleibt trotzdem massiv langsam. Erst recht, wenn mehrere VMs drauf I/O ausführen und auch noch kleine und langsame Red-HDDs im Spiel sind. Da ist die Gefahr, das dies laggen wird, sehr sehr hoch.
Die Optane als Slog sichert lediglich Syncwrites für den Fall eines Crashs ab, so dass ZFS die Schreibzugriffe bestätigen kann, ohne dass die Daten auf dem Ziel-Pool liegen sondern noch im Ram sind.

Für die VMs hol Dir SSDs und richte die als zweiten Pool (als Mirror z.B. für Ausfallsicherheit, KEIN RaidZ für VMs nach Möglichkeit, wenn es kiene leistungsstarken SSDs sind) in der Storage-VM ein. Dort packe dann die anderen VMs drauf . Sprich VM-Systemimages auf den SSD-Pool, die Nutzdaten auf den HDD-Pool.
Achtung, keine Billig-SSDs nehmen!!!!! Intensive Schreibzugriffe mit ZFS Syncwrites können Samsung 850pro (also Ober- bis Spitzenklasse Consumer-SSD) auf wenige MB/s Durchsatz runterziehen! Das haben hier im Forum schon einige selbst erfahren.
Auch selbst 960/970 Evo/Pro halten keine permanenten Schreibzugriffe aus. D.h. bei Consumer-Laufwerken genug Platz freilassen ("overprovisioning") und entweder ein Slog auf den SSD-Pool für Syncwrites legen oder Sync disablen.
Ansonsten helfen da nur der Anwendung entsprechende Datacenter-Laufwerke, die für permanente Schreibbelastung hin ausgelegt sind.


Beispiel: Ich hab auf meinem Server, über Storage-VM und durchgereichter Hardware, einen Zpool mit Raidz2 (6x14TB HDD) für Nutz- und Mediadaten sowie Client-Backups und einen Zpool aus 3 Mirrorpärchen SSD (6*SM863 960GB), also quasi ein Raid10 aus 6 SSD, für VM-Images, Datenbank-Tablespaces und Kleinkram-Nutzdaten (die mit hoher Nutzungsfrequenz). Parity-Daten auf den Datenträgern erhöhen dabei nicht die Leseleistung. D.h. ein Raidz2 aus 6 HDD bietet lesend den sequentiellen Durchsatz von 4 HDD; 2 sind ja Parity.

Raidz1/2/3 ist gut für sequentiellen Zugriff auf große Files, aber relativ schlecht für Random I/O. Ideal also für Video, Musik, Bilder, etc. . Random-I/O schreibend auf Raidz bietet >bestenfalls< die Leistung eines einzelnen Laufwerks eines Pools.

Mirrorpärchen bieten die beste I/O-Performance für zufällige Zugriffe und können jederzeit durch anfügen weiterer Pärchen in vergleichsweise kleinen Schritten erweitert werden. Beim Lesezugriff wird dabei von allen Datenträgern gelesen. Random Schreibzugriff verteilt sich auf alle Pärchen eines Pools. D.h. mein o.g. SSD-Pool aus 6 SSD hat schreibend die I/O-Leistung von 3 SSDs, lesend von 6.

 

[JohnnyBGoode]

Vielleicht stelle ich als einfacher Nutzer eine doofe Frage: Weshalb kann man bei ZFS eigentlich keine SSDs als Schreib-Cache für z. B. für Pools verwenden, die auf mechanischen Laufwerken liegen?

 

[asche77]

1. Weil dann die Datensicherheit davon abhängt, dass diese SSD nicht krepiert.
Oberstes Lemma von ZFS ist ja "wenn ich melde, dass geschrieben wurde, dann würde das auch auf Platte geschrieben!!!". Genau das ist unvereinbar mit dem parken von Daten auf einem Cache.
2. Weil ZFS aus der Unternehmenswelt kommt, wo man im zweifel von hoher schreibleistung ausgeht. Wenn aber immer volle Kanne geschrieben wird, kommt es nur auf die Leistung des endgültigen Speichers an.
3. Weil man RAM Cache hat und der viel mehr bringt.
4. Weil es darauf ankommt, random writes zu vermeiden und in seuqentielle Last umzuwandeln. Dafür reicht der RAM Cache. 48GB RAM rein, dann braucht's keine SSD.
5. Weil man neuerdings mit Special vdevs kleine (random) writes gezielt auf einen schnellen SSD Pool umleiten kann .
6. Weil es ein riesen SSD _Cache_
einfach nicht bringt.
7. Weil ZFS dann vielleicht doch etwas zu alt ist

....
Die Lösung in Unternehmensumfeld hieße dann eher tiered storage mit Data mover (sowas macht unraid glaube ich auch, verkauft es aber als "Cache").

 

[gea]

Sehr schön zusammengefasst.

Ergänzend kann man sagen, dass im Gegensatz zu No-Raid Systemen bei denen nur eine Platte aktiv ist, ein ZFS Pool sequentiell ein mehrfaches schneller ist als eine SSD. Da eine SSD dvor zu schalten wäre quasi die angezogene Handbremse.

Wenn man sich Performancetests mit unterschiedlichen Blockgrößen ansieht, merkt man, dass Platten (und ZFS Pools) bei Blockgrößen ab ca 1 MB bereits volle Performance haben. Man muss also vor allem die kleinen Blöcke vermeiden und das kann ein mehrere GB großer RAM-Schreibcache perfekt. Bei ausreichend RAM ist ein ZFS Schreibcache bis zu 4GB groß. Ist der zu Hälfte gefüllt so wird er sequentiell geschrieben. Die andere Hälfte übernimmt als Cache. Eine Vergrößerung würde wenig bringen.

Die professionelle Alternative bei "Big Storage" war bisher Tiering nicht im Sinne von Cache sondern indem man aktive Daten auf einen schnelleren Bereich des Arrays legt. Nachteil ist der Performanceverlust und die Inflexibilität des nötigen Umkopierens. Intel hat da einen intelligenteren Ansatz in ZFS integriert, die special vdevs. Das ist z.B. ein NVMe Mirror in einem Platten-Pool. ZFS kann dann spezielle Daten aufgrund besonderer Merkmale wie dedup-Tabelle, Metadaten, kleine io oder einzelne Dateisysteme auf dieses schnelle vdev zwingen. Ein sehr interessanter Ansatz (in aktuellem ZoL und Illumos/OmniOS verfügbar), siehe Tests in Punkt 8, special_vdev in https://napp-it.org/manuals/index.html und eine Top-Erghänzung zum RAM-Schreibcache.

 

[JohnnyBGoode]

Danke für die Belehrung zu den special VDEVs!

Das war mir noch unbekannt - und ja, wegen der Ausfallsicherheit hätte ich sowieso zwei Optanes als Mirror für diesen "Schreibcache" verwendet.

 

[gea]

Bei den special vdevs bitte unbedingt darauf achten, dass die denselben ashift haben wie der Pool (meist ashift=12 für 4k Platten). Manche nvme setzen ashift=9. Das kann sehr problematisch sein, wenn man die special vdev wieder aus dem Pool entfernen möchte. Aktuelles Open-ZFS crasht dann, siehe https://www.illumos.org/issues/11840

Wenn man also special vdevs einem Pool hinzufügt, die manuell auf den Pool ashift einstellen (kann man nachträglich nicht ändern!)

 

[Tandaril]

Vielen Dank erst einmal für eure ganzen Antworten.

Wie zos schon vermutet, der Platz auf der Optane reicht nicht aus um die gewünschte VMs zu beherbergen. Die WD REDs sind schon vorhanden und stammen aus meinem vorherigen Proxmox Server, ebenfalls mit ZFS. Da war die Performance zumindest soweit okay.

Ich würde es gerne einfach darauf ankommen lassen und testen ob mir die Performance ausreicht. Wenn nicht werde ich mir direkt Gedanken über SSDs machen und nicht mehr in drehende Platten investieren.

Wie könnte man den Pool unter napp-it am besten aufbauen um das meiste aus den REDs heraus zu holen?
So wie ich es verstanden habe würde ich der napp-it VM folgende Platten auf der Optane (VMFS6) zwei weitere Platten anhängen:
- 1 x SLOG: 10GB? (Wenn es etwas bringt setze ich das gerne höher)
- 1 x L2ARC 80GB? (Ausrecheind oder lieber größer?)

Wenn es aus eurer Sicht enorm mehr bringt, kann ich den RAM evtl. auch noch auf 24GB erhöhen.

Welche Einstellungen sollten bei der Erstellung des Pools gewählt werden?

 

[gea]

Mit drei PLatten ist ein Z1 naheliegend. Phi mal Daumen gibt das:
IOPS ca 100 (wie eine Platte) lesen und schreiben
mixed load ca 200 MB/s (100 MB/s je Platte) lesen und schreiben

Die Hauptalternative wäre noch eine 3 TB PLatte kaufen und Raid-10 zu machen:
IOPS ca 400 lesen und 200 schreiben
mixed load ca (100 MB/s je Platte) 400 MB/s lesen und 200 MB/s schreiben

Da Optane kein Trim und keine Garbage Collection benötigt, braucht man auch kein Overprovisioning. 10 GB wären für Slog ausreichend.

L2Arc sollte 5x-max 10x RAM haben. Mit ausreichend RAM ist aber die Performanceverbesserung minimal wenn man nicht sehr viele User hat. 24GB RAM statt z.B. 16 GB wird mehr bringen.

 

[Tandaril]

Vielen Dank für die Info.

Damit kann ich auf jeden Fall schon mal los laufen und das ganze Testen und soweit zum laufen bringen.
Sollte die Performance nicht passen wird denke ich mal ein Wechsel auf SSD erfolgen bevor ich eine weitere drehende Platte anschaffe.

Habt Ihr da eine direkte Empfehlung? Die Überlegung da wäre dann auf 4 x 1,92 TB zu schwenken. Hier würde ich dann auch wieder auf RaidZ1 setzen wollen um die Kapazität zu halten. Das sollte dann bei SSDs nicht mehr so schlimm sein oder?

 

[asche77]

Die Überlegung da wäre dann auf 4 x 1,92 TB zu schwenken.

Klingt nach overkill und falscher Geld-Allokation.

1) Erstmal: mehr RAM! Das bringt am meisten.
2) Nur die VMs auf SSD. Daten sind auf der Platte gut aufgehoben, vor allem wenn Du viel RAM reinsetzt.
3) Weiss nicht, wie groß Deine VMs so sind -- ich vermute, Dir reicht auch ein einfacher mirror mit kleineren SSD (480GB, 960GB)?
4) Dran denken: Enterprise/Server SSD kaufen (da Du schon eine optane hast, ist das aber uU etwas weniger relevant - habe dazu keinen Vergleich/Erfahrungswerte).
5) Backups/snapshots der VMs kann man laufend & automatisch auf die Daten-HDD sichern, so dass Du dafür nicht unbedingt massig Platz auf der SSD brauchst.

Hier würde ich dann auch wieder auf RaidZ1 setzen wollen um die Kapazität zu halten. Das sollte dann bei SSDs nicht mehr so schlimm sein oder?

Ja. RAIDZ1 gilt bei SSD - anders als bei HDD - in der Tat als unproblematisch. Du hast zwar weiterhin nur die iops einer Platte, aber eben wegen SSD ca. 1.000 bis 10.000 statt ca. 100 bei der HDD.

 

[gea]

Man sollte bei SSD noch beachten, dass Desktop SSD keine Powerloss Protection haben. Bei einer mechanischen Festplatte (wenn der Plattecache deaktiviert ist) bedeutet ein bestätigter Schreibvorgang dass Daten tatsächlich auf Platte sind. Bei einer SSD können die noch im RAMcache der SSD sein. Auch organisisert die SSD selbständig Daten im Hintergrund. Ein Absturz könnte da einen Datenverlust zur Folge haben, insbesondere bei VM Dateisystemen bei denen das Dateisystem des Servers keine Kontrolle über die VM Dateisysteme hat.

Wenn man also SSDs nimmt, sync aktiviert und eine hohe Sicherheit möchte (ist ja auch der Grund für ZFS) so sollte man bei den SSDs auf Powerloss Protection achten oder SSD/NVMe nehmen bei denen man ein sehr gutes Verhalten annehmen kann z.B. Optane 900 bei denen Intel kein PLP garantiert.