[Sammelthread] ZFS Stammtisch

[gea]

Kommt darauf an.
ZFS (bis auf Draid) arbeitet mit dynamischen Recsizes. Vereinfacht gesagt passiert folgendes:

Bei 128k default Recsize.
Schreibt man 60k Daten, so wird ein kleinerer 64k Datenblock geschrieben, "Verschnitt" 4k

Worst Case
Schreibt man 128,01k Daten, so werden 2 Datenblöcke je 128k geschrieben, max Verschnitt praktisch 128k

Mit 1M recsize
und kleinen Datenblöcken, werden dynamisch kleinere Datenblöcke 2 Hoch n also 4k, 8k, 16k, 32k, .. genutzt.
4k ist Minimum (physical Blocksize der Platte), ZFS Compress, Prüfsummen, Verschlüssellung ist extrem ineffektiv bei so kleinen Blöcken.

Worst Case
Schreibt man 1,01M Daten, so werden 2 Datenblöcke je 1M geschrieben, max Verschnitt praktisch 1M

Hat man im Wesentlichen große Daten, kommt der worst case selten vor. Ist das ein "Office filer" ist das nicht ganz so optimal.
Hinzu kommt dass man auch bei größeren Dateien bei denen man einen Teil lesen möchte, immer 1M einlesen muss, auch wenn man nur ein paar Bytes Text oder einen einzelnen Datenbankeintrag benötigt.

Bei einem Video Filer ist also 1M eher günstiger, bei einem Filer mit vielen unterschiedlichen Dateien ist 128k Default eher besser, bei einer VM oder Datenbank eher 32-64k

 

[Multiverse]

Dank dir, dann nehme ich mal die 1M!

 

[Techlogi]

4x8TB Raid-Z1 ist vielleicht etwas optimistisch, oder kann man das noch machen?

 

[Potz]

Letzter Versuch: Ein "Verlängerungs-Adapter" um sie direkt an dem M.2-Steckplatz des Boards zu betreiben. Keine Ahnung ob es einen Unterschied gitb oder die PCIe Adapter nur zu billig waren. Wenn sie dann nicht läuft werde ich wohl in Richtung Consumer-SSD schauen. Vielleicht sind die unproblematischer.

Ich habe schon ein paar "lustige" Erlebnisse mit NVMe Adaptern gesammelt. Durchprobieren kann erstaunlicher Weise selbst in Fällen wo sie nahezu identisch aussehen helfen...

Beitrag automatisch zusammengeführt: 21.03.2023

4x8TB Raid-Z1 ist vielleicht etwas optimistisch, oder kann man das noch machen?

Ich sehe kein Problem.

 

[ludwinator]

4x8TB Raid-Z1 ist vielleicht etwas optimistisch, oder kann man das noch machen?

Klar, gar kein Problem!

 

[Techlogi]

Kann man abschätzen wie lange ein Rebuild da laufen würde bei z.B. halb oder 2/3 vollem Pool?

Edit, mit HDDs.

 

[gea]

Hängt ab von Füllgrad, den iops der Platten, recsize, Fragmentierung und wieviel Metadaten im Arc liegen.
Als Hausnummer würde ich 8-36 Stunden sehen. Fällt da eine weitere Platte aus ist der Pool verloren.

Gibt es einen Lesefehler hat man lediglich eine defekte Datei (bei Raid-5 war meist das Array verloren)

 

[dstockm]

Ich habe schon ein paar "lustige" Erlebnisse mit NVMe Adaptern gesammelt. Durchprobieren kann erstaunlicher Weise selbst in Fällen wo sie nahezu identisch aussehen helfen...

Das scheint mir auch so. Mit der Verlängerung sieht es etwas besser aus. Keine SMART-Fehler mehr vom BIOS.
Habe jetzt vermutlich noch ein Hitzeprblem. Mit großem CPU-Kühlkörper anscheinend alles stabil. Nehme ich ihn runter dauert es keine Minute bis sie sich aufhängt.

Falls jemand Erfahrungen mit dem Fujitsu D3417-B2 und aktuell verfügbaren NVMe-SSD's hat, nehme ich gern noch Vorschläge entgegen. Ich überlege ob ich nicht einfach eine Samsung 980 nehme (PCIe 3).

--------------

Update: Samsung 980 (ohne PRO) scheint stabil zu laufen.
Im BIOS werden jetzt auch keine Geister-NVMe-Controller mehr angezeigt. Bei der Micron 7400 und der Samsung PM9A3 wurden 4 Controller angezeigt...

 

[AliManali]

Hi

Angenommen, ich habe einen Anwendungsserver auf einem ESXi als Gast. Dessen Storage liegt auf einem vSAN. Was passiert da, wenn ich dem Server im Betrieb den Storage weg ziehe? Also OS und Daten.

Mache das nur ungern. Netzwerk mal weg ziehen ok. Aber Storage (per NFS) einfach mal neu starten?

Nunja, ich habe es nun schon etliche Male versucht. War immer wieder erstaunt, wie Gäste die über NordVPN auf einen Server in Holland verbunden waren die Verbindung aufrecht erhalten konnten. Die lokalen Server (Win und Linux) frieren kurz ein. Danach ist es wie wenn nichts gewesen wäre. Server sind wieder erreichbar, und im Client kann ich das Fenster wieder verschieben.

Auch die Takmanager irritieren mich bei dem Vorgang. Ein Linux Hostingpanel macht da für den Unterbruch 100% CPU Last im Gast, der Windows Client 0%. Müsste das, wenn schon, nicht umgekehrt sein?

Ich gehe aber schon richtig in der Annahme, dass ein Neustart vom Storage eher eine schlechte Idee ist? Obwohl es recht witzig ist.

 

[asche77]

@AliManali, ich _glaube_ der ESXi puffert Schreib- und Lesevorgänge kurzzeitig und übersteht daher einen kurzen Ausfall von Netzwerkstorage (egal ob per NFS oder vSAN). Ich meine, ebenfalls schonmal meine storage VM neu gestartet zu haben ohne alle VMs herunterzufahren, und nach einem kurzen Hänger lief es dann weiter.

So oder so aber: Kids, don't try this at work ;-)

 

[gea]

Ist wohl wie russisches Roulett.
Glück, Zeitpunkt und Statistik und nicht jedesmal ist Gustav Gans am Werk.

Selbst wenn der Anwendungsserver nicht abstürzt, gibt es keine Garantie dass die Daten konstsistent sind.

 

[asche77]

EDIT: Die Ursache lag im Einschalten von "encrypt=enabled" (optionale SMB-Verschlüsselung). Zurück auf "disabled" und performance ist da wo man sie kennt.

----

Ich habe ein Thema mit meiner SMB-Performance:

OmniOS r44 auf ESXI 8.0c. Xeon 1225v5, OmniOS hat 48GB RAM.

Ich habe gerade meinen Pool umgezogen von 2xRAIDZ1 (2x4 1.92TB Enterprise SSD)) auf 1 RAIDZ1 (6x3.84TB Enterprise SSD). Jeweils am gleichen SAS3008.

Seit dem Umzug schreibt Win11 aber nur noch mit ca. 50MB/s statt mit 110MB/s auf den pool. WTF? Seit wann hat die Anzahl der vdevs eine solche Auswirkung - sowohl Bandbreite als auch IOPS des SSD-Pools müssten für Gigabit ja locker ausreichen?! Jemand eine Idee, was da los ist?

Die Benchmark-Werte des neuen Pools sehen eigentlich ähnlich aus wie die meines alten pools:

Benchmark: Write: filebench, Read: filebench, date: 04.02.2023

pool: ssdpool

    NAME                        STATE     READ WRITE CKSUM
    ssdpool                     ONLINE       0     0     0
      raidz1-0                  ONLINE       0     0     0
        c10t500A075131B05800d0  ONLINE       0     0     0
        c7t5002538C40BAD895d0   ONLINE       0     0     0
        c4t5002538C40BAD886d0   ONLINE       0     0     0
        c5t5002538C40BAD82Bd0   ONLINE       0     0     0
        c6t5002538C40BAD822d0   ONLINE       0     0     0
        c11t5002538C40BFF160d0  ONLINE       0     0     0

host                            omniosce
pool                            ssdpool (recsize=128K, ssb=-, compr=off, readcache=none)
slog                            -
encryption                      -
remark                        


Fb3 randomwrite.f               sync=always                     sync=disabled                
                                3072 ops                        7038 ops
                                614.379 ops/s                   1407.553 ops/s
                                6836us cpu/op                   4050us cpu/op
                                1.6ms latency                   0.7ms latency
                                4.6 MB/s                        10.8 MB/s

Fb4 fivestreamwrite.f           sync=always                     sync=disabled              
                                5792 ops                        9069 ops
                                1155.648 ops/s                  1811.968 ops/s
                                14320us cpu/op                  10463us cpu/op
                                3.9ms latency                   2.4ms latency
                                1154.6 MB/s                     1811.0 MB/s
________________________________________________________________________________________
                                randomread.f     randomrw.f     fivestreamrea
pri/sec cache=none              7.8 MB/s         3.8 MB/s       1.1 GB/s                  
________________________________________________________________________________________

 

[mrpasc]

Aus Versehen „Sync=always“ auf dem neuen Pool?

 

[Potz]

Aus Versehen „Sync=always“ auf dem neuen Pool?

An den Benchmarks siehst du ja, dass es mit sync nicht viel anders ist als ohne. Die Random-Performance ist nicht so geil...

 

[asche77]

Ergänzungen:
1. Sowohl lesen als auch schreiben über SMB ist betroffen: Lesen von 115 auf 85-90, Schreiben auf die Hälfte (ca. 50) eingebrochen.
2. "filebench" performance scheint mir nicht soo anders zu sein als vorher (leicht andere Messungen teilweise).

Spoiler: Mit filebench "singlestream" zur besseren Vergleichbarkeit:

Fb3 sync=always sync=disabled

Fb4 singlestreamwrite.f sync=always sync=disabled
3915 ops 9072 ops
782.783 ops/s 1813.588 ops/s
13769us cpu/op 10434us cpu/op
1.3ms latency 0.5ms latency
782.6 MB/s 1813.4 MB/s
________________________________________________________________________________________
randomread.f randomrw.f singlestreamr
pri/sec cache=none 9.2 MB/s 24.2 MB/s 558.6 MB/s
________________________________________________________________________________________

3. Der "ZFS send" von einem 2-vdev-HDD auf den SSD pool hatte ca. 250-380 MB/sec. laut syncoid. Kopieren von einem dataset aufs andere (vom Windows Explorer angestoßen, aber lokal vom SMB-Server ausgeführt) zeigt 650 MB/sc. An der grundsätzlichen Schreibwilligkeit des pools sollte es also nicht liegen.
4. sync ist auf "default" = "standard". Manuell auf "disabled" gestellt macht keinen Unterschied. Selbst sync "always" landet in der gleichen Größenordnung (400 Mbit).
5. Upload auf (und download von) einen S3 bucket (minio, gleicher pool) geht mit Gigabit-Geschwindigkeit. Upload: Windows Taskmanager zeigt alle 5 Sekunden (write cache?) einen kurzen Abfall der Übertragungsrate auf etwa die Hälfte.

 

[Potz]

Seit wann hat die Anzahl der vdevs eine solche Auswirkung

Ich hoffe ich verstehe dich richtig, aber wird generell immer empfohlen über möglichst viele Mirrors zu stripen, wenn man mit ZFS viel IOPS erzielen möchte. Mir sieht das ein bisschen so aus, als wäre genau das dein Problem. Du hast vorher über zwei RaidZ1 gestripet und jetzt ist es noch ein RaidZ1?

Warum die Performance allgemein so miserabel ist, kann ich dir nicht mit Sicherheit sagen, da ich mit Setups deiner Art keine Erfahrung habe, aber ich befürchte es hängt mit der Virtualisierung zusammen.

 

[asche77]

Ich hoffe ich verstehe dich richtig, aber wird generell immer empfohlen über möglichst viele Mirrors zu stripen, wenn man mit ZFS viel IOPS erzielen möchte. Mir sieht das ein bisschen so aus, als wäre genau das dein Problem. Du hast vorher über zwei RaidZ1 gestripet und jetzt ist es noch ein RaidZ1?

Korrekt. Aber ein SSD Pool aus Enterprise SSDs müsste mehr als genug IOPS haben, dass er 100MB/sec wegschreiben kann auch bei nur einem vdev. Wenn ich Dateien in einen s3 Bucket lade, geht es ja auch.

Warum die Performance allgemein so miserabel ist, kann ich dir nicht mit Sicherheit sagen, da ich mit Setups deiner Art keine Erfahrung habe, aber ich befürchte es hängt mit der Virtualisierung zusammen.

Vorsicht - die performance ist nicht schlecht. Die Werte oben musst Du richtig interpretieren/vergleichen.

Spoiler: Hier ein Gegenbeispiel einer einzelnen Enterprise SSD (aus [URL='https://www.napp-it.org/doc/downloads/optane_slog_pool_performane.pdf']gea's Übersicht[/URL]):

2.4 Single SSD values, effect of Arc rambased read cache
Single Intel DC 3510-120 nocache vs allcache
hostname omniosce Memory size: 32429 Megabytes
pool singledc3510 (recsize=128k, compr=off, readcache=none)
slog -
remark
Fb3 randomwrite.f sync=always sync=disabled
1740 ops 331 ops
347.983 ops/s 66.196 ops/s
1775us cpu/op 8382us cpu/op
2.9ms latency 15.1ms latency
2.6 MB/s 0.4 MB/s
Fb4 singlestreamwrite.f sync=always sync=disabled
682 ops 3324 ops
136.392 ops/s 664.754 ops/s
5203us cpu/op 1283us cpu/op
7.3ms latency 1.5ms latency
136.2 MB/s 664.6 MB/s
________________________________________________________________________________________
read fb 7-9 + dd (opt) randomread.f randomrw.f singlestreamr
pri/sec cache=none 0.6 MB/s 1.6 MB/s 36.4 MB/s
_________________________________________________________________________

Da liegt mein Pool deutlich drüber (beides ohne cache).

Beitrag automatisch zusammengeführt: 02.04.2023

"Aber ich habe nichts verändert, wirklich"

DOCH.

Der Übeltäter war:

pfexec sharectl set -p encrypt=enabled smb

(enabled = verschlüsseln, wenn möglich, aber nicht erforderlich)

Zurück auf "disabled" und die normale SMB-performance (Gigabit-Geschwindigkeit) ist wieder da!

 

[gea]

Verschlüssellung bei kleinen Datenblöcken ist nicht schnell. ZFS sync mit Verschlüssellung ist da ein besonders negatives Beispiel. Auf SMB Verschlüssellung hätte ich jetzt aber auch nicht getippt. S3 ist immer extrem schnell und auf max Performance getrimmt aber dafür ohne die Multiuser Features von SMB.

ps
zum Benchmark.
Für readcache=none ist das Ergebnis exzellent. Ich würde aber auch bei einem Benchmark zwar compress ausschalten, Cache aber aktiviert lassen. Ohne Cache ist ZFS wie Auto mit angezogener Handbremse. Im Ergebnis sieht man nur wie schlecht ZFS mit all seinen Sicherheitsoptionen dastünde wenn der Cache nicht so extrem gut wäre.

 

[gea]

Ich wurde gefragt, wie man einen ZFS Pool identisch auf einen neuen Pool überträgt
z.B. wenn man die vdev Struktur ändern möchte

Beim Übertragen eines Pool mit allen Eigenschaften und datasets ist folgendes zu beachten.

1. Der Replikationsjob muss "recursive" sein. (Joboption)
Damit werden alle enthaltenen datasets (Dateisysteme, Snaps, Zvols) mit übertragen

2. Eine Replikation legt Dateisysteme immer unterhalb des Ziel-Dateisystems an,
pool1 -> pool2 ergibt pool2/pool1

Will man die identische Struktur, muss man für jedes Dateisystem auf erster Ebene einen eigenen (recursiven) Job anlegen
pool1/dateisystem1 -> pool2 ergibt dann pool2/dateisystem1

Soll der neue Pool dann wie der alte Pool (pool1) heißen:
Alten pool1 löschen, pool2 exportieren und als pool1 importieren.

3. Eine Replikation überträgt nicht alle ZFS Eigenschaften
Manche muss man danach entweder von Hand setzen oder man setzt die besser vorher im Parent Dateisystem des Ziels. Die werden dann bei der Replikation vererbt

4. Manche ZFS Eigenschaften z.B. Zeichensatz oder Groß/Kleinschreibungsverhalten werden beim Anlegen des Pools gesetzt und können anschließend nicht geändert werden.
Wenn die Pools beidesmal von napp-it angelegt werden, sind die identisch.

Vorhandene Replikationsjob können fortgesetzt werden wenn:
- es identischen Snappaare gibt (gleicher Job, gleiche Nummer z.B. ..jobid_repli..Quelle/Ziel_nr_10)
- die Struktur (poolx/Dateisystem) von Quelle und Ziel gleich bleibt.

Möchte man einen neuen Job anlegen der auf vorhandenen Snaps aufbaut, so geht das auch.
Man muss dazu beim Anlegen des Jobs die alte Jobid verwenden (Ersichtlich in Snapnamen)

Alternativ, Erstreplikation neu starten
Ziel Dateisysteme umbenennen damit man die bei Problemen noch hat) z.B. in daten.bak, eine neue Voll-Replikation starten und nach Erfolg die .bak Dateisysteme löschen.

 

[gea]

Neues Feature in napp-it 23.dev (Apr 05):
ZFS autosnaps und ZFS replication bei ESXi/NFS Dateisystemen mit ESXi hot memory snaps.

siehe

ESX / ESXi - Hilfethread

Wenn es keine einfache Möglichkeit gibt, dass das Script erst endet wenn ein create oder remove nicht nur angestoßen sondern erfolgreich abgearbeitet ist oder ein Timeout stattgefunden hat, dann muss man halt darauf hinweisen dass man das manuell per web-ui kontrollieren muss. Man kann ja...

www.hardwareluxx.de

https://www.napp-it.org/doc/downloads/napp-in-one.pdf

napp-it ZFS server on OmniOS/Solaris: news, tips and tricks

How to duplicate a ZFS pool with ongoing replications? New pool should be exact identical to old pool but for ex. larger or with a different vdev structure You must care of the following: 1. Transfer ZFS filesystems with a "recursive" job setting This includes all datasets in the transfer...

forums.servethehome.com

 

[AliManali]

Hi

Ich habe einen ESXi AiO mit napp-it, wo ich einen Perc 310 im IT Mode durchgereicht habe. Am Host und am napp-it hängen wild ein paar SSD und eine Platte dran. Raid gibt es da nicht.

Nun habe ich zusätzlich eine Windows SSD an den Host gehängt. Ist das ein Problem, wenn ich da Windows boote, wenn die ganze ESXi Geschichte mit dran hängt? Kann mir Windows da ungewollt was kaputt schreiben? Die Platten am HBA sind btw. auch sichtbar im Windows. Ist das normal?

 

[Trambahner]

Das sollte eigentlich kein Problem sein, Windows zeigt Dir da dann einfach die Devices als Raw/unbekanntes Dateisystem an (das ist normal solange Windows passende Treiber hat, ja), weil es ja mit VMFS oder anderen unixoiden Dateisystem oder ZFS nicht anfangen kann,

Ich würde nur keine Windows-Installation/Featureupgrade machen, wenn der ESXI-Kram dran ist, damit der Windows Bootmanager da unter keinen Umständen drauf landen kann und irgendwelche ESXI-Bootpartitions schrotten kann. Denn das passiert manchmal, das sich das Windows-Setup da bisserl "vergalloppiert" und Bootloader auf andere Devices schreibt.

 

[Bzzz]

Vielleicht stelle ich mich dumm an, aber den Aufzeichnungen nach ging folgendes früher mal, sowohl unter Solaris, als auch mit OpenZFS:

Pool1 erstellt (sudo zpool create -O compression=lz4 -O encryption=aes-256-gcm -O keylocation=prompt -O keyformat=passphrase pool1 raidz2 /ganzvieledevs)
ZFS in Pool1 erstellt
Snapshot1 erstellt
Pool2 erstellt (andere Diskstruktur, aber restliche Optionen identisch)
ZFS übertragen (sudo zfs send -R pool1/V/snapshotalt | pv | sudo zfs receive -Fv pool2/V)
...und danach beliebig oft:
Neuer Snapshot erstellt
Neuer Snapshot inkrementell übertragen (sudo zfs send -R -i pool1/V@snapshotalt snapshotneu | sudo zfs receive -Fv pool2)

Nun war ich so doof und habe im Pool1 zuviele Snapshots gelöscht und hatte (1,5 Jahre Lücke...) keinen Stand mehr, von dem aus ich weitersyncen kann. Also zfs destroy und alles einmal neu.

Das geht auch alles, nur kann ich nach dem erstmaligen Übertragen je nach Variante entweder nichts mehr dranhängen - oder das ganze ZFS nicht mehr unlocken. Snapshot deleten bringt dann das ZFS auch nicht mehr in einen lesbaren Zustand zurück.

sudo zfs destroy -r pool2/V
sudo zfs send pool1/V@snapshotalt  | pv | sudo zfs receive -v pool2/V
    received 27,1G stream in 45 seconds (617M/sec)
sudo zfs send -R -i pool1/V@snapshotalt pool1/V@snapshotneu  | sudo zfs receive -Fdv pool2
    cannot send pool1/V@snapshotneu: encrypted dataset pool1/V may not be sent with properties without the raw flag
    cannot receive: failed to read from stream
sudo zfs send -R --raw -i pool1/V@snapshotalt pool1/V@snapshotneu  | sudo zfs receive -Fdv pool2
    receiving incremental stream of pool1/V@snapshotneu into pool2/V@snapshotneu
    cannot receive incremental stream: IV set guid mismatch. See the 'zfs receive' man page section  discussing the limitations of raw encrypted send streams.
    
    ^--: "Note that if you do not use this flag for sending encrypted datasets, data 
        will be sent unencrypted and may be re-encrypted with a different encryption key on the receiving system, which will disable the ability to do a raw send to that
        system for incrementals."

sudo zfs destroy -r pool2/V
sudo zfs send -R pool1/V@snapshotalt  | pv | sudo zfs receive -v pool2/V
    cannot send pool1/V@snapshotalt: encrypted dataset pool1/V may not be sent with properties without the raw flag
    cannot receive: failed to read from stream

sudo zfs destroy -r pool2/V
sudo zfs send --raw pool1/V@snapshotalt  | pv | sudo zfs receive -v pool2/V
    received 17,3G stream in 49 seconds (362M/sec)
sudo zfs send -R -i pool1/V@snapshotalt pool1/V@snapshotneu  | sudo zfs receive -Fdv pool2
    cannot send pool1/V@snapshotneu: encrypted dataset pool1/V may not be sent with properties without the raw flag
    cannot receive: failed to read from stream
sudo zfs send -R --raw -i pool1/V@snapshotalt pool1/V@snapshotneu  | sudo zfs receive -Fdv pool2
    receiving incremental stream of pool1/V@snapshotneu into pool2/V@snapshotneu
    received 181K stream in 1 seconds (181K/sec)
    filesystem 'pool2/V' can not be mounted: Permission denied
    cannot mount 'pool2/V': Invalid argument

sudo zfs send -R --raw pool1/V@snapshotalt  | pv | sudo zfs receive -v pool2/V
    received 17,3G stream in 50 seconds (354M/sec)
sudo zfs send -R -i pool1/V@snapshotalt pool1/V@snapshotneu  | sudo zfs receive -Fdv pool2
    cannot send pool1/V@snapshotneu: encrypted dataset pool1/V may not be sent with properties without the raw flag
    cannot receive: failed to read from stream
sudo zfs send -R --raw -i pool1/V@snapshotalt pool1/V@snapshotneu  | sudo zfs receive -Fdv pool2
    receiving incremental stream of pool1/V@snapshotneu into pool2/V@snapshotneu
    received 181K stream in 1 seconds (181K/sec)
    filesystem 'pool2/V' can not be mounted: Permission denied
    cannot mount 'pool2/V': Invalid argument

Ohne -F beim receive (manchmal will er den ZFS-Namen, manchmal nicht?)

cannot receive incremental stream: most recent snapshot of pool2 does not
match incremental source

Aus man zfs receive:

Raw encrypted send streams (created with zfs send -w ) may only be received as is, and cannot be re-encrypted, decrypted, or recompressed by the receive process. Un‐
encrypted streams can be received as encrypted datasets, either through inheritance or by specifying encryption parameters with the -o options. Note that the
keylocation property cannot be overridden to prompt during a receive. This is because the receive process itself is already using stdin for the send stream. Instead,
the property can be overridden after the receive completes.

Hat sich da schlicht was in der Syntax geändert und ich muss dem beim Receive irgendwelche Infos zur bestehenden Verschlüsselung des Pools mitgeben? Das ZFS selbst ist ja nicht separat/anders verschlüsselt, auf Pool1 unlockt es auch direkt mit, wenn der Pool geöffnet und gemounted wird.

 

[ludwinator]

Alles wahnsinnig chaotisch was ich da lese.
Interessant wäre, welche ZFS Version auf welchem System ist das?
Warum verschlüsselst du ganze Pools, ist das notwendig? Auch wenn du den zweiten Poool mit der selben Passphrase angelegt hat, ist es trotzdem nicht der selbe Key! Wenn das ein Backup sein soll, würde ich den Pool ohne Verschlüsselung anlegen und mit Raw schicken, dann klappts auch mit den Keys.
Vorschlag: entscheide dich mal, ob du Raw oder entschlüsselt schicken willst. Raw geht immer, entschlüsselt nur wenn der Key geladen ist.
Dann verwende keine Optionen, die du dir nicht erklären kannst (-d bei receive zum Beispiel)

Also hier mit raw:
sudo zfs send -wv -R pool1/V@snapshotalt | sudo zfs receive -F pool2/V
sudo zfs send -wv -Ri pool1/V@snapshotalt pool1/V@snapshotneu | sudo zfs receive -F pool2/V

 

[Bzzz]

Chaotisch? Es sind halt die vier Varianten, die -R bzw -w/--raw zulassen. Mir ist auch vollkommen egal, ob ich verschlüsselt auf der lokalen Maschine sende, es muss nur lesbar ankommen. Pools sind beide ungelockt, früher (zumindest mit Solaris) war das eine zwingende Voraussetzung.
ZFS 2.1.5, wobei ich gerne noch eine höhere ausprobieren würde, wegen dem Dunstkreis um https://github.com/openzfs/zfs/pull/14119

Warum der Pool verschlüsselt ist? Weil ich nicht 12 einzelne Datasets öffnen möchte, sondern der Kram aufgehen soll, wenn ich den Pool importiere.
Lustigerweise habe ich auch noch einen dritten Pool, den ich (einzelne Platte für Aufräumzwecke) ohne jegliche Konfiguration = unverschlüsselt angelegt und dann mit den gleichen Kommandos befüllt habe - der tut, nur will der eben für jedes einzelne ZFS den gleichen Schlüssel sehen, was schlicht nervt.

 

[gea]

Es kommt darauf an, welches ZFS benutzt wird.
Insbesondere bei Verschlüssellung verhält sich Original ZFS von Oracle anders als Open-ZFS unter BSD/Illumos/OI/OmniOS/OSX/Linux oder Windows,

Raw send verschlüsselter Dateisysteme bei Erhalt des Schlüssels gibt es nur bei Open-ZFS. Solaris will das nicht sondern nutzt immer den Schlüssel eines Parents. In großen zentralen Installationen sicher die bessere Variante. At home ist verschlüsseltes raw send interessanter.

Ich würde Pool verschlüsseln vermeiden sondern nur einzelne Dateisysteme darunter. Replikationen insbesondere wenn man auf einem zweiten Pool identische Strukturen oder andere Keys möchte, sind sonst nicht möglich oder machen Aufwand. Weitere verschlüsselte Dateisysteme nur wenn man andere Schlüssel möchte.

Verschlüsselte geschachtelte Dsteisysteme insbesondere mit nicht vererbten Schlüsseln führen gerne zum Chaos. Insgesamt würde ich geschachtelte Dateisysteme eh vermeiden soweit es geht sondern in einem Dateisystem normale Unterordner anlegen und keine ZFS Dateisysteme.

Bei inkrementellen Replikationen wird ein identisches Snappaar auf Quelle/Ziel benötigt. Fehlt das muss man erneut eine Erstreplikation erstellen.

 

[kandamir]

Frage zu den Replikationsjobs unter Napp-It: Die würde ich gerne für ein Offsite-Backup nutzen, beide Napp-IT Instanzen sond per VPN verbunden, auf dem Backup-Ziel liegen bereits Pool/Filesysteme aus einem manuellen Backup per zfs send/receive mit Snapshots vor. Kann der Replikationsjob da problemlos aufsetzen oder fängt man mit einer initialen Replikation von vorne an? Bei Verwendung des Parameters -I für „include all intermediary snapshots and clones“ wird das Delta aus letzte, Snap des Ziels und letztem Snap der Quelle automatisch ermittelt und alles dazwischen übertragen? Option -w für verschlüsselte Filesysteme dürfte auch klar sein.
Wenn ich einen Pool als Quelle auswähle, werden alle darunter liegenden Filesysteme repliziert, richtig? Kann man einzelne Filesysteme ausschließen oder muss man in dem Fall die zu replizierenden Filesysteme über separate Jobs replizieren?

 

[gea]

Frage zu den Replikationsjobs unter Napp-It: Die würde ich gerne für ein Offsite-Backup nutzen, beide Napp-IT Instanzen sond per VPN verbunden, auf dem Backup-Ziel liegen bereits Pool/Filesysteme aus einem manuellen Backup per zfs send/receive mit Snapshots vor.

Wenn man eine transparente VPN Verbindung hat (beide Seiten im gleichen LAN Segment), ist es natürlich besonders einfach. Hat man eine NAT Verbindung (mit Routing und Adresstranslation) so erreicht der Backupserver z.B. den Quellserver zwar unter dessen echter lokaler IP, eine Rückantwort kommt allerdings unter der IP des VPN/NAT Routers an. In dem Fall muss man im Backupserver in System > Einstellungen unter Swap remote_addr (ip=newip) die echte ip Adresse des Quellservers z.B. 192.168.10.11 durch die Router/NAT Adresse newip ersetzen, z.B. 192.168.10.11=192.168.1.1

Diese Option ist neu in 23.dev

Kann der Replikationsjob da problemlos aufsetzen oder fängt man mit einer initialen Replikation von vorne an?

kein Problem, Eine Replikation kann man fortsetzen wenn auf beiden Seiten ein identischer Basissnap (gleiche Nummer) vorliegt. Vor einer Folgereplikation wird dann das Zieldateisystem darauf zurückgesetzt. Es werden dann nur geänderte Datenbläcke aus einem neuen Snap des Quell Dateisystems übertragen um auf beiden Seiten einen identischen Stand zu haben.

Bei Verwendung des Parameters -I für „include all intermediary snapshots and clones“ wird das Delta aus letzte, Snap des Ziels und letztem Snap der Quelle automatisch ermittelt und alles dazwischen übertragen?

Ein identischer Basisnap z.B. repli_snap_nr_821 auf beiden Seiten wird immer benötigt. Der -I Parameter sorgt lediglich dafür dass Snaps die auf dem Quellserver nach dem Snap 821 angelegt wurden mit übertragen werden und auf dem Backupserver einzeln verfügbar sind.

Option -w für verschlüsselte Filesysteme dürfte auch klar sein.

Nur bei Open-ZFS wie OmniOS, nicht bei Solaris und Original ZFS

Wenn ich einen Pool als Quelle auswähle, werden alle darunter liegenden Filesysteme repliziert, richtig?

Nur wenn man "enable recursive" bei den Jobsettings aktiviert hat

Kann man einzelne Filesysteme ausschließen oder muss man in dem Fall die zu replizierenden Filesysteme über separate Jobs replizieren?

Ausschließen geht nicht. Man muss dann mehrere Jobs anlegen.

 

[AliManali]

Hi

Ich habe einen ESXi AiO mit napp-it als Filer. napp-it hängt an einem separaten Management vLAN ohne Rechte nach aussen.

Am napp-it hängen eine SM883 mit einem Plesk sowie fürs Backup ein xigmanas, und eine WD RED 8TB, wo eine VMDK für das Backup des Plesk darauf ist.

Sprich die Datenplatte des xigmanas liegt auf dem ZFS von napp-it, und ist dort nochmals auf einem ZFS vom xigmanas. Das mache ich wegen der Sicherheit, weil ich ungern von der DMZ in das management LAN beregeln würde.

Nun ist das super langsam, wenn ich vom Plesk ein Backup ziehe. Am Netzwerk liegt es nicht, weil solange der Cache der WD RED noch am greifen ist, schreibt es mit 500 MB/s. Ist der Cache voll, geht es runter auf 25 MB/s. Kopiere ich direkt am napp-it von SSD auf HDD, geht es mit 125 MB/s zur Sache, wie es sein soll.

napp-it und xigmanas liegen auf dem selben vSwitch. Das Backup läuft über sftp.

Ist das normal, bzw. muss ich damit leben? Oder fällt da wem eine Lösung dazu ein?

 

[gea]

Klingt etwas kompliziert. Kompliziert ist meist das Gegenteil von sicher.

Möglichkeiten der Vereinfachung:
-Zugriff auf die napp-it Managementoberfläche auf LAN oder einzelne Rechner begrenzen in System > Settings,
kann man für Management und Remote Control/ Replikation getrennt einstellen

Möglichkeit der Beschleunigung
- ZFS auf ZFS ist nicht superschnell
- vielleicht tuts was einfacheres als Plex wie direkte SMB Shares oder miniDLNA, dazu ein Mediaplayer am TV, auch falls Codecs nicht passen
- sftp ist langsam. Schneller ist rsync (Server mode) oder SMB und viel schneller S3