LVM Gefahren und Vorbehalte

189

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?

Adam Matan
quelle
19
Beachten Sie beim Lesen der Antworten auf diese Frage das Datum (Jahr), an dem sie veröffentlicht wurden. In 3 Jahren passiert in dieser Branche viel.
MattBianco
2
Ich habe kürzlich (im April 2015) einige Updates durchgeführt, um festzustellen, ob sich etwas geändert hat. Der 2.6er Kernel ist mittlerweile veraltet, SSDs sind häufiger, aber abgesehen von einigen kleinen LVM-Korrekturen hat sich nicht viel geändert. Ich habe ein paar neue Artikel über die Verwendung von VM / Cloud-Server-Snapshots anstelle von LVM-Snapshots geschrieben. Der Status des Schreibcaches, der Größenänderung des Dateisystems und der LVM-Snapshots hat sich meines Erachtens kaum geändert.
RichVel
1
In Bezug auf den Kommentar "Denken Sie an das Datum" - stimmt, aber bedenken Sie auch, dass viele "Unternehmen" immer noch RHEL 5 und RHEL 6 verwenden, die beide auf dem neuesten Stand oder älter als das Datum sind der Antwort
JDS

Antworten:

252

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.

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).

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):

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.

RichVel
quelle
4
Die Online-Größenänderung mit xfs funktioniert einwandfrei, Sie müssen nicht einmal die Größe angeben. Es wird auf die Größe des LV anwachsen. Lesen Sie mehr in xfs_grow (5). OTOH Ich habe +1 für die Zusammenfassung der Schreibbarrieren erreicht.
cstamas
2
KUMPEL! Wo warst du mein ganzes Leben lang!?
songei2f
2
@TREE: Die Idee mit einem batteriegepufferten RAID-Controller ist, dass sein Cache bei Stromausfällen dauerhaft ist und im Allgemeinen als dokumentiert funktioniert, wohingegen einige Festplatten-Caches darüber lügen, ob sie tatsächlich einen Block auf die Festplatte geschrieben haben und von Natürlich sind diese Caches nicht persistent. Wenn Sie den Festplatten-Cache aktiviert lassen, sind Sie anfällig für einen plötzlichen Stromausfall (z. B. Ausfall des Netzteils oder der USV), der durch die Batteriesicherung des RAID-Controllers geschützt wird.
RichVel
6
Eine der besten Antworten, die ich je gesehen habe, egal zu welchem ​​Thema. Nur ändern würde ich machen, Zusammenfassung an die Spitze der Frage für diejenigen mit Aufmerksamkeitsdefizitstörung oder nicht viel Zeit bewegen. :-)
Prof. Falken
3
Gegebenenfalls habe ich Korrekturen / Aktualisierungen von vorhandenen Kommentaren hinzugefügt. Ich habe LVM in letzter Zeit noch nicht so oft verwendet, kann mich aber nicht erinnern, dass ich größere Änderungen auf der Grundlage von LWN.net-Geschichten gesehen habe, die solche Dinge ziemlich genau nachverfolgen. ZFS unter Linux ist jetzt ausgereifter (aber immer noch besser unter FreeBSD oder Solaris), und btrfs ist immer noch weit von der tatsächlichen Produktionsreife entfernt, obwohl es von einigen Linux-Distributionen verwendet wird. Daher sehe ich derzeit keine Änderungen, die berücksichtigt werden müssen, aber ich höre gerne zu!
RichVel
15

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.

Florian Heigl
quelle
Gute Punkte, besonders beim pvmove-Datenverlust (wusste nicht, dass dies bei wenig Speicher zum Absturz führen kann) und beim Snapshot-Design. Zu Schreibbarrieren / Caching: Ich habe LVM und den Kernel Device Mapper zusammengeführt, da sie aus Anwendersicht zusammenarbeiten, um das zu liefern, was LVM bietet. Upvoted. Hat auch Ihren Blog-Eintrag zu pvmove data loss gefallen
RichVel
Schnappschüsse: Sie sind in LVM notorisch langsam, daher war es offensichtlich keine gute Designentscheidung, Leistung vor Zuverlässigkeit zu wählen. Meinten Sie mit "hit the wall", dass sich der Schnappschuss füllt, und kann das wirklich zu einer Beschädigung der ursprünglichen LV-Daten führen? Das LVM-HOWTO besagt, dass der Snapshot in diesem Fall gelöscht
RichVel
5
"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." Das ist einfach falsch. Wenn neue Daten auf das Originalgerät geschrieben werden, wird die alte Version in den COW-Bereich der Snapshots geschrieben. Es werden nie wieder Daten zusammengeführt (außer wenn Sie möchten). Unter kernel.org/doc/Documentation/device-mapper/snapshot.txt finden Sie alle wichtigen technischen Details.
Damien Tournoud
Hallo Damien, das nächste Mal einfach weiterlesen bis zu dem Punkt, an dem ich meinen Beitrag korrigiert habe?
Florian Heigl
12

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.

pQd
quelle
+1 für eine Leistungswarnung für offene Snapshots.
Prof. Falken
Nach meiner Erfahrung verwenden 1-TB-Laufwerke normalerweise 512-Byte-Sektoren, die meisten 2-TB-Laufwerke jedoch 4 KB.
Dan Pritts
@DanPritts es ist kein Schaden anzunehmen, dass die Sektorgröße 4kB oder sogar 128kB beträgt - nur für den Fall, dass es dazwischen einen Überfall gibt. du verlierst so wenig - vielleicht 128kB und du kannst viel gewinnen. auch beim Imaging von der alten auf eine neue Festplatte.
pQd
1
Es kann geringfügig schaden, Dateisystemblöcke zu "groß" zu machen. Jede Datei ist in nicht weniger als einem Block enthalten. Wenn Sie viele kleine Dateien und 128-KB-Blöcke haben, summiert sich dies. Ich stimme zu, dass 4K durchaus vernünftig ist, und wenn Sie ein Dateisystem auf neue Hardware umstellen, werden Sie schließlich 4K-Sektoren haben.
Dan Pritts
1
(Ich kann meinen vorherigen Kommentar nicht bearbeiten.) ... Platzverschwendung spielt zwar keine Rolle, erhöht jedoch Ihre durchschnittliche Suchzeit auf sich drehenden Festplatten. Dies kann möglicherweise zu einer Schreibverstärkung (Ausfüllen des Sektors mit Nullen) auf SSDs führen.
Dan Pritts
5

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.

Mike Diehn
quelle
2
hält /bootgetrennt ist immer eine gute Idee
Hubert Kario
3
GRUB2 unterstützt das Booten von einem logischen LVM-Volume (siehe wiki.archlinux.org/index.php/GRUB2#LVM ), GRUB1 jedoch nicht. Ich würde immer ein separates Nicht-LVM / Boot verwenden, um sicherzustellen, dass es einfach wiederherzustellen ist. Die meisten Rettungsdisketten unterstützen heutzutage LVM - einige erfordern ein Handbuch vgchange -ay, um die LVM-Volumes zu finden.
RichVel
1
auf pvmove: siehe den punkt über pvmove datenverlust in der antwort von florian heigl.
RichVel