Sollten LVM-Partitionen in Images von virtuellen Maschinen verwendet werden?

Soll LVM für die Partitionen beim Erstellen von VM-Images (z. B. KVM-Images) verwendet werden? Es scheint, als würde dies die Komplexität erhöhen, wenn Sie beispielsweise ein qcow2-Image auf dem Host bereitstellen möchten, wenn das Image LVM-Partitionen enthält.

Auf der anderen Seite scheinen die Vorteile von LVM-Partitionen auf einem VM-Image nicht so bedeutend zu sein, da es viel einfacher ist, eine VM offline zu schalten und ihre Größe zu ändern als auf einem physischen System.

"Es hängt davon ab, ob."

Wenn Sie sich in einer Umgebung befinden, die Sie steuern (vmware oder kvm oder was auch immer), und Ihre eigenen Entscheidungen über die QoS der Festplattenleistung treffen können, empfehle ich, LVM nicht in Ihren VMs zu verwenden. Es gibt Ihnen nicht viel Flexibilität, die Sie auf Hypervisor-Ebene nicht erreichen könnten.

Denken Sie daran, dass der Hypervisor diese Aufgaben bereits effektiv ausführt. Wenn Sie in der Lage sein möchten, die Größe von Dateisystemen willkürlich zu ändern (eine gute Idee), erstellen Sie einfach eine separate virtuelle Festplatte für jedes Dateisystem.

Eine Sache, an die du denken könntest, wenn du diesen Weg einschlägst. Auf diese Weise müssen Sie nicht einmal unbedingt Partitionen auf Ihren virtuellen Laufwerken platzieren. Beispielsweise können Sie ein virtuelles Laufwerk für erstellen /home. es ist /dev/vdcin deinem vm. Tun Sie beim Erstellen des Dateisystems etwas, mke2fs -j /dev/vdcanstatt eine Partition anzugeben.

Dies ist eine gute Idee, aber ... die meisten Tools (und andere Administratoren, die hinter Ihnen her sind) erwarten Partitionen auf jeder Festplatte. Ich würde nur empfehlen, eine einzelne Partition auf der Festplatte zu platzieren und damit fertig zu sein. Es bedeutet jedoch noch einen Schritt mehr, wenn Sie die Größe des Dateisystems ändern. Und vergessen Sie nicht, Ihre Partitionen richtig auszurichten - das Starten der ersten Partition bei 1 MB ist eine gute Faustregel.

Alles, was gesagt wurde - Wenn Sie dies alles auf Hypervisor-Ebene tun, müssen Sie wahrscheinlich die VM neu starten, um die Größe der Partitionen zu ändern. Mit LVM können Sie eine virtuelle Festplatte im laufenden Betrieb hinzufügen (vorausgesetzt, Ihre Hypervisor / Betriebssystem-Kombination ermöglicht dies) und das Dateisystem ohne Neustart erweitern. Das ist definitiv ein Plus.

Wenn Sie einen Cloud-Anbieter verwenden, ist dies subtiler.

Ich weiß nicht viel über Azure, GCP oder einen der kleineren Spieler, deshalb kann ich dort nicht helfen.

Mit AWS können Sie meinen obigen Rat befolgen und es wird Ihnen oft gut gehen. Sie können (jetzt) ​​die Größe von EBS-Volumes (virtuellen Laufwerken) im laufenden Betrieb erhöhen und die Größe von Partitionen usw. ändern.

Im Allgemeinen kann es jedoch sinnvoll sein, alles auf ein einziges großes EBS-Volume zu stellen und LVM (oder, wie ich vermute, einfache Partitionen) zu verwenden. Amazon gibt Ihnen ein IOPS-Limit für jedes Volume. Standardmäßig skaliert diese Grenze mit der Größe des Volumes. Beispielsweise erhalten Sie für gp2Volumes 3 IOPS pro GiB (mindestens 100 IOPS). Siehe https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html

Für die meisten Workloads möchten Sie, dass alle verfügbaren IOPS für jedes Dateisystem verfügbar sind, je nach aktuellem Bedarf. Daher ist es sinnvoll, ein einziges großes EBS-Volume zu erstellen, alle Ihre IOPS in einem Bucket zu speichern und es zu partitionieren / LVM-fähig zu machen.

Beispiel:

3 Festplatten mit unabhängigen Dateisystemen / Auslagerungsbereichen, jeweils 100 GB groß. Jeder bekommt 300 IOPS. Die Leistung ist auf 300 IOPS pro Platte begrenzt.

1 Festplatte, 300 GB groß. LVM-Partitionen auf der Festplatte mit jeweils 100 GB. Die Festplatte erhält 900 IOPS. Jede der Partitionen kann alle 900 IOPS verwenden.

Logische Volumes können schneller erstellt, in der Größe geändert und gelöscht werden.
Die Frage "Zu LVM oder Nicht" hat immer die gleiche Antwort, es kommt darauf an :)
Es ist sinnvoll, wenn Sie die Flexibilität auf der Ebene der Festplatte (n) oder Partition (en) benötigen.
Es ist wenig sinnvoll, wenn Sie die Flexibilität von LVM nicht benötigen oder andere LVM-Funktionen nicht nutzen möchten

Ich benutze LVs eigentlich gerne, weil sie vom virt-server aus nicht leicht zugänglich sind. Daher können diese Dateien nicht einfach durch Zufall zerstört / verschoben werden.

Weitere wichtige Merkmale von LVs:

• Sie können Schnappschüsse machen
• Sie können Festplatten-E / A basierend auf LV ( iostat) analysieren.
• Leicht zu ändern
• Durch die Verwendung von Snapshots können Sie einen konsistenten Klon von laufenden Systemen erstellen

Um die Komplexität zu verringern, verwende ich eine LV als Festplatte (nicht als Partition). Der Nachteil ist, dass ich die Größe der letzten Partition der "Festplatte" nur leicht ändern kann - aber mein Standard-VM-Festplattenlayout berücksichtigt dies (daher enthält die letzte Partition die wichtigen Anwendungsdaten).

Neben der Flexibilität haben LVM-basierte VM-Images möglicherweise weniger Overhead, da auf sie nicht über ein Dateisystem zugegriffen wird. Auf der anderen Seite können Sie Bilder nicht mehr so ​​einfach bewegen, wie Sie es mit einer Datei tun würden. Nicht unmöglich, aber etwas komplizierter

Meine eigene Erfahrung ....

Ich wollte ein logisches Volume (lv) mit lvm2 für ein ext4-Dateisystem verwenden. nicht als festplatte, sondern einfach als nicht partitionierte rohplatte für die fs.

Was ich fand, war, dass der Start der VM auf der initrd-Stufe gestoppt werden würde; Wenn ich den /etc/fstabEintrag auskommentiere, bootet der Computer. Den /etc/fstabEintrag kommentiert zu lassen, war keine Lösung, mit der ich glücklich war zu leben. Also habe ich ein normales Disk-Image (immer noch ein logisches Volume) erstellt, es mit einer Partition partitioniert fdiskund das Dateisystem darauf erstellt. Keine weiteren Probleme.

Die relevanten Halterungen in meinem /etc/fstabverwendeten UUID.

Ich habe überlegt, ob ich eine Datei oder ein Dateisystem verwenden soll, habe mich aber dagegen entschieden.

In meinem Fall verwende ich ein Debian Jessie-basiertes System Devuan

Ich verwende eigentlich nur LVMs für den Backup-Speicher auf Hypervisor-Ebene, Image-Dateien sind für die Vögel. Ich würde auch empfehlen, sie auf der Gastebene zu verwenden. Es ist wahr, dass Sie nicht vom Pooling unterschiedlicher Speicherquellen profitieren oder es einfacher finden, den verfügbaren Speicherplatz insgesamt zu erhöhen (da Sie dies genauso einfach erreichen können, indem Sie die Größe des Hypervisors ändern), aber manchmal weisen Sie einem Dateisystem zu viel zu . Vielleicht möchten Sie einen einfachen Weg, um 1 Gig von / opt zu nehmen und an / var zu übergeben (zum Beispiel). Wenn Sie reguläre Partitionen in der VM selbst ausführen, wird die Größenanpassung dadurch noch schwieriger.

Neben den anderen guten Antworten hier ist der einzige wirklich gute Grund, LVM in einer VM zu verwenden, dass Sie mit einer Testumgebung experimentieren und praktische Erfahrungen mit LVM sammeln möchten.

Sie können verschiedene HOWTOs und Lernprogramme durchgehen, gängige (und nicht so gängige) LVM-Verwaltungsaufgaben ausführen, verschiedene Fehlerszenarien einrichten und lernen, wie Sie damit umgehen.

dh als Selbstlernhilfe.

Bearbeiten: Das unten ist nicht mehr wahr. Die Verwendung der von LVM bereitgestellten Thin Provisioning-Funktion für VM-Festplatten-Images ist wahrscheinlich situationsabhängig.

Führen Sie Entwicklungs-VMs auf einem Laptop aus? dann bist du mit QCow2 wahrscheinlich besser dran.

Verwalten einer VM-Farm, die möglicherweise sehr viel Speicherplatz auf mehreren Festplatten beansprucht? LVM ist wahrscheinlich eine gute Möglichkeit, diesen Speicher zu verwalten.

Ein Grund , warum Sie lvm nicht verwenden, besteht darin, dass Sie mit lvm keinen Overcommit für den Speicher durchführen können. Wenn Sie 10 VMs mit 100 GB Speicher erstellen, benötigen Sie 1000 GB tatsächlichen Datenträger, auch wenn 9 der zehn VMs immer nur 20 GB ihrer Dateisysteme verwenden. Sparse Disk-Images oder Images im qcow2-Format können bedeuten, dass nur der tatsächlich von den Gästen verwendete Speicher zugewiesen werden muss.

Ob dies für Sie tatsächlich nützlich ist, hängt davon ab, was Sie aus Ihrem Speicher benötigen.