<<< installation von asterisk mit zaphfc - übersicht - wie geht dem - erstellen eines howto >>>
vserver - virtuelle linux hardware
Wie mache ich mehr Server aus meiner Hardware?
Die aktuelle Version dieser Seite liegt unter http://verfaction.de/vserver.
Alle Copyrightrechte verbleiben beim Autor.
Vorbetrachtungen
Warum VServer?
Gerade in der Zeit steigender CPU-Leistung macht es nur noch selten Sinn einen kompletten Server dediziert zu betreiben. Das Zauberwort ist inzwischen Virtualisierung. Damit lassen sich auf ein und derselben Hardware mehrere virtuelle Server betreiben, die miteinander nur minimal wechselwirken. Eine dieser Wechselwirkungen ist selbstverständlich, dass nur 100% CPU und 100% RAM zur Verfügung stehen. Um alle anderen Beeinflussungen zu minimieren, wurde das Prinzip der Contexte bereits vor Jahren eingeführt, jedoch erst mit Hardwareleistung im Überfluss ist dieses Thema auch für den flächigen Einsatz interessant. Der Context wird für alle zu virtualisierenden Elemente im Kernel eingeführt, also zum Beispiel Prozessliste, Festplatten, Hauptspeicher, Netzwerk-Interfaces, CPU. Jeder Prozess kann dann abhängig von seinem Context nur mit anderen Prozessen dieses Context wechselwirken.
Virtualisierungstechniken im Überblick
Als notwendige Präparation muss für jede Virtualisierung sowohl der Linux-Kernel geändert werden, als auch ein passender Satz Zusatzprogramme installiert werden. Im weiteren wird der Linux-Vserver (www.linux-vserver.org) betrachtet. Als Alternativen gibt es User-Mode-Linux (UML), XEN, FreeVPS und eventuell auch die simple chroot() Funktion. Bei diesen muss grundsätzlich zwischen Emulatoren und Nicht-emulatoren unterschieden werden. UML und XEN nutzen beide einen speziellen Linux-Kernel, der im Userland läuft und einen separaten "Server" Vaterprozess erzeugen, unter dem dann die restlichen Prozesse laufen. Linux-Vserver und FreeVPS hingegen setzen auf den Betriebssystemkernel, der alle zusätzlichen Funktionen übernehmen muss. Hier werden alle Context-Zuordnungen direkt dem Systemkernel mitgeteilt und dort verwaltet. Prinzipbedingt kann mit UML und XEN auch Kernel-Entwicklung betrieben werden. Durch die zusätzliche Kernelemulation sind jedoch Vserver und FreeVPS den emulierenden Virtualisierungstechniken überlegen. Bei den Emulatoren ist laut der Webseite von XEN der Verlust von UML größer als bei XEN.
Vorbereitungen
Kernel & Userland
Da es zum Patchen und Bauen von Linux-Kernels bereits haufenweise Dokumentation gibt (z.B. hier), soll dies hier nicht näher betrachtet werden. Im Folgenden wird also davon ausgegangen, dass ein Linux-Vserver mit 1.9.x Patch auf Basis von Linux 2.6.y installiert ist und korrekt funktioniert. Dazu muss nun noch util-vserver (z.Zt. 0.30.203) installiert werden. Für die meisten Distributionen sollte das als fertiges Paket verfügbar sein und mit Bordmitteln trivial zu installieren.
AMD64 (x86_64) Hinweis: Für einen Systemkernel mit 64bit muss man aktuell auch die Userland Programme in der amd64-Version installieren. Dieses soll sich demnächst noch ändern, so dass auch die 32bit Userland Programme mit dem 64bit Kernel reden können.
Vserver-Root
Um die sogenannte Dateisystem-Barriere zu erzeugen, nehmen wir ein Verzeichnis, das für normale Benutzer nicht zugänglich ist. Unterhalb dieses Verzeichnisses werden dann die einzelnen Vserver eingerichtet. Da im Vserver Device-Nodes benötigt werden, darf keine der Mount-Optionen "nodev", "noexec" und "nosuid" für diesen Baum aktiv sein. Wahlweise sollten "noatime" oder "defaults" ausreichen. Optional zusätzliche Quotas, wenn gewünscht. Je nach Vorliebe kann man pro Vserver eine separate Partition anlegen oder für alle Vserver zusammen eine gemeinsam genutzte. Bei letzterem kann man von identischen Dateien profitieren, die nur jeweils einmal physikalisch gespeichert werden und für alle übrigen Vserver mittels Hardlink referenziert werden.
Einrichten des Vserver-Root

lvcreate -nvservers -L500 raid
mke2fs -j /dev/raid/vservers
echo "/dev/raid/vservers /srv/vservers ext3 noatime 0 2" \
>>/etc/fstab
mkdir -p /srv/vservers
mount /srv/vservers
chmod 0000 /srv/vservers
Erste Vserver erstellen
Um nun zu einem Vserver zu kommen, kann man sich des "vserver test build" bedienen. Als Methode kann debootstrap oder einfach skeleton zum Einsatz kommen. Der Vorteil bei skeleton ist, dass man direkt mit allem ausgestattet wird, um bestehende Chroots und existierende Systeme zu migrieren. Wichtig ist vor allem das /dev Verzeichnis.
Inhalt von /dev im Skeleton

crw-rw-rw- 1 root root 1, 7 2005-02-22 19:47 full
crw-rw-rw- 1 root root 1, 3 2005-02-22 19:47 null
crw-rw-rw- 1 root root 5, 2 2005-02-22 19:47 ptmx
drwxr-xr-x 2 root root 4096 2005-02-22 19:47 pts
crw-r--r-- 1 root root 1, 8 2005-02-22 19:47 random
crw-rw-rw- 1 root root 5, 0 2005-02-22 19:47 tty
crw-r--r-- 1 root root 1, 9 2005-02-22 19:47 urandom
crw-rw-rw- 1 root root 1, 5 2005-02-22 19:47 zero
Mit diesem skeleton /dev (hier nochmal als Tarball) ausgerüstet, kann man nun anfangen zu bootstrappen. Der grosse Vorteil daran ist, dass die vserver "build" Methode das Verzeichnis neu anlegen möchte. man kann also nicht mit "vserver sarge1 build" in eine leere Partition bootstrappen. Von daher exerzieren wir das komplette Setup hier von Hand. Für einen Debian Vserver geht das mittels cdebootstrap dann mit:
Entwicklungs-Vserver mittels cdebootstrap für amd64 Sarge

# cdebootstrap -a amd64 -f build sarge /srv/vserver/sarge1 http://ftp.de.debian.org/debian-amd64/pure64/
....
#
Danach muss man nur das /dev/ aus dem Skeleton in den neuen Vserver kopieren. Nun noch /etc/resolv.conf initialisieren. Jetzt kann man mit ein Paar einfachen Kommandos die noch fehlenden Schritte vervollständigen
# chroot /srv/vserver/sarge1
# apt-setup
# apt-get update;apt-get dist-upgrade;apt-get clean;apt-get autoclean
# apt-get install sysklogd
# rm /etc/rc3.d/S11klogd
# mv /sbin/start-stop-daemon.REAL /sbin/start-stop-daemon 
# exit
Jetzt fehlt nur noch /etc/vserver/sarge1 und der Vserver ist bereit für den Einsatz.
Initiales Setup von /etc/vserver/sarge1

# cat << EOF >/etc/vserver/sarge1.conf
S_HOSTNAME="sarge1"
IPROOT="1.2.3.4"
IPROOTDEV="eth0"
S_NICE=""
S_FLAGS="nproc"
S_CAPS=""
ULIMIT="-HS -n 1024"
S_DOMAINNAME=""
S_CONTEXT=42
EOF
# mkdir -p /etc/vserver/sarge1
# cd /etc/vserver/sarge1
# echo 42 >context
# mkdir -p apps/init apps/pkgmgmt \
interfaces/0 uts
# touch apps/pkgmgmt/internal
# ln -s /srv/vserver/sarge1 vdir
# ln -s /etc/vserver/sarge1/vdir /etc/vservers/.defaults/vdirbase/sarge1
# ln -s /var/run/vserver/sarge1 run
# ln -s /etc/vservers/.defaults/run.rev
# echo sarge1 >name
# echo sarge1.mydomain.loc >uts/nodename
# cat <fstab
none /proc proc defaults 0 0
none /tmp tmpfs size=16m,mode=1777 0 0
none /dev/pts devpts gid=5,mode=620 0 0
EOF
# echo 1.2.3.4 >interfaces/0/ip
# #echo eth0 >interfaces/dev
# touch interfaces/nodev
# ## ^^^ do this if your interface is up already
# echo eth0 >interfaces/0/name
Diese Voreinstellungen entsprechen im Großen und Ganzen den Defaults. Es gilt 1.2.3.4 ist diejenige lokale IP Adresse (hier von eth0), die im Hauptsystem verfügbar ist und aus dem Vserver genutzt werden soll. Jetzt kann man mit "vserver sarge1 start" den Vserver hochfahren und sollte mit "vserver sarge1 enter" eine root-shell im Vserver bekommen. Nun kann man den ssh-Server installieren und alle sonstigen Dienste. Diese werden nach aussen dann über die IP 1.2.3.4 angeboten, man sollte also auf dem Hauptsystem darauf achten, dass diese IP nicht für dieselben Dienste genutzt wird.
Alias IPs
Nachdem man also sehr wahrscheinlich jeden Vserver individuell erreichen können möchte, muss für jeden Server eine eigene IP eingerichtet werden. Nur Vserver, die nicht dieselben Dienste (und damit dieselben Ports) nach aussen belegen, können theoretisch auf ein und derselben IP sitzen. Da dies jedoch nur schwer sichergestellt werden kann, sollte man sich eine derartige Konfiguration gut überlegen.
Um also nun neue IPs auf eth0 hinzuzufügen genügt folgende Zeile:
Zusätzliche IP auf eth0

/sbin/ip addr add 1.2.3.5 dev eth0
Wenn wir also nun unser Ethernet-Interface mit ausreichend neuen IPs versorgt haben, dann können wir beliebig viele neue Vserver analog zu dem Beispiel oben einrichten.
Weitergehendes
Wem das dchroot-Prinzip für den Vserver fehlt, der sollte mal vexec von Bjoern Steinbrink probieren (falls man fopen als Fehler bekommt, einfach prüfen dass /etc/vservers/.defaults/vdirbase/$VSERVERNAME auf das korrekte Basisverzeichnis zeigt).