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.
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!