Debian Lenny auf einem Rootserver mit Raid-1 und LVM

Das ist ein Update zu meiner alten Anleitung. Der Unterschied zur alten Anleitung:

  • Dieses Mal soll ein Server unter Debian Lenny eingerichtet werden
  • Swap liegt ebenfalls im Raid
  • Der Server soll mit OpenVZ virtualisierte Maschinen hosten
  • Das root-Dateisystem soll ebenfalls im LVM liegen, damit wir beim Backup konsistente Snapshots vom gesamten System machen können

Hier also das Update zu meiner rundum-sorglos copy&paste-Anleitung zur Einrichtung von

Debian Lenny auf einem Rootserver mit Raid-1 und LVM


Der Hoster in diesem Beispiel ist Hetzner, das kann man aber auch auf andere Systeme übertragen. Ausgestattet der EQ4-Server mit 2x750GB SATA Platten. Das Ziel ist, ein System aufzusetzen, dass die SATA-Platten im RAID-1 spiegelt und darauf ein LVM betreibt.

/etc/network/interfaces

Zunächst wird das default-System gebootet und die /etc/network/interfaces gesichert. Die brauchen wir später.

Partitionierung

Da scheiden sich die Geister, vorgeschlagen wird folgende Aufteilung der Platten:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         523     4200966   fd  Linux raid autodetect
/dev/sda2             524         646      987997+  fd  Linux raid autodetect
/dev/sda3             647       91201   727383037+  fd  Linux raid autodetect

Zuerst kommt die Swap-Partition, dann /boot und der Rest geht für’s LVM drauf.

Die auf /dev/sda eingerichtete Partitionstabelle kann nun auf /dev/sdb gespiegelt werden:

# sfdisk -d /dev/sda | sfdisk --force /dev/sdb

Jetzt muss ggf neu gebootet werden, weil der Kernel sonst noch mit der alten Partitionstabelle arbeitet. Danach kann man den

Raid erzeugen

Swap:

mdadm -v --create /dev/md0 --level=mirror --raid-devices=2 /dev/sda1 /dev/sdb1

/boot

mdadm -v --create /dev/md1 --level=mirror --raid-devices=2 /dev/sda2 /dev/sdb2

(LVM)

mdadm -v --create /dev/md2 --level=mirror --raid-devices=2 /dev/sda3 /dev/sdb3

Am besten wartet man jetzt die 120 Minuten, bis das Raid synchronisiert ist:

watch cat /proc/mdstat

Man kann aber auch gleich fortfahren und den

Swap einrichten

rescue:~# mkswap /dev/md0 
Setting up swapspace version 1, size = 4301713 kB
no label, UUID=861f444a-13d6-4640-8fc9-568eafe3a315

/boot formatieren

mkfs.ext3 /dev/md1

LVM anlegen

Zuerst wird /dev/md2 als physical volume angelegt:

pvcreate /dev/md2

Dann wird die Volumegroup „mainvg“ darauf erzeugt:

vgcreate mainvg /dev/md2

Jetzt die Volumes anlegen:

lvcreate -n usr -L 2G mainvg
lvcreate -n home -L 2G mainvg
lvcreate -n root -L 2G mainvg
lvcreate -n tmp -l 1G mainvg
lvcreate -n var -l 300G mainvg

Für /root und /usr reichen 2GB locker, /tmp sollte auch mit einem GB klar kommen. Das Home soll nicht bewohnt sein – die User leben in Virtuellen Maschinene – deswegen gibt’s hier ebenfalls nur 2GB. Das letzte lvcreate weist dem Logical Volume „var“ 300GB zu. Ein bisschen Platz (ca. 10% des gesamten VLMs) brauchen wir als Reserve für die Snapshots (die kommen beim Backup ins Spiel). Ich belege nicht gleich 600GB, weil man die Partition ja immer noch vergrößern kann Problem.

Das ganze nochmal prüfen:

#  pvscan
  PV /dev/md2   VG mainvg   lvm2 [693,68 GB / 386,68 GB free]
  Total: 1 [693,68 GB] / in use: 1 [693,68 GB] / in no VG: 0 [0   ]
 
# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "mainvg" using metadata type lvm2
 
# lvscan
  ACTIVE            '/dev/mainvg/usr' [2,00 GB] inherit
  ACTIVE            '/dev/mainvg/root' [2,00 GB] inherit
  ACTIVE            '/dev/mainvg/home' [2,00 GB] inherit
  ACTIVE            '/dev/mainvg/var' [300,00 GB] inherit
  ACTIVE            '/dev/mainvg/tmp' [1,00 GB] inherit

/usr, /var, /home, /tmp und / formatieren

mkfs.ext3 /dev/mainvg/usr
mkfs.ext3 /dev/mainvg/var
mkfs.ext3 /dev/mainvg/tmp
mkfs.ext3 /dev/mainvg/home
mkfs. /dev/mainvg/root

Mount

Damit ergibt sich folgendes Mountschema:

/dev/md1           /boot
/dev/mainvg/root    /
/dev/mainvg/usr    /usr
/dev/mainvg/var    /var
/dev/mainvg/tmp    /tmp
/dev/mainvg/home   /home

Das wird im Rescue-System erstmal alles nach /mnt gemountet.

mount /dev/mainvg/root       /mnt/
cd /mnt/
mkdir etc
mkdir boot
mkdir var 
mkdir usr
mkdir tmp
mkdir home
 
mount /dev/md1 boot/
mount /dev/mainvg/var  var/
mount /dev/mainvg/tmp  tmp/
mount /dev/mainvg/usr usr/
mount /dev/mainvg/home home/

Kontrolle:

# mount
(...)
/dev/mainvg/root on /mnt type ext3 (rw)
/dev/md1 on /mnt/boot type ext3 (rw)
/dev/mainvg/home on /mnt/home type ext3 (rw)
/dev/mainvg/usr on /mnt/usr type ext3 (rw)
/dev/mainvg/var on /mnt/var type ext3 (rw)
/dev/mainvg/tmp on /mnt/var type ext3 (rw)

Ok, dann kann man ja eine /mnt/etc/fstab mit folgendem Inhalt erzeugen:

proc                    /proc   proc    defaults 0 0
/dev/md1                /boot   ext3    defaults 0 2
/dev/mainvg/root        /       ext3     defaults 0 1
/dev/mainvg/home        /home   ext3     defaults 0 2
/dev/mainvg/usr         /usr    ext3     defaults 0 2
/dev/mainvg/var         /var    ext3     defaults 0 2
/dev/mainvg/tmp         /tmp    ext3     defaults 0 2
/dev/md0                none    swap    defaults,pri=1 0 0

Das neue System ist jetz soweit, dass wir mit der

Installation des Basissystems

beginnen können. Zunächst sollte apt aktualisieret werden um debootstrap zu installieren:

aptitude update && aptitude install debootstrap

debootstrap ist das Tool der Wahl, wenn man aus dem Nichts debian installieren will. Wir wollen Debian etch in das Verzeichnis /mnt installieren und tippen dafür:

debootstrap --arch amd64 lenny  /mnt/  http://ftp.de.debian.org/debian

Danach brauchen wir noch ein paar Mounts:

mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys

So, jetzt kann man in das neue System chrooten:

chroot /mnt

Grundlegendes im neuen System

Als erstes das root-pwd setzen:

passwd

Die /etc/network/interfaces von vorhin kann nun wieder hergestellt werden. Wer mehrere IP-Adressen in dem Server hat, kann sie gleich nach dem folgenden Schema eintragen:

### Hetzner Online AG - installimage
# Loopback device:
auto lo
iface lo inet loopback
 
# device: eth0 IP1
auto  eth0
iface eth0 inet static
  address   78.26.12.104
  broadcast 78.26.12.127
  netmask   255.255.255.224
  gateway   78.26.12.97
 
# device: eth0:1 IP2
auto  eth0:1
iface eth0:1 inet static
  address   78.26.12.123
  broadcast 78.26.12.127
  netmask   255.255.255.224
  gateway   78.26.12.97
 
# device: eth0:2 IP3 
auto  eth0:2
iface eth0:2 inet static
  address   78.46.12.124
  broadcast 78.46.12.127
  netmask   255.255.255.224
  gateway   78.46.12.97
 
# device: eth0:3 IP4
auto  eth0:3
iface eth0:3 inet static
  address   78.26.12.125
  broadcast 78.26.12.127
  netmask   255.255.255.224
  gateway   78.26.12.97
 
# default route to access subnet
up route add -net 78.26.12.96 netmask 255.255.255.224 gw 78.26.12.97 eth0

In /etc/hostname sollte der FQDN des Rechners eingetragen werden.

Für die Netzwerkkarte im Hetzner EQ4-Server muss das passende Kernelmodul geladen werden, deswegen wird in /etc/modules die Zeile

r8169

eingetragen.

Ggf. müssen die Sourcen (/etc/apt/sources.list) angepasst werden. Wer mag, kann den Hetzner-Mirror verwenden, um Traffickosten zu sparen:

deb http://hetzner:download@download.hetzner.de/debian/mirror lenny main
deb-src http://hetzner:download@download.hetzner.de/debian/mirror lenny  contirb
deb http://security.debian.org/ lenny/updates main contrib non-free

Nach einem herzlichen

aptitude update

Ist alles in Butter. Dann kann ein wenig Software installiert werden, z.B. ssh, mdadm, ntpdate etc. Unbedingt sollte man jetzt auch das Paket lvm2 installieren, sonst kann man nicht ins LVM booten!

aptitude install mdadm openssh-server lvm2 locales
dpkg-reconfigure locales

Hilfreich ist es auch gleich in etc/environment folgendes einzutragen:

export LANGUAGE=de_DE.UTF-8
export LC_ALL=de_DE.UTF-8
export LANG=de_DE.UTF-8

Der knifflige Teil folgt in Form der

Kernel und Boot-Konfiguration

Das ist nur für Magier ab Stufe 9. Die /etc/fstab haben wir ja schon in Ordnung gebracht. Jetzt kommt der spannenden Teil.

Da wir eine OpenVZ-Maschine bauen wollen, nehmen wir den OpenVZ-Kernel, der bei Debian zum Glück schon im Repository enthalten ist (im Gegensatz zu ubunut…):

aptitude install linux-image-openvz-amd64
aptitude install grub

Da unser /boot unter /dev/md1 liegt, lassen wir grub-install darauf los

grub-install --no-floppy /dev/md1

Dann grub Konsole starten:

grub --no-floppy

/boot liegt auf (hd0,1) (d.h. sda2/sdb2), also liegt der Kernel hier: (hd0,1)/vmlinuz-2.6.26-2-openvz-amd64 . Deswegen sagen wir in der grub shell:

root (hd0,1)
setup (hd0)
root (hd1,1)
setup (hd1)
quit

Damit ist grub auf beiden Festplatten installiert. Dann muss noch die /boot/grub/menu.lst aktualisiert werden:

timeout 2
 
# which config to boot from
default 0
fallback 0
 
# using boot partition from 1st disk
title Linux (hd0,1)
kernel (hd0,1)/vmlinuz-2.6.26-2-openvz-amd64 root=/dev/mainvg/root
initrd (hd0,1)/initrd.img-2.6.26-2-openvz-amd64
 
# using boot partition from 2nd disk
title Linux (hd1,1)
kernel (hd1,1)/vmlinuz-2.6.26-2-openvz-amd64 root=/dev/mainvg/root
initrd (hd1,1)/initrd.img-2.6.26-2-openvz-amd64

Obacht: das Root-Filesystem liegt auf dem LVM-Volume root, deswegen root=/dev/mainvg/root! Es kann sein, dass beim Booten das Root-Filesystem nicht gefunden wird. In dem Fall bitte testen, ob statt dessen der Parameter root=/dev/mapper/mainvg-root funktioniert (das scheint ein Debian-Bug zu sein).

Dann kann die chroot-Umgebung mit

exit

verlassen werden. Dann kann man vor dem Altar niederknien und sogleich laut und deutlich

reboot

aussprechen und hoffen, dass die Scheisskiste endlich bootet. Falls nicht hilft LARA.

Fertig?

Das System sieht jetzt so aus:

Dateisystem          Größe Benut  Verf Ben% Eingehängt auf
/dev/mapper/mainvg-root
                      2,0G  102M  1,9G   5% /
tmpfs                 3,9G     0  3,9G   0% /lib/init/rw
udev                   10M  760K  9,3M   8% /dev
tmpfs                 3,9G  4,0K  3,9G   1% /dev/shm 
/dev/md1              950M   36M  867M   4% /boot
/dev/mapper/mainvg-home                      2,0G  4,2M  2,0G   1% /home
/dev/mapper/mainvg-usr                      2,0G  177M  1,9G   9% /usr
/dev/mapper/mainvg-var                      300G  186M  300G   1% /var
/dev/mapper/mainvg-tmp                     1014M  4,2M 1010M   1% /tmp

Im LVM stehen etwa 690 GB zur Verfügung, 380 sind davon noch frei.

# vgdisplay 
  --- Volume group ---
  VG Name               mainvg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  7
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               5
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               693,68 GB
  PE Size               4,00 MB
  Total PE              177583
  Alloc PE / Size       78592 / 307,00 GB
  Free  PE / Size       98991 / 386,68 GB
  VG UUID               JAvU3s-J8do-f1Jj-B9c7-Dhds-RCdT-7bt4pp

Damit haben wir ein funktionierendes Grundsystem.

Aus dem Rescue-System auf die Host-Platten zugreifen

Wenn man im unwahrscheinlichen Falle eines Falles vom Rescue-System Gebrauch machen möche, kann man die Partitionen so mounten:

mount /dev/mainvg/root /mnt/
mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev
mount -o bind /sys /mnt/sys
cd /mnt/
mount /dev/md1 boot/
mount /dev/mainvg/home  home/
mount /dev/mainvg/usr  usr/ 
mount /dev/mainvg/var  var 
chroot /mnt/

Credits

Geholfen bei der Einrichtung des Servers haben mir diese beiden Tutorials:

Über Feedback freue ich mich natürlich. Beim nächsten Mal, richten wir ein paar OpenVZ-Container ein.

8 Antworten auf „Debian Lenny auf einem Rootserver mit Raid-1 und LVM“

  1. Klasse Tutorial! Vielen Dank 🙂
    Hat alles auf Anhieb funktioniert…
    musste aber auch /dev/mapper/mainvg-… nehmen anstelle /dev/mainvg/…

  2. Warum nicht einfach „installimage“ im Rescue System ausfuehren? Das installimage von Hetzner kann auch Raid und LVM genau wie gewuenscht – eine Installation von Lenny ist so in ca. 2 Minuten komplett fertig 🙂 Ausserdem spricht aus meiner Sicht nix dagegen swap aufs LVM zu packen…

  3. David, „installimage“ ist sicher der passende Hinweis für Hetzner Kunden.
    Den Swap-Space würde ich mit möglichst wenig Zwischenschichten anlegen, also ohne LVM. Jede Abstraktionsschicht frist Leistung. Swap lässt sich flexibel konfigurieren und benötigt für sich nicht die Features von LVM.

Kommentare sind geschlossen.