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.
