Evaluation XenServer 5.5

Wir setzen ja seit Mitte 2005 Xen im Produktivbetrieb für paravirtualisierte Linux-Gäste ein. Für Windows-Systeme haben wir bisher VMWare eingesetzt. Hier nun die Ergebnisse unseres Tests für XenServer 5.5.

Die Hardware und Voraussetzung:

Zur Verfügung steht eine Maschine mit 2 Stata-Platten a 1,5TB und einem Intel i7-Prozessor (8Kerne) sowie 24GB RAM welche bei Hetzner im Rechenzentrum steht. Die Sata-Platten sollen als Software-Raid arbeiten. Angeregt durch einen Artikel in der c’t 06/2010 sollte das System vorbereitet sein für die Domänenmigration über das Netzwerk. Genutzt werden sollte also ein „distributed block-device“, also DRBD. In der Netzwerkanbindung hat die Maschine 4 IP-Adressen aus 2 verschiedenen Subnetzen. Eine Besonderheit, die Xen zu schaffen machte (s.u.).  Ferner soll die Maschine mittels OpenVPN angebunden werden.

Die Maschine steht in einem Rechenzentrum, so dass lokale CDs nur mit Problemen eingelegt werden können. Also musste die Installation ohne lokales CD-Laufwerk auskommen.

Installationsvorbereitung

Zuerst wurde die ISO-Boot-CD des XenServers auf auf einem Webserver in Dateiform bereitgestellt. Wir konnten also per HTTP auf die Dateien im Image zugreifen, nicht auf die ISO-Datei selbst.

Dann wurde auf dem System ein CentOS in einer Minimalversion installiert und in dieses gestartet.

Installation

Auf dem installierten Minimalsystem werden zuerst die Xen-Boot-Dateien installiert:

cd /boot
wget http://xxx.xxx.xxx.xxx/PfadZumImageinhalt/boot/vmlinuz
wget http://xxx.xxx.xxx.xxx/PfadZumImageinhalt/boot/xen.gz
wget http://xxx.xxx.xxx.xxx/PfadZumImageinhalt/install.img

Dann ist natürlich das Grub-Bootmenu unter

/boot/grub/menu.lst

anpassen zu:

timeout 5
default 1

title CentOS Linux (2.6.18-164.11.1.el5)
root (hd0,1)
kernel /boot/vmlinuz-2.6.18-164.11.1.el5 ro root=/dev/md2 vga=0x317
initrd /boot/initrd-2.6.18-164.11.1.el5.img

title Install Xenserver
root (hd0,1)
kernel /boot/xen.gz dom0_mem=752M acpi=off nosmp noapic noirqbalance
module /boot/vmlinuz answerfile=http://IP-ADRESSE_DES_WEBSPACE/answer.xml install
module /boot/install.img

und der Rechner neu zu starten.

Die erwähnte Answer-Datei sieht wie folgt aus:

<installation mode="fresh" srtype="lvm">

 <bootloader>grub</bootloader>

 <primary-disk gueststorage="yes">sda</primary-disk>

 <keymap>de</keymap>

 <hostname>xen</hostname>

 <root-password>ROOT-PASSWORT</root-password>

 <source type ="url">http://IP-ADRESSE_des_ausgepackten_ISO-Image</source>

 <!-- No Post install scripts configured -->

 <admin-interface name="eth0" proto="static">

 <ip>EIGENE_IP-ADRESSE</ip>

 <subnet-mask>EIGENE_SUBNETZ-MASKE</subnet-mask>

 <gateway>EIGENES-GATEWAY</gateway>

 </admin-interface>

 <nameserver>NAMESERVER</nameserver>

 <timezone>Europe/Berlin</timezone>

 <time-config-method>ntp</time-config-method>

 <ntp-servers>ntp</ntp-servers>

 <ntpservers>NTP-SERVER</ntpservers>

</installation>

Die oben durchgeführte Installation des CentOS-Minimalsystems hat drei Software-Raid-1-Systeme angelegt, deren Signaturen nun noch im System rumgeistern. Diese sind zu löschen:

mdadm -S /dev/md0
mdadm -S /dev/md1
mdadm -S /dev/md2
mdadm --zero-superblock /dev/sdb1
mdadm --zero-superblock /dev/sdb2
mdadm --zero-superblock /dev/sdb3

Nach dem Artikel http://wiki.hetzner.de/index.php/Xenserver_5.5:_Automatische_Installation,_sw_raid1,_lokale_ISO_library wird nun weiter installiert. Hier die Auszüge. Für die einzelnen Funktionen bitte im Originalartikel nachlesen.

dd if=/dev/sda of=/dev/sdb bs=512 count=1
echo -e "\nt\n1\nfd\nt\n3\nfd\nw\nx" | fdisk /dev/sdb
[ -e /dev/md0 ] || mknod /dev/md0 b 9 0
[ -e /dev/md1 ] || mknod /dev/md1 b 9 1
mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1
mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb3
pvcreate -ff /dev/md1
volume_group=`vgscan | grep VG | awk -F \" '{print $2}'`
vgextend $volume_group /dev/md1
pvmove /dev/sda3 /dev/md1
vgreduce $volume_group /dev/sda3
mkfs.ext3 /dev/md0
cd / && mount /dev/md0 /mnt && rsync -a --progress --exclude=/sys --exclude=/proc --exclude=/dev/shm --exclude=/dev/pts / /mnt
mkdir /mnt/sys
mkdir /mnt/proc
sed -r -i 's,LABEL=root-\w+ ,/dev/md0 ,g' /mnt/etc/fstab
mkdir /root/initrd && cd /root/initrd
zcat /boot/initrd-`uname -r`.img | cpio -i && \
cp /lib/modules/`uname -r`/kernel/drivers/md/raid1.ko lib
q="echo Waiting for driver initialization."
sed -r -i "s,^${q}$,\n\necho Loading raid1.ko module\ninsmod /lib/raid1.ko\n${q}\n,g" init
q="resume /var/swap/swap.001"
sed -r -i "s,^${q}$,${q}\necho Running raidautorun\nraidautorun /dev/md0\nraidautorun /dev/md1,g" init
r=`grep mkroot /root/initrd/init`
sed -r -i "s|^${r}$|${r/sda1/md0}|g" init
find . -print | cpio -o -c | gzip -c > /mnt/boot/initrd-`uname -r`.img
sed -r -i 's,LABEL=root-\w+ ,/dev/md0 ,g' /mnt/etc/fstab
sed -r -i 's,LABEL=root-\w+ ,/dev/md0 ,g' /etc/fstab

sed -r -i 's,root=LABEL=root-\w+ ,root=/dev/md0 ,g' /mnt/boot/grub/grub.conf
sed -r -i 's,root=LABEL=root-\w+ ,root=/dev/md0 ,g' /boot/grub/grub.conf
grub-install /dev/sdb

Es muss noch einmal in ein Rettungssystem (ein System welches per PXE bootet und indem man auf die Platten zugreifen kann) gestartet werden und dort die Partitionstabelle modifiziert werden sowie die Xen-Hauptpartition ins Software-Raid

/dev/md0

eingebunden werden.

echo -e "\nt\n1\nfd\nt\n3\nfd\nw\nx" | fdisk /dev/sda
mdadm -a /dev/md0 /dev/sda1

Nach einem erneuten Neustart befinden wir uns wieder im Xen-System und erzeugen dort das Software-Raid für den späteren Image-Bereich, der die VMs aufnehmen soll:

mdadm -a /dev/md1 /dev/sda3

DRBD-Einbindung

Für das DRBD-System werden sowohl Programme (Userland-Tools) als auch ein passendes Kernel-Modul benötigt. Hierbei sollten diese in der Versionsnummer 100%ig übereinstimmen. Selbst Unterschiede in der Minor-Nummer könnten zur Instabilität oder zu Fehlverhalten führen – wie wir leider feststellen mussten.

Im o.g. c’t-Artikel steht für DRBD 8.3.5 ein fertiges Kernelmodul bereit. Dieses lud zwar ohne Probleme in unseren Kernel, führte jedoch auch zu Instabilitäten. Wir haben mit dem DDK von Citrix ein eigenes Modul für DRBD 8.3.5 gebaut und dies hatte merkwürdigerweise eine andere Größe als das c’t-Modul. Daraufhin haben wir gleich die aktuelle DRBD-Version (8.3.7) genommen und hiervon ein passendes Kernelmodul gebaut.

Die DDK-Maschine ist eine VM unter Xen. Hier ergibt sich also ein klassisches Henne-Ei-Problem. Glücklicherweise konnten wir „auf die Schnelle“ auf eine zweite Xen-Maschine zugreifen und das DDK dort installieren.

Nun die Userland-Tools auf der Xen-Dom0-Maschine übersetzen:

• Vorbereitungen

  yum -y install gcc
  yum -y install make
  yum -y install flex

• Installation

  cd /usr/src
  wget http://oss.linbit.com/drbd/8.3/drbd-8.3.7.tar.gz
  tar -xpzf drbd-8.3.7.tar.gz
  cd drbd-8.3.7/
  ./configure --prefix=/
  make
  make install

Und auf der DDK-VM das Kernel-Modul übersetzen:

cd /usr/src
wget http://oss.linbit.com/drbd/8.3/drbd-8.3.7.tar.gz
tar -xpzf drbd-8.3.7.tar.gz
cd drbd-8.3.7/
./configure
make
cd drbd
make KDIR=/usr/src/kernels/2.6.18-128.1.6.el5.xs5.5.0.505.1024xen-i686

In XenCenter wird nun der von Xen schon bei der Installation belegte Speicherplatz für die VMs freigegeben, damit dieser für DRBD genutzt werden kann.

Dann wird in der Dom0 DRBD konfiguriert über die Datei /etc/drbd.conf:

global {
    usage-count yes;
}

common {
  protocol C;
  net {
    allow-two-primaries;
    shared-secret "UnserGeheimnis";
    after-sb-0pri discard-zero-changes;
    after-sb-1pri consensus;
    after-sb-2pri disconnect;
  }
  startup {
    #become-primary-on both;
  }
  syncer { rate 10M; }
}

resource main {

  protocol C;

  handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh";
  }

  device /dev/drbd1;
  disk /dev/md2;
  meta-disk internal;
  on xen {
    address unsereAdresse:7788;
  }

  on xenback {
    address dummyadresse:7788;
  }
}

und die DRBD-Volumes erzeugt:

drbdadm create-md main
drbdadm attach main
drbdadm -- --overwrite-data-of-peer primary main

Das neue DRBD-Device „main“ konnte dan Xen im XenCenter als Speicherplatz zur Verfügung gestellt werden.

Besonderheiten:

Da wir die zweite DRBD-Maschine nicht bereitgestellt haben, befand sich das System nach jedem Neustart im undefinierten Zustand. Daher musste jeweils

drbdadm attach main
drbdadm -- --overwrite-data-of-peer primary main

ausgeführt werden.

Netzwerkkonfiguration und OpenVPN

Die Einstellungen zur  Netzwerkkonfiguration und OpenVPN folgen dann im nächsten Eintrag.