[Sammelthread] ZFS Stammtisch

[gea]

Bei einer inkrementellen Replikation wird ein Snap erzeugt, z.B. Snap 21 und die Snapnummer eines Vorgängersnaps z.B. 19 beim Senden angegeben. Übertragen werden dann die Änderungen zwischen beiden. Auf der Zielseite muss das Dateisystem vor dem Empfang ein Rollback auf 19 machen, damit im Ergebnis auch der Datenstand so wie von Snap 21 auf der Quellseite entsteht.

Snap 19 wäre hier der identische Basissnap der auf beiden Seiten benötigt wird.

 

[CommanderBond]

also nach einer inkrementellen Replikation kann der dadurch erzeugte Snap für darauffolgene replikationen als Basissnap benutzt werden?

 

[asche77]

Ja.

Aber:

Das Zieldateisystem wird dazu vor dem Empfang auf den Basisstand rückgesetzt der identisch ist zum Basissnap des Quellsystems. Kann man sich vorstellen wie die Fortsetzung der Aufnahme eines Liedes im Radio das man teilweise aufgenommen hatte und das später an gleicher Stelle fortgesetzt wird. Vor der Aufnahme des restlichen Liedes spult man zurück zum Ende und nimmt dann den Rest auf. Im Ergebnis hat man das ganze Lied.

Alle zwischenzeitlichen Änderungen auf dem Zielsystem werden dann gelöscht.

Schau Dir auch Mal die verschiedenen tools für Replikation an: zrep, zrepl, syncoid, znapzend, pyznap, ......

 

[Bzzz]

Bestimmt überseh ich irgendwas Dämliches: Wenn ich ein ZFS snapshotte und ohne weitere Änderungen alle vier vorhandenen Snapshots auf einen neuen Pool sende, sollte dann nicht dort der exakt selbe Datenbestand bestehen? Geringfügige Abweichungen refer vs. used wegen spätem Aktivieren von lz4 auf dem Quell-ZFS (ist 2014 auch nicht mit v44 gestartet...) und ne anderen Poolgeometrie (nun 10 statt 8 Platten je im Z2, beide ashift 12) mal beiseite gelassen:

alt/X       compressratio       1.06x       -
alt/X       recordsize       128K       default
alt/X       referenced       472G       -
alt/X       used       500G       -
alt/X       usedbychildren       0       -
alt/X       usedbydataset       472G       -
alt/X       usedbyrefreservation       0       -
alt/X       usedbysnapshots       27.5G       -
Snapshots:
alt/X@2019.01 315M used 321G refer
alt/X@2019.12 2.07M used 337G refer
alt/X@2020.11 734K used 471G refer
alt/X@2021.02 0 used 472G refer


neu/X       compressratio       1.07x       -
neu/X       recordsize       128K       default
neu/X       referenced       447G       -
neu/X       used       473G       -
neu/X       usedbychildren       0       -
neu/X       usedbydataset       447G       -
neu/X       usedbyrefreservation       0       -
neu/X       usedbysnapshots       26.1G      

neu/X@2019.01 302M used 302G refer
neu/X@2019.12 2.29M used 318G refer
neu/X@2020.11 737K used 446G refer
neu/X@2021.02 0 used 447G refer

1% bessere Kompression und ein bisschen weniger Verschnitt erklären von mir aus den Unterschied zwischen den 25 bzw. 27 GB refer/used, aber woher kommt der absolute Unterschied? Wie können im alten ZFS Daten liegen, die nicht in Snapshots enthalten sind und damit übertragen werden müssten?

 

[gea]

Wenn man einen Snapshot eines Dateisystems erstellt, so werden alle darin referenzierten aktuellen Daten übertragen. Man hat also am Ziel alle aktuellen Dateien des Dateisystems, normalerweise keine Vorversionen. Vor der Übertragung werden alle Daten dekomprimiert oder dedupliziert und auf dem Ziel neu kompromiert oder dupliziert. Allein dadurch kann sich der Platzverbrauch ändern. Hinzu kommt noch die Frage der physikalischen Struktur der Platten (512B oder 4k) oder des Pools. Je nachdem und auch je nach Füllstand ergibt sich zudem eine andere Fragmentierung. Das kann einen Unterschied ausmachen.

Ansonsten brauchen weitere enthaltene Quell Snapshots auf dem Quell Dateisystem Platz. Man müsste also alle Zwischensnaps und eventuelle zvols mit zfs send -r (recursiv) mit übertragen damit man auch diese Versionierungs-Snaps oder Blockdevices auf dem Zielsystem hat. Alternativ dürften zum Vergleich keine weiteren Quellsnaps oder zvols neben dem zu übertragenden Snap bestehen.

Da die Snaps gleich sind und nur der Platzverbrauch unterschiedlich wird wohl der erste Punkt den Unterschied ausmachen.

 

[zos]

Vermutlich jeder User hier im Forum hat sich bereits mit dem Thema Werbung-/Tracking-Blocking beschäftigt und eine der bekannteren Lösungen ist ja bspw. Pi-hole für einen Raspberry Pi.
Vor ein paar Wochen wurde im Nachbarthread *Sense (Firewall- und Routing-Appliance) vom User @oNyX` als weitere Lösung in einem seiner Beiträge die Open Source Software AdGuardHome vorgeschlagen.

Da ich keinen zusätzlichen Raspberry Pi ergänzend zu meinem OmniOS-Homeserver betreiben möchte, habe ich mal ausprobiert, ob sich das auf einem Solarish-System installieren lässt. Das habe ich heute Abend (mit etwas Widerstand) hinbekommen. Für diejenigen, die es interessiert, hier die Anleitung:

Voraussetzungen
SmartOS pkgsrc ist installiert (mindestens 2020Q3)
git ist installiert (ggf. mit "pkg install git" installieren)

Installation (OmniOS r151036 und o.a. 2020Q3-SmartOS-Repo)

/opt/local/bin/pkgin -y in go
/opt/local/bin/pkgin -y in nodejs-10.21.0
/opt/local/bin/pkgin -y in npm
/opt/local/bin/pkgin -y in yarn
cd ~
git clone https://github.com/insomniacslk/dhcp
sed -i 's/build /build solaris /g' ~/dhcp/interfaces/bindtodevice_bsd.go
git clone https://github.com/AdguardTeam/AdGuardHome
cd ~/AdGuardHome
echo 'replace github.com/insomniacslk/dhcp v0.0.0-20201112113307-4de412bc85d8 => ../dhcp' >> ~/AdGuardHome/go.mod
env GOOS='solaris' GOARCH='amd64' make
~/AdGuardHome/AdGuardHome

Der vorletzte Befehl dauert ein wenig. Sofern der Build dann ohne Error geendet ist, startet der letzte Befehl AdGuardHome. Die Weboberfläche wird dann unter http://<serverip>:3000 aufgerufen. Nach der Erstkonfiguration ist AdGuardHome dann unter Port 80 (http://<serverip>) erreichbar.

 

[Fischje]

Hallo, ich habe eine Frage, die zwar nur indirekt mit zfs zu tun hat, aber ich hier trotzdem stellen wollte, das es sich um ein zfs-raid handelt:

Die Platte hatte das jetzt schon zum 2. mal in folge in 2 Wochen. Was wäre denn jetzt eine geeignete Vorgehensweise bevor ich diese an Seagate moniere?

Hatte das vor einem Jahr schonmal und der Plattentausch hat fast 5 Wochen gedauert....

Wie teste ich die Platte am besten, bzw. was könnte es als alternativen geben, dass die Platte rumzickt?

 

[Gen8 Runner]

Hallo, ich habe eine Frage, die zwar nur indirekt mit zfs zu tun hat, aber ich hier trotzdem stellen wollte, das es sich um ein zfs-raid handelt:
Anhang anzeigen 596690
Die Platte hatte das jetzt schon zum 2. mal in folge in 2 Wochen. Was wäre denn jetzt eine geeignete Vorgehensweise bevor ich diese an Seagate moniere?

Hatte das vor einem Jahr schonmal und der Plattentausch hat fast 5 Wochen gedauert....

Wie teste ich die Platte am besten, bzw. was könnte es als alternativen geben, dass die Platte rumzickt?

Fünf Wochen? Direkt über Seagate oder über den Händler?

Ich würde wahrscheinlich wie folgt vorgehen:
- SMART Werte auf deinem ZFS Filer auslesen und speichern / Screenshot
- Mit Seatools einen Check durchführen (da meist die Hersteller dies wünschen)
- RMA mit Seagate öffnen und deren Aussage abwarten
- Vermutlich Platte tauschen (sprich einschicken / neue einbauen oder wie Seagate das auch handhabt)

Oder Alternativ neue Platte besorgen, einbauen, RAID neu aufbauen, dann erst die defekte einschicken und die zurückgesandte bei Ebay verkaufen.

 

[Fischje]

Fünf Wochen? Direkt über Seagate oder über den Händler

Über seagate.

 

[Fischje]

also smartctl hatte keine fehler. ist mir aber zu heiß und ich sende das jetzt nach seagate. für soetwas wie ein badblock test habe ich nicht genug erfahrung oder alternative platten, um das separat zu machen. dann tausch ich lieber - bin ja noch in der garantie.

 

[Gen8 Runner]

also smartctl hatte keine fehler. ist mir aber zu heiß und ich sende das jetzt nach seagate. für soetwas wie ein badblock test habe ich nicht genug erfahrung oder alternative platten, um das separat zu machen. dann tausch ich lieber - bin ja noch in der garantie.

Genau, wenn Seagate die RMA mitmacht, tauschen.

Gerade wenn die jetzt schon mehrfach auffällig war innerhalb von kurzer Zeit.

 

[p4n0]

Ahoi in die Runde,
kann mir jemand erklaeren, wieso mein Raid-Z1 bestehend aus 4 disks schneller schreibt als liest?
(System ist ein virtualisiertes FreeNas, Sync = Standard)
Ist das normal oder wie kommt das zu Stande?


Gemessen wurde auf einem NFS Share.

dd if=/dev/zero of=tempfile bs=1M count=16384 conv=fdatasync,notrunc
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 15.9088 s, 1.1 GB/s

dd if=tempfile of=/dev/null bs=1M count=16384
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 29.9082 s, 574 MB/s

Muesste das nicht lesend schneller als schreibend sein?
(Nicht dass mich es groß stoeren wuerde, moechte nur verstehen wieso das so ist und ob ich das 'fixen' kann, habe noch nicht soviel Erfahrung mit ZFS)

 

[gea]

Sind "disks" mechanische Festplatten?

Dann sieht es so aus
Eine mechanische Festplatte hat lesend und schreibend sequentiell lt Datenblatt max 200-250 MB/s. Da ZFS Daten auf ein vdev relativ gleichmäßig verteilt, spielen iops eine entscheidende Rolle für die Performance. In der Praxis kann man pro Platte in einem ZFS Z1 eher 100-150 MB/s rechnen, zumal ja neben den Daten auch Prüfsummen mit gespeichert werden.

Ein Z1 aus 4 Platten hat damit 3 Datenplatten. Die theoretische Pool Leistung beim Schreiben und Lesen liegt damit bei 300 MB/s - ca 450 MB/s. Der Schreibwert von 574 MB/s liegt damit bereits über dem theoretischen Maximum, der Lesewert ist Peterchens Mondfahrt. Das Ergebnis wird meist durch den Cache verfälscht. (wobei dd kein guter Benchmark ist)

Beim Schreiben gehen alle Daten zunächst in den RAM-Schreibcache. Der ist bei Open-ZFS per Default 10% RAM, max 4GB. Ist der Halb voll, wird im Hintergrund sequentiell und der Rest des Caches nimmt neue Writes auf. Der Cache dient vor allem zum Optimieren der Writes. Man kommt damit nahe an die Pool-Leistung heran. Da der Wert doppelt so groß ist wie physikalisch möglich, wird hier wohl vor allem Cache Qualität getestet.

Beim Lesen wird auch RAM als Cache genutzt (ca 80% vom gerade freien RAM). Der Lesecache arbeitet mit einer read last/read most Optimierung und cacht keine sequentiellen Daten (sonst wäre er sofort voll), also vor allem kleine Datenblöcke und Metadaten. Der Wert hier liegt etwas über dem Maximum so dass auch da Cache Hilfe eine wenn auch kleiner Rolle spielt.

Um die reine Pool-Leistung zu messen müsste man entweder die Cache deaktivieren oder RAM soweit herabsetzen dass Cache keine Rolle spielt also bei Free-NAS z.B. 4-6 GB RAM und bei dem etwas genügsameren OmniOS ca 2-4 GB.

Dann aber nicht erschrecken wie schlecht die Werte werden. ZFS braucht RAM um den Nachteil von CopyonWrite (Fragmentiertung, mehr Daten) und Prüfsummen (noch mehr Daten) auszugleichen.


Insgesamt sollte bei einer Barebone Installation dd Lese/Schreibwerte nicht so stark abweichen. Die Virtualisierungsplattform scheint hier zu tricksen. Auch scheint NFS ohne sync zu arbeiten. Sonst wäre Write eher bei 20-50 MB/s (ESXi aktiviert z.B. sync automatisch bei NFS). Für ein VM Storage sollte sync immer aktiviert sein damit Gast Dateisysteme auf ZFS bei einem Crash nicht über den Jordan gehen.

 

[p4n0]

@gea Vielen Dank fuer deine Erlaeuterungen.

Es handelt sich um einen SSD Pool, keine mechanischen Platten.
Haette vielleicht noch mehr Input liefern sollen, sorry.

Die Storage VM laeuft mit 32GB RAM.

Der Client und die Storage VM hängen an einem extra VSwitch des ESXi, worueber nur Storage-Zeug laeuft.
Es wird nicht direkt an das Hostsystem per NFS gemounted.
Also einfach per nfsmount direkt von der Linux-VM an das FreeNas.

Die Links der VMXNET Karten stehen auf 10GBIT, was wohl auf ein bottleneck hindeutet ( 1.1GB/Sek. ).

Das ZVol ist laut FreeNas auf 'Standard' Sync eingestellt. Die Performance ändert sich jedoch nicht wenn ich = always einstelle.
Kann ich irgendwie haendisch pruefen ob syncwrites = always aktiviert ist?

Die Platten sollten laut. Datenblatt 540/360 MB/sec bzw. 90k/4,5k IOPS steady state machen.
Gibt kein ZLOG oder aehnliches auf dem Ding.

Komischerweise spuckt er jetzt nach nem bisschen herumprobieren manchmal 1.1GB/Sec in beide Richtungen aus.
Oft jedoch 'nur' 550MB/Sec lesend.

 

[gea]

Wenn man sync=always stellt, sieht man gleich was passiert. Sync=Default überläßt dem schreibenden Programm die Entscheidung und das heißt hier wohl dass kein sync aktiviert wird.

Für einen SSD Pool wären die 1 GB/s denkbar. Die so ziemlich beste Sata SSD (Intel DC 3700) kommt (bei den großen Modellen) gerade auf 75k/36k iops. Das sind realistische Angaben. Viele billige Desktop SSD können mehr lt Datenblatt (aber nur wenn sie leer sind und das dann ganz kurze Zeit). Der geringe Wert von 4,5K Schreib iops im Datenblatt läßt auf eine billige Desktop SSD schließen. Da wird man im Raid/Server oft arg enttäuscht.

Ansonsten macht man zuerst Pool Tests lokal und nicht übers Netz. Dann kann man mit iperf Netz testen um am Schluss zu schauen ob NFS oder SMB (oder Treiber, Kabel) das Problem sind.

 

[zos]

Nachdem es mir letzte Woche gelungen ist AdGuardHome unter OmniOS zu bauen, stellte ich letzten Sonntag bei ersten Tests fest, dass die Response auf einen DNS-Request nicht beim Client ankommt. Im Log von AdGuardHome tauchten dann gehäuft Fehlermeldungen wie

error while responding to a dns request: udpWrite() returned error, cause: write udp [::]:53->172.16.0.107:53926: sendmsg: invalid argument

auf. Mit ein wenig Nachforschung konnte ich die Stelle, an der der Fehler im Sourcecode auftritt lokalisieren und habe dazu ein Github issue aufgemacht. Einer der Entwickler hat auch schnell geantwortet und vermutet "differences in support for socket options" bei Solarish-Systemen, kann aber (mangels Ressourcen) keine weiteren Hinweise zur Lösung beitragen. Ab hier bin ich aber leider mangels Know-How und Zeit raus. Tja, etwas zu früh gefreut

 

[gea]

Vielen Dank für deine Bemühungen, zeigt es doch dass man jede Mainstream Linux Anwendung auf jedem Unix oder nicht mainstream Linux zum Laufen bringen kann. Letzendlich hängt es am Manpower Problem. Dann gewinnt immer Debian oder Ubuntu.

Bestärkt mich aber auch in meiner Auffassung dass man zwischen Spezialanwendungen und Mainstream unterscheiden muss. Für einen Virtualisierungsserver sind mir die Spezielisten wie ESXi immer noch am liebsten, für Storage Solarish und ZFS und für Firewalls Free-BSD. Für den Rest die Mainstream Linux und Windows, für Media Sachen OSX.

Meine Grund-Überzeugung ist VM und Storage möglichst unabhängig voneinander und vom Rest zu halten damit nicht jeder kleiner Versuch und kleiner Bug grundlegendes gefärdet. Macht man derartige Services auf OmniOS oder einem anderen Storageserver, hat man bei jedem Problem kein Storage mehr. Macht man VMs im OS ist jedes Problem gleich "Die Kiste zickt".

ESXi und alles virtualisiert inkl. Storage ist für mich "King of Lewerkäs"

Bhyve/KVM, LX Zonen oder Docker können die Abhängigkeit Basis-OS zu Services mindern, ein klarer Cut ist mir lieber solange man keine x+ Container hat.

 

[zos]

Nun, ich stimme in vielen Punkten mit Dir überein, meist ist es nur die Neugier "was gehen würde".

Bhyve/KVM, LX Zonen oder Docker können die Abhängigkeit Basis-OS zu Services mindern, ein klarer Cut ist mir lieber solange man keine x+ Container hat.

Also ich habe mir im vergangenen Jahr auch ein ESXi-System gebaut, auf welchem bspw. neben der Storage-VM noch Windows-VMs (8,.1 und 10), macOS-VMs (Mojave, Catalina und Big Sur) und eine OpenIndiana-VM installiert sind. Weitere Services (wie z. B. Nextcloud/AMP, Minio, Netatalk, Airconnect) sind aber nicht in eine Linux-VM sondern in Sparse-Zones gepackt (die Nextcloud/AMP- und Minio-Zone dabei noch hinter einer NAT/IPFilter-Zone). Sparse-Zones fressen kaum Brot und ich muss nicht noch zusätzlich eine fette Linux-VM für die Services pflegen.

Die Zones liegen dabei auf einem eigenen zpool, wie auch das Verzeichnis /etc/zones, welches per Softlink auf den Zones-Pool umgebogen ist (-> /zones/config, ähnlich wie SmartOS das macht). Die Global Zone macht dabei ausschließlich Storage (NFS, SMB) und User. Wenn die StorageVM abraucht, ist der Aufwand das schnell wieder herzustellen gering. Außerdem ist das ganze (Storage und Services) sehr schnell auf eine Bare-Metal-Installation umzuziehen, falls VMWare seine Geschäftspolitik mal ändern sollte (Die VMs muss man dann halt auf einen anderen Hypervisor umziehen). Insofern sind Solaris-Zones m. E. ein echtes Killerfeature von Solarish (mit Docker konnte ich mich nie so recht anfreunden).

 

[AliManali]

Hi

Ich habe da mal eine Frage bezüglich SLOG und Optane. Mein Kumpel hat sich jetzt das krasse Rome Board geholt. Da haben wir eine 800p Optane 58 GB dazu bestellt, da drauf soll napp-it und SLOG.

Ich habe dazu gelesen:

My suggested AiO setup now :

- use an USB stick to boot ESXi
- create a local datastore on an Intel Optane and place the napp-it storage VM onto
- Use an LSI HBA or Sata in pass-through mode for your datadisks
- add a 20 G vdisk on the Optane datastore to the napp-it storage VM and use as Slog for your datapool - add a vdisk for L2ARC (around 5 and no more than 10 x size of RAM) and enable read ahead

ESXi ist auf einer separaten SATA SSD. An napp-it reichen wir einen LSI 2008 durch, da dran hängt zum anfangen eine SM883 und eine WD Gold.

Was mir nicht ganz klar ist:

• Wie richte ich die Optane ein? 16GB für napp-it und 30GB für SLOG, jeweils eine VMDK ok? Für napp-it würde ich erst mal 24GB RAM zuweisen
• Ist SLOG und L2ARC in dem Fall das gleiche/auf der gleichen vDisk?
• soll ich den Platz auf der Optane allokieren?

Verbesserungsvorschläge?

Gruss

 

[gea]

Hi

Ich habe da mal eine Frage bezüglich SLOG und Optane. Mein Kumpel hat sich jetzt das krasse Rome Board geholt. Da haben wir eine 800p Optane 58 GB dazu bestellt, da drauf soll napp-it und SLOG.

warum soll napp-it da drauf?

Ich habe dazu gelesen:



ESXi ist auf einer separaten SATA SSD. An napp-it reichen wir einen LSI 2008 durch, da dran hängt zum anfangen eine SM883 und eine WD Gold.

Napp-it würde ich dann zusätzlich zu ESXi auf diese Sata SSD packen.
Weder ESXi noch OmniOS haben besondere Performance Ansprüche. Die SSD sollte ab 60 GB besser 90GB haben damit bei OmniOS Updates das neue OS darauf passt und man zwei oder drei Systemzustände vor den Updates hat. Swap und crash dump möchten auch gerne etwas Platz,

Was mir nicht ganz klar ist:

• Wie richte ich die Optane ein? 16GB für napp-it und 30GB für SLOG, jeweils eine VMDK ok? Für napp-it würde ich erst mal 24GB RAM zuweisen
• Ist SLOG und L2ARC in dem Fall das gleiche/auf der gleichen vDisk?
• soll ich den Platz auf der Optane allokieren?

Verbesserungsvorschläge?

Gruss

Prinzipiell kann man die Optane an OmniOS durchreichen und als Slog nutzen. Möchte man auch zusätzlich ein L2Arc könnte man die Optane unter OmniOS partitionieren. Einfacher wäre es dann aber die Optane unter ESXi als datastore zu nutzen um darauf vdisks für slog (min 10GB, besser etwas mehr) und l2arc (max 5 x Ram) anzulegen. Das L2Arc wird bei 24GB RAM für OmniOS nicht soviel bringen, eventuell etwas wenn man read ahead darauf aktiviert.

Wenn man für VM Storage eine SM 883 nutzt braucht man nicht unbedingt ein Slog da die SM selbst schon ganz gut ist. Eine Optane kann nur noch etwas bringen.

 

[AliManali]

Supi danke. Das Slog dachte ich machen wir, falls noch ein paar mechanische Platten (Storage) dazu kommen. Der VM Datastore wird aber ausschliesslich auf SSD bleiben. Die SM883 hat 2TB, damit kommen wir schon recht weit.

Sollen wir die Optane in dem Fall stornieren?

Storage und ESXi hatte ich bislang nicht auf einem einzelnen Datenträger, damit ich ESXi einfach einmal frisch aufsetzen kann, ohne Angst zu haben, den Filer dabei aus Versehen zu überschreiben. Bzw. das hat sich bei mir halt so ergeben, weil ich von dem USB Stick zur SSD gewechselt hatte.

 

[gea]

Supi danke. Das Slog dachte ich machen wir, falls noch ein paar mechanische Platten (Storage) dazu kommen. Der VM Datastore wird aber ausschliesslich auf SSD bleiben. Die SM883 hat 2TB, damit kommen wir schon recht weit.

Sollen wir die Optane in dem Fall stornieren?

Dir Optane als Slog/L2Arc wird schon noch etwas bringen. Ist halt nicht so extrem wie bei einem Plattenpool.

Storage und ESXi hatte ich bislang nicht auf einem einzelnen Datenträger, damit ich ESXi einfach einmal frisch aufsetzen kann, ohne Angst zu haben, den Filer dabei aus Versehen zu überschreiben. Bzw. das hat sich bei mir halt so ergeben, weil ich von dem USB Stick zur SSD gewechselt hatte.

Man kann ESXi problemlos updaten ohne VMs auf dem datastore zu löschen. Wenn man OmniOS nur als Filer nutzt wäre eine erneute Bereitstellung der VM auch in 2 Minuten erledigt. Konfiguration nochmal ein paar Minuten. Ist ja nichts spezielles drauf was kompliziert in der Wiederherstellung wäre. Und wenn man komplizierte Dienste installiert, dann repliziert man das aktuelle BE auf den Datenpool und kann den jederzeit einfach wiederherstellen (Disaster recovery mit neuer Bootplatte in < 30 Min.)

 

[MisterY]

Ich spiele mit dem Gedanken zwei NVME SSDs (970 Evo) mit PCI-E adaptern in einen R620 einzubauen und als ZFS Mirror in meinem Proxmox Server zu verwenden. Es soll nicht davon gebootet werden.
Funktioniert das ohne Probleme? Oder gibt es Probleme bspw bezüglich Trim? Ist das Problem hier mittlerweile gelöst: https://github.com/openzfs/zfs/issues/8381 ?

 

[ludwinator]

Um die Frage beantworten zu können, wäre interessant zu wissen, welches BS mit welchem ZFS Stand du einsetzen willst?

 

[asche77]

Performance-Frage zu meinem SSD-Pool: Sind die Werte für einen pool aus diversen Enterprise SATA SSDs noch OK, oder habe ich da irgendwo den Wurm drin?

Benchmark: Write: filebench, Read: filebench, date: 03.12.2021

pool: ssdpool

NAME STATE READ WRITE CKSUM
ssdpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c10t50011731011E98A4d0 ONLINE 0 0 0
c11t5002538C404114C8d0 ONLINE 0 0 0
c3t50011731011D6D40d0 ONLINE 0 0 0
c8t55CD2E414FBAF863d0 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
c4t500A07511BF6E585d0 ONLINE 0 0 0
c5t500A075123031EDCd0 ONLINE 0 0 0
c6t500A07512138ED2Ad0 ONLINE 0 0 0
c7t55CD2E414DFC14FAd0 ONLINE 0 0 0

host omniosce
pool ssdpool (recsize=128K, ssb=-, compr=off, readcache=none)
slog -
encryption -
remark Raw SSD pool (2x RAIDZ1 with enterprise SSDs), no cache, no compression


Fb3 randomwrite.f sync=always sync=disabled
3295 ops 4451 ops
658.983 ops/s 890.159 ops/s
5263us cpu/op 4093us cpu/op
1.5ms latency 1.1ms latency
5.0 MB/s 6.8 MB/s

Fb4 singlestreamwrite.f sync=always sync=disabled
3299 ops 10460 ops
659.775 ops/s 2091.889 ops/s
12190us cpu/op 8770us cpu/op
1.5ms latency 0.5ms latency
659.6 MB/s 2091.7 MB/s
________________________________________________________________________________________
randomread.f randomrw.f singlestreamr
pri/sec cache=none 6.2 MB/s 18.2 MB/s 482.0 MB/s
________________________________________________________________________________________

 

[MisterY]

Um die Frage beantworten zu können, wäre interessant zu wissen, welches BS mit welchem ZFS Stand du einsetzen willst?

Hatte ich doch geschrieben. Proxmox mit mirror. Oder was meinst du?

 

[gea]

Performance-Frage zu meinem SSD-Pool: Sind die Werte für einen pool aus diversen Enterprise SATA SSDs noch OK, oder habe ich da irgendwo den Wurm drin?

ZFS wäre eigentlich ein Dateisystem das viel langsamer ist als ältere Dateisysteme. Es muss erheblich mehr Daten schreiben/lesen/verarbeiten (wegen Prüfsummen und Copy on Write), hat mehr Fragmentierung und schreibt Metadaten zweifach. Wo manch älteres Dateisystem beim Ändern von Hans in Haus in einem Text nur ein Byte ändern muss, schreibt ZFS den kompletten ZFS Block der das geänderte Byte enthält (128k) neu.

Intelligent gemachte rambasierte Schreib/Lesecaches sorgen dafür dass ZFS nicht lahm ist sondern oft sogar schneller als alte Dateisysteme. Den Sicherheitsgewinn von ZFS muss man damit nicht mit Performance sondern mit RAM (und etwas mehr CPU Power) bezahlen.

Wenn man wie hier den Lesecache ausschaltet, erhält man die pure ZFS Poolperformance ohne dass der RAM hilft. Das macht man nur wenn man vergleichende Tests möchte ohne dass der RAM das Ergebnis verfälscht. Die Performance beim Lesen ist dann meist schlecht, selbst die Schreibperformance sinkt weil man auch zum Schreiben vorher Metadaten lesen muss.

Die Schreibwerte sind angesichts dessen ok, eigentlich sehr gut (Meist gibt man sequentielle Werte an, da sind 650MB/s sync und 2 GB/s nonsync sehr gute Werte, pro Datenplatte sind das 2000/6=330 MB/s und damit immerhin ca 2/3 von den möglichen ca 500MB/s einer SSD). Lesen ist viel schlechter bis ganz schlecht. Das liegt aber wohl primär am ausgeschalteten Cache.Singlestreamread mit Cache würde wohl sonst auch Richtung 2GB/s gehen.

ps
Den Benchmark als Code einfügen, dann bleibt er besser lesbar

 

[asche77]

Danke. Es ging mir in der Tat um die Einschätzung der puren Pool Leistung (inkl iops). Operativ spendiere ich ausreichend RAM als Cache.

Mit Cache ist man dann in der von Dir genannten Region:

Fb3 randomwrite.f               sync=always                     sync=disabled                   
                                10459 ops                       58090 ops
                                2091.752 ops/s                  11617.204 ops/s
                                2462us cpu/op                   1607us cpu/op
                                0.5ms latency                   0.1ms latency
                                16.2 MB/s                       90.6 MB/s

Fb4 singlestreamwrite.f         sync=always                     sync=disabled                 
                                3309 ops                        8287 ops
                                661.765 ops/s                   1643.460 ops/s
                                12116us cpu/op                  11701us cpu/op
                                1.5ms latency                   0.6ms latency
                                661.6 MB/s                      1643.3 MB/s
________________________________________________________________________________________
                                randomread.f     randomrw.f     singlestreamr
pri/sec cache=all               193.8 MB/s       171.0 MB/s     2.4 GB/s

 

[gea]

Die Werte sind doch top und wären mit üblichen Desktop SSD nicht erreichbar.
Was man bei SSD beachten muss, ist dass die Werte bei neuen SSD oder sicher gelöschten SSD oder nach einem Trim erheblich besser sind als nach einiger Zeit der Nutzung da dann teilweise Blocks belegt sind. Ändern bedeutet dann teilweise einen ganzen Block z.B. 512k oder 2MB lesen, ändern und den Block neu schreiben - und das auch wenn man nur 4k schreiben möchte. Desktop SSD brechen in der Performance dann meist nach einiger Zeit der Nutzung heftig ein. Enterprise SSD sind da besser darauf vorbereitet und halten ihre Performance viel besser auch bei dauerhafter Nutzung ohne Trim.

SSD Trim (und automatisches Garbage Collection) sorgt dafür dass es möglichst wenig teilweise belegte Blöcke gibt. Es macht also Sinn Trim (ZFS Eigenschaft) bei SSD zu aktivieren entweder mit auto oder manuellem Trim in einer low activity Zeit (Trim kann ansonst auch Performance kosten statt zu verbessern).

Trim macht bei Enterprise SSD meist keine Probleme. Als Trim in ZFS eingeführt wurde (vor ca 1,5 Jahren) gab es Berichte von korrupten Pools bei manchen SSD. Aktuell scheint ZFS gut zu erkennen ob eine SSD geeignet ist. Ich würde dennoch Trim nicht adhoc bei Produktiv-Storage einschalten sondern immer erst eine Testphase mit viel Aktivität und laufendem Trim voranschalten.

Powerloss Protection ist bei SSD Pflicht wenn man das für kritischere Daten oder als VM Storage einsetzt. Bei Enterprise SSD meist Standard außer bei den günstigeren eher "leseoptimierten" SSD.

 

[Dani2070]

Powerloss Protection ist bei SSD Pflicht wenn man das für kritischere Daten oder als VM Storage einsetzt.

Gibts eigentlich auch HDDs mit PLP?