- Logical Volume Manager
-
Logical Volume Manager
Der Logical Volume Manager (LVM) ist eine hauptsächlich im Unix- und Linux-Umfeld verbreitete Abstraktionsebene zwischen Festplatten, Partitionen und Dateisystemen. 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 HP-UX und sind von diesem abgeleitet.
Inhaltsverzeichnis
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 Betriebssystemkern 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 Microsoft Windows entspricht dies in etwa den „Dynamischen Datenträgern“, welche seit Windows 2000 verfügbar sind[1].
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ützten 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 klassischem 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 logische 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.
Betriebssysteme mit LVM-Unterstützung
- AIX, HP-UX, Tru64
- 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 so wie 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).
- Solaris
- Ab Solaris Version 9 gehört der SVM (Solaris Volume Manager) 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 Kommandozeile (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 seit 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 „In Vino Veritas“ (Vino ist der Ablativ von Vinum) und heißt wörtlich übersetzt „Im Wein liegt Wahrheit“. [1] [2]
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. Seit 2002 gibt es mit LVM2 ein neues Metadatenformat mit einem Satz zugehöriger neuer Benutzer-Modus-Werkzeuge. Es war zu Beginn der Arbeiten an 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.[2]
Weblinks
- Umfangreiche Anleitung (englisch)
- Anleitung
- LVM2 Resource Page
- Enterprise Volume Management System (EVMS)
- LVM-Workshop zum Selbststudium
Einzelnachweise
Wikimedia Foundation.
