[Sammelthread] ZFS Stammtisch

[gea]

Ja genau, die Frage war jetzt eigentlich, muss ich "recursive" ein oder ausschalten, damit das dataset1 inkl. childdataset1 gesnapshotet wird oder nicht?

Wenn man einen Snapshot auf dataset1 macht so werden nur Dateien und Ordner in diesem Dateisystem im Snap sein. Wenn man auch Dateien aus einem darunter liegenden Dateisystem snapshotten möchte, so muss rekursiv aktiviert sein.

Beitrag automatisch zusammengeführt: 11.09.2023

Hallo nutzt hier jemand den rsync Daemon von OmniOS/Napp-it? Ich habe den für ein Dateisystem (hoffentlich korrekt) konfiguriert und den Daemon gestartet. Von einer anderen Maschine aus will ich per rsync Dateien dorthin synchronisieren, scheitere aber:

> rsync quelldatei rsync://user@san/Data.Backup/ --password-file=secret

rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(228) [sender=3.2.3]

Benutzer user existiert, das password-file enthält das Passwort des Users auf san.

Die Versionen von rsync sind auf Quelle und Ziel identisch, nämlich 3.2.3.

Hat jemand Hinweise, was da schief geht? Vielleicht rsync Daemon unter Napp-it nicht korrekt konfiguriert?

Danke vorab!

Edit: Die andere Maschine ist ein Debian 11, falls das relevant ist.

Läuft denn der rsync server daemon?
Ersichtlich im Menü ZFS Dateisysteme (Spaltenüberschrift rsync in schwarz) oder in der Übersicht im Menü About bei additional services (rsync-server). Aktiviert wird der Server in Services > rsync.

Man kann auch die Settingsdatei in Services > Rsync > rsyncd.conf kontrollieren. Die Einstellungen da entsprechen den von

rsyncd.conf(5) manpage

siehe auch z.B. https://gridscale.io/community/tutorials/rsync-tutorial/

 

[toscdesign]

Wenn man einen Snapshot auf dataset1 macht so werden nur Dateien und Ordner in diesem Dateisystem im Snap sein. Wenn man auch Dateien aus einem darunter liegenden Dateisystem snapshotten möchte, so muss rekursiv aktiviert sein.

Danke!
Genau das wollte ich wissen

 

[CommanderBond]

Wenn ich ein neues Dataset erstelle und verschlüsselung anwähle ist aes-256-ccm vorausgewählt.
OpenZFS verwendet aber ab Version 0.8.4 Standardmäßig nun nicht mehr ccm sondern gcm

A quick-start guide to OpenZFS native encryption

Learn the hows, whys, and whats of OpenZFS encryption with this short guide.

arstechnica.com

zfsprops.7 — OpenZFS documentation

openzfs.github.io

Wäre es nicht gut wenn nappit Standardmäßig hier auch aes-256-gcm benutzt/vorschlägt, statt ccm?
gcm soll im übrigen auch Performanter sein und sich auch parallelisieren lassen usw.
Wobei ich sagen muss bei mir habe ich auf den ersten Blick keine Performanceunterschiede feststellen können.

 

[gea]

Ja, macht Sinn.
Habe ich in der aktuellen free/dev geändert.

 

[kandamir]

Läuft denn der rsync server daemon?
Ersichtlich im Menü ZFS Dateisysteme (Spaltenüberschrift rsync in schwarz) oder in der Übersicht im Menü About bei additional services (rsync-server). Aktiviert wird der Server in Services > rsync.

Ja, der läuft laut Übersicht.

Man kann auch die Settingsdatei in Services > Rsync > rsyncd.conf kontrollieren. Die Einstellungen da entsprechen den von

rsyncd.conf(5) manpage

siehe auch z.B. https://gridscale.io/community/tutorials/rsync-tutorial/

Danke für die Rückmeldung! Meine rsycd.conf ist erst einmal sehr übersichtlich. Modul angelegt, fertig. Keine Nutzer-Einschränkung für‘s erste.

[Data.Backup]
path = /Data/Backup
comment = My Rsync Server
read only = no
list = yes

Ich hätte erwartet, dass das dann ohne Weiteres funktioniert. Ich hab jetzt noch die fett gedruckten Zeilen in der Conf ergänzt und siehe da - es scheint zu funktionieren. Vielleicht ergänzt Du das in Napp-It, dass diese Parameter automatisch eingetragen werden, wenn man für ein Filesystem rsync aktiviert. ;-)

 

[gea]

ok (aktuelle dev von heute bei der ersten rsync Freigabe eines Dateisystems)

 

[java4ever]

Nachdem ich an verschiedenen Stellen gelesen habe, dass Expander Backplanes (wie BPN-SAS3-216EL1) nicht nur Bandbreite kosten (was nicht zu vermeiden ist), sondern auch in Verbindung mit SSDs massiv IOPS, habe ich mich entschlossen, das demnächst mal zu messen.
Zusätzlich sollen die neuen Controller, wie LSI 9500, angeblich in Verbindung mit SSDs deutlich mehr IOPS erzeugen, als Vorgänger wie der LSI 9300.

Folgendes Testsetup wird es geben:

Platform: EPYC 7302 auf Supermicro H12SSL-i (notwendig, für PCIe4.0 des LSI 9500)
SSD: 24x Micron 5300 PRO 1.92TB (Enterprise SATA mit PLP)

ZFS Setup für alle Tests: Stripe aus 24 vdev

Zu testen sind:

1x LSI 9300-8i + BPN-SAS3-216EL1 (Expander Backplane)
1x LSI 9500-8i + BPN-SAS3-216EL1 (Expander Backplane)
3x LSI 9300-8i + BPN-SAS3-216A (Direct Attach Backplane)
3x LSI 9500-8i + BPN-SAS3-216A (Direct Attach Backplane)


Noch offen:
- Genaue fio commandline
- Deaktivieren des SSD Schreibcaches (https://yourcmc.ru/wiki/index.php?t..._view_desktop#Drive_cache_is_slowing_you_down berichtet, dass selbst bei Enterprise mit PLP, wie die Micron 5300 welche sind, das deaktivieren des Schreibcaches die IOPS massiv verbessern kann)
- ggf. ZFS tuning

Hier auch gerne Input von unserem ZFS Experten @gea

 

[gea]

Die Ergebnisse direct attached vs expander würden mich auch interessieren.
Man sollte aber darauf achten, dass vor jedem Messlauf die SSD sicher gelöscht wird damit die Ergebnisse vergleichbar sind!

Grundsätzlich ist das aber ein Thema das mit ZFS nur am Rande zu tun hat.
Erstmal werden die max möglichen iops durch das Laufwerk selber bei 4k io definiert z.B. 40k, siehe Datenblatt. Das ist die Basis und mehr kann das Laufwerk nicht, egal welcher Controller.

Bessere Werte erzielt man nur wenn iops (input/output per second) sich nicht auf 4k bezieht sondern wenn mit einem io z.B. ein ZFS Datenblock in recsize also z.B. 32k, 128k oder gar 1M gemeint ist. Auch kann man durch höhere queudepth den tatsächlichen Durchsatz verbessern. Bei SAS kommt hinzu dass paralleler Zugriff per mpio und höheren sequentiellen Raten z.B. 2x12G SAS statt einmal 6G Sata eine deutliche Verbesserung bringen genau wie SAS Fullduplex vs Sata Halfduplex.

Für einen Teil dieser besseren Werte kann das OS verantwortlich sein für einen weiteren Teil der Controller. Ich würde aber nicht davon ausgehen dass der Durchsatz des 9500 bei direct attached SSD erheblich über dem 9300 liegt. Mit Expander und vielen SSD mag das anders aussehen.

Entscheidender ist: Wenn einem Sata SSDs zu langsam sind, ist der erste Schritt 12G SAS und dann mpio 2 x 12 SAS optional über ein dual expander jbod, künftig 2 x 24G SAS.

 

[chicken]

Ich hab mein Heimnetz jetzt auf 10G aktualisiert. Verkabelung, Switch und Client geben 9-10G her.


Wenn ich iperf3 von meiner Windows Workstation zu einer Ubuntu VM (4 vCPUs, 4GB) mit einem Datenstrom starte, läuft der eine Datenstrom mit etwa 6,6-6,9Gbit/s. CPU Auslastung der VM: 17%.

Wenn ich iperf3 von meiner Windows Workstation zur Napp-IT VM (8 vCPUs, 16GB) mit einem Datenstrom starte, dann gehen da gerademal etwa 3,5Gbit/s durch die Leitung. CPU-Auslastung der VM: 24%.

Wenn ich zwei parallele Datenströme laufen lasse, dann kommt die Ubuntu VM auf knapp 9G. Napp-IT aber nur auf 4,5G. Bei Napp-IT brauch ich ganze neun bis zehn Datenströme um dauerhaft in Summe über 9Gbit/s zu schaffen.

Interessant dabei: Die Ubuntu VM ist bei >=9Gbit/s mit zehn Datenströmen zu gerademal 50% ausgelastet. Napp-IT ist mit seinen doppelt so viel Kernen mit 10 Strömen bei über 9Gbit/s zu 70% ausgelastet.

Ist das bekannt? Kann man da was tweaken? Liegt das an iperf3 oder woran?


Alles was ich aktuell übers physische Netz per SMB anbiete läuft aktuell noch auf Spindeln UND ist zudem verschlüsselt. Die Performance ist deshalb nicht ganz so fix wie das Netzwerk. Ich würde aber gerne auf SSDs umstellen. Dann wären schnellere Single-Datenströme schon schön.

 

[MisterY]

Hast du MTU auf 9000 gestellt?

 

[gea]

Die OmniOS ip Grundeinstellungen sind eher auf 1G ausgelegt. Bei 10G sollte man die ip buffer hochsetzen (napp-it Menü System > Tuning: default tuning). Auch Jumbo verbessert generell die 10G ip Performance. Nutzen alle VM vmxnet3 mit ähnlichen Einstellungen (z.B. ringsize 4096 statt 256)?

 

[chicken]

@MisterY : Ich hab so meine Zweifel ob das in heutigen Zeit und bei nem vSwitch noch allzuviel bringt. Die meisten Gründe für große Frames sind historisch und haben sich durch performantere Hardware aufgelöst.

Trotzdem schadet es ja nicht unbedingt. Darum hab ich den Switch auf Default MTU 9000 gestellt (phys Switch und VMware vSwitch). Und auch die Interfaces für NFS und iSCSI von Napp-IT und anderen Server VMs stehen auf 9000. Bei solch statischen Verbindungen macht es Sinn und schadet auch nicht. Aber für Dienste die Hauptsächlich von Clients genutzt werden (SMB-Netzlaufwerke) macht das keinen Sinn, denn MTU 9000 passt nicht mehr durch VPN-Tunnel durch und sowieso hat kein Endgerät mehr als 1500 eingestellt.

@gea
Du meinst diese hier?

# tcp tunings
max_buf=16777216 tcp
send_buf=2097152 tcp
recv_buf=2097152 tcp

Die Puffer sehen für mein Empfinden doch schon ganz schön üppig aus (16mb max, 2mb sendenden/empfangen).

Theoretisch: Wenn die Puffer ein Problem wären, dann dürfte doch eigentlich (oder gerade) auch bei mehreren Streams keine Steigerung der Bandbreite möglich sein. Denn mehrere Streams belasten die Puffer doch noch stäker.

Alle vmxnet3 sind gleich eingestellt (hab nix geändert). 1st ring size von den vmxnet3 adaptern ist auf 4096 eingestellt und es scheint wohl auch nix auf Hypervisorebene verworfen zu werden. Hier ne Anleitung wie man das checken kann: https://www.techcrumble.net/2018/12/how-to-check-ring-buffer-size-and-network-stat-from-esxi/

 

[ludwinator]

Interessant dazu:

Feature #15907: vmxnet3 improvements - illumos gate - illumos

Redmine

www.illumos.org

 

[gea]

Noch als Anmerkung
Nutzt ein Client mtu=9000 so müssen die Switche etwas mehr können (wg Header, vlans)

Die Empfehlung lautet Switch = maximale Einstellung oder mindestens 9126

Topicbox

 

[chicken]

Viele Consumer-Switche können, wenn überhaupt, maximal MTU 9000. Selbst mein CISCO CBS350 kann nicht mehr. Alles darüber ist ein Glücksfall und nur bei Overlaygeeigneten Switches (oder solche die es routen können) garantiert.

Und dann kommt noch dazu, dass MTU nicht bei jedem Hersteller das selbe meint. Ich hab das selbst schon innerhalb eines Herstellers gesehen, dass bei der einen Produktlinie IP-MTU gemeint war (komplettes IP-Paket), beim nächsten ist damit der Ethernetframe + Nutzlast gemeint (komplettes IP-Paket + Ethernetframe).

Heißt: Endgeräte (Workstations, Laptops, Mobile devices) besser nicht anheben, es sei denn man weiß genau was man tut. In der Regel sorgt das dann aber im Nachgang oder an anderen Stellen für Ärger. Wenn, dann nur bei Serverähnlichen Systemen, die immer im selben Netz sind.


@ludwinator: Danke. Sieht nach einem allgemeinen Betriebssystem-Problem aus. Hoffen wir mal, dass das schnell umgesetzt wird. Bis dahin werd ich mal sehen wie weit ich mit meiner NIC mit PCIe-Passthrough komme.

 

[CommanderBond]

Spoiler: Screenshot

Warum zeigt er mir 43 Snaps an obwohl ich keine 43 Snaps habe?
Kann ich mir nur so erklären dass da noch die Snaps eine längst exportierten/entfernten Pools mit drin sind.
Oder woher kommt das?

 

[chicken]

Ich wollte nochmal auf das Bandbreitenthema zurück kommen, denn ich hab mittlerweile ziemlich viel getestet. Ausgehend von vergleichbaren VMs (8 vPUs, 8 oder mehr GB RAM, vmxnet3 als vNIC) und iperf3 als Testtool. Single flow connections zwischen der WIndows 11 Workstation und den VMs:

Fresh FreeBSD 13.2 install: 5Gbit/s
Schon länger genutzte OPNsense 23.7.4 Installation: 2,7Gbit/s (ziemlich erbärmlich eigentlich, obwohl es auf FreeBSD 13.2 basiert)
Frische OPNsense 23.7.4 Installation mit einer allow all regel: 2,8Gbit/s
Frische OPNsense 23.7.4 Installation mit deaktivierter Firewall (pf): 3,2Gbit/s
Ubuntu 22.04 LTS: 9Gbit/s
Napp-IT auf OmniOS: 3,5Gbit/s

Alle VMs sind mit MTU 1500 konfiguriert.

Was ich damit sagen will: Die MTU spielt keine Rolle wenn die Treiber und der Kernel an die vmxnet3 angepasst sind.

 

[gea]

Spoiler: Screenshot

Anhang anzeigen 922207

Warum zeigt er mir 43 Snaps an obwohl ich keine 43 Snaps habe?
Kann ich mir nur so erklären dass da noch die Snaps eine längst exportierten/entfernten Pools mit drin sind.
Oder woher kommt das?

Was zeigt denn
zfs list -t snapshot

ps
napp-it puffert Daten für eine gewisse Zeit um Menüs schneller aufzubauen. Dieser Puffer wird regelmäßig verworfen, kann man auch manuell im Menü Snapshot > Delete Snap Buffer ausführen. Vielleicht liegts ja daran.

 

[CommanderBond]

wenn ich zfs list -t snapshot ausführe zeigt er mir alle an was in napp-it zusehen ist zusätzlich aber auch noch eine Reihe von Snapshots auf rpool.
In Summe könnte das hinkommen mit der angezeigten 43 dann.

 

[gea]

Datensnaps auf rpool sind eher ungewöhnlich. Da sind normalerweise nur Bootenvironments (bootfähige Snaps). Üblicherweise trennt man Boot/Rpool und Datenpools. Da rpool auch ein ZFS Pool ist kann man da aber auch normale Snaps anlegen.

 

[CommanderBond]

Spoiler: Screenshot

habe den screenshot mal angehangen

 

[gea]

Wurden denn Replikationen des aktuellen Bootenvironments als Disaster Backup angelegt ?
Das würde auch rpool Snaps anlegen.

 

[CommanderBond]

nein,
ich habe aber 2 Datasets unter rpool angelegt für keydata.

 

[gea]

Das Anlegen eines Dateisystems erfolgt unabhängig vom Anlegen von Snapshots. Die rpool /Root sind aber vermutlich bootfähige Snaps /Bootenvironments. Die werden auch bei Updates angelegt.

 

[CommanderBond]

Auf einem anderen Server beobachte ich das gleiche.

Snaps: 105/105

Es werden aber nur 72 angezeigt.

Die nicht angezeigten snaps auf rpool sollten doch besser nicht mitgezählt werden unter "Snaps"

 

[gea]

Ich muss mir die Soll Systematik nochmal überlegen. Snap Datasets auf rpool sollten aber angezeigt und gezählt werden (ohne Bootenvironments). beadm list -s zeigt aber Bootenvironments und deren Snaps, könnte man als Referenz nehmen

Beitrag automatisch zusammengeführt: 18.09.2023

Eine Möglichkeit wäre in /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl
die Zeile 5172 auszukommentieren. Dann werden rpool Snaps mit Clones angezeigt und auch zum Löschen angeboten.

Ich muss mir erst überlegen ob das Sinn macht.

 

[chicken]

@gea: Nutzt OmniOS / Napp-IT eigentlich die Hardwarebeschleunigung von Netzwerkkarten?

Ich hab gerade rausgefunden, dass z.B. OPNsense in der default installation die Hardwarebeschleunigung für Netzwerkkarten komplett deaktiviert hat. Deshalb sehe ich da auch mit der vmxnet3 nur mikrige 2,7Gbit/s an Durchsatz. Nachdem ich die Beschleunigung komplett aktiviert hab, sind es schon über 5Gbit/s mit nur einem iperf3 Datenstrom.

Kann man die Beschleunigung für CRC, LRO, TSO und VLAN an/abschalten?

 

[gea]

Da bin ich jetzt überfragt.
Da vmxnet3 aber keine Hardware hat, handelt es sich um Softwareoptimierung.

Ich vermute dass es es bei Illumos genau darum geht

Topicbox

 

[chicken]

Ja, vmxnet3 ist auch "nur" software. Aber aus Gastbetriebssystemsicht ist es egal, ob der offload an Hardware oder Software übergeben wird. Dieser Softwareadapter läuft einfach hardwarenäher im Hypervisor und ist mit ziemlich großer Wahrscheinlich der am besten optimierte Softwareadapter am Markt, wenn man seine Funktionen richtig anspricht. Allein dass ich bei der OPNsense durch den Offload den doppelten Datendurchsatz bei halber CPU-Beanspruchung sehe zeigt, dass es sinnvoll ist, die Abhandlung von Traffic an den vmxnet3 zu übergeben und nicht im Gastbetriebssystem laufen zu lassen.

Ich frag mal den Maintainer nach dem Stand der Dinge.

 

[chicken]

Und da muss ich meine vorige Aussage auch schon korrigieren, basierend auf diesem KB Artikel: https://kb.vmware.com/s/article/2055140

CRC, LRO, TSO und wahrscheinlich noch weitere Funktionen werden - sofern von der physikalischen NIC unterstützt - vom vmxnet3 Adapter an die physikalische NIC durchgereicht, was die CPU ungemein entlastet.

Wenn man sich mal anschaut, was die NICs heute alles offloaden können, dann ist das schon eine feine Sache. Die x550-T2 in meinem AIO kann zum Beispiel auch iSCSI, FCoIP und NFS offloaden.

Richtige gute NICs sind sogar programmierbar und offloaden auch vSAN und einen haufen anderes Zeugs in Line Speed. Das ist gerade bei Software Defined Data Centern richtig geil und reduziert den Software Defined Overhead.