Fileserver Geli+ZFS Setup

lockdoc

Well-Known Member
Hi,

ich wollte einen ZFS Fileserver mit 6 x1TB Samsung Spinpoint F3 im Mirror und evtl. einer SSD aufsetzen, natuerlich soll der ZFS Pool mit Geli Vollverschluesselt sein.

Hiermal ein paar Fragen, die ich gerne abwaegen wollte zwecks Performance.
Was meint ihr?

[1] Sollte das System selbst im Pool laufen oder lieber auf einer extra UFS Partition/Platte?

[2] erst Geli und dann ZFS oder erst ZFS und dann Geli?

[3] Was sollte alles auf die SSD ausgelagert werden?

[4] Was muss ich beim Sector Alignment der Platten beachten, wenn ich Geli mit ZFS benutze, da Geli ja ihre eigene Blocksize auf die vorhandene der Platten drueberpackt?
 

cla

Well-Known Member
1. System auch als ZFS-Dateisystem; muss nicht zwangsläufig der gleiche Pool sein. Ich würde sogar einen eigenen Pool dafür definieren. Aber ZFS mit UFS mischen würd ich vermeiden, da sich beide Dateisysteme gegenseitig den RAM streitig machen - suboptimal.

2. afaik erst Geli, dann ZFS; so machts glaub auch die Verschlüsselung von PC-BSD.

3. ZFS Logdevice und Cachedevice (braucht FreeBSD 9.0 oder höher) für deinen Datenpool. (ein paar GB reichen da schon). Bleibt noch genug für anderweitigen Spaß übrig. Theoretisch könntest du auch das System auf die SSD installieren und davon booten...dann am Ende noch 2 Partitionen für Log/Cache dazu und dein ZFS Pool hat auch noch einen schönen SSD-Cache.
Die Festplatten sind dann einzig und alleine dein großer Datenpool und unabhängig vom System. Nachteil: Dein System wäre nicht redundant.

4. Kann ich leider nix zu sagen, was das Zusammenspiel mit Geli angeht.

Allgemein: Warum ein Mirror, anstatt ein RaidZ2? Performance?
 

lockdoc

Well-Known Member
@cla:
soweit ich das verstanden habe ist raid-z eher fuer seriellen zugriff und ein mirror fuer random access. Zudem ist es ja ein stripe bestehend aus 3 mirrorn, also sollte ich theoretisch 6-fache lesegeschwindigkeit haben und 3-fache schreibgeschwindigkeit.
Wogegen er bei Raid-Z (soweit ich weiss) immer abhaengig von allen platten lesen muss und bei mirror unabhaengig, da es ja identisch ist.
 

Crest

rm -rf /*
Teammitglied
Schön das mal jemand klare Fragen stellt.

[1] Sollte das System selbst im Pool laufen oder lieber auf einer extra UFS Partition/Platte?
Ich rate dazu das System und die Daten in getrennten Pools zu halten. Es erlaubt dir die Daten auch mal mit einem paar TiB/min zwischen zwei Systemen zu bewegen.

[2] erst Geli und dann ZFS oder erst ZFS und dann Geli?
ZFS ist (auch) ein Dateisystem. Ein Dateisystem brauchst du zu oberst. GELI arbeitet auf GEOM Providern (in deinem Fall Platten/Partitionen). Die einfachste (und vermutlich einzig sinnvolle) Anordnung erst GELI dann ZFS. Es wäre möglich erst ZFS zu verwenden um einen Pool anzulegen in diesem ZVOLs zu definieren und mit GELI zu verschlüsseln. Auf den verschlüsselten ZVOLs könntest du anschließend ZFS (oder UFS) verwenden. Dies wäre jedoch deutlich langsamer.

[3] Was sollte alles auf die SSD ausgelagert werden?
SSDs sind keine magische Waffe gegen Performanceprobleme. Es bietet sich an sowohl das OS und das ZIL des Datenpools aus zu lagern.

[4] Was muss ich beim Sector Alignment der Platten beachten, wenn ich Geli mit ZFS benutze, da Geli ja ihre eigene Blocksize auf die vorhandene der Platten drueberpackt?
ZFS hat eine dynamische Blockgröße pro VDEV von 2 hoch ashift bis 128KiB. Ashift wird pro VDEV beim erstellen des VDEVs festgelegt. ZFS wählt ashift automatisch passend das 2 hoch ashift >= der größten Sektorgröße aller Devices des VDEVs. Leider lügen SATA Platten was ihre Sektorgröße angeht. Der Workaround ist es gnop create -S 4096 $name auf die GEOM Provider anzuwenden und anschließend den Pool auf den $name.nop zu erstellen. Diese werden beim Reboot nicht wieder erstellt und ZFS findet seine Devices anhand der Metadaten wieder. Damit ist ausgeschlossen, dass ZFS mit seiner dynamischen Blockgröße mit 4kiB Platten Probleme macht. All dies setzt vorraus das die Partitionen für ZFS auf 4kiB ausgerichtet sind. Dafür hat gpart das -a Flag.

Soll das "/" FS verschlüsselt sein muss "/boot" auf einem eigenen Pool liegen und vorzugsweise zur Laufzeit als Symlink nach "/boot" gelinkt werden. Darüber hinaus vertragen sich UFS und ZFS unter Last nicht sobald das RAM knapp wird, weil beide ihre Puffer selbst verwalten. Entscheide dich für eins von beiden pro System.
 

lockdoc

Well-Known Member
Hallo Crest, Danke fuer die Info.
Noch eine Unklarheit:

Ich rate dazu das System und die Daten in getrennten Pools zu halten. Es erlaubt dir die Daten auch mal mit einem paar TiB/min zwischen zwei Systemen zu bewegen.

[X] Meinst du damit, dass wenn man die Daten vom System trennt, dass dann der Datenpool mehr Power hat, als wenn noch das OS mit drauf waere?

Soll das "/" FS verschlüsselt sein muss "/boot" auf einem eigenen Pool liegen...
Boot erfolgt ueber USB Stick, wie im wiki Article beschrieben.


Also wie ich den Datenpool erstelle, dass ist mir schon klar, die schwere Frage ist jetzt, wie genau erstelle ich den Pool fuer das OS mit folgenden Anforderungen:
+ liegt auf einer SSD (60GB)
+ ZIL + L2ARC sollen drauf
+ OS soll drauf

[X] Was davon sollte verschluesselt sein?
[X] Wie sollte ich das partitionieren?
[X] Was sind denn die commands um ZIL und L2ARC auszulagern?

Als Anreiz:
Ich spendiere dafuer noch einen Wiki-Eintrag :-)
 

Nukama

Well-Known Member
[1] System auf SSD, möglicherweise auch auf einen gesonderten ZFS Pool auf die SSD verfrachten. Auf jeder Festplatte eine freebsd-boot Partition packen, dann kommt das System auch in die Gänge, wenn die Bootreihenfolge verändert wird.
[2] erst den geom_eli Provider, und diesen dann an ZFS verfüttern
[3] Auf jeden Fall bei einer SSD Karte nur Daten darauf lagern, die immer wieder beschafft werden können.
[4] Wenn geli mit einer Blockgröße von z.B. 4096 initiiert wird kann diese Größe zuvor als -a Parameter innerhalb von "gpart add" benutzt werden. Sollte den Anfang/Ende einer Partition an die richtige Stelle rücken. Das Wichtige dabei ist, dass die Blockgröße dieselbe oder ein Vielfaches des darunterliegendes Mediums ist, und es so zu keinen Überlappungen kommt.

Update: SSD schön partitionieren für deine Wünsche.
1. freebsd-boot
2. freebsd-zfs oder freebsd-ufs für /boot
3. freebsd-zfs oder freebsd-ufs für /
4. Partition für cache
5. Partition für log
(6. Partition für swap)

Um die log und cache vdevs einzubinden:
zpool create -n data mirror ada1 ada2 mirror ada3 ada4 mirror ada5 ada5 cache /dev/ada0p4 log /dev/ada0p5

Wenn der Datenpool vollständig verschlüsselt sein soll, sollte vielleicht auch das cache und log device verschlüsselt werden, was sich aber in erheblichen Einbußen in der Performance niederschlägt. Dann verschlüssele den kompletten / gleich mit. ;)
 

mark05

Well-Known Member
moin
im prinzip habe ich ein aehnliches setup im auge

verwendet wir fbsd 9 da hier wohl das 4k grundsaetzlich geloest ist.

die ssd ( 60GB ) teile ich im prinzip in 4 teile auf
25 G fuer OS zum booten etc
5G swap
15 G zfs cache
5 G zil

der bereich wo letztenendlich daten liegen ist bei mir zz nur eine einzelen 2 TB wd platte
die will ich aber noch irgendwann mirrorn ( wenn platten preise wieder ok sind )

deswegen ist sie schon im zfs pool eingebunden.

holger

p.s. wieviel macht es den aus wenn man zfs und ufs mischt ?
 

lockdoc

Well-Known Member
So bin schon am verbauen...
Leider warte ich noch auf die SSD und noch 3 weitere Schwebehalter fuer die HDD's :D:D:D:
 

Anhänge

  • DSCF1146.JPG
    DSCF1146.JPG
    280,2 KB · Aufrufe: 426

lockdoc

Well-Known Member
[4] Wenn geli mit einer Blockgröße von z.B. 4096 initiiert wird kann diese Größe zuvor als -a Parameter innerhalb von "gpart add" benutzt werden[...]
Hallo Nukama,
Fer gpart kann ich bei add nirgends den -a param finden
Code:
gpart add -b start -s size -t type [-i index] [-l label] [-f flags] geom



Irgendwie scheint dieses 4k Problem noch schwieriger zu sein als ich dachte. Schon allein ohne Geli habe ich 3 Versionen gefunden (Beispiel mit nur 1er HDD)

1. gpart mit partition + align via gnop
http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/
Code:
## (01.) create partition
> gpart create -s gpt ada0
> gpart add -t freebsd-zfs -l disk0 ada0

## (02.) align disk for 4k
> gnop create -S 4096 /dev/gpt/disk0
> zpool create data /dev/gpt/disk0.nop
> zpool export data
> zpool destroy /dev/gpt/disk0.nop
> zpool import data


2. gpart ohne partition + align via gnop
http://ivoras.net/blog/tree/2011-01-01.freebsd-on-4k-sector-drives.html
Code:
## (01.) align 4k
gnop create -S 4096 /dev/ada0

## (02.) create pool
zpool create data /dev/ada0.nop
zpool export data
gnop destroy /dev/ada0.nop
zpool import data


3. gpart mit partition + align via gpart (wie wie windows es macht 1MB frei am Anfang)
http://www.wonkity.com/~wblock/docs/html/disksetup.html#_the_new_alternate_method_tt_gpart_8_tt
Code:
## (01.) alignment
gpart create -s gpt ada0
gpart add -t freebsd-zfs -b 1M ada0

## dann der pool
...



Was waere denn jetzt die Beste herangehensweise a) ohne Geli und b) mit Geli?
 

Yamagi

Possessed With Psi Powers
Teammitglied
Aus der Log eher wenig, ledichlich Metadaten wie zum Beispiel Dateinamen. Auch Nutzungsmuster lassen sich vielleicht auslesen. Aus dem Cache-Device kann man hingegen durchaus größere Mengen Nutzdaten extrahieren.
 

lockdoc

Well-Known Member
Ahh ok, das ist ja immer wichtig zu wissen. Nachher hat man das vollverschluesselte System und dann lesen andere trotzdem munter daten raus ;-)

Macht denn eine geli encrypted cache ssd ueberhaupt sinn zwecks performance, oder wird dass dann so langsam, dass ich mir das kneifen kann?
 

KobRheTilla

used register
Aber ZFS mit UFS mischen würd ich vermeiden, da sich beide Dateisysteme gegenseitig den RAM streitig machen - suboptimal.
Entgegen allem FUD hab ich das noch nicht beobachtet, zumindest wenn man genug Arbeitsspeicher hat.

3. ZFS Logdevice und Cachedevice (braucht FreeBSD 9.0 oder höher) für deinen Datenpool.

9? Ist hier schon seit 8 im Einsatz. Ich würde auch eher zum Cache tendieren, außer du brauchst wahnsinnige NFS-Performance, dann als ZIL. Auch würde ich nicht beides auf _einen_ Datenträger packen.

Rob
 

KobRheTilla

used register
Danke Rob, kannst du noch kurz sagen warum?

Ist ne persönliche Einstellung :-) Zwar kann man mittlerweile Pools mit kaputtem ZIL restaurieren (dem L2ARC ist es eh egal) dennoch würde ich lieber nen mirror für ZIL nehmen, auch wenn es nur 2 USB Sticks sind, da kommen nicht viel Daten zusammen... Aber wie schon geschrieben, ZIL ist _nicht_ unbedingt nötig, nehm die SSD lieber als Cache. Da lohnt es sich auch, evtl. nur Metadaten zu cachen (secondarycache=metadata), je nachdem wie die Workload ausfällt, dann hast du auch nicht so ein großes Problem mit nichtverschlüsselten Daten.

Rob
 

lockdoc

Well-Known Member
Nagut, dann lass ich den ZIL erstmal weg und nehme eine SSD fuer das os und eine SSD fuer L2ARC.
Die Frage ist jetzt noch welches Dateisystem L2ARC ueberhaupt braucht, also wie baue ich das?
 

lockdoc

Well-Known Member
Hmm, also da hab ich mich falsch ausgedrueckt.
Ich meinte eigentlich, ob die platte auch gpart und ein eigenes dateisystem braucht, oder ob ich das einfach ohne was zu machen als device hinzufuege
 

KobRheTilla

used register
Ich meinte eigentlich, ob die platte auch gpart und ein eigenes dateisystem braucht, oder ob ich das einfach ohne was zu machen als device hinzufuege

ZFS ist doch ein Dateisystem. Und es ist dafür gebaut, auf rohen Devices zu arbeiten. Du brauchst nix mit der SSD machen, außer sie in den Pool aufzunehmen.

Rob
 

lockdoc

Well-Known Member
Achso? Bisher habe ich (Die Datenfestplatten) immer erst wie folgt vorbereitet, bevor ich sie in den pool geschoben habe:
Code:
gpart create -s GPT ad10
gpart add -t freebsd-zfs ad10
Das kann ich also fuer L2ARC weglassen.
Kann ich es denn auch (abgesehen vom 4k Problem) fuer die Datenplatten weglassen?
 

Nukama

Well-Known Member
Das log/cache-vdev kann das ganze Device umfassen, oder nur eine Partition.

Es ist nicht notwendig, die ganze SSD als L2ARC oder ZIL zu nutzen. Das OS passt da meistens auch noch drauf.

Beim cache-Device ist es nicht notwendig auf hohe Schreibraten zu setzen, da es mit einer limitierten Schreibrate gefüllt wird.
 

Yamagi

Possessed With Psi Powers
Teammitglied
KobRheTilla schrieb:
Entgegen allem FUD hab ich das noch nicht beobachtet, zumindest wenn man genug Arbeitsspeicher hat.
Das war auch eher ein Problem der frühen Versionen, bis etwa FreeBSD 8.1. Schon 8.2 war in Sachen RAM viel besser und mit 9.0 ist es nun eigentlich alles in Ordnung. Ich habe da aber irgendwie immer noch ein rational nicht zu begründendes, schlechtes Gefühl bei... Wobei ich selbst die extremen Slowdowns auch nur unter 7.3 gesehen habe.
 
Oben