ZIDline
Virtuelle Lizenzserver für Campussoftware
Martin Holzinger, Rudolf Ladner, Eva Lahnsteiner
Die Abteilung Standardsoftware stellt seit Jahreswechsel die zentralen Elemente ihrer Campussoftware-Services in einer hochverfügbaren virtuellen Umgebung unter Xen zur Verfügung. Nach sorgfältiger Planung wurde eine Virtualisierungslösung realisiert, die auf Sicht von drei Jahren nach heutigem Ermessen bestmöglichen Ausfallsschutz bieten soll.

Vorgeschichte

Der Hardwarecrash eines der beiden in die Jahre gekommenen redundanten HPUX-Server (lserver.tuwien.ac.at) im April 2010 hat nicht zuletzt wegen der ausdefinierten Ausfallsszenarien glücklicherweise – bis auf zwei nur halboffiziell gehostete Applikationen, deren Lizenzserver wegen der unterschiedlichen CPU-ID des Ersatzsystems nicht startbar waren – keine längeren Stehzeiten verursacht, jedoch wurde durch den Vorfall in aller Deutlichkeit die Notwendigkeit der Entwicklung einer umfassenden Lösung aufgezeigt.

Dem nicht unerheblichen Risiko, hochverfügbare Lizenzserver auf veralteter Hardware (HP A400) zu betreiben, wurde demnach im Frühjahr 2010 mit einem abteilungsinternen Xen-Virtualisierungsprojekt begegnet, das im Oktober 2010 erfolgreich zum Abschluss gebracht werden konnte.

Das Xen-Projekt der Abteilung Standardsoftware

Definiertes Projektziel war, die diversen Lizenzserver der Abteilung als virtuelle Maschinen auf einer weitgehend redundanten Hardwareplattform zu betreiben. Nach Identifizierung der in Frage kommenden Services – immerhin wurden von 10 teils veralteten physischen Servern an die 50 verschiedene Services gehostet – stellte sich die Frage nach möglichen Szenarien für den zukünftigen laufenden Betrieb.

Eingehend untersucht wurden dabei zwei aus unserer Sicht im Grunde gleichwertige Varianten, neben der kommerziellen, von Citrix angebotenen Xen-Server-Komplettlösung (basierend auf CentOS) wurde die Open-Source-Variante der Community von Xen.org eingehend evaluiert. Nachstehend ein paar unserer Gedanken bzw. Argumente, die unsere Entscheidung beeinflusst haben.

Citrix-Xen verwendet zur Konfiguration des Netzwerkes und auch für anderes mehr eine zentrale XML-Datenbank, ähnlich der Registry bei Windows. Das Netzwerk kann somit nicht auf herkömmliche Weise durch Editieren der zuständigen Files konfiguriert werden, sondern nur mit Hilfe der XSCONSOLE (ein Shell-Tool) oder durch das Xen-Center. Ein manueller Eingriff in diese Datenbank kann das System irreparabel zerstören. Dies konnte durch unsere Tests reproduziert werden. Die grafische Oberfläche ist zwar bedienerfreundlich, vermittelt aber den Eindruck, dass man in einer Art Black Box gefangen ist. Schließlich fallen durch die kommerzielle Lösung jährlich Lizenzkosten an.

Bei der Open-Source Xen-Lösung fällt ein proprietärer 7x24-Stunden-Support natürlich gänzlich weg, man ist gleichsam auf sich allein gestellt. Andererseits ist der Quellcode öffentlich zugänglich (und somit schlimmstenfalls auch selbständig modifizierbar) und eine wachsende Community tauscht ihre Infos und Erfahrungen über Foren aus. Nicht zuletzt verfügt die Abteilung Standardsoftware über exzellentes Know-how und Erfahrung in ihren eigenen Reihen.

Projektrealisierung und Wartung

Nach intensiver Prüfung und Abschätzung aller Implikationen wurde schließlich dem Open-Source Szenario der Vorzug gegenüber der proprietären Lösung gegeben. Softwaremäßig sollte für die implementierten Xen-Server xen1.zid und xen2.zid mit Linux-Standardkomponenten das Auslangen gefunden werden, um im Notfall so schnell wie möglich auf andere Server umsteigen zu können, der Betrieb erfolgt unter Debian 6.0 (squeeze, 64-bit Version, seit Februar 2011 stable) mit Xen 4.0.1 (die im Moment aktuelle Variante) und den QEMU-Tools zur Konvertierung der Images von anderen Formaten (wie z. B. VMware).

Für die beiden Dell R710 Server wurden zunächst redundante Standorte im Maschinenraum Freihaus und im Ausweichrechenzentrum (Gußhausstraße) gewählt. Beide Server sind sowohl über das Kleinserver-Segment als auch über ein Management-LAN erreichbar. Ein zusätzliches VLAN zur optionalen Synchronisation von Bereichen der Raid-Disks (mittels drbd) wurde ebenfalls eingerichtet.

Jeder Rechner verfügt dabei über folgende Hardware-Konfiguration: 2 schnelle 73 GB Harddisks (SAS, 15000 rpm Zugriffszeit ca. 3 ms) werden mit RAID1 zur Systempartition konfiguriert, für den Datenbereich und damit die virtuellen Instanzen stehen auf RAID5 (5 Stück zu je 300 GB + 1 Stück global hot spare, je ca. 4 ms Zugriffszeit) etwa 1200 GB Plattenplatz zur Verfügung. Jedes System verfügt über 24 GB Arbeitsspeicher, als Prozessoren kommen 2 Stück Intel Xeon X5650 zum Einsatz, das sind insgesamt 12 CPU-Kerne.

Im laufenden Betrieb unterscheiden wir in der Zuständigkeit zwischen der Betreuung und Wartung des Xen-Systems und jener der auf dem System laufenden Instanzen. Erstere erfolgt durch das so genannte Core-Team, während die Ausfallsszenarien und Zuständigkeiten für die zu portierenden Systeme unverändert übernommen wurden, das personelle Redundanzkonzept ist ausdefiniert, umfasst im allgemeinen drei Personen je Server und ist für die Beteiligten dokumentiert und einsehbar. Zu den Aufgaben des Core-Teams zählen neben dem Aufsetzen des Systems das Durchspielen von Ausfallsszenarien, die Diskussion und Implementierung von Monitoring und Logging sowie die Entwicklung von Maßnahmen im Störfall durch umfangreiches Testen. Auch nach dem Übergehen in den operativen Betrieb werden zu Schulungszwecken regelmäßige Meet-ings dieser Gruppe durchgeführt.

Für die Zukunft ist im Virtualisierungsbereich auf Grund des sich abzeichnenden Erfolges eine sukzessive Erweiterung der Hardwarekomponenten bzw. die Anschaffung eines weiteren Entwicklungs- und Testsystems, auf dem auch weniger ausfallssensible Instanzen permanent gehostet werden können, geplant.

Operativer Betrieb am Beispiel des Updateservers msus.tuwien.ac.at

Für die einzelnen Benutzer (also die Betreiber der Server und Services) wurden Accounts eingerichtet und Möglichkeiten zur Steuerung und zum Backup der virtuellen Maschinen geschaffen. Bis zum Jahresende wurde neben den Lizenzservern auch der Microsoft Updateserver virtualisiert, der bereits im Dezember 2010 seinen vollen Produktionsbetrieb aufgenommen hat.

Der Start einer Instanz von msus (4 GB RAM, 4 CPU-Kerne und 200 GB Plattenplatz sind für den operativen Betrieb unter Server 2008R2 im Moment ausreichend) erfolgt auf dem Produktionssystem (Maschinenraum, xen1) durch den Befehl

xm create msus.conf

Ein Herunterfahren der Instanz geschieht sauber durch shutdown innerhalb der Instanz aus dem laufenden Betriebssystem heraus, falls notwendig aber auch durch

xm shutdown (destroy) msus

Ganz bequem kann die laufende Instanz (auf die täglich über 2000 Clients zugreifen) bei Bedarf ausfallsfrei aus dem Maschinenraum ins Ausweichrechenzentrum verlegt werden:

xm migrate -l msus xen2

Einen Überblick über die laufenden Instanzen kann man sich leicht durch den Befehl

xm list

verschaffen.

import os, re
arch = os.uname()[4]
kernel = "/usr/lib/xen-default/boot/hvmloader"
builder='hvm'
vcpus=4
memory = 4096
shadow_memory = 8
name = "msus"
vif = [ 'type=ioemu, bridge=xenbr1,mac=00:01:02:03:04:05' ]
disk = [ 'phy:/dev/drbd1,xvda,w' ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
boot="c"

acpi=1
apic=1
sdl=0
keymap='de'
stdvga=0
serial='pty'
usbdevice='tablet'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
on_xend_stop = 'shutdown'
on_xend_start = 'ignore'
localtime = 1

Auszug aus der Konfigurationsdatei der Instanz des Microsoft-Updateservers