Validierung eines RAID5 inklusive Luks-Verschlüsselung

Um keine bösen Überraschungen bei einem Live-System zu erwarten, sollte man vorher mögliche Szenarien vorher auf einer virtuellen Maschine durchspielen.

Als Basis dient eine virtuelle Maschine unter vmware. Dabei ist es unerheblich ob vmware unter Linux oder Windows läuft. In diesem Tutorial wird auf vmware Workstation unter Linux gesetzt.

Die Konfiguration:

CPU: 1 RAM: 1024MB
Betriebssystem: Debian 6 x64 Festplatten: 1x SCSI 8GB, 5x SCSI 10GB

RAID 5 aufbauen (Schnelldurchlauf):

Partitionstabellen löschen:

dd if=/dev/zero of=/dev/sdb count=1
dd if=/dev/zero of=/dev/sdc count=1
dd if=/dev/zero of=/dev/sdd count=1
dd if=/dev/zero of=/dev/sde count=1
dd if=/dev/zero of=/dev/sdf count=1

Partition mit FD:

cfdisk /dev/sdb
cfdisk /dev/sdc
cfdisk /dev/sdd
cfdisk /dev/sde
cfdisk /dev/sdf

Raid erstellen:

mdadm --create /dev/md0 --level=5 -n 5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Konfiguration:

echo "DEVICE partitions" > /etc/mdadm/mdadm.conf
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
vi /etc/mdadm/mdadm.conf
MAILADDR max.mustermann@musterhausen.de
mdadm --monitor --scan --test --oneshot

neu einlesen:

sfdisk -R /dev/md0

mounten und schauen ob alles geklappt hat

mount /dev/md0 /mnt/raid/
df -h

RAID 5 verschlüsseln (Schnelldurchlauf):

luks installieren:

apt-get install cryptsetup
modprobe dm-mod

verschlüsseln (vorher umounten):

luksformat -t ext4 /dev/md0

cryptsetup luksOpen /dev/md0 md0_crypt

mkdir /mnt/md0_crypt

prüfen:

mount /dev/mapper/md0_crypt /mnt/md0_crypt/
df -h

Damit wir prüfen können, ob wir etwas kaputt machen, müssen natürlich Daten vorhanden sein. Also werden wir einfach das RAID 5 Array zu 90% (RAID 5 Größe) an Daten füllen. Danach sollte das in etwa so aussehen:

root@debian-test-x64:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.6G  7.6G     0 100% /
tmpfs                 247M     0  247M   0% /lib/init/rw
udev                  242M  220K  242M   1% /dev
tmpfs                 247M     0  247M   0% /dev/shm
overflow              1.0M     0  1.0M   0% /tmp
/dev/mapper/md0_crypt
                       40G   34G  3.9G  90% /mnt/md0_crypt

Worst-Case-Szenario 1a -Stecker ziehen (ohne Zugriff)

Einfach mal den Stromstecker ziehen

vmrum stop /path/to/vm/vm.vmx hard nogui

VM wieder starten und überprüfen:

e2fsck -f /dev/mapper/md0_crypt

Das Ergebnis sollte so aussehen:

root@debian-test-x64:~# e2fsck -f /dev/mapper/md0_crypt
e2fsck 1.41.12 (17-May-2010)
/dev/mapper/md0_crypt: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/md0_crypt: 11/2621440 files/data (0.0% non-contiguous), 209554/10480640 blocks

Worst-Case-Szenario 1b - Stecker ziehen (Lesezugriff)

vmrum stop /path/to/vm/vm.vmx hard nogui

Wir kopieren einfach die image.iso auf ein entferntes Samba-Share:

cp /mnt/md0_crypt /mnt/samba-server

VM wieder starten und mit e2fsck überprüfen:

root@debian-test-x64:~# e2fsck -f /dev/mapper/md0_crypt
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/md0_crypt: 15/2621440 files/data (0.0% non-contiguous), 8938400/10480640 blocks

Worst-Case-Szenario 2 – Festplatte entfernen, bzw. fällt aus

Als nächstes entfernen wir eine Festplatte aus dem Verbund, wir wählen am besten eine aus der Mitte aus, damit es auch spannend bleibt. Wir booten das System und schauen was passiert.

Wir schauen erst mal was für eine Platte betroffen ist:

root@debian-test-x64:~# mdadm -D /dev/md0
mdadm: Unknown keyword mdadm
/dev/md0:
        Version : 1.2
  Creation Time : Fri Jan 27 09:42:15 2012
     Raid Level : raid5
     Array Size : 41924608 (39.98 GiB 42.93 GB)
  Used Dev Size : 10481152 (10.00 GiB 10.73 GB)
   Raid Devices : 5
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Fri Jan 27 19:01:58 2012
          State : clean, degraded
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : debian-test-x64:0  (local to host debian-test-x64)
           UUID : 71e51ec6:f5a909a4:52d4f7ae:df1b01c8
         Events : 38

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       0        0        1      removed
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1
       5       8       65        4      active sync   /dev/sde1

Wie wir unschwer erkennen können, ist die Festplatte “sdf” ausgefallen. Jedoch vergibt Linux laufende Buchstaben, deswegen könnte es auch eine andere Festplatte sein. Warum, wieso, weshalb -> Bitte in die Kommentare schreiben, Danke! Oh schreck, Oh nein, was sollen wir tun? Zu allererst: Ruhe bewahren! Wenn wir die Platte mit Luks öffnen und mounten, sehen wir trotzdem alle Daten:

root@debian-test-x64:~# ls /mnt/md0_crypt/
image.iso  lost+found  testmovie1.mkv  testmovie2.mkv  testmovie3.avi

Um das RAID 5 wieder vollständig zu machen, bauen wir eine neue Festplatte ein und booten das System.

Wir schauen als nächstes, welchen Buchstaben die neue Platte hat:

root@debian-test-x64:~# mdadm -D /dev/md0
mdadm: Unknown keyword mdadm
/dev/md0:
        Version : 1.2
  Creation Time : Fri Jan 27 09:42:15 2012
     Raid Level : raid5
     Array Size : 41924608 (39.98 GiB 42.93 GB)
  Used Dev Size : 10481152 (10.00 GiB 10.73 GB)
   Raid Devices : 5
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Fri Jan 27 21:00:11 2012
          State : clean, degraded
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : debian-test-x64:0  (local to host debian-test-x64)
           UUID : 71e51ec6:f5a909a4:52d4f7ae:df1b01c8
         Events : 46

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       0        0        1      removed
       2       8       49        2      active sync   /dev/sdd1
       3       8       65        3      active sync   /dev/sde1
       5       8       81        4      active sync   /dev/sdf1

Es fehlt also “sdc”. Wir schauen noch unter "/dev/” nach und sehen, das “sdc” keine Partition enthält –> hat nix zu sagen, halten wir aber mal fest.

Als nächstes wird die neue Platte “sdc” bearbeitet. Die Partitionstabelle wird gelöscht und eine neue Partition angelegt mit dem Typ FD:

Partionstabelle löschen:

dd if=/dev/zero of=/dev/sdc count=1

Partion anlegen mit FD:

cfdisk /dev/sdc

So die neue Platte ist bereit um im RAID 5 Verbund aufgenommen zu werden. Linux merkt sofort, das sdc1 wieder da ist und startet sofort das rebuilding:

root@debian-test-x64:~# mdadm -D /dev/md0
mdadm: Unknown keyword mdadm
/dev/md0:
        Version : 1.2
  Creation Time : Fri Jan 27 09:42:15 2012
     Raid Level : raid5
     Array Size : 41924608 (39.98 GiB 42.93 GB)
  Used Dev Size : 10481152 (10.00 GiB 10.73 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Fri Jan 27 21:05:45 2012
          State : clean, degraded, recovering
 Active Devices : 4
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 512K

 Rebuild Status : 7% complete

           Name : debian-test-x64:0  (local to host debian-test-x64)
           UUID : 71e51ec6:f5a909a4:52d4f7ae:df1b01c8
         Events : 52

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       6       8       33        1      spare rebuilding   /dev/sdc1
       2       8       49        2      active sync   /dev/sdd1
       3       8       65        3      active sync   /dev/sde1
       5       8       81        4      active sync   /dev/sdf1

Wir schauen, wie lange der Spaß dauert:

root@debian-test-x64:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdc1[6] sdb1[0] sdf1[5] sde1[3] sdd1[2]
      41924608 blocks super 1.2 level 5, 512k chunk, algorithm 2 [5/4] [U_UUU]
      [==>..................]  recovery = 14.3% (1499648/10481152) finish=19.6min speed=7616K/sec

unused devices: 

Je nach Rechnerpower, dauert das Rebuild eine Weile. Danach sollte das RAID 5, wieder im vollen Umfang einsatzbereit sein. Klasse oder?

Weitere Worst-Case-Szenarien folgen!