NAS einrichten, aber wie ?

[tcg]

Hi,

leider habe ich, trotz inzwischen >30 Jahren IT Erfahrung, immer noch Probleme ein "vernünftiges" NAS mit ZFS einzurichten.
Ich habe viel Halbwissen, möchte es aber mal gescheit machen.
Ich bräuchte also mal Hilfe beim Brainstormen...

Als HW nehme ich / habe ich folgendes:
*) HP Microserver Gen8 (link)
*) E3-1240v2 (link)
*) 16GB RAM (2*8GB, 1333MHz, ECC)
*) 16GB Intel Optane NVME 2280 im PCIe Slot (leider nicht bootbar)
*) 240GB SSD (ODD, Toshiba glaube ich)
*) 16GB Usb-Stick (intern, SanDisk)
*) 4 * ST16000NM001G (4 * 16TB SATA)

Ich würde nun folgendes machen (wollen):
*) FreeNAS bootbar auf den Usb-Stick installieren
Wie sieht es hier mit Wear aus ? Also: ist der Stick dann schnell kaputt wegen zu häufigem Schreiben ?
*) Die SATA Platten als Z2 Pool anlegen (laut hier dann ca. 30TB netto)
das BIOS wird dazu dann auf AHCI eingestellt (nicht der "Spezial-B120i-Mode")
*) die Optane als ZIL (die kompletten 16GB)
ZIL ist eine Art Write-Cache (glaube ich), aber ich hatte auch schon gelesen dass so viel gar nicht benutzt wird, immer nur "ein paar Sekunden"...
*) die SSD als L2ARC (die kompletten 240GB)
Das ist dann wohl der Read-Cache, die SSD ist keine Enterprise-SSD (ist also nicht Powerfail-safe), sollte ja aber beim Lesen egal sein.
*) kein dedup
Platz ist ja genug da und dedup braucht wohl das meiste RAM

Habe ich das so richtig verstanden ?
Macht das Sinn ?
Was habe ich übersehen ?
Gibt es andere Empfehlungen ?

Optional:
*) ESXi bootbar auf den Usb-Stick installieren
Läuft bisher super in meinem anderen Würfel...
*) FreeNAS als Autostart VM auf die ODD-SSD installieren
*) Die SATA Platten in die FreeNAS-VM durchreichen und als Z2 Pool anlegen
*) die Optane als ZIL (die kompletten 16GB)
wenn möglich auch an FreeNAS durchreichen, geht das ?
*) auf der SSD eine Partition (fixed Size) als L2ARC (dann evtl. nur 200GB)
*) kein dedup

Lieber Option 1 oder 2 ?

Meine Signatur habe ich schonmal angepasst ;-)

bye, tcg

 

[asche77]

Am einfachsten:
1. FreeNAS auf die ODD-SSD installieren.
2. Optane weglassen. Du brauchst für ein normales NAS (Dokumentenablage, Photos, Musik, Videos, ...) kein ZIL. (ZIL ist kein Schreibcache!). Zudem ist die 16GB-optane m.W. eh nicht wirklich geeignet dafür (anders als die "großen").
3. Die 4x SATA Platten als RAID10 einrichten. Gleiche nutzbare Größe wie bei RAIDZ2, ähnlich sicher, aber doppelte IOPS = mehr "Schwuppzidität".
4. Don't bother with L2ARC or dedup.
5. Fertig.

 

[tcg]

Meine Erfahrungen mit ZFS war bisher, naja, recht bescheiden.
Die Geschwindigkeit (allerdings mit recht alten Platten als Test) war wirklich grausam.

Ich will schon was vernünftiges haben, vor allem wenn auch die ein oder andere (Test-) VM drauf laufen soll (deswegen eher Option 2: mit ESXi), die Optane könnte/sollte dabei schon helfen.

Nur RAID und kein ZFS will ich eigentlich nicht mehr einsetzen, ich habe zwar recht gute Ergebnisse damit (siehe hier, das bleibt auch erstmal so wie es ist), aber ZFS ist mir deutlich lieber (Selbstheilung ! Keine BBU ! ...).

Klar, dedup ist echt nicht nötig.

"ZIL ist kein Schreibcache" ?? Ich habe ZFS anscheinend nicht ganz verstanden... Was ist ZIL denn dann ?
Hier steht: "Das ZIL (ZFS intent log) ist ein Schreib-Cache ..."
Und "Der L2ARC ist ein Lese-Cache ..." und da ich 200GB SSD frei habe würde ich das schon einplanen wollen.

RAID 10 mit 3 Platten ist schwierig, das ist dann "degraded by design" ;-)

 

[bluesunset]

Verwende bitte kein Raid6 (z2) aus nur vier Platten, wenn du meinst, du könntest dir ein Backup damit sparen! Bei nur vier Platten und Speicherbedarf von zweien ist ein Raid10 immer zu bevorzugen, außer es wären wirklich fragwürdige Endkunden Platten, dann würde man eher von den Platten abraten.
Beim RAM 32GB, welche normal maximal unterstützt wurden für den Prozessor. ZFS verwendet diesen gerne als Lesecache. Eine langsamere 240GB SATA SSD als zusätzlichen Lesecache ist recht fragwürdig, wenn du nicht gerade etwas in Richtung www Cache aufbauen willst, was ich mal bezweifle.

 

[tcg]

Nein, Backup ist was anderes als Redundanz ! Das ist klar !
Ich denke momentan auch eher an Z1. Das sind dann >40TB netto, das reicht mir für immer ;-)
Raid will ich eigentlich nicht mehr einsetzen, ZFS sollte sicherer sein ("Selbstheilung" statt nur Erkennung von Problemen)...

Die Platten (ST16000NM001G) sind soweit ok denke ich, das sind Nearline-HDs, damit habe ich (in "klein", 5TB Variante, ST5000NM0084) super Erfahrung gemacht (bisher). Der "Kleine" ist auch mein Backup Server für wichtige Daten.

Der HP Microserver kann leider nur 16GB ansprechen, sollte aber hier (ist für Zuhause) auch locker reichen, ich bin zu 90% auch der einzige Benutzer, Frau und Kinder werden eher selten drauf zugreifen, das Teil idelt fast nur.

Nach etwas Basteln gestern habe ich auch ein Problem mit meinem Plan gefunden:
Ich kann nicht einzelne Platten an eine VM (FreeNAS) durchreichen, sondern nur den kompletten Controller, also alle 4 SATA Platten und die ODD-SSD.
Damit habe ich kein Platz mehr für den VM Datastore...
Also habe ich jetzt mal gespielt und die Optane nicht an die VM gegeben (was prinzipiell geht, habs probiert), da sind jetzt 2 Partitionen drauf, eine 8GB "thin" für FreeNAS und eine 3GB "thick" für das/den ZIL.
Hier steht etwas Info zum Zil, ist also wohl doch nicht so richtig ein Schreib-Cache. Nur sowas in der Art...
However, 3GB sollten schon reichen, ZFS speichert ja nur ein paar Sekunden (10 ?) dort ab (bei max. 115MB/s Netzwerk-Speed sind das bei 3GB ~30 Sekunden), aber wohl auch nicht alles, Sync-Writes gehen wohl direkt auf den Pool.
Dann in FreeNAS NFS eingerichtet und das dann wieder an ESXi exportiert. Jetzt habe ich nur noch das Problem dass ESXi diesen Share zwar sieht, aber nur ReadOnly...

Ich spiele noch, mach Spaß ;-)

 

[asche77]

"RAID10" meinte einen zpool mit 2 vdevs, beide vdevs als two-way-mirror.

ZIL ist kein Cache!, sondern das ZFS Intention Log. Du meinst das SLOG = Separate (ZFS Intention) LOG. Ohne SLOG wird - bei sync writes! - erst das ZIL auf den Pool geschrieben und dann erst die Daten in echt. SLOG hilft Dir dabei, dass sync writes (NFS, nicht SMB) nicht total langsam werden, indem man Log device und Data device trennt. Relevant grds nur wenn Du schreibintensive VMs oder Datenbanken nutzt.

Schreibcache = RAM!

Daher Empfehlung für einfach: ohne SLOG und ohne L2ARC starten.

Für VMs und esxi brauchst Du dann noch einen HBA zum durchreichen, oder Du nimmst proxmox.

 

[tcg]

Danke asche77, ich lerne immer noch dazu.

"Schreibcache = RAM!" ist aber richtig gefährlich.
Da gibts Platten mit PLP und trotzdem wird RAM benutzt ? Uiui... Als Lesecache, ja, als Schreibcache, uiuiui.

"HBA zum durchreichen" hab ich schon, der B120i im Server ist an die FreeNAS-VM durchgereicht, geht super (solange man einen Xeon hat und nicht den original G1610T)

"ohne SLOG und ohne L2ARC starten": gestartet bin ich schon, bin auch schon einen kleinen Schritt weiter, also mit SLOG/L2ARC jetzt ;-)

Ich schreibe auch gerne alles hier auf damit ich nicht der einzige bin, der was lernt !

20h Basteln am Wochenende...
Meine Frau ist schon wieder, naja, fast etwas unhappy darüber, aber alle paar Jahre muss ich einfach mal ;-)
Beruflich mach ich inzwischen nicht mehr so viel Technik, da brauche ich das einfach manchmal.

Also, kurzes Update:
Mit der Optane/16GB wird es arg eng, die läuft immer wieder voll.
Ich habe zuerst den ESXi Swap und Host-Cache augeschaltet, dann auch noch alle Snapshots von der Optane löschen müssen.
Und auch meine tolle Idee, ein ZIL/SLOG (ich habe den Unterschied immer noch nicht kapiert) auf NVME musste ich kürzen, ist jetzt nur noch 1GB.
Die Lösung: eine 480GB Kingston SEDC1000BM8 statt dessen, so ziemlich die einzige bezahlbare NVME-M.2 SSD mit PLP (ja, ich bin etwas paranoid).
In den HP Microserver passt nicht mehr rein, der hat nur 1 PCIe Slot frei !
Dafür werde ich nun die ODD-SSD ausbauen, brauche ich nicht mehr.

Plan nun:
*) ESXi (6.7-u3) auf 16GB USB-Stick (intern), ESXi läuft ja 100% im RAM, ist also kein Wear-Problem zu erwarten (anders als bei FreeNAS auf nem Stick !)
*) 1* SEDC1000BM8 im PCIe Slot (als Datastore mit FreeNAS (11.3-u1) 16GB Bootdisk, 64GB SLOG, 256GB L2ARC, alle 3 Thick-provisioned !)
*) 4* SATA Platten an die VM durchgereicht als Z1
*) ein storagepool "data"
*) darauf je ein dataset "smb", "nfs" und "iscsi"
*) "iscsi" dann (siehe unten) als Haupt-Datastore für ESXi

Eine Lösung für

dass ESXi diesen Share zwar sieht, aber nur ReadOnly

habe ich gefunden.
Ein "chmod 777" auf diesem dataset hat gefehlt !

Noch ne Frage:
SMB ist async, NFS ist sync, richtig ?
Was stellt man denn da am besten in ZFS ein ?
Je nach dataset ?
Also "data/smb"=async, "data/nfs"=sync und "data/iscsi"=sync ?

Und gleich die nächste Frage:
Ich exportiere aus der FreeNAS VM ein ZFS dataset per NFS an ESXi als Datastore.
Läuft auch recht gut. Auch meine Linux Recher kommen da ran. Passt soweit.
Aber da ich noch nie mit iSCSI gespielt habe überlege ich gerade ob es Sinn macht NFS weiter für die Linux Clients laufen zu lassen, aber für den Datastore iSCSI zu nehmen.
FreeNAS kann das exportieren und ESXi kann das benutzen.
Wenn ich das so machen würde, was für Vorteile / Nachteile hätte das ?
Habe ich es richtig verstanden:
NFS ist eher was für Streams/Files bzw. Thin-provisioning,
iSCSI eher für Block-/Sektordevices bzw. Thick-provisioning für VMs ?
Tante Google meint iSCSI sei (für VMs zumindest) viel schneller (z.B. hier ganz unten bei "Conclusion"), NFS hätte aber andere Vorteile (z.B. hier)
Da bleibt mir ja nicht viel übrig, ich muss mal mit iSCSI anfangen.

Faszinierend ist ZFS ja schon.
In meinem bisherigen "Hauptwürfel" habe ich Nearline-Platten, einen P420 mit 2GB RAM + BBU und 2TB (davon 1TB genutzt) HP SmartCache auf 4*SATA-SSD. Auch ESXi, Ubuntu und WebMin als SMB-Server.
Im neuen Würfel habe ich bisher noch die HD204ui-2TB zum Spielen (>>10 Jahre alt, "Desktop-Zeugs", laaangsam), und das System fühlt sich per SMB sogar eher schneller an ! WOW !

bye, tcg

 

[asche77]

Die Lösung: eine 480GB Kingston SEDC1000BM8 statt dessen, so ziemlich die einzige bezahlbare NVME-M.2 SSD mit PLP (ja, ich bin etwas paranoid).

Ich würde Dir nach wie vor empfehlen, Dich nicht so auf L2ARC / SLOG festzulegen. Vor allem brauchst Du keine 64GB!! SLOG. Auch die 256GB L2ARC dürften Deinen RAM unangenehm begrenzen - Berechnen kann ich das aber nicht.

Ich vermute, dass Du die lausigen 120 IOPS des HDD-RAIDZ1 auch mit noch so viel L2ARC (und SLOG) nicht wirklich kompensieren kannst (Stichwort "LKW-Anhänger mit hochgepimpten Rasenmäher-/F1-Motor ziehen wollen"). Da fehlen mir aber die Erfahrungswerte, da meine VMs schon immer auf einem SSD-Pool laufen (mit PLP), ohne SLOG.

*) "iscsi" dann (siehe unten) als Haupt-Datastore für ESXi

Macht man normalerweise über NFS.

SMB ist async, NFS ist sync, richtig ?

Korrekt.
Das geht nach Zugriff, auf Pool-Ebene brauchst Du da grds nichts einzustellen, wenn Du nicht generell sync ein- oder ausschalten wolltest.

Tante Google meint iSCSI sei (für VMs zumindest) viel schneller (z.B. hier ganz unten bei "Conclusion"), NFS hätte aber andere Vorteile (z.B. hier)

Jein. iSCSI sind keine sync-writes, schon allein deshalb "viel schneller" aber eben unsicherer. Schaltest Du da sync ein, dürfte die Performance bei iSCSI auch deutlich runtergehen. Ich sehe da keine Vorteile in iSCSI bei einem "all-in-one" Konzept wie bei Dir. -- die von Dir genannten Quellen gehen auch von völlig anderen Voraussetzungen aus (zB dezidierte fibre-channel Anbindung des iSCSI im zweiten Artikel).

Da bleibt mir ja nicht viel übrig, ich muss mal mit iSCSI anfangen.

Nein. Müssen wirklich nicht. Vor allem für VMs verlierst Du dann die Möglichkeit der netten snapshots / backups der VMs über ZFS.[/QUOTE]

 

[Helmi20]

Verwende bitte kein Raid6 (z2) aus nur vier Platten, wenn du meinst, du könntest dir ein Backup damit sparen! Bei nur vier Platten und Speicherbedarf von zweien ist ein Raid10 immer zu bevorzugen, außer es wären wirklich fragwürdige Endkunden Platten, dann würde man eher von den Platten abraten.

Eventuell eine Einsteiger Frage, aber wieso lieber Raid 10 als Raid 6 bei 4 Platten? Gilt das nur wenn man sich das "Backup" sparen möchte, oder macht Raid 6 mit nur 4 Platten einfach weniger Sinn? Habe zwar schon danach gesucht und nach daraus resultierenden Verständnis ist Raid 6 bei der Ausfallsicherheit eben vorzuziehen, da es egal wäre welche der 2 Platten kaputt gehen während bei Raid 10 man mit Pech den kompletten Zpool verliert.
Bin gerade selber dabei meine FreeNas Installation mit 4x4TB aufzuziehen und jetzt etwas verunsichert.
P.S. Bei mir ist mittelfristig eine zweite FreeNas Instanz als Offsite-Backup geplant

 

[asche77]

@Helmi20:
RAIDZ2 aus 4 Platten ergibt eher wenig Sinn: Die Sicherheit ist nur "unwesentlich" größer als ein ZFS-RAID10, die IOPS sind aber nur halb so groß, und wenn Du vergrößern willst musst Du alle 4 Platten tauschen statt zunächst nur zwei (oder Du hast noch Plattenplätze frei, was bei tcg aber nicht der Fall ist).

Unsicher RAIDZ2 vs ZFS-RAID10: ein rebuild (resilver) gilt bei mirrors als deutlich schneller und sicherer als bei einem RAIDZ.

 

[tcg]

Vor allem brauchst Du keine 64GB!! SLOG.

Wieder der Beweis: ich kenn mich nicht aus.
Den Unterschied zwischen ZIL (nicht per FreeNAS GUI eingebbar) und SLOG (auch nicht) und LOG (das taucht dort auf, ist aber evtl. SLOG) muss ich mir nochmal antun...

Auch die 256GB L2ARC dürften Deinen RAM unangenehm begrenzen.

Auch sehr interessant, da gibts nen Zusammenhang ?
Ich habe zum Test mal die komplette ODD-SSD (240GB) als CACHE (so nennt sich das in der FreeNAS GUI) genommen, und hatte dann auch auch 10GB RAM (von 12GB zugewiesen) Verbrauch.

Die lausigen IOPS sind nicht so wichtig, das Teil wird eh hauptberuflich NAS sein und VMs nur mal zum kurz Spielen...
Ich wills halt nur mal verstehen...

Macht man normalerweise über NFS.

Dazu habe ich jetzt verschiedene Meinungen gelesen.
Need more input !
"Summary? It’s quite obvious, iSCSI protocol gives higher performance than NFS", je nach Fall 75% besser in seinem Test. Hab den Test aber auch nur überflogen, werde das nochmal genauer lesen müssen.

Schaltest Du da sync ein, dürfte die Performance bei iSCSI auch deutlich runtergehen.

Hmm, ok, kann ich ja mal probieren.
Immer wenn ich was konfiguriert habe erzeuge ich ne Win10 VM und starte CrystalDiskMark darin um zumindest ein Gefühl zu bekommen.

Müssen wirklich nicht.

Doch, ich muss !
Nicht weil es technisch wichtig wäre, sondern für mich, ich wills mal probiert haben und ab besten auch kapiert...

Vor allem für VMs verlierst Du dann die Möglichkeit der netten snapshots / backups der VMs über ZFS

Snapshots macht doch ESXi für mich, auch ganz ohne ZFS...
Würde ich nicht brauchen / benutzen wollen.

Beitrag automatisch zusammengeführt: 09.03.2020

die von Dir genannten Quellen gehen auch von völlig anderen Voraussetzungen aus (zB dezidierte fibre-channel Anbindung des iSCSI im zweiten Artikel).

Ich hab da ja sogar was viel besseres: ein "unphysikalisches" Netzwerk, läuft ja alles auf der selben physischen Kiste...
Hmmm, wird das dann schneller als 1GBit/s ? Oder wird das trotzdem durch den Netzwerkstack gedrängt und daher evtl. begrenzt ?

 

[tcg]

Aha: "... sending the ZIL writes to a Separate ZFS Intent Log or “SLOG”, or simply “log”. ...", hängt also zusammen...
Aha: "ZFS currently uses 16 GiB of space for SLOG. Larger SSDs can be installed, but the extra space will not be used. "
Und wieder was zum Nachdenken: "RAIDZ1 is not recommended for drives over 1 TiB in size"... Ich hab 16TB !

 

[gea]

Nur ein paar Anmerkungen.

ZFS nutzt Ram als Schreibcache (Open-ZFS default 10% RAM, max 4GB, Original Solaris ZFS 5s). Stürzt der Rechner ab. ist der Inhalt verloren sofern man kein sync write aktiviert. Wenn man sync aktiviert wird jeder bestätigte Schreibvorhang protokolliert damit der beim nächsten Reboot nachgeholt werden kann. Diese Protokollierung erfolgt entweder auf dem Pool (ZIL) oder einem speziellen vdev, dem Slog. Da beide nur im Crashfall beim reboot gelesen werden handelt es sich um keinen Cache. Die Funktion ist vergleichbar zum Cache/BBU eines Hardware Raid. Die Größe eines Slog hängt von der Größe des Ramcaches ab. Ist der RAMcache zur Hälfte gefüllt, wird er auf das Slog geschrieben und die andere Hälfte protokolliert weiter. 10 GB ist daher ausreichend. Bei Oracle Solaris und Original-ZFS muss der Cache ca 2 x 5s Schreiben aufnehmen können.

RAM wird auch als Lesecache (Arc) genutzt. Hat man wenig RAM kann man den Lesecache um eine langsamere SSD/NVMe (L2Arc) ergänzen. Da man RAM zum Verwalten benötigt. sollte ein L2Arc ca 5 bis max 10x RAM haben. Mit ausreichend RAM ist ein L2Arc ziemlich nutzlos (bis auf read ahead, das kann minimal was bringen). Oft ist ein special vdev für Metadaten und kleine IO effektiver (gibts bei OmniOS einem Solaris Fork und Linux bei Free-BSD (z.B. FreeNAS) irgendwann im Laufe des Jahres).

Eine 16GB Optane ist aber relativ schwach als Slog, siehe Punkt 8 unter https://napp-it.org/manuals/index.html

iSCSI vs NFS
Viele Programme die NFS nutzen, z.B. ESXi aktivieren sync write per default. Bei iSCSI ist dagegen sync write per default deaktiviert. Bei vielen Vergleichstest wird das nicht beachtet und daher iSCSI bei Schreiben dann erheblich schneller.- Ist aber in beiden Fällen eine Einstellungssache des zugrundeliegenden ZFS Dateisystems. Mit der Einstellung sync=default entscheidet das schreibende Programm (z.B. ESXi) das sync Verhalten. Bei iSCSI die Einstellung writeback-cache. Man kann aber das ZFS Dateisystem auf sync=disabled oder always auf ein bestimmtes Verhalten zwingen.

Unter ESXi braucht man ein Bootdevice. Das kann ein USB Stick sein. Man kann auch eine Storage VM auf einem USB Stick installieren. Ist aber langsam, unzuverlässig und man kann keine bootfähigen Systemsnaps (Bootenvironments) speichern. Außerdem hat man RAM-Swapping und Crash-Protokollierung optional auf dem Bootdevice. Ich würde für ESXi und die Storage-VM immer eine billige (min 80GB) Sata SSD nehmen.

Unter ESXi sollte eine Stoage VM nicht zuviel RAM verbrauchen. FreeNAS (heißt jetzt TrueNAS core)´ist da eher untauglich da es selber bereits 8, eher16 GB möchte. Am sparsamsten was Resourcen für ZFS angeht sind Oracle Solaris (original ZFS) und die Solaris Forks wie OmniOS mit Open-ZFS, https://omniosce.org/ (zur Abwechslung mal ein europäisches Software-Projekt). Zum Web-Management von Solaris und OmniOS gibts mein napp-it (mal was aus DE).

 

[tcg]

Nur ein paar Anmerkungen.

Danke dafür...

...handelt es sich um keinen Cache. Die Funktion ist vergleichbar zum Cache/BBU eines Hardware Raid.

Hmmm, mein P420/2GB+BBU ist ohne Cache sau-langsam, aber mit ist er ganz ok. Also eine Art Cache wie ich ihn mir vorstelle: Pufferung von Schreibdaten, Vorhalten von Lesedaten (mit zusätzlich 1TB SSD SmartCache mit 4 SSDs, quasi im Raid0, ist er echt ok).
Du schreibst "kein Cache" aber auch "vergleichbar mit einem Cache", das verwirrt mich gerade etwas...

10 GB ist daher ausreichend. Bei Oracle Solaris und Original-ZFS muss der Cache ca 2 x 5s Schreiben aufnehmen können.

An welcher Schraube kann ich das (bei FreeNAS) erhöhen ? z.b. 2*10s ? Irgendein Tunable, richtig ?
Gestern habe ich das gefunden: "ZFS currently uses 16 GiB of space for SLOG", habe aber keine ahnung ob das aktuell oder eher 10 Jahre alt ist. Ich plane momentan mal 32GB LOG (ZIL ? SLOG ? ist mir immer noch zu 50% unklar wie das ganz genau intern geht).

RAM wird auch als Lesecache (Arc) genutzt. Hat man wenig RAM kann man den Lesecache um eine langsamere SSD/NVMe (L2Arc) ergänzen. Da man RAM zum Verwalten benötigt. sollte ein L2Arc ca 5 bis max 10x RAM haben. Mit ausreichend RAM ist ein L2Arc ziemlich nutzlos

Da mein Würfel auf 12GB (für die VM) begrenzt ist, plane ich hier mal 100GB CACHE (L2ARC) ein.

Eine 16GB Optane ist aber relativ schwach als Slog, siehe Punkt 8 unter https://napp-it.org/manuals/index.html

Ich nehme an wegen der Schreibrate ? 145MB/s...
Die habe ich eh ersetzt durch eine DC1000B, die ist 4 mal so schnell beim Schreiben (und >3 mal beim Lesen).

iSCSI vs NFS
Viele Programme die NFS nutzen, z.B. ESXi aktivieren sync write per default. Bei iSCSI ist dagegen sync write per default deaktiviert. Bei vielen Vergleichstest wird das nicht beachtet und daher iSCSI bei Schreiben dann erheblich schneller.-

So langsam kapier ich die Unterschiede (Sync, Async, wann was...).
Ich könnte mir auch vorstellen dass es besser für VMs ist ein ZVOL statt eines Datasets zu nehmen, Kompression auszuschalten und die virtuelle Platte "eager zeroed" (also Thick-Provisioned) zu erzeugen. Muss mal spielen wenn ich wieder Zeit habe.

Unter ESXi braucht man ein Bootdevice.

Hab nen USB Stick, und hoffentlich keine Probleme mit Wear (anders als das bei FreeNAS wäre), läuft ja alles aus dem RAM (habe ich irgendwo gelesen, aber mehrfach, schient plausibel zu sein)

Unter ESXi sollte eine Stoage VM nicht zuviel RAM verbrauchen. FreeNAS (heißt jetzt TrueNAS core)´ist da eher untauglich da es selber bereits 8, eher16 GB möchte.

Hat 12GB bekommen, nutzt 10GB davon (als ARC !)...
Allerdings bisher nur mit den uralten Testplatten (4*2TB im Z1).
Seit gestern abend habe ich die neuen drin (4*16TB im Z1), mal schauen was der Unterschied ist.
Ich komm aber wohle erst am Wochenende zum genaueren Testen.

Was ist eigentlich eine gute Stripesize ?
FreeNAS bietet als default 128k an, aber das ist ja abhängig von der Anzahl der Platten, vom Z-Level, von der Sektorgröße (die reale ? oder die "nach aussen" sichtbare ?) und evtl. auch von der HD Größe... Ist die 128k ein einfach ein statischer Defaultwert, oder schon "sinnvoll" berechnet ?

 

[gea]

Cache
Ein Cache verbindet schnelle und langsame Teile eines Computers. Alle Daten gehen durch den Cache. Ein Slog liegt nicht zwischen schreibendem Device und Platten sondern protokolliert lediglich unabhängig vom normalen Datenstrom bestätigte Schreibvorgänge. Ein Slog wird nur im Crashfall gelesen, daher Slog ist kein Cache! ZFS Schreibcash ist RAM und sonst nix.

Bei einem Hardwareraid hat man auch einen Cache zur Performancesteigerung (wie ZFS Ramcache). Damit der im Crashfall nicht verlorengeht hat man da eine BBU/Flashsicherung. Die Funktion dieser Batterieabsicherung übernimmt bei ZFS das ZIL/Slog. ZIL ist onpool. Da der normale Pool z.B. wegen Fragmentierung je nach Füllgrad immer langsamer wird, schreibt man da die Protokolldaten in einen besonderen Bereich des Pools der darauf optiomiert ist (ZIL). Alternativ kann man die Protokolldaten auf ein eigenes Laufwerk (Slog) legen dass dafür besser geeignet ist. Besser geeignet bedeutet niedrige Latenz, hohe dauerhafte write iops bei qd1 und powerloss protection. Normale Desktop SSD/NVMe sind absolut ungeeignet. Gut ist eine (gebrauchte) Intel DC 3700 oder bei aktuellen Sachen eine Intel Optane ab 800p oder eine WD SAS SS530. Den Performanceverlust sync vs async zeige ich in Punkt 8.0 in https://napp-it.org/manuals/index.html

Arc cacht nur random io, keine sequentiellen Daten. Gleiches gilt für L2Arc. Bei VMs und Mediadaten bringt beides nicht soviel. Speziell für VMs braucht an einfach einen schnellen Pool, alternativ ein special vdev (vgl 8.1 in https://napp-it.org/manuals/index.html). Free-BSD (FreeNAS) unterstützt special vdev oder Verschlüssellung aber noch nicht, geht aktuell nur bei OmniOS und ZoL.

Stripesize
Da gibt es kein gut oder schlecht. 128k ist bei ZFS der Defaultwert. Ein größerer Wert bis 1M verbessert z.B. dedup oder verringert Resilverzeiten. Ein kleinerer Wert kann bei Datenbanken oder VMs sinnvoll sein da man damit näher an der Blocksize der Dateisysteme ist. Ich setze bei ESXi Storage meist einen Recsize Wert von 32 oder 64kb. Über Recsize kann man auch steuern ob ein Dateisystem auf ein spezial vdev gezwungen werden soll.

 

[tcg]

Vieeeelen Dank !
So langsam verstehe ich immer mehr.

"Heute um 05:09" ? Huch, du stehst ja noch früher auf als ich !

Ein Slog liegt nicht zwischen schreibendem Device und Platten sondern protokolliert lediglich unabhängig vom normalen Datenstrom bestätigte Schreibvorgänge. Ein Slog wird nur im Crashfall gelesen, daher Slog ist kein Cache! ZFS Schreibcash ist RAM und sonst nix.

Also für mich:
Lesecache: ARC (=RAM) und L2ARC (=NVME) ist rein auf Lesen ausgelegt.
Schreibcache: "... ist RAM und sonst nix" (ZIL/LOG/SLOG ist alles "nur" für Sicherheit)

Besser geeignet bedeutet niedrige Latenz, hohe dauerhafte write iops bei qd1 und powerloss protection. Normale Desktop SSD/NVMe sind absolut ungeeignet. Gut ist eine (gebrauchte) Intel DC 3700 oder bei aktuellen Sachen eine Intel Optane ab 800p oder eine WD SAS SS530. Den Performanceverlust sync vs async zeige ich in Punkt 8.0 in https://napp-it.org/manuals/index.html

Die Kingston DC1000B ist die einzige (relativ) schnelle aber vor allem auch bezahlbare Lösung die ich gefunden habe.
Die hat PLP und eine recht hohe TBW (475TB, bzw. 1/2 DWPD) und sollte als L2ARC (3,2GB/s) sehr brauchbar sein.

Arc cacht nur random io, keine sequentiellen Daten. Gleiches gilt für L2Arc. Bei VMs und Mediadaten bringt beides nicht soviel. Speziell für VMs braucht an einfach einen schnellen Pool

Mein Verständnis:
*) SMB ist async, also bringt (L2)ARC was für die Samba-Shares (aber halt nur lesend).
*) NFS ist sync, also ist die Speed (lesend wie auch schreibend) komplett abhängig von den HDs (keine SSD/NVME/whatever hilft hier). Schade... Gerade für VMs auf NFS wäre das interessant...

 

[Stueckchen]

@tcg Ob dir ein L2ARC was bringt oder nicht kannst du ganz einfach sehen:
Starte ohne und schau auf die ARC hitrate, wenn die quasi konstant >90% ist bringt dir ein L2ARC quasi nix mehr.
Startest du mit L2ARC kann es halt sein, dass du weniger RAM für ARC (L2ARC braucht auch etwas Ram wurde aber auch betreits geschrieben) hast und daher die hitrate runtergeht.

 

[asche77]

ARC / L2ARC gilt für alle Lesezugriffe. Sync oder nicht betrifft nur writes.

 

[tcg]

Hab noch was interessantes gefunden: ZFS sync/async + ZIL/SLOG, explained
und ZFS tuning cheat sheet

Das muss ich jetzt noch 5 mal lesen und verdauen...
Vielleicht schmeiße ich SLOG und L2ARC ja doch wieder raus ?!?
Aber dann war die schöne NVME-SSD ja ganz umsonst :-(

Ja, ist hier irgendwie schon alles mehrfach erwähnt worden, aber ich bin halt irgendwie langsam ;-)

Starte ohne und schau auf die ARC hitrate, wenn die quasi konstant >90% ist bringt dir ein L2ARC quasi nix mehr.

Probier ich mal.
Letztendlich ist das bei meinem spezielle Use-Case (zuhause, selten benutzt, ist mehr eine Ablage als richtig in gebrauch) eh alles nicht so tragisch.
Mich interessierts halt mal im Prinzip.

 

[Gelöschtes Mitglied 304674]

@tcg ich lese hier auch schon ein paar Tage mit, und wollte dich gerade zu diesem Beitrag verweisen:

https://www.hardwareluxx.de/community/threads/zfs-stammtisch.570052/page-353#post-27389830

Dann sehe ich, dass du die Artikel auch bereits gefunden hast.

 

[tcg]

in dem Thread lese ich auch, bin aber erst auf Seite 200 oder so ;-)
Danke !

 

[gea]

Mein Verständnis:
*) SMB ist async, also bringt (L2)ARC was für die Samba-Shares (aber halt nur lesend).
*) NFS ist sync, also ist die Speed (lesend wie auch schreibend) komplett abhängig von den HDs (keine SSD/NVME/whatever hilft hier). Schade... Gerade für VMs auf NFS wäre das interessant...

Nein!

Einen SMB Filer (hat nichts mit SAMBA zu tun, für den multithreaded/ in ZFS integrierten SMB Server in Solarish - der mir persönlich erheblich besser gefällt als SAMBA, gilt das genauso) kann man auch mit sync betreiben. Macht man wegen der reduzierten Performance aber selten, auch wenn es genügend Szenarien gibt bei denen man damit bei einem SMB Filer einen Datenverlust vermeiden könnte. Ein Plattenpool mit einer Optane als Slog ist aber inzwischen so schnell wie ein 10G Netzwerk. SMB + sync könnte also immer interessanter werden wenn man auf höchste Datensicherheit Wert legt.

NFS ist ein anderes Sharing Protokoll. Auch da kann man frei wählen ob man sync möchte oder nicht. Da man NFS fast ausschließlich als Storage für VMs nutzt, ist es naheliegend da sync als default zu verwenden.

 

[miccgn]

Hallo,

ich lese hier mit, während ich in einem anderen Thread mein Wunschsystem für ein kleines, unkritisches Home-NAS zusammenpuzzle, und lerne viel - danke dafür!
Ich habe vor, mir ein NAS mit 2x10 TB in einem ZFS-mirror zu basteln. Als Bootlaufwerk wird eine alte SSD herhalten.

Wenn ich das bis hierhin richtig verstanden habe, wäre es dann doch kein Fehler, einen Bereich dieser alten SSD als SLOG zu verwenden: die Schreibgeschwindigkeit dort wird schneller sein als auf den HDDs, damit werden sync-Writes schneller zurückgegeben. Noch besser wäre es, wenn die SSD "echt schnell" wäre (was für Optane spräche), oder PLP hätte. Ob ich dann mehr sync-Writes forciere, indem ich sync=always setze, ist dann eine andere Frage.


Oder liege ich hier falsch?

 

[tcg]

"alten SSD" und "SLOG" passt nicht (habe ich hier gelernt...). Eher fürs L2ARC, da machts nix aus wenn die mal nicht mehr will.
SLOG muss ja nicht groß sein, eine 16GB Optane würde wohl reichen. Auch wenn die nicht super schnell schreibt (die 16GB Version zumindest), immer noch schneller als "rotating rust".
Gegen einen frankierten Rückumschlag mit 10€ drin könntest du eine haben (ich hab vor einiger Zeit mal einen 10er Pack Optanes bei eBay geschossen, hab noch ein paar hier liegen ;-)

 

[miccgn]

Hallo,
vielen Dank für das Angebot, welches gut klingt! Ich werde allerdings erstmal schauen, ob ich das so zum Laufen kriege, wie ich es mir vorstelle - das von mir vorgesehene Board hat nur einen M.2-Slot, und wer weiß, ob ich da nicht doch eine SSD drin brauche, falls das mit der alten SATA-SSD nicht hinhaut. Erster Anlauf wird dann vermutlich ohne SLOG sein.

Danke aber!!!

 

[Gelöschtes Mitglied 304674]

Da man NFS fast ausschließlich als Storage für VMs nutzt

Wie genau meinst du das?

Mein Plan wäre gewesen die VMs direkt auf einem SSD Pool anzulegen, dann einzelne Ordner für Daten von einem HDD Pool via NFS in den VMs mounten.

 

[besterino]

Genauso meint er das.

Also: VMs (oder der Hypervisor) nutzen den ihnen über NFS zur Verfügung gestellten „ZFS-Speicherplatz“ für weitere Anwendungen.

 

[gea]

Es gibt zwei Verfahren um Dateien eines Servers mehreren Benutzern zur Verfügung zu stellen. Das übliche ist SMB, das Microsoft für Windows entwickelt hat. Es bietet Authentifizierung (Anmeldung) und Authorisierung (Erlaubnis für Zugriff). NFS (network file system) ist eine Alternative die Sun für Solaris entwickelt hat und zwar mit dem Ziel den Zugriff möglichst einfach und schnell zu gestalten bei dem ein Share als Ordner im Dateisystem gemounted wird. Es hat aber keine Authentifizierung (zumindest nicht in der meist genutzten v3) und nur eine rudimentäre Authorisierung (nur auf Basis der ip) und ist damit nur für vertrauenswürdige Netze sinnvoll.

Für einen normalen Filesserver ist NFS v3 damit untauglich. Als Storage für einen VM Server zum Ablegen der VMs aber wohl erste Wahl