"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

Zfs Raid Setup

Innovaset 11.09.2018 - 19:04 1438 5
Posts

deleted5875454

Bloody Newbie
Registered: Dec 2021
Location:
Posts: 0
Servus!
Gibt ja einige zfs Experten hier, vl hat wer input, damit ich mir learning bei doing erspare :)

Ausgabgsbasis:
32gb ram, 3*500gb consumer ssd, 5*4tb consumer hdd, ev 16 oder 250gb m2 sata

Ich habe viele Fotos, Videos und Linux images ;) - und bin mir unschlüssig welches setup ich am besten verwende.

Einerseits will demnächst ei iges an Daten crawlen und analysieren (Mongo DB), andererseits eben einiges speichern, wo mir die Performance wurscht ist.

Ich wäre jetzt davon ausgangen, dass es am sinnvollsten wäre eine z1 Pool mit 3*500gb ssd zu machen für "Performance" Anwendungen, und einen z1 Pool mit 5*4tb + 16gb ssd als log cache.

Macht das Sinn? Oder gibt's da bessere Empfehlungen?

Edit: host: proxmox
Und nein, ich hab oc.at nicht gecrawlt :D
Tia
Bearbeitet von deleted5875454 am 11.09.2018, 19:08

Valera

Here to stay
Registered: Dec 2005
Location: Mint
Posts: 683
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
:)
Bearbeitet von Valera am 11.09.2018, 22:45

Crash Override

BOfH
Registered: Jun 2005
Location: Germany
Posts: 2951
Vergiss das SLOG für den Daten Pool. Das ist überflüssig, bei nicht 100% 'mission critical' Daten stellst du die Freigaben auf ASYNC, hast eine Performance die du mit SLOG nie erreichen kannst und verliert im schlimmsten Fall die letzten 5 Sekunden vor dem Totalausfall. Wenn die Daten so wichtig währen, wäre aber ein RAIDZ1 viel zu unsicher.

Optimal wäre eine 4. SSD für den schnellen Pool damit du 2 Mirror als Stripe verwenden kannst (vgl. RAID10). Dann sollte für MongoDB die Blocksize auf 64k gestellt werden. zusätzlich würde ich für alle Pools Compression auf LZ4 setzen.

Valera

Here to stay
Registered: Dec 2005
Location: Mint
Posts: 683
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.
;)

Crash Override

BOfH
Registered: Jun 2005
Location: Germany
Posts: 2951
Das RAIDZ ein Backup ersetzt habe ich nicht geschrieben. Ich bin selbst DBA und betreibe einige Datenbanken auf ZFS. 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. Dann muss man wirklich die Verfügbarkeit hoch bekommen und da hilft nunmal die Redundanz erhöhen.

Valera

Here to stay
Registered: Dec 2005
Location: Mint
Posts: 683
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.
Bearbeitet von Valera am 12.09.2018, 22:20
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz