SW-RAID und LVM (Grundlagen)

aus openSUSE, der freien Wissensdatenbank

Einführung

Ein Logical-Volume auf einem Software-RAID aufzusetzen, hört sich für den Laien wahrscheinlich zunächst einmal seltsam an, zumal ja LVM unter Linux selbst auch entsprechende Funktionalitäten mitbringt.

In der professionellen Unix-Welt sind diese Konstellationen allerdings gang und gäbe. Dabei wird das Betriebsystem mit seinen hauptsächlich unveränderlichen Daten auf ein Software-RAID abgespeichert um eine höhere Ausfallsicherheit zu erlangen. Da es sich um Daten handelt, die fast ausschließlich gelesen werden - mit Ausnahme von Logfiles, kleinen Änderungen an Konfigurationsdateien und temporären Dateien, bleibt die CPU-Belastung sehr gering. Hierfür extra ein Hardware-RAID einzusetzen lohnt die Mehrkosten idR nicht. Daten-Partitionen wie für Datenbanken, Home-Verzeichnissen etc. werden in solchen Konstellationen auf externen Hardware-RAIDs oder Filern abgelegt.

Zur Partitionierung wird dann ein Volume-Management mit dem Vorteil herangezogen, dass man im Bedarfsfall Partitionen im laufenden Betrieb verändern kann.

Weiter Vorteile von Volume-Management sind so genannte Snapshots, mit denen es möglich ist, Daten von einem Volume zu einem bestimmten Zeitpunkt zu spiegeln.

Für Home-Verzeichnisse bedeutet dies z.B., dass ein Benutzer innerhalb eines bestimmten Zeitrahmens gelöschte bzw veränderte Dateien aus dem Snapshot wieder herauskopieren kann, ohne erst auf ein Backup zurückgreifen zu müssen.

Datenbanken kann man hierbei z.B. sichern, ohne sie herunterfahren zu müssen. Die Daten liegen auf dem Snapshot und können dann vom Backup-Programm gelesen werden während gleichzeitig auf dem Ursprungs-Volume die Datenbank weiterläuft und benutzt werden kann.

Für den Hausgebrauch reicht ein Software-RAID natürlich aus, da ein einzelner Benutzer es selten schafft, so viele Daten schreibend zu verändern, dass ein merklicher Ansteig der CPU-Belastung oder der Datenleitungen zu den Festplatten vorliegt. Selbst in kleineren Netzen mit mehreren Benutzern ist dies nicht der Fall, wodurch sich das Software-RAID sehr gut für kleine Server eignet und Volume-Management sinnvoll eingesetzt werden kann. Die Geschwindigkeit der Datenübertragung des Netzes ist sowieso langsamer als die Daten verarbeitet werden ...

Beispiel

Als Anwendungsszenario könnte man z.B. einen Subversion-Server nehmen. Eine kleine Entwicklertruppe von vielleicht 10 Personen greift auf ein zentrales Subversion-Repository zu. Zum Einen benötigt man eine gewisse Ausfallsicherheit, die durch das Software-RAID gegeben ist, zum anderen muss man das Repository sichern können (Datensicherheit) möchte aber während dem Zeitraum der Sicherung das Repository nicht abschalten müssen.

Zur Datensicherung wird nun ein Snapshot erzeugt, von dem aus man das Backup startet. Der weitere Vorteil ist, da man vorher nie so genau weiß, wieviel Platz eine Daten-Partition denn nun braucht, z.B. das Repository gegenüber den Home-Verzeichnissen, kann man im Bedarfsfall die Grenzen der Volumes später anpassen.

Vorüberlegung

Begrifflichkeiten

LVM

(Logical Volume Management) Ein größeren Verbund von sogenannten Volumes - als Volumes werden je nach System verschiedene Geräte bezeichnet, zum Beispiel Festplatten, andere RAIDs oder ähnliches - in logische Einheiten (Logical Volumes) unterteilen und verwalten (z.B. verkleinern und vergrößern) zu können nennt man Logical Volume Management.

shrinking, expanding

Das Verkleinern eines Logical Volumes bzw. eines Dateisystems auf dem Logical Volume wird schrinking bezeichnet. Genauer gesagt läuft das verkleinern eines volumes so ab:

• verkleinern des Dateisystems auf dem logischen Volumes
• verkleinern des logischen Volumes bis auf die Größe des Dateisystems

Expandieren oder Vergrößern (expanding) geschieht in umgekehrter Weise wie das Verkleinern.

online, offline

In diesem Fall bedeutet es, ob das Dateisystem gemounted (eingehängt, in Verwendung) ist oder nicht.

RAID

Welches RAID soll man nehmen?, Unter Linux stehen für Software-RAID folgende RAID-Levels zur Auswahl:

RAID-0

Hierbei handelt es sich um so genanntes stripping. Die Daten werden bei Schreibzugriffen auf das RAID in kleine Stücke zerteilt und verschiedene Stücke werden gleichzeitig auf verschiedene Festplatten geschrieben. Dadurch erhält man höherer Schreibraten, nämlich so schnell (sozusagen), wie das größte Stück des letzten Teils auf die langsamste Platte braucht. (Bildlich gesprochen)

RAID ist eine Abkürzung die ursprünglich für Redundant Array of Inexpensive Disks steht. Das Inexpensive wird heute durch Independent ersetzt. In diesem Sinne ist RAID-0 kein RAID, da es keine Redundanz besitzt. In diesem Artikel wird es daher nicht weiter beachtet.

RAID-1

Bei RAID-1 werden jeweils zwei Platten (oder z.B. zwei RAIDs) zusammengefasst. Man erzielt dadurch zwar keinen Geschwindigkeitsvorteil wie bei anderen RAIDs, genausowenig wie einen Sicherheitsvorteil, allerdings gewinnt man einen Vorteil bei der Verfügbarkeit.

Während andere RAID-Systeme eine fehlende Platte nach dem Ersetzen erst aus den Original-Daten und den Parity-Daten errechnen muss und dabei neben viel Zeit auch noch eine hohe CPU-Belastung erwirken, müssen beim RAID-1 nur die Daten wieder auf die andere Platte kopiert werden. Die benötigte Zeit begrenzt sich auf das Kopieren und die CPU-Belastung ist recht gering.

Es werden immer mindestens Paare benötigt.

RAID-4

RAID-4 benutzt eine einzelne Paritäts-Platte. Dadurch ist die maximale Datenrate bei RAID-4 durch die Schreibgeschwindigkeit auf die Paritäts-Platte beschränkt. Da die Paritäts-Platte bei jedem Schreibzugriff ebenfalls benutzt wird ist sie auch die Festplatte welche am häufigsten ausfällt. Die Lese-Geschwindigkeit ist bei sequenziellen Zugriffen schneller als bei einem RAID-5 daher wird diese RAID gerne in solch speziellen Szenarien eingesetzt.

Ansonsten wird diese Art des RAIDs nur selten verwendet; da es hier nur eine Festplatte als Paritäts-Platte zu beschreiben ist entfällt dabei das Verteilen der Paritäts-Informationen auf verschiedene Platten.

Für Daten verfügbar sind in einem RAID-4-Verbund von n Festplatten n-1.

Es werden mindestens drei Festplatten benötigt.

RAID-5

Die am häufigsten benutze Art eines RAIDs. RAID-5 verteilt die Paritäts-Daten über alle Festplatten und erreicht damit vergleichsweise hohe Datendurchsätze beim Schreiben (Ausnahme siehe RAID-4). Die Größe des RAIDs beträgt wie bei RAID-4 n-1.

Es werden wie bei RAID-4 mindestens drei Festplatten benötigt.

RAID-6

RAID-6 ist die RAID-5-Alternative zu RAID-1, zumindest soweit es Datensicherheit und Verfügbarkeit betrifft. RAID-6 verkraftet den Ausfall von zwei Festplatten, da es doppelte Paritäts-Informationen auf den Festplatten verteilt. Allerdings geht dadurch die Geschwindigkeit der Schreibzugriffe gegenüber einem wesentliches mehr an CPU-Belastung zurück.

Bei einem Software-RAID sollte RAID-6 daher nur eingesetzt werden, wenn man auf der einen Seite dieses mehr an Sicherheit benötigt, aber auf der anderen Seite kaum Schreibzugriffe hat. Wenn man allerdings dieses mehr an Sicherheit benötigt sollte man eh zu einem externen RAID greifen.

Die Datengröße beträgt n-2.

Ein RAID-6 benötigt mindestens 4 Festplatten.

RAID-10

Ein RAID-10 ist ein Kombinations-RAID von einem RAID-0 über mehrere RAID-1. Mit anderen Worten, wie beim RAID-0 werden die Daten zerstückelt und dann geschrieben. In diesem Fall aber nicht auf einzelne Festplatten sondern auf RAID-1 wodurch die Daten gespiegelt werden.

Ein RAID-10 verkraftet dadurch den Ausfall von bis zu Hälfte der verwendeten Festplatten, vorausgesetzt es trifft immer nur eine von einem der RAID-1.

Die maximale Größe beträgt n/2.

Es werden mindestens 4 Festplatten benötigt.

Bei einem Software-RAID können sinnvoll RAID-1, RAID-5 und RAID-10 eingesetzt werden, sowie RAID-4, wenn man es fast nur mit sequenziellen Schreibzugriffen zu tun hat. RAID-0 ist ein Thema für Geschwindigkeit, was nicht Thema dieses Artikels ist und wer ein RAID-6 braucht ist normalerweise mit einem externen RAID besser beraten.

Filesystem

Grundsätzliches

Die Überlegung, welches Filesystem zu benutzen ist, ist hier reduziert von vielen Überlegungen wie Lizenz, eigenen Vorlieben, angeblichen und wirklichen Geschwindigkeitstest. Diese Überlegungen sind bei der Verwaltung indes LVM zweitrangig. Die Möglichkeiten der Größenänderung ist in diesem Fall die Hauptüberlegung und dahinter tritt alles andere zurück:

Filesystem	Offline Shrinking	Offline Expansion	Online Shrinking	Online Expansion	Bemerkung
JFS					mount -o remount,resize
XFS					xfs_growfs
ReiserFS					resize_reiserfs
Ext2/3					reseize2fs

Wie man sieht, gibt es einige Unterschiede in den Möglichkeiten des Verkleinern und Vergößerns. Zur Wahl des Filesystems sollte man sich zuerst die Online-Möglichkeiten und dann die Offline-Möglichkeiten anschauen. Wei man sieht, ist keine Filesystem unter Linux derzeit zu einem Online-Shrinking in der Lage. Zu Online-Expansion sind inzwischen alle 4 Dateisysteme in der Lage. Von diesen bietet zwei Filesystem die Möglichkeit, ein Shrinking durchzuführen. Zwar nur Offline aber immerhin. Die Wahl fällt in diesem Fall daher auf ReiserFS oder Ext2/3.

Andere Überlegungen sind natürlich durchaus Möglich, z.B. brauche ich ein überhaupt ein Verkleinern für dieses logische Volumen? Wenn nicht, dann bleibt aus Geschwindigkeitsgründen nur XFS. Brauche ich unbedingt eine Shrinking aber es muss nichts von allem Online sein?? Wenn ja, dann käme auch ein Ext3 in Frage.

Bleibt noch die Frage, welche logischen Volumes brauche ich und wie groß müssen die sein... Nun, die Größe dürfte nicht wirklich interessant sein, denn genau deswegen verwendet man das ganze ja. Bei einigen Dateisystem kann man sich über eine gewisse Anfangsgröße zur Installation Gedanken machen.

Mountpoints

/ (Root-Filesystem)

Das Root-Filesystem ist wohl das was in der Regel ein Verkleinern bzw. Vergößern am wenigsten braucht. Normalerweise schnippelt man von einem Root-Filesystem alles weg, was solche Operationen benötigen könnte, packt es in eigene Volumes rein und streitet sich mit den Verfechtern der beiden Lager Root-Filesystem-auf-Volume und Root-Filesystem-nicht-auf-Volume.

Allerdings kann man sich aus dem Streit auch raushalten und einfach folgende 2 Überlegungen beachten:

• Wenn man schon mal ein RAID darunter hat, um die Daten zu sichern, ist es Recht kompliziert, kein Volume zu verwenden. Genauergesagt muss man das RAID dann kleiner machen und eigentlich noch ein extra RAID für das Root-Filesystem anlegen. Dar Aufwand lohnt sich eigentlich nicht, da es keinen Nachteil ergibt, ob man das Root-Filesystem nun in einem Volume hat oder nicht.
• Es ist ganz nett, das Root-Filesystem nach der Installation auf die tatsächlich benötigte Größe zu verkleiner, das spart Platz. Sollte man später, weil irgendein neues Tool unbedingt auf das Root-Filesystem muss, das ganze ein wenig vergößern müssen, hat man es ebenfalls gut getroffen.

Vermeintliche Nachteile eines Root-Filesystems auf einem Volume werden durch durch das drunterliegende RAID auf jeden Fall wieder wettgemacht.

/boot

Um ein LVM zu betreiben muss der Kernel entweder LVM-Support haben, oder über eine initrd verfügen. Da eine initrd sehr praktisch ist legt man der Einfachheit halber ein kleines RAID-1 für /boot an. Dieses /boot kann dann auch von einem Rescue-System verwendet werden, welches man für Reparatur-Zwecke am LVM ebenfalls anlegen sollte.

/home

In diesem Verzeichnis liegen traditionell die Benutzer-Verzeichnisse. Snapshots zur Datensicherung werden zwar nicht gebraucht, aber sie erleichtern das Leben, falls ein Benutzer versehentlich Dateien/Daten gelöscht hat. Er braucht die Sachen dann nur aus dem Snapshot zu kopieren.

/opt

Diese Verzeichnis dient für Optionale Software, wobei damit große Softwarepakete wie auch KDE oder Gnome gemeint sind. Sollten weitere Softwarepakete in Planung sein, so empfiehlt sich das Anlagen eines solchen logischen Volumes.

/srv

/srv ist ein relativ junges Verzeichnis im traditionellen Unix-Baum. Nachdem es lange keinen fest definierten Ort für ein Document-Root für z.B. einen HTTP-Server oder einen FTP-Server gab und die Streitereien darüber groß waren, legte man ein neues Verzeichnis an.

/srv/*

Derzeit liegt in der Hauptsache der HTTP_Server und der FTP-Server mit seinem Document-Root dort (/srv/www, /srv/ftp), aber man kann dort beliebige Server unterbringen, z.B. Subversion oder CVS. Je nach Einsatzzweck empfiehlt es sich, dann, für solche Server eigene logische Volumes anzulegen.

Z.B. liegen auf einem Webserver nur statische Daten, die leicht beim Backup gesichert werden können. Für diese Daten braucht es kein Snapshot. Für die Daten von z.B. Subversion wäre ein Snapshot aber von Vorteil. Man hätte also die logischen Volumes /srv und /srv/subversion.

/usr

Mit /usr verhält es sich ähnlich wie mit /opt, nur dass es sich um kleinere Pakete handelt, die in der Regel durch wenige Befehle gekennzeichnet sind. Neben befehlen wie sed oder gawk sind das auch solche Sachen wie z.B. der Apache Webserver.

/usr/local

Dieses Dateisystem dient dazu, wenn der Administrator ausschließlich für den lokalen Rechner bestimmte Daten(!!) installiert. Systemsoftware darf sich selbst hier nicht installieren, da das Verzeichnis bei Systemupdates etc. sicher sein muss. Liegen viele solche Daten vor, sollte man /usr/local auf ein eigenes logisches Volume unterbringen.

/usr/share

Hier werden Daten abgespeichert, die von Programmen benutz werden, z.B. Sprachanpassungen, Bilder etc. /usr/share ist dabei gedacht, im Netzwerk diese Daten verteilen zu können, so dass die Daten nicht öfters auf jedem Rechner zur Verfügung gestellt werden müssen.

/usr/src

Wenn jemand auf einer Produktivumgebung unbedingt meint, den neuseten Kernel hier ablegen zu müssen und selber zu kompilieren, dann ist ein eigenes logisches Volume für /usr/src sicher nicht schlecht.

/var

/var dient dazu, wenn Programme variable Daten ablegen müssen, z.B. Log-Dateien, PID-Files, oder die Daten des SQL-Servers. Letzerer wäre inzwischen aber besser in /srv aufgehoben.

/var/lib

Wie schon erwähnt wäre ein SQL-Server mittlerweile wohl besser unter /srv aufgehoben, aber aus historischen Gründen liegt er noch unter /var und da im Besondern, wie fast alle anderen Server auch, unter /var/lib. Um einen SQL-Server zu sichern muss man entweder den Server runterfahren (bzw. zum Schreiben sperren), oder eben, wie auch unter /srv/* erwähnt per Snapshot sichern.

Zu Beachten: Unter /srv sollten Server liegen, die Daten von/für Benutzer bereithalten. Server die unter /var liegen benötigen die Daten für sich selbst um arbeiten zu können also z.B. der DHCP-Server, der DNS-Server etc.

/var/log

Die Daten hier wachsen mit der Zeit an... Wenn man Anpassungen vornehmen muss, ist dies mit einem LVM leicht erledigt.

Anfangsgrößen

Anhand dieser Überlegungen sollte man sich ein gutes Bild von den benötigten Dateisystemen machen können, um den eigenen Anforderungen gerecht zu werden. Hierzu noch einige Hinweise zu den Anfangsgrößen einiger LVs mit denen man soweit gut unter OpenSuSE zurecht kommen sollte:

• /: Normalerweise zwischen 1GB und 6GB. Zur Installation am besten 6GB-10GB verwenden. Als Rescue-System (Minimal-installation mit einigen zusätzlichen Paketen) 1GB-3GB (ReiserFS oder Ext3)
• /boot: 100MB (Ext2 zu empfehlen)
• /home, /srv, /var: je etwa 1GB (Je nach Anwendung XFS, ReiserFS, Ext3, zu den Überlegungen siehe oben)

Die Autorin

anniyka