[Sammelthread] ZFS Stammtisch

[you]

Kannst Du nicht das proxmox ZFS nativ nutzen und mit napp-it verwalten? Das lässt sich doch Dank gea's Mühen auch unter Linux installieren und nutzen?

Nur SMB dann evtl etwas umständlich..

Das wäre sicherlich eine Möglichkeit. Ich möchte den Hypervisor aber nicht mit "artfremden" Funktionen umkonfigurieren und den PVE so native wie möglich halten. Die benötigten Services bilde ich in VMs ab, da ich aus Platzmangel alles in einem Geräte/Server packen möchte/muß.

Ich würde am liebsten wieder zurück auf ESXi, da läuft es ja auch so. ESXI = Hypervisor, VM = NAS Appliance auf OmniOS/napp-it. ABER: Ich brauche die Erfahrung mit PVE und die Möglichkeit, damit auch daheim zu arbeiten, weil ich es auf der Arbeit nutzen darf.

Mich irritert, dass OmniOS in der Doku ja schreibt: "OmniOS works well within a virtual machine environment such as Virtualbox, VMware, Xen, Hyper-V, KVM or Bhyve." Und unter KVM ist es mir noch nicht gelungen und wenige andere, die überhaupt über dieses Setup geschrieben haben, haben ebenfalls wegen Kernelproblemen aufgegeben.

EDIT: TrueNAS Core läuft unter Proxmox mit den beiden durchgereichten HBAs ohne Probleme.

 

[Green7]

Mal eine kurze frage zwischen durch: Normal werden doch 10% des Rams (bei mir 32 GB gesamt)als "Schreib Cache" benutzt. Kann man das editieren ?
Mir ist die Schreibperformance zu gering
Wenn ich z.b 30 GB auf den Pool Schreibe (4x 8 TB WD) habe ich die ersten 3 GB nen speed um die 1000 MB/s (10 GBE) und der Dropt dann auf so 150 MB/s
Ich hätte lieber 50% des Rams als Schreib Cache.

 

[gea]

Die Tuning Variable (in /etc/system) wäre zfs_dirty_data_max

http://dtrace.org/blogs/ahl/page/3/

Ich glaube aber dass das kontraproduktiv ist. Erstmal fehlt der RAM dann fürs readcache und dann ist sehr viel mehr verloren wenn das System crasht. Auch wäre ein 16G cache sofort voll, wenn nur 150MB/s abfließen.

Der RAM Schreibcache dient dazu kleine io z.B. 4k-128k zu vermeiden und kleine io als größeres Packet zu schreiben.. Bei größeren io ab ca 256k ist der Performancegewinn des Schreibcaches normalerweise minimal und man erreicht die sequentielle Performance des Pools. Dass der Pool hier nur sequentiell 150MB/s kann (Performance einer einzelnen Platte) ist das eigentliche Problem. Kommt das dadurch zustande dass sync aktiviert ist oder sind es msr Platten? Selbst ein Raid 10 müsste > 200 MB/s können, ein Z1 > 300 MB/s sequentiell.

 

[Green7]

Alles klar , ich habe zwischenzeitig mal das Autotune Aktiviert (Truenas 12) und einmal neugestartet, jetzt komme ich auf Lesend ~500 Mb/s und Schreibend ~320 Mb/s

 

[you]

Mich irritert, dass OmniOS in der Doku ja schreibt: "OmniOS works well within a virtual machine environment such as Virtualbox, VMware, Xen, Hyper-V, KVM or Bhyve." Und unter KVM ist es mir noch nicht gelungen und wenige andere, die überhaupt über dieses Setup geschrieben haben, haben ebenfalls wegen Kernelproblemen aufgegeben.

EDIT: TrueNAS Core läuft unter Proxmox mit den beiden durchgereichten HBAs ohne Probleme.

OmniOS läuft bei mir jetzt auch seit zwei Tagen, virtualisiert unter proxmox. Bisher ohne Probleme.

ABER:

Das System stürzt weiterhin nachvollziehbar ab, wenn ich meinen IT-flashed H310 (also 2008er, meine HDDs, Firmware 20.0...7) durchreiche. mpio enabled/disabled spielt keine Rolle.

Wenn ich OmniOS ohne HBA oder mit dem onboard IT-flashed 3008er betreibe (meine SSDs), dann scheint es zu laufen. Ich teste das jetzt mal eine zeitlang, auch mit Replikation zwischen meiner TrueNAS VM (mit 2008) und OmniOS/napp-it (mit 3008) via ZFS send. Mal sehen, ob das unter Last stabil bleibt.

 

[kandamir]

Hallo zusammen,
mal wieder eine Frage zu ZFS. Backup Szenario. Ich möchte die Änderungen seit dem letzten Backup an einen Backup-Pool senden. Der zuletzt gesicherte Snapshot ist snap1, seither gab es auf der Quelle weitere Snapshots, der neueste heißt snap2. Ich musste zuerst lernen, das Ziel-Dateisystem nicht noch einmal separat zu verschlüsseln, sondern den initialen Snapshot raw zu senden. Verschlüsselung wandert dann ja gleich mit. Nun sende ich also raw einen inkrementellen Stream. Die Daten scheinen auch übertragen zu werden, zumindest teilweise. Dann kracht mit das Shellskript weg, welches das ganze durchführt. Hier die relevante Passage:

zfs send -w -RI Data/filesystem@snap1 Data/filesystem@snap2 | pv -rtab | zfs recv -F Backup_USB/filesystem
1.03MiB 0:02:39 [6.62KiB/s] [6.62KiB/s]
Assertion failed: 0 == nvlist_lookup_string(props, zfs_prop_to_name(ZFS_PROP_KEYLOCATION), &stream_keylocation), file ../common/libzfs_sendrecv.c, line 2716, function recv_fix_encryption_hierarchy
./back.sh: line 34: 21197 Done                    zfs send -w -RI $quellfs$back_newest_snap $source_newest
     21198                       | pv -rtab
     21199 Abort                   (core dumped) | zfs recv -F $zielfs/$FS_name

pv habe ich dazwischen geschaltet, um eine einfache Fortschrittsanzeige zu haben, das hat bislang immer ganz gut geklappt.

Hat jemand einen Tipp, was da schief geht? Ich bin etwas verunsichert, ob die Daten vollständig am Ziel angekommen sind...

 

[Bzzz]

Hat jemand weitergehenden Lesestoff für Meta Devices?

Devices can be added to a storage pool as meta devices. These devices
store copies of critical metadata which needs to be accessed in a non-
sequential manner. This functionality is especially useful for dedupli-
cation entries. Since copies of the metadata are also written to the
main storage pool, I/O errors to this device can be recovered and this
device does not have to be mirrored.

To create a pool with meta devices, specify a meta vdev with any number
of devices. For example:

# zpool create pool c0d0 c1d0 meta c2d0 c3d0

Multiple meta devices can be specified, and they can be mirrored, but
they cannot be part of a raidz configuration.

Meta devices can be added, replaced, attached, detached, imported, and
exported as part of the larger pool.

Das ist im Netz irgendwie ziemlich dünn beschrieben und mir ist nicht klar, ob das jetzt eine super Sache für nicht ständig laufende, plattenbasierende zpools wäre (ohne Dedup), oder nur in Sonderfällen überhaupt was bringt.

 

[asche77]

Fände ich auch spannend, meine mich aber vage zu erinnern, dass es nicht wirklich was brächte...

Oder ist das ein Special vdev? Dazu gibt's viel, auch tests von gea auf napp-it.org.

 

[gea]

Das meta vdev ist eine Oracle Solaris Besonderheit für originales ZFS:

zpool - man pages section 8: System Administration Commands

zpool - configures ZFS storage pools The zpool command configures ZFS storage pools. A storage pool is a collection of devices that provides physical storage and...

docs.oracle.com

Meta Devices
Devices can be added to a storage pool as meta devices. These devices store copies of critical metadata
which needs to be accessed in a non-sequential manner. This functionality is especially useful for deduplication
entries. Since copies of the metadata are also written to the main storage pool, I/O errors to this device can
be recovered and this device does not have to be mirrored.

  To create a pool with meta devices, specify a meta vdev with any number of devices. For example:
# zpool create pool c0d0 c1d0 meta c2d0 c3d0

Multiple meta devices can be specified, and they can be mirrored, but they cannot be part of a raidz configuration.
Meta devices can be added, replaced, attached, detached, imported, and exported as part of the larger pool.

Bei Open-ZFS gibt es stattdessen special vdevs. Die dienen dazu Daten aufgrund ihrer Struktur auf ein special vdev zu schreiben, Diese strukturellen Besonderheiten können sein:

- Metadata
- Small io oder io mit recsize kleiner einem Schwellwert
- Dedup Tabellen

Einen Performancegewinn hat man für diese Datentypen beim Lesen und Schreiben

https://www.napp-it.org/doc/downloads/special-vdev.pdf

Ansonsten hat man zur Performancesteigerung beim Lesen:
- Arc (Ramcache für Metadata und random io)
- L2arc (SSD Cache, erweitert Arc), kann durch Read ahead sequentielle Daten beschleunigen
- persistent L2Arc (Inhalt übersteht Reboot), neuere ZFS Systeme z.B. OmniOS 151038 long term stable
https://github.com/omniosorg/omnios-build/blob/r151038/doc/ReleaseNotes.md

Performancesteigerung beim Schreiben
- Ram (Solaris 5s Schreiben, Open-ZFS 10% RAM/max 4GB)
- Slog (Absicherung des Ramcaches bei aktiviertem sync write)

 

[kandamir]

@gea hast Du evtl. eine Idee, warum zfs recv mit core dump abstürzt? Das hier

Assertion failed: 0 == nvlist_lookup_string(props, zfs_prop_to_name(ZFS_PROP_KEYLOCATION), &stream_keylocation), file ../common/libzfs_sendrecv.c, line 2716, function recv_fix_encryption_hierarchy

scheint mir einen Hinweis zu liefern, mit dem ich aber nichts anfangen kann und auch eine Internet Recherche hat mich hier nicht wirklich weiter gebracht. Fehlen Dir noch Infos, um das bewerten zu können?

Danke im Voraus und einen schönen Sonntag noch!

 

[gea]

Mit der Meldung kann ich leider auch nichts anfangen außer dass es etwas mit Verschlüssellung zu tun hat. Mit dem Coredump können die Illumos/OmniOS devs dann etwas anfangen.

Wenn auf beiden Seiten ein aktuelles OmniOS 151036 stable ist, dann

- wenn es einen Wartungsvertrag mit OmniOS gibt, sich da melden
- ohne Wartungsvertrag eine Mail an Omnios-discuss oder illumos-discuss bzw. illumos-dev schicken
- wenn es sich um einen eindeutigen Bug handelt, einen Bugreport bei Illumos Issues erstellen

Maillisten:

Topicbox

Bugs:

Issues - illumos

Redmine

www.illumos.org

Dabei angeben:
- OS Version, Pool aktuell
- Quell und/oder Zieldateisystem verschlüsselt?
- zfs send und receive Befehl
- sonstige Besonderheiten und Vermutungen

 

[martingo]

U.2 und M.2 sind die einzigen Optionen

Intel® Optane™ DC SSD Reihe – Produktinformationen, Dokumente,...

Produkte der Intel® Optane™ DC SSD Reihe anzeigen. Hier finden Sie Produktspezifikationen, technische Dokumentation, Downloads und Support und mehr von Intel.

www.intel.de

Gibt es einen sinnvollen Grund, wieso bei 100GB die M.2 Variante signifikant teurer ist, als die U.2 Variante? (intel.de UVP: 283,71€ zu 173,79€). Man sollte doch meinen, das separate Gehäuse macht die Produktion aufwendiger, als die simple Platine. Performance sollte doch identisch sein, oder?
Die U.2 SSDs passen logischerweise nicht in 2.5" SAS/SATA Trays, d.h. ich benötige zwingend noch eine Adapterkarte. Bzw. im Mirrorpärchen dann zwei Adapter.

Sollte zwingend ein Mirror eingesetzt werden? Ich würde mal vermuten:
als SLOG: nein (ist ja nur eine Protection für "Strom weg")
als special vdev: ja (da dort auch exklusiv Daten liegen)
Ist das so korrekt?

 

[Luckysh0t]

Gibt es einen sinnvollen Grund, wieso bei 100GB die M.2 Variante signifikant teurer ist, als die U.2 Variante?

Die M.2 war nie wirklich lieferbar - hat ewig gedauert bis sich ein Kumpel dann doch die U.2 Version gekauft hat. Schätze mal dass es daran liegt.

 

[gea]

Gibt es einen sinnvollen Grund, wieso bei 100GB die M.2 Variante signifikant teurer ist, als die U.2 Variante? (intel.de UVP: 283,71€ zu 173,79€). Man sollte doch meinen, das separate Gehäuse macht die Produktion aufwendiger, als die simple Platine. Performance sollte doch identisch sein, oder?
Die U.2 SSDs passen logischerweise nicht in 2.5" SAS/SATA Trays, d.h. ich benötige zwingend noch eine Adapterkarte. Bzw. im Mirrorpärchen dann zwei Adapter.

Sollte zwingend ein Mirror eingesetzt werden? Ich würde mal vermuten:
als SLOG: nein (ist ja nur eine Protection für "Strom weg")
als special vdev: ja (da dort auch exklusiv Daten liegen)
Ist das so korrekt?

Wenn ein Slog ausfällt, wird auf das onpool logging umgeschaltet.
Man hat also anschließend lediglich eine geringere Performance. Lediglich wenn bei einem Absturz gleichzeitig das Slog defekt wird, gibt es einen Datenverlust.

Bei einem special vdev ist das anderes. Da liegen exklusiv z.B. die Metadaten. Fällt das vdev aus, ist der Pool verloren. Da ist dann 2way/3way Mirror Pflicht.

ps
Optane DC4800 gibts nicht mehr lange!
Anschließend gibts nur noch DC 5800 (viel schneller und viel teurer),

Intel Optane DC P4800X with Memory Drive Technology Discontinued

With the new P5800X and PMem 200 launch, the Intel Optane DC P4800X and accompanying Memory Drive Technology Plans are being discontinued

www.servethehome.com

 

[martingo]

Danke Dir Günther. Mehr ausgeben muss nicht sein - ich weiß ehrliuch gesagt selbst noch nicht, was ich will und brauche 🙃

Mir ist im großen und ganzen klar, was die unterschiedlichen Typen "Caching" machen - mir ist aber noch nicht klar, was bei mir das sinnvollste wäre. Vielleicht kannst Du mich auch in die richtige Richtung lenken?
Wichtig wäre mir vor allem um die Beschleunigung des Pools HDD01 im daily use, aber ich würde das aktuelle Setup meines Haupt-Servers trotzdem vorab einigermaßen schildern, vielleicht denke ich auch in die falsche Richtung. Server ist ein HPE ML350p gen8 mit zwei Xeons, 192GB RAM und Platz im Überfluss (denke acht oder zehn PCIe von x1 bis x16 Steckplätze, von denen bisher nur einer für eine Mellanox Karte belegt ist, die per DAC am Switch hängt).
An Käfigen sind aktuell ein 4x 2,5" an einem P420i, sowie ein 8x 2,5" und ein 6x 3,5" an je einem HBA H220. Platz wäre noch für ein 8x2,5 oder 6x3,5 - beide Cases vorhanden, aber HBA fehlt noch. Denke aber nicht, dass ich das aktuell brauche.
Server hängt mit einem Bein an einer USV, mit dem anderen Bein am normalen Stromnetz.

Hypervisor ist primär ein ESXi 7, läuft auf dem P420i Controller mit zwei einfachen 128GB SSDs im RAID1. Zusätzlich liegen auf diesem internen Datastore paar ganz elementare VMs ohne viel IO (Storage, primärer DC auf WS2019Core, USV, Backup). Platz ist damit auch ziemlich am Limit (85%).

Die Storage VM hat aktuell 64GB RAM
Auf der Storage VM laufen drei primäre Pools (HDD01, SAS01 und SSD01):

Auf den beiden SSD01 (2x Crucial MX500 500GB im Mirror) und SAS01 (5x HPE 1TB SAS im RaidZ2) laufen hauptsächlich VMs und deren Arbeitsdaten (steigt noch, z.B. soll auf den SAS01 noch der SCCM mit Datenbank und WSUS Daten - 5TB bräuchte ich da aber nicht). Den SAS01 Pool habe ich vor allem in der Größe, weil die 1TB SAS Platten eh da sind. Aktuell primär für unwichtigere VMs genutzt.

Der HDD01 Pool ist etwas mein Sorgenkind. Eigentlich der wichtigste Pool, weil dort alle Nutzdaten liegen. Vom Dokumentenmangementsystem über Homemedia bis zum Filmarchiv. Aufgeteilt in drei ZFS Dateisysteme, um die unterschiedlichen Backup-Zyklen und Aufbewahrungswünsche besser steuern zu können. Bisher sind dort 2x 8TB Red verbaut, eine dritte steckt im obigen Screenshot gerade drin und wird wechselweise mit einer anderen extern verwahrt. Eine Red des 8TB Mirrors meldet nun moderate SMART Fehler und nachdem beide auf die fünf Jahre zugehen, habe ich mir zwei WDC/HGST Ultrastar DC HC530 14TB besorgt. Diese habe ich die letzten Tage gründlich durchgetestet und sehen in Ordnung aus.

Allerdings ist bei beiden die Schreibperformance erwartungsgemäß wieder recht mau:

Meine Frage ist nun konkret: wie helfe ich den beiden am besten auf die Sprünge? Wird in Summe wahrscheinlich etwas besser sein, als bei den 8TB Red, aber nichtmal GBit kann man damit auslasten. Ich habe keinen speziellen Usecase - eben daily use. Besonders auf den Senkel geht mir der HDD01 Pool, wenn ich vom Rechner etwas auf die Freigabe verschiebe. Sei es eine einzelne ISO mit paar GB oder eine SD-Karte der Spiegelreflex ausleere (viele Dateien, á 8-20MB). Lesend ist es ähnlich, aber nachdem die zu lesenden Daten wirklich ständig wechseln, würde ich das mal ausklammern, da nicht wirklich behebbar und ja eh spürbar schneller.

Meine Gedanken sind nun (wobei ich das gerne völlig ergebnisoffen halten würde):
- Nehme ich nun eine Optane als Slog her, dass ich flott wegkopieren kann? Bei 64GB RAM, von dem aktuell ca. 50GB für ZFS genutzt werden, kann ich auch nur maximal 50GB hierfür auslasten?
- Ich kopiere im daily-use (ohne Migrationen etc.) sicher nie mehr als 20-30GB auf einmal auf den Server.
- Obwohl ich mit der Performance meiner VMs zufrieden bin, widerstrebt es mir ein Stück weit, "schweineteure" Optane für reine Nutzdaten herzunehmen und die VMs laufen auf den MX500 SSDs
- 100GB sind nicht viel, aber was mache ich mit dem Rest, wenn ich es als Slog für HDD01 nutze?
- macht ein Special Vdev mehr Sinn? Habe ich da granular Einfluss, was auf welchem vdev liegt? Kann ich sogar mehr vdevs nutzen und die Verteilung on-demand ändern? Wilder Mix aus HDD, SAS und SSD?
- oder KISS? Je mehr vdevs im Pool, desto komplexer und im Fehlerfall aufwendiger wiederherzustellen
- je weniger ich ausgeben muss, desto besser - ich habe aktuell keine wirkliche Handlungsnot und nach den beiden 14TB Platten würde ich mein Spiellimit mal ungefähr bei 450€ ansetzen (2x P4800X U.2 100GB á 180€ + 2x PCIe Adapter á 50€).

Viele Grüße
Martin

Nachtrag wg. 3-way Mirror: den würde ich ausschließen, mein 2-way ist ausschließlich Redundanz und wenn ich paar Tage brauche, bis ich wieder am Schließfach war oder meine Daten von Glacier geholt habe, dann ist das nicht schön und mit Arbeit verbunden, aber die Welt geht davon nicht unter.

 

[asche77]

Besonders auf den Senkel geht mir der HDD01 Pool, wenn ich vom Rechner etwas auf die Freigabe verschiebe. Sei es eine einzelne ISO mit paar GB oder eine SD-Karte der Spiegelreflex ausleere (viele Dateien, á 8-20MB). Lesend ist es ähnlich

1. SLOG dürfte da nichts bringen, ausser Du hast den HDD-Pool auf "sync always" gestellt.
2. RAM ist genug da.
3. Du brauchst v.a. mehr IOPS also entweder mehrere Festplatten-Mirror oder musst auf SSDs umstellen. Zeitgleich steigt damit auch die sequentielle Performance (mehr Platten bzw. kein Einbruch durch Fragmentierung / innenliegende Spuren bei SSD).
3b. Ob ein special vdev was bringt --> siehe Unterlagen von gea. Es spricht einiges dafür (metadata, small blocks) aber ich have vage Erinnerung, dass der tatsächliche Effekt hinter dem erhofften deutlich zurück blieb.
4. Oder Du suchst/baust Dir ein System mit "storage tiering".
5. Leseperformance könnte künftig von einem L2ARC profitieren, da der ja jetzt "permanent" cached und nicht nach jedem Neustart neu befüllt werden muss.

 

[martingo]

Hi,

danke Dir fürs Feedback. Ich versuche, mal passend zu beantworten:

1. steht eigentlich alles auf TrueNAS Default - an SSD01 habe ich wohl schon mal rumgedoktert, aber nicht nachteilig:

2. ok, verstehe aber nicht, wieso er ihn im SMB Umfeld nicht hinreichend nutzt. Dass Sync auf Default steht, sollte doch eigentlich bedeuten, dass er CIFS Daten auch notfalls verliert und dafür etwas schneller
annimmt, oder? Bzw nutzt er ihn, aber vielleicht hat TrueNAS eher viel LeseCache im Kopf?

3. naja, da versuche ich gerade, die Balance zu finden, daher die Frage. Ich habe aber in guter Erinnerung, dass ich auf das gleiche Pärchen 8TB WD Red vor drei oder vier Jahren (Datenmenge war annähernd gleich) mit über 100 MB/s (annhähernd 120) auf Bitlocker-verschlüsselte Windows Storage Spaces auf einem Microserver G8 mit 12GB RAM verschoben habe. Ja, Storage Spaces haben ihre Nachteile und ich hatte meine Gründe ,wieso ich auf zfs gwechselt bin, aber so eine gewisse "Grund-Performance" muss doch auch mit zfs und Spindeln möglich sein?? Selbst mein 2-bay QNAP NAS war in meiner Erinnerung flotter.

3b. Ja, gelesen hatte ich dazu schon manches, auch die Unterlagen von Günther schon mehrfach angesehen, aber eine common-daily-use-policy konnte ich leider nicht ableiten. Daher ja auch die direkte Frage.

4. Ist Storage Tiering nicht genau das, wohin die Special Vdevs gehen sollten? Gibt es in den Windows Storage Spaces ja grundsätzlich auch seit WS2016(?) (keine weitere Erfahrung). Ich weiß nur nicht, ob/wie das sinnvoll zu steuern ist. Reine Automatismen haben ja auch ihre Grenzen, wenn der Mensch eigene Überlegungen einbringen möchte.

5. Mehr Leseperformance wäre natürlich auch nice. Wenn wir jetzt mal die VM Pools SSD01/SAS01 außenvor lassen und wir keine Benutzerprofile o.ä. auf der Kiste haben, dürfte diese doch kaum zu beschleunigen sein, oder?

HP bietet doch deren NVMes auch in diversen Auslastungsraten an - kann man nicht auch ein Art "Cache"-Empfehlung für gemischte Dateisysteme abgeben?

https://buy.hpe.com/de/de/options/drives-storage/server-solid-state-drives/hpe-nvme-mainstream-performance-mixed-use-solid-state-drives/p/1012730302

VG Martin

 

[asche77]

Ich habe aber in guter Erinnerung, dass ich auf das gleiche Pärchen 8TB WD Red vor drei oder vier Jahren (Datenmenge war annähernd gleich) mit über 100 MB/s (annhähernd 120) auf Bitlocker-verschlüsselte Windows Storage Spaces auf einem Microserver G8 mit 12GB RAM verschoben habe. Ja, Storage Spaces haben ihre Nachteile und ich hatte meine Gründe ,wieso ich auf zfs gwechselt bin, aber so eine gewisse "Grund-Performance" muss doch auch mit zfs und Spindeln möglich sein?? Selbst mein 2-bay QNAP NAS war in meiner Erinnerung flotter

Dann liegt das Problem vielleicht eher bei TrueNAS oder dem Netzwerk? Die Platten sollten 100MB/s schon wegschreiben können über SMB (jedenfalls bei einer großen Datei).

Kleine Dateien werden immer langsam (er) sein wegen overhead + latency Netzwerk und SMB Zugriff, selbst bei 10G NICs, vgl diverse c't Tests.

 

[gea]

Prinzipiell ist ZFS langsamer als alte Dateisysteme wegen Prüfsummen und doppelter Metadaten (mehr Daten, mehr Processing), wegen CopyonWrite (selbst wenn in einer Textdatei nur ein Byte geändert werden muss wird immet ein Block in recsize geschrieben). Auch verteilz ZFS Daten gleichmäßig über die vdevs. Hat Vorteile bei großem Storage, hat Nachteile bei einem einzelnen sequentiellen Stream.

Ausgleichen ja teils überkompensieren kann man das mit Caches. In erster Linie den Arc Lesecache. Der nimmt sich ca 70% des freien Speichers und verbessert Lesen der Metadaten und random io. Hilft wenig bei sequentiellen Daten und nichts bei erstmaligem Lesen. Da gehts schnell auf die reine Plattenperformance bei mixed load (ca 80-150 MB/s je Platte). Eine aktuelle große Platte wenn sie nicht gerade MSR ist (meiden für Raid wie der Teufel das Weihwasser) sollte aber lesend und schreibend immer > 1Gb Netzwerk sein.

Die erste Möglichkeit, Performance zu verbessern wäre ein Raid-10 statt Mirror. Bringt rechnerisch 100% mehr Leistung.

Weitere Optionen
L2Arc: Erweitert den Arc Ram Lesecache. Man kann read ahead aktivieren. Bringt etwas bei sequentiellen Daten. Den größten Schub bringt das neue ZFS Feature persistent L2Arc. Da wird der Cache beim Reboot nicht gelöscht. Sollgröße eines L2Arc max 5x RAM.

Slog: Wenn man sync write aktiviert bricht die seqentielle Schreibleistung einer guten mechanischen Platte von sagen wir mal 150 MB/s auf 15 MB/s ein. Ein gutes Slog (Optane 4801) verbessert Schreibraten bei einem leistungsfähigen Pool mit 1000 MB/s unsync auf 500 MB/s sync (ohne Slog 50MB/s). Da der RAM Schreibcache per default 10% RAM, max 4GB ist, müssen nur diese 4GB x 2 gesichert werden. Minimalgröße eines Slog ist daher ca 8GB (Das hatte das legendäre ZeusRAM Slog auch gerade).

Ohne sync bei Filerbetrieb: Stürzt der Server ab, ist die Datei die gerade geschrieben wird, defekt. ZFS bleibt immer intakt. Lediglich wenn sie schon vollständig im Schreibcache liegt, ist sich sicher - vorrausgesetzt der Schreibcache ist sicher. Dazu brauchts sync write und ein Slog wenn das auch noch halbwegs schnell sein soll. Mit einer Optane 4801 als slog kann man 10G schreibend mit sync auslasten. Wenn man fremde Dateisysteme auf ZFS hat (iSCSI, VMs) besteht ohne sync immer die Gefahr eines korrupten Dateisystems darauf.

Eine weitere Performancesteigernde Massnahme ist ein schnelles special vdev Mirror. Damit zwingt man Daten aufgrund von Eigenschaften wie small io, recsize < Schwellwert, Metadate oder Dedupdata auf des special vdev. Wirkt wie Tiering nur intelligenter. Der Nutzen hängt aber stark vom Workload ab. Bei einfachen Benchmarks sieht man wenig Verbesserrung. Man kann sich aber Workloads vorstellen wo das drastisch Performance verbessert (Multiuser mit viel random io und kleinen Dateien, Dedup).

 

[zos]

@gea: Da Intel sein Angebot an Optane-Produkten in der Art ausdünnt, dass lediglich die, wie @martingo schrieb, “schweineteuren“ übrig bleiben, hast Du einen Überblick über vergleichbare Alternativprodukte anderer Hersteller mit weniger schmerzhaften Preisen?

 

[the_pi_man]

Eigentlich wollte ich einen neues ZFS-Server aufsetzen und als Platten 6x 14TB Ironwolf Pro nutzen. Leider kann ich die Platten nicht mehr so günstig bekommen wie gehofft und frage jetzt welche Probleme auftreten können wenn man die Ironwolf mit EXOS mischen würde... Bin gerade echt gefrustet... 5 Ironwolf hatten bereits den Weg zu mir gefunden...

Tja wer nicht hören will... Nun sind es eben 7 Platten (5 x Ironwolf pro und 2 Exos) geworden. Den Umstieg von Solaris 11.3 auf Truenas habe ich leider nicht hinbekommen. Bei Einlesen des unter Truenas erstellten Pools hat mir Solaris immer Fehler geworfen. Und umgedreht geht es ja gar nicht. Also hatte ich den Versuch gestartet Solaris in Version 11.4 auf eine neue Bootplatte zu installieren. Ging... fast. Das über IPMI eingebundene Image wurde erkannt und das Installieren ging bis 97% gut und dann nix mehr. Mehrfach versucht.. nix. Also läuft eben alles unter 11.3 weiter... Zumindest die Repikationsjobs sind ordentlich gelaufen mit 19 Platten gleichzeitig an einem Rechner...
Das nur mal so als kleine Annekdote.

 

[gea]

@gea: Da Intel sein Angebot an Optane-Produkten in der Art ausdünnt, dass lediglich die, wie @martingo schrieb, “schweineteuren“ übrig bleiben, hast Du einen Überblick über vergleichbare Alternativprodukte anderer Hersteller mit weniger schmerzhaften Preisen?

Die Alternativen
Sata: Intel DC 37x0
SAS: WD SS530 mit 3, besser 10 dwpd
NVMe: Intel P3700 und neuerere schreiboptimierte NVMe mit plp

Optane DC 48/58 spielt allerdings in einer eigenen Liga

 

[kandamir]

Mit der Meldung kann ich leider auch nichts anfangen außer dass es etwas mit Verschlüssellung zu tun hat. Mit dem Coredump können die Illumos/OmniOS devs dann etwas anfangen.

Wenn auf beiden Seiten ein aktuelles OmniOS 151036 stable ist, dann

- wenn es einen Wartungsvertrag mit OmniOS gibt, sich da melden
- ohne Wartungsvertrag eine Mail an Omnios-discuss oder illumos-discuss bzw. illumos-dev schicken
- wenn es sich um einen eindeutigen Bug handelt, einen Bugreport bei Illumos Issues erstellen

Maillisten:

Topicbox

Bugs:

Issues - illumos

Redmine

www.illumos.org

Dabei angeben:
- OS Version, Pool aktuell
- Quell und/oder Zieldateisystem verschlüsselt?
- zfs send und receive Befehl
- sonstige Besonderheiten und Vermutungen

Danke, @gea für die Rückmeldung. Ich habe inzwischen bei omnios-discuss eine Anfrage gestartet, leider ohne Rückmeldung. Insgesamt scheint da kaum was los zu sein... weiterhin habe ich Omnios noch aktualisiert auf r151036v - hat leider auch nix geändert. Bin ziemlich ratlos, weil ich somit kein verschlüsseltes Backup anlegen kann, was aber ziemlich dringend nötig ist. Ich hab zwar einen unverschlüsselten Stand, der ist aber noch auf den gleichen Platten. Von Sicherheit kann man da kaum reden und mir ist ziemlich mulmig in der Magengegend... kann das wirklich sein, dass quasi ein Key-Feature nicht funktioniert? Verschlüsselte Snapshots an einen anderen Pool senden? Ich mach doch hier sicher keinen Firlefanz - aber vielleicht was verkehrt?

Vielleicht kann ja jemand helfen. Was mache ich in meinem Skript? Ich iteriere durch alle Filesysteme meines Quell-Pools und prüfe, ob es das Filesystem im Ziel-Pool schon gibt. Falls nein lege ich es an mit zfs send -w source_pool/filesystem@initial_snap | zfs recv dest_pool/filesystem
Überlegung dabei ist: Quellsystem ist bereits encrypted, mit -w wird raw übertragen, damit sollte das Ziel identisch verschlüsselt sein. Korrekt?
Da nun der erste Snap am Ziel ist, kann nun der Rest inkrementell übertragen werden. D.h. Ich ermittle auf dem Ziel den neuesten vorhandenen Snapshot (snap1 - alles was älter ist, muss also schon im Zielpool liegen - nur das neuere muss übertragen werden). Also zfs send -w -RI source_pool/filesystem@snap1 source_pool/filesystem@snap2 | pv -rtab | zfs recv -F dest_pool/filesystem

Passt die Syntax? Oder mache ich da was verkehrt? Vielleicht noch ein Hinweis: Die Filesysteme waren nicht immer verschlüsselt. Irgendwann habe ich die Filesysteme neu angelegt - mit Verschlüsselung - und dann alle Snapshot nach ähnlichem Schema wie hier übertragen.
Weiterer Hinweis? Die Filesysteme sind über Passwort-Datei Verschlüsselt. Diese liegt - aktuell noch - im Home Verzeichnis von root. Soll bei Gelegenheit mal auf einen USB Stick o.ä. wandern.

In dem Zusammenhang: im Rahmen meines OmniOS Updates musste die Kiste natürlich wieder gebootet werden. Und wie vor ein paar Wochen waren danach alle Shares weg. Und noch weiter: die gecryptetem Filesysteme waren zwar nicht gelocked (aufschließen hat also geklappt), aber alle gecrypteten Filesysteme waren nicht gemountet. Und vermutlich infolge dessen auch nicht per NFS/SMB geshared. Warum werden die gecrypteten Filesysteme zwar aufgeschlossen aber nicht gemountet?

Ne Menge Fragen und Unklarheiten - das mit dem Backup wäre mir mit am wichtigsten, da,it ich das endlich zum Laufen bekomme und wieder eine Sicherung auf einem separaten Medium habe. Außerdem muss ich dringend den Platz frei machen, den die unverschlüsselten Versionen der Filesysteme in dem Pool verbauchen (auf dem Pool ist dadurch nämlich wiederum kein Platz mehr für Backups von Clients... Rattenschwanz...).

Danke nochmals an @gea und alle anderen, die ggf. helfen können!

 

[asche77]

Der Hinweis hilft Dir vermutlich nicht, aber: Statt eines eigenen Skripts könntest Du auch einfach eine der bewährten ZFS sync Pakete nehmen - zrepl, zrep, syncoid/sanoid, znapzend, ...

Ob die mit verschlüsselten Systemen klarkommen weiss ich nicht.

 

[gea]

Die zfs send Syntax sieht ok aus.

Zum Mount und enc Handling.
Open-ZFS hat da noch nicht den Komfort von Solaris mit Original ZFS. Bei Key Management insbesondere nach Reboot ist noch Handarbeit oder Scriptunterstützung nötig. Dafür kennt Solaris das raw send nicht.

Prinzipiell sollte raw send funktionieren. Ich würde mal das recursive send -R weglassen. Wegen der Keyvererbung kann da was schiefgehen. (Immer nur bei verschachtelten verschlüsselten Dateisystemen den Key auf das oberste Dateisystem setzen)

 

[asche77]

@kandamir, gerade neues OmniOS update in r36 - eine Änderung zu encryption (hilft Dir vermutlich aber nicht):

omnios-build/doc/ReleaseNotes.md at r151036 · omniosorg/omnios-build

Build system for OmniOS. Contribute to omniosorg/omnios-build development by creating an account on GitHub.

github.com

Release Notes for OmniOS v11 r151036​

r151036x (2021-04-14)​

Weekly release for w/c 12th of April 2021.

This update requires a reboot

Changes​

• curl updated to 7.76.1
• Changing the encryption key on a ZFS dataset with clones did not update the clones themselves, rendering them inaccessible.
• SMB shares from an lofs mount would fail.
• Reaping many process with shared mappings of files on ZFS was extremely slow.
• In rare cases, a kernel panic could occur during system boot due to a race condition in the mlxcx driver.
• The pkg depot server would periodically hang when accessed over low-latency connections.
• The dma mailer could spin when trying to create a new local mailbox.

 

[kandamir]

Moin zusammen!

Die zfs send Syntax sieht ok aus.

Zum Mount und enc Handling.
Open-ZFS hat da noch nicht den Komfort von Solaris mit Original ZFS. Bei Key Management insbesondere nach Reboot ist noch Handarbeit oder Scriptunterstützung nötig. Dafür kennt Solaris das raw send nicht.

Prinzipiell sollte raw send funktionieren. Ich würde mal das recursive send -R weglassen. Wegen der Keyvererbung kann da was schiefgehen. (Immer nur bei verschachtelten verschlüsselten Dateisystemen den Key auf das oberste Dateisystem setzen)

Ich bin heute Morgen mal dazu gekommen, hier weiter zu arbeiten. Das Weglassen des recursive send (-R) hat geholfen. Da ich keine verschachtelten Filesysteme habe, sollte das also erstmal kein Nachteil sein, oder?
Komisches Gefühl habe ich trotzdem noch, denn ich würde schon erwarten, dass ein recursive send auch geht. Naja, so tut's jetzt erst einmal...

@asche77 Danke für die Hinweise auf die Pakete. Ich hänge tatsächlich nicht am eigenen Skript (das hat sich eher bei der Automatisierung ergeben, meine unverschlüsselten Filesysteme in verschlüsselte Filesysteme zu übertragen). Ich werde mir die auf jeden Fall mal anschauen. Auch das Update werde ich bei Gelegenheit einspielen.

Danke für Eure Tipps! Schönen Sonntag noch!

 

[gea]

Wenn es keine geschachtelten verschlüsselten Dateisysteme gibt, mit -R aber auch enthaltene Snaps (und Clones) übertragen werden (die eventuell früher einen anderen Schlüssel hatten), so könnte das aktuelle Update auf OmniOS 151036x stable tatsächlich was bringen da hier genau ein Problem bei diesem Sonderfall behoben wurde.

ps
Prinzipiell ist inkrementelles zfs send ein relativ einfaches Sync Verfahren. Grundsätzlich kann man das gut scripten. Kompliziert wird es wenn man Snap Historie und Log Management oder remote high Perfomance Multi-Server Betrieb hinzufügen möchte. Bei meinem eigenen Script in napp-it steckt da 90% des Aufwands, also z.B. in den keep und hold Fähigkeiten wie behalte letzte 10 Snaps oder die der letzten 10 Tage oder 24 Snaps je Stunde für den aktuellen Tag, 7 Tages Snaps für die aktuelle Woche, 52 Wochen Snaps für aktuelles Jahr, 12 Monats Snaps aktuelles Jahr etc.

 

[kandamir]

Ich werde das OmniOS Update auf jeden Fall einspielen, jetzt läuft aber erst mal das komplette Backup auf eine separate Platte.

Die Snaps nehme ich derzeit noch komplett mit und kümmere mich noch nicht weiter um das Löschen alter Snaps. Zwischenzeitlich hatte ich die automatischen Snaps auch wieder abgeschaltet, das werde ich dann wieder aktivieren. Backup auf Remote-Server kommt auch noch. Liegt noch etwas Arbeit vor mir...

 

[Shihatsu]

Vielleicht hier nochmal meine Frage:
Moin, ich hab mal ne Frage zu SMB von einer Proxmox-VM.
Szenario: Proxmox-Host ist mit Gigabit an einem Switch. Auf dem Host läuft eine TrueNAS-VM. Diese VM hat einen HBA durchgereicht, dieser hat 5 Platten angeschlossen, die im TrueNAS als raidz2 organisiert sind. Ich bekomme nur maximal 65MB Transferleistung auf den darin enthaltenen Datapool bzw. seine Datasets. Woran liegt das? Das ist dann doch etwas arg langsam...