%20verschiedene%20Arten%20von%20PVs%20(Physical%20Volumes)%20enthalten%3F.png)
Der Hintergrund ist, dass wir unser Datenbankdatenverzeichnis auf einem LV haben, das sich auf einer VG befindet. Wir möchten die Snapshot-Funktion des LVM verwenden, um unsere Datenbankdaten zu sichern, aber diese VG hat keine freien PEs mehr. Wir konnten das LV auch nicht verkleinern (wir verwenden XFS). Die VG hat zwei PVs, wobei jedes PV ein RAID 10 ist (jedes mit 8 Festplatten). Wir haben zwei zusätzliche Ersatzfestplatten (für Hot Failover ist die Größe dieselbe, aus der die RAID10-PVs bestehen).
Ich überlege, eines der Ersatzlaufwerke zu nehmen, darauf ein PV zu erstellen und es der VG hinzuzufügen, die das Datenbankdatenverzeichnis hostet. Funktioniert das? Könnte eine VG verschiedene PV-Typen enthalten, z. B. 2 RAID 10 PVs und 1 Festplatte ohne RAID?
Antwort1
Jeder Geräteknoten, der ein Blockgerät ist, kann zu einem PV gemacht und als Mitglied einer VG hinzugefügt werden. Beispielsweise habe ich in einem meiner Computer eine Festplatte und eine Solid-State-Disk, die Mitglieder eines einzigen PV sind und als Cache fungieren (https://man7.org/linux/man-pages/man7/lvmcache.7.html).
Beim Erstellen des Snapshot-LV möchten Sie möglicherweise die RAID10-PVs zum Hosten der Live-Datenbankdaten und die Ersatzfestplatte zum Speichern des Copy-on-Write-Snapshots (COW) verwenden. Ich schlage dies vor, da bei einem Ausfall der Ersatzfestplatte das laufende Backup und nicht die Live-Datenbank verloren gehen würde. Das genaue PV, das ein LV hostet, kann in der Befehlszeile angegeben werden, die den Snapshot erstellt, wie unten beispielhaft dargestellt.
# lvcreate -L 10G -n backup_snap_lv -s data_vg/data_lv /dev/sdb
# lvdisplay --maps data_vg/backup_snap_lv
Antwort2
Es sollte kein Problem geben, denn das ist die Idee von LVM. Auf der untersten Ebene haben Sie physische Speichergeräte. Auf ihnen werden PV erstellt. Wenn Sie dann PV(s) zu VG hinzufügen, ist es VG egal, was darunter ist. Wenn Sie dann Speicherplatz zu LV hinzufügen/LV erstellen, ist es LV egal, woher VG diesen Speicherplatz hat.
Natürlich gibt es Sonderfälle, bei denen Sie beim Erstellen eines Spiegels (zwei Kopien des LV) diese auf unterschiedlichen PVs speichern können (für den sehr strengen Modus benötigen Sie auch ein drittes PV).
Antwort3
LVM kümmert sich (meistens) nicht um die Besonderheiten der Blockgeräte, auf denen sich die PVs einer VG befinden. Die einzige wichtige Ausnahme besteht darin, dass es möglicherweise versucht, Verwerfungsvorgänge an zugrunde liegende Blockgeräte weiterzugeben, wenn diese angeben, dass sie solche Vorgänge unterstützen.
Auf meinem Home-Server-System habe ich beispielsweise vier 4-TB-SATA-Festplatten und zwei 1-TB-NVMe-SSDs, alle als PVs für die einzige VG auf dem System eingerichtet. Das habe ich getan, weil es die Datenmigration erleichtert, wenn ich eine Festplatte austauschen muss (es wird zu einem einfachen pvmoveBefehl, anstatt dass ich etwas wie das Zusammenführen von VGs tun muss).
Jedoch, es gibt jedoch einen großen Vorbehalt. Da LVM sich nicht um die zugrunde liegenden Blockgeräte kümmert, ist es nicht intelligent genug, um „intelligent“ neue LVs zu platzieren (oder in einigen Fällen vorhandene zu erweitern), es sei denn, Sie möchten nur die Fragmentierung des freien Speicherplatzes minimieren. Daher sollten SiestetsGeben Sie beim Erstellen neuer LVs in einem solchen Setup explizit an, welche PVs verwendet werden sollen, damit Sie genau das erwartete Verhalten erhalten.
Abgesehen davon, vorausgesetzt, diese Ersatzlaufwerke sindWAHRHotspares (das heißt, das System verwendet sie automatisch als Ersatz, falls im Rest des Arrays ein Laufwerk ausfällt), würde ich nicht empfehlen, eines davon umzufunktionieren, es sei denn, Sie brauchen dringend mehr Platz und die Möglichkeit eines doppelten Laufwerksausfalls ist Ihnen wirklich egal (was bei so vielen Laufwerken in jedem Array eigentlich relativ wahrscheinlich ist). Wenn Sie auf andere Weise Platz freigeben können, sollte das wahrscheinlich Ihr erster Ansatz sein, um mehr Platz zum Arbeiten zu bekommen.