SW-RAID und LVM (Howto)

aus openSUSE, der freien Wissensdatenbank

Installation

Szenario

Eingerichtet wird ein Admin-Server. Der Server dient dazu, zwei andere Server, ein HTTP/Email-Server (Kunden-Server) und ein Spiegel-Server, zu überwachen, zu konfigurieren zu administrieren und zu installieren.

Auf dem Kunden-Server läuft eine MySQL-Datenbank sowie ein Apache für die Webshops sowie ein Postfix/Courier-Server mit Blacklisting und Graylisting und Authentifizierung über MySQL. Der Webshop hat eine Anbindung an eine externe, beim Kunden vorliegende Warenwirtschaft.

Um die Daten und die Konfiguration zu sichern wird ein kompletter Spiegel des Servers aufgesetzt. Der einzige Unterschied besteht in der IP-Adresse. Der Vorteil liegt darin, dass man bei einem Ausfall des Kundenservers durch eine kurze Änderung der IP-Adresse sofort wieder online ist. Alternativ kann auch der Eintrag im Nameserver geändert werden.

Sollte allerdings der Spiegelserver auch ausfallen wäre das ein Katastrophe. (Ähnlich wie bei einem RAID-1 bei dem beide Platten ausfallen...). Denn: ein spiegeln der Daten ist keine Datensicherung, es wird erst dann eine Datensicherung, wenn die Daten noch an einem anderen Platz aufbewahrt werde. Ein anderer Rechner ist zwar ein anderer Platz, aber wenn beide Rechner im gleichen Rechenzentrum stehen und dieses Abbrennt, ist man ohne Datensicherung verloren.

Der Adminserver übernimmt nun verschiedene Aufgaben.

Überwachung

Mittels Nagios werden alle Funktionen und Zustände der beiden Server überwacht. Bei Unregelmäßigkeiten wird per Eskalation die Administratorin benachrichtigt und der Event-Manager gestartet. Letzterer startet cfengine.

Installation

Ein ausgefallener Server wird minimal aufgesetzt, inklusive der Software für cfengine. Cfengine übernimmt dann komplett das Aufspielen jeglicher Software und der Konfiguration.

Build-Server

Zur Pflege eines Servers gehört auch das Einspielen neuer Software oder Software die aus bestimmten Gründen neu kompiliert werden musste. So besitzt die courier-authlib der OpenSuSE 10.1 z.B. keine Unterstützung für MySQL. Solche Software sollte natürlich nicht auf dem Kundenserver bearbeitet werden, ebensowenig auf dem Spiegel-Server, der ja ein exaktes Abbild des Kundenservers darstellen soll.

Konfiguration

Wie schon bei der Installation erwähnt, soll hier mittels cfengine der Server remote konfiguriert werden. Sollten Störungen auftreten so wird cfengine automatisch durch den Event-Manager von Nagios angestoßen und kann entsprechende Umkonfigurationen vornehmen.

Backup

Da ein Spiegel kein vollwertiges Backup ist, werden die Daten auf diesem Rechner nochmal hinterlegt und auf entsprechende Medien gesichert.

Hardware und Einteilung

In dem Rechner befinden sich drei SATA-Festplatten, 2*160GB und 1*200GB

Es macht keinen Sinn SWAP auf ein RAID oder in ein LVM zu legen. Da die SWAP-Daten nur temporäre Speicherauszüge sind, die möglichst schnell geschrieben und gelesen werden sollen/müssen, würde ein LVM, welches Aufgrund des Aufbaus von LVM sehr defragmentiert sein kann Schreib- und Leseoperationen ausbremsen. Bei einem RAID würde die CPU-Belastung zum berechnen der Parität ebenfalls zu einer Verlangsamung führen. Einzig ein RAID-0 wäre sinnvoll, wenn SWAP das nicht schon selbst erledigen würde. Zwei SWAP-Partitionen mit derselben Priorität haben wirken wie ein RAID-0. Das macht natürlich auch nur Sinn, wenn die verschiedenen SWAP-Partitionen auf verschiedenen Platten liegen.

/boot soll aus weiter oben genannten Gründen ebenfalls nicht auf das LVM wohl aber auf ein RAID, genauso wie ein Rescue-System, mit dem man Offline-Arbeiten am Root-Filesystem durchführen kann. Da ein RAID immer voraussetzt, dass die einzelnen Teile des RAIDs gleich groß sind (mehr oder weniger, es gilt die kleinste Einheit als Maß) sind in diesem Fall 40GB auf einer Platte übrig, die mit Sicherheit nicht in einem RAID verwendet werden. In diesem Fall werden sie daher unter anderem für das Rescue-System verwendet.

Festplatteneinteilung:

SWAP

je 2GB, mit gleicher Priorität:

• /dev/sda1
• /dev/sdb1
• /dev/sdc1

/boot

/dev/md0 (RAID-1), jede Partition hat 100MB und ist formatiert mit Ext2:

• /dev/sda2
• /dev/sdb2
• /dev/sdc2)

LVM

/dev/md1 (RAID-5) bestehend aus dem Rest von sda und sdb sowie einer etwa gleich großen Partition auf sdc

• /dev/sda3
• /dev/sdb3
• /dev/sdc3

Rest

Extended Partition als /dev/sdc4 mit dem übriggebliebenen Rest von /dev/sdc. Wird unterteilt in:

• /rescue

  3GB auf /dev/sdc5 mit Ext3 formatiert

  /BUILD

  Dem Rest von sdc als /dev/sdc6, formatiert mit XFS

Der Bootloader ist Lilo, da er eine wesentlich bessere Unterstützung für RAID bietet als GRUB. Bei einem RAID kann sich LILO sogar automatisch auf den verschiedenen Platten installieren und das RAID auch nach dem Ausfall von einer Platte booten. Da das RAID den Ausfall von 2 Platten sowieso nicht verträgt, könnte darauf verzichtet werden, /boot über 3 Platten zu verteilen. Aber mit dem neuen UDEV-Dateisystem kann man sich nicht sicher sein, wie die Hardwarereihenfolge denn nun wirklich ist. Linux mag es anders darstellen, als es das BIOS sieht. Bei normalen Installationen fällt das kaum ins Gewicht, da die Installations-Routine schon dir richtige Platte für den Boot-Loader findet. Da hier aber von einem RAID gebootet werden soll, könnte es passieren, dass das ganze Layout nicht mit der Hardware-Reihenfolge übereinstimmt und man denn von einem RAID booten möchte, welches vom BIOS gar nich gefunden wird, weil es auf weiter hinten liegenden Festplatten liegt.

Volume-Einteilung auf dem LVM (/dev/vg00)

Der Name vg00 ist frei wählbar. YaST schlägt bei der Installation system vor, aber eingebürgert hat sich eigentlich vg für Volume-Groupe, also einer Gruppe von Volumes (hier besteht die Gruppe allerdings aus nur einem RAID-5, nämlich /dev/md1) sowie einer durchgehenden Nummerierung, angefangen bei 00 für die Volume-Group auf der das System liegt:

/ (Root-Filesystem)

7GB - Ext3

/backup

1GB - ReiserFS

/home

1GB - XFS

/srv

1GB - ReiserFS

/var

1GB - ReiserFS

/var/lib

1GB - XFS

Über die Wahl der Dateisysteme

ReiserFS/XFS

ReiserFS kann Online-Expand und Offline-Shrinking, XFS nur Online-Expand. XFS ist allerdings unter Linux das schnellste Dateisystem. ReiserFS wurde deshalb für Dateisysteme gewählt, die eventuell auch ein Shrinking benötigen, wärend XFS für Dateisysteme gewählt wurde, bei denen Shrinking keine Rolle spielt.

Ext2

Ext2 ist sehr schnell und stabil für kleine Dateisystem.

Ext3

dieses Dateisystem soll nach Erfahrungsberichten etwas stabiler als ReiserFS sein. Da ein Shrinking nur Offline geht, wurde dieses Dateisystem für das Root-Filesystem und für das Rescue-Filesystem gewählt. Da später Voraussichtlich das System kein Expand braucht wurde hier zugunsten von Stabilität vor Verfügbarkeit gegen ReiserFS entschieden (Die Autorin selbst hat noch nie Probleme mit ReiserFS gehabt noch kann sie auf irgendwelche Testberichte diesbezüglich zurückgreifen. Es handelt sich um eine Entscheidung die Hörensagen und vermutlich Vorurteile mit einbezieht.)

JFS

JFS ist vergleichbar mit XFS, aber im Umgang mit besonders grossen Dateien bedeutend schneller. Die Verwendung von JFS empfieht sich also bei Verwendung von bis zu mehreren Gigabyte grossen Datenbank-Dateien. XFS ist hingegen im Umgang mit vielen kleinen Dateien schneller.

Durchführung

Der Artikel wird zur Zeit abschnittsweise überarbeitet.
Die Abschnitte über diesem Hinweis sind bereits fertig,
die darunter befinden sich in Arbeit.
--anniyka 15:22, 5. Sep 2006 (UTC)

Im Folgenden werden nun noch die Schritte aufgeführt und, wenn nötig, erklärt. Bei den Erklärungen wird nun davon ausgegangen, dass der Benutzer über ausreichendes Wissen verfügt. Schließlich handelt es sich hier um ein Thema der fortgeschrittenen Systemadministration.

Partitionierung und das Rescuesystem

• Booten von der DVD
• Lizenz akzeptieren etc.
• Minimal-Installation nicht grafisch !!! (Zumindest reinen Serversystemen ...)
• Systemstart (Bootmanager) ändern auf LILO

  SuSE verwendet per Default GRUB als Bootloader. Wenn man dies später ändert, nach der Partitionierung, so ist unter Umständen ein ziemliches Anpassen nötig.

• Partitionierung ändern (Benutzerspezifisch)
  • Partitionen anlagen:
    • sda1, 2GB, SWAP, SWAP
    • sda2, 100MB, nicht formatieren, Typ:0xFD
    • sda3, Rest, nicht formatieren, Typ:0xFD
    • sdb1, 2GB, SWAP, SWAP
    • sdb2, 100MB, nicht formatieren, Typ:0xfD
    • sdb3, Rest, nicht formatieren, Typ:
    • sdc1, 2GB, SWAP, SWAP
    • sdc2, 100MB, nicht formatieren, Typ:0xFD
    • sdc3, wie sda3/sdb3, nicht formatiert:0xFD
    • sdc4, Rest, Extended
    • sdc5, 3GB, Ext3, /
    • sdc6, Rest, XFS, /BUILD
  • RAID für /boot anlegen
    • auf RAID klicken -> RAID anlegen
    • RAID-1 -> weiter
    • Hinzufügen von sda2, sdb2, sdc2
    • Dateisystem Ext2 und Mountpoint /boot -> Beenden
  • RAID für LVM anlegen:
    • auf RAID klicken -> RAID anlegen
    • RAID-5 - weiter
    • Hinzufügen von sda3, sdb3 und sdc3
    • Dateisystem KEINS, Mountpoint KEINER
  • LVM anlegen:
    • auf LVM klicken
    • Name: vg00 -> OK
    • md1 hinzufügen -> weiter

Da im Moment nur das Rescue-System installiert wird, werden noch keine logischen Volumes benötigt. Die Partitionierung wird daher an dieser stelle beendet.

Die Installation wird nun wie gewohnt durchgeführt mit allem, was auf einem 2GB Rescuesystem so Platz hat und man so persönlich braucht. Dabei gilt es zu beachten, daß der Boot-Loader auf Lilo umgestellt werden sollte. Über den Reiter Experten erreicht man das entsprechende Menü. Dabei sollte Lilo im Bootsector der /boot-Partition installiert werden, also in /dev/md0.

Sollte auf dem System vorher schon ein Boot-Loader installiert gewesen sein, womöglich noch im MBR, so sollte der MBR mit generischem Code überschrieben werden.

Nach der Installation des Rescue-Systems kann man sich etwas ausruhen und sich mit watch cat /proc/mdstat den Fortschritt der Synchronisation des RAIDs anschauen. Bei der Größe dieses RAIDs wäre es nicht unbeding ratsam die Installation vorzunehmen, wenn die Synchronisation noch nicht abgeschlossen ist. Ansonsten kann es sein, dass der Server zur Synchronisation später 24 Stunden oder länger dafür benötigt, was er ansonsten innerhalb von 2-3 Stunden abgeschlossen hat.

LVM und das eigentliche System

• Booten von der DVD
• Lizenz akzeptieren etc.
• KDE oder Gnome oder was auch immer nach belieben
• Partitionierung ändern (Benutzerspezifisch)
  • md0 bearbeiten, nicht formatieren, Mountpoint auf /boot setzen
  • Auf LVM klicken
  • vg00 sollte ausgewählt sein -> Weiter
  • Hinzufügen:
    • Name:root, 6GB, Ext3, Mountpoint:/
    • Name:backup, 1GB, ReiserFS, /backup
    • Name:home, 1GB, XFS, /home
    • Name:srv, 1GB, ReiserFS, /srv
    • Name:var, 1GB, ReiserFS, /var
    • Name:var_lib, 1GB, XFS, /var/lib
    • Weiter
  • Beenden
• Den Bootmanager auf LILO ändern und der Ort des Boot-Loader ist wieder /dev/md0

Die Autorin

anniyka