© Rudmer Zwerver, 123RF.com

Damit Microsoft den Hype um Open Stack nicht verschläft, greift dem Konzern jetzt eine italienische Firma unter die Arme. Die verspricht, Open Stack mit dem Hypervisor Hyper-V zu verheiraten – und das gelingt dank Python erstaunlich gut. Grund genug, einmal etwas genauer hinzuschauen.

Microsoft und Linux, oft genug war das eine Beziehung voller Missverständnisse, FUD und Emotionen. Noch vor zwölf Jahren bezeichnete Steve Ballmer Linux als Krebsgeschwür [1], doch seit einiger Zeit ist der Konzern von seiner Konfrontationsstrategie abgerückt, setzt lautstark auf “Interoperabilität”, leistet gar einen beträchtlichen Beitrag zum Linux-Kernel und wird nicht müde, sich als Open-Source-Company zu präsentieren.

Linux by Microsoft

Microsoft nimmt mittlerweile beträchtlichen Anteil an vielen OSS-Entwicklungen und schottet seine Produkte gegen quelloffene Software längst nicht mehr so radikal ab wie früher. Freiwillig ist das nicht, denn ein Strategiewechsel tut not: Im Rechenzentrum dominiert in Zeiten der Cloud immer häufig das flexiblere Linux, Windows-Server kommen immer öfter in die Unterzahl.

Ein verbreitetes Vorurteil stellt die Fähigkeiten von Windows in modernen Cloudumgebungen in Frage – zu kompliziert seien Lizenzmanagement und Administration; das proprietäre System käme vergleichsweise schlecht mit den Cloudkonzepten der Linux-dominierten Wolken zurecht. Zugleich weiß jeder, der mal eine Migration betreut hat: Ganz ohne Windows geht es eben meistens doch nicht.

Bei der Cloud, so wie sie der folgende Artikel verwendet, dreht sich alles um das Bereitstellen von virtuellen Systemen, kombiniert mit den Vorteilen von Online-Speicherangeboten und der Möglichkeit für Benutzer, an einem Self-Service-Portal selbst und ohne Eingriff des Dienstleisters etwa neue virtuellen Maschine anzulegen oder Onlinespeicher bei Bedarf einfach zu erweitern.

Der Cloud-Computing-Umgebung selbst, im folgenden Beispiel dem derzeit von vielen Konzernen promoteten Open Stack ([2], [3], [4]), kommt die Aufgabe des Managements zu. Damit dieses hochdynamische Prinzip funktioniert, müssen die Komponenten einer Cloudumgebung aber in vielerlei Hinsicht zusammenspielen – und da liegt auch die Motivation hinter Microsofts Interop-Strategie.

Installation war gestern!

Die Umgebung verwaltet die Hypervisor-Knoten und kümmert sich um die Nutzerverwaltung und die der Netzwerktechnik, die ja üblicherweise auf Software-defined Networking (SDN) setzt. Zudem muss eine Cloud auch Betriebssystem-Abbilder bieten – niemand zwingt heute Kunden, die nur virtuelle Maschinen starten wollen, ein Betriebssystem zu installieren, am Ende noch von CD oder DVD!?

Grob gesagt, wären auf der einen Seite viele potenzielle Kunden dazu rein technisch gar nicht mehr in der Lage, auf der anderen Seite würde das den Vorgang, auch nur unnütz in die Länge ziehen und kostspielige Ressourcen belegen. In modernen Cloudumgebungen arbeitet der Kunde mit vorgefertigten Festplatten-Abbildern, aus denen er sich eines per Mausklick aussucht, dazu noch ein Speichergerät aus den von ihm gebuchten Ressourcen in der Cloud – fertig ist der neue Server.

Für die Cloud und ihren Hypervisor gilt: Paravirtualisierte Systeme arbeiten in der Regel deutlich schneller als ihre vollvirtualisierten Pendants. Damit Paravirtualisierung funktioniert, braucht das Gastsystem aber spezifische Treiber. Die lassen es wissen, dass es selbst virtualisiert läuft und mit einem Hypervisor zusammenzuarbeiten hat. Solange geeignete Treiber im Gastsystem zur Verfügung stehen, ist also alles in bester Ordnung. Aber der Treiber für den Gast muss speziell darauf abgestimmt sein, wie der jeweilige Hypervisor tickt. Ein vorhandener Treiber zur Paravirtualisierung in KVM hilft in einem Xen-Setup nicht weiter.

Windows als Gast

Wer Windows als Gast in den unter Linux verbreiteten KVM-VMs einsetzt – unabhängig davon, ob von Open Stack oder einer anderen Virtualisierungsumgebung gemanagt –, darf das Problem heute als gelöst betrachten. Die Treiber kommen zwar nicht direkt von Microsoft, aber vom KVM-Team. Das Fedora-Repository [5] bietet sie sogar digital signiert, sodass sie in allen aktuellen Windows-Versionen problemlos installierbar sind.

Windows-Installationen sind es gewohnt, eng mit der Hardware verknüpft zu sein, auf denen sie laufen. In einer Cloudumgebung geht das aber nur zum Teil, es gibt schließlich keine Garantie dafür, dass alle Hypervisor-Knoten auf exakt die gleiche Hardware setzen. Ganz im Gegenteil: Je länger die Wolke schon in Betrieb ist, desto bunter wird der Hardware-Mix. Und dann sind da ja auch noch streng rechnerspezifische Details wie der Lizenzschlüssel, der zu einer virtuellen Maschine gehört.

Fakt ist: All diese Informationen können nicht Teil des Windows-Abbilds sein, das der Cloudadministrator seinen Kunden zur Verfügung stellt. Das muss im Grunde ein nacktes Image sein, das keine wie auch immer gearteten spezifischen Konfigurationsparameter enthält. Microsoft stellt für genau dieses Problem eine Lösung in Form eines Werkzeugs namens Sysprep [6] bereit.

Mit ihm gelingt es, einem fertig installierten und konfigurierten Windows quasi das Gehirn zu entfernen. Das ist ganz und gar nicht ironisch gemeint: Alles, was spezifisch für diese eine virtuelle Maschine war – und dazu gehört auch der Lizenzschlüssel –, ist nach einem Sysprep-Aufruf verschwunden, das System präsentiert sich wieder jungfräulich. Genau das ist der Moment, in dem der Admin ein Image zieht und es in den Open-Stack-Imagestore lädt.

Gigabyte-große Images

Eine Eigenheit im Windows-Kontext fällt gelegentlich negativ auf: die Größe. Ein typisches Windows-Image ist ein paar GByte groß – für Linuxer unfassbar. Das verursacht beim Starten einer neuen virtuellen Maschine einige Probleme. Ohne auf die Hypervisor-abhängigen Unterschiede eingehen zu wollen, funktioniert der Start immer gleich: Das Management, beispielsweise Open Stacks Computing-Komponente Nova, triggert eine neue virtuelle Maschine auf einem Hypervisor-Knoten. Dann lädt der Computing-Knoten das Image aus dem Speichermanager Glance lokal auf seine Platte, um im nächsten Schritt die virtuelle Maschine von der lokalen Imagekopie zu starten. Je mehr Gigabytes das Image hat, umso länger dauert das. In diesem Punkt ist Linux klar im Vorteil.

Kleine Vorteile genießen Windows-VMs, die auf KVM setzen: Weil die Virtualisierung die so genannten Backing Images nutzt, muss der Hypervisor ein Image nur einmal laden und kann anschließend beliebig viele VMs durch das Anlegen von Deltafiles von diesen starten. Trotzdem gilt: Wer Windows-Images in seiner Wolke anbietet, tut gut daran, eine stabile und eher potente Netzwerkverbindung zwischen seinen Open-Stack-Knoten zu haben, weil ansonsten die ganze Sache lahmt.

Lizenz-Horror und Support

Wer Windows-VMs in Open Stack betreiben will, braucht technische Einschränkungen kaum fürchten, wohl aber die gleichen Lizenzierungs-Einschränkungen, wie sie eben auch bei konventionellen Virtualisierungs-Setups auftreten. Der Kasten “Die Sache mit den Lizenzen” nimmt sich des Problems an.

Nach der Installation und Klärung der Lizenzierung steht der Admin vor der Frage nach dem offiziellen Support für die virtualisierten Maschinen. Wer eine umfassende Cloud-Computing-Umgebung verkaufen möchte, muss seinen Kunden die Möglichkeit bieten, fast beliebige Applikationen laufen zu lassen.

Gerade im Windows-Umfeld finden sich bei den großen Suites in letzter Zeit aber immer mehr Programme, die in ihren Systemanforderungen spezifische Details für virtualisierte Umgebungen festlegen. Häufig steht dort die Einschränkung, dass in VMs der gesamte Stack, also vom Hypervisor bis zur virtuelle Maschine, ausschließlich Windows-basiert zu sein hat. Wenn der Kunde diese Anforderung nicht erfüllt, verweigert mancher Anbieter kurzerhand den Support.

Hilfe für Hyper-V

Derlei kommt natürlich Microsoft zugute, weil so auch in reinen Linux-Umgebungen Hosts mit Hyper-V auftauchen, die den vom Anbieter der spezifischen Applikation vorgegebenen Windows-Stack bereitstellen, obwohl es keine technische Notwendigkeit dafür gibt.

Doch die wichtigste Frage lautet: Wie vertragen sich Open Stack, Hyper-V und Redmonds Betriebssystem überhaupt miteinander? Oder ist hier gar separates Management mit redundanten Strukturen angesagt? Zur Verunsicherung trugen auch die Open-Stack-Entwickler im Februar 2012 bei, als sie die Unterstützung für Hyper-V ganz aus der damals neuen Version 2012.1 (Essex) entfernten.

Doch dann trat Cloudbase ([7], Abbildung 1)auf den Plan: Das italienische Unternehmen um Geschäftsführer Alessandro Pilotti kümmert sich im Grunde exklusiv um die Integration von Microsofts Hyper-V in Open Stack. Das geht so weit, dass Gerüchte in der Open-Stack-Community kursieren, Cloudbase sei nur eine von Microsoft gesteuerte Strohfirma, die es dem Windows-Konzern auf einfache Weise ermögliche, an Open Stack mitzuarbeiten, ohne dabei gleich die Altvorderen der “Corp” aufzuscheuchen.

Abbildung 1: Die italienische Firma Cloudbase hat viele der Open-Stack-Komponenten auf Windows portiert.

Was an dem Gerücht dran ist, muss sich erst noch zeigen, sicher ist hingegen, dass sich die Arbeit von Cloudbase sehr positiv auf die Hyper-V-Unterstützung in Open Stack auswirkt. Schon in Version 2012.2 (Folsom) war die Unterstützung wieder direkt in Open Stack und sie funktionierte besser als je zu vor.

Zunächst hatte Cloudbase das Hauptaugenmerk darauf gelegt, die für Hypervisor-Unterstützung wichtigste Open-Stack-Komponente – »nova-compute« – auf Windows mit installiertem Hyper-V lauffähig zu machen. Open Stack ist pures Python und das wiederum ist für Windows nebst brauchbarer Kommandozeile problemlos verfügbar.

Basierend auf dem Hypervisor-Code, der auch für Hyper-V bereits da war, sorgt das in Verona ansässige Unternehmen dafür, dass sich »nova-compute« völlig schmerzfrei auf Windows nutzen lässt: Die Entwickler spendierten der Software sogar einen eigenen Installer, sodass sich ein Windows-Rechner – so seltsam das klingen mag – deutlich leichter in einen Computing-Knoten für Nova verwandeln lässt, als ein Linux-System. Der Admin braucht lediglich einen mit Hyper-V ausgestatteten Rechner, sogar die Desktopsysteme (also Windows 7 oder 8) taugen dafür (Abbildung  2).

Abbildung 2: Leichter als mit Linux: In der Hyper-V-Konsole zeigt sich, wie nahtlos Cloudbase nova-compute in Open Stack integriert.

Das Netz

Cloudumgebungen nutzen Software Defined Networking (SDN) und degradieren die Switches im Rechenzentrum zu bloßem Eisen, um den Packetflow danach über die Cloudumgebung selbst zu kontrollieren. Der Nachteil: Zusammen mit der Virtualisierungssoftware muss auf den Hypervisor-Knoten noch eine Komponente laufen, die sich um das Netzwerk kümmert.

In Open Stack ist für das Netzwerk die Komponente Neutron verantwortlich, die bis vor Kurzem offiziell den Namen Quantum trug. Quantum setzt in der Standardkonfiguration auf Open Vswitch [8], um ein SDN zu etablieren.

Damit konnte Cloudbase bei Windows aber nichts anfangen, eine Art Open Vswitch für Windows existiert bis heute nicht. Deshalb strickten die Italiener ein eigenes Quantum-Plugin. Das erlaubt es zwar nicht, Hyper-V-Server und solche mit Linux und Open Vswitch in der gleichen Quantum-Umgebung laufen zu lassen. Aber wenigstens funktioniert so das Netzwerk zwischen Quantum und Hyper-V zufriedenstellend.

Cinder

Unter dem Namen Cinder firmiert in Open Stack die Komponente, die VMs mit persistentem Blockspeicher ausrüstet. Auch diese Software war auf Windows nicht lauffähig, bevor Cloudbase sich ihrer annahm. Cinder bekam einen grafischen Installer (Abbildung 3) spendiert und lässt sich jetzt auf Windows-Server-Systemen installieren, wobei die »cinder-volume« -Komponente den wichtigsten Teil ausmacht.

Abbildung 3: Der Cinder-Installer für Windows ermöglicht es, Speicher über I-SCSI von einem Windows-Server in der Cloud bereitzustellen.

Ab jetzt kann der Admin den Speicher auf dem Cinder-Volume-Host problemlos in Form von Blockdevices direkt an die laufenden VMs anhängen, ganz gleich, ob darin Linux oder Windows läuft. Dabei kommt schlicht I-SCSI zum Einsatz, das der Windows-Server schon mit Bordmitteln zu exportieren weiß.

Cloudbase-Init

Kommentare zum Cloud Computing greifen gerne zu folgender tierischen Analogie: Konventionelle IT-Setups bestanden aus Systemen, die wie kleine Kätzchen zu hegen und zu pflegen sind. Ein System in einer Open-Stack-Cloud jedoch ist im Grunde ein Herdenrind, dessen Ausfall den Besitzer emotional nicht mehr sonderlich beeinflusst. Schließlich lässt sich das ausgefallene System jederzeit durch ein anderes ersetzen, vielleicht sogar automatisch. Doch der Teufel steckt im Detail: Auch wenn eine virtuelle Maschine beliebig ersetzbar ist, bleiben doch ein paar spezifische Daten, die sie selbst kennen muss. Dazu gehören der Hostname oder der SSH-Schlüssel, die im System hinterlegt sein sollen, damit die entfernte Anmeldung klappt.

Für Linux-Gäste gibt es eine einfache und zuverlässige Möglichkeit, das Problem in Open-Stack-Clouds in den Griff zu kriegen: »cloud-init« . Das Shellskript, das ein Linux-Gast beim Starten aufruft, bedient sich der fest definierten URL »http://169.254.169.254:80/« .

Im Hintergrund kümmert sich Open Stack darum, dass der Request bei Novas Metadatenserver landet, wo sich im Anschluss ein entsprechendes Reply auf die Reise macht (Abbildungen 4 und 5). So erfährt die virtuelle Maschine, wer sie ist. Das ganze Prinzip scheint schamlos bei Amazon AWS geklaut zu sein, wo der gesamte Vorgang im Grunde genauso funktioniert.

Abbildung 4: Über den Metadatenservice erfahren virtuelle Maschinen jede Menge über sich selbst, zum Beispiel ihren Hostnamen.

Abbildung 5: Beim Starten rufen die meisten Cloudimages die Informationen vom Metadatenserver ab.

Windows-Port

Das einzige Problem daran: Das benutzte »cloud-init« ist Linux-spezifisch, eine Portierung auf Windows war für die Open-Source-Community technisch auch nicht sinnvoll. Doch Cloudbase hat in den sauren Apfel gebissen und eine Re-Implementation für Windows verfasst, die »cloudbase-init« ([9], Abbildung 6) heißt und auf Windows-Systemen im Grunde den gleichen Zweck erfüllt wie Cloud-init auf Linux-Systemen. Mittlerweile beherrscht »cloudbase-init« fast mehr Funktionen als sein Linux-Urahn und hat sich zu einem zuverlässigen Werkzeug gemausert.

Abbildung 6: Cloudbase-Init startet nach dem Booten der Windows-VMs und implementiert die gleichen Features, die cloud-init für Windows bietet.

Große Ankündigungen

Windows-Systeme mit Hyper-V lassen sich schon jetzt sehr ordentlich in eine Open-Stack-Umgebung integrieren, nur das Thema Netzwerk bereitet noch Kummer. Aber Cloudbase ruht sich keinesfalls auf den erreichten Lorbeeren aus: CEO Pilotti sorgte im Juni als Vortragender beim Open Stack CEE Day 2013 [10] in Budapest mit einem ambitionierten Plan für Aufsehen: Cloudbase arbeitet daran, Open Vswitch auf Windows nativ lauffähig zu machen (Abbildung 7).

Abbildung 7: Netzwerk in Open Stack: Neutron mit Open Vswitch ist der Standard, Cloudbase portiert gerade Open Vswitch auf das Betriebssystem aus Redmond.

Freilich würden davon alle Applikationen profitieren, die auf Open Vswitch setzen, aber im Open-Stack-Kontext wäre der Nutzen am offensichtlichsten. Denn sobald Open Vswitch für Windows funktioniert, wäre es de facto möglich, Hyper-V-Systeme völlig nahtlos in bestehende Clouds mit Open Stack zu integrieren und sie sogar unter der gleichen Oberfläche mittels Browser zu verwalten. Einzig die Live-Migration zwischen den einzelnen Servern bliebe das Problem, weil eine Live-Migration von KVM auf Hyper-V oder irgendeine andere Virtualisierungstechnik zurzeit nicht geht und wohl absehbar auch nicht zu erwarten ist. Das lässt sich im Open Stack aber gegebenenfalls dadurch abfangen, die Linux-Systeme und die Hyper-V-Server in eigene Zonen zu stecken. Open Stack bekommt so die Option, zwischen den Servern zu unterscheiden.

Gast und Hypervisor

Das Open-Stack-Projekt hält im Dokumentationsarchiv gute Anleitungen bereit, wie sich ein Windows-Image für die Nutzung in Open Stack aufbauen lässt [11]. Wer Windows-VMs auf KVM oder Hyper-V paravirtualisiert einsetzt, braucht sich um viele Probleme keine Gedanken mehr zu machen, denn die KVM-Entwickler und auch Microsoft haben hier die eigenen Hausaufgaben gemacht.

Es mag manchen Linuxer überraschen, doch Windows-Systeme finden nicht nur als Guest-VM in Open Stack einen Lebensraum. Auch als Hypervisor in Open Stack lässt sich Windows nutzen, und die Lorbeeren dafür gehen an Cloudbase In der Tat ist es in wenigen Mausklicks möglich, aus einem Hyper-V-System einen Knoten für Open Stack zu machen, und die Unterstützung für Storage (Cinder) sowie das per Software definierte Netzwerk (Neutron) ist schon enthalten. Dass das Unternehmen es nun noch auf sich nimmt, Open Vswitch in einer Version für Windows aufzulegen, ist eine tolle Nachricht für die F/OSS-Welt und auch für alle Leute, die Hyper-V-Systeme gern als Hypervisor in ihre Clouds mit hinein nehmen wollen. Bleibt zu hoffen, dass Cloudbase mit der Portierung gut vorankommt.

Testen leicht gemacht

Wer sich von den Möglichkeiten mit Windows in Open Stack ein eigenes Bild machen möchte, findet auf der Cloudbase-Website [7] sowohl alle benötigten Open-Stack-Komponenten wie auch ein fertiges Gast-Image, das die Möglichkeiten von Windows-Gästen in Open Stack zeigt. Ab Werk ist das Image eine Trial-Version, die sich allerdings durch die Eingabe einer Seriennummer in eine normale Version umwandelt.

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei Hastexo. Er beschäftigt sich dort intensiv mit den Themen Hochverfügbar und Cloud Computing und pflegt in seiner Freizeit den Linux-Cluster-Stack für Debian GNU/Linux.