Frage LVM Gefahren und Vorbehalte


Ich habe vor kurzem begonnen, LVM auf einigen Servern für Festplatten größer als 1 TB zu verwenden. Sie sind nützlich, erweiterbar und sehr einfach zu installieren. Ich konnte jedoch keine Daten über die Gefahren und Vorbehalte von LVM finden.

Was sind die Nachteile von LVM?


177
2018-06-12 07:34


Ursprung


Wenn Sie die Antworten auf diese Frage lesen, beachten Sie das Datum (Jahr), in dem sie veröffentlicht wurden. In dieser Branche passiert in 3 Jahren viel. - MattBianco
Ich habe vor kurzem (April 2015) einige Updates durchgeführt, nachdem ich überprüft habe, ob sich etwas geändert hat. Der Kernel 2.6 ist mittlerweile veraltet, SSDs sind häufiger, aber abgesehen von einigen kleinen LVM-Fixes hat sich nicht wirklich viel geändert. Ich habe einige neue Sachen über die Verwendung von VM / Cloud-Server-Snapshots anstelle von LVM-Snapshots geschrieben. Der Zustand des Schreib-Caching, der Dateisystem-Größenanpassung und der LVM-Snapshots hat sich nicht wirklich so weit verändert, wie ich sehen kann. - RichVel
in Bezug auf den Kommentar "Beachte das Datum" - wahr genug, aber denke auch, dass viele "Unternehmen" immer noch RHEL 5 und RHEL 6 verwenden, die beide auf dem neuesten Stand der Technik oder älter als das Datum sind der Antwort - JDS


Antworten:


Zusammenfassung

Risiken bei der Verwendung von LVM:

  • Anfällig, Caching-Probleme mit SSD oder VM-Hypervisor zu schreiben
  • Schwieriger, Daten aufgrund komplexerer Strukturen auf der Festplatte wiederherzustellen
  • Schwieriger, Dateisysteme korrekt zu skalieren
  • Snapshots sind schwer zu verwenden, langsam und fehlerhaft
  • Erfordert einige Fähigkeiten, um diese Probleme korrekt zu konfigurieren

Die ersten beiden LVM-Probleme verbinden sich: Wenn das Schreib-Caching nicht korrekt funktioniert und Sie einen Stromausfall haben (z. B. ein Netzteil oder eine USV), müssen Sie sich möglicherweise von der Sicherung erholen, was erhebliche Ausfallzeiten bedeutet. Ein Hauptgrund für die Verwendung von LVM ist eine höhere Verfügbarkeit (beim Hinzufügen von Laufwerken, Ändern der Größe von Dateisystemen usw.), aber es ist wichtig, dass die Schreib-Caching-Einstellungen korrekt sind, um zu vermeiden, dass LVM die Betriebszeit reduziert.

- Updated Sep 2017: machte das alte Kernel-Material weniger prominent

Risiken mindern

LVM kann immer noch gut funktionieren, wenn Sie:

  • Holen Sie sich Ihr Schreib-Caching-Setup direkt in Hypervisor, Kernel und SSDs
  • Vermeiden Sie LVM-Snapshots
  • Verwenden Sie aktuelle LVM-Versionen zum Ändern der Größe von Dateisystemen
  • Habe gute Backups

Einzelheiten

Ich habe das in der Vergangenheit schon ein wenig erforscht, nachdem ich mit LVM einen gewissen Datenverlust erlebt hatte. Die wichtigsten LVM-Risiken und Probleme, die mir bekannt sind, sind:

Anfällig für Festplatten-Schreibcache aufgrund von VM-Hypervisor, Festplatten-Caching oder alten Linux-Kernelund erschwert die Wiederherstellung von Daten aufgrund komplexerer Strukturen auf der Festplatte - Details finden Sie weiter unten. Ich habe gesehen, dass komplette LVM-Setups auf mehreren Festplatten ohne eine Chance auf Wiederherstellung beschädigt wurden, und LVM plus Festplatten-Schreib-Caching ist eine gefährliche Kombination.

  • Schreiben Sie Caching und schreiben Sie die Reihenfolge auf der Festplatte neu ist wichtig für eine gute Leistung, kann aber aufgrund von VM-Hypervisors, Festplatten-Schreib-Caching, alten Linux-Kerneln usw. keine fehlerfreie Spülung von Blöcken auf Festplatten durchführen.
    • Schreibt Barrieren bedeutet, dass der Kernel garantiert, dass bestimmte Schreibvorgänge vor dem Schreiben der "Barriere" -Diskette abgeschlossen werden, um sicherzustellen, dass Dateisysteme und RAID im Falle eines plötzlichen Stromausfalls oder Absturzes wiederhergestellt werden können. Solche Barrieren können a FUA-Betrieb (Force Unit Access) um bestimmte Blöcke sofort auf den Datenträger zu schreiben, was effizienter ist als ein vollständiger Cache-Flush. Barrieren können mit effizienten kombiniert werden markiert/einheimisch Befehlswarteschlange (gleichzeitige Ausgabe mehrerer Festplatten-E / A-Anforderungen), damit die Festplatte eine intelligente Neuordnung der Schreibvorgänge durchführen kann, ohne das Risiko eines Datenverlusts zu erhöhen.
  • VM-Hypervisor kann ähnliche Probleme haben: Ausführen von LVM in einem Linux-Gast auf einem VM-Hypervisor wie VMware, XenKann KVM, Hyper-V oder VirtualBox erstellen ähnliche Problemezu einem Kernel ohne Schreibbarrieren, wegen Schreib-Caching und Schreib-Nachbestellung. Überprüfen Sie Ihre Hypervisor-Dokumentation sorgfältig auf eine "Flush to Disk" - oder Write-Through-Cache-Option (in KVM, VMware, Xen, VirtuelleBox und andere) - und testen Sie es mit Ihrem Setup. Einige Hypervisor wie VirtualBox haben eine Standardeinstellung Das ignoriert alle Platten, die vom Gast gelöscht werden.
  • Enterprise-Server mit LVM sollten immer a verwenden batteriegestützter RAID-Controller und deaktivieren Sie den Schreibcache der Festplatte (der Controller verfügt über einen batteriegepufferten Schreibcache, der schnell und sicher ist) - siehe dieser Kommentar vom Autor von Dieser XFS-FAQ-Eintrag. Es kann auch sicher sein, zu Schreibbarrieren abschalten im Kernel, aber das Testen wird empfohlen.
  • Wenn Sie keinen batteriegepufferten RAID-Controller haben, verlangsamt das Deaktivieren des Festplatten-Schreib-Caching die Schreibvorgänge erheblich, macht aber LVM sicher. Sie sollten auch das Äquivalent von ext3 verwenden data=ordered 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 benutze ext4 welche aktiviert standardmäßig Barrieren.) Dies ist die einfachste Option und bietet eine gute Datenintegrität auf Kosten der Leistung. (Linux hat die Standardoption ext3 geändert zum gefährlicheren data=writeback eine Weile zurück, so verlassen Sie sich nicht auf die Standardeinstellungen für die FS.)
  • So deaktivieren Sie das Schreibcache der Festplatte: hinzufügen hdparm -q -W0 /dev/sdX für alle Laufwerke in /etc/rc.local (für SATA) oder verwenden Sie sdparm für SCSI / SAS. Jedoch, gemäß dieser Eintrag In der XFS-FAQ (die zu diesem Thema sehr gut ist) kann ein SATA-Laufwerk diese Einstellung nach einer Laufwerkfehlerwiederherstellung vergessen - also sollten Sie SCSI / SAS verwenden, oder wenn Sie SATA verwenden müssen, dann den Befehl hdparm in einen Cron-Job einfügen läuft jede Minute oder so.
  • Um das Schreib-Caching von SSD / Festplatte zu aktivieren für bessere Leistung: Dies ist ein komplexer Bereich - siehe Abschnitt unten.
  • Wenn Sie verwenden Advanced-Format-Laufwerke 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 wichtig, aber nicht genug, um LVM sicher zu machen: Alles, was einen harten Absturz oder einen Stromausfall verursacht (z. B. Ausfall der USV, Netzteilfehler oder Erschöpfung der Laptopbatterie), kann Daten in Festplattencaches verlieren.
  • Sehr alte Linux Kernel (2.6.x von 2009): In sehr alten Kernelversionen, 2.6.32 und früher, gibt es eine unvollständige Schreibbarrierenunterstützung (2.6.31 hat etwas Unterstützung, während 2.6.33 funktioniert für alle Arten von Gerätezielen) - RHEL 6 verwendet 2.6.32 mit vielen Patches. Wenn diese alten 2.6 Kernel für diese Probleme nicht gepatcht sind, 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 belässt (sagen 32 MB pro Laufwerk für gewöhnliche SATA-Laufwerke). Der Verlust von 32 MB der zuletzt geschriebenen FS-Metadaten und Journaldaten, von denen der Kernel denkt, dass sie sich bereits auf der Festplatte befinden, bedeutet normalerweise eine Menge FS-Korruption und damit Datenverlust.
  • Zusammenfassung: Sie müssen im Dateisystem, RAID, VM-Hypervisor und Festplatten- / SSD-Setup, das mit LVM verwendet wird, vorsichtig umgehen. Sie müssen sehr gute Backups haben, wenn Sie LVM verwenden, und sicherstellen, dass Sie speziell die LVM-Metadaten, den Setup-Bereich für physische Partitionen, MBR- und Volume-Boot-Sektoren sichern. Es ist auch ratsam, SCSI / SAS-Laufwerke zu verwenden, da diese weniger wahrscheinlich darüber sind, wie sie Caching schreiben - es ist mehr Vorsicht geboten, um SATA-Laufwerke zu verwenden.

Schreibcache aktiviert halten für die Leistung (und die Bewältigung der Lügen Laufwerke)

Eine komplexere, aber performante Option besteht darin, das Schreib-Caching von SSDs / Festplatten beizubehalten und sich auf Kernel-Schreibbarrieren zu verlassen, die mit LVM auf Kernel 2.6.33+ arbeiten (überprüfen Sie, indem Sie in den Protokollen nach Barrieren suchen).

Sie sollten auch sicherstellen, dass das RAID-Setup, VM-Hypervisor-Setup und Dateisystem verwendet Schreibbarrieren (d. h. erfordert das Laufwerk, ausstehende Schreibvorgänge vor und nach Schlüsselmetadaten / Journalschreibvorgängen zu löschen). XFS verwendet standardmäßig Barrieren, ext3 jedoch nicht, also mit ext3 solltest du verwenden barrier=1 in den Mount-Optionen und immer noch verwenden data=ordered oder data=journal wie oben.

SSDs sind problematisch, da die Verwendung des Schreibcaches für die Lebensdauer der SSD kritisch ist. Am besten ist es, eine SSD mit einem Superkondensator zu verwenden (um das Leeren des Cache bei Stromausfall zu ermöglichen und somit zu ermöglichen, dass der Cache zurückgeschrieben wird und nicht durchschreibt).

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

  • Mit neueren Advanced-Format-Laufwerke Bei Verwendung von 4 physischen KiB-Sektoren kann es wichtig sein, das Laufwerkschreib-Caching aktiviert zu lassen, da die meisten dieser Laufwerke derzeit logische 512-Byte-Sektoren emulieren ("512 Emulation"), und einige behaupten sogar, physische Sektoren von 512 Byte zu haben, während sie tatsächlich 4 KiB benutzen.
  • Das Deaktivieren des Schreib-Cache eines Advanced-Format-Laufwerks kann eine sehr große Leistungsbeeinträchtigung verursachen, wenn die Anwendung / Kernel 512-Byte-Schreibvorgänge ausführt, da solche Laufwerke darauf angewiesen sind, 8 x 512-Byte-Schreibvorgänge zu akkumulieren, bevor ein einzelnes KiB-physical ausgeführt wird schreiben. Testen wird empfohlen, um Auswirkungen zu bestätigen, wenn Sie den Cache deaktivieren.
  • Ausrichten der LVs an einer 4 KiB Grenze Dies ist wichtig für die Performance, sollte aber automatisch erfolgen, solange die zugrunde liegenden Partitionen für die PVs ausgerichtet sind, da LVM Physical Extends (PEs) standardmäßig 4 MiB sind. RAID muss hier berücksichtigt werden - das LVM- und Software-RAID-Setup-Seite schlägt vor, den RAID-Superblock am Ende des Laufwerks anzubringen und (falls erforderlich) eine Option auf zu verwenden pvcreate um die PVs auszurichten. Dieser LVM-E-Mail-Listen-Thread verweist auf die Arbeit, die in Kernen im Jahr 2011 geleistet wurde, und das Problem der partiellen Blockschreibvorgänge beim Mischen von Platten mit 512 Byte und 4 KiB-Sektoren in einem einzigen LV.
  • GPT-Partitionierung mit erweitertem Format Insbesondere bei boot + root-Festplatten ist Vorsicht geboten, um sicherzustellen, dass die erste LVM-Partition (PV) an einer 4 KiB-Grenze beginnt.

Schwieriger, Daten aufgrund komplexerer Strukturen auf der Festplatte wiederherzustellen:

  • Jede Wiederherstellung von LVM-Daten, die nach einem harten Absturz oder Stromausfall (aufgrund eines inkorrekten Schreib-Cachings) erforderlich ist, ist bestenfalls ein manueller Prozess, da es offensichtlich keine geeigneten Werkzeuge gibt. LVM ist gut darin, seine Metadaten unter zu sichern /etc/lvm, die helfen können, die grundlegende Struktur von LVs, VGs und PVs wiederherzustellen, wird aber nicht mit verlorenen Dateisystem-Metadaten helfen.
  • Daher ist wahrscheinlich eine vollständige Wiederherstellung von der Sicherung erforderlich. Dies bedeutet viel mehr Ausfallzeiten als ein schnelles Journal-basiertes FSCK, wenn LVM nicht verwendet wird, und Daten, die seit dem letzten Backup geschrieben wurden, gehen verloren.
  • TestDisk, ext3grep, ext3undel und andere Werkzeuge  kann Partitionen und Dateien von Nicht-LVM-Festplatten wiederherstellen, unterstützt jedoch nicht direkt die LVM-Datenwiederherstellung. TestDisk kann feststellen, dass eine verloren gegangene physische Partition eine LVM-PV enthält, aber keines dieser Tools die logischen LVM-Volumes versteht. Datei-Schnitzen Werkzeuge wie FotoRec und viele andere würden funktionieren, wenn sie das Dateisystem umgehen, um Dateien aus Datenblöcken wieder zusammenzusetzen, aber dies ist ein low-level resort-Ansatz für wertvolle Daten und funktioniert weniger gut mit fragmentierten Dateien.
  • Eine manuelle LVM-Wiederherstellung ist in einigen Fällen möglich, ist jedoch komplex und zeitaufwendig - siehe Dieses Beispiel und diese, diese, und diese für wie man sich erholt.

Schwieriger, Dateisysteme korrekt zu skalieren - Eine einfache Größenanpassung 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. Dies kann mit dem gesamten Server geschehen, und in einigen Fällen mit FS aber ich würde niemals Letzteres riskieren ohne aktuelle Backups und die Verwendung von Befehlen, die auf einem gleichwertigen Server getestet wurden (z. B. Disaster Recovery Clone des Produktionsservers).

  • Aktualisieren: Neuere Versionen von lvextend unterstütz die -r (--resizefs) -Option - wenn dies verfügbar ist, ist es eine sicherere und schnellere Möglichkeit, die Größe des LV und des Dateisystems zu ändern, besonders wenn Sie den FS verkleinern, und Sie können diesen Abschnitt meistens überspringen.
  • Die meisten Anleitungen zur Größenanpassung von LVM-basierten FS berücksichtigen nicht die Tatsache, dass der FS etwas kleiner sein muss als die Größe des LV: detaillierte Erklärung hier. Wenn Sie ein Dateisystem verkleinern, müssen Sie die neue Größe für das FS-Größenanpassungswerkzeug angeben, z. resize2fs für ext3 und für lvextend oder lvreduce. Ohne große Sorgfalt können sich die Größen aufgrund des Unterschieds zwischen 1 GB (10 ^ 9) und 1 leicht unterscheiden GiB (2 ^ 30), oder die Art, wie die verschiedenen Werkzeuge die Größe nach oben oder unten verändern.
  • Wenn Sie die Berechnungen nicht genau richtig machen (oder einige zusätzliche Schritte über die offensichtlichsten hinaus verwenden), können Sie einen FS erhalten, der für das LV zu groß ist. Alles wird für Monate oder Jahre in Ordnung sein, bis Sie den FS vollständig gefüllt haben. An diesem Punkt werden Sie ernsthafte Korruption erleiden - und wenn Sie sich dieses Problems nicht bewusst sind, ist es schwierig herauszufinden, warum Sie bis dahin tatsächlich Festplattenfehler haben diese Wolke die Situation. (Es ist möglich, dass dieses Problem nur die Größe von Dateisystemen verringert. Es ist jedoch klar, dass die Größenanpassung von Dateisystemen in beide Richtungen das Risiko eines Datenverlusts erhöht, möglicherweise aufgrund von Benutzerfehlern.)
  • Es scheint, dass die LV-Größe größer als die FS-Größe um 2 x die LVM-Größe des physischen Extents (PE) sein sollte - aber überprüfen Sie den Link oben für Details, da die Quelle dafür nicht autorisierend ist. Es ist oft ausreichend, 8 MiB zu erlauben, aber es kann besser sein, mehr zuzulassen, z.B. 100 MiB oder 1 GiB, nur um sicher zu sein. Um die PE-Größe und die Größe Ihres logischen Volumes + FS zu überprüfen, verwenden Sie 4 KiB = 4096 Byte-Blöcke:

    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 blocksize an:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • Im Gegensatz dazu macht ein Nicht-LVM-Setup die Größe des FS sehr zuverlässig und einfach Gparted und die Größe der benötigten FS ändern, dann wird alles für Sie tun. Auf Servern können Sie verwenden parted aus der Schale.

    • Es ist oft am besten, das zu verwenden Gparted Live CD oder Getroffene MagieDa diese einen kürzlichen und oft fehlerfreieren Gparted & Kernel als die Distro Version haben, habe ich einmal einen ganzen FS verloren, weil die Partition nicht korrekt im laufenden Kernel aktualisiert wurde. Wenn Sie die Distribution Gparted verwenden, müssen Sie nach dem Ändern der Partitionen einen Neustart durchführen, damit die Kernel-Ansicht korrekt ist.

Snapshots sind schwer zu verwenden, langsam und fehlerhaft- Wenn der Snapshot nicht mehr im Voraus zugewiesenen Speicherplatz hat, ist es automatisch gelöscht. Jeder Snapshot eines bestimmten LV ist ein Delta gegenüber diesem LV (nicht gegenüber früheren Snapshots), das bei der Erstellung von Snapshots von Dateisystemen mit beträchtlicher Schreibaktivität viel Speicherplatz beanspruchen kann. Es ist sicher, einen Snapshot-LV zu erstellen, der dieselbe Größe wie der ursprüngliche LV hat, da dem Snapshot dann nie mehr freier Speicherplatz zur Verfügung steht.

Snapshots können auch sehr langsam sein (dh 3 bis 6 mal langsamer als ohne LVM für diese MySQL-Tests) - sehen Diese Antwort deckt verschiedene Snapshot-Probleme ab. Die Langsamkeit ist teilweise weil Snapshots erfordern viele synchrone Schreibvorgänge.

Snapshots haben einige signifikante Fehler, z. in manchen Fällen Sie können den Bootvorgang sehr langsam machen oder dazu führen, dass der Bootvorgang vollständig fehlschlägt (weil der Kernel kann Timeout sein  Warten auf den Root-FS, wenn es ein LVM-Snapshot ist [in Debian behoben initramfs-tools Update, Mär 2015]).

  • Eine Metrik ist, dass es viele Debian-Bugs gibt passender "lvm snapshot 2015"einige von ihnen ziemlich ernst - jedoch haben viele Snapshot-Zustand Fehler offensichtlich wurde behoben. LVM ohne Snapshots scheint im Allgemeinen recht gut zu debuggen, vielleicht weil Snapshots nicht so oft verwendet werden wie die Kernfunktionen.

Snapshot-Alternativen - Dateisysteme und VM-Hypervisors

VM / Cloud-Snapshots:

  • Wenn Sie einen VM-Hypervisor oder einen IaaS-Cloud-Anbieter verwenden, sind deren Snapshots (z. B. EBS-Snapshots von VMware, VirtualBox oder Amazon EC2) oft eine viel bessere Alternative zu LVM-Snapshots. Sie können ganz einfach einen Snapshot für Sicherungszwecke erstellen (aber überlegen Sie, ob Sie den FS vor dem Einfrieren einfrieren).

Dateisystem-Snapshots:

  • Snapshots auf Dateisystemebene mit ZFS oder btrfs sind einfach zu verwenden und im Allgemeinen besser als LVM. Obwohl keines der beiden Dateisysteme unter Linux sehr ausgereift ist, sind sie möglicherweise eine bessere Option für Benutzer, die Snapshots benötigen, ohne die VM / Cloud-Route zu verwenden:

Snapshots für Online Backups und fsck

Snapshots können verwendet werden, um eine Konsistenz zu gewährleisten Quelle für Backups, solange Sie mit zugewiesenem Speicherplatz vorsichtig umgehen (idealerweise hat der Snapshot dieselbe Größe wie der zu sichernde LV). Das Ausgezeichnete rsnapshot (seit 1.3.1) verwaltet sogar die Erstellung / Löschung des LVM-Snapshots für Sie - siehe hierzu HOWTO auf rsnapshot mit LVM. Beachten Sie jedoch die allgemeinen Probleme mit Snapshots und dass ein Snapshot nicht als Backup betrachtet werden sollte.

Sie können auch LVM-Snapshots verwenden, um einen Online-Fsck auszuführen: Snapshot des LV und fsck des Snapshots, während weiterhin der Haupt-Non-Snapshot-FS verwendet wird - hier beschrieben - Wie auch immer, es ist nicht ganz unkompliziert also ist es am besten zu benutzen e2croncheck wie von Ted Ts'o beschrieben, Betreuer von ext3.

Du solltest "friere" das Dateisystem ein vorübergehend während des Schnappschusses - einige Dateisysteme wie ext3 und XFS werden mach das automatisch wenn LVM den Snapshot erstellt.

Schlussfolgerungen

Trotzdem benutze ich immer noch LVM auf einigen Systemen, aber für ein Desktop-Setup bevorzuge ich rohe Partitionen. Der Hauptvorteil, den ich von LVM sehen kann, ist die Flexibilität beim Verschieben und Ändern der Größe von FS wenn Sie eine hohe Verfügbarkeit auf einem Server haben müssen - Wenn Sie das nicht benötigen, ist gparted einfacher und hat weniger Risiko von Datenverlust.

LVM erfordert aufgrund von VM-Hypervisoren, Festplatten- / SSD-Schreib-Caching und so weiter große Sorgfalt bei der Schreib-Caching-Konfiguration - dasselbe gilt jedoch auch für die Verwendung von Linux als DB-Server. Der Mangel an Unterstützung durch die meisten Werkzeuge (gparted einschließlich der kritischen Größe Berechnungen und testdisk usw.) macht es schwieriger zu verwenden, als es sein sollte.

Wenn Sie LVM verwenden, achten Sie besonders auf Snapshots: Verwenden Sie VM / Cloud-Snapshots, wenn möglich, oder untersuchen Sie ZFS / btrfs, um LVM vollständig zu vermeiden - Sie können feststellen, dass ZFS oder btrs im Vergleich zu LVM mit Snapshots ausreichend ausgereift ist.

Fazit: Wenn Sie nichts über die oben aufgeführten Probleme wissen und wie Sie diese beheben können, sollten Sie LVM am besten nicht verwenden.


238
2018-06-12 08:19



Online-Größenanpassung mit xfs funktioniert perfekt, Sie müssen nicht einmal die Größe angeben. Es wird auf die Größe des LV wachsen, lesen Sie mehr in xfs_grow (5). OTOH Ich habe +1 für die Zusammenfassung zu Schreibbarrieren getroffen. - cstamas
KUMPEL! Wo warst du mein ganzes Leben lang!? - songei2f
@TREE: Die Idee mit einem batteriegepufferten RAID-Controller ist, dass sein Cache bei Stromausfällen persistent ist und man allgemein davon ausgehen kann, dass er wie dokumentiert funktioniert, während einige Festplatten-Caches darauf beruhen, ob sie tatsächlich einen Block auf Festplatte geschrieben haben Natürlich sind diese Caches nicht persistent. Wenn Sie den Festplattencache aktiviert lassen, sind Sie anfällig für einen plötzlichen Stromausfall (z. B. Netzteil oder UPS versagt), der durch die Batteriepufferung des RAID-Controllers geschützt ist. - RichVel
Eine der besten Antworten, die ich je gesehen habe, jedes Thema. Nur ändern würde ich machen, verschieben Sie die Zusammenfassung an die Spitze der Frage für Menschen mit Aufmerksamkeitsstörungen oder nicht viel Zeit. :-) - Prof. Falken
Nachdem ich alle Kommentare und die letzte Aktualisierung der Antwort vor einem Jahr gelesen hatte, fragte ich mich, ob die Antwort aktualisiert werden könnte, um neue Änderungen in Bezug auf Zuverlässigkeit, Leistung und Benutzerfreundlichkeit zu berücksichtigen. - Luis Alvarado


Ich [+1] diesen Beitrag, und zumindest für mich denke ich, dass die meisten Probleme existieren. Sehen Sie sie, während Sie ein paar 100 Server und ein paar 100 TB Daten laufen lassen. Für mich fühlt sich der LVM2 in Linux wie eine "clevere Idee" an. Wie einige von ihnen erweisen sie sich manchmal als "nicht schlau". I.e. Es hat sich möglicherweise als sehr schlau erwiesen, Kernel und Userspace (lvmtab) nicht getrennt zu haben, da es Korruptionsprobleme geben kann (wenn Sie den Code nicht richtig bekommen).

Nun, nur dass diese Trennung da war aus einem Grund - Die Unterschiede zeigen sich bei der PV-Verlustbehandlung und der Online-Reaktivierung einer VG mit zB fehlenden PVs, um sie wieder ins Spiel zu bringen - Was bei "Original-LVMs" (AIX, HP-UX) ein Kinderspiel wird, verwandelt sich seitdem in LVM2 Der Umgang mit dem Staat ist nicht gut genug. Und erzähl mir nicht mal über Quorum Loss Detection (haha) oder State Handling (wenn ich einen Datenträger entferne, wird dieser nicht als nicht verfügbar markiert. Es ist nicht einmal haben die verdammte Statusspalte)

Re: Stabilität pvmove... warum ist

pvmove Datenverlust

so ein Top-Ranking-Artikel auf meinem Blog, hmmm? Gerade jetzt schaue ich auf eine Diskette, auf der die physischen lvm-Daten immer noch in den Zustand von Mitte-Mitte gehalten werden. Es gab einige Memleaks, denke ich, und die allgemeine Idee, dass es gut ist, Live-Block-Daten aus dem Userspace zu kopieren, ist einfach nur traurig. Schönes Zitat aus der LVM-Liste "scheint wie vgreduce - missing nicht pvmove" Bedeutet in der Tat, wenn eine Festplatte sich während pvmove ablöst, dann ändert sich das lvm Management Tool von lvm in vi. Oh, und es gab auch einen Fehler, bei dem pvmove nach einem Lese- / Schreibfehler des Blocks fortfährt und tatsächlich keine Daten mehr auf das Zielgerät schreibt. WTF?

Re: Schnappschüsse Das CoW wird nicht sicher ausgeführt, indem die NEUEN Daten in den Snapshot-Bereich aktualisiert und dann wieder zusammengeführt werden, sobald Sie den Snap löschen. Das bedeutet, dass Sie während der endgültigen Zusammenführung neuer Daten in das ursprüngliche LV starke IO-Spikes haben und, viel wichtiger, Sie haben natürlich auch ein viel höheres Risiko der Datenbeschädigung, da der Snapshot nicht gebrochen wird, sobald Sie auf das Symbol klicken Wand, aber das Original.

Der Vorteil liegt in der Leistung, da 1 statt 3 geschrieben wird. Das Auswählen des schnellen aber unsafer-Algorithmus ist etwas, was man offensichtlich von Leuten wie VMware und MS erwartet. Auf "Unix" würde ich eher raten, dass Dinge richtig gemacht werden. Ich habe nicht viel Leistungsprobleme gesehen, solange ich den Snapshot-Hintergrundspeicher auf einem anders Festplatte als die primären Daten (und Backup auf eine andere natürlich)

Re: Barrieren Ich bin mir nicht sicher, ob man das LVM vorwerfen kann. Soweit ich weiß, handelte es sich um ein Devon-Mapper-Problem. Aber es kann etwas dafür verantwortlich sein, dass man sich von mindestens Kernel 2.6 bis 2.6.33 nicht wirklich um dieses Problem kümmert AFAIK Xen ist der einzige Hypervisor, der O_DIRECT für die virtuellen Maschinen verwendet. Das Problem war früher, als "loop" verwendet wurde, weil der Kernel immer noch diesen Cache cachen würde. Virtualbox hat zumindest einige Einstellungen um solche Sachen zu deaktivieren und Qemu / KVM scheint generell Caching zu erlauben. Alle FUSE FS haben auch Probleme dort (kein O_DIRECT)

Re: Größen Ich denke, LVM "rundet" die angezeigte Größe ab. 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 richtige Netzgröße geben, und dieses Problem ist immer ein Nutzungsproblem. Es wird von Dateisystemen verschlimmert, die während fsck / mount (hallo, ext3) so etwas nicht bemerken oder kein online funktionierendes "fsck -n" (hallo, ext3) haben

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

Verglichen mit dem Original ist LVM2 das Paradebeispiel für "Diejenigen, die UNIX nicht verstehen, sind dazu 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 werden, blockiert der Snapshot, nicht das ursprüngliche LV. Ich habe mich geirrt, als ich das zum ersten Mal gepostet habe. Ich habe falsche Informationen von einem Arzt geholt, oder vielleicht habe ich es verstanden. In meinen Setups war ich immer sehr paranoid, um sie nicht voll zu machen und so wurde ich nie korrigiert. Es ist auch möglich, Snapshots zu erweitern / verkleinern, was ein Vergnügen ist.

Was ich noch nicht lösen konnte, ist, wie man das Alter einer Momentaufnahme erkennt. Zu ihrer Leistung gibt es einen Hinweis auf der Fedora-Projektseite "Thinp", in der steht, dass die Snapshot-Technik überarbeitet wird, damit sie nicht mit jedem Snapshot langsamer wird. Ich weiß nicht, wie sie es umsetzen.


15
2017-12-11 14:03



Gute Punkte, vor allem beim Datenverlust von pvmove (man merkte nicht, dass dies bei wenig Speicher zum Stillstand kommen könnte) und Snapshot-Design. Auf Schreibbarrieren / Caching: Ich habe LVM und den Kernel-Device-Mapper zusammengelegt, da sie aus Sicht des Benutzers zusammenarbeiten, um zu liefern, was LVM bietet. Upvoted. Gefallen auch Ihre Blog-Posting auf pvmove Datenverlust: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
Auf Snapshots: Sie sind in LVM notorisch langsam, also war es eindeutig keine gute Designentscheidung, die Leistung höher zu setzen als die Zuverlässigkeit. Mit "hit the wall", meinst du, der Snapshot füllt sich, und kann das wirklich zu einer Beschädigung der ursprünglichen LV-Daten führen? Das LVM HOWTO sagt, dass der Snapshot in diesem Fall gelöscht wird: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"Die CoW wird nicht sicher ausgeführt, indem die NEUEN Daten in den Snapshot-Bereich aktualisiert und dann wieder zusammengeführt werden, sobald Sie den Snap löschen." Das ist nur falsch. Wenn neue Daten auf das ursprüngliche Gerät geschrieben werden, wird die alt Version wird in den COW-Bereich des Snapshots geschrieben. Es werden niemals Daten zurückgemischt (außer wenn Sie möchten). Sehen kernel.org/doc/Documentation/device-mapper/snapshot.txt für alle technischen Details. - Damien Tournoud
Hi Damien, beim nächsten Mal einfach weiterlesen bis zu dem Punkt wo ich meinen Beitrag korrigiert habe? - Florian Heigl


Wenn Sie beabsichtigen, Snapshots für Backups zu verwenden, sollten Sie darauf vorbereitet sein, dass ein größerer Performance-Treffer auftritt, wenn ein Snapshot vorhanden ist. Weiterlesen Hier. Sonst ist alles gut. Ich verwende lvm in der Produktion seit einigen Jahren auf Dutzenden von Servern, obwohl mein Hauptgrund, es zu verwenden, der atomare Schnappschuss ist, nicht die Fähigkeit, Volumes leicht zu erweitern.

BTW, wenn Sie 1TB Laufwerk verwenden werden, erinnern Sie sich an Partition Alignment - dieses Laufwerk hat höchstwahrscheinlich 4kB physikalische Sektoren.


12
2018-06-12 09:44



+1 für die Leistungswarnung bei geöffneten Snapshots - Prof. Falken
Meine Erfahrung ist, dass 1-TB-Laufwerke normalerweise 512-Byte-Sektoren verwenden, aber die meisten 2-TB-Laufwerke verwenden 4 KB. - Dan Pritts
@DanPrits schadet nicht, wenn man davon ausgeht, dass die Sektorgröße 4kB oder sogar 128kB beträgt - nur für den Fall, dass es dazwischen einen Raid gibt. Sie verlieren so wenig - vielleicht 128kB und Sie können viel gewinnen. auch beim Bild von der alten Festplatte zu einer neuen. - pQd
Es gibt einen geringfügigen Schaden, um die Dateisystemblockgröße "zu groß" zu machen; Jede Datei ist in nicht weniger als einem einzelnen Block enthalten. Wenn Sie viele kleine Dateien und 128KB-Blöcke haben, wird es sich summieren. Ich stimme jedoch zu, dass 4K ziemlich vernünftig ist, und wenn Sie ein Dateisystem auf neue Hardware verschieben, werden Sie schließlich mit 4k-Sektoren enden. - Dan Pritts
(Lassen Sie mich nicht meinen vorherigen Kommentar bearbeiten) ... Eine Verschwendung von Speicherplatz ist nicht wichtig, aber es wird am Ende Ihre durchschnittliche Suchzeit auf rotierenden Festplatten erhöhen. Es könnte sich bei SSDs möglicherweise in Schreibverstärkung (Ausfüllen des Sektors mit Nullen) verwandeln. - Dan Pritts


Adam,

Ein weiterer Vorteil: Sie können ein neues physisches Volumen (PV) hinzufügen, alle Daten zu dieser PV verschieben und dann die alte PV ohne Serviceunterbrechungen entfernen. Ich habe diese Fähigkeit in den letzten fünf Jahren mindestens vier Mal genutzt.

Ein Nachteil, den ich nicht sehen konnte, wurde noch deutlich herausgestellt: Es gibt eine ziemlich steile Lernkurve für LVM2. Meistens in der Abstraktion erstellt es zwischen Ihren Dateien und den zugrunde liegenden Medien. Wenn Sie nur mit ein paar Leuten arbeiten, die Aufgaben auf einer Reihe von Servern teilen, können Sie die zusätzliche Komplexität für Ihr Team als Ganzes erdrücken. Größere Teams, die sich der IT-Arbeit widmen, werden in der Regel kein Problem haben.

Zum Beispiel verwenden wir es hier bei meiner Arbeit weit und haben sich Zeit genommen, dem ganzen Team die Grundlagen, die Sprache und das Nötigste bei der Wiederherstellung von Systemen beizubringen, die nicht korrekt booten.

Eine Vorsichtsmaßregel, die Sie besonders hervorheben sollten: Wenn Sie von einem logischen LVM2-Volume booten, haben Sie bei einem Serverabsturz die Wiederherstellung erschwert. Knoppix und Freunde haben nicht immer die richtigen Sachen dafür. Also entschieden wir, dass unser Verzeichnis / boot auf einer eigenen Partition sein würde und immer klein und nativ wäre.

Insgesamt bin ich ein Fan von LVM2.


5
2018-06-22 21:03



halten /boot getrennt ist immer eine gute Idee - Hubert Kario
GRUB2 unterstützt das Booten von einem logischen LVM-Volume (siehe wiki.archlinux.org/index.php/GRUB2#LVM) aber GRUB1 nicht. Ich würde immer einen separaten Nicht-LVM / Boot verwenden, nur um sicherzustellen, dass es sich leicht wiederherstellen lässt. Die meisten Rettungsdisketten unterstützen heutzutage LVM - einige benötigen ein Handbuch vgchange -ayum die LVM-Volumes zu finden. - RichVel
auf pvmove: Siehe den Punkt über pvmove Datenverlust in Florian Heigls Antwort. - RichVel