© maridav, 123RF

Ende Januar 2014 hat das Cloud-Stack-Projekt Version 4.3 seiner Cloudumgebung veröffentlicht. Die wartet mit vielen nützlichen Features wie Hyper-V-Support und schicken HA-Funktionen auf und zeigt, warum Open Stack nicht ewig an der Spitze stehen muss.

Open Source, Cloud und Managementsoftware – das Thema scheint, so erklären die Strategen diverser IT-Konzerne, derzeit komplett Open Stack, dem “Linux of the Cloud” zu gehören. Noch vor zwei, drei Jahren wäre den meisten Admins dafür eher Eucalyptus eingefallen. In dem schnelllebigen Markt konnte das von einer Stiftung und massivem Firmenengagement getriebene Open Stack [1] einen rasanten Aufstieg hinlegen, der es seinen Konkurrenten schwer macht, selbst kleine Häppchen des öffentlichen Interesses zu ergattern.

Zu Unrecht, beteuern deren Entwickler und verweisen, wie im Falle von Cloud Stack [2], auf Features, die der Platzhirsch Open Stack nicht anbietet. Tatsächlich hat es die Version 4.3 vom Januar 2014 durchaus in sich: Sie erlaubt es beispielsweise, Hyper-V als Computing-Knoten innerhalb einer Cloud-Stack-Umgebung zu betreiben.

Diese Kompatibilität zu Microsofts Virtualisierung macht zweifellos das Feature mit der größten Breitenwirkung aus. Zwar hat Hyper-V in der Branche lange nicht eine so hohe Bedeutung, wie man es sich in Redmond wohl wünscht. Fakt ist aber trotzdem, dass gerade Public-Cloud-Anbieter um den Virtualisierer auf Windows-Basis kaum herumkommen.

V wie Vendor-Lock-in

Der Grund dafür wirkt fast schon banal: Die Hersteller vieler kommerzieller Produkte schreiben in ihren Lizenzbedingungen für Programme fest, dass diese zwar in VMs betrieben werden dürfen, dass diese VMs aber auf einem Windows-Stack fußen müssen. Im Klartext heißt das, dass sowohl als Betriebssystem auf dem Blech wie auch die eigentliche VM mit Windows zu betreiben sind. Kommt der Kunde der Bedingung nicht nach, verweigert der Hersteller im schlimmsten Fall die Unterstützung.

Auch regelmäßig von Amazon veröffentlichte Statistiken zu EC2 zeigen klar, dass Windows-VMs dann Ubuntu & Co. unterliegen, wenn es um die bloße Anzahl gestarteter VMs geht. Ohne das Patronat einiger Softwarehersteller sähe es für Microsoft im Cloudkontext vermutlich noch dunkler aus. So aber hat das Unternehmen zumindest ein Fundament, auf dem es seine Cloudaktivitäten in Zukunft aufbauen kann.

Technisch macht Cloud Stack durchaus etwas her: Unterstützt wird im Augenblick zwar nur Hyper-V 2012, das sich in Windows Server 2012 oder in Hyper-V Server 2012 findet. Auch in Windows 8 kann Hyper-V seine Arbeit erledigen. Der typische Einsatzzweck dürfte aber der Hyper-V Server sein, den Microsoft in der Version 2012R2 sogar kostenlos an den Mann oder die Frau bringt [3].

Ein Hyper-V-Host integriert sich nahtlos in Cloud Stack 4.3: Das Agent-Modell, das bereits für die anderen Hypervisoren zum Einsatz kommt, funktioniert auch beim Hyper-V-Ansatz ähnlich. Grundidee ist, dass eine Cloud-Stack-spezifische Anwendung, der so genannte Agent, auf dem Hypervisor läuft und dort vom Cloud-Stack-Server Befehle entgegennimmt, die er anschließend lokal auf dem Hypervisor umsetzt.

Doch beschränken sich die Cloud-Stack-Entwickler bei ihrer Umsetzung von Hyper-V-Unterstützung nicht auf das Computing per se; sie haben auch dafür gesorgt, dass sich virtuelle Maschinen im Gespann mit persistenten Volumes nach SMB-Standard betreiben lassen, die Cloud Stack selbst wiederum exportiert. In seinem Tech Center erklärt Microsoft [4], in welchen Situationen das echte Vorteile bringen soll.

Zum Beispiel lassen sich solche auf SMB-Storages liegenden VMs deutlich leichter von einer virtuellen VM zur nächsten übertragen. Vorteilhaft ist auch, dass sich aus Cloud Stack heraus gestartete VMs über das entsprechende Windows-GUI verwalten lassen. Insgesamt wirkt die Umsetzung von Hyper-V in Cloud Stack sehr gelungen und wie aus einem Guss.

SDN von Juniper

Auch den Hype ums Software Defined Networking (SDN, [5]) haben die Entwickler bedacht. Im Grunde geht es bei SDN um die Entkopplung von Netz und Hardware: Wo Administratoren die Topologie ihres Netzwerks klassischerweise über die Konfiguration von Switches bestimmten (zum Beispiel mit VLANs), verwalten und steuern bei SDN Virtualisierungsumgebungen auch die Netzwerktopologie selbst. Der Cloudcontroller wird auch zum Netzwerk-Controller, Switches sind zu bloßem Metall degradiert und nehmen selbst keine Kontrollaufgaben mehr wahr.

Contrail und Open Contrail

Die wohl bekannteste SDN-Implementation am Markt ist Open Flow, das im Normalfall im Gespann mit Open V-Switch daherkommt. Allerdings gibt es in zunehmendem Maße auch SDN-Lösungen der etablierten Netzwerkhersteller wie Cisco, Brocade und Juniper. Letzterer hat Contrail Ende 2012 gekauft und sich damit eine vollständige SDN-Lösung ins Haus geholt; in Cloud Stack 4.3 haben die Entwickler der offenen Cloudlösung ihr Produkt um Support für das quelloffene Open Contrail erweitert [6].

Man darf gespannt sein, inwiefern Contrail im FLOSS-Bereich an Relevanz gewinnen wird. Schon kurz nachdem Juniper Contrail akquiriert hatte, kursierten Gerüchte, die Käuferin habe lediglich “irgendwas” im SDN-Bereich machen wollen, ohne einen konkreten Plan zu haben. Wer Contrail nutzt oder nutzen möchte kann das in Zukunft jedenfalls mit Cloud Stack 4.3 unkompliziert tun.

Abbildung 1: Cloud Stack arbeitet mit einer ganzen Reihe verschiedener SDN-Lösungen zusammen. In Version 4.3 kommt Junipers Contrail hinzu.

Zwar ist die Qualität der Implementierung laut Aussage der Entwickler noch nicht ganz vergleichbar mit den anderen SDN-Suites, die Cloud Stack unterstützt. Das stimmt aber vor allem deshalb, weil nicht die komplette Funktionalität der Cloud-Stack-Netzwerkkomponente VPC im Contrail-Plugin abgebildet ist. Doch versprechen die Entwickler, eben jenen Missstand in der nächsten Cloud-Stack-Version zu beheben.

Firewall as a Service

Ebenfalls ein großes Thema in Sachen Cloud Computing ist die Sicherheit. Im Fahrwasser des Software Defined Networking gewannen in den letzten Monaten auch einige Firewall-Applikationen massiv an Popularität – dazu gehören beispielsweise die Produkte von Palo Alto Networks, die im Wesentlichen Firewallfunktionen in Form von Appliances verkaufen (Abbildung 2, [7]). In Cloud Stack 4.3 haben die Entwickler die externen Tools von Palo Alto Networks mit der eigenen SDN-Implementierung integriert.

Abbildung 2: Cloud Stack integriert externe Firewalls wie die von Palo Alto.

Admins konfigurieren so die Firewall aus Cloud Stack heraus per Webinterface. Der Cloud- und SDN-Manager sorgt dafür, dass die Pakete auf ihrem Weg durch das virtuelle Netz die Firewalls wie gewünscht passieren. Bemerkenswert: Das Design von Cloud Stack erlaubt es auch, Dienstleistungen wie “Firewall as a Service” schnell und unkompliziert anzubieten (Abbildung 3).

Abbildung 3: Ist eine Firewall in Cloud Stack konfiguriert, lässt sie sich per Mausklick hinzuschalten.

Cloud Stack beherrscht ein Load-Balancer-as-a-Service-Feature (LBaaS), das Kunden die Möglichkeit bietet, innerhalb der Cloud Load Balancer zu betreiben. Eine solche Herangehensweise hat sich bei fast allen Cloudsuiten herausgebildet. Technischer Kerngedanke ist, dass sich direkt aus der Cloudumgebung heraus ein Load Balancer wie HA Proxy [8] vom Kunden starten lässt, der dann direkt auf echtem Blech läuft.

Gegenüber der Variante, bei der ein Kunde sich eine eigene VM installiert, um darin einen Balancer zu starten, bietet das gewichtige Vorteile: Zunächst verbrät der Kunde nicht unnötig Computing-Power, die er folglich auch nicht bezahlen muss. Außerdem lässt sich ein von der Cloud gesteuerter Load Balancer auch über das schon vorhandene Userinterface der Cloud steuern; im besten Fall klickt sich der Kunde die gewünschte Balancer-Konfiguration also dort zusammen, wo er auch den Rest seiner Cloud verwaltet.

LBaaS: Load Balancer as a Service

Das so implementierte LBaaS unterstützt übrigens nicht nur den Betrieb von Software-Load-Balancern, sondern kann auch proprietäre Balancer-Appliances steuern. Cloud Stack bietet LBaaS bereits seit einiger Zeit an. In der Version 4.3 haben die Entwickler das Feature aufgebohrt, denn ab sofort können Kunden ihren LBaaS-Dienst auch nutzen, um SSL-Verbindungen bereits auf dem Load Balancer zu terminieren.

Das ist einerseits dann praktisch, wenn der genutzte Dienst selbst kein SSL beherrscht; vorrangig dürfte aber von Bedeutung sein, dass Nutzer per LBaaS ihre SSL-Konfiguration direkt in der Steuerzentrale von Cloud Stack durchführen können. Per Mausklick lässt sich auf diese Weise ein SSL-Zertifikat für ein Setup mit vielen Target-Knoten ausrollen. Vorerst funktioniert das Feature allerdings nur dann, wenn eine Load-Balancer-Appliance zum Einsatz kommt, die das SSL-Termination-Feature selbst beherrscht. Der einzige OSS-Balancer, der SSL-Termination derzeit unterstützt, ist HA Proxy, allerdings ist die Funktion nur im Beta-Zweig der Software enthalten.

Hochverfügbares DBaaS

Cloud Stack brilliert seit langer Zeit mit seinem inhärenten Support für Hochverfügbarkei. Dass man auf dem Gebiet anderen Projekten schon immer weit voraus war, ficht die Entwickler nicht an, die Suite weiter zu verbessern: Version 4.3 spendierten sie HA-Features für das Database-as-a-Service-Plugin.

DBaaS ist in Cloud Stack schon länger vorhanden und auf Basis von MySQL implementiert. Ganz ähnlich wie LBaaS erlaubt es einem Nutzer, in der Cloud Datenbanken direkt per Self-Service-Portal zu starten anstatt eigene VMs mit händisch gebauten Datenbanken für diesen Zweck aus dem Boden stampfen zu müssen. Bis jetzt fehlte der Funktion allerdings die ausfallsichere Redundanz. Fiel eine DB aus, war der Dienst nicht erreichbar.

Cloud Stack 4.3 löst dieses Problem, indem es auf das MySQL-Active-Feature setzt (also auf eingebaute Replikation). Eine entsprechend konfigurierte HA-DB existiert in Zukunft also praktisch zweimal mit replizierten Datensätzen. Dem vorgeschaltet ist ein Load Balancer, der Clients auf eine der beiden Datenbanken umleitet. Dank der HA-Funktionalität wirkt DBaaS in Cloud Stack 4.3 deutlich attraktiver für Enterprise-Kunden.

Monitoring für Router

Nicht so “enterprisig” war jedoch, wie vor 4.3 die Virtual Router funktionierten. Virtuelle Router sind im SDN-Kontext wichtige Komponenten. Sie verbinden private, nicht nach außen geroutete Kundennetze per NAT mit dem Internet. Technisch umgesetzt haben die Entwickler dies in Form virtueller Maschinen, die einfach die passenden Routingdienste nutzen. Bisher war Cloud Stack aber nicht in der Lage, auf den Ausfall des Dienstes eines Virtual Routers überhaupt zu reagieren; stürzte zum Beispiel der Load Balancer ab, der den externen Zugriff auf die Webserver eines Kunden ermöglichte, ließ das Cloud Stack völlig kalt und der Kunde schaute in die Röhre.

Das Problem lag noch tiefer, als es zunächst den Anschein hatte: Cloud Stack hat bisher gar nicht gemerkt, wenn ein Dienst eines Virtual Routers ausfiel. In Version 4.3 ist das anders: Die virtuellen Router lassen sich ab sofort nämlich über das Cloud-Stack-interne Monitoring überwachen, das bei Bedarf Alarm schlägt und den Admin informiert.

Fazit

Cloud Stack 4.3 ist zwar nur eine Minor Release, die aber mit vielen praktischen Features aufzuwarten weiß. An erster Stelle steht dabei zweifelsfrei der Hyper-V-Support. Auch wenn die Entwickler für ihr Hyper-V-Feature noch (oder schon) Ausbaupläne haben, zeigt sich die Funktion bereits jetzt erfreulich umfangreich. Dank des Hyper-V-Supports steigt Cloud Stack damit in die Riege der universalen Clouds auf, die mit fast jedem Betriebssystem auf der Gast- oder der Host-Seite kooperieren.

Die Unterstützung für Hyper-V ist aber keineswegs die einzige Neuerung in Cloud Stack 4.3, die Beachtung verdient hat. Die vielen Verbesserungen – längst nicht alle Neuerungen von Cloud Stack 4.3, die im Changelog des Projekts [9] beschrieben sind, konnten Eingang in diesen Artikel finden – lassen die Software insgesamt deutlich attraktiver erscheinen. Es empfiehlt sich insofern nicht nur als fast zwingend, eine bestehende Cloud-Stack-Cloud auf die neue Version zu aktualisieren, unter Umständen lohnt sich der Blick auf die Alternative zu den Marktführern auch für Cloud-Stack-Neulinge.