Zfs Raid Setup

Ich hab derzeit folgende Systeme mit ZFS on Linux am Laufen:

Server 1
HP Proliant ML10v2 Intel Pentium G3240 2x3,1GHz 24GB DDR3 ECC RAM
1 Stk 60GB SSD für das Debian System verschlüsselt mit LUKS ext4
4 Stk 6TB HDD 7.2k verschlüsselt mit LUKS und raidZ1

Server 2 (Backup)
HP Microserver N54L AMD Turion 2x2.2GHz 16GB DDR3 ECC RAM
1 Stk 40GB SSD für das Debian System verschlüsselt mit LUKS ext4
5 Stk 5TB HDD 5.4k verschlüsselt mit LUKS und raidz1

Server 3 (extern)
Intel Pentium G3220 2x3,00GHz 8GB DDR3 ECC RAM
1 Stk SSD Linux Mint ext4
2 Stk WD RED 4TB ZFS mirror

Auf den Servern wird alles gespeichert was so das Leben hergibt. Ich bearbeite alle Dateien wie Fotos und RAW Dateien direkt am Server, der limitierende Faktor ist dabei das GBit LAN. CPU Auslastung bei Server 1 ~5-10% wenn mit 100MB/sek geschrieben/gelesen wird.
Gerade beim Lesen/Schreiben von großen Dateien ist der limitierende Faktor das GBit LAN. Bei kleinen Dateien imho die Geschwindigkeit der Platten. Ganz mies sind dabei Webseiten Kopien - viele kleine Dateien, da geht die Geschwindigkeit ins Bodenlose runter wie von HDDs gewohnt.

Ich habe null Erfahrung mit Datenbanken im raidz1.

Ich habe auch überlegt mir einen SLOG Device auf SSD Basis zuzulegen, da es die Latenz verringt, den Durchsatz aber nicht was bei GBit LAN ja prinzipiell sinnvoll wäre. Besonders bei Datenbanken soll der Einsatz eines SLOGs viel bringen.

Der Aufbau wäre so gewesen: 2 SSDs, partitioniert auf 4GB und dann der Rest. Die 4GB als mirror für das SLOG (SLOG darf NICHT ausfallen!) und den Rest als Standard zpool (RAID 0) als L2ARC (L2ARC ist egal wenn der ausfällt).

Aber der Aufwand/Kosten war es mir nicht wert, da ich den Server als reinen Fileserver einsetze. Wenn mal eine Cloudlösung draufkommt inkl Datenbank und die ganze Familie benutzt das, dann kann das anders aussehen.
Eine SSD als SLOG wäre mir zu unsicher.

Lesetips:
https://pthree.org/2012/12/03/how-a...disk-latencies/
https://pthree.org/2012/04/17/insta...ebian-gnulinux/
https://calomel.org/zfs_raid_speed_capacity.html

edit: Eine weitere Erfahrung die ich gemacht habe ist, dass die Performance mit der Anzahl der Platten im raidz steigt. Was auch klar ist, da das nichts anderes als ein striped set mit Redundanz ist. CPU Power ist heutzutage ja absolut kein limitierender Faktor mehr, HDD Zugriffszeiten sehr wohl.
edit2: Added calomel link

Ja, es gibt einige ZFS Tuning Attribute.

Zuerst muß der Pool an die HDD blocksize angepasst werden. An sich fragt ZFS die Hardware, aber die meisten neuen HDD lügen ganz frecht und geben statt 4K 512b aus. Dh beim Erstellen des Pools muß man den Parameter ashift=12 händisch angeben.

lz4 Kompression habe ich auch aktiviert, allerdings bringt es für den Speicherplatz fast nichts (<2%), da ich praktisch nur nicht komprimierbare Files habe. Bei der Performance habe ich keine Messungen gemacht.

Wenn man die Pools mit Samba freigibt:
zfs set xattr=sa (pool)
Source: http://www.nerdblog.com/2013/10/zfs...g-on-linux.html

atime auf disable setzen:
zfs set atime=off (pool)
Erhöht die Leseleistung.

Zusätzliche Info zu Performance
https://wr.informatik.uni-hamburg.d...performance.pdf

Zitat

Wenn die Daten so wichtig währen, wäre aber ein RAIDZ1 viel zu unsicher.

1. RAID ist kein Backup!
2. Warum ZFS (wie auch Hammer, REFS, ..) sicherer ist als andere Filesysteme der alten Generation hat mit den Prüfsummen zu tun, die die Datenintegrität sichert und in einem in einem redundanten Pool die inetgren Daten wiederherstellen kann.
Vergiss alles was du mit herkömmlichen Filesystemen und herkömmlichen RAID weißt. Außer: RAID ist kein Backup.

Zitat

Das RAIDZ ein Backup ersetzt habe ich nicht geschrieben.

Klar hast du das.

Zitat

Wenn die Daten so wichtig währen, wäre aber ein RAIDZ1 viel zu unsicher

Daten wichtig - raidz1 zu unsicher. Das impliziert, dass Daten durch RAID gesichert werden. Das ist einfach falsch.
Wenn du selber Admin bist, dann weißt du das RAID die Verfügbarkeit erhöht, aber keine Daten sichert.
Wenn du schon gegen raidz1 Stellung nehmen mußt - was ja dein gutes Recht ist, dann müßtest du schreiben: Wenn die Verfügbarkeit so wichtig wäre.. etc
Bei ZFS mit Redundanz geht es im privaten Bereich aber eher nicht um Verfügbarkeit, sondern eher um Datenintegrität. Sonst könnte man genausogut ein herkömmliches Raid mit alten FS nehmen.

Zitat

Wenn man aber auch die letzten 5 Sekunden vor einem Crash persistiert haben muss und deshalb ein SLOG nutzt, ist das Backup viel zu alt.

Was du bitte bei einem solchen Tip erwähnen solltest: Der Threadersteller sprach von Datenbank. 5sek können in einer Datenbank einiges ausmachen. Es ist aber trotzdem wurscht, weil wenn der Server an einer USV hängt, ist es schon sehr unwahrscheinlich, dass er einfach abraucht, daher kann man im privaten Umfeld imho das Risiko durchaus eingehen.

edit: Aber um das Ganze nochmals aufzurollen: Bei einem normalen Fileserver ist sync=disable überhaupt nicht notwendig. Was allerdings die Performance wesentlich steigert ist zfs set atime=off (pool) Warum? Dieser Befehl deaktiviert das Schreiben der Access time. Stadardeinstellung ist: Jedesmal wenn ein File gelesen wird, wird eine Access time geschrieben --> Lesezugriff bedeutet dann immer auch Schreibzugriff. Das verlangsamt das Ganze natürlich und wenn man sich große Directories auflistet dann kann das dauern. Dh. wenn Acess time nicht benötigt wird, dann deaktivieren.