Die großen Kapazitätssteigerungen bei Festplatten in den letzten Jahren haben nicht das Problem der Datenspeicherung vereinfacht, vielmehr wachsen die Datenbestände allenthalben in immer größerem Tempo. Gerade bei sorgsam aufgeteilten Systemen, auf denen Benutzer- und Anwendungsdaten auf verschiedenen Laufwerken gespeichert sind, fehlt es immer wieder an Platz. Der Einbau einer neuen Festplatte hilft nur bedingt - im schlimmsten Fall müssen die Daten je nach verfügbarem Platz ständig hin und her verschoben werden.
Ein Ausweg sind Raid-Systeme, die mehrere Festplatten zu einem Blockdevice zusammenfassen. Zusätzlich bieten sie Ausfallsicherheit. Die Umstellung eines Linux-Systems auf ein Software-Raid-5 ohne Neuinstallation beschreibt der Artikel aus[1]. Damit ist das Linux-System jedoch auf die Größe des Raids zementiert, das Auslagern der Benutzer-Homes oder die Erweiterung durch größere Festplatten erfordert in jedem Fall ein weiteres Raid oder einzelne, dann ungesicherte Festplatten. Die beschriebenen Verteilungsprobleme stellen sich dann erneut.
Mit dem Logical Volume Manager (LVM) gewinnt der Administrator die nötige Flexibilität, um etwa im Betrieb die Gesamtkapazität zu erhöhen oder einzelne Systemteile abzutrennen. Dazu schiebt er das LVM zwischen Dateisystem und Raid ein. Das Besondere eines LVM ist, dass die Größe des Speicherplatzes des Systems zur Laufzeit vergrößert oder verkleinert werden kann - sofern das Dateisystem dies erlaubt. Software-Raid und Logical Volume Manager bilden somit eine gute Kombination aus Hochverfügbarkeit und Skalierbarkeit.
Die Qual der Wahl
Für Linux gibt es zurzeit zwei sehr gute Volume-Manager-Implementationen: Zu-erst den Logical Volume Manager, der seit 1997 von Heinz Mauelshagen entwickelt wird und sich stark an den LVM von HP-UX anlehnt. Die zweite ist das Enterprise Volume Management System (EVMS)[2] von IBM, das seit 2002 unter der GPL steht. Die Entwicklung zweier Volume-Manager hat für einige Diskussionen in der Linux-Gemeinde gesorgt, viele fragen, ob man beide Projekte nicht besser zusammenlegen solle. Für den 2.6er Kernel hat Linus Torvalds entschieden, LVM in der Version 2 (LVM 2) aufzunehmen.
|
|
|
LE
|
Logical Extent
|
|
LV
|
Logical Volume
|
|
LVM
|
Logical Volume Manager
|
|
PE
|
Physical Extent
|
|
PV
|
Physical Volume
|
|
VG
|
Volume Group
|
|
VGDA
|
Volume Group Descriptor Area
|
Parallelentwicklung
IBM entwickelt EVMS dennoch parallel weiter. Der Kasten "Exkurs: EVMS" enthält eine Einführung in dieses umfangreiche Werkzeug, das nicht nur Linux-LVM beherrscht. Ausführlich beschäftigt sich der Artikel jedoch mit dem LVM, der im Kernel 2.4 der meisten Distributionen bereits enthalten ist. Der Plain-vanilla-Kernel 2.4 arbeitet noch mit Version 1 des LVM, zum Umstieg auf LVM 2.00.08 muss das Paket von[3] eingebaut werden. Es enthält neben dem Kernelpatch auch die passende Version der LVM-Administrationsprogramme. Zusätzlich ist das Patch für den Device Mapper von[3] erforderlich.
|
Das Enterprise Volume Management System (EVMS) von IBM besteht aus einem Plugin-Modell, in das sich einzelne Module als Erweiterungen sehr einfach einfügen lassen. Es ist kompatibel zum LVM, integriert Software-Raid (Multiple Devices) und unterstützt die gängigen Linux-Dateisysteme. Auch Bad Block Relocation (BBR) und Cluster Support sind keine Fremdworte für das EVMS.
Das grafische Admin-Interface von EVMS (Abbildung 3) gibt es auch als Textmodus-Variante. Die Terminologie ist etwas anders als beim LVM, so werden zum Beispiel Physical Volumes zu Segments, die Volume Group heißt Containers und hinter dem Begriff Regions verbergen sich die Logical Volumes. Die gute Dokumentation auf der Projekt-Homepage[2] erleichtert den Einstieg.
Abbildung 3: Das EVMS lässt sich per GUI oder über die Textkonsole komfortabel verwalten. Die Bezeichnungen unterscheiden sich jedoch von denen bei LVM.
|
Bei den aktuellen Distributionen ist Suse Linux 9.0 bezüglich Volume-Manager führend: Der Suse-Kernel enthält bereits LVM, LVM 2 und EVMS. Fedora Linux bringt es immerhin auf LVM und LVM 2, bei Red Hat gibt es in der Professional Workstation und Enterprise nur LVM. Die folgenden Beispiele funktionieren mit der LVM-Version 1, die Neuerungen von Version 2 sind im Kasten "Neu in LVM 2" beschrieben.
|
Die drei wesentlichen Änderungen im LVM 2 sind der Device Mapper, das neue Metadatenformat und die Konfigurationsdatei »lvm.conf«. Mit dem Device Mapper ist es möglich, ein neues Blockdevice auf ein existierendes Device aufzusetzen. Das Metadatenformat im LVM 2 ist gegenüber dem alten stabiler und effizienter gestaltet.
Mit der »lvm.conf« hat der Administrator die Möglichkeit, Parameter für die einzelnen Devices einzutragen und das Backup der Metadaten sowie den Umfang der Logfiles anzupassen. LVM 2 ist abwärts kompatibel zur Version 1.x, der Befehl »vgconvert -M2 asterix« konvertiert die Metadaten der Volume Group »asterix« in das neue Format.
|
« Zurück
1
2
3
4
5
Weiter »