[Sammelthread] ZFS Stammtisch

[Happy Hepo]

Snaps halten ja nur einen alten Stand, damit man Änderungen Rückgängig machen kann. Anhand des Namens würde ich vermuten, dass der am 20.12. Letztes Jahr erstellt wurde, wenn du da Hotsnaps getestet hast, passt das ja.
Ich hatte auch die Erfahrung gemacht, dass Hotsnaps absurd viel Platz brauchen, und das schnell wieder gelassen (damals effektiv 500GB Pool)

 

[gea]

Das war der Hinweis!!!
Ich hab immer im .zfs Verzeichnis auf Poolebene geschaut.
Aber es existierte tatsächlich ein Snapshot mit dem Namen nightly-1640037429_2021.12.20.23.47.00 im /ESXi/vm Filesystem.
Der ist 295GB (effektiv 152GB). Ziemlich genau der Platz nach dem ich gesucht habe. Oh mann ... das Problem war wieder mal 50cm vor dem Bildschirm.

Aber was genau ist das für ein Snapshot, bzw. wodurch ist er erstellt worden. Das ist mir noch nicht ganz klar. Ist das ein Snapshot, der aus meinen Tests mit ESXi Hotsnaps resultiert? Kann ich den einfach "destroyen", um den Platz freizugeben und im aktuellen Status zu bleiben?

Der Snap Name läßt darauf schließen, dass er durch einen Autosnap Job erzeugt wurde.

Ansonsten gehören Snaps zu einem Dateisystem. Der Pool selber ist auch ein Dateisystem und nur dessen Snaps liegen in /.zfs. Im napp-it Menü Snapshots kann man aber schnell sehen wo es welche Snaps gibt und welchen Platz die blockieren/belegen. Wenn man Snaps löscht wird der aktuelle Datenstand nicht verändert und die im Snap belegten Datenblöcke wieder nutzbar. Man kann aber nicht mehr auf den früheren Stand zurückgehen z.B. mit ZFS Rollback oder Windows "vorherige Version".

Beitrag automatisch zusammengeführt: 14.01.2022

CIFS Spuckt jedoch nur ~10TB aus. Vielleicht klemmts irgendwo an den Diensten.
In meinem Fall TrueNAS FreeNas, denke jedoch dass es bei dir aehnlich laeuft auf Napp-IT.

Vielleicht kann gea etwas dazu sagen.

Es sind mehrere Aspekte denkbar
- ZFS zeigt bei zpool list die Summe aller Platten als Poolsize an. Davon muss man Platten für Redundanz abziehen
- Die Anzeige des verfügbaren Platzes ist Kapazität-"Platz der durch Snaps oder zvols belegt wird"
- ZFS rechnet in T (Tebibyte) wärend andere Tools in TB (Terabyte) rechnen. Letzteres gibt ca 10% größere Werte.
- Eine ZFS Reservierung verringert den für andere Dateisysteme zur Verfügung stehenden Platz.
- Compress und Dedup können Angaben verfälschen

Als erstes immer nach Snapshots schauen: zfs list -t snapshot

 

[negotiator]

Nach dem Update auf Omnios r151040 kann ich mich per Putty nicht mehr auf der Omios-Maschine mit meinem SSH Zertifikat authentifizieren: "Server refused our key".
Nach Eingabe des (root) Passworts kann ich mich dann problemlos anmelden.
Vor dem Update hat das definitiv funktioniert, an der Konfiguration habe ich nichts geändert - also offensichtlich eine Anpassung über das Update. Wo kann ich da ansetzen? Unter "/etc/ssh" liegt eine "sshd_config.new" mit heutigem Datum, die "sshd_config" wurde jedoch laut Datum nicht geändert...

 

[gea]

Putty als root geht, remote ssh nicht?

Liegt eventuell an neuer OpenSSH Version.

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

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

github.com

Deprecated features in 151040​

• OpenSSH no longer accepts RSA signatures using SHA-1 by default.
• OpenSSH in OmniOS no longer provides support for GSSAPI key exchange. This was removed in release r151038.
• OpenSSL 1.0.x is deprecated and reached end-of-support at the end of 2019. OmniOS has completely transitioned to OpenSSL 1.1.1 and will begin to move to OpenSSL 3 in a future release, but retains the OpenSSL 1.0.2 libraries for backwards compatibility. The 1.0.2 libraries are maintained solely on a best-efforts basis.

Ich würde versuchen Keys neu zu generieren und es damit versuchen.

 

[jonofe]

Ja geht. Eine Scripdatei /var/web-gui/_log/jobs/$id.pre bzw /var/web-gui/_log/jobs/$id.post anlegen ($id=jobid). Das Script wird vor/nach der Replikation ausgeführt.

Ich hab das mal so asuprobiert: Einen Replication Job angelegt und dann eine $ID.pre und $ID.post Datei angelegt. In der $ID.pre werden die ESXI Snapshots gelöscht und angelegt und in der $ID.post Datei werden Sie nur gelöscht und dann der Server runtergefahren.
Die $ID.pre wurde erfolgreich ausgeführt, die $ID.post hingegen nicht. Der Replication Job endete ohne Fehler mit "ok", aber ohne Versuch die $ID.post auszuführen.
Ein händischen Ausführen der $ID.post Datei hat funktioniert. Die ID stimmt auch.

Woran kann das liegen?


Hier das Ende des Logs:

 

[gea]

ich habs nochmal getestet. 1642459747.pre und 1642459747.post werden ausgeführt und stehen auch im last Protokoll
Bei mir sieht das last log dann so aus (siehe Zeile 4/5 des Logs und am Ende)

 

[jonofe]

Bei mir sieht das last log dann so aus (siehe Zeile 4/5 des Logs und am Ende)

Dann schau ich mir das nochmal an ... Danke fürs Testen!

 

[Luckysh0t]

Dann schau ich mir das nochmal an ... Danke fürs Testen!

Mal das banalste, wa mir als Skriptanfänger unter Linux schon öfters passiert ist..Hast du die Datei ausführbar gemacht ? xD

 

[jonofe]

Hast du die Datei ausführbar gemacht ?

Hatte ich auch schon gedacht, *.pre und *.post sind waren aber gleich berechtigt. 700 für user napp-it.

 

[gea]

Hatte ich auch schon gedacht, *.pre und *.post sind waren aber gleich berechtigt. 700 für user napp-it.

Das Script muss nicht ausführbar sein da es via "sh script" gestartet wird. Jobs werden aber nicht als napp-it sondern als root gestartet, Werden die Jobs denn im last Log protokolliert?

 

[jonofe]

Die Job Files...

root@napp-it-backup:/var/web-gui/_log/jobs# ls -la 1642436560.*
-rwx------   1 napp-it  root        6530 Jan 17 18:25 1642436560.last
-rwx------   1 napp-it  root         790 Jan 17 18:25 1642436560.log
-rwx------   1 napp-it  other        337 Jan 17 17:22 1642436560.par
-rwx------   1 napp-it  root        3431 Jan 17 17:25 1642436560.post
-rwx------   1 napp-it  root        2930 Jan 17 17:24 1642436560.pre

Das $ID.post Skript:

root@napp-it-backup:/var/web-gui/_log/jobs# cat 1642436560.post
# sudo ssh -l root host vim-cmd vmsvc/snapshot.removeall [VmId]
# You can delete lines or disable with a '#' at the beginning of a line.
#
ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 121;   # [nappit-VM] TVHeadend_1/TVHeadend_1.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 121 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 121 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] TVHeadend_1/TVHeadend_1.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 122;   # [nappit-VM] SmartHome/SmartHome.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 122 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 122 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] SmartHome/SmartHome.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 123;   # [nappit-VM] mFi Controller/mFi Controller.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 123 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 123 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] mFi Controller/mFi Controller.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 124;   # [nappit-VM] FreePBX 14/FreePBX 14.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 124 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 124 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] FreePBX 14/FreePBX 14.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 125;   # [nappit-VM] Shinobi/Shinobi.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 125 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 125 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] Shinobi/Shinobi.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 126;   # [nappit-VM] EDOMI/EDOMI.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 126 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 126 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] EDOMI/EDOMI.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 127;   # [nappit-VM] Bitwarden/Bitwarden.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 127 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 127 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] Bitwarden/Bitwarden.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 128;   # [nappit-VM] Backup/Backup.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 128 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 128 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] Backup/Backup.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 133;   # [nappit-VM] Windows 10/Windows 10.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 133 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 133 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] Windows 10/Windows 10.vmx

ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.removeall 134;   # [nappit-VM] EDOMI Test/EDOMI Test.vmx
#ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.remove 134 `ssh -l root 192.168.0.201 vim-cmd vmsvc/snapshot.get 134 | ggrep -A 1 'ZFS_autosnap' | sed '1d' | awk '{print $4}'`;   # [nappit-VM] EDOMI Test/EDOMI Test.vmx

ssh root@esxi-backup.feld.home poweroff -d 300

Das $ID.last Log: (lässt sich hier nur als Grafik einbinden aufgrund der HTML Syntax)

Das pre-Skript taucht auf, das post-Skript nicht.

Werde es aber morgen nochmal probieren.

Noch eine Frage: Kann man eigentlich in einem $ID.post Skript auch einen nächsten Replikations-Job anstoßen, um so die Replikationen sequentiell durchlaufen zu lassen und am Ende im letzten Replikations-Job den Server runterzufahren? Wenn ja, wie wäre die Syntax?

 

[gea]

Ich würde die files testweise auf 755 setzen (alle lesen)

Um eine weitere Replication aus dem eigenen Script zu starten:
Anlegen einer Datei: /tmp/nappit/job-replicate_$jobid.request
z.B.: echo 'run_1642459747 1' > /tmp/nappit/job-replicate.request

Inhalt der Datei (erste Zeile):
run_$jobid 1

Zum Herunterfahren: shutdown (man shutdown)

 

[bbott]

Ist das erweitern von ZFS ähnlich belastend wie das Rebuild bei HDD Ausfall? Wie sieht das bei ändern von Z2 auf Z3 aus? Ich frage daher, weil ich überlege erstmal ein kleinen Pool anzulegen und dann zu erweitern.

 

[gea]

Ist das erweitern von ZFS ähnlich belastend wie das Rebuild bei HDD Ausfall? Wie sieht das bei ändern von Z2 auf Z3 aus? Ich frage daher, weil ich überlege erstmal ein kleinen Pool anzulegen und dann zu erweitern.

Ein Z2 läßt sich absehbar nicht auf Z3 ändern!

Einen Pool kann man vergrößern:
- Durch Ersetzen aller Platten durch größere (erzeugt massiv Last)
- Durch Anfügen weiterer vdevs (Mirror, Z1-3, erzeugt keine Last - Pool ist aber dann zunächst 'unbalanced')

 

[asche77]

erstmal ein kleinen Pool anzulegen und dann zu erweitern.

Don't.

Festplattenpreise sind wieder gesunken -> Neukauf nur >= 14 TB wäre meine Devise...

Etwaige alte Platten löschen und auf eBay verkaufen.

 

[Bierjpg]

Guten Tag,
ich lese mich seit einigen Tagen in ZFS ein, allerdings gibt es da einige Themen bei denen ich noch keine Antwort gefunden habe.
Meine geplante Konfiguration:

FreeBSD + ZFS + Samba
1 Intel X540
6 18TB HDDs als Z2 Raid
3 SSD als Mirror fürs Special VDev
1 EMC NV-1616 als SLOG Device (im Vollausbau erzielte Geschwindigkeit 2GB/s ---> 5 sek sind 10GB benötigte Speicherkapazität)
Aktive LZ4 Verschlüsselung

In Zukunft soll das Storage evlt um einen weiteren 6x18 Z2 Pool erweitert werden.
Evlt (je nach Antworten hier) kommt ein SSD Z2 Pool hinzu.


1. Was passiert exakt wenn das Slog device ausfällt.
Hier habe ich 2 Informationen gefunden.
1.1 Die letzten 5 Sekunden an Daten sind verloren ( sofern das Slog device gleichzeitig mit dem Strom ausfällt)
1.2 Die kompletten Daten des Storages sind verloren. (Halte ich für unwahrscheinlich)

2. Special VDevs
2,1 Kann ich Special VDevs verschiedene Aufgaben zuweisen? eigentlich will ich ein Special VDev für die Metadaten haben und eins für special_small_blocks. Kann man dies Konfigurieren? Leider habe ich nichts dazu gefunden.
2.2 Wie viel Bandbreite/IO brauche ich auf dem Special VDev wenn es nur Metadaten abspeichert?
2.3 Nach allem was ich gelesen habe braucht man etwa 0.3 % des gesamten storage Platzes. Wenn ich sicherheitshalber mit 0.6% rechne brauche ich etwa 864GB um auch bei einer Verdoppelung der Speicherkapazität ausreichend Platz zu haben. Sehe ich dies Richtig?
2.4 Sehe ich das richtig, dass wenn man ein Special VDev man einiges an RAM einspaaren kann, da man die Metadaten auf der SSD liegen haben kann anstatt im RAM?
2.5 Eventuell werde ich für einige Datasetz deduplication aktivieren. Sehe ich das richtig, dass sollte ich ein Special VDev haben ich die 5GB Ram/ TB nicht brauche?
2.6 Wie viel wird auf Special VDevs rum geschrieben? Ist hier eine SSD welche vorwiegend auf Lesen ausgelegt ist ausreichend oder braucht man eine SSD welche mehrere Petabyte schreiben kann ohne zu sterben?

3. CPU Performance
3.1 Wie viel CPU Performance brauche ich für 2GB/s? Alzo mit LZ4 Verschlüsselung, 2 Z2 und evlt AES? Ist diese eher zu vernachlässigen oder ist diese relevant?
Sprich reicht alter kleiner XEON oder braucht man einen fetten EPYC.
3.1 Wie viel CPU Performance braucht dedublication?

4. Ram
4.1 Ich habe gesehen, dass der RAM für mehrere Dinge genutzt wird. Als Lesecache, als Index für das LARC2 Device (sofern vorhanden),als Schreibcache, um die Metadaten zu hinterlegen und für die Dedub Tabelle. Sehe ich dies richtig oder habe ich etwas vergessen?
4.2 Stimmt die Faustregel 1GB / TB auch bei großen Storages oder ist dies inzwischen überholt.
4.2.1 Sehe ich das richtig, das hier nur ein Teil des GBs für Metadaten genutzt wird und der restliche teil als Cache?
4.4 Wie in 2 schon gefragt sollte ich ein Special VDev haben, Kann ich die 4 GB/TB Regel für DeDub ignorieren und diesen RAM anders nutzen?
4.5 Sehe ich das Richtig, dass ich in meinem Fall bis zu 10GB als Schreibcache brauche und der Rest vor allem Lesecache ist?
4.6 Ich hatte aktuell 64GB Ram angedacht. Ist dies Kritisch? (wären im Endausbau etwa 0.48GB/TB)

4. SSD Z3
4.1 Kann ich einem ZFS Dataset sagen, lege deine Daten nur auf dieses VDev oder kann ich ein VDev für bestimmte Datasets blocken? Der Hintergrund ist der, ich möchte gegebenenfalls Virtuelle Maschinen / MP3s und anderes Kleinzeug auf den SSDs liegen haben... Und die SSDs nicht mit großem Zeug wie backups vom Notebook voll laufen lassen....
4.2 Sollte 4.1 nicht möglich sein, kann ich das SLOG und Special VDEV zwei ZPools zuweisen? (ich vermute nicht)

So genug der Fragerrei, hier noch ein paar Infos was ich mit dem Storage machen will:
Backup:
Ich möchte Backups von Notebooks und lokalen PCs darauf ablegen.
Storage:
Filme/Musik/Spiele
Sync:
Als Speicher für dinge, welche zwischen verschiedenen Geräten synchronisiert werden sollen, config Dateien, Musik, etc
Virtuelle Maschinen:
Evlt möchte ich meine Virtuellen Maschinen dort ablegen, dies steht allerdings noch nicht fest

Vielen Dank

 

[gea]

Guten Tag,
ich lese mich seit einigen Tagen in ZFS ein, allerdings gibt es da einige Themen bei denen ich noch keine Antwort gefunden habe.
Meine geplante Konfiguration:

FreeBSD + ZFS + Samba
1 Intel X540
6 18TB HDDs als Z2 Raid
3 SSD als Mirror fürs Special VDev
1 EMC NV-1616 als SLOG Device (im Vollausbau erzielte Geschwindigkeit 2GB/s ---> 5 sek sind 10GB benötigte Speicherkapazität)
Aktive LZ4 Verschlüsselung

In Zukunft soll das Storage evlt um einen weiteren 6x18 Z2 Pool erweitert werden.
Evlt (je nach Antworten hier) kommt ein SSD Z2 Pool hinzu.


1. Was passiert exakt wenn das Slog device ausfällt.
Hier habe ich 2 Informationen gefunden.
1.1 Die letzten 5 Sekunden an Daten sind verloren ( sofern das Slog device gleichzeitig mit dem Strom ausfällt)
1.2 Die kompletten Daten des Storages sind verloren. (Halte ich für unwahrscheinlich)

Wenn das Slog ohne Systemcrash ausfällt, passiert garnichts außer der Rechner wird langsamer (Logging findet dann auf dem ZIL des Datenpools statt). Mit Systemcrash sind die letzten bestätigten Schreibvorgänge verloren. Da der Ramcache in Open-ZFS per default 10% RAM, max 4GB umfasst, sind bis zu diesen Daten verloren. Die 5s betrifft nur Oracle Solaris.

2. Special VDevs
2,1 Kann ich Special VDevs verschiedene Aufgaben zuweisen? eigentlich will ich ein Special VDev für die Metadaten haben und eins für special_small_blocks. Kann man dies Konfigurieren? Leider habe ich nichts dazu gefunden.
2.2 Wie viel Bandbreite/IO brauche ich auf dem Special VDev wenn es nur Metadaten abspeichert?
2.3 Nach allem was ich gelesen habe braucht man etwa 0.3 % des gesamten storage Platzes. Wenn ich sicherheitshalber mit 0.6% rechne brauche ich etwa 864GB um auch bei einer Verdoppelung der Speicherkapazität ausreichend Platz zu haben. Sehe ich dies Richtig?
2.4 Sehe ich das richtig, dass wenn man ein Special VDev man einiges an RAM einspaaren kann, da man die Metadaten auf der SSD liegen haben kann anstatt im RAM?
2.5 Eventuell werde ich für einige Datasetz deduplication aktivieren. Sehe ich das richtig, dass sollte ich ein Special VDev haben ich die 5GB Ram/ TB nicht brauche?
2.6 Wie viel wird auf Special VDevs rum geschrieben? Ist hier eine SSD welche vorwiegend auf Lesen ausgelegt ist ausreichend oder braucht man eine SSD welche mehrere Petabyte schreiben kann ohne zu sterben?

Special vdev kann für Metadaten/small io oder dedup eingesetzt werden. Der Schwellwert für small io kann per Dateisystem gesetzt werden. Damit kann man auch komplette Dateisysteme auf das special vdev zwingen (recsize < small io).

Matadatenzugriffe finden für jedes io statt. Je schneller desto besser.

Mit 0,6% Poolsize ist man auf der sicheren Seite

Metadaten liegen im RAM Lesecache aber nur für aktive Daten. Für andere Daten ist das special vdev viel schneller als der Pool. Special vdev ersetzt dabei nicht den RAM Lesecache sondern beschleunigt Zugriffe auf noch nicht gelesene Daten. Lediglich bei sehr wenig RAM sind nur wenige Metadaten im Cache.

Für Dedup brauchts ein eigenen Special Mirror. 5 GB ist worst Case für deduplizierte Daten der Dateisysteme (nicht Poolsize).

Mit special vdev belegt die Dedup Tabelle keinen RAM sondern liegt auf SSD.

Special vdev kann sehr viel Schreiblast abbekommen, hängt aber von den Umständen ab. Billige Desktop SSD oder ohne PLP würde ich meiden. Bei Verlust des special vdev ist der Pool verloren.

3. CPU Performance
3.1 Wie viel CPU Performance brauche ich für 2GB/s? Alzo mit LZ4 Verschlüsselung, 2 Z2 und evlt AES? Ist diese eher zu vernachlässigen oder ist diese relevant?

Hängt wie oft von vielen Faktoren ab (SSD, RAM, CPU, Usecase). 2 GB/s Pool Performance ist mit guten SSD einfach. 2GB/s per SMB ist sehr gut. 2 GB/s mit Verschlüssellung ist High End und mit sync nicht erreichbar,

Sprich reicht alter kleiner XEON oder braucht man einen fetten EPYC.

https://napp-it.org/doc/downloads/epyc_performance.pdf

3.1 Wie viel CPU Performance braucht dedublication?

Wenig, braucht vor allem schnellen Zugriff auf die Deduptabellen

4. Ram
4.1 Ich habe gesehen, dass der RAM für mehrere Dinge genutzt wird. Als Lesecache, als Index für das LARC2 Device (sofern vorhanden),als Schreibcache, um die Metadaten zu hinterlegen und für die Dedub Tabelle. Sehe ich dies richtig oder habe ich etwas vergessen?
4.2 Stimmt die Faustregel 1GB / TB auch bei großen Storages oder ist dies inzwischen überholt.

war immer schon ein Mythos eines speziellen Forums.

4.2.1 Sehe ich das richtig, das hier nur ein Teil des GBs für Metadaten genutzt wird und der restliche teil als Cache?

Kann man kaum trennen. OS braucht RAM (min 2GB bei Solaris, egal wie groß der Pool), dazu für Dienste wie iSCSI/S3/NFS/SMB. Ca 70% des Ram nutzt man meist als Schreib/Lesecache.

4.4 Wie in 2 schon gefragt sollte ich ein Special VDev haben, Kann ich die 4 GB/TB Regel für DeDub ignorieren und diesen RAM anders nutzen?

ignorieren

4.5 Sehe ich das Richtig, dass ich in meinem Fall bis zu 10GB als Schreibcache brauche und der Rest vor allem Lesecache ist?
4.6 Ich hatte aktuell 64GB Ram angedacht. Ist dies Kritisch? (wären im Endausbau etwa 0.48GB/TB)

Schreibcache ist 10% RAM, max 4 GB. Ist der Cache halb voll wird er geschrieben, der Rest macht dann Caching. Da der Cache primär dazu dient keine kleinen Datenblöcke zu schreiben, bringt ein größerer Schreibcache nichts. (Poolgröße egal)

4. SSD Z3
4.1 Kann ich einem ZFS Dataset sagen, lege deine Daten nur auf dieses VDev oder kann ich ein VDev für bestimmte Datasets blocken?

ja z.B. via special vdev und Einstellung special_small_blocks=128K pool/fs1. Setzt man recsize für dieses Dateisystem auf 64K landet alles auf dem special vdev

Der Hintergrund ist der, ich möchte gegebenenfalls Virtuelle Maschinen / MP3s und anderes Kleinzeug auf den SSDs liegen haben... Und die SSDs nicht mit großem Zeug wie backups vom Notebook voll laufen lassen....
4.2 Sollte 4.1 nicht möglich sein, kann ich das SLOG und Special VDEV zwei ZPools zuweisen? (ich vermute nicht)

nein

So genug der Fragerrei, hier noch ein paar Infos was ich mit dem Storage machen will:
Backup:
Ich möchte Backups von Notebooks und lokalen PCs darauf ablegen.
Storage:
Filme/Musik/Spiele
Sync:
Als Speicher für dinge, welche zwischen verschiedenen Geräten synchronisiert werden sollen, config Dateien, Musik, etc
Virtuelle Maschinen:
Evlt möchte ich meine Virtuellen Maschinen dort ablegen, dies steht allerdings noch nicht fest

Vielen Dank

 

[asche77]

Meine geplante Konfiguration:

FreeBSD + ZFS + Samba

Das nennt sich FreeNAS .
Alternativ xigmaNAS

 

[Bierjpg]

Wenn das Slog ohne Systemcrash ausfällt, passiert garnichts außer der Rechner wird langsamer (Logging findet dann auf dem ZIL des Datenpools statt). Mit Systemcrash sind die letzten bestätigten Schreibvorgänge verloren. Da der Ramcache in Open-ZFS per default 10% RAM, max 4GB umfasst, sind bis zu diesen Daten verloren. Die 5s betrifft nur Oracle Solaris.

Vielen Dank für diese Information. Ich habe hierzu keine Information von Open-ZFS gefunden und bin auch hier von den 5s ausgegangen. Da selbst im TrueNAS Forum von 5s gesprochen wird. Scheint so als sei diese Information noch von vor dem wechsel auf Open-ZFS https://www.truenas.com/community/threads/slog-and-power-loss-protection.89602/

Vielen Dank

Special vdev kann für Metadaten/small io oder dedup eingesetzt werden. Der Schwellwert für small io kann per Dateisystem gesetzt werden. Damit kann man auch komplette Dateisysteme auf das special vdev zwingen (recsize < small io).

Dies ist mir bekannt, leider hilft mir dies nicht viel weiter. Da ich das Special VDev für Metadaten freihalten will.

Matadatenzugriffe finden für jedes io statt. Je schneller desto besser.

Mit 0,6% Poolsize ist man auf der sicheren Seite

Perfekt!

Metadaten liegen im RAM Lesecache aber nur für aktive Daten. Für andere Daten ist das special vdev viel schneller als der Pool. Special vdev ersetzt dabei nicht den RAM Lesecache sondern beschleunigt Zugriffe auf noch nicht gelesene Daten. Lediglich bei sehr wenig RAM sind nur wenige Metadaten im Cache.

Mir ist klar, dass das Special VDev nicht als Lesecache fungiert. (hierfür müsste man einen L2ARC nutzen, wogegen ich mich entschieden habe)
Der rest ist echt Hilfreich.

Für Dedup brauchts ein eigenen Special Mirror. 5 GB ist worst Case für deduplizierte Daten der Dateisysteme (nicht Poolsize).

Mit special vdev belegt die Dedup Tabelle keinen RAM sondern liegt auf SSD.

Hier noch einmal meine Frage von oben, ist es möglich mehreren Special VDevs einzelne Funktionen zuzuordnen.
1 Spezial VDev für kleine Dateien
1 Spezial VDev für Dedup
1 Spezial VDev für Metadaten.

Special vdev kann sehr viel Schreiblast abbekommen, hängt aber von den Umständen ab. Billige Desktop SSD oder ohne PLP würde ich meiden. Bei Verlust des special vdev ist der Pool verloren.

In welchen Fällen ist die Schreiblast sehr hoch? z.B. Dedup Tables und Metadaten sollten eigentlich vergleichsweise relativ wenig Schreiblast erzeugen. (zumindest nach meinem Verständnis. Sagen wir wenn ich 1TB aufs Storage schreibe fallen im schlimmsten Fall 3GB an Metadaten und 5GB an Dedup Dateien an. Also etwa 504 GB beim einmaligen füllen des Arrays (mit 0.3 gerechnet) Damit könnte ich bei einer SSD mit einer TBW von 1PB das array fast 2000 mal Vollschreiben bei 6 Disks. Oder habe ich hier etwas übersehen?

Aktuell hatte ich diese Disks angedacht: https://geizhals.de/micron-3400-1tb-mtfdkba1t0tfh-1bc1aab-a2617228.html?hloc=at&hloc=de Wenn dass mit der Schreib menge kritisch ist muss ich mir her andere suchen.

Hängt wie oft von vielen Faktoren ab (SSD, RAM, CPU, Usecase). 2 GB/s Pool Performance ist mit guten SSD einfach. 2GB/s per SMB ist sehr gut. 2 GB/s mit Verschlüssellung ist High End und mit sync nicht erreichbar,

Vielen Dank mich wundert das echt mit der Verschlüsselung. Dies sollte doch eigendlich von der CPU mit dem eingebauten AES Befehlssatz erschlagen werden können.

https://napp-it.org/doc/downloads/epyc_performance.pdf

Ja das PDF kenne ich. Leider fehlt mir dort einiges. Wie hoch war die CPU Auslastung? Wie viel hat der PCI-E 3 zu 4 ausgemacht?
Evlt reicht ja so etwas hier:

Supermicro X9SRA + Intel Xeon E5-1650v2 6C/12T 3.5-3.9GHz + Alpenföhn Gotthard | eBay

Entdecken Sie Supermicro X9SRA + Intel Xeon E5-1650v2 6C/12T 3.5-3.9GHz + Alpenföhn Gotthard in der großen Auswahl bei eBay. Kostenlose Lieferung für viele Artikel!

www.ebay.de

Daher meine Frage

Wenig, braucht vor allem schnellen Zugriff auf die Deduptabellen

war immer schon ein Mythos eines speziellen Forums.

Perfekt

Kann man kaum trennen. OS braucht RAM (min 2GB bei Solaris, egal wie groß der Pool), dazu für Dienste wie iSCSI/S3/NFS/SMB. Ca 70% des Ram nutzt man meist als Schreib/Lesecache.

ignorieren

Thx

Schreibcache ist 10% RAM, max 4 GB. Ist der Cache halb voll wird er geschrieben, der Rest macht dann Caching. Da der Cache primär dazu dient keine kleinen Datenblöcke zu schreiben, bringt ein größerer Schreibcache nichts. (Poolgröße egal)

Ok also scheinen 64gb ausreichend zu sein.

ja z.B. via special vdev und Einstellung special_small_blocks=128K pool/fs1. Setzt man recsize für dieses Dateisystem auf 64K landet alles auf dem special vdev

Das beantwortet meine Frage nicht. Und ist wie oben erwähnt nicht hilfreich.
Ich möchte 3 schnelle SSDs als special VDev nutzen und ein z2 Raid aus langsamen SSDs einbinden z.b. der MX500 Welche explizit nicht für Metadaten etc genutzt werden sollen.

nein

Allerdings vielen dank bisher das hat mir schon geholfen.

Das nennt sich FreeNAS .
Alternativ xigmaNAS

Das ist nicht hilfreich. Ich habe mich absichtlich gegen FreeNAS und Konsorten entschieden. Erstens möchte ich alles von Hand konfigurieren und zweitens möchte ich nicht das irgendeine Software dinge tut von denen ich nichts weis. Es ist erweitert nur die Komplexität.

 

[bbott]

Bei der Migration auf großé HDDs: Ist es möglich den kompletten ZFS Pool offline (ausschalten) zu nehmen und dann die Paltten einzeln zu clonen und dann den alten Pool auf den neuen Platten wieder starten? So müsste nicht je HDD Wechsel die Komplettendaten gelesen werden sondern nur einmal der belegte Platz einer Platte.

 

[asche77]

Ich vermute eher nein, da Deine neuen Platten ja andere UUIDs haben werden?

 

[gea]

Vielen Dank für diese Information. Ich habe hierzu keine Information von Open-ZFS gefunden und bin auch hier von den 5s ausgegangen. Da selbst im TrueNAS Forum von 5s gesprochen wird. Scheint so als sei diese Information noch von vor dem wechsel auf Open-ZFS https://www.truenas.com/community/threads/slog-and-power-loss-protection.89602/

Tuning the OpenZFS write throttle

In previous posts I discussed the problems with the legacy ZFS write throttle that cause degraded performance and wildly variable latencies.

www.delphix.com

Vielen Dank


Dies ist mir bekannt, leider hilft mir dies nicht viel weiter. Da ich das Special VDev für Metadaten freihalten will.


Perfekt!

Mir ist klar, dass das Special VDev nicht als Lesecache fungiert. (hierfür müsste man einen L2ARC nutzen, wogegen ich mich entschieden habe)

Auf einem special vdev landen zunächst die Metadaten. Optional und zusätzlich auch ZFS Datenblöcke unterhalb eines Schwellwertes (small io, einstellbar per ZFS Dateisystem). Man kann auch kein Special vdev für Metadaten und ein weiteres für small io definieren. Beides ist kombiniert. Lediglich dedup geht separat. Special vdev ist definiv kein Cache sondern ausschließlicher Speicherort für bestimmte Datentypen. Ein Verlust des special vdev bedeutet daher Pool lost.

Der rest ist echt Hilfreich.


Hier noch einmal meine Frage von oben, ist es möglich mehreren Special VDevs einzelne Funktionen zuzuordnen.
1 Spezial VDev für kleine Dateien
1 Spezial VDev für Dedup
1 Spezial VDev für Metadaten.

In welchen Fällen ist die Schreiblast sehr hoch? z.B. Dedup Tables und Metadaten sollten eigentlich vergleichsweise relativ wenig Schreiblast erzeugen. (zumindest nach meinem Verständnis. Sagen wir wenn ich 1TB aufs Storage schreibe fallen im schlimmsten Fall 3GB an Metadaten und 5GB an Dedup Dateien an. Also etwa 504 GB beim einmaligen füllen des Arrays (mit 0.3 gerechnet) Damit könnte ich bei einer SSD mit einer TBW von 1PB das array fast 2000 mal Vollschreiben bei 6 Disks. Oder habe ich hier etwas übersehen?

Aktuell hatte ich diese Disks angedacht: https://geizhals.de/micron-3400-1tb-mtfdkba1t0tfh-1bc1aab-a2617228.html?hloc=at&hloc=de Wenn dass mit der Schreib menge kritisch ist muss ich mir her andere suchen.


Vielen Dank mich wundert das echt mit der Verschlüsselung. Dies sollte doch eigendlich von der CPU mit dem eingebauten AES Befehlssatz erschlagen werden können.

Sync Write + Verschlüsselung ist sehr langsam. Ursache sind hier die sehr keinen Datenblöcke bei sync die sich sehr schlecht verschlüsseln lassen und die Datenmenge vergrößern. ZFS Verschlüssellung nutzt AES ist aber langsamer als Festplattenverschlüssellung die sich lediglich in den Datenstrom zur Platte einklingt.

Ja das PDF kenne ich. Leider fehlt mir dort einiges. Wie hoch war die CPU Auslastung? Wie viel hat der PCI-E 3 zu 4 ausgemacht?
Evlt reicht ja so etwas hier:

Supermicro X9SRA + Intel Xeon E5-1650v2 6C/12T 3.5-3.9GHz + Alpenföhn Gotthard | eBay

Entdecken Sie Supermicro X9SRA + Intel Xeon E5-1650v2 6C/12T 3.5-3.9GHz + Alpenföhn Gotthard in der großen Auswahl bei eBay. Kostenlose Lieferung für viele Artikel!

www.ebay.de

CPU Auslastung habe ich nicht erfasst. Mir ging es nur um erreichbare Performance Epyc vs Xeon. PCI E3/4 sollte komplett egal sein.

Daher meine Frage


Perfekt


Thx

Ok also scheinen 64gb ausreichend zu sein.

Das beantwortet meine Frage nicht. Und ist wie oben erwähnt nicht hilfreich.
Ich möchte 3 schnelle SSDs als special VDev nutzen und ein z2 Raid aus langsamen SSDs einbinden z.b. der MX500 Welche explizit nicht für Metadaten etc genutzt werden sollen.



Allerdings vielen dank bisher das hat mir schon geholfen.


Das ist nicht hilfreich. Ich habe mich absichtlich gegen FreeNAS und Konsorten entschieden. Erstens möchte ich alles von Hand konfigurieren und zweitens möchte ich nicht das irgendeine Software dinge tut von denen ich nichts weis. Es ist erweitert nur die Komplexität.

 

[ludwinator]

Bei der Migration auf großé HDDs: Ist es möglich den kompletten ZFS Pool offline (ausschalten) zu nehmen und dann die Paltten einzeln zu clonen und dann den alten Pool auf den neuen Platten wieder starten? So müsste nicht je HDD Wechsel die Komplettendaten gelesen werden sondern nur einmal der belegte Platz einer Platte.

Nein, aber dafür gehts im Betrieb und ohne offline Zeiten. Einfach die neuen Platten als Mirror an die alte dranhängen und munter weiterarbeiten.

 

[gea]

Bei der Migration auf großé HDDs: Ist es möglich den kompletten ZFS Pool offline (ausschalten) zu nehmen und dann die Paltten einzeln zu clonen und dann den alten Pool auf den neuen Platten wieder starten? So müsste nicht je HDD Wechsel die Komplettendaten gelesen werden sondern nur einmal der belegte Platz einer Platte.

ZFS liest beim Resilvern nicht die kompletten Platten sondern nur die Daten die auf die neue Platte müssen. Lediglich die Metadaten werden komplett gelesen. Das sind aber relativ wenig Daten. Ein Resilver z.B. einer leeren Platte geht praktisch ohne Verzug. Durch das Feature sequential/sorted resilvering geht ein Resilver ohnehin sehr schnell da die Daten so geschrieben werden dass die Köpfe der Platten möglichst wenig umpositioniert werden müssen.

Also einfach neue Platte anstecken und Disk > Replace/ zpool replace starten. Geht ausreichend schnell und ist sehr sicher selbst bei Fehlern auf der neuen Platte oder gegen Fehlbedienung

 

[oyster]

Moin. Ich habe Performanceprobleme unter Ubuntu 20.04 mit folgendem Setup:
Intel Core i3 9100
64 GB ECC RAM
LSI SAS2008
6x WD Red (CMR) 6TB Raid-Z2
2x Kingston A400 240 GB SSD ZFS Mirror (für OS)

Das Raid-Z2 kommt auf eine Lesgeschwindigkeit von 100-130 MB/s. Die Schreibgeschwindigkeit kommt auf eine ähnliche Größenordnung. Der ZFS Mirror auf den SSDs kommt auf lediglich 80-90 MB/s Lesegeschwindigkeit. Jeweils getestet mittels dd (beim Lesen ist die Quelle ein großes File mit Random Daten und beim Schreiben ist die Quelle /dev/zero, Kompression ist auf dem pool dazu aus).

Interessant ist, dass bei einem "zpool iostat -v 1" die Lesegeschwindigkeit immer wieder auf nahe 0 einbricht, dann wieder mit höherer Geschwindigkeit gelesen wird usw. Ich gehe mal davon aus, dass das nicht so aussehen sollte und die Anzeige beim sequentiellen Lesen eher konstant sein sollte.

Welche Performance wäre bei dem Raid-Z2 normalerweise read/write zu erwarten und wo könnte das Problem liegen? Der Mirror ist mir relativ egal, da darauf sowieso nur das System läuft.

 

[gea]

Ein Raid-Zn vdev hat rechnerisch die iops einer Festplatte (ca 100 iops) und sequentiell die Summe der Datenplatten. Da ZFS im Raid relativ viel random io erzeugt, setze ich als Daumenregel bei "langsameren" Platten ca 80-100 MB/s an und bei schnelleren 120-160 MB/s.

Ein Raid-Z2 aus 6 Platten hat 4 Datenplatten. Man sollte also bei eher sequentiellen Workloads > 300 MB/s erreichen. Schafft man das nicht mit ausreichend RAM ist am ehesten eine "schwache" Platte schuld. Erkennen kann man das z.B. mit iostat wenn nicht alle Platten gleiche Auslastung zeigen (z.B. wait%, busy%).

Erklärt natürlich nicht warum auch der SSD Mirror so langsam ist. Beim HBA würde ich noch die Firmware kontrollieren. Buggy ist 20.0.0 bis 20.0.4. Dann Updaten auf 20.0.7.

Lesecaches sind eingeschaltet?

 

[Trambahner]

Nunja, die A400 sind auf kostengünstig getrimmte Einsteiger-SSDs. Dram-less, 2 Kanal Flash-Controller.

Hängen die Red und die SSD am SAS2008? Wenn ja, in was für einem Slot hängt der SAS2008 mit wieviel PCIe-Lanes? Was für Board?
Sind die HDD mit ashift 12 , also sauberen 4k Blockalignment, angelegt?

Abgesehen davon, bei 20.04 ist ZFS noch als "experimental" deklariert. siehe hier

Eventuell auf 21.10 upgraden?

 

[oyster]

Nunja, die A400 sind auf kostengünstig getrimmte Einsteiger-SSDs. Dram-less, 2 Kanal Flash-Controller.

Hängen die Red und die SSD am SAS2008? Wenn ja, in was für einem Slot hängt der SAS2008 mit wieviel PCIe-Lanes? Was für Board?
Sind die HDD mit ashift 12 , also sauberen 4k Blockalignment, angelegt?

Abgesehen davon, bei 20.04 ist ZFS noch als "experimental" deklariert. siehe hier

Eventuell auf 21.10 upgraden?

Wie gesagt, die SSDs sind mir relativ egal, da die eh nur für das System da sind. Mich wundert nur etwas die sehr grottige Performance, v.a. beim lesen, auch wenn es billige SSDs sind. Die beiden SSDs hängen am Onboard Controller vom Supermicro X11SCL-iF. Der Pool ist mit ashift 12 angelegt.

Ich glaube das experimental bezieht sich v.a. auf den root pool.

Ich hatte vorhin auf eine andere Systemplatte mal omnios installiert. Leider konnte ich meinen Pool nicht importieren - vermutlich nicht mit ZOL kompatibel. Außerdem hat OmniOS leider keinen Treiber für meine Mellanox ConnectX-3.

Ein Raid-Zn vdev hat rechnerisch die iops einer Festplatte (ca 100 iops) und sequentiell die Summe der Datenplatten. Da ZFS im Raid relativ viel random io erzeugt, setze ich als Daumenregel bei "langsameren" Platten ca 80-100 MB/s an und bei schnelleren 120-160 MB/s.

Ein Raid-Z2 aus 6 Platten hat 4 Datenplatten. Man sollte also bei eher sequentiellen Workloads > 300 MB/s erreichen. Schafft man das nicht mit ausreichend RAM ist am ehesten eine "schwache" Platte schuld. Erkennen kann man das z.B. mit iostat wenn nicht alle Platten gleiche Auslastung zeigen (z.B. wait%, busy%).

Erklärt natürlich nicht warum auch der SSD Mirror so langsam ist. Beim HBA würde ich noch die Firmware kontrollieren. Buggy ist 20.0.0 bis 20.0.4. Dann Updaten auf 20.0.7.

Lesecaches sind eingeschaltet?

Mit Lesecache meinst du den ARC-Cache?

Auf dem HBA läuft noch eine eher antike Version: 15.0.0.0 IT. Lohnt hier ein Update? Ich bin da immer kein Freund von wenn es nicht zwingend nötig ist.

Iostat sagt beim Lesen etwa 12% iowait.

 

[negotiator]

Putty als root geht, remote ssh nicht?

Liegt eventuell an neuer OpenSSH Version.

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

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

github.com

Deprecated features in 151040​

• OpenSSH no longer accepts RSA signatures using SHA-1 by default.
• OpenSSH in OmniOS no longer provides support for GSSAPI key exchange. This was removed in release r151038.
• OpenSSL 1.0.x is deprecated and reached end-of-support at the end of 2019. OmniOS has completely transitioned to OpenSSL 1.1.1 and will begin to move to OpenSSL 3 in a future release, but retains the OpenSSL 1.0.2 libraries for backwards compatibility. The 1.0.2 libraries are maintained solely on a best-efforts basis.

Ich würde versuchen Keys neu zu generieren und es damit versuchen.

Danke für die Rückmeldung. Die Anpassung hatte ich tatsächlich übersehen, allerdings komme ich trotzdem nicht weiter.
Ich habe wie vorgeschlagen neue Keys generiert - und zwar in allen möglichen "Farben":

• mit PUTTYGEN unter Windows als RSA-Key
• mit PUTTYGEN als DSA-Key
• mit ssh-keygen unter Omnios

Die entsprechenden Public-Keys habe ich unter root/.ssh/authorized_keys abgelegt - aber egal was ich versuche, ich erhalte weiterhin die "Server refused our key"-Meldung von Putty. Wenn ich die Public-Keys bei Debian oder Ubuntu hinterlege, komme ich damit problemlos auf die Maschinen.
Interessanterweise komme ich von einer zweiten Omnios-Maschine weiterhin mit den vor Ewigkeiten erzeugten Zertifikaten (soweit ich das sehen kann SHA-1) auf die Maschine. Wenn ich den dazugehörigen Private-Key nach Putty importiere und mich auch Omnios verbinden möchte -> "Server refused our key"

Was mache ich falsch?

 

[oyster]

Wie gesagt, die SSDs sind mir relativ egal, da die eh nur für das System da sind. Mich wundert nur etwas die sehr grottige Performance, v.a. beim lesen, auch wenn es billige SSDs sind. Die beiden SSDs hängen am Onboard Controller vom Supermicro X11SCL-iF. Der Pool ist mit ashift 12 angelegt.

Ich glaube das experimental bezieht sich v.a. auf den root pool.

Ich hatte vorhin auf eine andere Systemplatte mal omnios installiert. Leider konnte ich meinen Pool nicht importieren - vermutlich nicht mit ZOL kompatibel. Außerdem hat OmniOS leider keinen Treiber für meine Mellanox ConnectX-3.


Mit Lesecache meinst du den ARC-Cache?

Auf dem HBA läuft noch eine eher antike Version: 15.0.0.0 IT. Lohnt hier ein Update? Ich bin da immer kein Freund von wenn es nicht zwingend nötig ist.

Iostat sagt beim Lesen etwa 12% iowait.

Habe nun doch mal ein Update auf die neueste Firmware gemacht. Schneller ist es nicht geworden. Allerdings beobachte ich nun ein iowait von 30%+.