Viele Proxmox VE Installationen werden redundant ausgelegt, bei der Installation von Proxmox VE kann man das Betriebssystem mittels ZFS on Linux gespiegelt auf ZFS-Mirror (ähnlich RAID1) installieren. Dadurch erhält das System Ausfallsicherheit, da eine der beiden System-Platten nun ausfallen darf, trotzdem startet das System weiterhin ohne Probleme. In diesen Artikel zeigen wir, welche Schritte nach einem Ausfall einer Systemfestplatte zu tun sind. Wir gehen auf die verschiedenen Boot-Loader (GRUB) oder systemdbootd (UEFI) ein und zeigen wie Sie einen Austausch einer Festplatte vornehmen können, sodass Ihr Mirror wieder vollständig Online und Healthy und die Redundanz des Betriebssystem wiederhergestellt ist.
Testen Sie den Vorgang einmal in einer virtuellen Umgebung - hierzu einfach eine Proxmox-VM erstellen dort PVE installieren auf ein ZFS RAID-1 und dann können Sie schon einmal den Vorgang ohne größeres Risiko nach testen.
Zuerst müssen Sie herausfinden ob Sie für den Systemstart GRUB oder systemd-boot verwenden.
Wird Ihnen diese Ausgabe angezeigt, so wird kein UEFI verwendet und Sie verwenden Grub im Legacy Mode:
root@pve-virtual-01:~# efibootmgr -v EFI variables are not supported on this system.
Sieht die Ausgabe so aus, so verwenden Sie GRUB im UEFI mode:
root@pve-virtual-01:~# efibootmgr -v Boot0005* proxmox [...] File(\EFI\proxmox\grubx64.efi)
Finden Sie im Output einen Eintrag mit systemd-bootx64.efi am Ende, so verwenden Sie UEFI mit systemd-boot:
root@pve-virtual-01:~# efibootmgr -v Boot0005* Linux Boot Manager HD(2,GPT,b345eb37-ad60-4f22-bbdd-24dc2e8bb13d,0x800,0x100000)/File(\EFI\systemd\systemd-bootx64.efi)
Wichtig ist zuerst herauszufinden, welche Festplatte ausgefallen ist im System und welche Bezeichnung diese in Ihrem Proxmox-VE System hat. Dies können Sie z.B. mit dem Kommando lsblk herausfinden.
Nach der Installation sind zwei Boot-Datenträger vorhanden (sda und sdb):
root@pve-virtual-01:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1007K 0 part ├─sda2 8:2 0 512M 0 part └─sda3 8:3 0 99.5G 0 part sdb 8:16 0 100G 0 disk ├─sdb1 8:17 0 1007K 0 part ├─sdb2 8:18 0 512M 0 part └─sdb3 8:19 0 99.5G 0 part
In diesem Test-Szenario ist die Festplatte sda ausgefallen, sie fehlt nach dem Ausfall in der lsblk Ausgabe:
root@pve-virtual-01:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 100G 0 disk ├─sdb1 8:17 0 1007K 0 part ├─sdb2 8:18 0 512M 0 part └─sdb3 8:19 0 99.5G 0 part
WICHTIG: prüfen Sie die genaue Bezeichnung immer dann wenn die kaputte Festplatte bereits mit der neuen Festplatte ausgetauscht wurde! Sollten Sie beispielsweise die defekte Festplatte entfernen, das System nur mit einer Festplatten neu starten und dann zur Laufzeit eine weitere Festplatte hinzufügen, so wird ihr bisheriges sdb zu sda und die neue Festplatte zu sdb. Dies erhöht das Fehlerpotential enorm wenn wir im nächsten Schritt das Partitions-Layout von der gesunden Festplatte auf die neue Festplatte kopieren und ggf. dann die falsche Device-Namen-Angabe machen.
Diese folgenden beiden Schritte sind sowohl für GRUB als auch für systemd-boot relevant und müssen in beiden Fällen durchgeführt werden. Diese Information finden Sie auch immer in der aktuellen Proxmox VE Dokumentation.[1]
# sgdisk <healthy bootable device> -R <new device> # sgdisk -G <new device> # zpool replace -f <pool> <old zfs partition> <new zfs partition>
Die neue Festplatte ist im System und hat noch kein Partitions-Layout - wir benötigen aber die Partitionen damit das System einwandfrei booten kann und wir zwei technisch identische Festplatten für das ZFS bereitstellen können:
root@pve-virtual-01:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk sdb 8:16 0 100G 0 disk ├─sdb1 8:17 0 1007K 0 part ├─sdb2 8:18 0 512M 0 part └─sdb3 8:19 0 99.5G 0 part
Wie oben bereits erwähnt kopieren wir das Partitionslayout der gesunden Festplatte auf die neue Festplatte. Bitte beachten Sie hierbei dass Sie vorher UNBEDINGT die richtige Festplatten-Bezeichnung (Device-Name) mittels lsblk identifizieren müssen. Ansonsten droht ein kaputtes Proxmox-VE System, da ggf. versehentlich das Partitions-Layout der neuen Festplatte auf die alte Festplatte repliziert wird. Dies hätte zur Folge, dass das System dann gar nicht mehr booten kann und Sie ggf. neu installieren müssen.
root@pve-virtual-01:~# sgdisk /dev/sdb -R /dev/sda The operation has completed successfully. root@pve-virtual-01:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1007K 0 part ├─sda2 8:2 0 512M 0 part └─sda3 8:3 0 99.5G 0 part sdb 8:16 0 100G 0 disk ├─sdb1 8:17 0 1007K 0 part ├─sdb2 8:18 0 512M 0 part └─sdb3 8:19 0 99.5G 0 part root@pve-virtual-01:~# sgdisk -G /dev/sda The operation has completed successfully.
Da wir das Layout kopiert haben auf die neue Festplatte haben wir nun auch die selben GUIDs für die Festplatte und die Partitionen, deswegen müssen wir diese noch randomisieren:
root@pve-virtual-01:~# sgdisk -G /dev/sda The operation has completed successfully.
Damit wir die Festplatte korrekt im ZFS austauschen können mit der alten Festplatte, müssen wir die ID der neuen Festplatte herausfinden. In diesem Fall suchen wir nach der Festplatte die mit dem Device-Namen sda verbunden ist.
root@pve:~# ls -l /dev/disk/by-id/* lrwxrwxrwx 1 root root 9 Mar 16 15:11 /dev/disk/by-id/ata-QEMU_DVD-ROM_QM00003 -> ../../sr0 lrwxrwxrwx 1 root root 9 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0 -> ../../sda lrwxrwxrwx 1 root root 10 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1 -> ../../sdb lrwxrwxrwx 1 root root 10 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Mar 16 15:11 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part3 -> ../../sdb3
Proxmox legt bei den Festplatten immer folgende Partitionen an, daran erkennen wir welche Partition welchen Zweck erfüllt:
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 209715166 208664543 99.5G Solaris /usr & Apple ZFS
In diesem Fall benötigen wir die Device-ID (by-id) von der Partition /dev/sda3 diese lautet in diesem Fall:
/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3
Zuerst überprüfen wir den ZFS Pool Status, hier sehen wir dass die ausgefallene Festplatte nicht mehr im System ist und vorher die ID /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 hatte.
root@pve-virtual-01:~# zpool status -v pool: rpool state: DEGRADED status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://zfsonlinux.org/msg/ZFS-8000-4J scan: none requested config: NAME STATE READ WRITE CKSUM rpool DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 15467202543801207082 UNAVAIL 0 0 0 was /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part3 ONLINE 0 0 0
Nun tauschen wir die alte Festplatte mit der neuen Festplatte aus:
# Wichtig in diesem Beispiel hat unsere neue Festplatte die gleiche ID wie die alte Festplatte, das wird in Ihrem Real-Szenario nicht der Fall sein. Bitte halten Sie die Syntax ein: zpool replace -f rpool /dev/disk/by-oid/ID-ALTE-FESTPLATTE /dev/disk/by-id/ID-NEUE-FESTPLATTE root@pve-virtual-01:~# zpool replace -f rpool /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 # Make sure to wait until resilver is done before rebooting.
Somit wurde die Festplatte ausgetauscht. Nun gilt es noch Schritte durchzuführen, je nachdem ob Sie Grub oder systemd-boot verwenden (Identifikation im ersten Schritt Punkt 1.0) Wir können nun jedoch schon einmal überprüfen, ob das RAID-1 (ZFS-Mirror) nun wieder Online und Healthy ist.
root@pve-virtual-01:~# zpool status -v pool: rpool state: ONLINE scan: resilvered 998M in 0 days 00:00:08 with 0 errors on Tue Mar 16 12:16:34 2021 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part3 ONLINE 0 0 0 scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part3 ONLINE 0 0 0
Je nachdem ob Sie Grub oder systemd-boot verwenden, müssen noch ein paar Schritte durchgeführt werden, damit das System rebootfest und funktional ist.
Bei Einsatz von Grub müssen Sie Grub noch auf die neue Festplatte installieren (/dev/sdX):
root@pve-virtual-01:~# grub-install /dev/sda Installing for i386-pc platform. Installation finished. No error reported. root@pve-virtual-01:~# update-initramfs -u update-initramfs: Generating /boot/initrd.img-5.15.35-1-pve Running hook script 'zz-proxmox-boot'.. Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace.. Copying and configuring kernels on /dev/disk/by-uuid/8E4C-89DE Copying kernel and creating boot-entry for 5.15.30-2-pve Copying kernel and creating boot-entry for 5.15.35-1-pve Copying and configuring kernels on /dev/disk/by-uuid/8E4C-C684 Copying kernel and creating boot-entry for 5.15.30-2-pve Copying kernel and creating boot-entry for 5.15.35-1-pve
Danach ist das System reboot fest und nun wieder vollständig redundant und sicher ausgelegt.
Sollten Sie UEFI verwenden, müssen Sie noch folgende Schritte mit dem Tool proxmox-boot-tool durchführen. Zuerst müssen Sie wie im Schritt "Festplatten ID herausfinden (by-id)" die Festplatten-ID herausfinden - dieses mal aber die ID der zweiten Partition, da diese immer für das EFI System verwendet wird. Sobald Sie die ID haben hier in diesem Fall /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part2 können Sie die folgenden Befehle ausführen:
root@pve:~# proxmox-boot-tool format /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part2 UUID="" SIZE="536870912" FSTYPE="" PARTTYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" PKNAME="sdb" MOUNTPOINT="" Formatting '/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part2' as vfat.. mkfs.fat 4.2 (2021-01-31) Done. root@pve:~# proxmox-boot-tool init /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part2 Re-executing '/usr/sbin/proxmox-boot-tool' in new private mount namespace.. UUID="FD52-5CAE" SIZE="536870912" FSTYPE="vfat" PARTTYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" PKNAME="sdb" MOUNTPOINT="" Mounting '/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part2' on '/var/tmp/espmounts/FD52-5CAE'. Installing systemd-boot.. Created "/var/tmp/espmounts/FD52-5CAE/EFI/systemd". Created "/var/tmp/espmounts/FD52-5CAE/EFI/BOOT". Created "/var/tmp/espmounts/FD52-5CAE/loader". Created "/var/tmp/espmounts/FD52-5CAE/loader/entries". Created "/var/tmp/espmounts/FD52-5CAE/EFI/Linux". Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/var/tmp/espmounts/FD52-5CAE/EFI/systemd/systemd-bootx64.efi". Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/var/tmp/espmounts/FD52-5CAE/EFI/BOOT/BOOTX64.EFI". Random seed file /var/tmp/espmounts/FD52-5CAE/loader/random-seed successfully written (512 bytes). Not installing system token, since we are running in a virtualized environment. Created EFI boot entry "Linux Boot Manager". Configuring systemd-boot.. Unmounting '/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part2'. Adding '/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part2' to list of synced ESPs.. Refreshing kernels and initrds.. Running hook script 'proxmox-auto-removal'.. Running hook script 'zz-proxmox-boot'.. Copying and configuring kernels on /dev/disk/by-uuid/5D2E-4BFB Copying kernel and creating boot-entry for 5.15.30-2-pve WARN: /dev/disk/by-uuid/5D2F-103F does not exist - clean '/etc/kernel/proxmox-boot-uuids'! - skipping Copying and configuring kernels on /dev/disk/by-uuid/FD52-5CAE Copying kernel and creating boot-entry for 5.15.30-2-pve root@pve:~# proxmox-boot-tool status Re-executing '/usr/sbin/proxmox-boot-tool' in new private mount namespace.. System currently booted with uefi 5D2E-4BFB is configured with: uefi (versions: 5.15.30-2-pve) WARN: /dev/disk/by-uuid/5D2F-103F does not exist - clean '/etc/kernel/proxmox-boot-uuids'! - skipping FD52-5CAE is configured with: uefi (versions: 5.15.30-2-pve) root@pve:~# proxmox-boot-tool refresh Running hook script 'proxmox-auto-removal'.. Running hook script 'zz-proxmox-boot'.. Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace.. Copying and configuring kernels on /dev/disk/by-uuid/5D2E-4BFB Copying kernel and creating boot-entry for 5.15.30-2-pve WARN: /dev/disk/by-uuid/5D2F-103F does not exist - clean '/etc/kernel/proxmox-boot-uuids'! - skipping Copying and configuring kernels on /dev/disk/by-uuid/FD52-5CAE Copying kernel and creating boot-entry for 5.15.30-2-pve root@pve:~# proxmox-boot-tool clean Checking whether ESP '5D2E-4BFB' exists.. Found! Checking whether ESP '5D2F-103F' exists.. Not found! Checking whether ESP 'FD52-5CAE' exists.. Found! Sorting and removing duplicate ESPs.. root@pve:~# proxmox-boot-tool status Re-executing '/usr/sbin/proxmox-boot-tool' in new private mount namespace.. System currently booted with uefi 5D2E-4BFB is configured with: uefi (versions: 5.15.30-2-pve) FD52-5CAE is configured with: uefi (versions: 5.15.30-2-pve)
Danach ist das System reboot fest und nun wieder vollständig redundant und sicher ausgelegt.
Autor: Jonas Sterr Ich beschäftige mich mit den Themen Software Defined Storage, Proxmox Virtualisierung auf Basis von KVM, QEMU & Ceph im Produktmanagement der Thomas-Krenn.AG in Freyung. Proxmox ist meine absolute Leidenschaft und ich freue mich gerne über Kontaktanfragen und einen Austausch auf LinkedIn.
|