Logical Volume Manager

Logical Volume Manager

Beschreibung

Logical Volume Manager

https://www.instagram.com/p/C5-4fF_AqmX/

Der Logical Volume Manager (LVM) ist ein hauptsächlich im Unix- und Linux-Umfeld verbreitetes Partitionsschema, das eine Abstraktionsebene zwischen Festplatten, Partitionen und Dateisystemen bietet

• Durch den LVM ist es möglich, dynamisch veränderbare Partitionen (Logical Volumes, kurz LV) zu bilden, die sich auch über mehrere Festplatten hinweg erstrecken können
• Die Größe dieser virtuellen Datenträger lässt sich auch nach dem Anlegen eines Dateisystems noch ändern,

selbst wenn schon Daten darin gespeichert wurden

Sowohl der Name LVM als auch die Implementierung unter Linux haben ihren Ursprung bei AIX und sind von diesem abgeleitet

• Es wurde später Teil von OSF/1 und andere haben es dann ebenfalls übernommen

Softwarearchitektur

Der Ausdruck „Manager“ ist leicht irreführend, denn der Logical Volume Manager besteht im Wesentlichen aus zwei Komponenten: einer Verwaltungsebene (dem Manager) mit CLI und/oder GUI sowie einem in den Kernel integrierten Treiber, welcher die eigentliche Implementierung realisiert

• Der LVM fasst Festplatten beziehungsweise Partitionen (Physical Volume, PV) zu einem Pool (Volume Group, VG) zusammen, aus dem dynamisch LV-„Partitionen“ (die Logical Volumes, LV) angefordert werden können
• Auf diesen Logical Volumes werden die Dateisysteme angelegt
• Unter Windows entspricht dies in etwa den „Dynamischen Datenträgern“, welche seit Windows 2000 verfügbar sind.

Eine Volume Group kann durch Hinzufügen von Physical Volumes erweitert werden, und Logical Volumes können sich innerhalb der Volume Group über mehrere Physical Volumes erstrecken

• Somit kann ein Logical Volume um ein Vielfaches größer sein als die größte im System vorhandene Festplatte

Die wichtigsten Vorteile des LVM gegenüber der traditionellen statischen Partitionierung von Festplatten liegen in der Möglichkeit, ein Dateisystem nachträglich vergrößern zu können

• Hierzu werden die auch nachträglich erweiterbaren Volume Groups durch Hinzufügen von Physical Volumes (Festplatten) erweitert
• Der nun zusätzlich verfügbare Speicherplatz kann anschließend bedarfsgerecht den ebenfalls nachträglich erweiterbaren Logical Volumes zugeteilt werden
• Anschließend muss das Dateisystem um den neu verfügbaren Speicherplatz erweitert werden – wobei das nicht bei allen Dateisystemen ohne Probleme nachträglich möglich ist
• Unter den meisten Betriebssystemen ist die Vergrößerung eines Logical Volumes und des darauf angelegten Dateisystems auch im laufenden Betrieb möglich, ohne dass darauf laufende Applikationen durch die Vergrößerung beeinträchtigt werden

Grundsätzlich ist es nicht erforderlich, den genauen Überblick darüber zu behalten, auf welchen Physical Volumes ein Logical Volume zu liegen kommt, denn die Verteilung auf die Physical Volumes innerhalb einer Volume Group wird vom LVM automatisch vorgenommen

• Bei leistungskritischen Anwendungen kann jedoch darauf geachtet werden, dass simultane Plattenzugriffe auf verschiedene Physical Volumes verteilt werden, um die Bewegung der Schreib- und Leseköpfe zu optimieren
• Darüber hinaus ist es in der Praxis üblich, die Verteilung so zu steuern, dass ein Logical Volume sich nicht auf zu viele Physical Volumes verteilt
• So können die Auswirkungen eines Festplattenausfalls begrenzt werden
• LVMs besitzen üblicherweise entsprechende Befehle, um die Verteilung der Daten auf den Physical Volumes im laufenden Betrieb zu prüfen und zu ändern

RAID-Unterstützung durch den LVM

Viele LVMs unterstützen die Organisation der Logical Volumes als RAID-Verbund, sodass die Daten gegen Plattenausfälle geschützt werden können oder der Zugriff beschleunigt wird

• In der Regel implementieren die Betriebssystemhersteller dazu lediglich gemeinsame Verwaltungsfunktionen, welche die weitestgehend unabhängig voneinander arbeitenden Volume Manager und Software-Raid-Implementierungen steuern
• Die Bezeichnung Software-RAID (auch SoftRAID) rührt daher, dass dieses Verfahren ohne zusätzliche Hardware arbeitet
• Je nach System werden typischerweise RAID 0 (Striping, kein Schutz gegen Plattenausfälle) und RAID 1 (Mirroring, Spiegeln) unterstützt
• In einigen versierteren Implementierungen unterstützen die LVMs auch RAID 5 (Redundanz durch Paritätsbildung)
• Da Letzteres auch nennenswert Rechenkapazität benötigt, kommt es nur bei ausreichend ausgestatteten Systemen in Frage
• In einigen Systemen (z. B. HP-UX oder Linux) sind Software-RAID und LVM optionale Erweiterungen und können völlig unabhängig voneinander installiert und genutzt werden
• Manche Hersteller lizenzieren daher Volume-Management und RAID (Mirroring und/oder RAID 5) auch separat

Eine bemerkenswerte andere, aber zum Teil auch kritisierte Herangehensweise zeigen das in Solaris integrierte ZFS sowie das freie btrfs

• Beide implementieren in einem Guss eine Zusammenfassung aus hochentwickeltem Dateisystem mit LVM und Software-RAID
• Das in das Dateisystem integrierte RAID-Subsystem bietet gegenüber klassischen Hardware- oder Software-RAID-Implementierungen beispielsweise den Vorteil, dass durch das integrierte RAID-System zwischen belegten und freien Datenblöcken unterschieden werden kann und somit bei der Rekonstruktion eines RAID-Volumes nur belegter Plattenplatz gespiegelt werden muss, hieraus resultiert im Schadensfall, besonders bei wenig gefüllten Dateisystemen, eine enorme Zeitersparnis

Abgrenzung von LVM und RAID

Die Arbeits- und Wirkungsweise eines Logical Volume Managers wird oft mit der eines RAID-Systems vermischt

• Dabei gibt es eine klare Abgrenzung
• Echte RAID-Systeme bieten immer (bis auf RAID-0) Redundanz und verfügen folglich immer über eine RAID-Engine, welche die zusätzlichen, für die Redundanz benötigten Datenströme erzeugt
• Die häufigsten Engine-Varianten sind bei RAID 1 die Datenduplizierung und bei RAID 5 und den meisten anderen Verfahren die XOR-Bildung
• Es werden bei RAID also immer zusätzliche Daten in erheblichem Umfang erzeugt, der Datendurchsatz der RAID-Engine ist folglich ein wichtiger Performancefaktor

Aufgabe eines LVMs ist es, physische Volumes auf logischen abzubilden

• Einer der häufigsten Anwendungsfälle ist das nachträgliche Vergrößern von Partitionen und Dateisystemen, die durch den LVM verwaltet werden
• Ein LVM erzeugt dabei aber keine zusätzlichen Datenströme; er hat auch keine Engine und bietet daher auch keine Redundanz, somit erzeugt er auch nur minimalen Rechenaufwand
• Daher hat er praktisch keinen Einfluss auf die Performance (wenngleich auch einige Systeme in die LVM-Implementierung integrierte RAID-0-Erweiterungen besitzen)
• Die Aufgabe des LVMs besteht also im Wesentlichen darin, die Datenströme aus den Dateisystemen auf die jeweils zugehörigen physischen Datenträger zu verteilen, sie ähnelt am ehesten der Arbeitsweise einer MMU
• Ein RAID-System verteilt zwar ebenfalls Datenströme, es erzeugt aber aus Redundanzgründen auch immer einen oder mehrere zusätzliche Datenströme

Physical und Logical Extents

Der Physical Extent (implementationsabhängig auch: Physical Partition) ist die Speichereinheit, in der die Daten der Volume Group organisiert werden

• Die Größe eines Logical Volume entspricht immer dem Vielfachen der Größe eines Physical Extent in der Volume Group

Der Logical Extent (implementationsabhängig auch: Logical Partition) fasst bei LVMs, die die Spiegelung von Logical Volumes auf mehreren Festplatten unterstützen, die Anzahl der Spiegel zusammen

• Liegen zwei Spiegelhälften vor, entspricht ein Logical Extent zwei Physical Extents
• Bei LVM-Implementationen, die keine Spiegelung unterstützen, entspricht ein Logical Extent immer genau einem Physical Extent

Snapshots

Einige Implementierungen unterstützen Snapshots

• Dabei handelt es sich um ein Logical Volume, welches an ein weiteres Logical Volume angehängt wird
• Bevor Änderungen an einer Datei auf das Logical Volume geschrieben werden wird eine Kopie der Datei im Snapshot Logical Volume angelegt
• Erst dann werden die Änderungen in die Datei des eigentlichen Logical Value geschrieben
• Dadurch ist es leicht Änderungen in Dateien rückgängig zu machen
• Ist man mit den Änderungen an der Datei zufrieden dann löscht man einfach die Kopie im Snapshot Logical Volume. Natürlich haben Snapshots ihren Preis
• Snapshots können die Performanz eines Systems erheblich beeinflussen. Ein Snapshot Logical Volume kann jederzeit wieder gelöscht werden
• Mit dem Befehl „lvconvert --merge“ können die beiden Logical Volumes wieder zusammengefasst werden
• Manchmal ist ein reboot dafür notwendig
• Das ist praktisch wenn man mit Layouts experimentieren will.

Betriebssysteme mit LVM-Unterstützung

AIX, HP-UX, Tru64 UNIX

Komplette LVM-Unterstützung mit Spiegelung und Online-Vergrößerung von Logical Volumes

• Letztere sind unter HP-UX (MirrorDisk UX, OnlineJFS) und Tru64 (AdvFS, LSM) zusätzlich lizenzpflichtig

Linux

LVM-Implementation (1998 von Heinz Mauelshagen geschrieben), die sich in der Bedienung stark an HP-UX anlehnt

• Eine Online-Vergrößerung ist unter anderem mit folgenden Dateisystemen möglich: ext2, ext3, und ext4, JFS, ReiserFS v3 sowie mit XFS
• Ebenfalls ist die Spiegelung der Logical Volumes möglich und unabhängig vom verwendeten Dateisystem
• Neben der LVM-Implementierung von Red Hat (ehemals Sistina) gibt es mit EVMS auch eine Implementierung von IBM, die über LVM hinaus auch fast alle anderen Massenspeicheraufgaben unterstützt (Partitionierung, RAID, Dateisystemverwaltung)
• Seit Kernel 2.6 setzt LVM auf dem Device Mapper auf

Solaris

1991 wurde für SunOS die Online DiskSuite (ODS) als Zusatzprodukt vorgestellt, welches dann in Solstice DiskSuite (SDS) umbenannt wurde

• Ab Solaris 8 wurde der Name nochmals zu Solaris Volume Manager (SVM) geändert und gehört seitdem zum Betriebssystem
• Ab Solaris 10 kann auch ZFS Pooled Storage verwendet werden
• ZFS implementiert eine Zusammenfassung aus hochentwickeltem Dateisystem mit LVM und Software-RAID aus einem Guss
• Damit werden Platten oder Plattenbereiche einem Storage Pool zugeordnet
• Die Dateisysteme (ZFS) werden direkt in diesem Storage Pool angelegt
• Storage Pool und Dateisysteme sind dynamisch erweiterbar

IRIX

Sowohl der alte XLV als auch der neue XVM LVM werden mit IRIX 6.5 ausgeliefert, jedoch ist für das Einrichten von Spiegeln eine zusätzliche Lizenz (Plexing Licence) notwendig

OS/2, eComStation

Mit der Einführung des JFS im Jahr 2000 wurde gleichzeitig ein LVM eingeführt

• Die Verwaltung kann über eine Befehlszeile (CLI) oder über eine Grafische Benutzeroberfläche (GUI) stattfinden
• Die OS/2-Portierung von JFS war die Basis für JFS2.

Windows 2000 und höher

Hier entspricht das logische Volume Management in etwa der Verwaltung von Dynamischen Datenträgern

• Das werksseitig in alle neuere Versionen integrierte logische Volume Management setzt das Dateisystem NTFS voraus
• Es unterstützt die Spiegelung sowie die Online-Vergrößerung von Logical Volumes, die der Hersteller abweichend als Dynamische Datenträger bezeichnet

FreeBSD, NetBSD, OpenBSD

Vinum bzw. Gvinum ist ein LVM, der vom Veritas Volume Manager inspiriert wurde, aber nicht darauf basiert

• Entwickelt wurde er anfangs für FreeBSD und gehört ab Version 3.0-RELEASE zu dessen Lieferumfang; inzwischen gibt es auch NetBSD- und OpenBSD-Versionen
• Unterstützt werden die Raid-Levels 0, 1, 5, und JBOD
• Der Name leitet sich vom lateinischen Sprichwort ‚Vorlage:Lang‘ (Vino ist der Ablativ von Vinum) und heißt frei übersetzt „Im Wein liegt Wahrheit“.

macOS

Seit Mac OS X Lion ist ein LVM unter dem Namen CoreStorage implementiert

• Anfangs wurde nur Apples FileVault (2
• Generation) zur gesamten Festplattenverschlüsselung unterstützt. Für OS X Mountain Lion wurde CoreStorage um Unterstützung für Tiering erweitert
• Apples sogenanntes Fusion Drive verbindet dadurch eine SSD und eine Festplatte zu einem logischen Laufwerk, bei dem die SSD als Pufferspeicher verwendet wird.

Sonstige LVM-Unterstützung

Veritas Volume Manager

Unterstützung verschiedener Betriebssysteme wie HP-UX, Linux, Solaris und Windows inklusive eines kommandozeilenorientierten sowie eines graphischen Interfaces

• Veritas bietet zudem einen Cluster Volume Manager an, der logisches Volume Management in Clustern ermöglicht
• Beide Volume Manager sind lizenzpflichtig

Oracle Automatic Storage Management (ASM)

Unterstützung von Logical Volumes für Oracle-Datenbanken inklusive Disk Striping und Mirroring

• Die Verteilung der Daten in sogenannten Stripes erfolgt dabei nicht aufgrund der Datenmenge, sondern nach I/O-Last
• Diese Last wird über ein internes Repository (Automatic Workload Repository, kurz AWR) gespeichert und ausgewertet
• ASM wird kostenfrei mit der Oracle-Datenbanksoftware zur Verfügung gestellt

Geschichte

Für Linux-Betriebssysteme gibt es LVM-Implementierungen seit 1997

• Das erste LVM für Linux wurde von Heinz Mauelshagen von der Sistina Software geschrieben
• Als Vorlage diente ihm die Implementierung von HP-Unix

Seit 2002 gibt es mit LVM2 ein neues Metadatenformat mit einem Satz zugehöriger neuer Kommandozeilenprogramme Es war zu Beginn der Arbeiten am Kernel-Versionszweig 2.5 neben dem Enterprise Volume Management System (EVMS) von IBM eine zweite Implementierung eines LVM, die schließlich für Kernel 2.6 übernommen wurde

• EVMS bietet jedoch weitergehende Fähigkeiten und lebte danach ohne die eigenen Kernel-Teile als ein Benutzer-Modus-Frontend zu LVM2 weiter und wurde 2006 schließlich aufgegeben.

Anhang

Siehe auch

• Logical Volume Manager

Links

Weblinks

1. https://de.wikipedia.org/wiki/Logical_Volume_Manager
2. Umfangreiche Anleitung (englisch, aber leider sehr veraltet)
3. LVM2 Resource Page
4. Enterprise Volume Management System (EVMS)
5. Einführung in LVM (ADMIN-Magazin)