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.
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.
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 sich als physikalische Platte darstellt, obwohl der Gerätename sich davon unterscheidet (abhängig vom Treiber).
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.
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.
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 : Wed May 6 09:24:34 2015
Raid Level : raid0
Array Size : 8387584 (8.00 GiB 8.59 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Wed May 6 09:24:34 2015
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.12 (29-Aug-2014)
Creating filesystem with 2095104 4k blocks and 524288 inodes
Filesystem UUID: fff08295-bede-41a9-9c6a-8c7580e520a6
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 18M 7.4G 1% /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 : Wed May 6 09:30:19 2015
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 : Wed May 6 09:30:40 2015
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“ oder "sauberen" 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.
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 : Wed May 6 09:39:39 2015
State : clean, 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
2 0 0 2 removed
1 8 64 - faulty /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 : Wed May 6 09:48:49 2015
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 /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
[...]
Update Time : Wed May 6 09:49:08 2015
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 /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.
LVM, der Logical Volume Manager, ist ein weiterer Ansatz zur Abstraktion logischer Volumes von ihren physischen Geräten, der sich auf die Erhöhung der Flexibilität und nicht auf die Erhöhung der Zuverlässigkeit konzentriert. LVM erlaubt es, ein logisches Volume transparent für die Anwendungen zu ändern; es ist beispielsweise möglich, neue Platten hinzuzufügen, die Daten darauf zu migrieren und die alten Platten zu entfernen, ohne das Volume zu deinstallieren.
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
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
Physical volume "/dev/sdc3" successfully created
Physical volume "/dev/sdd" successfully created
Physical volume "/dev/sdf1" successfully created
Physical volume "/dev/sdf2" successfully created
# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/sdb2 lvm2 --- 4.00g 4.00g
/dev/sdc3 lvm2 --- 3.09g 3.09g
/dev/sdd lvm2 --- 4.00g 4.00g
/dev/sdf1 lvm2 --- 4.10g 4.10g
/dev/sdf2 lvm2 --- 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, 2015-06-10 06:10:50 -0400
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% Meta% Move Log Cpy%Sync 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.
Logische Volumes werden nach ihrer Erstellung zu Blockgerätedateien in /dev/mapper/:
# ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Jun 10 16:52 control
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2
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 Jun 10 17:05 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Jun 10 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.12 (29-Aug-2014)
Creating filesystem with 3145728 4k blocks and 786432 inodes
Filesystem UUID: b5236976-e0e2-462e-81f5-0ae835ddab1d
[...]
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 30M 12G 1% /srv/backups
# [...]
[...]
# cat /etc/fstab
[...]
/dev/vg_critical/lv_base /srv/base ext4 defaults 0 2
/dev/vg_critical/lv_files /srv/files ext4 defaults 0 2
/dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2
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% Meta% Move Log Cpy%Sync 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
Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 7.00 GiB (1792 extents).
Logical volume lv_files successfully resized
# lvdisplay -C vg_critical/lv_files
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_files vg_critical -wi-ao-- 7.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/vg_critical/lv_files is now 1835008 (4k) 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
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
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
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.
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/sda: 300 GB, 300090728448 bytes, 586114704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00039a9f
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 1992060 1990012 1.0G fd Linux raid autodetect
/dev/sda2 1992061 3984120 1992059 1.0G 82 Linux swap / Solaris
/dev/sda3 4000185 586099395 582099210 298G 5 Extended
/dev/sda5 4000185 203977305 199977120 102G fd Linux raid autodetect
/dev/sda6 203977306 403970490 199993184 102G fd Linux raid autodetect
/dev/sda7 403970491 586099395 182128904 93G 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.
