So außerordentlich praktisch sich der Logical Volume Manager auf einem Fileserver auch macht, bringt sein Einsatz für den Admin doch einige Schwierigkeiten mit sich. Sie reichen von Performanceproblemen über Platzverschwendung bis zum spontanen Datenverlust.

Admins, die auf ihren Servern LVM einsetzen, erhalten für den Mehraufwand beim Setup eine gute Entschädigung: Dank der LVM-Abstraktionsschicht jonglieren sie sehr frei mit logischen Massenspeichern, ohne die darauf aufsetzenden Applikationen zu irritieren. Wildes Herumkopieren zwischen den Server-Festplatten sollte mit den logischen Volumes der Vergangenheit angehören.

Aktuell ist der LVM 2 [1], der einen Device-Mapper im Kernel, die passende Support-Library Libdevmapper und die LVM-2-Tools voraussetzt [2]. Leider spannt LVM für seine Benutzer auch ein paar üble Fallstricke aus, dieser Praxisartikel beschreibt Umgehungsstrecken.

Falle 1: Anlegen von großen Volume Groups

Wer je den LVM 1 mit großen Datenbeständen betraute, hat wahrscheinlich den ersten Fallstrick schon berührt: Der Standardwert für die PE-Größe (Physical Extent Size) steht auf 4 MByte. Damit sind nur etwa 256 GByte adressierbar. Als LVM 1 noch im besten Alter war, stellte diese Begrenzung kein praktisches Problem dar. Heute, in den Zeiten von Terabyte-Datenbanken und -fileservern, sieht der geneigte Admin das Limit nicht mehr so theoretisch.

Glücklicherweise gilt für LVM 2 die Grenze nicht in dieser Schärfe. Trotzdem – und das ist der eigentlich interessante Punkt – sollte der Admin die PE-Größe auch heutzutage noch ändern, wenn er Volume-Größen von mehr als 256 GByte anpeilt. Der Grund dafür ist, dass die LVM-2-Tools bei sehr großen Volumes in Kombination mit der Standard-PE-Größe von 4 MByte unzumutbar lange brauchen, um ihre Arbeit zu verrichten.

Falle 2: Booten vom LV geht meist schief

Wer beim Systemstart von einer Initrd Gebrauch macht – und wer tut das nicht – und dabei die »/boot«-Partition aufs LV packt, stellt beim ersten Start des Systems fest, dass er auf keine glorreiche Idee verfallen ist. Denn nur mit geladener »initrd« kann das System logische Volumes ansprechen, und die liegt traditionell in »/boot«, also im LVM.

Darum ist es ungleich besser, »/boot« auf eine separaten Partition zu legen – für Verfügbarkeitsfreunde: auf einen Raid-Spiegel. Das macht übrigens auch Kernelupdates für den LVM unkritisch. Schusseligkeit des Admin kann trotzdem für viel Verdruss sorgen, etwa wenn er den brandneuen Kernel ohne LVM-Support übersetzt oder vergessen hat, die »initrd« neu zu erstellen. Kurz und klar: »/boot« gehört nicht auf ein logisches Volume.

Falle 3: Swap auf LV kostet Performance

Das Gleiche gilt auch für die Swap-Partition. Im Unterschied zur »/boot«-Falle implodiert zwar nicht gleich das ganze System, aber oft ist die Performance alles andere als zufrieden stellend. Grund dafür: Der Kernel schreibt bei einer klassischen Swap-Partition alle Daten nahe beieinander auf die Festplatte. Beim LV sind sie dagegen über mehrere Zonen der Platte verteilt – die Zugriffe sind entsprechend lahm.

Über die Frage übrigens, ob es sinnvoll ist, das Root-Verzeichnis »/« auf ein logisches Volume zu legen, gibt es unterschiedliche Ansichten. Rein technisch spricht nichts dagegen.

Falle 4: Misslungene Rettungsaktionen mit CD

Eine Live-CD ist ein Schweizer Taschenmesser, obwohl er es selten braucht, hat es der Admin immer zur Hand. Gerade wenn mal wieder eine Festplatte überraschend gestorben ist (der Kollege kommt rein: “Moin, die »/dev/sdf« auf Proxy 3 hat gerade den Kurt Cobain gemacht”, [4]), ist die Live-CD der Retter. Es muss allerdings schon die richtige sein.

Das ansonsten von den Autoren dieses Artikels sehr geschätzte Knoppix 3.8 sorgt als Rettungssystem für betretene Mienen, denn ihm fehlt der LVM-2-Support. Besser schneidet beispielsweise die Gentoo-Live-CD ab. Ihr Werkzeugkasten für Reparaturen am LVM und Soft-Raid ist vollständig. So ausgestattet verliert eine Root-Partition auf dem LV ihren Schrecken – fast, denn da ist noch der fünfte Fallstrick.

Falle 5: Fehler bei der Wahl des Dateisystems

Der Nutzen logischer Volumes liegt in der Flexibilität. Ein besonders gutes Beispiel dafür ist die Möglichkeit, mit LVM Volumes dynamisch zu verkleinern und zu vergrößern. Nebenbei bietet dieses Feature für den Admin auch Gelegenheit, sich sauber in den Fuß zu schießen. Besondere Voraus- und Umsicht erfordert das dynamische Verkleinern.

Das Schrumpfen hat beispielsweise bei einer Root-Partition Sinn, bei der der Admin gerade Teilen wie »/var« oder »/opt« eigene Partitionen spendiert hat. Anschließend ist »/« meist viel zu groß, eine Verkleinerung drängt sich auf. Das gewählte Filesystem muss dazu aber online verkleinerbar sein. Ist das nur offline möglich, müsste der Admin »/« unmounten, was den laufenden Betrieb zum sofortigen Stillstand bringt.

Schlimmer ist dran, wessen Filesystem weder online noch offline verkleinerbar ist, da er der Plattenplatzverschwendung dann keinen Einhalt bieten kann. Das Wichtigste in Kürze:

• Ext 3 ist ein Tausendsassa, der Admin kann es online wie
  offline vergrößern und verkleinern.
• Reiser-FS lässt sich zwar online vergrößern,
  aber nur offline verkleinern.
• XFS und JFS sind online vergrößerbar, schrumpfen
  aber nicht, weder on- noch offline.

Ergo: Es ist kein Problem, »/« auf ein LV zu legen, wenn das Filesystem nachträgliche Schönheitskorrekturen gestattet und für den Notfall ein Erste-Hilfe-Koffer mit LVM-Pflaster zur Verfügung steht.

Abbildung 1: Die vom LVM 1 geerbte 4-MByte-Grenze der Physical Extent Size führt bei Volumes jenseits 256 GByte zu Geschwindigkeitsverlusten.

Falle 6: Mit dem falschen Tool geht das Restore schief

Jeder Admin hat fürs Backup sein Lieblingswerkzeug. Dagegen ist auch nichts einzuwenden, wenn es nicht nur beim Sichern, sondern auch beim Restore gut arbeitet. Denn ist eine Wiederherstellung nötig, regiert in aller Regel Stress die Szenerie, den eine zickige Software nicht noch verstärken soll.

Um solchen Ärger zu vermeiden, muss der Admin gleich nach der Installation des Backupprogramms klären, ob die Restorefunktion darauf ausgelegt ist, sowohl mit dem gewählten Filesystem als auch mit logischen Volumes zurechtzukommen. Ist das nicht der Fall, führt kein Weg an einer anderen Backuplösung vorbei. Unter den quelloffenen Werkzeugen sind es zum Beispiel Mondo und Mkcdrec, die mit logischen Volumes umgehen können. (jk)