© Achiartistul, 123RF.com

Am 3. Februar erschien die aktuelle Bexar-Release von Open Stack, der freien Architektur für Cloud Computing. Vor der Tür steht schon die nächste Version: Cactus. Wie Admins damit eine hybride Compute- und Storage-Wolke bauen und warum sich das Warten noch lohnt, zeigt dieser Artikel.

Kakteen sind normalerweise stachelig und schmerzhaft für jeden, der mit ihnen unvorsichtig umgeht. Warum die Nasa, ein großer amerikanischer Provider (Rackspace) und zahlreiche IT-Großunternehmen der nächsten Release ihres Cloud-Stack gerade den Namen der pieksenden Cactaceae verpasst haben, wird wohl ein Rätsel bleiben.

Industriestandard

Sicher ist jedoch, dass die mittlerweile über 50 Mitglieder des Konsortiums einen handlichen und offenen Industriestandard fürs Cloud Computing entwickeln wollen und dafür bereits einiges Know-how investiert haben. Open Stack ([1], [2]) soll der offene Stapel für die hybride Wolke werden. Dazu setzt es auf bewährte Technologien wie I-SCSI, KVM oder auch die Eucalyptus-Tools [3] und verbindet diese mit Hilfe zweier Dienste (Swift [4] und Nova [5]) und eines API zu einer Komplettlösung.

Nova, der Compute-Manager, kontrolliert die Knoten der Wolke, während Swift als Storage-Manager die Images der zu virtualisierenden Systeme verwaltet. Das Open Stack Dashboard, ein Webinterface (Abbildung 1), administriert die Wolke, hier fügt der Admin externe oder interne Ressourcen hinzu. Alles geht dann aber noch nicht: Für den reibungslosen Betrieb seiner Infrastruktur nutzt der Admin die deutlich weiter reichenden Möglichkeiten der CLI-Werkzeuge aus den Eucatools. Angesichts der teilweise ellenlangen Befehlsketten ist allerdings ein wenig Eingewöhnung notwendig.

Abbildung 1: Im Web-GUI von Open Stack konfiguriert der Admin seine hybride Wolke. Das klappt mit internen oder externen Ressourcen, zum Beispiel aus Amazons Diensten.

Aber die Mühe lohnt sich: So stehen beispielsweise Xen, KVM oder Hyper-V für die Virtualisierung bereit. Seit der vor wenigen Wochen erschienenen Release Bexar beherrscht Open Stack IPv6 und erkennt vom Admin registrierte Images automatisch.

Doch das Konsortium, dem auch Canonical, Citrix, Intel und AMD angehören, treibt die Weiterentwicklung schnell voran: Im April soll schon die nächste Version erscheinen. Bexar war von Anfang an nur als Zwischenrelease geplant, deshalb zeichnen sich manche Features von Cactus bereits jetzt in Patches und Blueprints ab.

Seit Bexar ermöglicht es der projekteigene Object-Storage namens Swift, Objekte mit einer Größe von mehr als 5 GByte bereitzustellen. Dazu kamen die ersten Grundlagen für ein zu Amazons Simple Storage Service (S3, [6]) kompatibles API. Den bisher nur für Entwicklungszwecke geeigneten Authentifizierungslayer »devauth« haben die Entwickler durch »swauth« ersetzt.

Wesentlich umfangreichere Änderungen erfolgten in Nova, dem Dienst zur Verwaltung virtueller Maschinen. Im Netzwerkbereich ist IPv6 nun fast vollständig implementiert. Einen Zugriff auf die Ausgabe einer seriellen Konsole erlaubt »euca-get-console-output«, falls diese im Gast konfiguriert ist. Alternativ ist das auch über das Open-Stack-API oder über einen Proxydienst via Webinterface möglich. Für neue Instanzen unterstützt Open Stack jetzt das Copy-on-write-Format (COW), was gerade beim gleichzeitigen Start vieler virtueller Maschinen viel Zeit und Storage spart.

Als Volumes, also Devices, die in Instanzen als Speichermedien bereitstehen, sind neben I-SCSI auch Sheepdog [7] und Ceph/Rados [8] möglich. I-SCSI ist mit dem aktuellen Entwicklungsstand – entgegen den Angaben in den Bexar Release Notes – nicht nur mit dem Xen-API nutzbar, die Autoren dieses Artikels konnten auch erfolgreich I-SCSI-Volumes in KVM-Instanzen einbinden.

Glance

Als neuen Dienst fügten die Entwickler dem Stack Glance [9] hinzu, der in Zukunft die Kommunikation zwischen Nova und dem Object-Storage übernehmen soll. Glance setzt sich aus den Komponenten »glance-api« sowie »glance-registry« zusammen, die über ein REST-ful-API (Abbildung 2) kommunizieren. Die Metadaten der Images landen in einer Datenbank, etwa MySQL oder SQLite, wo sie der Admin mit dem Programm »glance-manage« verwaltet.

Abbildung 2: Überblick über die einzelnen Komponenten des neuen Glance-Dienstes in Open Stack. API und Registry verbinden Datenbank und Clients über Adapter mit dem Storage.

Als Object-Storage unterstützt Open Stack neben Swift auch Amazons S3 direkt, aber auch eine Ablage auf einem lokal eingebundenen Dateisystem. Die Glance-Konfiguration erfolgt über die Konfigurationsdatei »/etc/glance/glance.conf«. Für einen einfachen Test reicht dort:

filesystem_store_datadir=/srv/glance
default_store = file[...]

Anschließend lassen sich mit »glance-control all start« die Dienste »glance-api« und »glance-registry« starten. Wer hier eine Firewall im Einsatz hat, muss die TCP-Ports 9191 und 9292 öffnen, beispielsweise durch eine IPtables-Regel. Nach dem Start der Dienste lädt der Admin mit »glance-upload« neue Images in den angebundenen Object-Storage hoch (Listing 1).

01 glance-upload --host chronos testing.img testing
02  Stored image. Got identifier: {u'created_at': u'2011-02-25T11:36:45',
03   u'deleted': False,
04   u'deleted_at': None,
05   u'id': 5,
06   u'is_public': True,
07   u'location': u'file:///srv/glance/5',
08   u'name': u'testing',
09   u'properties': {},
10   u'size': 102400,
11   u'status': u'active',
12   u'type': u'raw',
13   u'updated_at': None}

Damit auch Nova seine Images von Glance bezieht, muss der entsprechende Image-Service in der Konfigurationsdatei »/etc/nova/nova.conf« eingetragen sein:

--image_service=nova.image.glance.GlanceImageService
--glance_host=chronos
--glance_port=9292[...]

Die Änderung macht einen Restart von »nova-compute« erforderlich, da die Dienste derzeit noch keinen »SIGHUP«-Handler enthalten.

Dashboard und Konsole

Mit dem Dashboard [10] steht seit Bexar eine Referenzimplementierung für ein auf Django fußendes Webinterface zur Verfügung. Derzeitig lassen sich einfache Aufgaben, etwa eine neue Instanz oder ein neues Volume erzeugen, durchführen und laufende Instanzen anzeigen. Abbildung 1 zeigt diese für das Projekt »openstack«. Die weitgehend selbsterklärenden Webschnittstelle, deren Installation [11] beschreibt, nutzt für alle Aktionen die Eucatools, die Entwickler arbeiten jedoch daran, alle Funktionen über das Open-Stack-API anzubieten.

Mit »nova-ajax-console-proxy« kann der Admin über eine serielle Konsole auf eine laufende Instanz zugreifen. Dieser Proxydienst reicht zum Beispiel Ajaxterm auf die serielle Schnittstelle einer virtuellen Maschine durch, womit sich beispielsweise auch Instanzen mit Netzwerkproblemen retten oder mit »top« Performancedaten auslesen lassen (Abbildung 3). Allerdings braucht der virtuelle Gast dafür selbst eine serielle Konsole. Unter Linux aktiviert diese der Eintrag in der »/etc/inittab«:

Abbildung 3: Funktioniert meist selbst dann noch, wenn das virtuelle Netz abgeraucht ist: Open Stack erlaubt den Zugriff auf serielle Konsolen der virtuellen Maschinen, hier im Webinterface.

s0:2345:respawn:/sbin/getty -L 115200 ttyS0 vt102

Nach solchen Änderungen in einem Image muss der Open-Stack-Admin allerdings jetzt noch auf allen Compute-Nodes das entsprechende Abbild in »/var/lib/nova/instances/_base/« löschen, damit der Object-Storage es neu abholt. Alternativ lädt der Admin das Image noch einmal hoch und registriert es neu. Cactus wird dafür eine Checksummen-Funktion anbieten.

Vorlagen

Das von »nova-compute« verwendete Template zur Konfiguration virtueller Maschinen der Libvirt liegt in »nova/virt/libvirt.xml.template« und bedarf ebenfalls einer Anpassung (Listing 2). Den Pfad zu dem modifizierten Template macht die Option »–libvirt_xml_template=Datei« in »/etc/nova/nova.conf« bekannt.

01 <!--
02 <serial type="file">
03     <source path='${basepath}/console.log'/>
04     <target port='1'/>
05 </serial>
06 -->
07
08 <console type='pty' tty='/dev/pts/0'>
09     <source path='/dev/pts/0'/>
10     <target port='0'/>
11 </console>
12
13 <serial type='pty'>
14     <source path='/dev/pts/0'/>
15     <target port='0'/>
16 </serial>

Den neuen Konsolenproxy startet »nova -ajax-console-proxy -flagfile=/etc/nova/nova.conf« auf einem beliebigen System. Sinnvoll ist es, dafür das System mit dem Nova-API-Dienst selbst auszuwählen und anschließend auf allen Knoten, auf denen Nova-Compute läuft, in »/etc/nova/nova.conf« das Flag »–ajax_console_proxy_url=http://PROXY_HOST:8000« hinzuzufügen.

Nun lässt sich mit dem neuen Programm »euca-get-ajax-console« für beliebige laufende Instanzen eine URL für den Zugriff anfordern:

chronos:~ # euca-get-ajax-console i-0000068b
 http://chronos:8000/?token=d8545d2d-b43c-4615-8cd7-99ab4f96bccc

Der ebenfalls neue Dienst »nova-instancemonitor« hilft dabei, die Ressourcen-Nutzung laufender Instanzen mit dem Dienst »nova-compute« zu visualisieren. Für jede Instanz erfasst RRD-Tool die Nutzung von CPU, Netzwerk und Storage. Dazu muss »nova-instancemonitor« laufen, zusätzlich zum »nova-compute«-Dienst. Die RRD-Archive sowie Grafiken landen in Unterverzeichnissen von »/var/lib/nova/monitor/instances/«.

Die Entwicklung des Stack verläuft derzeit so rasant, dass Bexar bereits in Kürze veraltet sein wird und nicht mehr für eine Evaluierung taugt. Kurz vor Redaktionsschluss erschien das wohl einzige Maintenance-Update. Cactus steht schon in den Startlöchern. Mit einem Blick in die Bugreports auf der Webseite und ein wenig Warten spart sich der Admin viel Arbeit und Kopfzerbrechen.

Cactus

So haben die Entwickler einige Fehler im Handling der IPtables-Regeln behoben, die verhinderten, auf einem Nova-Compute-Knoten mehrere Instanzen zugleich von einem Image zu starten. Auch Timing-Probleme bei der Verwendung von I-SCSI haben sie gelöst. Als neuer Hypervisor ergänzt Vsphere wahrscheinlich das Portfolio. Zudem steht die Möglichkeit der Live-Migration kurz vor dem Upstream, und es soll endlich möglich werden, in Instanzen mehrere Netzwerkkarten zu verwenden.

Nova-Manage ermöglicht neue Instanztypen, die derzeit noch direkt im Code definiert sind. Die Entwickler überarbeiten auch den Scheduler, der die Verteilung von Aufgaben an die einzelnen Dienste übernimmt, sodass er auf mehreren Systemen lauffähig ist. Das soll einen weiteren Single Point of Failure entfernen: Bisher läuft das Queuing über AMQP, meist in Verbindung mit Rabbit MQ als Server. In einiger Zeit soll das eigenständige Projekt Burrow ([12], [13]) diese Vorläufer ersetzen.

Als Datenbank-Backend erlaubt das Framework auch andere Systeme. Mit Cactus soll PostgreSQL problemlos funktionieren. Wann und ob weitere Datenbanken wie zum Beispiel Oracle hinzukommen, bleibt abzuwarten.

In Entwicklung

Viel Arbeit stecken die Entwickler ins Logging von Cactus, das sie für eine einfachere Fehleranalyse komplett überarbeiten. Zudem wollen sie die unzähligen Konfigurationsmöglichkeiten von Nova strukturieren und dafür eine Dokumentation zusammentragen.

Die passable offizielle Dokumentation [14] ist zwar gegenwärtig noch nicht auf dem neuesten Stand, erfährt aber derzeit viel Zuwendung. Die Entwicklergemeinde erweist sich als sehr aktiv, sie reagiert sehr schnell auf Bugreports und versucht den Code zu stabilisieren sowie die Qualität zu erhöhen. Eine vollständige Liste angestrebter neuer Funktionen findet sich unter [15].

Wer Open Stack evaluieren will, kann sofort loslegen und bekommt einen guten Einblick. Für produktive Cloud-Computing-Infrastrukturen sollte er aber die Release von Cactus abwarten. (mfe)