Kapitel 12. Erweiterte Verwaltung

Dieses Kapitel greift noch einmal einige Aspekte, die wir bereits beschrieben haben, aus einer anderen Perspektive auf: anstatt einen einzelnen Rechner zu installieren, werden wir Systeme für den Masseneinsatz untersuchen; anstatt RAID- oder LVM-Volumes während der Installierung zu erstellen, lernen wir, dies von Hand zu tun, so dass wir später unsere ursprünglichen Entscheidungen revidieren können. Schließlich werden wir Überwachungsprogramme und Virtualisierungstechniken besprechen. Daher richtet sich dieses Kapitel in erster Linie an professionelle Administratoren und weniger an Einzelpersonen, die für ihr Heimnetzwerk zuständig sind.

12.1. RAID und LVM

Kapitel 4, Installation hat diese Techniken aus der Sicht des Installationsprogramms dargestellt und wie es sie so integriert, dass ihr Einsatz von Beginn an einfach ist. Nach der anfänglichen Installation muss ein Administrator in der Lage sein, neu auftretendem Bedarf an Speicherplatz zu begegnen, ohne auf eine aufwändige Neuinstallation zurückgreifen zu müssen. Er muss daher die Hilfsprogramme zur Handhabung von RAID- und LVM-Volumes verstehen.

Sowohl RAID als auch LVM sind Verfahren, um die eingehängten Speicherbereiche von ihren physischen Entsprechungen (Festplatten oder ihre Partitionen) zu lösen, wobei ersteres die Daten durch redundante Speicherung vor einem Hardwareausfall schützt und letzteres die Datenverwaltung flexibler und unabhängig von der tatsächlichen Größe der zugrunde liegenden Speicherplatten macht. In beiden Fällen führt dies zu einem System mit neuen Blockgeräten, die zur Erstellung von Dateisystemen oder Auslagerungsspeicher verwendet werden können, ohne diese notwendigerweise einer physischen Speicherplatte zuordnen zu müssen. RAID und LVM haben recht unterschiedliche Ursprünge, ihre Funktionsweise überschneidet sich jedoch teilweise, weshalb sie häufig gemeinsam erwähnt werden.

AUSBLICK Btrfs vereint LVM und RAID

Während LVM und RAID zwei unterschiedliche Subsysteme des Kernels sind, die zwischen den Blockgeräten und ihren Dateisystemen liegen, ist btrfs ein neues Dateisystem, das ursprünglich bei Oracle entwickelt wurde und darauf abzielt, die Funktionen von LVM und RAID und noch vieles mehr zu vereinen. Es ist weitgehend funktionsfähig, wird aber noch als „experimentell“ bezeichnet, da seine Entwicklung noch nicht abgeschlossen ist (einige Funktionsmerkmale sind noch nicht umgesetzt), und hat auch seine Brauchbarkeit schon in Produktionsumgebungen unter Beweis gestellt.

→ http://btrfs.wiki.kernel.org/

Zu den erwähnenswerten Funktionsmerkmalen gehört die Fähigkeit, zu jedem beliebigen Zeitpunkt einen Schnappschuss des Dateisystembaums festhalten zu können. Das Abbild des Schnappschusses nimmt anfangs keinen Speicherplatz ein, da Daten nur kopiert werden, wenn etwas verändert wird. Das Dateisystem kann auch Dateien transparent komprimieren, und Prüfsummen gewährleisten die Integrität aller gespeicherten Daten.

Sowohl bei RAID als auch bei LVM stellt der Kernel eine Gerätedatei bereit in ähnlicher Weise, wie bei denen, die sich auf ein Festplattenlaufwerk oder eine Partition beziehen. Wenn eine Anwendung oder ein anderer Teil des Kernels auf einen Block eines derartigen Geräts zugreifen muss, lenkt das entsprechende Subsystem den Block zu der entsprechenden physischen Ebene. Je nach Konfiguration kann dieser Block auf einer oder mehreren physischen Platten gespeichert sein, wobei sein physischer Ort nicht unbedingt direkt dem Ort des Blocks in dem logischen Gerät entspricht.

12.1.1. Software-RAID

RAID bedeutet Redundant Array of Independent Disks (Redundante Anordnung unabhängiger Festplatten). Ziel dieses Systems ist es, Datenverluste im Falle eines Festplattenausfalls zu vermeiden. Das allgemeine Prinzip ist recht einfach: Daten werden mit einem einstellbaren Grad von Redundanz auf mehreren physischen Platten gespeichert statt nur auf einer. In Abhängigkeit vom Ausmaß dieser Redundanz können Daten selbst bei einem unerwarteten Plattenausfall ohne Verluste von den verbleibenden Platten wieder hergestellt werden.

RAID kann entweder mit speziell hierfür vorgesehener Hardware eingerichtet werden (mit RAID-Modulen, die in SCSI- oder SATA-Controllerkarten integriert sind) oder durch Softwareabstraktion (den Kernel). Ob Hard- oder Software, ein RAID-System mit ausreichender Redundanz kann in transparenter Weise funktionsfähig bleiben, wenn eine Platte ausfällt. Die oberen Abstraktionsschichten (Anwendungen) können trotz des Ausfalls weiterhin auf die Daten zugreifen. Dieser „eingeschränkte Modus“ kann natürlich Auswirkungen auf die Leistung haben, und die Redundanz ist geringer, so dass ein weiterer Plattenausfall dann zu Datenverlust führen kann. Daher wird man in der Praxis versuchen, nur solange in diesem eingeschränkten Modus zu verbleiben, wie das Ersetzen der ausgefallenen Platte dauert. Sobald die neue Platte eingebaut ist, kann das RAID-System die erforderlichen Daten wieder herstellen, um so zu einem sicheren Modus zurückzukehren. Die Anwendungen werden hiervon nichts bemerken, abgesehen von einer möglicherweise verringerten Zugriffsgeschwindigkeit während sich die Anordnung im eingeschränkten Modus oder im Stadium der Wiederherstellung befindet.

Wenn RAID von der Hardware zur Verfügung gestellt wird, wird die Konfiguration im Allgemeinen innerhalb des Bios-Setup durchgeführt und der Kernel hält das RAID-Array für eine einzelne Festplatte die als physikalische Platte darstellt, obwohl der Gerätename sich davon unterscheidet. Zum Beispiel stellt der Kernel in Squeeze einige Hardware-RAID-Arrays als /dev/cciss/c0d0 zur Verfügung; der Kernel in Wheezy änderte diesen Namen in die näherliegende Bezeichnung/dev/sda, aber bei anderen RAID-Kontrollern kann es sich anders verhalten.

Wir betrachten in diesem Buch nur Software-RAID.

12.1.1.1. Unterschiedliche RAID-Stufen

RAID existiert in der Tat in mehreren Ausprägungen, gekennzeichnet durch ihre Level. Diese Level unterscheiden sich in ihrem Aufbau und in dem Ausmaß der Redundanz, die sie bereitstellen. Je mehr Redundanzen, desto ausfallsicherer, da das System auch mit mehreren ausgefallenen Platten immer noch funktioniert. Die Kehrseite ist, dass der verfügbare Platz bei gegebener Anzahl an Platten geringer wird; oder anders ausgedrückt, es werden mehr Platten benötigt, um dieselbe Datenmenge zu speichern.

Lineares RAID: Obwohl das RAID-Subsystem des Kernels die Einrichtung eines „linearen RAIDs“ ermöglicht, ist dies kein wirkliches RAID, da sein Aufbau keinerlei Redundanz enthält. Der Kernel reiht lediglich mehrere Platten von Anfang bis Ende aneinander und stellt den sich daraus ergebenden zusammengefassten Datenträger als eine virtuelle Platte (ein Blockgerät) bereit. Das ist so gut wie seine einzige Funktion. Dieser Aufbau wird selten für sich allein verwendet (Ausnahmen werden weiter unten erläutert), insbesondere da die fehlende Redundanz dazu führt, dass bei Ausfall einer Platte der gesamte Datenträger und damit alle Daten nicht mehr verfügbar sind.
RAID-0: Diese Stufe stellt ebenfalls keinerlei Redundanz bereit, aber die Platten werden nicht einfach aneinandergereiht: sie werden in Streifen unterteilt, und die Blöcke des virtuellen Geräts werden in Streifen abwechselnd auf den physischen Platten abgespeichert. So werden zum Beispiel bei einem RAID-0-Aufbau, der aus zwei Platten besteht, die geradzahligen Blöcke des virtuellen Geräts auf der ersten physischen Platte gespeichert, während die ungeradzahligen Blöcke auf der zweiten physischen Platte landen.
Dieses System beabsichtigt nicht, die Zuverlässigkeit zu erhöhen, da (wie beim linearen RAID) die Verfügbarkeit der Daten gefährdet ist, sobald eine Platte ausfällt, sondern die Leistung zu erhöhen: beim sequentiellen Zugriff auf große Mengen zusammenhängender Daten kann der Kernel gleichzeitig von beiden Platten lesen (oder auf sie schreiben), wodurch die Datenübertragungsrate erhöht wird. Die Verwendung von RAID-0 geht jedoch zurück, da seine Nische durch LVM gefüllt wird (siehe unten).
RAID-1: Diese Stufe, die auch als „RAID-Spiegelung“ bezeichnet wird, ist der einfachste und am häufigsten verwendete Aufbau. In seiner Standardform verwendet er zwei physische Platten gleicher Größe und stellt einen logischen Datenträger von ebenfalls gleicher Größe bereit. Daten werden auf beiden Platten identisch gespeichert, daher die Bezeichnung „Spiegel“. Wenn eine Platte ausfällt, sind die Daten auf der anderen weiterhin verfügbar. Für sehr kritische Daten kann RAID-1 natürlich auch auf mehr als zwei Platten eingerichtet werden, mit direkter Auswirkung auf das Verhältnis von Hardwarekosten zu nutzbarem Speicherplatz.
HINWEIS Platten und Clustergrößen
Wenn zwei Platten unterschiedlicher Größe als Spiegel eingerichtet werden, wird die größere nicht vollständig benutzt, da sie die gleichen Daten wie die kleinere enthält und sonst nichts. Der von einem RAID-1-Volume bereitgestellte nutzbare Platz entspricht daher der Größe der kleinsten Platte dieser Anordnung. Dies gilt auch für RAID-Volumes einer höheren RAID-Stufe, obwohl dort die Redundanz anders abgespeichert wird.
Es ist daher wichtig, beim Einrichten von RAID-Anordnungen (außer von RAID-0 und „linearem RAID“) nur Platten gleicher oder sehr ähnlicher Größe zu verbinden, um die Verschwendung von Ressourcen zu vermeiden.
HINWEIS Reserveplatten
RAID-Stufen, die Redundanz enthalten, ermöglichen es, mehr Platten als nötig einem Verbund zuzuordnen. Diese zusätzlichen Platten dienen als Reserve für den Fall, dass eine der Hauptplatten ausfällt. Zum Beispiel wird der Kernel in einem Spiegel aus zwei Platten und einer Reserveplatte, wenn eine der ersten beiden ausfällt, automatisch (und sofort) den Spiegel unter Verwendung der Reserveplatte neu aufbauen, so dass die Redundanz nach Abschluss des Wiederaufbaus weiterhin gewährleistet ist. Dies kann als weitere Schutzmaßnahme für kritische Daten genutzt werden.
Man könnte sich natürlich fragen, wieso dies besser ist als gleich von Anfang an auf drei Platten zu spiegeln. Der Vorteil der Anordnung mit einer „Reserveplatte“ besteht darin, dass die Reserveplatte von mehreren RAID-Volumes gemeinsam benutzt werden kann. So kann man zum Beispiel mit nur sieben Platten (drei Paaren und einer Reserve für alle) statt neun, die für drei Dreiergruppen erforderlich wären, drei gespiegelte Volumes haben, bei denen die Redundanz selbst beim Ausfall einer Platte gewährleistet bleibt.
Diese RAID-Stufe wird in der Praxis häufig verwendet, obwohl sie kostspielig ist (da der physische Speicherplatz allenfalls zur Hälfte genutzt werden kann). Sie ist einfach zu verstehen und ermöglicht sehr einfache Sicherheitskopien: da beide Platten den gleichen Inhalt haben, kann eine von ihnen ohne Auswirkung auf das arbeitende System vorübergehend entfernt werden. Die Leseleistung ist häufig höher, da der Kernel auf jeder Platte eine Hälfte der Daten gleichzeitig lesen kann, während die Schreibleistung nicht allzu stark vermindert ist. Bei einer RAID-Anordnung von N Platten bleiben die Daten selbst bei einem Ausfall von N-1 Platten erhalten.
RAID-4: Diese selten verwendete RAID-Stufe verwendet N Platten zur Speicherung nutzbarer Daten und eine zusätzliche Platte zur Speicherung der Redundanzinformation. Falls diese Platte ausfällt, kann das System ihren Inhalt aus den übrigen N Platten wieder herstellen. Falls eine der N Platten ausfällt, enthalten die verbleibenden N-1 Platten zusammen mit der „Paritätsplatte“ genügend Informationen, um die erforderlichen Daten wieder herzustellen.
RAID-4 ist nicht allzu kostspielig, da es nur zu zusätzlichen Kosten in Höhe von Eins-in-N führt. Es hat keinen spürbaren Einfluss auf die Leseleistung, verlangsamt aber das Schreiben. Da außerdem jeder Schreibvorgang auf einer der N Platten auch einen Schreibvorgang auf der Paritätsplatte erfordert, finden auf letzterer sehr viel mehr Schreibvorgänge als auf den anderen statt, und ihre Lebensdauer kann folglich deutlich verkürzt sein. Daten in einer RAID-4-Anordnung sind lediglich bis zum Ausfall einer Platte (der N+1 Platten) sicher.
RAID-5: RAID-5 behebt das Problem der Asymmetrie von RAID-4: Paritätsblöcke sind über alle N+1 Platten verteilt, ohne dass eine einzelne Platte eine besondere Rolle spielt.
Die Lese- und Schreibleistung ist die gleiche wie bei RAID-4. Auch hier bleibt das System funktionsfähig, wenn eine der N+1 Platten ausfällt, jedoch nicht mehr.
RAID-6: RAID-6 kann als Erweiterung von RAID-5 angesehen werden, wobei jeder Reihe von N Blöcken zwei Redundanzblöcke zugeordnet sind, und jede dieser Serien von N+2 Blöcken über N+2 Platten verteilt ist.
Diese RAID-Stufe ist etwas teurer als die zwei vorhergehenden, bietet jedoch etwas mehr Sicherheit, da bis zu zwei der N+2 Platten ausfallen können, ohne dass die Datenverfügbarkeit gefährdet ist. Die Kehrseite ist, dass jeder Schreibvorgang jetzt das Schreiben eines Datenblocks und zweier Redundanzblöcke erfordert, wodurch er noch langsamer wird.
RAID-1+0: Dies ist genau genommen keine RAID-Stufe, sondern ein Zusammenfassen zweier RAID-Gruppen. Ausgehend von 2xN Platten werden diese zunächst paarweise in N RAID-1-Volumes angeordnet. Diese N Volumes werden dann entweder durch „lineares RAID“ oder (immer häufiger) durch LVM zu einem einzigen Volume zusammengefasst. Letzteres geht über reines RAID hinaus. Das ist jedoch nicht problematisch.
RAID-1+0 kann den Ausfall mehrerer Platten überstehen und zwar bis zu N der oben beschriebenen 2xN-Anordnung, vorausgesetzt, dass in jedem der RAID-1-Paare wenigstens noch eine Platte funktioniert.
WEITERE SCHRITTE RAID-10
RAID-10 wird im Allgemeinen als ein Synonym für RAID-1+0 angesehen, jedoch führt eine Besonderheit von Linux zu dieser Verallgemeinerung. Diese Anordnung ermöglicht ein System, bei dem jeder Block selbst bei einer ungeraden Plattenanzahl auf zwei unterschiedlichen Platten gespeichert ist, wobei die Kopien einem konfigurierbaren Modell entsprechend verteilt werden.
Die Leistung kann in Abhängigkeit von dem gewählten Repartitionierungsmodell und Redundanzniveau sowie von der Arbeitslast des logischen Volumes unterschiedlich sein.

Natürlich wird die RAID-Stufe in Abhängigkeit von den Beschränkungen und Erfordernissen jeder Anwendung gewählt. Man beachte, dass ein einzelner Rechner über mehrere unterschiedliche RAID-Anordnungen mit unterschiedlichen Konfigurationen verfügen kann.

12.1.1.2. RAID einrichten

Zur Einrichtung von RAID-Volumes wird das Paket mdadm benötigt. Es stellt den Befehl mdadm zur Verfügung, mit dem RAID-Anordnungen erstellt und verändert werden können, wie auch Skripten und Hilfsprogramme, mit denen es in das übrige System integriert werden kann, einschließlich eines Überwachungssystems.

Als Beispiel nehmen wir einen Server mit einer Anzahl von Platten, von denen einige bereits benutzt werden, während der Rest für die Einrichtung des RAID zur Verfügung steht. Zu Beginn haben wir die folgenden Platten und Partitionen:

die Platte sdb, 4 GB, ist vollständig verfügbar;
die Platte sdc, 4 GB, ist ebenfalls vollständig verfügbar;
auf der Platte sdd ist nur die Partition sdg2 (ungefähr 4 GB) verfügbar;
schließlich ist die Platte sde, ebenfalls 4 GB, vollständig verfügbar.

Wir werden diese physischen Komponenten zur Einrichtung zweier Volumes verwenden, eines RAID-0 und eines Spiegels (RAID-1). Wir beginnen mit dem RAID-0-Volume:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
# mdadm --query /dev/md0
/dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Jan 17 15:56:55 2013
     Raid Level : raid0
     Array Size : 8387584 (8.00 GiB 8.59 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 15:56:55 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : mirwiz:0  (local to host mirwiz)
           UUID : bb085b35:28e821bd:20d697c9:650152bb
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
524288 inodes, 2096896 blocks
104844 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2147483648
64 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
       32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/raid-0
# mount /dev/md0 /srv/raid-0
# df -h /srv/raid-0
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.9G  146M  7.4G   2% /srv/raid-0

Der Befehl mdadm --create erfordert mehrere Parameter: den Namen des zu erstellenden Volumes (/dev/md*, wobei MD Multiple Device bedeutet), die RAID-Stufe, die Anzahl der Platten (die in jedem Fall angegeben werden muss, obwohl dies nur bei RAID-1 oder höher Sinn macht) und die zu verwendenden physischen Laufwerke. Nachdem das Gerät erstellt ist, können wir es wie eine normale Partition verwenden, auf ihm ein Dateisystem einrichten, dieses Dateisystem einhängen und so weiter. Man beachte, dass unsere Einrichtung eines RAID-0-Volumes auf md0 nur Zufall ist, und dass die Nummerierung der Anordnung nicht der gewählten Redundanzstufe entsprechen muss. Man kann auch einen benannten RAID-Verbund erstellen, indem man mdadm Parameter wie /dev/md/linear statt /dev/md0 mitgibt.

Die Erstellung eines RAID-1 erfolgt auf ähnliche Weise; die Unterschiede machen sich erst nach der Erstellung bemerkbar:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1%
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
# mdadm --query /dev/md1
/dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Thu Jan 17 16:13:04 2013
     Raid Level : raid1
     Array Size : 4192192 (4.00 GiB 4.29 GB)
  Used Dev Size : 4192192 (4.00 GiB 4.29 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 16:13:04 2013
          State : clean, resyncing (PENDING) 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       8       64        1      active sync   /dev/sde
# mdadm --detail /dev/md1
/dev/md1:
[...]
          State : clean
[...]

Einige Bemerkungen sind angebracht. Zunächst stellt mdadm fest, dass die physischen Komponenten von unterschiedlicher Größe sind; da dies bedeutet, dass auf der größeren Komponente einiger Platz verloren geht, ist eine Bestätigung erforderlich.

Wichtiger ist es aber, den Zustand des Spiegels zu beachten. Im Normalzustand eines RAID-Spiegels haben beide Platten genau denselben Inhalt. Jedoch stellt nichts sicher, dass dies der Fall ist, wenn der Datenträger erstmalig erstellt wird. Das RAID-Subsystem gewährleistet dieses daher selbst, und es gibt eine Synchronisierungsphase, sobald das RAID-Gerät erzeugt worden ist. Einige Zeit später (die genaue Dauer hängt von der jeweiligen Größe der Platten ab...), schaltet die RAID-Anordnung in den „aktiven“ Zustand um. Man beachte, dass sich der Spiegel während dieser Rekonstruktionsphase in einem eingeschränkten Zustand befindet und Redundanz nicht sichergestellt ist. Ein Plattenausfall während dieser Risikolücke könnte zu einem vollständigen Verlust aller Daten führen. Jedoch werden kritische Daten selten in großer Menge auf einer neu erstellten RAID-Anordnung vor ihrer anfänglichen Synchronisierung gespeichert. Man beachte, dass selbst im eingeschränkten Zustand /dev/md1 benutzt werden kann, dass auf ihm ein Dateisystem erstellt werden kann, und dass Daten auf ihm abgelegt werden können.

TIPP Einen Spiegel in eingeschränktem Zustand starten

Manchmal sind zwei Platten nicht unmittelbar verfügbar, wenn man einen RAID-1-Spiegel einrichten möchte, weil zum Beispiel eine der hierfür vorgesehenen Platten bereits zur Speicherung der Daten benutzt wird, die man auf die Anordnung verschieben möchte. In solch einem Fall ist es möglich, vorsätzlich eine eingeschränkte RAID-1-Anordnung zu erzeugen, indem man als eines der Argumente missing statt einer Gerätedatei an mdadm übergibt. Sobald dann die Daten auf den „Spiegel“ kopiert worden sind, kann die alte Platte der Anordnung hinzugefügt werden. Anschließend wird eine Synchronisierung stattfinden, die zu der Redundanz führt, die wir von vornherein angestrebt hatten.

TIPP Einen Spiegel ohne Synchronisierung einrichten

RAID-1-Volumes werden häufig erstellt, um als neue Platten, die oft als leer erachtet werden, verwendet zu werden. Der ursprüngliche tatsächliche Inhalt der Platte ist daher nicht sehr relevant, da man nur sicher sein will, dass die Daten, die nach der Erstellung des Datenträgers geschrieben werden, und hier insbesondere das Dateisystem, anschließend zugänglich sind.

Man könnte sich daher fragen, wozu die Synchronisierung der beiden Platten zur Zeit der Erstellung gut ist. Warum sollte man sich darum kümmern, ob der Inhalt in Bereichen des Datenträgers gleich ist, von denen wir wissen, dass sie erst gelesen werden, nachdem wir etwas auf sie geschrieben haben?

Glücklicherweise kann diese Synchronisierungsphase vermieden werden, indem man die Option --assume-clean an mdadm übergibt. Diese Option kann jedoch in den Fällen zu Überraschungen führen, in denen die ursprünglichen Daten gelesen werden (falls zum Beispiel bereits ein Dateisystem auf der physischen Platte vorhanden ist). Deshalb ist sie nicht standardmäßig aktiviert.

Nun wollen wir sehen, was passiert, wenn eine der Komponenten der RAID-1-Anordnung ausfällt. Mit mdadm, genauer gesagt mit seiner Option --fail, lässt sich ein derartiger Plattenausfall simulieren:

# mdadm /dev/md1 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Thu Jan 17 16:14:09 2013
          State : active, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 19

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       1       0        0        1      removed

       1       8       64        -      faulty spare   /dev/sde

Der Inhalt des Datenträgers ist weiterhin zugänglich (und falls er eingehängt ist, bemerken die Anwendungen nichts), aber die Sicherheit der Daten ist nicht mehr gewährleistet: sollte die Platte sdd ebenfalls ausfallen, wären die Daten verloren. Wir möchten dieses Risiko vermeiden und werden daher die ausgefallene Platte durch eine neue, sdf, ersetzen:

# mdadm /dev/md1 --add /dev/sdf
mdadm: added /dev/sdf
# mdadm --detail /dev/md1
/dev/md1:
[...]
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Thu Jan 17 16:15:32 2013
          State : clean, degraded, recovering 
 Active Devices : 1
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 1

 Rebuild Status : 28% complete

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 26

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      spare rebuilding   /dev/sdf

       1       8       64        -      faulty spare   /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Update Time : Thu Jan 17 16:16:36 2013
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           Name : mirwiz:1  (local to host mirwiz)
           UUID : 6ec558ca:0c2c04a0:19bca283:95f67464
         Events : 41

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sdd2
       2       8       80        1      active sync   /dev/sdf

       1       8       64        -      faulty spare   /dev/sde

Auch in diesem Fall löst der Kernel automatisch eine Rekonstruktionsphase aus, während der sich der Datenträger in eingeschränktem Zustand befindet, auch wenn er weiterhin zugänglich ist. Sobald die Rekonstruktion vorüber ist, befindet sich die RAID-Anordnung wieder in normalem Zustand. Man kann dem System dann mitteilen, dass die Platte sde aus der Anordnung entfernt werden wird, um so zu einem typischen RAID-Spiegel auf zwei Platten zu gelangen:

# mdadm /dev/md1 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md1
# mdadm --detail /dev/md1
/dev/md1:
[...]
    Number   Major   Minor   RaidDevice State
       0       8       98        0      active sync   /dev/sdg2
       1       8      128        1      active sync   /dev/sdi

Von da an kann das Laufwerk physisch entfernt werden, sobald der Server das nächste Mal abgestellt wird, oder sogar im laufenden Betrieb, falls die Hardware-Konfiguration dies erlaubt. Zu derartigen Konfigurationen gehören einige SCSI-Controller, die meisten SATA-Platten und externe Laufwerke, die über USB oder Firewire betrieben werden.

12.1.1.3. Konfiguration sichern

Die meisten Meta-Daten, die RAID-Datenträger betreffen, werden direkt auf den Platten gespeichert, aus denen diese Anordnungen bestehen, so dass der Kernel diese Anordnungen und ihre Komponenten erkennen und sie selbsttätig zusammenstellen kann, wenn das System hochfährt. Es wird jedoch empfohlen, eine Sicherungskopie dieser Konfiguration zu erstellen, da diese Erkennung nicht ausfallsicher ist, und da sie voraussichtlich gerade in einer prekären Situation ausfallen wird. Wenn in unserem Beispiel der Ausfall der Platte sde tatsächlich stattgefunden hätte (statt ihn nur zu simulieren) und das System neu gestartet worden wäre, ohne die Platte sde zu entfernen, würde diese Platte möglicherweise wieder funktionieren, da sie während des Neustarts überprüft worden wäre. Der Kernel hätte dann drei physische Komponenten, von denen jede angeblich eine Hälfte desselben RAID-Volumes enthält. Weitere Verwirrung könnte entstehen, wenn RAID-Datenträger von zwei Servern auf einem zusammengefasst werden. Falls diese Anordnungen vor ihrem Umzug normal funktionierten, wäre der Kernel in der Lage, die Paare korrekt zu erkennen und neu zusammenzustellen. Falls die verlegten Platten jedoch auf dem vorherigen Server zu einem md1 zusammengefasst waren, und der jetzige Server bereits ein md1 hat, würde einer der Spiegel umbenannt werden.

Es ist daher wichtig, die Konfiguration zu sichern, selbst wenn dies nur zu Referenzzwecken geschieht. Das normale Verfahren besteht darin, die Datei /etc/mdadm/mdadm.conf zu editieren, von der hier ein Beispiel gezeigt wird:

Beispiel 12.1. Konfigurationsdatei mdadm

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
DEVICE /dev/sd*

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c04a0:19bca283:95f67464

# This configuration was auto-generated on Thu, 17 Jan 2013 16:21:01 +0100
# by mkconf 3.2.5-3

Einer der nützlichsten Bestandteile ist die Option DEVICE, mit der die Geräte aufgelistet werden, bei denen das System beim Start selbstständig nach Komponenten des RAID-Volumes suchen soll. In unserem Beispiel haben wir die Voreinstellung partitions containers durch eine eindeutige Liste mit Gerätedateien ersetzt, da wir uns entschieden haben, für einige Datenträger ganze Platten und nicht nur Partitionen zu verwenden.

Die letzten beiden Zeilen unseres Beispiels ermöglichen es dem Kernel sicher auszuwählen, welche Volume-Nummer welcher Anordnung zugewiesen werden soll. Die auf den Platten selbst gespeicherten Meta-Daten reichen aus, die Volumes wieder zusammenzustellen, jedoch nicht, die Volume-Nummer zu bestimmen (und den dazu passenden Gerätenamen /dev/md*).

Glücklicherweise können diese Zeilen automatisch erstellt werden:

# mdadm --misc --detail --brief /dev/md?
ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=bb085b35:28e821bd:20d697c9:650152bb
ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=6ec558ca:0c2c94a0:19bca283:95f6746

Der Inhalt dieser letzten beiden Zeilen ist nicht von der Liste der Platten abhängig, die zu dem Volume gehören. Es ist daher nicht erforderlich, diese Zeilen neu zu erstellen, wenn eine ausgefallene Platte durch eine neue ersetzt wird. Andererseits ist darauf zu achten, dass die Datei aktualisiert wird, wenn eine RAID-Anordnung erstellt oder gelöscht wird.

12.1.2. LVM

LVM, der Logical Volume Manager, ist ein anderer Ansatz, um logische Volumes von ihren physischen Grundlagen zu trennen, der seinen Schwerpunkt auf größere Flexibilität statt auf größere Zuverlässigkeit legt. LVM ermöglicht es, was die Anwendungen betrifft, ein logisches Volume transparent auszuwechseln. Es ist zum Beispiel möglich, neue Platten hinzuzufügen, Daten auf sie zu verschieben, und dann die alten Platten zu entfernen, ohne das Volume auszuhängen.

12.1.2.1. LVM-Konzepte

Diese Flexibilität wird durch eine Abstraktionsstufe erreicht, zu der drei Konzepte gehören.

Das PV (Physical Volume) ist das Element, das der Hardware am nächsten ist: es kann aus Partitionen auf einer Platte bestehen, aus einer ganzen Platte oder auch aus jedem anderen Blockgerät (einschließlich beispielsweise einem RAID-Verbund). Man beachte, dass auf eine physische Komponente, wenn sie als PV für einen LVM eingerichtet ist, nur über den LVM zugegriffen wird, da das System sonst verwirrt wird.

Eine Anzahl von PVs kann zu einer VG (Volume Group) zusammengefasst werden, die als virtuelle und erweiterbare Platte angesehen werden kann. VGs sind abstrakt und erscheinen nicht in einer Gerätedatei in der /dev-Hierarchie, so dass nicht die Gefahr besteht, dass sie direkt benutzt werden.

Die dritte Art von Objekten ist das LV (Logical Volume), das aus einer Menge von VGs besteht. Wenn wir die Analogie beibehalten, dass eine VG eine Platte ist, kann das LV als eine Partition angesehen werden. Das LV erscheint als Blockgerät mit einem Eintrag in /dev, und es kann wie jede andere physische Partition verwendet werden (am häufigsten, um ein Dateisystem oder Auslagerungsspeicher aufzunehmen).

Wichtig ist, dass das Aufteilen einer VG in LVs von ihren physischen Komponenten (den PVs) völlig unabhängig ist. Eine VG, die nur aus einer einzelnen physischen Komponente besteht (zum Beispiel einer Platte), kann in ein Dutzend logischer Volumes unterteilt werden. In ähnlicher Weise kann eine VG mehrere physische Platten verwenden und dennoch als ein einziges großes logisches Volume erscheinen. Die einzige Beschränkung besteht darin, dass die Gesamtgröße, die den LVs zugeteilt ist, offensichtlich nicht größer als die Gesamtkapazität der PVs in dieser Volumegruppe sein kann.

Es macht jedoch häufig Sinn, eine gewisse Einheitlichkeit unter den physischen Komponenten einer VG einzuhalten, und die VG in logische Volumes zu unterteilen, die ähnliche Verwendungsmuster haben. Falls die verfügbare Hardware zum Beispiel schnellere und langsamere Platten enthält, könnten die schnelleren zu einer VG zusammengefasst werden und die langsameren zu einer anderen. Teile der ersten können dann Anwendungen zugeordnet werden, die schnellen Datenzugriff erfordern, während die zweite weniger anspruchsvollen Aufgaben vorbehalten bleibt.

In jedem Fall sollte man sich merken, dass ein LV nicht ausdrücklich einem bestimmten PV zugeordnet ist. Man kann den Ort, an dem die Daten eines LV physisch gespeichert werden, beeinflussen, jedoch ist diese Möglichkeit für den täglichen Gebrauch nicht notwendig. Im Gegenteil: wenn sich der Satz physischer Komponenten einer VG weiterentwickelt, können die physischen Speicherorte, die einem bestimmten LV entsprechen, über Platten hinweg verschoben werden (wobei sie natürlich innerhalb der PVs verbleiben müssen, die der VG zugeordnet sind).

12.1.2.2. Einen LVM einrichten

Wir wollen nun Schritt für Schritt den Prozess der Einrichtung eines LVM für einen typischen Anwendungsfall verfolgen: wir wollen eine komplizierte Speichersituation vereinfachen. Eine derartige Situation entsteht normalerweise aus einer langen und verwickelten Abfolge sich anhäufender temporärer Maßnahmen. Zu Illustrationszwecken nehmen wir einen Server an, bei dem die Speicherbedürfnisse sich im Laufe der Zeit verändert und schließlich zu einem Gewirr verfügbarer Partitionen geführt haben, die über mehrere teilweise genutzte Platten verteilt sind. Genauer gesagt sind folgende Partitionen vorhanden:

auf der Platte sdb eine Partition sdb2, 4 GB;
auf der Platte sdc eine Partition sdc3, 3 GB;
die Platte sdd, 4 GB, vollständig verfügbar;
auf der Platte sdf eine Partition sdf1, 4 GB; und eine Partition sdf2, 5 GB.

Zusätzlich nehmen wir an, dass die Platten sdb und sdf schneller als die anderen beiden sind.

Unser Ziel ist es, drei logische Volumes für drei verschiedene Anwendungen einzurichten: einen Dateiserver (der 5 GB Speicherplatz benötigt), eine Datenbank (1 GB) und Speicherplatz für Sicherungskopien (12 GB). Die ersten beiden erfordern eine gute Leistung, wohingegen bei den Sicherungen die Zugriffsgeschwindigkeit weniger entscheidend ist. Alle diese Einschränkungen verhindern die Verwendung einzelner Partitionen. Durch den Einsatz eines LVM kann von der physischen Größe der Geräte abstrahiert werden, so dass nur der insgesamt verfügbare Platz als Begrenzung verbleibt.

Die erforderlichen Hilfsprogramme befinden sich in dem Paket lvm2 und seinen Abhängigkeiten. Wenn sie installiert sind, erfolgt die Einrichtung eines LVM in drei Schritten, entsprechend den drei Konzeptstufen.

Zunächst erstellen wir mit pvcreate die physischen Volumes:

# pvdisplay
# pvcreate /dev/sdb2
  Writing physical volume data to disk "/dev/sdb2"
  Physical volume "/dev/sdb2" successfully created
# pvdisplay
  "/dev/sdb2" is a new physical volume of "4.00 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb2
  VG Name               
  PV Size               4.00 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               0zuiQQ-j1Oe-P593-4tsN-9FGy-TY0d-Quz31I

# for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done
  Writing physical volume data to disk "/dev/sdc3"
  Physical volume "/dev/sdc3" successfully created
  Writing physical volume data to disk "/dev/sdd"
  Physical volume "/dev/sdd" successfully created
  Writing physical volume data to disk "/dev/sdf1"
  Physical volume "/dev/sdf1" successfully created
  Writing physical volume data to disk "/dev/sdf2"
  Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
  PV         VG   Fmt  Attr PSize PFree
  /dev/sdb2       lvm2 a--  4.00g 4.00g
  /dev/sdc3       lvm2 a--  3.09g 3.09g
  /dev/sdd        lvm2 a--  4.00g 4.00g
  /dev/sdf1       lvm2 a--  4.10g 4.10g
  /dev/sdf2       lvm2 a--  5.22g 5.22g

So weit, so gut. Man beachte, dass ein PV sowohl auf einer vollständigen Platte als auch auf einzelnen darauf enthaltenen Partitionen eingerichtet werden kann. Wie oben gezeigt, listet der Befehl pvdisplay die bestehenden PVs in zwei möglichen Ausgabeformaten auf.

Wir wollen jetzt diese physischen Komponenten mit dem Befehl vgcreate zu VGs zusammenfügen. Dabei nehmen wir nur PVs von den schnellen Platten in eine VG namens vg_critical auf; die andere VG, vg_normal, enthält dagegen auch langsamere Komponenten.

# vgdisplay
  No volume groups found
# vgcreate vg_critical /dev/sdb2 /dev/sdf1
  Volume group "vg_critical" successfully created
# vgdisplay
  --- Volume group ---
  VG Name               vg_critical
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               8.09 GiB
  PE Size               4.00 MiB
  Total PE              2071
  Alloc PE / Size       0 / 0   
  Free  PE / Size       2071 / 8.09 GiB
  VG UUID               bpq7zO-PzPD-R7HW-V8eN-c10c-S32h-f6rKqp

# vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2
  Volume group "vg_normal" successfully created
# vgdisplay -C
  VG          #PV #LV #SN Attr   VSize  VFree 
  vg_critical   2   0   0 wz--n-  8.09g  8.09g
  vg_normal     3   0   0 wz--n- 12.30g 12.30g

Auch hier sind die Befehle recht einfach (und bei vgdisplay kann zwischen zwei Ausgabeformaten gewählt werden). Man beachte, dass es durchaus möglich ist, zwei Partitionen derselben physischen Platte in zwei unterschiedlichen VGs zu verwenden. Außerdem beachte man, dass wir bei der Benennung unserer VGs zwar das Präfix vg_ benutzt haben, dass dies aber lediglich eine Gewohnheit ist.

Wir haben jetzt zwei „virtuelle Platten“ mit einer Größe von etwa 8 GB und 12 GB. Wir wollen sie jetzt in „virtuelle Partitionen“ (LVs) unterteilen. Dies geschieht mit dem Befehl lvcreate und einer etwas komplizierteren Syntax:

# lvdisplay
# lvcreate -n lv_files -L 5G vg_critical
  Logical volume "lv_files" created
# lvdisplay
  --- Logical volume ---
  LV Path                /dev/vg_critical/lv_files
  LV Name                lv_files
  VG Name                vg_critical
  LV UUID                J3V0oE-cBYO-KyDe-5e0m-3f70-nv0S-kCWbpT
  LV Write Access        read/write
  LV Creation host, time mirwiz, 2013-01-17 17:05:13 +0100
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

# lvcreate -n lv_base -L 1G vg_critical
  Logical volume "lv_base" created
# lvcreate -n lv_backups -L 12G vg_normal
  Logical volume "lv_backups" created
# lvdisplay -C
  LV         VG          Attr     LSize  Pool Origin Data%  Move Log Copy%  Convert
  lv_base    vg_critical -wi-a---  1.00g                                           
  lv_files   vg_critical -wi-a---  5.00g                                           
  lv_backups vg_normal   -wi-a--- 12.00g

Zur Erstellung logischer Volumes sind zwei Parameter erforderlich; sie müssen als Optionen an den Befehl lvcreate übergeben werden. Der Name des zu erstellenden LV wird mit der Option -n festgelegt und seine Größe im Allgemeinen mit der Option -L. Wir müssen dem Befehl außerdem natürlich mitteilen, auf welche VG er angewendet werden soll. Dazu dient der letzte Parameter der Befehlszeile.

WEITERE SCHRITTE Optionen von lvcreate

Der Befehl lvcreate verfügt über mehrere Optionen, mit denen die Erstellung eines LV fein eingestellt werden kann.

Wir wollen mit der Beschreibung der Option -l beginnen, bei der die Größe des LVs als Anzahl von Blöcken angegeben wird (im Gegensatz zu den „menschlichen“ Einheiten, die wir zuvor verwendet haben). Diese Blöcke (die in der Sprache des LVM als PEs, physical extents, bezeichnet werden) sind zusammenhängende Einheiten von Speicherplatz in den PVs, die nicht auf verschiedene LVs aufgeteilt werden können. Wenn man den Speicherplatz eines LV genau festlegen möchte, um zum Beispiel den verfügbaren Platz vollständig zu nutzen, wird man wohl die Option -l der Option -L vorziehen.

Man kann auch den physischen Ort eines LV angeben, so dass seine „extents“ in einem bestimmten PV abgelegt werden (wobei sie natürlich innerhalb des Bereichs verbleiben müssen, der der VG zugewiesen ist). Da wir wissen, dass sdb schneller als sdf ist, werden wir lv_base wohl dort ablegen, wenn wir dem Datenbank-Server gegenüber dem Dateiserver einen Vorteil verschaffen möchten. So wird die Befehlszeile zu: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Man beachte, dass dieser Befehl scheitern kann, wenn das PV nicht genügend freie „extents“ hat. In unserem Beispiel müssten wir wohl lv_base vor lv_files erstellen, um eine derartige Situation zu vermeiden - oder mit dem Befehl pvmove auf sdb2 etwas Platz schaffen.

Logische Volumes werden nach ihrer Erstellung zu Blockgerätedateien in /dev/mapper/:

# ls -l /dev/mapper
total 0
crw------T 1 root root 10, 236 Jan 17 16:52 control
lrwxrwxrwx 1 root root       7 Jan 17 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root       7 Jan 17 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root       7 Jan 17 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jan 17 17:05 /dev/dm-0
brw-rw---T 1 root disk 253, 1 Jan 17 17:05 /dev/dm-1
brw-rw---T 1 root disk 253, 2 Jan 17 17:05 /dev/dm-2

HINWEIS LVM-Volumes automatisch erkennen

Wenn der Rechner hochfährt, überprüft das Skript /etc/init.d/lvm die verfügbaren Geräte. Diejenigen, die als physische Volumes für LVM initialisiert sind, werden im LVM-Untersystem registriert; diejenigen, die zu Volume-Gruppen gehören, werden zusammengefügt; und die entsprechenden logischen Volumes werden gestartet und bereitgestellt. Es ist daher nicht erforderlich, Konfigurationsdateien zu editieren, wenn LVM-Volumes erstellt oder verändert werden.

Man beachte jedoch, dass die Anordnung der LVM-Komponenten (physische und logische Volumes und Volume-Gruppen) in der Datei /etc/lvm/backup gespeichert wird, was bei Problemen nützlich sein kann (oder auch um einfach einen Blick unter die Haube zu werfen).

Zur Vereinfachung werden zudem bequeme symbolische Verknüpfungen in den Verzeichnissen angelegt, die den VGs entsprechen:

# ls -l /dev/vg_critical
total 0
lrwxrwxrwx 1 root root 7  17 Jan.  17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7  17 Jan.  17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7  17 Jan.  17:05 lv_backups -> ../dm-2

Die LVs können genau wie Standard-Partitionen benutzt werden:

# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
[...]
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 
# mkdir /srv/backups
# mount /dev/vg_normal/lv_backups /srv/backups
# df -h /srv/backups
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_normal-lv_backups   12G  158M   12G   2% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base    /srv/base       ext4
/dev/vg_critical/lv_files   /srv/files      ext4
/dev/vg_normal/lv_backups   /srv/backups    ext4

Aus Sicht der Anwendungen ist die Vielzahl kleiner Partitionen jetzt zu einem großen Datenträger mit 12 GB und einem freundlicheren Namen zusammengefasst worden.

12.1.2.3. LVM im Verlauf der Zeit

Wenn auch die Fähigkeit, Partitionen oder physische Platten zusammenzufassen, praktisch ist, so ist dies doch nicht der wichtigste Vorteil, den LVM bietet. Die Flexibilität, die er mit sich bringt, wird erst im Laufe der Zeit richtig deutlich, wenn sich die Anforderungen weiterentwickeln. In unserem Beispiel wollen wir annehmen, dass neue große Dateien gespeichert werden müssen, und dass das für den Dateiserver reservierte LV für sie zu klein ist. Da wir noch nicht allen in vg_critical verfügbaren Platz verwendet haben, können wir lv_files vergrößern. Zu diesem Zweck benutzen wir den Befehl lvresize und anschließend resize2fs, um das Dateisystem entsprechend anzupassen:

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  5.0G  4.6G  146M  97% /srv/files
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lv_files vg_critical -wi-ao-- 5.00g
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   2   2   0 wz--n- 8.09g 2.09g
# lvresize -L 7G vg_critical/lv_files
  Extending logical volume lv_files to 7.00 GB
  Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
  LV       VG          Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.5 (29-Jul-2012)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/vg_critical/lv_files to 1835008 (4k) blocks.
The filesystem on /dev/vg_critical/lv_files is now 1835008 blocks long.

# df -h /srv/files/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files  6.9G  4.6G  2.1G  70% /srv/files

VORSICHT Die Größe von Dateisystemen ändern

Nicht bei allen Dateisystemen lässt sich die Größe im laufenden Betrieb verändern. Zur Änderung der Größe eines Datenträgers kann es daher erforderlich sein, das Dateisystem zunächst aus- und anschließend wieder einzuhängen. Wenn man die Größe, die einem LV zugeordnet ist, verkleinern will, muss man natürlich zunächst das Dateisystem verkleinern. Die Reihenfolge ist umgekehrt, wenn die Größenänderung in die andere Richtung verläuft: das logische Volume muss vor dem darauf befindlichen Dateisystem vergrößert werden. Dies ist recht eindeutig, da zu keiner Zeit das Dateisystem größer sein darf als das Blockgerät, auf dem es sich befindet (gleichgültig, ob dieses Gerät eine physische Partition oder ein logisches Volume ist).

Die Dateisysteme ext3, ext4 und xfs können im laufenden Betrieb vergrößert werden, ohne sie auszuhängen. Zu einer Verkleinerung müssen sie jedoch ausgehängt werden. Das Dateisystem reiserfs ermöglicht eine Größenänderung im laufenden Betrieb in beide Richtungen. Das altehrwürdige ext2 erlaubt keines von beiden und muss immer ausgehängt werden.

Wir könnten in ähnlicher Weise vorgehen, um den Datenträger zu erweitern, auf dem sich die Datenbank befindet. Nur haben wir hier die Grenze des für die VG verfügbaren Platzes erreicht:

# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 1008M  854M  104M  90% /srv/base
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree 
  vg_critical   2   2   0 wz--n- 8.09g 92.00m

Das macht nichts, da es mit LVM möglich ist, physische Datenträger zu bestehenden Volume-Gruppen hinzuzufügen. Wir könnten zum Beispiel festgestellt haben, dass die Partition sdb1, die bisher außerhalb des LVM verwendet wurde, nur Archivdateien enthält, die nach lv_backups verschoben werden könnten. Wir können sie dann neu verwenden und in die Volume-Gruppe integrieren und so zusätzlichen Platz gewinnen. Hierzu dient der Befehl vgextend. Natürlich muss die Partition zunächst als physischer Datenträger eingerichtet werden. Sobald die VG erweitert worden ist, können wir ähnliche Befehle wie zuvor verwenden, um zunächst das logische Volume und anschließend das Dateisystem zu vergrößern:

# pvcreate /dev/sdb1
  Writing physical volume data to disk "/dev/sdb1"
  Physical volume "/dev/sdb1" successfully created
# vgextend vg_critical /dev/sdb1
  Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
  VG          #PV #LV #SN Attr   VSize VFree
  vg_critical   3   2   0 wz--n- 9.09g 1.09g
# [...]
[...]
# df -h /srv/base/
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base  2.0G  854M  1.1G  45% /srv/base

WEITERE SCHRITTE Weitergehender LVM

LVM wird auch weitergehenden Einsätzen gerecht, bei denen viele Einzelheiten von Hand festgelegt werden können. So kann ein Administrator zum Beispiel die Größe der Blöcke, aus denen physische oder logische Datenträger bestehen, wie auch ihre physische Anordnung genau einstellen. Es ist auch möglich, Blöcke in andere PVs zu verschieben, um zum Beispiel die Leistung fein abzustimmen, oder etwas alltäglicher, um ein PV leerzuräumen, wenn man die entsprechende physische Platte aus der VG entfernen muss (um sie einer anderen VG zuzuordnen oder vollständig aus dem LVM zu entfernen). Die Handbuchseiten, die die Befehle erläutern, sind meist deutlich und ausführlich. Ein guter Einstieg ist die Handbuchseite lvm(8).

12.1.3. RAID oder LVM?

Sowohl RAID als auch LVM bieten eindeutige Vorteile, sobald man den einfachen Fall eines Arbeitsplatzrechners mit einer einzigen Festplatte, bei der sich die Art der Nutzung im Laufe der Zeit nicht ändert, verlässt. RAID und LVM gehen jedoch in zwei verschiedene Richtungen mit unterschiedlichen Zielen, und man fragt sich zu Recht, welches man anwenden soll. Die richtige Antwort hängt natürlich von den jetzigen und voraussichtlichen Anforderungen ab.

Es gibt einige einfache Fälle, in denen sich diese Frage nicht wirklich stellt. Wenn es erforderlich ist, Daten vor Hardwareausfällen zu schützen, wird natürlich RAID auf einer redundanten Anordnung von Platten eingerichtet, da LVM dieses Problem nicht wirklich anspricht. Falls andererseits Bedarf an einem flexiblen Speichersystem besteht, bei dem die Datenträger von der physischen Anordnung der Platten unabhängig sind, hilft RAID nicht viel, und die Wahl fällt natürlich auf LVM.

HINWEIS Wenn es auf Performance ankommt…

Wenn es auf die Schreib-/Lese-Geschwindigkeit ankommt, vor allem auf die Zugriffszeit, dann hat die Verwendung von LVM und/oder RAID in einer seiner vielen Ausprägungen möglicherweise Einfluss auf die Performance. Das kann die Entscheidung, welche Lösung gewählt werden soll, beeinflussen. Jedoch sind diese Unterschiede in der Perormance gering und nur in wenigen Fällen messbar. Wenn es auf Performance ankommt, kann man mit nicht drehenden Speichermedien die besten Resultate erzielen (solid-state drives or SSDs); Dabei sind die Kosten pro Megabyte höher als bei Standardplatten und ihre Kapazität ist üblicherweise geringer, aber sie bieten ausgezeichnete Performance bei zufällig verteilten Zugriffen. Wenn das Nutzungsprofil viele Lese-/Schreibzugriffe über das ganze Dateisystem verteilt beinhaltet, dann ist der Vorteil, wenn sie auf SSD ausgeführt werden, weit größer, als das, was Sie gewinnen können, wenn Sie LVM einem RAID vorziehen oder umgekehrt. In diesen Fällen, sollte die Entscheidung nach anderen Kriterien als der reinen Zugriffsgeschwindigkeit erfolgen, denn Geschwindigkeitsanforderungen werden am besten bei Verwendung von SSDs erfüllt.

Der dritte bemerkenswerte Anwendungsfall liegt vor, wenn man einfach zwei Platten zu einem Datenträger zusammenfassen möchte, entweder aus Gründen der Leistung oder um ein einziges Dateisystem zu haben, das größer als jede der verfügbaren Platten ist. Dieser Fall kann sowohl mit einem RAID-0 (oder sogar einem linearen RAID) als auch mit einem LVM-Volume gelöst werden. In dieser Situation, und falls es keine sonstigen Anforderungen gibt (zum Beispiel, mit den übrigen Rechnern konform zu bleiben, falls diese nur RAID verwenden), wird häufig LVM die Konfiguration der Wahl sein. Die anfängliche Einrichtung ist kaum komplizierter, aber die etwas höhere Komplexität wird durch die außergewöhnliche Flexibilität wettgemacht, die LVM bietet, wenn sich die Anforderungen ändern oder wenn neue Platten hinzugefügt werden müssen.

Dann gibt es natürlich den wirklich interessanten Fall, bei dem das Speichersystem sowohl gegen Hardwareausfall beständig gemacht werden muss als auch flexibel bei der Datenträgeraufteilung. Weder RAID noch LVM allein kann beide Ansprüche erfüllen. Kein Problem, hier verwenden wir beide gleichzeitig - oder vielmehr übereinander. Der Aufbau, der quasi zum Standard geworden ist, seit RAID und LVM die Einsatzreife erreicht haben, besteht darin, zunächst Datenredundanz sicherzustellen, indem Platten zu einer kleinen Anzahl großer RAID-Anordnungen zusammengefasst werden, und dann diese RAID-Anordnungen als physische LVM-Volumes zu verwenden. Anschließend werden diese LVs in logische Partitionen für die Dateisysteme aufgeteilt. Der Grund für diesen Aufbau ist, dass, wenn eine Platte ausfällt, nur wenige der RAID-Anordnungen wiederhergestellt werden müssen, wodurch die Zeit, die der Administrator für die Wiederherstellung aufwenden muss, begrenzt bleibt.

Nehmen wir ein konkretes Beispiel: die Werbeabteilung bei Falcot Corp. benötigt einen Arbeitsplatzrechner für die Videobearbeitung, das Budget der Abteilung reicht aber nicht aus, um von Grund auf in Hochleistungsgeräte zu investieren. Es wird daher beschlossen, sich hierbei auf die Geräte zu beschränken, die für die grafische Art der Arbeit spezifisch sind (Bildschirm und Grafikkarte), und für die Speicherung bei normaler Hardware zu bleiben. Es ist jedoch allgemein bekannt, dass digitales Video einige besondere Ansprüche an die Speicherung stellt: der Umfang der zu speichernden Daten ist hoch, und die Durchsatzgeschwindigkeit für das Lesen und Schreiben dieser Daten ist für die Gesamtleistung des Systems wichtig (wichtiger als zum Beispiel die typische Zugriffszeit). Diese Anforderungen müssen mit der normalen Hardware erfüllt werden, in diesem Fall mit zwei 300 GB SATA-Festplatten. Die Systemdaten und einige Anwenderdaten müssen außerdem gegen Hardwareausfall beständig gemacht werden. Bearbeitete Videoclips müssen wirklich sicher sein, während dies bei Videoabschnitten, die noch nicht editiert wurden, weniger kritisch ist, da es sie noch auf den Videobändern gibt.

RAID-1 und LVM werden kombiniert, um diese Ansprüche zu erfüllen. Die Platten werden an zwei verschiedene SATA-Controller angeschlossen, um den parallelen Zugriff zu optimieren und das Risiko eines gleichzeitigen Ausfalls zu verringern, und werden demnach als sda und sdc angezeigt. Sie werden beide in gleicher Weise wie folgt partitioniert:

# fdisk -l /dev/sda

Disk /dev/hda: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00039a9f

   Device Boot      Start      End      Blocks   Id  System
/dev/sda1   *           1      124      995998+  fd  Linux raid autodetect
/dev/sda2             125      248      996030   82  Linux swap / Solaris
/dev/sda3             249    36483   291057637+   5  Extended
/dev/sda5             249    12697    99996561   fd  Linux raid autodetect
/dev/sda6           12698    25146    99996561   fd  Linux raid autodetect
/dev/sda7           25147    36483    91064421   8e  Linux LVM

Die ersten Partitionen beider Platten (etwa 1 GB) werden zu einem RAID-1-Datenträger namens md0 zusammengefasst. Dieser Spiegel wird direkt dazu benutzt, das Wurzeldateisystem aufzunehmen.
Die Partitionen sda2 und sdc2 werden als Auslagerungspartitionen verwendet und stellen insgesamt 2 GB an Auslagerungsspeicher bereit. Zusammen mit 1 GB RAM hat der Arbeitsplatzrechner somit einen reichlichen Umfang an verfügbarem Speicher.
Die Partitionen sda5 und sdc5 wie auch sda6 und sdc6 werden zu zwei neuen RAID-1-Datenträgern namens md1 und md2 mit einer Größe von je 100 GB zusammengefasst. Diese beiden Spiegel werden als physische Datenträger für LVM initialisiert und der Volumengruppe vg_raid zugewiesen. Diese VG umfasst somit etwa 200 GB an sicherem Speicherplatz.
Die übrigen Partitionen, sda7 und sdc7 werden direkt als physische Datenträger benutzt und einer weiteren VG namens vg_bulk zugewiesen, die daher auch etwa 200 GB Speicherplatz bekommt.

Nachdem die VGs erstellt sind, können sie auf sehr flexible Weise partitioniert werden. Man muss dabei beachten, dass die in vg_raid erstellten LVs selbst dann erhalten bleiben, wenn eine der Platten ausfällt, wohingegen dies bei den in vg_bulk erstellten LVs nicht der Fall ist. Andererseits werden letztere parallel auf beiden Platten bereitgestellt, wodurch höhere Lese- und Schreibgeschwindigkeiten für große Dateien möglich sind.

Wir erstellen daher auf vg_raid die LVs lv_usr, lv_var und lv_home zur Aufnahme der entsprechenden Dateisysteme. Ein weiteres großes LV, lv_movies, dient dazu, die endgültigen Versionen der Filme nach ihrer Editierung aufzunehmen. Die andere VG wird in ein großes lv_rushes für Daten direkt aus den digitalen Videokameras und ein lv_tmp für temporäre Dateien aufgeteilt. Für den Ort des Arbeitsbereichs ist eine weniger einfache Entscheidung zu treffen: während für diesen Datenträger einerseits gute Leistung erforderlich ist, fragt es sich, ob es andererseits wert ist, den Verlust der Arbeit zu riskieren, wenn während des Editierens eine Platte ausfällt. In Abhängigkeit von der Antwort auf diese Frage wird das entsprechende LV auf der einen oder der anderen VG erstellt.

Wir haben jetzt sowohl einige Redundanz für wichtige Daten als auch große Flexibilität in der Art, wie der verfügbare Platz auf die Anwendungen verteilt ist. Sollten später neue Programme installiert werden (zum Beispiel zum Editieren von Audiodateien), kann das LV, das /usr/ enthält, problemlos vergrößert werden.

HINWEIS Warum drei RAID-1-Datenträger?

Wir hätten nur einen RAID-1-Datenträger einrichten können, um als physischer Datenträger für vg_raid zu dienen. Warum haben wir dann drei erstellt?

Der Grund für die erste Unterteilung (in md0 und die übrigen) liegt in der Datensicherheit: Daten, die auf beide Komponenten eines RAID-1-Spiegels geschrieben werden, sind identisch, und es ist daher möglich, die RAID-Ebene zu umgehen und eine der Platten direkt einzuhängen. Im Falle eines Kernelfehlers oder falls die LVM-Metadaten beschädigt werden, ist es immer noch möglich, ein minimales System zu starten, um damit auf wichtige Daten wie die Belegung der Platten in den RAID- und LVM-Volumes zuzugreifen. Die Metadaten können dann wiederhergestellt und die Dateien wieder zugänglich gemacht werden, so dass das System in seinen Ausgangszustand zurückversetzt werden kann.

Der Grund für die zweite Unterteilung (in md1 und md2) ist weniger offensichtlich und hängt eher mit der Erkenntnis zusammen, dass die Zukunft unsicher ist. Wenn der Arbeitsplatzrechner erstmals eingerichtet wird, sind die genauen Speichererfordernisse nicht unbedingt mit absoluter Sicherheit bekannt; außerdem können sie sich im Laufe der Zeit verändern. In unserem Fall können wir den tatsächlichen Bedarf an Speicherplatz für Videoszenen und vollständige Videoclips nicht im Vorhinein kennen. Falls ein bestimmter Clip eine sehr hohe Anzahl an Szenen benötigt, und die VG für redundante Daten weniger als halb voll ist, können wir einen Teil ihres nicht genutzten Platzes anderweitig verwenden. Wir können einen der physischen Datenträger entfernen, zum Beispiel md2 aus vg_raid, und ihn entweder direkt vg_bulk zuordnen (falls die voraussichtliche Dauer des Einsatzes kurz genug ist, um den vorübergehenden Leistungsabfall in Kauf zu nehmen), oder die RAID-Anordnung auf md2 auflösen und seine Komponenten sda6 und sdc6 in die Massen-VG integrieren (die damit um 200 GB statt um 100 GB anwächst). Der logische Datenträger lv_rushes kann dann nach Maßgabe des Bedarfs vergrößert werden.