Die Hyper-V- und Windows-Integration in OpenStack Cloudbase.it - die OpenStack-Implementierung für Microsoft

OpenStack entwickelt sich zur ganz großen Nummer im Cloud-Business und bestätigt nicht nur, dass das IaaS-Segment von Open-Source-Software dominiert wird, sondern bringt auch Microsoft unter Zugzwang. Da die Redmonder die Open-Source-Standards nicht offenkundig unterstützen können oder wollen, muss ein OpenStack-Engagement indirekt erfolgen, durch Cloudbase.it.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

Dass das italienische Unternehmen Cloudbase.it eine von Microsoft kontrollierte Strohfirma ist, wie es entsprechende Gerüchte innerhalb der OpenStack-Community verlauten, lässt sich momentan nicht klären. Klar ist aber, dass Cloudbase.it nahezu im Alleingang das OpenStack-Projekt um Technolgien und Software bereichert, die ohne massive Unterstüztung vom Microsoft kaum realisierbar gewesen wären. So könnte Microsoft sein Gesicht wahren und würde keine der alteingesessenen Open-Source-Firmen der OpenStack-Gemeinschaft gegen sich aufbringen.

Dabei betreiben die Redmonder schon seit einigen Jahren mit Nachdruck einen Image-Umbau in Bezug auf die eigene Position zu Open Source und trachten danach, langfristig als Company wahrgenommen zu werden, der Interoperabilität besonders am Herzen liegt. Dass der Sinneswandel hauptsächlich aus strategischen Erwägungen resultiert wird niemand ernsthaft in Frage stellen wollen, auch wenn man bei genauerem Hinsehen konstatieren muss, dass Microsoft in den vergangenen Jahren tatsächlich einen bemerkenswerten Öffnungsprozess vollzogen hat.

Dass Microsofts Strategiewechsel nicht ganz freiwillig erfolgt, lässt sich am besten beim Cloud-Computing festmachen, nicht irgendeinem Marktsegment, in dem auch Microsoft ein Wörtchen mitreden möchte, sondern möglicherweise dem Schlüsselmarkt im IT-Sektor für die nächsten Jahrzehnte. Hier kann und muss Microsoft ein Interesse daran haben, dass nicht nur Windows-Gäste möglichst reibungslos in einer Cloud- oder Virtualisierungs-Infrastruktur laufen, sondern nach Möglichkeit auch „Hyper-V“ einer der von OpenStack unterstützen Hypervisoren bleibt oder wird.

Eigentlich ist Linux fast schon ein Windows, oder?

Wenn man bedenkt, dass die Redmonder noch vor wenigen Jahren alles mit Vehemenz, sowie mit lauteren und unlauteren Mitteln, wie etwa fragwürdigen Studien, bekämpft hat, was nur entfernt nach Linux roch, ist es durchaus etwas Besonderes, dass der etwa der Microsoft-Entwickler K. Y. Srinivasan satte 343 Änderungen zum Linux-Kernel 3.0 beisteuerte und sich damit sogar vorübergehend an die Spitzen der Kernel-Commiter gesetzt hatte. Die von Microsoft beigesteuerten Treiber dienten allerdings dazu, den Linux-Kernel für den Einsatz als Gastsystem in Microsofts Virtualisierungsplattform Hyper-V zu optimieren.

Was OpenStack selbst angeht, gerät gerne Mal in Vergessenheit, dass die OpenStack-Entwickler die Unterstützung für Hyper-V Anfang letzten Jahres aus Ihrem Framework entfernten, weil der betreffende Code zu diesem Zeitpunkt zu lange nicht mehr gepflegt worden war. Un das geschah trotz der Ankündigung vom Dezember 2010, dass das Unternehmen Cloud.com gemeinsam mit Microsoft daran arbeiten würde, Openstack so anzupassen, dass der Windows Server 2008 R2 RS samt Hyper-V-Technologie auf dem Cloud-Framework liefe.

Zudem waren sich die Maintainer seinerzeit gar nicht sicher, ob der bis dato existierende Code mit der seinerzeit aktuellen OpenStack-Version „Essex“ überhaupt noch funktioniert hätte. Selbst wenn, hätten dem Hyper-V-Treiber im Vergleich zu den anderen von OpenStack unterstützten Hypervisoren „KVM“ und „Xen“ damals wichtige Funktionen gefehlt. Trotzdem äußerte sich der Rackspace Marketingchef Mark Collier im gleichen Monat in einem Interview zuversichtlich in puncto einer künftigen Vereinbarkeit von Hyper-V in Openstack.

Alle Windows-OpenStack-Tools schon da

Nun, was 2010 und 2012 hypothetisch war beziehungsweise in der Zukunft lag, ist heute schon wieder Vergangenheit oder Status Quo. Denn irgendwann zwischen der Aufkündigung der Hyper-V-Unterstützung in Essex und der erneut verfügbaren, qualitativ viel besseren Hyper-V-Unterstützung in „Folsom“ – ebenfalls im Jahr 2012 – war plötzlich das italienische Unternehme Cloudbase.it präsent, das sich offenbar exklusiv und alleine und die Hyper-V-Integration in OpenStack zu kümmern scheint.

Um beurteilen zu können, welche Ingenieur-Leistung, vor allem in Anbetracht der Kürze der Zeit seit dem Entfernen des Hype-V-Treibers aus Essex in den beschrieben Tools, Treibern und Komponenten von Cloudbase steckt, muss man sich vergegenwärtigen, worin eigentlich die grundsätzlichen Probleme einer Verheiratung von OpenStack mit Hyper-V beziehungsweise mit Windows-Gastsystemen in Virtualisierungs- und Cloud-Umgebungen liegen.

Da steckt Microsoft dahinter

Ob Microsoft überhaupt eine Strategie in Bezug auf OpenStack hat oder hatte spielt übrigens insofern zunächst gar keine Rolle, als dass es Betreiber und Nutzer von Open-Stack basierten Clouds gibt - bei Private Clouds in Personal-Union -,die Microsoft Betriebssysteme als virtuelle Gastsysteme einsetzen. Dabei zeigen sich gerade Microsoft-Systeme beim Einsatz als Gastsysteme in virtuellen Umgebungen, egal ob im virtuellem Rechenzentrum oder als Komponente in einer Cloud-Infrastruktur aus mehreren Gründen sperrig.

So ist abseits technischer Probleme schon die Lizenz-Situation bei Microsoft-Betriebssystemen in Virtualisierungs- und Cloud-Umgebungen problematisch. Bekanntlich braucht jede virtuelle Windows-Maschine einen Lizenzschlüssel, sonst funktioniert sie nicht. Die meisten Unternehmen nutzen aber heute Windows-Volumen-Lizenzen. Die greifen aber in Cloud-Umgebungen nicht, weil Microsoft von Cloud-Betreibern verlangt, für jede virtuelle Maschine eine eigene Lizenz zu erwerben.

Microsoft behindert damit ein einfaches Betreiben und Lizensieren von Windows-Gästen in Cloud-Umgebungen, wenn auch die dahinter stehenden Überlegungen etwa am Beispiel virtueller Desktops nachvollziehbar sind. Ein Cloud-basierter Desktop kann ja beispielsweise mobilen Benutzern über die Cloud das Verwenden von Windows-Anwendungen auf Geräten ohne Windows ermöglichen.

Der Umgang mit und die Lizenzierung von Thin Clients

Eine ähnliche Problematik besteht auch bei Thin-Clients. Die am nächsten liegende Lösung, ein „Mieten virtueller Desktops“ von einer Hosting-Unternehmen (Desktop as a Service) verbietet aber die Windows-Linzensierung. Im konkreten Fall können Unternehmen virtuelle Desktops entweder als einen gehostete Windows-Server-Desktop mieten oder Firmen beauftragen, einen Managed Service Provider (MSP) virtuelle PC-Desktops für sich zu hosten.

Dann lassen sich Windows-Server-Desktops via RDS (Remote Desktop Dienste) zur Verfügung stellen. Desktop-Sitzungen lassen sich nämlich vom Hosting-Anbieter, der über Microsofts Lizenzvereinbarung „Services Provider Licensing Agreement“ (SPLA) verfügt auf monatlicher Basis ans eine Kunden weitervermieten. Das greift aber tatsächlich nur für virtuelle Desktops, die dann pro Nutzer vermietet werden können.

Eine weitere Möglichkeit bestünde darin, einen Managed Service Provider (MSP) dafür zu bezahlen, dass dieser virtuelle Desktops ausführt. Hier stellt der Nutzer/Kunde dem MSP virtuelle Maschinen mit Windows zur Verfügung, die dieser auf seinen Servern hostet, allerdings muss dann jeder einzelne MSP-Server muss einen festen Kunden zugeordnet sein.

Dynamik in der Lizenzierung

Denn Cloud- und Virtualisierungsangebot sparen keineswegs Lizenzkosten. Auch MSPs müssen bei jedem RDP-Zugriff jedes Gerät, das virtuellen Maschinen nutzt, Windows –Lizenzen zahlen, egal ob via Windows mit Software Assurance (Microsofts Programm zur Upgrade-Berechtigung) oder über „Virtual Desktop Access“-Subskriptionen damit gearbeitet wird. Cloud-Szenarien, egal ob mit OpenStack oder mit anderen Lösungen, erfordern aber quasi dynamische Lizenzen.

Immerhin ist in OpenStack mit etwas Aufwand durchaus möglich, eine VM einen dynamischen Lizenzschlüssel mitzugeben. „Glance“, die für das Speichern von Images im OpenStack ObjectStore (Swift) zuständige OpenStack-Komponete würde das jeweilige Image dann als nacktes Image, quasi ohne Gedächtnis, ablegen.

Ein solches Windows-Image darf darüber hinaus in einer Cloud-Umgebung mit keinerlei Hardware-Infrmationen verknüpft sein, wie es für Windows-Images üblich ist. Denn in OpenStack oder einer anderen Cloud-Lösung kann niemand garantieren, dass sämtliche Hypvisor-Nodes auf der gleichen Hardware basieren. Dies wird sich sogar mit steigender Betriebsdauer des Cloud-Setups höchstwahrscheinlich ändern.

Die Rolle der Treiber

Ein weitere Problem im Zusammenhang sind die Treiber für den para-virtualisierten Betrieb. Kommt als HypervisorKVM zum Einsatz, ist das für Linux-Gäste unproblematisch, weil virtuelleTreiber inzwischen integrale Komponente aller Linux-Versionen sind. Sogar für Windows-Gäste ließen sich virtuelle Treiber theoretisch mit im Image pflegen, weil sowohl das KVM-Team, als auch „Fedora“ die entsprechenden Windows-Gast-KVM-Treiber pflegen, Fedora sogar in digital signierter Form.

Trotzdem dürfen auch diese Informationen in einen Cloud-Setup nicht Teil der VM-Images sei, weil neben KVM ja auch Xen als Hypervisor zum Einsatz komme kann und danke der Mitarbeit von Cloudbase auch Hyper-V. Zum Extrahieren all dieser Informatonen aus einer Windows-Installation, also Linzenz-Key, Hardwareverknüpfugen und spezifische Treiber stellt Microsoft ein Werkzeug mit der Bezeichnung Sysprep zur Verfügung. Dieses können OpenStack-Admins zum Erstellenn derart bereinigter Abbilder nutzen.

Heißt der in einem OpenStack-Szenario verwendete Hypervisor aber nicht KVM, sondern Hyper-V, was zum Beispiel dann Sinn macht, wenn es auf Applikationsseite spezifische Anforderungen an den vorzufindenen Windows-Stack gibt, stellt sich auch für OpenStack-Admin die Frage, ob und wie sich OpenStack und Hyper-V derzeit tatsächlich vertragen. Das wiederum lenkt den Blick auf die Angebote von Cloudbase.it.

Die Compute-Komponente

Die Italiener haben zum Beispiel die OpenStack-Compute-Komponente Nova in Eigenregie auf Windows mit Hyper-V lauffähig gemacht. Das war insofern problemlos möglich, als der Code von OpenStack reines Python ist, das auch unter Windows verfügbar ist.

So lässt sich Nova-Compute inzwischen nicht nur problemlos unter Windows nutzen, Cloudbase hat auch gleich den passenden Windows-Installer entwickelt, mit dem sich ein beliebiger mit Hyper-V ausgerüsteter Host (geht inzwischen ja sogar mit einer Windows-8-Maschine) als Compute-Knoten für Nova verwenden lässt.

Die Quantum-Komponente

Die Cloudbase-Etwickler haben daher kurzerhand ein eigenes Quantum-Plugin entwickelt, dass zumindest für einen funktionierenden Netwerk-Stack zwischen Quantum und Hyper-V sorgt, wenn auch KVM/Xen-Server-Linux-Server mit Open vSwitch und Hyper-V-Server damit nicht in der gleichen Quantum-Umgebung laufen. Laut Cloudbase-Founder und CEO Alessandro Pilotti arbeitet das Unternehmen derzeit aber bereits ab einer echten Portierung von Open vSwitch auf Windows.

Die letzte auf der Cloudbase-Webseite zu findende Anpassung für OpenStack trägt die Bezeichnung „Cloud-Init for Windows“. Das ist ein von Cloudbase für Windows angepasste Variante des normalerweise in OpenStack-Umgebungen eingesetzen Linux/Unix-Shell-Srkipts „cloud-init“. Das Skript wickelt praktisch das allererste Initialisieren einer Cloud-Instanz ab.

Dabei setzt das Skript unter anderem den Host-Namen der virtuellen Maschinen, sowie die Default-Werte fest und generiert die benötigten SSH-Private-Keys und fügt sie der Datei .ssh/authorized_keys des zugehörigen Benutzers an. Die Informationen bezieht das von Linux-Gästen beim Starten ausgeführte Skript vom Nova-Metadaten-Server.

Die Windows-Re-Implemention von Cloud-init „codbase-int“ bietet laut Cloudbase mittlerweile mehr Funktionen, als das Original.

Der Autor:

Thomas Drilling ist freier Fachautor und blogt auf DataCenter-Insider.de in „Drillings Open-Source-Eck“.

(ID:42302304)