LVM Grundlagen

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

Der Logical Volume Manager (LVM) ermöglicht eine abstrahierte und flexible Verwaltung von Datenspeichern eines Computer-Systems. Gegenüber dem traditionellem Weg über Partitionen wird eine weitere, höhere Abstraktionsschicht eingeführt, die eine einfache und effiziente Verwaltung und Konfiguration der Datenträger ermöglichen soll. So können zum Beispiel mehrere Festplatten zu einem Logical Volume zusammengefasst und als ein gesamter Datenspeicher verwendet werden. Eine weitere Vereinfachung bietet die Möglichkeit der Gruppierung von Logical Volumes in Volume Groups, denen auch Bezeichnungen gegeben werden können. Durch diese Einordnungen und Namensgebungen ensteht für den Administrator auch ein logischer Bezug zu den sich in den Logical Volumes befindlichen Daten.

Dieser Artikel zeigt wie LVM unter Linux implementiert ist.

Physical Volumes (PVs)

Ein PV wird immer durch ein Block-Device repräsentiert - z.B. eine Festplatte (Device) oder eine Partition. Wird eine Partition bzw. ein Device als PV initialistiert, so wird das Block-Device mit einem LVM-Label gekennzeichent und mit Metadaten versehen. Das LVM-Label identifiziert das Block-Device als PV, es beinhaltet den Random Unique Identifier (UUID), es speichert die Größe des Devices in Bytes und es zeichnet auf, wo sich die Metadaten befinden.[1]

Aufbau PV-VG-LV

Die Metadaten werden für die genaue Beschreibung der Konfiguration der Volume Groups benötigt. Standardmäßig wird eine identische Kopie der Metadaten auf den PVs einer VG gespeichert. Beim Anlegen einer PV ist es möglich zu definieren, dass 0,1 oder 2 Kopien von Metadaten gespeichert werden - ist diese Zahl einmal definiert, kann sie nicht mehr geändert werden. Die mehrfache Speicherung der Metadaten soll vor einer irrtümlichen Überschreibung schützen.[2] Auch die Größe des Metadatenbereichs kann beim Anlegen eines PVs geändert werden. Unter Umständen kann dieser Bereich nämlich zu klein werden, was zu Problemen führen kann, da die Größe nachträglich nicht mehr geändert werden kann: LVM VG vgname metadata too large for circular buffer beheben.

Ein PV wird bei der Erstellung in lauter kleine, gleich große Stückchen unterteilt, den sogenannten Physical Extents (PEs).[3] Diese PEs sind die kleinst mögliche Datenmenge, die allokiert werden kann und beträgt standardmäßig 4 MiB, kann aber beim anlegen der darauf aufsetzenden Volume Group geändert werden. Seit dem lvm2-Format ist die Anzahl der PEs nicht mehr beschränkt, laut Man-Page von vgcreate kann eine hohe Anzahl an PEs die bereit gestellten Tools verlangsamen. Die I/O-Performance wird aber nicht beeinträchtigt.

Volume Groups (VGs)

Eine oder mehrerere PVs können zu einer oder mehreren VGs zusammengefasst werden. Diese VG stellt einen Pool an Datenspeicher dar, aus dem später Logical Volumes allokiert werden können. Der verfügbare Speicher einer VG wird dabei in kleine, gleich groß bleibende Teile unterteilt - den Logical Extents. Diese stellen das Pendant zu den PEs auf PV-Ebene dar. Die Aufgabe der VG ist es, die Logical Extents den Physical Extents richtig zuzuordnen. Durch diese Gruppierung in einer Zwischenschicht können auch PEs von unterschiedlichen Devices in einer VG zusammengefasst werden.

Logical Volumes (LVs)

VGs werden in eine oder mehrere LVs aufgeteilt, auf denen anschließend die Dateisysteme aufsetzen. Von LVs können drei verschiedene Arten angelegt werden:

Aufbau eines linearen LVs
  1. Linear Volumes: Eine geordnete Zusammenfassung von PEs zu einem LV. Die Größe der darunter liegenden PVs muss nicht gleich sein, sie werden konsolidiert an die LVs weiter gegeben. Des weiteren muss ein LV nicht zwangsweise aus einer VG bestehen. Es können genauso mehrere LV aus einer VG heraus kreiert werden, solange die VG noch Speicherplatz zur Verfügung stellen kann. Die Größen der erzeugten LV können dabei auch unterschiedlich sein, haben minimal aber die Größe eines PE.
  2. Striped Volumes: Wie bei RAID 0 werden die Daten des LVs abwechselnd auf die die PVs aufgeteilt. Dies kann unter Umständen die Performance erhöhen, nicht aber die Ausfallssicherheit.
    Aufbau eines striped LVs
    Die Abbildung "Aufbau eines striped LV" zeigt, wie die Stripes 1 bis 6 sequentiell auf die darunterliegenden PVs geschrieben werden. Dabei kann es sein, dass einzelne I/O-Operationen parallel getätigt werden können und somit der Schreibvorgang schneller erledigt wird.
  3. Mirrored Volumes: Ähnlich zu RAID 1 werden bei Mirrored Volumes die Daten auf die darunter liegenden Devices gespiegelt. Es können dabei auch mehrere Spiegelungen auf verschiedene, sogenannte "Legs" aufgeteilt werden. Das zu kopierende Device wird dabei in sogenannte "Regions" unterteilt, die bei Änderungen synchronisiert werden. Die Größe dieser Regions ist standardmäßig 512KB, kann aber auch verändert werden.[4]

LVM und Device Mapper

Seit dem Linux Kernel 2.6 ist LVM mithilfe des Device Mappers implementiert. LVM verwendet dabei das linear Device Mapper Target.[5]

Vorteile bei der Verwendung von LVMs[6]

  • Flexible Kapazitäten
    Mehrere Festplatten können zu einem LV zusammengefasst werden.
  • Änderungen der Größe
    LVs können erweitert bzw. verkleinert werden, ohne dass die darunter liegenden Devices neu formatiert oder partitioniert werden müssen.
  • Reallokierung von Daten im laufenden Betrieb
    Daten können im laufenden Betrieb neu angeordnet werden. Dies kann z.B. hilfreich sein, wenn eine hot-swapable Disk getauscht wird.
  • Disk Striping
    Daten können über mehrere Devices verteilt werden ("Gestriped"), was die Performance erhöhen kann, aber nicht zur Ausfallssicherheit beiträgt.
  • Data Mirror
    Daten können einfach gespiegelt werden.
  • Volume Snapshots
    Es können von einem Device Snapshots erstellt werden, z.B. um von den Snapshots Sicherungen zu erstellen

Nachteile bei der Verwendung von LVMs[7]

  • Liegen die Daten verteilt auf verschiedenen Devices ("Striping"), so erhöht sich die Gefahr eines Ausfalls der Platten. Dies ist kann nur bedingt als Nachteil von LVM selbst angesehen werden, da es sich eigentlich um eine Designentscheidung beim Aufbau der Speicherarchitektur handelt.
  • Um Zugriff auf die Daten über Live-CDs zu erhalten müssen diese die Verwaltung von LVMs unterstützen. Grundsätzlich wird zur Zeit der Zugriff auf LVMs nur von Linux unterstützt.
  • Die alte Grub-Version konnte nicht auf LVM's benutzt werden, es war daher eine eigene, nicht-LVM boot-Partition nötig. GRUB 2 verlangt dies nicht mehr.[8]

Anleitungen und Konfigurationen

Folgende Webseiten sind unter anderem sehr bei der Einrichtung und Konfiguration von LVMs hilfreich:

Im Einzelfall muss überprüft werden mit welchen LVM-Tools gearbeitet wird, da LVM stetig weiterentwickelt wird. Es kann daher sein, dass neue Features vorgestellt werden, die in den älteren Versionen noch nicht vorhanden sind. Welche LVM-Version aktuell installiert ist, kann wie folgt herausgefunden werden:

root@ubuntu:~# lvm version   
  LVM version:     2.02.54(1) (2009-10-26)  
  Library version: 1.02.39 (2009-10-26)
  Driver version:  4.15.0

Einzelnachweise

Foto Georg Schönberger.jpg

Autor: Georg Schönberger

Georg Schönberger, Abteilung DevOps bei der XORTEX eBusiness GmbH, absolvierte an der FH OÖ am Campus Hagenberg sein Studium zum Bachelor Computer- und Mediensicherheit, Studium Master Sichere Informationssysteme. Seit 2015 ist Georg bei XORTEX beschäftigt und arbeitet sehr lösungsorientiert und hat keine Angst vor schwierigen Aufgaben. Zu seinen Hobbys zählt neben Linux auch Tennis, Klettern und Reisen.


Das könnte Sie auch interessieren

LVM Grundkonfiguration
LVM Snapshot Merge
LVM Volume group vgname metadata is inconsistent beheben