Virtuelle Server sind eine elegante Möglichkeit, einen Rootserver besser auszunutzen. Durch Aufteilung des Servers in virtuelle Server ist es möglich, weitere Anwendungen auf derselben Hardware zu installieren, ohne dass diese sich gegenseitig behindern (im Rahmen der vorhandenen CPU-Leistung und RAM-Speicherplatzes natürlich). Man hat die Möglichkeit, mehrere vserver einzurichten, die sich nur unwesentlich von einem "echten" Root-Server unterscheiden. Dieser Artikel erklärt, wie man den Linux-VServer-Kernel erstellt und installiert, welche Utility-Programme man braucht und wie man die virtuellen Server erstellt und konfiguriert. |
Um Linux-VServer zu nutzen, braucht man folgendes:
Die Webseite des VServer Projekts http://linux-vserver.org stellt die nötige Software sowie zahlreiche Informationen und Tutorials zur Verfügung.
In der Debian Etch Distribution gibt es bereits die VServer Tools in der (z.Zt.) neuesten Version. Es ist daher nicht nötig, diese selbst zu kompilieren. Auch verschiedene Kernels mit dem VServer-Patch stehen zur Verfügung. Da ich jedoch für einen Root-Server einen möglichst schlanken Kernel haben möchte, kompiliere ich mir lieber selbst einen.
Die VServer Tools installiert man wie folgt:
apt-get install vserver-debiantools vlan |
Die wichtigste Eigenschaft eines Root-Servers ist die Sicherheit. Je mehr Features in einem Kernel (oder in der ganzen Distribution) enthalten sind, desto mehr potentielle Angriffspunkte gibt es. Deswegen empfiehlt es sich, auf einem Root-Server nur die minimal erforderlichen Kernel-Funktionen und nur die nötigsten Programme zu installieren. Da sich die Hardware eines Root-Servers nicht ändert, kann man auch ruhig einen Kernel ohne dynamische Module verwenden. Die gewünschten Kernel-Features werden über die .config-Datei eingestellt.
Hier sind zwei Beispielkonfigurationen, die mit den aktuellen (Juni 2008) Root-Server von Hetzner funktionieren. In beiden Kernels ist der Support für sowohl VIA- als auch ATI-Chipsätze aktiviert, ebenso für die Realtek 8139 und 8169 Netzwerkkarten. Die SMP Variante ist für die aktuellen AMD 64 X2 Dual Core Prozessor Systeme gedacht, die ohne SMP kann auf den älteren AMD 64 Systemen (ohne Dual Core CPU) verwendet werden und bringt dort eine etwas bessere Performance als die SMP Variante.
Konfiguration |
.config |
Kernel |
|---|---|---|
|
||
|
Ältere Kernel und Konfigurationen siehe Attachments.
Ob diese Konfiguration zur eigenen Hardware passt, muss man gegebenenfalls selbst herausfinden. Auch verschiedene DS5000 haben durchaus unterschiedliche Hardware, z.B. andere Netzwerkkarten. Am einfachsten ist es, das Rescue-System zu starten, das dmesg und das lspci Kommando auszuführen und die Ausgabe genau zu analysieren. Man sieht meistens sehr schnell, welche CPU, welcher Chipsatz und welche Netzwerkkarte verwendet wird. Falls die Konfiguration nicht zur Hardware passt, löscht man einfach die entsprechenden Zeilen aus der Config-Datei heraus, und zwar sowohl den aktiven Eintrag (weil er ja nicht passt) als auch den zur vorhandenen Hardware gehörende, aber auskommentierten Eintrag (man kann ihn dann bei der Konfiguration explizit auswählen).
Nach Änderung der Konfigurationsdatei, oder wenn man einen aktuelleren Kernel mit einer älteren Config-Datei verwendet, immer "make oldconfig" ausführen. Man bekommt so die Möglichkeit, alle neuen Konfigurationsmöglichkeiten bzw. die gelöschten Einträge erneut zu konfigurieren. Falls man sämtliche Optionen neu setzen will, empfiehlt sich ein "make menuconfig".
Die VServer Funktionen werden über einen Patch im Kernel aktiviert. Den Patch kann man sich von der Linux-VServer Website downloaden.
Die neuen VServer-Kernelfunktionen haben ebenfalls etliche Konfigurationsmöglichkeiten in der Config-Datei. In der verwendeten Konfiguration wurden nur die Default-Optionen verwendet.
Hier ein Beispiel, wie man sich aus den Kernel-Sourcen, dem VServer Patch sowie einer vorhandenen config-Datei einen neuen Kernel baut. Die angegebenen Versionen sind allerdings inzwischen obsolet.
server00:/# bzcat linux-2.6.20.4.tar.bz2 | tar xf - server00:/# cp config-2.6.20.4 linux-2.6.20.4/.config server00:/# cd linux-2.6.20.4 server00:/# patch -p1 < ../patch-2.6.20.4-vs2.2.0.diff patching file Documentation/vserver/debug.txt patching file Makefile ... server00:/# make oldconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc HOSTCC scripts/kconfig/conf.o ... server00:/# make bzImage scripts/kconfig/conf -s arch/i386/Kconfig CHK include/linux/version.h UPD include/linux/version.h ... HOSTCC arch/i386/boot/tools/build BUILD arch/i386/boot/bzImage Root device is (8, 6) Boot sector 512 bytes. Setup is 4650 bytes. System is 1248 kB Kernel: arch/i386/boot/bzImage is ready (#1) server00:/# cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.20.4-vserver server00:/# lilo ... |
Jeder VServer benötigt eine separate IP-Adresse, da viele Dienste, z.B. http, https, sshd, mail usw. immer denselben Port benutzen müssen. Bei der Konfiguration des Servers ist daher darauf zu achten, dass dem Server mehrere IP-Adressen zur Verfügung stehen und dass diese richtig konfiguriert sind. Die zusätzlichen IP-Adressen müssen meistens beim Anbieter des Root-Servers explizit bestellt und von diesem in dessen Routern konfiguriert werden; zusätzlich muss man dann die IP-Adressen auf dem Server selbst aktivieren.
Hetzner bietet z.B. Server mit insgesamt 6 IP-Adressen an. Diese sind wie folgt verteilt:
Eine schöne Erläuterung des Subnetting findet sich hier.
Die zusätzlichen IP-Adressen müssen in der /etc/network/interfaces Datei eingetragen und das Interface muss aktiviert werden. (Die angegebenen IP-Adressen sind erfunden.)
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 123.123.97.87 broadcast 123.123.97.95 netmask 255.255.255.224 gateway 123.123.97.65 auto eth0:1 iface eth0:1 inet static address 234.234.255.2 broadcast 234.234.255.7 netmask 255.255.255.248 gateway 234.234.255.1 auto eth0:2 iface eth0:2 inet static address 234.234.255.3 broadcast 234.234.255.7 netmask 255.255.255.248 gateway 234.234.255.1 auto eth0:3 iface eth0:3 inet static address 234.234.255.4 broadcast 234.234.255.7 netmask 255.255.255.248 gateway 234.234.255.1 auto eth0:4 iface eth0:4 inet static address 234.234.255.5 broadcast 234.234.255.7 netmask 255.255.255.248 gateway 234.234.255.1 auto eth0:5 iface eth0:5 inet static address 234.234.255.6 broadcast 234.234.255.7 netmask 255.255.255.248 gateway 234.234.255.1 |
Die Aktivierung erfolgt durch den Befehl "ifup -a".
Einige Programme binden sich an sämtliche Interfaces und IP-Adressen, die zur Verfügung stehen. Das führt dazu, dass die VServer diese IP-Adresse nicht mehr nutzen können, da sie bereits durch den Host Server belegt ist. |
In dieser Beispielkonfiguration trifft dies z.B. für den sshd des Host Servers zu. In der /etc/ssh/sshd_config Datei ist daher folgende Einstellung vorzunehmen:
... ListenAddress 123.123.97.87 ... |
Ähnliches gilt für bind, httpd, mysqld usw., falls man diese Programme auf dem Host Server nutzen will.
Ein neues Debian Etch System wird dann so erstellt:
newvserver --hostname <servername> --domain <domainname> \
--ip 234.234.255.2/29 --interface eth0 --context 2 \
--dist etch --mirror ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/debian
|
Für <servername> trägt man den gewünschten Servername ein. Dies ist gleichzeitig der Directoryname, in welchem die Distribution angelegt wird.
Der Parameter <domainname> enthält die Domain, oder auch z.B. einfach nur "local".
Die IP-Adresse ist die IP-Adresse des neuen VServers. Der Parameter /29 ist eine Kurzschreibweise für die Netmask und bedeutet, dass die Netzmaske aus 29 1er-Bits und 3 0er-Bits besteht (man könnte auch 255.255.255.248 schreiben).
Der Context Parameter gibt den VServer Context an. Man muss für jeden VServer einen anderen wählen, und "1" ist schon belegt.
Die restlichen Parameter definieren, welche Distribution von welchem Mirror Server installiert werden soll. Man kann natürlich auch diverse andere Distributionen benutzen, z.B. SuSE, RedHat, Fedora usw. Wie das geht, ist allerdings nicht Thema dieses Artikels und ich habe es auch noch nicht getestet.
Nun muss der neue VServer gestartet werden, danach kann man ihn direkt vom Host aus "betreten". Als erstes sollte man SSH installieren, damit man sich auch direkt auf den neuen Server einloggen kann (gleich testen).
server03:~# vserver v0300 start Starting system log daemon: syslogd. Not starting internet superserver: no services enabled. Starting periodic command scheduler: crond. server03:~# vserver v0300 enter v0300:/# apt-get install ssh v0300:~# apt-get install ssh Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: ssh 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/1054B of archives. After unpacking 32.8kB of additional disk space will be used. Selecting previously deselected package ssh. (Reading database ... 7090 files and directories currently installed.) Unpacking ssh (from .../ssh_1%3a4.3p2-9_all.deb) ... Setting up ssh (4.3p2-9) ... v0300:~# |
Um einen VServer automatisch beim Reboot des Host Servers zu starten, erstellt man folgende Datei im Konfigurationsdirectory jedes VServers und schreibt die Zeile "default" rein:
server03:~# echo default > /etc/vservers/v0300/apps/init/mark |
Mit dem Befehl "vserver-stat" erhält man einige nützliche Informationen über die aktiven VServer:
server03:~# vserver-stat CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 0 36 165.5M 46.5M 18h53m45 1d21h27 8d13h17 root server 2 8 20.5M 5.3M 0m00s00 0m00s00 28m14s74 v0300 3 3 8.5M 2.3M 0m00s00 0m00s00 4m52s60 v0301 4 3 8.5M 2.3M 0m00s00 0m00s00 4m52s60 v0302 5 3 8.5M 2.3M 0m00s00 0m00s00 4m51s96 v0303 6 4 1.7G 666.4M 9m53s40 0m59s25 5d10h23 v0304 |
Die installierte VServer Software hat im Moment noch ein Problem:
Gelegentlich verabschiedet sich der "vcontext" Prozess ab und verbraucht 100% CPU. Das scheint meistens dann zu passieren, wenn man den virtuellen Server mit "vserver [vserver-name] enter" betritt und die Konsole schließt, ohne den virtuellen Server mit "exit" wieder zu verlassen. Passiert häufig, wenn man die Konsole eine Weile offen lässt und die DSL-Verbindung in der Zwischenzeit resettet.
Man kann den "vcontext" Prozess ohne Probleme mit "kill [pid]" abschießen.
Weitere Informationen zu diesem Problem:
"vserver enter" eating cpu and vkill problem
Fragen, Kommentare? Einfach hier hinterlassen.