LVM Gefahren und Vorbehalte

Lösung 1:

Zusammenfassung

Risiken bei der Verwendung von LVM:

• Anfällig für Schreib-Caching-Probleme mit SSD- oder VM-Hypervisor
• Schwierigere Wiederherstellung von Daten aufgrund komplexerer Festplattenstrukturen
• Schwieriger, Dateisysteme korrekt zu skalieren
• Snapshots sind schwer zu verwenden, langsam und fehlerhaft
• Erfordert einige Fähigkeiten zur korrekten Konfiguration angesichts dieser Probleme

Die ersten beiden LVM-Probleme kombinieren sich:Wenn das Schreib-Caching nicht richtig funktioniert und Sie einen Stromausfall haben (z. B. ein Netzteil oder eine USV fällt aus), müssen Sie möglicherweise eine Wiederherstellung vom Backup durchführen, was zu erheblichen Ausfallzeiten führt. Ein Hauptgrund für die Verwendung von LVM ist eine höhere Betriebszeit (beim Hinzufügen von Festplatten, Ändern der Größe von Dateisystemen usw.), aber es ist wichtig, dass das Schreib-Caching-Setup korrekt ist, um zu vermeiden, dass LVM die Betriebszeit tatsächlich verringert.

-- Aktualisiert im Dezember 2019:kleineres Update zu btrfs und ZFS als Alternativen zu LVM-Snapshots

Minderung der Risiken

LVM kann immer noch gut funktionieren, wenn Sie:

• Machen Sie Ihr Schreib-Caching-Setup in Hypervisor, Kernel und SSDs richtig
• Vermeiden Sie LVM-Snapshots
• Verwenden Sie aktuelle LVM-Versionen, um die Größe von Dateisystemen zu ändern
• Haben Sie gute Backups

Einzelheiten

Ich habe dies in der Vergangenheit ziemlich viel recherchiert, nachdem ich einige Datenverluste im Zusammenhang mit LVM erlebt hatte. Die wichtigsten LVM-Risiken und -Probleme, die mir bekannt sind, sind:

Anfällig für Festplatten-Schreib-Caching aufgrund von VM-Hypervisoren, Festplatten-Caching oder alten Linux-Kerneln , und erschwert die Wiederherstellung von Daten aufgrund komplexerer Festplattenstrukturen - siehe unten für Details. Ich habe gesehen, wie komplette LVM-Setups auf mehreren Festplatten ohne Chance auf Wiederherstellung beschädigt wurden, und LVM plus Festplatten-Schreib-Caching ist eine gefährliche Kombination.

• Schreib-Caching und Schreib-Neuordnung durch die Festplatte ist wichtig für eine gute Leistung, kann aber aufgrund von VM-Hypervisoren, Festplatten-Schreib-Caching, alten Linux-Kerneln usw. beim korrekten Flushen von Blöcken auf die Festplatte fehlschlagen.
• Schreibbarrieren bedeuten, dass der Kernel garantiert, dass er bestimmte Festplattenschreibvorgänge vor dem „Barrier“-Festplattenschreiben abschließt, um sicherzustellen, dass Dateisysteme und RAID im Falle eines plötzlichen Stromausfalls oder Absturzes wiederhergestellt werden können. Solche Barrieren können eine FUA-Operation (Force Unit Access) verwenden, um bestimmte Blöcke sofort auf die Festplatte zu schreiben, was effizienter ist als ein vollständiger Cache-Flush. Barrieren können mit effizientem getaggtem/nativem Befehls-Queuing (gleichzeitiges Ausgeben mehrerer Festplatten-I/O-Anforderungen) kombiniert werden, damit die Festplatte eine intelligente Neuordnung der Schreibvorgänge durchführen kann, ohne das Risiko eines Datenverlusts zu erhöhen.
• VM-Hypervisoren kann ähnliche Probleme haben:Das Ausführen von LVM in einem Linux-Gast auf einem VM-Hypervisor wie VMware, Xen, KVM, Hyper-V oder VirtualBox kann aufgrund von Schreib-Caching und Neuordnung von Schreibvorgängen ähnliche Probleme wie ein Kernel ohne Schreibbarrieren verursachen . Überprüfen Sie Ihre Hypervisor-Dokumentation sorgfältig auf eine „Flush to Disk“- oder Write-Through-Cache-Option (in KVM, VMware, Xen, VirtualBox und anderen vorhanden) – und testen Sie sie mit Ihrem Setup. Einige Hypervisoren wie VirtualBox haben eine Standardeinstellung, die alle Festplatten-Flushes vom Gast ignoriert.
• Unternehmensserver mit LVM sollten immer einen batteriegestützten RAID-Controller verwenden und deaktivieren Sie das Festplatten-Schreibcache (der Controller verfügt über einen batteriegestützten Schreibcache, der schnell und sicher ist) - siehe diesen Kommentar des Autors dieses XFS-FAQ-Eintrags. Es kann auch sicher sein, Schreibbarrieren im Kernel auszuschalten, aber das Testen wird empfohlen.
• Wenn Sie keinen batteriegestützten RAID-Controller haben, verlangsamt das Deaktivieren des Festplatten-Schreib-Cachings die Schreibvorgänge erheblich, macht LVM jedoch sicher. Sie sollten auch das Äquivalent von data=ordered von ext3 verwenden Option (oder data=journal für zusätzliche Sicherheit), plus barrier=1 um sicherzustellen, dass das Kernel-Caching die Integrität nicht beeinträchtigt. (Oder verwenden Sie ext4, das Barrieren standardmäßig aktiviert.) Dies ist die einfachste Option und bietet eine gute Datenintegrität auf Kosten der Leistung. (Linux hat die standardmäßige ext3-Option in die gefährlichere data=writeback geändert eine Weile zurück, verlassen Sie sich also nicht auf die Standardeinstellungen für den FS.)
• Zum Deaktivieren des Schreibcaches der Festplatte :Fügen Sie hdparm -q -W0 /dev/sdX hinzu für alle Laufwerke in /etc/rc.local (für SATA) oder verwenden Sie sdparm für SCSI/SAS. Laut diesem Eintrag in der XFS-FAQ (der zu diesem Thema sehr gut ist) kann ein SATA-Laufwerk diese Einstellung jedoch nach einer Laufwerkfehlerwiederherstellung vergessen - Sie sollten also SCSI/SAS verwenden, oder wenn Sie SATA verwenden müssen, dann setzen Sie das hdparm-Befehl in einem Cron-Job, der etwa jede Minute ausgeführt wird.
• Um das SSD-/Festplatten-Schreib-Caching aktiviert zu lassen für eine bessere Leistung:Dies ist ein komplexer Bereich - siehe Abschnitt unten.
• Wenn Sie Laufwerke mit Advanced Format verwenden d.h. 4 KB physische Sektoren, siehe unten - das Deaktivieren des Schreib-Caching kann andere Probleme haben.
• UPS ist sowohl für Unternehmen als auch für SOHO von entscheidender Bedeutung, aber nicht genug, um LVM sicher zu machen:Alles, was einen harten Absturz oder einen Stromausfall verursacht (z
• Sehr alte Linux-Kernel (2.6.x von 2009) :In sehr alten Kernel-Versionen, 2.6.32 und früher, gibt es unvollständige Unterstützung für Schreibbarrieren (2.6.31 hat etwas Unterstützung, während 2.6.33 für alle Arten von Gerätezielen funktioniert) – RHEL 6 verwendet 2.6.32 mit vielen Patches. Wenn diese alten 2.6-Kernel für diese Probleme nicht gepatcht werden, könnte eine große Menge von FS-Metadaten (einschließlich Journalen) durch einen harten Absturz verloren gehen, der Daten in den Schreibpuffern der Festplatten hinterlässt (z. B. 32 MB pro Laufwerk für herkömmliche SATA-Laufwerke). Der Verlust von 32 MB der zuletzt geschriebenen FS-Metadaten und Journaldaten, von denen der Kernel annimmt, dass sie sich bereits auf der Festplatte befinden, bedeutet normalerweise eine Menge FS-Beschädigung und damit Datenverlust.
• Zusammenfassung: Sie müssen bei der Einrichtung von Dateisystem, RAID, VM-Hypervisor und Festplatte/SSD, die mit LVM verwendet werden, sorgfältig vorgehen. Sie müssen über sehr gute Sicherungen verfügen, wenn Sie LVM verwenden, und stellen Sie sicher, dass Sie speziell die LVM-Metadaten, die Einrichtung der physischen Partition, den MBR und die Bootsektoren des Volumes sichern. Es ist auch ratsam, SCSI/SAS-Laufwerke zu verwenden, da diese weniger wahrscheinlich darüber lügen, wie sie das Schreib-Caching durchführen – bei der Verwendung von SATA-Laufwerken ist mehr Sorgfalt erforderlich.

Schreibcache aktiviert lassen für Leistung (und Umgang mit Lügenfahrten)

Eine komplexere, aber leistungsfähigere Option besteht darin, das SSD-/Festplatten-Schreib-Caching aktiviert zu lassen und sich auf Kernel-Schreibbarrieren zu verlassen, die mit LVM auf Kernel 2.6.33+ funktionieren (überprüfen Sie dies, indem Sie in den Protokollen nach „Barrier“-Meldungen suchen).

Sie sollten auch sicherstellen, dass das RAID-Setup, das VM-Hypervisor-Setup und das Dateisystem Schreibbarrieren verwenden (d. h., dass das Laufwerk ausstehende Schreibvorgänge vor und nach dem Schreiben von Schlüsselmetadaten/Journal schreiben muss). XFS verwendet standardmäßig Barrieren, aber ext3 nicht, also sollten Sie mit ext3 barrier=1 verwenden in den Mount-Optionen und verwenden Sie weiterhin data=ordered oder data=journal wie oben.

• Leider lügen manche Festplatten und SSDs darüber, ob sie wirklich ihren Cache geleert haben auf die Festplatte (insbesondere ältere Laufwerke, aber auch einige SATA-Laufwerke und einige Enterprise-SSDs) - weitere Details hier. Es gibt eine großartige Zusammenfassung von einem XFS-Entwickler.
• Es gibt ein einfaches Testtool für liegende Laufwerke (Perl-Skript), oder sehen Sie sich diesen Hintergrund mit einem anderen Tool an, das die Neuordnung von Schreibvorgängen als Ergebnis des Laufwerkcaches testet. Diese Antwort bezog sich auf ähnliche Tests von SATA-Laufwerken, bei denen ein Schreibbarrierenproblem in Software-RAID aufgedeckt wurde – diese Tests testen tatsächlich den gesamten Speicherstapel.
• Neuere SATA-Laufwerke, die Native Command Queuing (NCQ) unterstützen, lügen möglicherweise weniger - oder sie funktionieren aufgrund von NCQ ohne Schreibcache gut, und nur sehr wenige Laufwerke können das Schreibcache nicht deaktivieren.
• SCSI/SAS-Laufwerke sind im Allgemeinen in Ordnung, da sie kein Schreib-Caching benötigen, um eine gute Leistung zu erzielen (über SCSI Tagged Command Queuing, ähnlich wie NCQ von SATA).
• Wenn Ihre Festplatten oder SSDs ihren Cache auf die Festplatte leeren, können Sie sich wirklich nicht auf Schreibbarrieren verlassen und müssen das Schreib-Caching deaktivieren. Dies ist ein Problem für alle Dateisysteme, Datenbanken, Volume-Manager und Software-RAID, nicht nur für LVM.

SSDs sind problematisch, da die Verwendung des Schreibcaches für die Lebensdauer der SSD entscheidend ist. Es ist am besten, eine SSD mit Superkondensator zu verwenden (um das Leeren des Caches bei Stromausfall zu ermöglichen und damit das Zurückschreiben und nicht das Durchschreiben des Caches zu ermöglichen).

• Die meisten Enterprise-SSDs sollten für die Schreib-Cache-Steuerung in Ordnung sein, und einige enthalten Superkondensatoren.
• Einige billigere SSDs haben Probleme, die nicht mit der Write-Cache-Konfiguration behoben werden können – die Mailingliste des PostgreSQL-Projekts und die Wiki-Seite Reliable Writes sind gute Informationsquellen. Verbraucher-SSDs können große Schreib-Caching-Probleme haben, die zu Datenverlust führen, und enthalten keine Superkondensatoren, sodass sie anfällig für Stromausfälle sind, die zu Beschädigungen führen.

Erweitertes Format Laufwerk-Setup - Schreib-Caching, Alignment, RAID, GPT

• Bei neueren Advanced Format-Laufwerken, die physische Sektoren von 4 KiB verwenden, kann es wichtig sein, das Laufwerk-Schreib-Caching aktiviert zu lassen, da die meisten dieser Laufwerke derzeit 512-Byte-logische Sektoren ("512-Emulation") emulieren und einige sogar behaupten, 512 zu haben -Byte physische Sektoren, während sie wirklich 4 KiB verwenden.
• Das Deaktivieren des Schreib-Cache eines Advanced Format-Laufwerks kann eine sehr große Auswirkung auf die Leistung haben, wenn die Anwendung/der Kernel 512-Byte-Schreibvorgänge durchführt, da solche Laufwerke darauf angewiesen sind, dass der Cache 8 x 512-Byte-Schreibvorgänge ansammelt, bevor sie einen einzigen ausführen 4 KiB physisches Schreiben. Es wird empfohlen, dies zu testen, um etwaige Auswirkungen zu bestätigen, wenn Sie den Cache deaktivieren.
• Das Ausrichten der LVs an einer 4-KiB-Grenze ist wichtig für die Leistung, sollte aber automatisch erfolgen, solange die zugrunde liegenden Partitionen für die PVs ausgerichtet sind, da LVM Physical Extents (PEs) standardmäßig 4 MiB groß sind. RAID muss hier berücksichtigt werden - diese LVM- und Software-RAID-Setup-Seite schlägt vor, den RAID-Superblock am Ende des Volumes zu platzieren und (falls erforderlich) eine Option auf pvcreate zu verwenden um die PVs auszurichten. Dieser LVM-E-Mail-Listen-Thread weist auf die Arbeit hin, die 2011 in Kerneln geleistet wurde, und auf das Problem von partiellen Blockschreibvorgängen, wenn Festplatten mit 512 Byte und 4 KiB-Sektoren in einem einzigen LV gemischt werden.
• Die GPT-Partitionierung mit Advanced Format erfordert Sorgfalt, insbesondere bei Boot+Root-Festplatten, um sicherzustellen, dass die erste LVM-Partition (PV) an einer 4-KiB-Grenze beginnt.

Schwierigere Datenwiederherstellung aufgrund komplexerer Festplattenstrukturen :

• Jede Wiederherstellung von LVM-Daten, die nach einem harten Absturz oder Stromausfall (aufgrund eines fehlerhaften Schreib-Cachings) erforderlich ist, ist bestenfalls ein manueller Prozess, da es anscheinend keine geeigneten Tools gibt. LVM ist gut darin, seine Metadaten unter /etc/lvm zu sichern , das dabei helfen kann, die Grundstruktur von LVs, VGs und PVs wiederherzustellen, hilft aber nicht bei verlorenen Dateisystem-Metadaten.
• Daher ist wahrscheinlich eine vollständige Wiederherstellung aus der Sicherung erforderlich. Dies bedeutet viel mehr Ausfallzeit als ein schnelles, journalbasiertes fsck, wenn LVM nicht verwendet wird, und Daten, die seit der letzten Sicherung geschrieben wurden, gehen verloren.
• TestDisk, ext3grep, ext3undel und andere Tools können Partitionen und Dateien von Nicht-LVM-Festplatten wiederherstellen, aber sie unterstützen die LVM-Datenwiederherstellung nicht direkt. TestDisk kann feststellen, dass eine verlorene physische Partition ein LVM-PV enthält, aber keines dieser Tools versteht logische LVM-Volumes. File-Carving-Tools wie PhotoRec und viele andere würden funktionieren, da sie das Dateisystem umgehen, um Dateien aus Datenblöcken wieder zusammenzusetzen, aber dies ist ein letzter Ausweg, Low-Level-Ansatz für wertvolle Daten und funktioniert weniger gut mit fragmentierten Dateien.
• Eine manuelle LVM-Wiederherstellung ist in einigen Fällen möglich, aber komplex und zeitaufwändig - sehen Sie sich dieses Beispiel und dies, dies und das an, um zu erfahren, wie man eine Wiederherstellung durchführt.

Schwieriger, die Größe von Dateisystemen richtig zu ändern - Die einfache Größenänderung des Dateisystems wird oft als Vorteil von LVM angegeben, aber Sie müssen ein halbes Dutzend Shell-Befehle ausführen, um die Größe eines LVM-basierten FS zu ändern. Letzteres würde ich jedoch niemals riskieren, ohne aktuelle Sicherungen und Befehle zu verwenden, die auf einem gleichwertigen Server vorab getestet wurden (z. B. Disaster-Recovery-Klon eines Produktionsservers).

• Aktualisierung: Neuere Versionen von lvextend unterstützen den -r (--resizefs )-Option - wenn diese verfügbar ist, ist dies ein sicherer und schneller Weg, um die Größe des LV und des Dateisystems zu ändern, insbesondere wenn Sie den FS verkleinern, und Sie können diesen Abschnitt meistens überspringen.

• Die meisten Anleitungen zur Größenänderung von LVM-basierten FSs berücksichtigen nicht die Tatsache, dass der FS etwas kleiner sein muss als die Größe des LV:ausführliche Erklärung hier. Beim Verkleinern eines Dateisystems müssen Sie die neue Größe dem FS-Resize-Tool angeben, z. resize2fs für ext3 und auf lvextend oder lvreduce . Ohne große Sorgfalt können die Größen aufgrund des Unterschieds zwischen 1 GB (10^9) und 1 GiB (2^30) oder der Art und Weise, wie die verschiedenen Tools Größen auf- oder abrunden, leicht abweichen.

• Wenn Sie die Berechnungen nicht genau richtig durchführen (oder einige zusätzliche Schritte über die offensichtlichsten hinaus verwenden), erhalten Sie möglicherweise einen FS, der zu groß für den LV ist. Alles scheint monate- oder jahrelang in Ordnung zu sein, bis Sie den FS vollständig gefüllt haben. An diesem Punkt treten schwerwiegende Beschädigungen auf - und wenn Sie sich dieses Problems nicht bewusst sind, ist es schwer herauszufinden, warum, da Sie bis dahin möglicherweise auch echte Festplattenfehler haben die die Situation trüben. (Es ist möglich, dass dieses Problem nur die Reduzierung der Größe von Dateisystemen betrifft - es ist jedoch klar, dass die Größenänderung von Dateisystemen in beide Richtungen das Risiko von Datenverlust erhöht, möglicherweise aufgrund von Benutzerfehlern.)

• Es scheint, dass die LV-Größe um das 2-fache der physischen LVM-Größe (PE) größer sein sollte als die FS-Größe - aber überprüfen Sie den obigen Link auf Details, da die Quelle dafür nicht maßgebend ist. Oft reicht es aus, 8 MiB zuzulassen, aber es kann besser sein, mehr zuzulassen, z. 100 MiB oder 1 GiB, nur um sicherzugehen. So überprüfen Sie die PE-Größe und die Größe Ihres logischen Volumes + FS mit 4 KiB =4096-Byte-Blöcken:

  Zeigt die PE-Größe in KiB an:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Größe aller LVs:
  lvs --units 4096b
  
  Größe von (ext3) FS, setzt 4 KiB FS-Blockgröße voraus:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Im Gegensatz dazu macht ein Nicht-LVM-Setup die Größenänderung des FS sehr zuverlässig und einfach - führen Sie Gparted aus und ändern Sie die Größe der erforderlichen FSs, dann erledigt es alles für Sie. Auf Servern können Sie parted verwenden aus der Shell.

• Es ist oft am besten, die Gparted Live-CD oder Parted Magic zu verwenden, da diese eine neuere und oft fehlerfreiere Gparted- und Kernel-Version haben als die Distributionsversion - ich habe einmal einen ganzen FS verloren, weil Gparted der Distribution Partitionen im Lauf nicht richtig aktualisiert hat Kernel. Wenn Sie das Gparted der Distribution verwenden, müssen Sie direkt nach dem Ändern der Partitionen neu starten, damit die Ansicht des Kernels korrekt ist.

Schnappschüsse sind schwer zu verwenden, langsam und fehlerhaft - Wenn der Snapshot keinen vorab zugewiesenen Speicherplatz mehr hat, wird er automatisch gelöscht. Jeder Snapshot eines bestimmten LV ist ein Delta gegenüber diesem LV (nicht gegenüber vorherigen Snapshots), was viel Speicherplatz erfordern kann, wenn Snapshots von Dateisystemen mit erheblicher Schreibaktivität erstellt werden (jeder Snapshot ist größer als der vorherige). Es ist sicher, ein Snapshot-LV zu erstellen, das die gleiche Größe wie das ursprüngliche LV hat, da dem Snapshot dann nie der freie Speicherplatz ausgeht.

Snapshots können auch sehr langsam sein (d. h. 3- bis 6-mal langsamer als ohne LVM für diese MySQL-Tests) – siehe diese Antwort zu verschiedenen Snapshot-Problemen. Die Langsamkeit liegt teilweise daran, dass Snapshots viele synchrone Schreibvorgänge erfordern.

Snapshots hatten einige signifikante Fehler, z.B. in einigen Fällen können sie das Booten sehr verlangsamen oder dazu führen, dass das Booten vollständig fehlschlägt (weil der Kernel beim Warten auf das Root-FS, wenn es sich um einen LVM-Snapshot handelt [behoben in Debian initramfs-tools Aktualisierung, März 2015]).

• Viele Snapshot-Race-Condition-Bugs wurden jedoch offenbar bis 2015 behoben.
• LVM ohne Snapshots scheint im Allgemeinen ziemlich gut debuggt zu sein, vielleicht weil Snapshots nicht so oft verwendet werden wie die Kernfunktionen.

Snapshot-Alternativen - Dateisysteme und VM-Hypervisoren

VM-/Cloud-Snapshots:

• Wenn Sie einen VM-Hypervisor oder einen IaaS-Cloud-Anbieter (z. B. VMware, VirtualBox oder Amazon EC2/EBS) verwenden, sind deren Snapshots oft eine viel bessere Alternative zu LVM-Snapshots. Sie können ganz einfach einen Snapshot für Sicherungszwecke erstellen (aber ziehen Sie in Betracht, den FS einzufrieren, bevor Sie dies tun).

Dateisystem-Snapshots:

• Snapshots auf Dateisystemebene mit ZFS oder Btrfs sind einfach zu verwenden und im Allgemeinen besser als LVM, wenn Sie Bare Metal verwenden (aber ZFS scheint viel ausgereifter zu sein, nur umständlicher zu installieren):

• ZFS:Es gibt jetzt eine Kernel-ZFS-Implementierung, die seit einigen Jahren verwendet wird, und ZFS scheint sich immer mehr durchzusetzen. Ubuntu hat jetzt ZFS als „out of the box“-Option, einschließlich experimentellem ZFS auf Root in 19.10.

• btrfs:immer noch nicht bereit für den produktiven Einsatz (sogar auf openSUSE, das es standardmäßig ausliefert und ein Team für btrfs hat), während RHEL die Unterstützung eingestellt hat). btrfs hat jetzt ein fsck-Tool (FAQ), aber die FAQ empfiehlt Ihnen, einen Entwickler zu konsultieren, wenn Sie ein defektes Dateisystem fsck müssen.

Schnappschüsse für Online-Backups und fsck

Snapshots können verwendet werden, um eine konsistente Quelle bereitzustellen für Backups, solange Sie mit dem zugewiesenen Speicherplatz vorsichtig sind (idealerweise hat der Snapshot die gleiche Größe wie das zu sichernde LV). Der ausgezeichnete rsnapshot (seit 1.3.1) verwaltet sogar das Erstellen/Löschen von LVM-Snapshots für Sie – sehen Sie sich dieses HOWTO zu rsnapshot mit LVM an. Beachten Sie jedoch die allgemeinen Probleme mit Snapshots und dass ein Snapshot an sich nicht als Backup betrachtet werden sollte.

Sie können auch LVM-Snapshots verwenden, um einen Online-fsck zu erstellen:Erstellen Sie einen Snapshot des LV und fsck den Snapshot, während Sie immer noch das Haupt-FS ohne Snapshot verwenden - hier beschrieben -, aber es ist nicht ganz einfach, daher ist es am besten, e2croncheck wie von Ted Ts beschrieben zu verwenden 'o, Betreuer von ext3.

Sie sollten das Dateisystem vorübergehend "einfrieren", während Sie den Snapshot erstellen - einige Dateisysteme wie ext3 und XFS werden dies automatisch tun, wenn LVM den Snapshot erstellt.

Schlussfolgerungen

Trotz alledem verwende ich auf einigen Systemen immer noch LVM, aber für ein Desktop-Setup bevorzuge ich rohe Partitionen. Der Hauptvorteil, den ich von LVM sehe, ist die Flexibilität beim Verschieben und Ändern der Größe von FSs wenn Sie eine hohe Betriebszeit auf einem Server haben müssen - Wenn Sie das nicht brauchen, ist gparted einfacher und hat ein geringeres Risiko von Datenverlust.

LVM erfordert aufgrund von VM-Hypervisoren, Festplatten-/SSD-Schreibcaching usw. große Sorgfalt bei der Einrichtung des Schreib-Cachings – aber das Gleiche gilt für die Verwendung von Linux als DB-Server. Die fehlende Unterstützung durch die meisten Tools (gparted einschließlich der Berechnungen der kritischen Größe und testdisk usw.) macht es schwieriger zu verwenden, als es sein sollte.

Wenn Sie LVM verwenden, seien Sie sehr vorsichtig mit Snapshots:Verwenden Sie nach Möglichkeit VM/Cloud-Snapshots oder untersuchen Sie ZFS/btrfs, um LVM vollständig zu vermeiden – Sie werden möglicherweise feststellen, dass ZFS oder btrfs im Vergleich zu LVM mit Snapshots ausreichend ausgereift ist.

Fazit:Wenn Sie die oben aufgeführten Probleme nicht kennen und wissen, wie Sie sie lösen können, verwenden Sie LVM am besten nicht.

Lösung 2:

Ich [+1] diesen Beitrag, und zumindest für mich denke ich, dass die meisten Probleme existieren. Ich habe sie gesehen, während sie ein paar 100 Server und ein paar 100 TB Daten betrieben haben. Für mich fühlt sich LVM2 in Linux wie eine "kluge Idee" an, die jemand hatte. Wie einige von ihnen erweisen sie sich manchmal als "nicht schlau". Kernel- und Userspace-Zustände (lvmtab) nicht streng voneinander getrennt zu haben, hätte sich vielleicht als sehr klug erwiesen, sie abzuschaffen, da es zu Korruptionsproblemen kommen kann (wenn Sie den Code nicht richtig hinbekommen)

Nun, nur dass diese Trennung aus einem bestimmten Grund da war - Die Unterschiede zeigen sich bei der Behandlung von PV-Verlusten und der Online-Reaktivierung einer VG mit z. B. fehlenden PVs, um sie wieder ins Spiel zu bringen - Was auf "Original-LVMs" (AIX, HP-UX) ein Kinderspiel ist, wird seitdem auf LVM2 zu Mist die Zustandsbehandlung ist nicht gut genug. Und bringen Sie mich nicht einmal dazu, über Quorum-Verlusterkennung (haha) oder Zustandsbehandlung zu sprechen (wenn ich eine Festplatte entferne, wird das nicht als nicht verfügbar gekennzeichnet. Es tut nicht einmal haben die verdammte Statusspalte)

Re:Stabilität pvmove ... warum ist

pvmove Datenverlust

So ein hochrangiger Artikel in meinem Blog, hmmm? Gerade schaue ich mir eine Platte an, auf der die physikalischen lvm-Daten noch auf dem Stand von mid-pvmove hängen. Es gab einige Memleaks, denke ich, und die allgemeine Idee, dass es eine gute Sache ist Live-Blockdaten aus dem Userspace zu kopieren ist einfach traurig. Nettes Zitat aus der lvm-Liste "scheint wie vgreduce --missing behandelt pvmove nicht" Bedeutet tatsächlich, wenn sich eine Festplatte während pvmove löst, ändert sich das lvm-Verwaltungstool von lvm zu vi. Oh, und es gab auch einen Fehler, bei dem pvmove nach einem Block-Lese-/Schreibfehler fortfährt und tatsächlich keine Daten mehr auf das Zielgerät schreibt. WTF?

Re:Schnappschüsse Die CoW wird unsicher ausgeführt, indem die NEUEN Daten in den Snapshot-lv-Bereich aktualisiert und dann wieder zusammengeführt werden, sobald Sie den Snap löschen. Dies bedeutet, dass Sie während des endgültigen Zusammenführens neuer Daten in das ursprüngliche LV starke IO-Spitzen haben und, viel wichtiger, Sie haben natürlich auch ein viel höheres Risiko einer Datenkorruption, da der Snapshot nicht beschädigt wird, sobald Sie das treffen Wand, sondern das Original.

Der Vorteil liegt in der Leistung, da 1 statt 3 Schreibvorgänge ausgeführt werden. Die Auswahl des schnellen, aber unsicheren Algorithmus ist etwas, das man offensichtlich von Leuten wie VMware und MS erwartet, auf "Unix" würde ich eher vermuten, dass die Dinge "richtig gemacht" werden Ich habe keine großen Leistungsprobleme gesehen, solange ich den Snapshot-Sicherungsspeicher auf einem anderen habe Laufwerk als die primären Daten (und natürlich als Backup auf einem anderen)

Re:Barrieren Ich bin mir nicht sicher, ob man das LVM anlasten kann. Es war ein Devmapper-Problem, soweit ich weiß. Aber es kann eine Schuld dafür geben, dass es sich nicht wirklich um dieses Problem von mindestens Kernel 2.6 bis 2.6.33 kümmert. AFAIK Xen ist der einzige Hypervisor, der O_DIRECT für die virtuellen Maschinen verwendet, das verwendete Problem zu sein, wenn "loop" verwendet wurde, weil der Kernel immer noch damit cachen würde. Virtualbox hat zumindest einige Einstellungen, um solche Dinge zu deaktivieren, und Qemu/KVM scheint im Allgemeinen Caching zuzulassen. Auch alle FUSE FS haben dort Probleme (kein O_DIRECT)

Re:Größen Ich denke, LVM "rundet" die angezeigte Größe. Oder es verwendet GiB. Wie auch immer, Sie müssen die VG Pe-Größe verwenden und sie mit der LE-Nummer des LV multiplizieren. Das sollte die korrekte Nettogröße ergeben, und dieses Problem ist immer ein Nutzungsproblem. Es wird durch Dateisysteme verschlimmert, die so etwas während fsck/mount (Hallo, ext3) nicht bemerken oder kein funktionierendes Online-"fsck -n" (Hallo, ext3)

Natürlich ist es bezeichnend, dass Sie keine guten Quellen für solche Informationen finden können. "Wie viele LE für die VRA?" "Was ist der physische Offset für PVRA, VGDA, ... etc"

Verglichen mit dem Original ist LVM2 das Paradebeispiel für "Diejenigen, die UNIX nicht verstehen, sind dazu verdammt, es neu zu erfinden, schlecht."

Update ein paar Monate später:Ich habe jetzt das Szenario "vollständiger Schnappschuss" für einen Test getroffen. Wenn sie voll werden, blockiert der Snapshot, nicht das ursprüngliche LV. Da habe ich mich geirrt, als ich das zum ersten Mal gepostet hatte. Ich habe falsche Informationen von einem Dokument erhalten, oder vielleicht hatte ich es verstanden. Bei meinen Setups war ich immer sehr paranoid, sie nicht füllen zu lassen, und so wurde ich nie korrigiert. Es ist auch möglich, Snapshots zu erweitern/verkleinern, was ein Leckerbissen ist.

Was ich immer noch nicht lösen konnte, ist, wie man das Alter eines Snapshots erkennt. Bezüglich ihrer Leistung gibt es einen Hinweis auf der Fedora-Projektseite "thinp", der besagt, dass die Snapshot-Technik überarbeitet wird, damit sie nicht langsamer werden mit jedem Snapshot.Ich weiß nicht, wie sie es implementieren.

Lösung 3:

Wenn Sie vorhaben, Snapshots für Backups zu verwenden, sollten Sie sich auf große Leistungseinbußen einstellen, wenn Snapshots vorhanden sind. ansonsten ist alles gut. Ich verwende lvm seit einigen Jahren in der Produktion auf Dutzenden von Servern, obwohl mein Hauptgrund, es zu verwenden, der atomare Snapshot ist, der nicht in der Lage ist, Volumes einfach zu erweitern.

Übrigens, wenn Sie ein 1-TB-Laufwerk verwenden, denken Sie an die Partitionsausrichtung - dieses Laufwerk hat höchstwahrscheinlich 4-kB-Sektoren.

Lösung 4:

Während sie einen interessanten Einblick in den Zustand von LVM vor mehr als 10 Jahren bietet, ist die akzeptierte Antwort heute völlig veraltet. Modern (d. h. LVM nach 2012):

• berücksichtigt Synchronisierungs-/Sperranforderungen
• hat eine schnelle und zuverlässige Snapshot-Fähigkeit in Form von lvmthin
• stabiles SSD-Caching über lvmcache haben und eine Richtlinie für schnelles Zurückschreiben für NVMe/NVDIMM/Optane über dm-writecache
• virtueller Datenoptimierer (vdo ) Unterstützung dank lvmvdo
• integriertes RAID pro Volume dank lvmraid
• automatische Ausrichtung auf 1 MB oder 4 MB (je nach Version), wodurch 4K-Ausrichtungsprobleme vollständig vermieden werden (es sei denn, LVM wird über einer falsch ausgerichteten Partition verwendet)
• hervorragende Unterstützung zum Erweitern eines Volumes, insbesondere beim Hinzufügen anderer Blockgeräte (was einfach nicht möglich ist, wenn ein klassisches Dateisystem wie ext4/xfs auf einer einfachen Partition verwendet wird)
• eine ausgezeichnete, freundliche und äußerst nützliche Mailingliste unter [email protected]

Das bedeutet natürlich nicht, dass Sie immer haben LVM zu verwenden - die goldene Regel für die Speicherung lautet, unnötige Schichten zu vermeiden. Beispielsweise können Sie für einfache virtuelle Maschinen sicherlich nur mit der klassischen Partition fortfahren. Aber wenn Sie eine der oben genannten Funktionen schätzen, ist LVM ein äußerst nützliches Tool, das in der Toolbox jedes ernsthaften Linux-Systemadministrators enthalten sein sollte.

Lösung 5:

Adam,

Ein weiterer Vorteil:Sie können ein neues physisches Volume (PV) hinzufügen, alle Daten auf dieses PV verschieben und dann das alte PV ohne Dienstunterbrechung entfernen. Ich habe diese Funktion in den letzten fünf Jahren mindestens viermal genutzt.

Ein Nachteil, auf den ich noch nicht deutlich hingewiesen habe:Es gibt eine etwas steile Lernkurve für LVM2. Meistens in der Abstraktion, die es zwischen Ihren Dateien und den zugrunde liegenden Medien schafft. Wenn Sie mit nur wenigen Leuten arbeiten, die sich die Aufgaben auf mehreren Servern teilen, werden Sie die zusätzliche Komplexität für Ihr Team als Ganzes möglicherweise überwältigen. Größere Teams, die sich der IT-Arbeit widmen, werden im Allgemeinen kein solches Problem haben.

Zum Beispiel verwenden wir es hier bei meiner Arbeit häufig und haben uns die Zeit genommen, dem gesamten Team die Grundlagen, die Sprache und das Nötigste über die Wiederherstellung von Systemen beizubringen, die nicht richtig booten.

Eine besondere Warnung:Wenn Sie von einem logischen LVM2-Volume booten, finden Sie Wiederherstellungsvorgänge schwierig, wenn der Server abstürzt. Knoppix und Co. haben dafür nicht immer das richtige Zeug. Also haben wir beschlossen, dass unser /boot-Verzeichnis auf einer eigenen Partition liegt und immer klein und nativ ist.

Insgesamt bin ich ein Fan von LVM2.