Einrichtung: DELL PowerEdge R520, oVirt Node 4.4.1 x86_64
# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 onn_ovirt01 lvm2 a-- 105.26g 20.77g
/dev/sda3 VG_he_nfs lvm2 a-- <100.00g <10.00g
/dev/sda4 VG_data_nfs lvm2 a-- <1.50t <206.00g
# lsblk
...
sdb 8:16 0 1.4T 0 disk
└─sdb1 8:17 0 1.4T 0 part /exports/nfs/backups
Problem: Beim Neustart des Systems wird das per SATA-zu-USB angeschlossene 1,4-TB-Backup-Laufwerk zu SDA, wobei LVM die erforderlichen Partitionen für die physischen Volumes nicht findet. Das System bootet dann in den Rettungsmodus, wo ich mich über den angeschlossenen Monitor/die angeschlossene Tastatur anmelden, das SATA-zu-USB-Laufwerk aushängen und auswerfen, seinen Eintrag aus der fstab kommentieren, es ausstecken und das System neu starten muss. Sobald es dann ordnungsgemäß mit dem richtigen Gerät als SDA gebootet ist, muss ich alles rückgängig machen, was ich im Rettungsmodus mit dem SATA-zu-USB-Gerät gemacht habe.
In der fstab ist bereits alles für die Einbindung per UUID oder /dev/mapper/ definiert.
Die Frage: Ist es möglich, die LVM-Konfiguration so zu ändern, dass sie das richtige physische Volume für das System erhält, unabhängig davon, welches Gerät zum SDA wird? Ist dies ohne Neuerstellung und Migration möglich (ich habe die Systemdaten auf einem RAID 1 (Spiegelung) mit Hot-Spare, also ist im Gehäuse kein Platz mehr für eine Ersatzlaufwerkanordnung)? Ich bin für jede Lösung offen, bei der keine Daten gelöscht oder eine neue RAID-Anordnung zum Ersetzen erstellt werden muss. Wenn das nicht möglich ist, bin ich wirklich für alles offen – oder werde einfach jedes Mal, wenn es unerwartet neu startet, damit fortfahren, es im Rettungsmodus zu sortieren.
Antwort1
LVM speichert keine Gerätepfade. Komponenten-UUIDs werden in den LVM-Superblöcken gespeichert und diese UUIDs werden ausschließlich zur Identifizierung von Komponenten (PVs, VGs, LVs) verwendet. LVM scannt einfach alle verfügbaren Blockgeräte (welche gescannt werden dürfen, wird in /etc/lvm/lvm.conf konfiguriert), erkennt physische Volumes und stellt daraus Volumegruppen zusammen. Es schaut einfach nicht, welchen Typ/Gerätepfad das physische Volume dieses Mal hat. Es ist sehr robust gegenüber Geräteneuindizierung usw. Es wird also Ihre Daten finden, wenn Sie Ihre Volumes nach /dev/cciss/cXdYpZ (der alte HP/Compaq SmartArray-Blocktreiber erstellt solche Geräte) oder nach /dev/hdXY oder /dev/sdXY oder /dev/mapper/... (alles, was auf DM aufbaut, platziert Geräteknoten dort – Krypto, Multipath usw.), /dev/md/... (Linux MD RAID) usw. verschieben. Ihre Besorgnis ist unbegründet und Ihr Problem liegt woanders.
Die Ursache Ihres Problems könnte die Langsamkeit von USB sein. Es hat große Latenzen; außerdem werden externe Festplatten sehr langsam gestartet (dies geschieht, um ihren Stromverbrauchsspitzen beim Hochfahren zu begrenzen). Bei USB geht es nicht um Leistung, sondern um Robustheit in den Händen unerfahrener Benutzer. Daher ist die Initialisierung langsam. Sie müssen Ihre Init-Skripte (wahrscheinlich das Init-Skript initramfs) so konfigurieren, dass große Verzögerungen/Timeouts möglich sind, damit USB-Geräte genügend Zeit haben, hochzufahren und sich zu beruhigen.
Eine weitere typische Ursache ist die schlechte Konfiguration des Bootloaders. Beispielsweise könnte er erwarten, seine Daten auf der „ersten Partition der ersten Festplatte“ zu finden. Wenn die „erste Festplatte“ jedoch das falsche Gerät ist, verfügt er nicht über die Konfiguration und das Kernel-Image zum Booten und wirft Sie in dieBootloaderRettungsshell. Die Befehlszeile des Kernels oder etwas, das in das Initramfs eingegeben wird, kann an einen konkreten Gerätepfad gebunden sein, und daher führt das Auswechseln von Geräten dazu, dass es / nicht finden kann und Sie ininitramfsRettungsschale. Beachten Sie, dass dieseandersRettungsgranaten und das Verständnis vonwelchersehen Sie, das ist wichtig.
RAID0 mit Spare ist ein Widerspruch in sich. RAID0 hat keine Redundanz, keinen definierten degradierten Zustand, nichts, um das Array nach einem Geräteausfall in den optimalen Zustand zu versetzen, also könnten Spare unmöglich helfen. Jedes Problem mit einem Komponentengerät führt im Allgemeinen dazu, dass ein ganzes Array direkt in den ausgefallenen Zustand versetzt wird. Jede andere RAID-Ebene hat eine Redundanz, sie wechselt im Falle eines Komponentenausfalls zuerst in den degradierten Zustand und profitiert daher von Spare, aber RAID0 hat keine.
Antwort2
Ich habe das Problem gelöst. Ich musste lediglich SDB-Partitionen zum Filter hinzufügen in /etc/lvm/lvm.conf
:
War:
filter = ["a|^/dev/sda2$|", "a|^/dev/sda3$|", "a|^/dev/sda4$|", "r|.*|"]
Gewechselt zu:
filter = ["a|^/dev/sda2$|", "a|^/dev/sda3$|", "a|^/dev/sda4$|", "a|^/dev/sdb2$|", "a|^/dev/sdb3$|", "a|^/dev/sdb4$|", "r|.*|"]
Jeder andere, der dies versucht, sollte seine Änderungen überprüfen und den Cache mitvgscan
mein erster Versuch (habe das |
nach dem vergessen $
):
[root@host lvm]# vgscan
Invalid separator at end of regex.
Invalid filter pattern "a|^/dev/sdb2$".
Failed to create regex device filter
mein zweiter Versuch:
[root@host lvm]# vgscan
Found volume group "VG_data_nfs" using metadata type lvm2
Found volume group "VG_he_nfs" using metadata type lvm2
Found volume group "onn_ovirt01" using metadata type lvm2
Das SATA-zu-USB-Laufwerk wird immer noch als SDA angezeigt, aber das ist egal – LVM springt zu SDB-Partitionen, wenn auf SDA nichts gefunden wird. Ich musste das SATA-zu-USB-Laufwerk zwar manuell mounten, aber da es /etc/fstab
richtig drin ist, musste ich nur Folgendes eingeben mount -a
. Ich muss dieses Problem später lösen und diesen Sieg vorerst als gegeben hinnehmen.