Aufspaltung eines RAID
Typischerweise haben Server einen RAID-Controller, der einen Festplattenausfall vor dem Betriebssystem verstecken kann. Wenn also eine Platte den Geist aufgibt, kann man sie wechseln, ohne auf irgendeine Besonderheit des installierten Systems Rücksicht nehmen zu müssen. Das erleichtert die Arbeit im Rechenzentrum erheblich: Platte tot → Austauschen → Fertig.
Redundante Redundanz
Auf einen Satz Server ist Proxmox zum Spielen drauf gekommen. Der Installer richtet auf einer ausgewählten Platte das System ein. In dem Fall also auf dem Hardware-RAID. Soweit so gut.
Für das Storage möchte ich auf Ceph zurück greifen, auf Neudeutsch hyperkonvergent arbeiten. Deswegen habe ich den größten Teil der Platte frei gelassen um den Rest als OSD einbinden zu können.
Ceph verwaltet eine eigene Redundanz über die OSD-Datenträger. Es berücksichtigt dabei großräumigere Strukturen als nur Platten an einem Contoller. Dies führt zu massiver Platzverschwendung: Daten liegen nicht mindestens doppelt, sondern vier- bis sechsfach vor.
Wird das Hardware-RAID aufgebrochen, kann Ceph die einzelen Platte direkt verwalten und damit effizienter umgehen. Aber was wird aus dem Basissystem?
Eine Neuinstallation später steht fest, dass der Proxmox-Installer das System ausschließlich auf eine der beiden Platte installiert hat. Konzeptionell ist das nachvollziehbar, da so mehr Platz für die OSDs bleibt. Geht die Systemplatte kaputt, installiert man den Knoten halt komplett neu und der Cluster erledigt den Rest.
Ich scheue aber den Aufwand, da die Netzwerkinstallation des Basissystem hier doch stärker vom Proxmox-Standard abweicht, als erwartet. Aber dazu ein andermal.
Aus eins mach zwei
Zuerst ein Blick auf die Situation direkt nach der Installation:
root@server21:~# fdisk /dev/sda Welcome to fdisk (util-linux 2.29.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/sda: 279.4 GiB, 300000000000 bytes, 585937500 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 3B2CD483-DE39-45BA-BF6A-C35E2AD8F783 Device Start End Sectors Size Type /dev/sda1 34 2047 2014 1007K BIOS boot /dev/sda2 2048 1050623 1048576 512M EFI System /dev/sda3 1050624 41943040 40892417 19.5G Linux LVM
Die Platte sdb ist leer.
Im ersten Schritt kopiere ich den Anfang der Platte incl. alle Boot-Informationen:
root@server21:~# dd if=/dev/sda of=/dev/sdb bs=512 count=1050623
Ja, die GPT ist auf der zweiten Platte kaputt, da die Kopie am Ende der Platte fehlt. Aber das behebt fdisk beim nächsten Aufruf.
So kann nun die zweite Platte so eingerichtet werden, wie später es sein soll:
root@server21:~# fdisk /dev/sdb [...] Command (m for help): t Partition number (1-3, default 3): Hex code (type L to list all codes): 29 Changed type of partition 'Linux LVM' to 'Linux RAID'. Command (m for help): p Disk /dev/sdb: 279.4 GiB, 300000000000 bytes, 585937500 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 3B2CD483-DE39-45BA-BF6A-C35E2AD8F783 Device Start End Sectors Size Type /dev/sdb1 34 2047 2014 1007K BIOS boot /dev/sdb2 2048 1050623 1048576 512M EFI System /dev/sdb3 1050624 41943040 40892417 19.5G Linux RAID
Und wenn wir schon mal hier sind, dann auch gleich das OSD vorbereiten
Command (m for help): n
Partition number (4-128, default 4):
First sector (41943041-585937466, default 41945088):
Last sector, +sectors or +size{K,M,G,T,P} (41945088-585937466, default 585937466):
Created a new partition 4 of type 'Linux filesystem' and of size 259.4 GiB.
Command (m for help): t
Partition number (1-4, default 4):
Hex code (type L to list all codes): 76
Changed type of partition 'Linux filesystem' to 'Ceph OSD'.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.Damit sehen die Platten so aus:
Die grünen Partitionen sind schon in Ordnung, die grünen Inhalte ebenfalls. Rot markierte Teile sind noch beheben, die Blauen noch unbenutzt.
Aus zwei mach eins
Zunächst muss das RAID als solches fertig werden. Es soll ein Spiegel werden, aber anfangs nur mit einer Partition.
root@server21:~# mdadm --create /dev/md0 -n 1 -f -l 1 /dev/sdb3
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90Sehr gute Frage! Ich habe den Boot-Kram in separaten Boot-Partitionen, was kann da schon schief gehen?
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@server21:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb3[0]
20429824 blocks super 1.2 [1/1] [U]
unused devices: <none>Schaut gut aus. Jetzt nur noch die Daten des LVM rein kopieren.
Die Idee ist dabei, das LVM aufzublasen und dann die alte Partition wieder raus zu nehmen.
root@server21:~# pvcreate /dev/md0 Physical volume "/dev/md0" successfully created. root@server21:~# pvdisplay --- Physical volume --- PV Name /dev/sda3 VG Name pve PV Size 19.50 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 4991 Free PE 3775 Allocated PE 1216 PV UUID ijshQ9-3z2d-oVxd-WJB2-8LUv-HEfL-lTZzEi "/dev/md0" is a new physical volume of "19.48 GiB" --- NEW Physical volume --- PV Name /dev/md0 VG Name PV Size 19.48 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID G8kgdF-Gcec-ddbO-92ys-9rsf-dkpo-Za9C4a root@server21:~# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md0 lvm2 --- 19.48g 19.48g /dev/sda3 pve lvm2 a-- 19.50g 14.75g
Es gibt nun zwei LVM-Datenträger, von denen einer das Volume enthält. Nun zum Umzug.
root@server21:~# vgextend pve /dev/md0 Volume group "pve" successfully extended root@server21:~# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md0 pve lvm2 a-- 19.48g 19.48g /dev/sda3 pve lvm2 a-- 19.50g 14.75g root@server21:~# vgdisplay -C VG #PV #LV #SN Attr VSize VFree pve 2 1 0 wz--n- 38.98g 34.23g root@server21:~# vgreduce pve /dev/sda3 Physical volume "/dev/sda3" still in use
Vergrößern ging, aber die alte Partition lässt sich nicht entfernen!
Warum? Weil noch Daten drauf sind. Schließlich wurde ja nur neuer Platz hinzugefügt. Nur der ist unbenutzt.
root@server21:~# pvmove /dev/sda3 /dev/sda3: Moved: 0.00% /dev/sda3: Moved: 18.17% /dev/sda3: Moved: 36.43% /dev/sda3: Moved: 54.52% /dev/sda3: Moved: 72.86% /dev/sda3: Moved: 91.04% /dev/sda3: Moved: 100.00% root@server21:~# pvdisplay --- Physical volume --- PV Name /dev/sda3 VG Name pve PV Size 19.50 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 4991 Free PE 4991 Allocated PE 0 PV UUID ijshQ9-3z2d-oVxd-WJB2-8LUv-HEfL-lTZzEi --- Physical volume --- PV Name /dev/md0 VG Name pve PV Size 19.48 GiB / not usable 3.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 4987 Free PE 3771 Allocated PE 1216 PV UUID G8kgdF-Gcec-ddbO-92ys-9rsf-dkpo-Za9C4a
Nun ist nichts mehr auf der alten Partition in Benutzung. "Allocated PE" ist 0.
Also müsste sich die Partition nun entfernen lassen.
root@server21:~# vgreduce pve /dev/sda3 Removed "/dev/sda3" from volume group "pve" root@server21:~# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md0 pve lvm2 a-- 19.48g 14.73g /dev/sda3 lvm2 --- 19.50g 19.50g
Hurra! Nun noch die Partition dem LVM entziehen.
root@server21:~# pvremove /dev/sda3 Labels on physical volume "/dev/sda3" successfully wiped. root@server21:~# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md0 pve lvm2 a-- 19.48g 14.73g
Und die Partition umwidmen.
root@server21:~# fdisk /dev/sda
Welcome to fdisk (util-linux 2.29.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/sda: 279.4 GiB, 300000000000 bytes, 585937500 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3B2CD483-DE39-45BA-BF6A-C35E2AD8F783
Device Start End Sectors Size Type
/dev/sda1 34 2047 2014 1007K BIOS boot
/dev/sda2 2048 1050623 1048576 512M EFI System
/dev/sda3 1050624 41943040 40892417 19.5G Linux LVM
Command (m for help): t
Partition number (1-3, default 3):
Hex code (type L to list all codes): 29
Changed type of partition 'Linux LVM' to 'Linux RAID'.
Command (m for help): p
Disk /dev/sda: 279.4 GiB, 300000000000 bytes, 585937500 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3B2CD483-DE39-45BA-BF6A-C35E2AD8F783
Device Start End Sectors Size Type
/dev/sda1 34 2047 2014 1007K BIOS boot
/dev/sda2 2048 1050623 1048576 512M EFI System
/dev/sda3 1050624 41943040 40892417 19.5G Linux RAID
Command (m for help): n
Partition number (4-128, default 4):
First sector (41943041-585937466, default 41945088):
Last sector, +sectors or +size{K,M,G,T,P} (41945088-585937466, default 585937466):
Created a new partition 4 of type 'Linux filesystem' and of size 259.4 GiB.
Command (m for help): t
Partition number (1-4, default 4):
Hex code (type L to list all codes): 76
Changed type of partition 'Linux filesystem' to 'Ceph OSD'.
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.Bei der Gelegenheit auch gleich noch die OSD Partition vorbereitet. Sehr schön.
Jetzt kann das RAID breit gezogen werden.
root@server21:~# mdadm -a /dev/md0 /dev/sda3
mdadm: added /dev/sda3
root@server21:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda3[1](S) sdb3[0]
20429824 blocks super 1.2 [1/1] [U]Nein.Das ist kein "hot spare", das ist Bestandteil des RAIDs selbst. Ich hätte wohl gleich mit zwei Partitionen, davon eine als "none", anfangen sollen.
root@server21:~# mdadm -r /dev/md0 /dev/sda3
mdadm: hot removed /dev/sda3 from /dev/md0
root@server21:~# mdadm --grow /dev/md0 -n 2 -a /dev/sda3
mdadm: added /dev/sda3
raid_disks for /dev/md0 set to 2
root@server21:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda3[1] sdb3[0]
20429824 blocks super 1.2 [2/1] [U_]
[>....................] recovery = 3.2% (669248/20429824) finish=1.4min speed=223082K/sec Hurra! Jetzt schaut es so aus.
Reboot
Da nun alles im laufenden Betrieb umgezogen ist, bleibt nur noch der finale Reboot.
Klappt aber nicht, weil der Grub das LVM-Volume nicht mehr findet. Sollte /boot nicht separat liegen?! Mal beim Nachbar nachschauen:
root@server22:~# mount | grep boot /dev/sda2 on /boot/efi type vfat ...
Ohje. Also nochmal von vorn und diesmal mit "--metadata=0.9". Siehe an, es geht.
Aber was ist eigentlich passiert? Zur Erinnerung nochmal die Warnung.
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90Die Metadaten des RAID können also am Anfang (neu) oder am Ende (alt) der Partition stehen. Wenn sie am Ende stehen, muss niemand irgendwas von dem RAID1 (Mirror) verstehen, um auf den Inhalt zugreifen zu können. Die Partition sieht halt aus, als gäbe es gar kein RAID.
Stehen die Daten am Anfang der Partition, muss die Software damit umgehen können. Im Prinzip ist das auch sehr einfach, weil man nur über die RAID-Kennung hinweg springen muss. Leider kann das Grub nicht und ist damit ein steter Quell von Problemen.