ZFS mit Geli - Gibt es eine bessere Vorgehensweise?

gadean

gadean

Depp vom Dienst!
Hi,
wahrscheinlich wurde das Thema schon mehrfach hier besprochen, aber mit der Sufu konnte ich nichts finden da die Suchfunktion mir gestern Nacht permanent sagte die Suchbegriffe wären zu kurz/lang what ever. Wie dem auch sein, zum eigentlichen Thema.

Ich nutzte FreeBSD schon etwas länger und fange jetzt an mich mit ZFS anzufreunden, mein Ziel ist es die ganze Festplatte mit geli zu verschlüsseln und darauf ein raidz mit ZFS aufzubauen. Jetzt würde ich gerne von euch wissen ob meine gewählte Vorgehensweise akzeptabel ist oder ob ich irgendwo einen wichtigen Punkt übersehen habe? Bei meinen Tests hat es soweit funktioniert, aber nur weil etwas funktioniert muss es nicht optimal sein :)

Für meinen Test habe ich eine VM genommen mit 5 Disks (1x IDE, 4x SCSI), auf ada0 ist das Betriebssystem (unverschlüsselt) und mit da0-da3 soll das raidz realisiert werden. Dazu habe ich da0-da3 erst mit geli initialisiert, danach "ge-mount-ed" und ein raidz erstellt. Die Disks waren komplett unformatiert und mit dd überschrieben worden.

Kurz Fassung:
Code: 
# geli init -b -l 256 -s 4096 /dev/da0
# geli init -b -l 256 -s 4096 /dev/da1
# geli init -b -l 256 -s 4096 /dev/da2
# geli init -b -l 256 -s 4096 /dev/da3
# geli attach /dev/da0
# geli attach /dev/da1
# geli attach /dev/da2
# geli attach /dev/da3
# zpool create tank raidz1 /dev/da0.eli /dev/da1.eli /dev/da2.eli /dev/da3.eli
# zpool status tank
  pool: tank
 state: ONLINE
  scan: none requested
config:

        NAME         STATE     READ WRITE CKSUM
        tank         ONLINE       0     0     0
          raidz1-0   ONLINE       0     0     0
            da0.eli  ONLINE       0     0     0
            da1.eli  ONLINE       0     0     0
            da2.eli  ONLINE       0     0     0
            da3.eli  ONLINE       0     0     0

errors: No known data errors

Wie gesagt, habe ich etwas übersehen oder vergessen? Oder ist der Weg akzeptabel?

Mit freundlichen Grüßen
ohaucke
 
Ich behandle die Platten vor der Verschluessellung noch mit gpart und gebe ihnen ein label.
Das ist ganz praktisch, wenn man spaeter sehr viele Festplatten hat und diese dann umsteckt, dadurch aendern sich die /dev/<name> nicht
und man kommt nicht durcheinander. (Oder wenn man diese halt in einen anderen computer einbaut)

Das sieht dann so aus.

Code: 
gpt/mirror0.disk0.eli
gpt/mirror0.disk1.eli
gpt/mirror0.disk2.eli

gpt/mirror1.disk0.eli
gpt/mirror1.disk1.eli
gpt/mirror1.disk2.eli
...

Zumahl das auch im 'zpool status' "schoener" aussieht
 
Zu unterscheiden sind GEOM labels und GPT labels. Um GPT labels nutzen zu können (gpart), muss man die Disk partitionieren. GEOM labels (glabel) funktionieren, indem einfach in den letzten Block einer Disk ein GEOM header geschrieben wird.

Ich mache erst GELI und dann glabel, damit auf der Disk keinerlei Klartext ist. Andersrum geht auch, dann ist das Label aber im Klartext auf der Disk.
 
Ich bevorzuge Platten per GPT zu formatieren und die Partitionen zu benennen. Warum sollte man sich anschließend noch ein zusätzliches GEOM Label antun?
Es reicht außerdem /boot auf einem unverschlüsselten Dateisystem zu haben. Dafür braucht es kein komplettes Basesystem. Du kannst in nem Livesystem z.B. einen verschlüsselten Pool anlegen und in diesen installieren. Anschließend legst du einen Pool den gptzfsboot lesen kann an und verschiebst /boot in diesen. Damit die Pfade dennoch passen solltest du einen Symlink auf die Kopie unter /boot anlegen. Afaik kann gptzfsboot nur Pools mit einem genau einem VDEV lesen. Diese VDEV muss entweder eine Disk, ein Mirror oder ein RAID-Z1 sein. Es bietet sich also an einfach einen 2iGB bis 4GiB mirrored Pool über alle Platten zu verteilen um dort /boot zu lassen.
 
Crest schrieb:
Ich bevorzuge Platten per GPT zu formatieren und die Partitionen zu benennen. Warum sollte man sich anschließend noch ein zusätzliches GEOM Label antun?
Zum Vergrößern anklicken....

Ich benutz ja gar keine Partitionen. Meine ZFS-Komponenten gehen von Block 0 bis last-1. Im Letzten ist das glabel.
 
Solange der Anfang deiner GELI Partition korrekt ausgerichtet ist z.B. mit gpart add -a 4k sowie mittels geli init -s 4096 auf die optimale Blocksize eingestellt wurde gibt bei ZFS auf GELI keine Probleme mit 4KiB Sectorsize.
 
Ok, da ich aber beim Live-System nur Platten mit 512Byte Sector size habe reichts wenn ich beim geli init "-s 512" abgebe? Den Spaß mit export, destroy und import (bezogen auf nop) kann ich mir da sparen?
 
Wenn du GELI nimmst und dort schon -s 4096 angibst, dann fällt das Gefummel mit GNOP eh komplett weg.
 
Ok, da ich aber beim Live-System nur Platten mit 512Byte Sector size habe reichts wenn ich beim geli init "-s 512" abgebe? Den Spaß mit export, destroy und import (bezogen auf nop) kann ich mir da sparen?
Zum Vergrößern anklicken....
.

  1. Wie TCM schon sagt, wenn du Geli mit -s4k benutzt brauchst du kein GNOP mehr. ZFS erkennt die passende Blockgröße vom Device darunter von selbst. Wenn deine HDDs was falsches angeben (üblich sind 4k platten die sich als 512 byte ausgeben) wird ZFS das auch falsch erkennen. GNOP ist einfach eine Device-Schicht wie GELI. Unterschied ist: Sie tut nichts sondern reicht nur durch. Man kann aber GNOP so erstellen, dass es "nach oben" aussieht wie 4k Sektorgröße. Mit Geli -s4k hast du schon ein Device was "nach oben" 4k angibt, du parst dir das GNOP also.
  2. Unabhängig von deiner tatsächlichen Sektorgröße würde ich dir empfehlen, 4k Sektorgrößen zu verwenden mit ZFS. Du kannst diese nämlich nie mehr ändern für einen einmal erstellten Pool. Wenn du also in ein, zwei Jahren einige HDDs mit 4k HDDs ersetzt wirst du dich sonst schwarzärgern wenn du 512 byte ZFS hast. Eine größere Sektorgröße (4k ZFS auf 512 byte HDD) ist nicht oder nur unmerklich langsamer, eine zu kleine Sektorgröße (512 byte ZFS auf 4k HDD) hingegen kann deutlich bremsen.
 
Wieso? Wer in ein paar Jahren Platten kauft wird am besten gleich nen neuen Pool anlegen und mit zfs send/recv die Datasets replizieren.
 
Crest schrieb:
Wieso? Wer in ein paar Jahren Platten kauft wird am besten gleich nen neuen Pool anlegen und mit zfs send/recv die Datasets replizieren.
Zum Vergrößern anklicken....

Klar, wenn du alle auf einmal erneuerst, dann schon. Wenn du deinen Pool aber noch ein paar Jahre behalten willst und nur Ausfälle ersetzt, dann bleibst du auf deiner initialen Sektorgröße sitzen. Ich weiß nicht, wie lange es noch neue 512er Platten geben wird oder in wiefern man dann bei der Auswahl eingeschränkt ist.

Mit ZFS kann man ansonsten auch Pools vergrößern, indem man größere Platten einbaut. Aus einem Raid-Z mit 3x1gig könnte so mit der Zeit ein Raid-Z mit 3x2gig werden. Wer keine Kosten scheut und genug Systeme oder Anschlüsse hat, kann sich natürlich auch einfach einen komplett neuen Satz Platten kaufen und zfs send/recv machen. Ich finde die Option die Daten schrittweise umzuziehen im Heimbereich jedenfalls sehr praktisch.
 
Was namor ansprach ist sogar früher oder später geplant, also das ersetzten der Disks zur vergrößerung des Pools. Also kurz nochmals zusammengefasst, die leere Disk mit geli und 4k Sektorgröße initialisieren, danach mit glabel labeln und daraus ein zfs pool erstellen.

Hab ich eig. schon danke schön für eure Hilfe gesagt? Vielen Dank!
 
Fuer den Fall, dass jede deiner Platten ein anderes Kennwort hat, wuerd ich trotzdem vor Geli ein gpart rauflegen.
Steckst du beispielsweise deine Platten um, und du hattest zuvor Kennwort X fuer ada3, dann aendert sich ada3 meinetwegen in ada2 und du musst erst rumprobieren, welche Platte nun welches Kennwort hatte.
Geht Beispielsweise dein Mainboard kaputt, oder du packst das an einen Raid Controller etc. musst du umstecken.

LG
 
Zu meiner Schande muss ich gestehen das ich bei allen Platten das selbe Passwort nutze bzw. auch weiterhin nutzen werde (36 Zeichen, a-zA-Z, Sonderzeichen).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben