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:
- Die Hotzeltopf-Anleitung: Debian Sarge auf Hetzner DS3000 mit RAID1 auf VIA Chipsatz
- Meine alte Anleitung
- Raid1 auf Hetzner Dedicated Server DS5000
Über Feedback freue ich mich natürlich. Beim nächsten Mal, richten wir ein paar OpenVZ-Container ein.