Das Hypervisor-übergreifende Management-Tool Archipel landet ein schickes GUI an und kommunziert mit den virtuellen Instanzen, die Server mit Xen, KVM, Open VZ und VMware bereitstellen. Dazu nutzt es das Jabber-Protokoll und erweist sich als ausgesprochen unterhaltsam.

Die Open-Source-Welt hat Virtualisierungstechnologien vom Allerfeinsten hervorgebracht – darunter die Hypervisoren Xen und KVM, APIs und Schnittstellen wie die Libvirt [1] und viele mehr. Allein an wirklich gut gestalteten und Hypervisor-übergreifenden Management-Tools für virtualisierte Umgebungen fehlt es bisher noch.

Die wenigen Vertreter dieser Gattung sind entweder auf eine bestimmte Oberfläche festgelegt wie zum Beispiel die X11-Applikation Virt-manager [2] oder sehr umfassende Werkzeuge mit Cloud-Ambitionen wie Xens Enomalism [3], die für normale Hypervisor-Administrationsaufgaben überdimensioniert sind.

Gefragt bei Administratoren sind mehr und mehr intuitive Web-GUIs, die den üblichen Zoo von virtuellen Systemen – von Xen über KVM bis hin zu VMware – komplett und zentral verwalten und den Überblick auch bei Tausenden von virtuellen Maschinen herstellen.

Hier springt Archipel [4] mit frischen Ansätzen in die Bresche. Das kleine französische Entwicklerteam beansprucht für sich, es besser als Enomalism oder Proxmox [5] machen zu wollen, und greift dazu tief in die Open-Source-Toolbox: Das Web-GUI bedient sich des Cappuccino-Javascript-Framework [6], um eine Desktop-ähnliche Benutzer-Erfahrung zu bieten. Im Kern nutzt das System das Libvirt-API, um die Steuerung aller bekannten Hypervisoren wie KVM, Xen, Open VZ und VMware zu ermöglichen.Vor Kurzem erschien die zweite Beta von Archipel, dieser Artikel zeigt, ob das System hält, was es verspricht.

Plausch mit dem Hypervisor

Beim intern verwendeten Protokoll zum Anbinden des Hypervisors beschreitet Archipel mit XMPP neue Wege. Das von Jabber bekannte Instant Messaging Protokoll dient dem internen Nachrichtenverkehr für Steuerung und Information in Realtime. Dies ermöglicht sogar die Nutzung von Jabber-Clients, um Statusinformationen von VMs abzurufen oder ihnen Kommandos zu schicken.

Archipel besteht im Kern aus drei Komponenten (Abbildung 1):

Abbildung 1: Die Archipel-Architektur mit Hypervisoren, virtuellen Maschinen, Archipel-Agenten und redundant ausgelegten XMPP-Servern.

• Der Archipel-Client (Testclients unter [7]) stellt ein stark an I-Tunes erinnerndes, optisch ansprechendes Web-GUI zur Verfügung, das dank Javascript in den meisten Browsern läuft.
• Pro Hypervisor-Instanz kommt Server-seitig ein Archipel-Agent zum Einsatz. Der ist in Python geschrieben und modular aufgebaut. Der Administrator nutzt Shellkommandos, um ihn zu installieren und zu aktualisieren.
• Über XMPP kommuniziert der Agent via Libvirt mit virtuellen Maschinen. Das macht das Aufsetzen eines Jabber-Servers erforderlich.

Archipel empfiehlt den Einsatz von Ejabberd [8], andere Implementierungen sollten aber auch funktionieren. Die Anweisung, eine VM zu starten, durchläuft der Reihe nach Jabber-XMPP auf dem Archipel-Client, dann den XMPP-Server, erreicht die Libvirt (Libvirt-create) und endlich den Hypervisor (etwa KVM-create).

Installation

Schon bei der Installation zeigt sich einer der größten Nachteile von Archipel, die äußerst magere Dokumentation. Immerhin ist das korrekte Setup recht ordentlich beschrieben [9], auch wenn dort noch ein paar Bugs lauern. Zunächst installiert der Archipel-Interessent Ejabberd, mindestens in der Version 2.1.6, am besten über den Binärinstaller. Den XMPP-Server muss er danach um die Module »ejabberd_xmlrpc« und »mod_admin_extra« erweitern. Dann holt er sich die Quellen, kompiliert die Erlang-Sourcen und kopiert die resultierenden »*.beam« -Dateien ins »ebin« -Verzeichnis des Ejabberd-Daemon (Listings 1 und 2).

01 wget http://www.ejabberd.im/files/contributions/xmlrpc-1.13-ipr2.tgz 02 tar -xzvf xmlrpc-1.13-ipr2.tgz 03 cd xmlrpc-1.13/src 04 make 05 cd ../../ 06 cp ebin/*.beam /opt/ejabberd-2.1.6/lib/ejabberd-2.1.6/ebin

01 cd /usr/local/src/ejabberd-modules/mod_admin_extra/trunk/ 02 ./build.sh 03 cp ebin/mod_admin_extra.beam /opt/ejabberd-2.1.6/lib/ejabberd-2.1.6/ebin

Anschließend ist die Anpassung von »/opt/ejabberd-2.1.6/conf/ejabberd.cfg« (je nach Distribution vielleicht »/etc/ejabberd/ejabberd.cfg« ) an der Reihe: Hier aktiviert der Administrator die neu erstellten Module und setzt vor allem den vollqualifizierten Domainnamen (FQDN) seines Servers ein. Leider führt der vom Archipel-Projekt dokumentierte Konfigurationsvorschlag an mehreren Stellen in die Irre, daher sollte sich der Admin besser an Listing 3 orientieren.

01 {hosts, ["jabber.deutschewolke.datenwerk-it.de"]}. 02 [...] 03 {listen, 04 [ 05 {4560, ejabberd_xmlrpc, []}, 06 {5280, ejabberd_http, [ 07 http_bind, 08 http_poll, 09 web_admin 10 ]} 11 ]}. 12 [...] 13 {modules, 14 [ 15 {mod_adhoc, []}, 16 {mod_http_bind,[]}, 17 [...] 18 {mod_admin_extra, []} 19 ]}. 20 [...]

Das Erstellen eines Administratorkontos schließt die Ejabberd-Einrichtung ab:

ejabberdctl register admin FQDN Passwort

Das Einrichten des Archipel-Agenten geht etwas schneller von der Hand, am Anfang steht der Check der Abhängigkeiten. Nötig sind Python ab Version 2.5, Libvirt ab Version 0.8.7 sowie ein Hypervisor wie KVM mit Qemu ab Version 0.12.5. Zudem sollten auch Qemu-img sowie die Python Setup Tools an Bord sein. Die folgende Befehlssequenz installiert den Archipel-Agenten:

easy_install archipel-agent archipel-initinstall

In »/etc/archipel/archipel.conf« setzt der Admin nun die Server-FQDN ein und startet Archipel mit dem mitgelieferten Init-Skript:

/etc/init.d/archipel start

Abschließend bedarf es noch zweier Ejabberd-Pubsub-Nodes, damit das Berechtigungssystem sowie die Tag-Verwaltung funktionieren:

archipel-tagnode --jid=admin@FQDN --password=Passwort --create SUCCESS: pubsub node /archipel/tags created! archipel-rolesnode --jid=admin@FQDN --password=Passwort --create SUCCESS: pubsub node /archipel/roles created!

Auf das im Archipel-Wiki ausführlich beschriebene eigenhändige Kompilieren des Clients kann der Administrator getrost verzichten, stattdessen besorgt er sich unter [10] eine aktuelle Archipel-Client-Distribution. Diese entpackt er einfach in ein lokales Verzeichnis und öffnet die Datei »index.html« in einem Browser. Bei dem folgenden Login ist es wichtig, die Jabber-ID fully qualified einzugeben, also mit dem kompletten Servernamen (Abbildung 2). Als Passwort dient das beim Erstellen des Administratorkontos definierte Credential. Die URL für das Feld »Service BOSH« folgt dem Schema »http://FQDN:5280/http-bind« .

Abbildung 2: Ein Archipel-Login auf dem Client verlangt den kompletten Login-Namen (inklusive Domain) auch im Feld »Jabber ID«.

Wo laufen sie denn?

Archipel präsentiert sich dem VM-Verwalter aufgeräumt und bis ins Detail liebevoll gestaltet. Doch ohne Bewohner – also Hypervisor-Hosts und VMs – taugt der schönste Archipel nicht viel. Der erste Schritt zur Population erschließt sich dabei nicht unbedingt von selbst: Der Administrator muss zunächst den Hypervisor in Archipel anmelden. Hierzu klickt er unten links auf das »+« -Zeichen, um einen neuen (Jabber-)Kontakt im Archipel-XMPP-System anzulegen.

Als Kontakt-ID gibt er »Hypervisor@FQDN« an und bestätigt mit »Ok« . Der Hypervisor taucht in der Kontaktleiste links mit seinem Avatar auf. Die Hauptansicht des Hosts zeigt direkt die so genannte »Health« -View mit allen wichtigen Informationen in Echtzeit (Abbildung 3).

Abbildung 3: Der Gesundheitszustand eines Hypervisors in Archipels »Health«-Übersicht.

Die VMs des Hypervisors sind Archipel damit aber leider noch nicht bekannt. Der Administrator hat nun zwei Möglichkeiten: Er kann bereits existierende VMs der Archipel-Verwaltung hinzufügen, wobei ihm das Skript »archipel-importvirtualmachine« hilfreich zur Seite steht. Dieses benötigt zwei Argumente, die vorab zu ermitteln sind: Zum einen die SQLite-3-Datenbank-Beschreibungsdatei des lokalen Hypervisors, zu finden unter »/var/lib/archipel/hypervisor.sqlite3.2« ), und zum anderen die UUID der zu importierenden VM. Die ermittelt am einfachsten das Libvirt-Tool Virsh:

virsh --connect qemu:///system list dominfo ID_der_VMUUID

Mit der UUID geht es nun an den eigentlichen Import (Listing 4). Die VM erscheint nun ebenfalls in der Kontaktliste links. Von hier aus kann der Archipel-Verwalter ihren Status einsehen sowie alle Lifecycle-Kommandos wie Start, Stop, Pause bis hin zur Migration auf einen anderen Hypervisor-Host ausführen oder Snapshots erstellen.

01 /etc/init.d/archipel stop # Archipel Agent stoppen 02 archipel-importvirtualmachine --file=/var/lib/archipel/hypervisor.sqlite3 --uuid=UUID --xmppserver=FQDN --name=vm1 03 /etc/init.d/archipel start # Archipel Agent stoppen

Die zweite Möglichkeit, die VM-Population in Archipel wachsen zu lassen, besteht darin, virtuelle Maschinen direkt im Archipel-GUI anzulegen. Auch das ist in wenigen Schritten erledigt. Zunächst legt der Verwalter das gewünschte Installations-ISO in das Verzeichnis »/vm/iso« . Im GUI klickt er dann auf »New VM« , wechselt zum Reiter »Definition« und setzt die gewünschten Einstellungen wie RAM, Festplattenlaufwerke und Netzwerk (Abbildung 4).

Abbildung 4: Die Konfiguration einer virtuellen Maschine in Archipel erschließt sich dem Admin von selbst.

Anschließend legt er eine neue (virtuelle) CD-ROM an und stellt den Bootvorgang von CD ein. Ein Klick auf »Play« erweckt die VM und damit den Installationsvorgang zum Leben. Ihre grafische Oberfläche bedient der VM-DJ in einer sehr schlanken und ansehnlichen, in Javascript verfassten VNC-Implementierung, zu finden auf dem Reiter »VNC« .

Mit einer virtuellen Maschine reden

Ein originelles Detail, das zugleich zeigt, wie konsequent Archipel auf dem XMPP-Protokoll aufbaut, ist der integrierte Chat. Der taugt zwar auch zur Kommunikation zwischen den Administratoren der Umgebung, überrascht aber vor allem durch die Möglichkeit, direkt und verbal mit seinen Hypervisoren und VMs zu kommunizieren (Abbildung 5).

Abbildung 5: Auf Chat-Anfragen antwortet Archipel in der Ich-Form und gibt bereitwillig Auskunft über den Gesundheitszustand der Hypervisoren und der VMs.

Das natürlich klingende sprachliche Vokabular von Archipel ist zwar sehr begrenzt, die Kommunikation bereitet aber Spaß und ist durchaus praxistauglich. Ein »how are you« quittiert eine VM zum Beispiel mit einer komprimierten Statusmeldung in der ersten Person Singular. Konsequenterweise funktioniert dies von jedem Jabber-Client aus.

Auch darüber hinaus zeigt sich Archipel auskunftsfreudig. Logs aller Systeme und Aktionen können Admins zur Echtzeit im GUI einsehen, ausgewählte Benachrichtigungen empfangen sie per Push-Notification auf dem Smartphone. Dafür lädt sich der Sysadmin zum Beispiel die »App Notifications« -App auf sein I-Phone und trägt den privaten API-Key in »archipel.conf« ein.

Rollenkonzepte, Deployment, Tagging

Archipel bringt als ambitionierter VM-Verwalter mächtige Deployment-Werkzeuge mit: Das integrierte VM Casting Protocol (ursprünglich von Enomalism entwickelt) stellt via RSS-Feeds Appliance-Downloads für die Hypervisoren bereit. Damit sind auch automatisch installierbare, auf definierten Appliances basierende Instanzen und Updates von VMs möglich.

Archipel-Admins können zudem Appliances direkt aus vorhandenen virtuellen Maschinen selbst erstellen, sie quasi als Templates ablegen und für neue VMs nutzen. Archipel unterstützt dabei das XVM2-Templateformat (ebenfalls eingeführt von Enomalism, bekannt auch von Xen Server) und demnächst den verbreiteten OVF-Standard.

An diesem Punkt hören viele Verwaltungstools auf, nicht jedoch Archipel, das mit einer ganzen Reihe weiterer Enterprise-Features aufwartet. Dazu gehört ein ausgefeiltes Rollenkonzept für das Definieren feingranularer Berechtigungen für unterschiedliche User und Rollen.

Für Admins sehr großer Umgebungen mit vielen VMs bringt es ein Tagging-System in Verbindung mit einer entsprechenden Suche mit sowie die Möglichkeit, Kontakte, also Hypervisoren und virtuelle Maschinen, logisch zu gruppieren.

Elegant ist auch die Fähigkeit, mittels Massen-Kommandos ganze Gruppen von VMs mit einem einzigen Klick zu steuern, zum Beispiel mehrere gleichzeitig zu starten, zu stoppen oder zu migrieren. Den Administratoren steht außerdem ein Scheduler zur Verfügung, um VM-orientierte Aktionen im Voraus zu planen und automatisiert ablaufen zu lassen.

Clustern, geografische Migration und Billing

Damit kein Single Point of Failure durch den Einsatz eines einzelnen XMPP-Servers entsteht, sieht Archipel Clustering vor. Es unterstützt Multisite-Setups und ist in der Lage, die Hypervisor-Hosts und zugehörigen VMs grafisch in einer integrierten Google-Map zu visualisieren und diese auf der Weltkarte zu verschieben, de facto zu migrieren. Auf der Roadmap stehen außerdem eine modulare Erweiterung um Cloud-Computing-Fähigkeiten inklusive Billing.

Sobald das angekündigte SDK erscheint, dürfte der eigenen, modularen Weiterentwicklung nichts mehr im Wege stehen. Schade nur, dass die finale Version vermutlich noch bis Ende 2011 auf sich warten lässt. Wer gern experimentiert und ein wenig Zeit erübrigen kann, dem sei ein Test ans Herz gelegt. Etwas Geduld muss der Interessent aber mitbringen und sich derzeit auch mit sehr knapper Dokumentation begnügen. Bleibt zu hoffen, dass die aufkeimende Archipel-Community schnell wächst und durch entsprechende Beiträge auch die typischen Kinderkrankheiten behebt.

Archipel ist aber jetzt schon weit mehr als ein schickes GUI für Open-Source-Hypervisoren. Ambitionierte Administratoren heterogener virtueller Umgebungen finden hier eine sehr interessante und leistungsfähige Alternative zu anderen Web-basierten Verwaltungstools. Kontaktfreudige Administratoren können sich über den IRC-Chat rasch Rat und Unterstützung aus der Community und von den Entwicklern selbst holen, diese haben sich auch bei den ersten Versuchen des Linux-Magazin-Autors als sehr hilfsbereit herausgestellt. (mfe)