Die Leistungsfähigkeit von Computern nimmt ständig zu. Server mit dutzenden von Kernen und vielen GB RAM sind mittlerweile erschwinglich. Ein Server mit 16 Kernen und 32 GB Ram kostet aktuell (Q1/2012) knapp 3000€. Diese Rechenleistung erlaubt es gleich mehrere Systeme virtuell auf der Hardware laufen zu lassen.
Virtualisierung ist nichts neues. Wir haben uns viele Virtualisierungs-Lösungen angesehen. Die kommerziellen Lösungen VMWare und VirtualBox bieten einen einfachen Einstieg. Die Planung komplexer Setups sollte aber genügend Zeit für das Studium der aktuellen Lizenzmodelle beinhalten.
Einen guten Einstieg in die Virtualisierung bietet Proxmox. Proxmox ist eine Linux Distribution, welche die Voll-Virtualisierung mittels kvm/qemu und die Para-Virtualisierung mittels OpenVZ über ein Frontend erlaubt. Eine Proxmox Node läßt sich per heartbeat/pacemaker clustern. Virtuelle Maschinen können zwischen den Nodes verschoben werden.
Es folgt ein Erfahrungsbericht mit Proxmox:
Installation
aktuelle Proxmox Installations-CD in das Laufwerk und Neustart. Den Anweisungen folgen bzw. die abgefragten Daten eingeben.
aptitude update aptitude full-upgrade
Proxmox unterstützt offiziell keine Soft-RAIDs. Es schlägt als Installationsziel immer eine der beim Boot gefundenen Festplatten vor. Will man ein Soft-RAID, so installiert man zunächst z.B. auf /dev/sda und erstellt das RAID er später.
Soft-RAID
Zunächst die noch nicht installierte benötigte Software nachinstallieren
aptitude install mdadm
Als nächsten Schritt das RAID vorbereiten:
sfdisk -d /dev/sda | sfdisk -f /dev/sdb sfdisk -c /dev/sdb 1 fd sfdisk -c /dev/sdb 2 fd mdadm --create -l 1 -n 2 /dev/md0 missing /dev/sdb1 mdadm --create -l 1 -n 2 /dev/md1 missing /dev/sdb2 mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Nun noch /boot auf md0 vorbereiten
mkfs.ext3 /dev/md0 mkdir /mnt/md0 mount /dev/md0 /mnt/md0 cp -ax /boot/* /mnt/md0
und die Datei /etc/fstab anpassen. Die Zeile mit *UUID=<your UUID here> /boot ext3 defaults 0 1* wird durch
/dev/md0 /boot ext3 defaults 0 1
ersetzt. Wenn nach dem nun folgenden Reboot ein
mount|grep boot
die Zeile */dev/md0 on /boot type ext3 (rw)* enthält, dann waren die Anpassungen erfolgreich.
Nun muss _grub_ noch angepass und eine neue initramfs erstellt werden
echo '# customizations' >> /etc/default/grub echo 'GRUB_DISABLE_LINUX_UUID=true' >> /etc/default/grub echo 'GRUB_PRELOAD_MODULES="raid dmraid"' >> /etc/default/grub echo raid1 >> /etc/modules echo raid1 >> /etc/initramfs-tools/modules grub-install /dev/sda grub-install /dev/sdb grub-install /dev/md0 update-grub update-initramfs -u
/dev/sda1 zu md0 hinzufügen
sfdisk -c /dev/sda 1 fd
mdadm –add /dev/md0 /dev/sda1
Nach einem weiteren Reboot kommt der letzte (und zeitaufwändigste) Schritt das PVE LV in das MD1 RAID zu moven:
pvcreate /dev/md1 vgextend pve /dev/md1 pvmove /dev/sda2 /dev/md1 vgreduce pve /dev/sda2 pvremove /dev/sda2 sfdisk --change-id /dev/sda 2 fd mdadm --add /dev/md1 /dev/sda2
Proxmox nutzt standardmäßig lvm2. Einige Funktionen die Proxmox nutzt bedienen sich von lvm2 mitgelieferten Funktionen, die im Zusammenspiel mit Soft-Raid zu Problemen führen.
So bietet Proxmox die Möglichkeit VMs im „Snapshot“-Modus zu sichern. Hierbei wird ein lvm2-snapshot erstellt, was zur Folge hat, dass die VM weiterhin online ist, die zu sichernden Daten aber konsistent in einem Snapshot erhalten bleiben.
Findet nun während der Snapshot-Sicherung ein Check bzw. Resync des Soft-Raids statt, so kommt der Proxmox-Host reproduzierbar nach einiger Zeit zum Stillstand.
Erzeugen einer VZ-VM aus den Repositories
Unter /var/lib/vz/private ein Verzeichnis mit einer neuen VŹ-ID anlegen. Im Beispiel ist die VZ-ID 200.
debootstrap –arch=amd64 precise 200/ http://archive.ubuntu.com/ubuntu
erstellt unter dem eben angelegten Verzeichnis die benötigte Struktur. Bei neueren zu installierenden Versionen kann das Skript dbootstrap nichts mit der Versionsbezeichnung anfangen. Z.B. beschwerte sich das Skript über den Namen precise. Ein
ln -s /usr/share/debootstrap/scripts/gutsy /usr/share/debootstrap/scripts/precise
behob das Problem.
Als nächstes unter /etc/vz/conf eine Datei namens <VZ-ID>.conf anlegen und anpassen
<pre>
ONBOOT=“yes“
PHYSPAGES=“0:1024M“
SWAPPAGES=“0:1024M“
KMEMSIZE=“465M:512M“
DCACHESIZE=“232M:256M“
LOCKEDPAGES=“512M“
PRIVVMPAGES=“unlimited“
SHMPAGES=“unlimited“
NUMPROC=“unlimited“
VMGUARPAGES=“0:unlimited“
OOMGUARPAGES=“0:unlimited“
NUMTCPSOCK=“unlimited“
NUMFLOCK=“unlimited“
NUMPTY=“unlimited“
NUMSIGINFO=“unlimited“
TCPSNDBUF=“unlimited“
TCPRCVBUF=“unlimited“
OTHERSOCKBUF=“unlimited“
DGRAMRCVBUF=“unlimited“
NUMOTHERSOCK=“unlimited“
NUMFILE=“unlimited“
NUMIPTENT=“unlimited“
# Disk quota parameters (in form of softlimit:hardlimit)
DISKSPACE=“8G:9227468″
DISKINODES=“1600000:1760000″
QUOTATIME=“0″
QUOTAUGIDLIMIT=“0″
# CPU fair scheduler parameter
CPUUNITS=“1000″
CPUS=“2″
HOSTNAME=“gosa“
SEARCHDOMAIN=“hq.cross“
NAMESERVER=“192.168.2.1″
IP_ADDRESS=“10.100.1.200″
VE_ROOT=“/var/lib/vz/root/$VEID“
VE_PRIVATE=“/var/lib/vz/private/200″
</pre>
Die zunächst interessanten Einträge finden sich im letzten Abschnitt. Im obigen Beispiel ist die VZ-ID 200. Die hier eingetragenen Werte werden von Proxmox übernommen. Zunächst ist die Maschine über Proxmox zu starten und nur über die Konsole erreichbar.
Nach der Installation des Pakets _openssh_server_ und setzen des root-Passworts ist die Maschine auch über das Netz per ssh erreichbar.
Die Einträge für SEARCHDOMAIN und NAMESERVER werden nur bei der Erstellung eines Containers berücksichtigt. Um bei einem existierenden Container die searchdomain und den nameserver zu ändern, reicht die Änderung dieser Einträge in der config nicht aus. Auch Änderungen in der Datei /etc/resolv.conf werden bei jedem Neustart des Containers überschrieben. Es ist zusätzlich noch die Datei /etc/resolvconf/resolv.conf.d/original anzupassen.
Virtualisieren eines physikalischen Windows-Hosts
Zunächst muss das Quellsystem vorbereitet werden. Wie auch bei Virtualbox wird als erstes die Registry mit Hilfe von mergide.reg (siehe angehängte Datei) angepasst.
Dann ist sicher zu stellen das im Verzeichnis %SystemRoot%\System32\Drivers folgende Dateien vorhanden sind:
Atapi.sys, Intelide.sys, Pciide.sys und Pciidex.sys
Sollten dieses Dateien oder auch nur einige fehlen, dann können diese aus der Datei %SystemRoot%\Driver Cache\I386\Driver.cab extrahiert werden.
Als nächstes wird eine VM in Proxmox angelegt. Diese Maschine sollte möglichst genau die Hardware der physikalischen Maschine widerspiegeln (Prozessor, RAM,…).
Nun muss die komplette Festplatte des zu virtualisierenden Systems per dd, gzip und ssh auf den Host kopiert werden.
Nach dem Entpacken der Datei wird diese in das qemu-Format konvertiert:
<pre>qemu-img convert <Abbild der physikalischen Maschine> -O qcow2 <Dateiname aus qemu-Konfiguration>.qcow2</pre>
Im Optimalfall lässt sich die virtualisierte Maschine jetzt schon problemlos starten. Die Erfahrung zeigt jedoch, dass der Wechsel auf die virtualisierte Hardware meist nicht problemlos abläuft.
Ein Boot in den Recoverymodus ist bisher immer notwendig gewesen. Wenn die hier zur Verfügung stehenden Mittel nicht ausreichen, dann half bisher meist eine Recovery-Installation.
Dabei sollte möglichst eine geslipstreamte CD der gleichen Version wie der installierten (XP Home / XP Proffesional) verwendet werden. Anderfalls ist das aktuelle Service Pack nach zu installieren. Installierte Anwendungen und die meisten Systemeinstellungen bleiben erhalten.
Beispiel
Auf dem Server wurden eingerichtet:
- Windows XP
- SOGo
- Samba 3
- Samba 4
- KDE
Der Windows Client wird benötigt, um die automatische Software-Verteilung OPSI zu testen. Windows läuft voll virtualisiert. Ein Kern und 1GB Ram reichen dem System, um die Softwareverteilung zu testen. Die SOGo Installation begnügt sich auch mit 1GB Ram. Samba3 muss aufgrund der NETBIOS Altlasten vollvirtualisiert laufen, weil es einen Domain Controller simmuliert. Das Samba 4 läuft einfach schon einmal im Netz.
Und der Server hat immer noch genügend Resourcen, um andere Dienste auszuprobieren, oder ganze Infrastrukturen zu simmulieren. Etwa ein Solr Cluster mit Replikation oder eine Freeswitch Telefonanlage im Failoverbetrieb.
Tags: proxmox