RAID5 verschlüsseln und erweiterbar halten

[MKay]

Hallo allerseits,

ich bin dabei mir ein NAS zu bauen und recherchiere gerade noch ein paar notwendige Grundlagen, bevor ich loslege.
Ziel ist es ein Software-RAID5 zu haben, bei dem die Daten alle verschlüsselt sind, und das durch weitere HDDs erweiterbar ist.

Zum Einsatz kommt ein System mit einer SSD für Ubuntu Server 12.04 und 3 x 2 TB für das RAID5.

Wichtig ist mir vor allem die Erweiterbarkeit, also dass ich in einem Jahr einfach eine weitere 2-TB-Platte einstecke und nach einer Hand voll Befehlen auf der Konsole die neue Platte zum RAID5 hinzugefügt habe, sodass ich mehr Platz zur Verfügung habe.
Meinen Recherchen nach unterstützt mdadm das problemlos, auch wenn das neu Initialisieren dann etwas dauert.

Bisher geht mein Ansatz in folgende Richtung:
Jede 2 TB Platte bekommt eine Partition. Diese Partitionen werden mittels mdadm zu einem RAID5 verbunden. Anschließend wird das RAID mittels LUKS verschlüsselt und das verschlüsselte Device mit EXT4 formatiert.

Soweit ich das bisher gelesen habe kann ich auf dem RAID5-device einfach "cryptsetup luksFormat" aufrufen, und anschließend mit "cryptsetup luksOpen" öffnen und das Crypt-device anschließend mittels mkfs formatieren. Mit anderen Worten: Ich kann direkt das Crypt-device formatieren ohne zuvor mittels pvcreate, vgcreate ... das ganze LVM-basiert aufzusetzen. Ist das soweit richtig?

Meine Frage ist nun, ob ich damit die gewünschte Erweiterbarkeit dann auch beibehalte (trotz LUKS):
Kann ich das RAID5 einfach wie gewohnt durch eine weitere Platte erweitern, ohne Änderungen am EXT4-Dateisystem oder LUKS vornehmen zu müssen, und habe anschließend wie gewünscht mehr verschlüsselten Plattenplatz zur Verfügung?

Gruss, MKay

[wanne]

Kann ich das RAID5 einfach wie gewohnt durch eine weitere Platte erweitern, ohne Änderungen am EXT4-Dateisystem oder LUKS vornehmen zu müssen, und habe anschließend wie gewünscht mehr verschlüsselten Plattenplatz zur Verfügung?

luks ist da das kleinere Problem. dm-crypt-partitionen (Das ist das was hinter dem luksHeader hängt) lassen sich mit dem befehl cryptsetup resize im Betrieb vergröern.
ext4 ist da das größere Problem. Das Vergrößern soll zwar mitlerweile problemlos gehen. (Anders als mit ext3 das scheinbar relativ regelmäßig nach der Größenänderung Datenverlust hatte) aber wenn du einen RAID5 beteibst, sheint dir Ausfallsicherheit am Herzen zuliegen und da würde ich das vergrößern von ext4 partitionen nicht unbedingt empfehlen. Und im laufenden Betreib würde ich mich das schon gar nicht trauen...
(Auch wenn das mitlerweile geht.)
Zum Vergrößern brauchst du resize2fs.

[schorsch_76]

Also ich habe ext4 problemlos erweitern können. Meine root Partition im laufenden Betrieb.

Gruß
schorsch

[wanne]

Ich habe ja nicht gesagt, das esin der Mehrheit der Fälle schief geht (Das ist nichtmal beim verkleinern von NTFS der Fall, obwohl das gar nicht vorgesehen ist.). Ich glaube nur das man damit ein RIsiko eingeht, das weit größer ist, als das eine HD den Geist aufgibt.

[TRex]

Was ist denn mit dem so LVM-freundlichen xfs?

Datensicherung und Größenänderung im laufenden Betrieb (ohne Aushängen des Dateisystems)

edit: LVM-Freundlichkeit wurde nur erwähnt, weil da Größenänderungen eine der Kernfunktionen sind.

[MKay]

Zunächst einmal danke für eure Antworten

Also muss ich beim Erweitern des RAIDs sowohl das crypt-Device vergrößern, als auch das Dateisystem vergrößern.
Welches Dateisystem würdet ihr denn empfehlen, wenn ihr wisst, dass später Größenänderungen anstehen?
Beim Ändern der Größe möchte ich natürlich das Risiko eines Datenverlustes so gering wie möglich halten.

Und welchen Vorteil bringt mir LVM in meinem Fall bei der Größenänderung, wenn ich das Logical Volume dann doch wieder mit ext/xfs formatieren und später die Größe ändern muss?
Soweit ich verstanden habe erlaubt LVM zwar das Vergrößern von VGs durch Hinzufügen von PVs und dann auch das Vergrößern von LVs, aber nichts desto trotz muss weiterhin das Dateisystem ebenfalls vergrößert werden.
In meinem RAID-Fall jedoch habe ich das Zusammenfassen der HDDs ja bereits durch mdadm gegeben, welches ja ebenfalls das Vergrößern (durch Hinzufügen weiterer HDDs) unterstützt.
Letztendlich wäre ein LVM hier doch nur zusätzlicher unnötiger Ballast, oder?

[TRex]

Da hab ichs extra druntergeschrieben und du hasts doch falsch verstanden. Nein, du sollst meinetwegen kein LVM benutzen, sondern dir xfs als alternatives Dateisystem anschauen. Läuft bei mir auch sehr rund und schnell.

[MKay]

Ach, so war der Satz von dir gemeint. Ich konnte das nicht ganz zuordnen, aber nun hats Klick gemacht

Dennoch: Hat noch jemand etwas außer XFS und ext4 anzubieten, bzw. was würdet ihr verwenden? Bisher klingt XFS ganz interessant.

Und mich würde mal interessieren, wie lange so ein "cryptsetup resize" oder das Vergrößern eines XFS-Dateisystems dauert Hat da jemand ein paar Beispielwerte parat?

[TRex]

Vergrößern ging zuletzt in wenigen Sekunden.

[MKay]

So, mittlerweile ist die Hardware angekommen und zusammengeschraubt und heute bin ich endlich dazu gekommen mal ein bisschen mit RAID rumzuspielen
Zum Testen habe ich auf 3 Festplatten jeweils eine 5GB Partition angelegt, diese zu einem RAID5 verbunden, das Device verschlüsselt und anschließend ein XFS-Dateisystem angelegt. Anschließend hab ich das RAID dann um eine weitere 5GB Partition erweitert. Das alles verlief dank zahlreicher Ressourcen im Internet ohne Probleme.

Nun aber zu meiner Frage:
Danach wollte ich das "echte" RAID aufsetzen. Dazu habe ich das Dateisystem unmounted, das LUKS-Gerät geschlossen und anschließend das RAID gestoppt sowie die Super-Blöcke gelöscht:

Code: Alles auswählen

sudo mdadm --stop /dev/md0
sudo mdadm --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1

Danach habe ich mittels fdisk die richtigen Partitionen angelegt und darauf wieder ein RAID gebaut:

Code: Alles auswählen

sudo mdadm --create --verbose /dev/md0 --auto=yes --level=5 --raid-devices=3 -c 128 /dev/sdb1 /dev/sdc1 /dev/sdd1

Ein Blick mittels "cat /proc/mdstat" verrät mir folgendes:

Code: Alles auswählen

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      3907020288 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/2] [UU_]
      [>....................]  recovery =  4.5% (89829200/1953510144) finish=443.1min speed=70084K/sec

Ist es normal, dass da ein Recovery-Prozess läuft, obwohl das RAID gerade erst angelegt wurde/wird? Bei den Tests vorher ist mir nichts derartiges aufgefallen, allerdings waren die Partitionen auch um ein Vielfaches kleiner

Hier noch die Detail-Ausgabe des RAID:

Code: Alles auswählen

sudo mdadm --detail /dev/md0 
/dev/md0:
        Version : 1.2
  Creation Time : Mon May 21 23:55:02 2012
     Raid Level : raid5
     Array Size : 3907020288 (3726.02 GiB 4000.79 GB)
  Used Dev Size : 1953510144 (1863.01 GiB 2000.39 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Mon May 21 23:55:03 2012
          State : clean, degraded, recovering 
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 128K

 Rebuild Status : 2% complete

           Name : myname:0  (local to host myname)
           UUID : 3e87d0a9:e0c1c7cf:171d3819:6b7dcb1c
         Events : 1

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1
       3       8       49        2      spare rebuilding   /dev/sdd1

Dort steht auch, dass ich ein Spare-Device habe. Aber eigentlich sollten es nur 3 zum RAID 5 gehörende Partitionen sein.

EDIT:
Ich lese gerade auf der MAN-page:

When creating a RAID5 array, mdadm will automatically create a degraded array with an extra spare drive. This is because building the spare into a degraded array is in general faster than resyncing the parity on a non-degraded, but not clean, array. This feature can be overridden with the --force option.

Scheint also soweit alles in Ordnung zu sein