LVM Gefahren und Vorbehalte

Ich habe kürzlich begonnen, LVM auf einigen Servern für Festplatten mit mehr als 1 TB zu verwenden. Sie sind nützlich, erweiterbar und recht einfach zu installieren. Ich konnte jedoch keine Daten über die Gefahren und Vorbehalte von LVM finden.

Was sind die Nachteile von LVM?

Zusammenfassung

Risiken bei der Verwendung von LVM:

• Anfällig für das Schreiben von Caching-Problemen mit SSD oder VM Hypervisor
• Schwieriger, Daten aufgrund komplexerer Strukturen auf der Festplatte wiederherzustellen
• Schwieriger, die Größe von Dateisystemen korrekt zu ändern
• Schnappschüsse sind schwer zu bedienen, langsam und fehlerhaft
• Erfordert einige Fähigkeiten, um diese Probleme richtig zu konfigurieren

Die ersten beiden LVM-Probleme lassen sich zusammenfassen: Wenn das Schreib-Caching nicht ordnungsgemäß funktioniert und Sie einen Stromausfall haben (z. B. Netzteil- oder USV-Ausfall), müssen Sie möglicherweise eine Wiederherstellung nach einem Backup durchführen, was erhebliche Ausfallzeiten zur Folge hat. Ein Hauptgrund für die Verwendung von LVM ist die höhere Betriebszeit (beim Hinzufügen von Festplatten, Ändern der Größe von Dateisystemen usw.), aber es ist wichtig, dass die Schreibcache-Einrichtung korrekt ist, um zu vermeiden, dass LVM die Betriebszeit tatsächlich verringert.

- Aktualisiert im Dezember 2018: Aktualisiertes Snapshot-Material, einschließlich der Stabilität von ZFS und BTRFS als Alternative zu LVM-Snapshots

Risiken mindern

LVM kann immer noch gut funktionieren, wenn Sie:

• Richten Sie Ihre Schreibcache-Einrichtung direkt in Hypervisor, Kernel und SSDs ein
• Vermeiden Sie LVM-Snapshots
• Verwenden Sie die neuesten LVM-Versionen, um die Größe von Dateisystemen zu ändern
• Habe gute Backups

Einzelheiten

Ich habe dies in der Vergangenheit ziemlich genau untersucht, nachdem ich einen Datenverlust im Zusammenhang mit LVM erlebt habe. Die wichtigsten LVM-Risiken und Probleme, die mir bekannt sind, sind:

Aufgrund von VM-Hypervisoren, Festplatten-Caching oder alten Linux-Kerneln anfällig für Schreibcaches auf der Festplatte. Aufgrund komplexerer Strukturen auf der Festplatte ist es schwieriger, Daten wiederherzustellen. Weitere Informationen finden Sie weiter unten. Ich habe festgestellt, dass vollständige LVM-Setups auf mehreren Datenträgern beschädigt wurden, ohne dass eine Wiederherstellung möglich war, und LVM plus Festplatten-Schreibcache ist eine gefährliche Kombination.

• Write-Caching und Write-Re-Ordering auf der Festplatte sind wichtig für eine gute Leistung, können jedoch aufgrund von VM-Hypervisoren, Write-Caching auf der Festplatte, alten Linux-Kerneln usw. fehlschlagen, um Blöcke korrekt auf die Festplatte zu übertragen.
  • Schreibbarrieren bedeuten, dass der Kernel garantiert, dass bestimmte Festplattenschreibvorgänge vor dem "Barriere" -Festplattenschreibvorgang abgeschlossen werden, um sicherzustellen, dass Dateisysteme und RAID bei einem plötzlichen Stromausfall oder Absturz 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. Dies ist effizienter als eine vollständige Cache-Leerung. Barrieren können mit effizientem Tagged / Native Command Queuing (Ausgabe mehrerer Festplatten-E / A-Anforderungen gleichzeitig) kombiniert werden , damit die Festplatte eine intelligente Neuordnung der Schreibvorgänge durchführen kann, ohne das Risiko eines Datenverlusts zu erhöhen.
• VM-Hypervisoren können ä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 des Schreibcaches und des erneuten Schreibens ähnliche Probleme wie ein Kernel ohne Schreibbarrieren verursachen -Bestellung. Überprüfen Sie Ihre Hypervisor-Dokumentation sorgfältig auf eine Option zum Leeren auf Festplatte oder Durchschreiben des Cache (in KVM , VMware , Xen , VirtualBox und anderen vorhanden) und testen Sie sie mit Ihrem Setup. Einige Hypervisoren wie VirtualBox verfügen über eine Standardeinstellung , die alle Datenträgerlöschvorgänge vom Gast ignoriert.
• Unternehmensserver mit LVM sollten immer einen batteriegepufferten RAID-Controller verwenden und das Schreibcache für die Festplatte deaktivieren (der Controller verfügt über einen batteriegepufferten Schreibcache, der schnell und sicher ist) - siehe diesen Kommentar des Autors dieses XFS-FAQ-Eintrags . Es kann auch sicher sein, Schreibsperren im Kernel zu deaktivieren, jedoch wird das Testen empfohlen.
• Wenn Sie keinen batteriegepufferten RAID-Controller haben, verlangsamt das Deaktivieren des Schreibcaches für Festplatten das Schreiben erheblich, macht LVM jedoch sicher. Sie sollten auch das Äquivalent der data=orderedOption ext3 verwenden (oder data=journalfür zusätzliche Sicherheit) und barrier=1sicherstellen, dass das Kernel-Caching die Integrität nicht beeinträchtigt. (Oder verwenden Sie ext4, das standardmäßig Barrieren aktiviert .) Dies ist die einfachste Option und bietet eine gute Datenintegrität zu Lasten der Leistung. (Linux hat die Standardoption ext3 vor einiger Zeit in die gefährlichere Option geändert. Verlassen Sie sichdata=writeback also nicht auf die Standardeinstellungen für den FS.)
• So deaktivieren Sie das Schreibcaching für Festplatten: Fügen Sie hdparm -q -W0 /dev/sdXfür alle Laufwerke /etc/rc.local(für SATA) hinzu, oder verwenden Sie sdparm für SCSI / SAS. Laut diesem Eintrag in den häufig gestellten Fragen zu XFS (der zu diesem Thema sehr gut ist) kann ein SATA-Laufwerk diese Einstellung nach einer Wiederherstellung nach einem Laufwerksfehler jedoch vergessen. Verwenden Sie daher SCSI / SAS, oder setzen Sie das ein, wenn Sie SATA verwenden müssen Befehl hdparm in einem Cron-Job, der etwa jede Minute ausgeführt wird.
• Damit das SSD / Festplatten-Schreib-Caching für eine bessere Leistung aktiviert bleibt: Dies ist ein komplexer Bereich - siehe Abschnitt unten.
• Wenn Sie Laufwerke mit erweitertem Format verwenden, z. B. physische 4-KB-Sektoren, siehe unten - das Deaktivieren des Schreibcaches kann andere Probleme verursachen.
• Die USV ist sowohl für Unternehmen als auch für SOHO von entscheidender Bedeutung, reicht jedoch nicht aus, um die Sicherheit von LVM zu gewährleisten: Alle Elemente, die einen schweren Absturz oder einen Stromausfall verursachen (z. B. USV-Ausfall, Netzteilausfall oder Erschöpfung der Laptopbatterie), können Daten in den Festplatten-Caches verlieren.
• Sehr alter Linux - Kernel (2.6.x ab 2009) : Es gibt unvollständige Schreibsperre Unterstützung in sehr alten Kernel - Versionen, 2.6.32 und früher ( 2.6.31 hat eine gewisse Unterstützung , während 2.6.33 Arbeiten für alle Gerätetypen Ziel) - RHEL 6 verwendet 2.6.32 mit vielen Patches. Wenn diese alten 2.6-Kernel für diese Probleme nicht gepatcht sind, kann eine große Menge von FS-Metadaten (einschließlich Journalen) durch einen Absturz verloren gehen, bei dem Daten in den Schreibpuffern der Festplatten verbleiben (z. B. 32 MB pro Laufwerk für gängige 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 hohe FS-Korruption und damit Datenverlust.
• Zusammenfassung: Sie müssen das Dateisystem-, RAID-, VM-Hypervisor- und Festplatten- / SSD-Setup berücksichtigen, das mit LVM verwendet wird. Wenn Sie LVM verwenden, müssen Sie über sehr gute Backups verfügen und sicherstellen, dass Sie die LVM-Metadaten, das Setup der physischen Partitionen, den MBR und die Volume-Boot-Sektoren speziell sichern. Es ist auch ratsam, SCSI / SAS-Laufwerke zu verwenden, da diese mit geringerer Wahrscheinlichkeit in Bezug auf die Schreibzwischenspeicherung lügen - die Verwendung von SATA-Laufwerken erfordert mehr Sorgfalt.

Schreib-Caching für die Leistung aktiviert lassen (und mit liegenden Laufwerken umgehen)

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.

Sie sollten auch sicherstellen, dass das RAID-Setup, das VM-Hypervisor-Setup und das Dateisystem Schreibbarrieren verwenden (dh das Laufwerk muss ausstehende Schreibvorgänge vor und nach Schlüsselmetadaten- / Journalschreibvorgängen löschen). XFS verwendet standardmäßig Barrieren, ext3 jedoch nicht . Daher sollten Sie ext3 barrier=1in den Mount-Optionen verwenden und weiterhin data=orderedoder data=journalwie oben verwenden.

• Leider lügen einige Festplatten und SSDs darüber, ob sie ihren Cache wirklich auf die Festplatte geleert haben (insbesondere ältere Laufwerke, aber auch einige SATA-Laufwerke und einige Enterprise-SSDs ) - mehr Details hier . Es gibt eine großartige Zusammenfassung von einem XFS-Entwickler .
• Es gibt ein einfaches Testtool für fehlerhafte Laufwerke (Perl-Skript), oder sehen Sie sich diesen Hintergrund mit einem anderen Tool an, das als Ergebnis des Laufwerk-Cache die Schreibreihenfolge ändert. Diese Antwort deckte ähnliche Tests von SATA-Laufwerken ab, bei denen ein Schreibschutzproblem bei Software-RAID aufgedeckt wurde - diese Tests belegen tatsächlich den gesamten Speicherstapel.
• Neuere SATA-Laufwerke, die Native Command Queuing (NCQ) unterstützen, weisen möglicherweise eine geringere Wahrscheinlichkeit auf - oder sie funktionieren aufgrund von NCQ ohne Schreib-Caching gut, und nur sehr wenige Laufwerke können das Schreib-Caching nicht deaktivieren.
• SCSI / SAS-Laufwerke sind im Allgemeinen in Ordnung, da für eine gute Leistung kein Schreibcache erforderlich ist (über SCSI Tagged Command Queuing , ähnlich wie bei SATA NCQ).
• Wenn Ihre Festplatten oder SSDs sich nicht darum kümmern, ihren Cache auf die Festplatte zu 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, Datenträgermanager und Software-RAIDs , nicht nur für LVM.

SSDs sind problematisch, da die Verwendung von Schreibcache für die Lebensdauer der SSD von entscheidender Bedeutung ist. Verwenden Sie am besten eine SSD mit einem Superkondensator (um das Leeren des Cache bei Stromausfall zu ermöglichen und damit das Zurückschreiben des Cache zu ermöglichen, nicht das Durchschreiben).

• Die meisten Enterprise-SSDs sollten bei der Schreibcachesteuerung in Ordnung sein, und einige enthalten Superkondensatoren.
• Einige billigere SSDs haben Probleme, die mit der Schreib-Cache-Konfiguration nicht behoben werden können - die Mailingliste des PostgreSQL-Projekts und die Wiki-Seite Reliable Writes sind gute Informationsquellen. Consumer-SSDs können schwerwiegende Schreib-Caching-Probleme aufweisen , die zu Datenverlusten führen. Sie enthalten keine Superkondensatoren und sind daher anfällig für Stromausfälle, die zu Korruption führen.

Advanced Format Drive Setup - Schreibcache, Ausrichtung, RAID, GPT

• Bei neueren Advanced Format-Laufwerken , die physische 4-KB-Sektoren verwenden, kann es wichtig sein, das Schreibcaching für Laufwerke aktiviert zu lassen, da die meisten dieser Laufwerke derzeit logische 512-Byte-Sektoren ( "512-Emulation" ) emulieren und manche sogar behaupten, physische 512-Byte- Sektoren zu haben Sektoren, während wirklich 4 KiB verwendet.
• Das Deaktivieren des Schreibcaches eines Advanced Format-Laufwerks kann eine sehr große Auswirkung auf die Leistung haben, wenn die Anwendung / der Kernel 512-Byte-Schreibvorgänge ausführt, da solche Laufwerke darauf angewiesen sind, dass der Cache 8 x 512-Byte-Schreibvorgänge ansammelt, bevor ein einzelnes 4-KB-physisches Laufwerk ausgeführt wird schreiben. Das Testen wird empfohlen, um Auswirkungen zu bestätigen, wenn Sie den Cache deaktivieren.
• Das Ausrichten der LVs an einer 4-KB-Grenze ist für die Leistung wichtig, sollte jedoch automatisch erfolgen, solange die zugrunde liegenden Partitionen für die PVs ausgerichtet sind, da LVM Physical Extents (PEs) standardmäßig 4 MiB betragen. RAID muss hier berücksichtigt werden. Auf dieser Seite zum Einrichten von LVM- und Software-RAID wird vorgeschlagen , den RAID-Superblock am Ende des Volumes zu platzieren und (falls erforderlich) eine Option pvcreatezum Ausrichten der PVs zu verwenden. Dieser LVM-E-Mail-Listenthread verweist auf die im Jahr 2011 in Kerneln durchgeführten Arbeiten und das Problem der Teilblockschreibvorgänge beim Mischen von Festplatten mit 512-Byte- und 4-KB-Sektoren in einer einzelnen LV.
• Die GPT-Partitionierung mit dem erweiterten Format erfordert besondere Sorgfalt, insbesondere für Boot- und Root-Laufwerke, um sicherzustellen, dass die erste LVM-Partition (PV) an einer Grenze von 4 KB beginnt.

Schwieriger, Daten aufgrund komplexerer Strukturen auf der Festplatte wiederherzustellen :

• Jegliche Wiederherstellung von LVM-Daten, die nach einem schweren Absturz oder einem Stromausfall (aufgrund eines falschen Schreibcaches) erforderlich ist, erfolgt bestenfalls manuell, da anscheinend keine geeigneten Tools vorhanden sind. LVM ist gut darin, die Metadaten unter zu /etc/lvmsichern. Dies kann zur Wiederherstellung der Grundstruktur von LVs, VGs und PVs beitragen, hilft jedoch nicht bei verlorenen Metadaten des Dateisystems.
• Daher ist wahrscheinlich eine vollständige Wiederherstellung von einem Backup erforderlich. Dies bedeutet viel mehr Ausfallzeit als ein schneller journalgestützter 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-Datenträgern wiederherstellen , unterstützen jedoch die LVM-Datenwiederherstellung nicht direkt. TestDisk kann feststellen, dass eine verlorene physische Partition eine LVM-PV enthält, aber keines dieser Tools versteht logische LVM-Volumes. Datei-Carving- Tools wie PhotoRec und viele andere würden funktionieren, wenn sie das Dateisystem umgehen, um Dateien aus Datenblöcken neu zusammenzusetzen. Dies ist jedoch ein letzter Ausweg für wertvolle Daten auf niedriger Ebene und funktioniert weniger gut mit fragmentierten Dateien.
• In einigen Fällen ist eine manuelle LVM-Wiederherstellung möglich, jedoch komplex und zeitaufwändig. In diesem Beispiel und in diesem , diesem und diesem Beispiel wird erläutert , wie Sie eine Wiederherstellung durchführen.

Schwieriger, die Größe von Dateisystemen korrekt zu ändern - Die einfache Größenänderung von Dateisystemen wird häufig 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 mit dem FS gemountet, aber ich würde letzteres niemals riskieren ohne aktuelle Backups und mit Befehlen, die auf einem äquivalenten Server vorgetestet wurden (zB Disaster Recovery Clone des Produktionsservers).

• Update: Neuere Versionen lvextendunterstützen die Option -r( --resizefs). Wenn diese verfügbar ist, können Sie die Größe des LV und des Dateisystems sicherer und schneller ändern, insbesondere, wenn Sie den FS verkleinern, und Sie können diesen Abschnitt meistens überspringen.
• Die meisten Anleitungen zum Ändern der Größe von LVM-basierten FSs berücksichtigen nicht die Tatsache, dass der FS etwas kleiner als die Größe des LV sein muss. Eine ausführliche Erläuterung finden Sie hier . Wenn Sie ein Dateisystem verkleinern, müssen Sie die neue Größe für das FS-Größenänderungs-Tool angeben, z. B. resize2fsfür ext3 und für lvextendoder lvreduce. Ohne große Sorgfalt, werden die Größen aufgrund der Differenz zwischen 1 GB etwas anders können (10 ^ 9) und 1 GiB (2 ^ 30) oder die Art und Weise die verschiedenen Werkzeuge Rundgrößen nach oben oder unten.
• Wenn Sie die Berechnungen nicht genau richtig durchführen (oder einige zusätzliche Schritte verwenden, die über die offensichtlichsten hinausgehen), erhalten Sie möglicherweise eine FS, die für die LV zu groß ist. Monate oder Jahre lang scheint alles in Ordnung zu sein, bis Sie den FS vollständig ausgefüllt haben. An diesem Punkt wird es ernsthafte Korruption geben - und wenn Sie sich dieses Problems nicht bewusst sind, ist es schwierig herauszufinden, warum, da Sie bis dahin möglicherweise auch echte Festplattenfehler haben das trübt die Situation. (Möglicherweise wirkt sich dieses Problem nur auf die Verringerung der Größe von Dateisystemen aus. Es ist jedoch klar, dass die Größenänderung von Dateisystemen in beide Richtungen das Risiko von Datenverlusten erhöht, möglicherweise aufgrund von Benutzerfehlern.)

• Es scheint, dass die LV-Größe um das Zweifache der Größe des physischen LVM-Bereichs (PE) größer sein sollte als die FS-Größe. Überprüfen Sie jedoch den obigen Link auf Details, da die Quelle dafür nicht maßgeblich ist. Oft reicht es aus, 8 MiB zuzulassen, aber möglicherweise ist es aus Sicherheitsgründen besser, mehr zuzulassen, z. B. 100 MiB oder 1 GiB. So überprüfen Sie die PE-Größe und Ihr logisches Volumen + FS-Größen 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, nimmt 4 KiB FS-Blockgröße an:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Im Gegensatz dazu macht eine Nicht-LVM-Einrichtung das Ändern der Größe 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 partedvon der Shell aus verwenden.

  • Es ist oft am besten, die Gparted Live-CD oder Parted Magic zu verwenden , da diese eine neuere und häufig fehlerfreiere Version von Gparted & Kernel als die Distributionsversion haben Kernel. Wenn Sie die Distribution Gparted verwenden, müssen Sie sofort nach dem Ändern der Partitionen einen Neustart durchführen, damit die Ansicht des Kernels korrekt ist.

Schnappschüsse sind schwer zu verwenden, langsam und fehlerhaft - wenn der vorab zugewiesene Speicherplatz für Schnappschüsse knapp wird, werden sie automatisch gelöscht . Jeder Snapshot eines bestimmten LV ist ein Delta zu diesem LV (nicht zu vorherigen Snapshots), was viel Speicherplatz erfordern kann, wenn Sie Dateisysteme mit erheblicher Schreibaktivität snapshoten (jeder Snapshot ist größer als der vorherige). Es ist sicher, eine Snapshot-LV zu erstellen, die dieselbe Größe wie die Original-LV hat, da der Snapshot dann niemals keinen freien Speicherplatz mehr hat.

Snapshots können auch sehr langsam sein (dh 3 bis 6-mal langsamer als ohne LVM für diese MySQL-Tests ). In dieser Antwort werden verschiedene Snapshot-Probleme behandelt . Die Langsamkeit ist teilweise darauf zurückzuführen, dass für Schnappschüsse viele synchrone Schreibvorgänge erforderlich sind .

Snapshots hatten einige schwerwiegende 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 (da der Kernel das Warten auf den Root-FS aussetzen kann, wenn es sich um einen LVM-Snapshot handelt [behoben im Debian- initramfs-toolsUpdate, März 2015] ).

• Bis 2015 wurden jedoch anscheinend viele Fehler in Bezug auf die Snapshot-Race-Bedingungen behoben .
• LVM ohne Snapshots scheint im Allgemeinen recht gut getestet zu sein, möglicherweise, weil Snapshots nicht so häufig 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 häufig eine viel bessere Alternative zu LVM-Snapshots. Sie können ganz einfach einen Snapshot für Sicherungszwecke erstellen (aber erwägen, den FS vorab einzufrieren).

Dateisystem-Snapshots:

• Schnappschüsse auf Dateisystemebene mit ZFS oder btrfs sind einfach zu verwenden und im Allgemeinen besser als LVM, wenn Sie auf Bare-Metal-Systemen arbeiten (ZFS scheint jedoch weitaus ausgereifter zu sein und nur umständlicher zu installieren):

  • ZFS: Es gibt jetzt eine Kernel-ZFS-Implementierung , die seit einigen Jahren in Gebrauch ist
  • btrfs : immer noch nicht produktionsbereit ( selbst unter openSUSE, das es standardmäßig ausliefert und ein spezielles Team für btrfs hat), während RHEL die Unterstützung eingestellt hat. Die Tools fsck und repair sind noch in der Entwicklung.

Snapshots für Online-Backups und fsck

Snapshots können verwendet werden, um eine konsistente Quelle für Backups bereitzustellen , sofern Sie den zugewiesenen Speicherplatz berücksichtigen (idealerweise hat der Snapshot die gleiche Größe wie der zu sichernde LV). Der exzellente rsnapshot (seit 1.3.1) verwaltet sogar die Erstellung / Löschung von LVM-Snapshots für Sie - siehe dieses HOWTO zu rsnapshot mit LVM . Beachten Sie jedoch die allgemeinen Probleme mit Snapshots und dass ein Snapshot nicht als Backup an sich betrachtet werden sollte.

Sie können auch LVM-Snapshots verwenden, um einen Online-Fsck durchzuführen: Snapshot des LV und Fsck des Snapshots, wobei der hier beschriebene FS , der nicht zum Snapshot gehört, weiterhin verwendet wird. Daher ist es nicht ganz einfach , 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 tun dies automatisch, wenn LVM den Snapshot erstellt.

Schlussfolgerungen

Trotz alledem verwende ich LVM immer noch auf einigen Systemen, aber für ein Desktop-Setup bevorzuge ich Raw-Partitionen. Der Hauptvorteil von LVM ist die Flexibilität beim Verschieben und Ändern der Größe von FSs, wenn auf einem Server eine hohe Verfügbarkeit erforderlich ist. Wenn Sie dies nicht benötigen, ist gparted einfacher und birgt ein geringeres Risiko für Datenverluste.

LVM erfordert aufgrund von VM-Hypervisoren, Festplatten- / SSD-Schreibcache usw. große Sorgfalt bei der Einrichtung des Schreibcaches. Dies gilt jedoch auch für die Verwendung von Linux als DB-Server. Der Mangel an Unterstützung durch die meisten Tools ( gpartedeinschließlich der kritischen Größenberechnungen testdiskusw.) erschwert die Verwendung.

Gehen Sie bei der Verwendung von LVM sehr vorsichtig mit Snapshots um: Verwenden Sie nach Möglichkeit VM / Cloud-Snapshots oder untersuchen Sie ZFS / BTRFS, um LVM vollständig zu vermeiden. Möglicherweise ist ZFS oder BTRS im Vergleich zu LVM mit Snapshots ausreichend ausgereift.

Fazit: Wenn Sie die oben aufgeführten Probleme nicht kennen und nicht wissen, wie Sie sie beheben können, sollten Sie LVM nicht verwenden.

Ich habe diesen Post [+1] und zumindest für mich denke ich, dass die meisten Probleme existieren. Ich habe sie gesehen, während ein paar 100 Server und ein paar 100 TB Daten laufen. Für mich fühlt sich der LVM2 unter Linux wie eine "clevere Idee" an, die jemand hatte. Wie einige von ihnen erweisen sie sich manchmal als "nicht schlau". Das heißt, wenn Kernel- und Userspace-Zustände (lvmtab) nicht strikt voneinander getrennt sind, hat sich dies möglicherweise als sehr klug herausgestellt, da es zu Korruptionsproblemen kommen kann (wenn Sie den Code nicht richtig verstehen).

Nun, nur, dass diese Trennung aus einem Grund bestand - die Unterschiede zeigen sich bei der Behandlung von PV-Verlusten und der Online-Reaktivierung einer VG mit zB fehlenden PVs, um sie wieder ins Spiel zu bringen - Was ist ein Kinderspiel bei "Original-LVMs" (AIX , HP-UX) wird auf LVM2 zu Mist, da die Zustandsbehandlung nicht gut genug ist. Und bringen Sie mich nicht einmal dazu, über die Erkennung von Quorum-Verlusten (haha) oder die Statusverwaltung (wenn ich eine Festplatte entferne, wird diese nicht als nicht verfügbar markiert. Sie enthält nicht einmal die Spalte mit dem verdammten Status) zu sprechen.

Re: Stabilität pvmove ... warum ist

pvmove Datenverlust

So ein Top-Artikel in meinem Blog, hmmm? Im Moment schaue ich auf eine Diskette, auf der sich die Daten der phyiscal lvm noch in der Mitte von pvmove befinden. Ich denke, es gab einige Memleaks, und die allgemeine Idee, dass es eine gute Sache ist, Live-Blockdaten aus dem Benutzerraum zu kopieren, ist einfach traurig. Nettes Zitat aus der lvm-Liste "scheint wie vgreduce --missing behandelt pvmove nicht" Bedeutet in der Tat, dass das lvm-Verwaltungstool von lvm zu vi wechselt, wenn sich eine Festplatte während pvmove löst. Oh, und es gab auch einen Fehler, bei dem pvmove nach einem Block-Lese- / Schreibfehler fortgesetzt wird und tatsächlich keine Daten mehr auf das Zielgerät schreibt. WTF?

Betreff : Snapshots Die CoW wird unsicher ausgeführt, indem die NEUEN Daten im Snapshot-Level-Bereich aktualisiert und dann wieder zusammengeführt werden, sobald Sie den Snap löschen. Dies bedeutet, dass Sie beim endgültigen Zusammenführen neuer Daten in die ursprüngliche LV starke E / A-Spitzen haben und, was noch wichtiger ist, natürlich auch ein viel höheres Risiko für Datenbeschädigungen, da der Snapshot nicht beschädigt wird, sobald Sie die Datei öffnen Wand, aber das Original.

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

Betreff: Barrieren Ich bin mir nicht sicher, ob man LVM dafür verantwortlich machen kann. Soweit ich weiß, war es ein Devmapper-Problem. Es kann jedoch einige Schuld daran geben, dass dieses Problem von Kernel 2.6 bis 2.6.33 nicht wirklich berücksichtigt wird. AFAIK Xen ist der einzige Hypervisor, der O_DIRECT für die virtuellen Maschinen verwendet. Das Problem bestand früher, als "loop" verwendet wurde, weil der Kernel verwendet wurde würde immer noch damit zwischenspeichern. Virtualbox hat zumindest einige Einstellungen, um solche Dinge zu deaktivieren, und Qemu / KVM scheint generell das Cachen zuzulassen. Alle FUSE FS haben auch dort Probleme (kein O_DIRECT)

Betreff: 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 mit der LE-Nummer des LV multiplizieren. Das sollte die richtige Netzgröße ergeben, und dieses Problem ist immer ein Verwendungsproblem. Es wird durch Dateisysteme verschlimmert, die so etwas bei fsck / mount nicht bemerken (hallo, ext3) oder online kein "fsck -n" haben (hallo, ext3)

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

Im Vergleich zum Original ist LVM2 das beste Beispiel für "Wer UNIX nicht versteht, ist verdammt, es schlecht neu zu erfinden."

Update ein paar Monate später: Ich habe jetzt das "Full Snapshot" -Szenario für einen Test getroffen. Wenn sie voll sind, wird der Snapshot blockiert, nicht der ursprüngliche LV. Ich habe mich dort geirrt, als ich das zum ersten Mal gepostet hatte. Ich habe bei einem Arzt falsche Informationen abgerufen, oder vielleicht habe ich sie verstanden. In meinen Setups war ich immer sehr paranoid, sie nicht voll werden zu lassen, und so wurde ich nie korrigiert. Es ist auch möglich, Schnappschüsse zu vergrößern / zu verkleinern, was ein Vergnügen ist.

Was ich immer noch nicht lösen konnte, ist, wie ich das Alter eines Schnappschusses identifiziere. In Bezug auf ihre Leistung gibt es auf der "thinp" -Fedora-Projektseite einen Hinweis, der besagt, dass die Schnappschuss-Technik überarbeitet wird, damit sie nicht mit jedem Schnappschuss langsamer wird. Ich weiß nicht, wie sie das umsetzen.

Wenn Sie vorhaben, Snapshots für Backups zu verwenden, sollten Sie auf einen großen Leistungseinbruch vorbereitet sein, wenn ein Snapshot vorhanden ist. Lesen Sie hier mehr . sonst ist alles gut Ich habe Lvm in der Produktion für ein paar Jahre auf Dutzenden von Servern verwendet, obwohl mein Hauptgrund für die Verwendung ist die atomare Momentaufnahme nicht die Fähigkeit, Volumes einfach zu erweitern.

Wenn Sie übrigens ein 1-TB-Laufwerk verwenden, denken Sie an die Partitionsausrichtung - dieses Laufwerk hat höchstwahrscheinlich 4-KB-Sektoren.

Adam,

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

Ein Nachteil, den ich noch nicht klar herausgestellt habe: Es gibt eine etwas steile Lernkurve für LVM2. Meist in der Abstraktion, die es zwischen Ihren Dateien und den zugrunde liegenden Medien erstellt. Wenn Sie mit nur wenigen Personen zusammenarbeiten, die Aufgaben auf einer Reihe von Servern teilen, ist die zusätzliche Komplexität für Ihr gesamtes Team möglicherweise überwältigend. Größere Teams, die sich der IT-Arbeit widmen, haben im Allgemeinen kein solches Problem.

Beispielsweise 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 zum Wiederherstellen von Systemen beizubringen, die nicht ordnungsgemäß gestartet werden.

Eine Warnung, die Sie besonders hervorheben sollten: Wenn Sie von einem logischen LVM2-Volume booten, war es schwierig, Wiederherstellungsvorgänge durchzuführen, wenn der Server abstürzt. Knoppix und seine Freunde haben nicht immer das richtige Zeug dafür. Deshalb haben wir beschlossen, dass sich unser / boot-Verzeichnis auf einer eigenen Partition befindet und immer klein und nativ ist.

Insgesamt bin ich ein Fan von LVM2.