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 zur Sicherheit und Verfügbarkeit 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 Laufwerke 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 einem physischen Laufwerk 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 und Datenverfügbarkeit zu garantieren. Das grundlegende 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, sondern die Leistung zu erhöhen, da (wie beim linearen RAID) die Verfügbarkeit der Daten gefährdet ist, sobald eine Platte ausfällt: 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 Laufwerke werden vollständig vom RAID-Gerät ausgenutzt, daher sollten sie die gleiche Größe haben, um keine Leistung zu verlieren.
Die Nutzung von RAID-0 schrumpft, die Nische wird von LVM gefüllt (siehe weiter 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: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail.
# mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Feb 28 01:54:24 2022
Raid Level : raid0
Array Size : 8378368 (7.99 GiB 8.58 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon Feb 28 01:54:24 2022
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Layout : -unknown-
Chunk Size : 512K
Consistency Policy : none
Name : debian:0 (local to host debian)
UUID : a75ac628:b384c441:157137ac:c04cd98c
Events : 0
Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sdb
1 8 16 1 active sync /dev/sdc
# mkfs.ext4 /dev/md0
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done
Creating filesystem with 2094592 4k blocks and 524288 inodes
Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 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.8G 24K 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 (Mehrfachgerät) 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 ergibt) 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/sdc2) exceeds size (4189184K) 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 : Mon Feb 28 02:07:48 2022
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon Feb 28 02:08:09 2022
State : clean, resync
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : resync
Rebuild Status : 13% complete
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 17
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
1 8 48 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:
Version : 1.2
Creation Time : Mon Feb 28 02:07:48 2022
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Update Time : Mon Feb 28 02:15:34 2022
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
Consistency Policy : resync
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 19
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
- 0 0 1 removed
1 8 48 - 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:
Version : 1.2
Creation Time : Mon Feb 28 02:07:48 2022
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Mon Feb 28 02:25:34 2022
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1
Consistency Policy : resync
Rebuild Status : 47% complete
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 39
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
2 8 64 1 spare rebuilding /dev/sdf
1 8 48 - faulty /dev/sde
# [...]
[...]
# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Mon Feb 28 02:07:48 2022
Raid Level : raid1
Array Size : 4189184 (4.00 GiB 4.29 GB)
Used Dev Size : 4189184 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
Update Time : Mon Feb 28 02:25:34 2022
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 1
Spare Devices : 0
Consistency Policy : resync
Name : debian:1 (local to host debian)
UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8
Events : 41
Number Major Minor RaidDevice State
0 8 34 0 active sync /dev/sdd2
2 8 64 1 active sync /dev/sdf
1 8 48 - 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 34 0 active sync /dev/sdd2
2 8 64 1 active sync /dev/sdf
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
Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the sde disk failure had been real (instead of simulated) and the system had been restarted without removing this sde disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. In reality this leads to the RAID starting from the individual disks alternately - distributing the data also alternately, depending on which disk started the RAID in degraded mode Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an md1 on the old server, and the new server already has an md1, one of the mirrors would be renamed.
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
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# 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*
# 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/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1
# This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf
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/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0
ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1
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.
Einige PVs können 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, sodass 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:
# 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 yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B
# 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.00g 3.00g
/dev/sdd lvm2 --- 4.00g 4.00g
/dev/sdf1 lvm2 --- 4.00g 4.00g
/dev/sdf2 lvm2 --- 5.00g 5.00g
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.
# 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 7.99 GiB
PE Size 4.00 MiB
Total PE 2046
Alloc PE / Size 0 / 0
Free PE / Size 2046 / 7.99 GiB
VG UUID JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G
# 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- 7.99g 7.99g
vg_normal 3 0 0 wz--n- <11.99g <11.99g
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 Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd
LV Write Access read/write
LV Creation host, time debian, 2022-03-01 00:17:46 +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 11.98G vg_normal
Rounding up size to full physical extent 11.98 GiB
Rounding up size to full physical extent 11.98 GiB
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----- 11.98g
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 Mar 1 00:17 control
lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_critical-lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar 1 00:17 vg_critical-lv_files -> ../dm-0
lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_normal-lv_backups -> ../dm-2
# ls -l /dev/dm-*
brw-rw---- 1 root disk 253, 0 Mar 1 00:17 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Mar 1 00:19 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Mar 1 00:19 /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 Mar 1 00:19 lv_base -> ../dm-1
lrwxrwxrwx 1 root root 7 Mar 1 00:17 lv_files -> ../dm-0
# ls -l /dev/vg_normal
total 0
lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_backups -> ../dm-2
Die LVs können genau wie Standard-Partitionen benutzt werden:
# mkfs.ext4 /dev/vg_normal/lv_backups
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done
Creating filesystem with 3140608 4k blocks and 786432 inodes
Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 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 24K 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 4.9G 4.2G 485M 90% /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- 7.99g 1.99g
# lvresize -L 6G vg_critical/lv_files
Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents).
Logical volume vg_critical/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---- 6.00g
# resize2fs /dev/vg_critical/lv_files
resize2fs 1.46.2 (28-Feb-2021)
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 1572864 (4k) blocks long.
# df -h /srv/files/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /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 974M 883M 25M 98% /srv/base
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 2 2 0 wz--n- 7.99g 1016.00m
No matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb3 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:
# pvcreate /dev/sdb3
Physical volume "/dev/sdb3" successfully created.
# vgextend vg_critical /dev/sdb3
Volume group "vg_critical" successfully extended
# vgdisplay -C vg_critical
VG #PV #LV #SN Attr VSize VFree
vg_critical 3 2 0 wz--n- <12.99g <5.99g
# lvresize -L 2G vg_critical/lv_base
[...]
# resize2fs /dev/vg_critical/lv_base
[...]
# df -h /srv/base/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_critical-lv_base 2.0G 886M 991M 48% /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.
Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited video clips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.
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:
# sfdisk -l /dev/sda
Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: SAMSUNG MZ7LM960
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: gpt
Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 100667391 100663296 48G Linux RAID
/dev/sda3 100667392 134221823 33554432 16G Linux RAID
/dev/sda4 134221824 763367423 629145600 300G Linux RAID
/dev/sda5 763367424 1392513023 629145600 300G Linux RAID
/dev/sda6 1392513024 1875384974 482871951 230.3G Linux LVM
The first partitions of both disks are BIOS boot partitions.
The next two partitions sda2 and sdc2 (about 48 GB) are assembled into a RAID-1 volume, md0. This mirror is directly used to store the root filesystem.
The sda3 and sdc3 partitions are assembled into a RAID-0 volume, md1, and used as swap partition, providing a total 32 GB of swap space. Modern systems can provide plenty of RAM and our system won't need hibernation. So with this amount added, our system will unlikely run out of memory.
The sda4 and sdc4 partitions, as well as sda5 and sdc5, are assembled into two new RAID-1 volumes of about 300 GB each, md2 and md3. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid volume group. This VG thus contains about 600 GB of safe space.
The remaining partitions, sda6 and sdc6, are directly used as physical volumes, and assigned to another VG called vg_bulk, which therefore ends up with roughly 460 GB of space.
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_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 Bearbeitung 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 Bearbeitens eine Platte ausfällt. In Abhängigkeit von der Antwort auf diese Frage wird das entsprechende LV entweder auf der einen oder auf der anderen VG erstellt.
Wir haben jetzt sowohl einiges an Redundanz für wichtige Daten als auch große Flexibilität in der Art, wie der verfügbare Platz auf die Anwendungen verteilt ist.
