Kendall Waters (OpenStack Founda

Interop Challenge: OpenStack auf dem Weg zur Workload-Portabilität

Die fehlende Workload-Portabilität gilt als großer Kritikpunkt von OpenStack. Mit der Interop Challenge will die Community das Gegenteil beweisen.

Wie jede Open-Source-Software profitiert auch OpenStack von der Offenheit, die das Cloud-Framework enorm flexibel und anpassbar macht. Gleichzeitig ist damit aber auch eine der größten Schwächen verbunden, weil es inzwischen so viele unterschiedliche Distributionen gibt, dass vor allem OpenStack-Einsteigern nur schwer ein Überblick über die Vor- und Nachteile der unterschiedlichen OpenStack-Produkte zu vermitteln ist.

An sich galt dabei von Anfang an der Grundsatz, dass sich alle OpenStack-Distributionen an ein einheitliches Set an Programmierschnittstellen (Application Programming Interface, API) halten sollten, um die Gefahr der Fragmentierung von Anfang an zu eliminieren. Aus diesem Grund gab es bereits sehr früh Projekte wie das DefCore Committee oder RefStack, mit denen die Einhaltung des gemeinsamen API-Sets sichergestellt werden sollte.

Spätestens seitdem OpenStack als stabil und skalierbar genug für Enterprise-Umgebungen gilt, also etwa seit OpenStack Kilo und OpenStack Liberty, und damit für viele Unternehmen ernsthaft in Frage kommt, wird aber genau diese Portabilität von OpenStack-Workloads über unterschiedliche Distributionen hinweg immer wieder bezweifelt.

Don Rippert, General Manager IBM Cloud Strategy, Business Development and Technology bei IBM, hatte daher auf dem OpenStack Summit in Austin im April 2016 die Interop Challenge ausgerufen, um ein für alle Mal zu beweisen, dass OpenStack die von Unternehmen geforderte Interoperabilität über Anbieter hinweg durchaus leisten kann. Anders als das DefCore Committee oder RefStack rücken damit beim Thema Interoperabilität jetzt OpenStack-Workloads selbst in den Fokus der Aufmerksamkeit.

Auf dem vergangenen OpenStack Summit in Barcelona vom 25. bis 27. Oktober 2016 wurde schließlich medienwirksam während der Keynote des zweiten Konferenztages der Beweis der Interoperabilität erbracht und ein Workload über mehrere OpenStack-Distributionen hinweg mit einem einheitlichen Tool-Set bereitgestellt.

Interop Challenge auf dem OpenStack Summit Barcelona

Insgesamt nahmen bis zum Barcelona-Summit 18 Unternehmen und Organisationen die Herausforderung an, darunter natürlich IBM, aber auch andere Schwergewichte der Branche wie Canonical, Cisco, die Deutsche Telekom, Fujitsu, Huawei, HPE, Mirantis, Rackspace, Red Hat, SUSE und auch VMware. Letzten Endes, so Don Rippert, gehe es bei der Interop Challenge darum, Unternehmen im Umgang mit OpenStack die Angst vor einem Vendor-Lock-in zu nehmen.

Dazu wurde am Beispiel von Wordpress eine Multi-Tier-Applikation mit Compute, Storage, Datenbank, Load-Balanced-Frontend und LAMP-Stack (Linux, Apache, MySQL, Python) auf 16 unterschiedlichen OpenStack-Distributionen bereitgestellt. Grundlage der so gezeigten Interoperabilität waren ein Heat-Template sowie das Orchestrierungs-Tool Ansible. Für die Portabilität müssen also zunächst spezielle Konfigurationsskripte geschrieben werden, die laut Jonathan Bryce, Executice Director der OpenStack Foundation, aber in Kürze für mehr und mehr Anwendungsfälle zur Verfügung gestellt werden sollen.

Abbildung 1: Live-Demo zur Interop Challenge auf dem OpenStack Summit Barcelona.

Für Rackspace-CTO John Engates ist das alles aber „kein Hexenwerk“, vielmehr handele es sich um sowieso sehr populäre Werkzeuge, wie sie heute in den meisten Cloud-Umgebungen bereits zum Einsatz kommen. Für ihn hatte die Demonstration dann auch eher exemplarischen Charakter und sollte lediglich zeigen, dass es durchaus möglich ist, komplexe Applikationen mit dem gleichen Tool-Set auf unterschiedlichen Distributionen bereitzustellen. In der täglichen Arbeit von OpenStack-Administratoren, so seine Einschätzung, wird die in der Keynote gezeigte Workload-Portabilität aber keine große Rolle spielen.

Xavier Poisson, Vice President EMEA Hybrid IT bei HPE, rät dann auch eher dazu, die Interop Challenge lediglich als Startpunkt zu begreifen, von dem aus weitere Bemühungen zur OpenStack-Interoperabilität ausgehen müssen. Immerhin zeige die Demonstration aber die Selbstverpflichtung der OpenStack-Community, die Kritik gemeinsam zu adressieren. „Der Code ist dabei nicht das Problem,“ so Xavier Poisson, „für Code-Probleme findet man immer eine Lösung. Viel entscheidender sind die operativen Prozesse. Wie wird OpenStack Enterprise-fähig? Wie werden operative Tätigkeiten einfacher?“

Die Interop Challenge adressiert dieses Problem, indem die auch bereits vorher innerhalb des API-Sets gegebene Workload-Portabilität jetzt über die einheitlichen Tools ein Stück einfacher möglich sei. In die gleiche Kerbe schlägt daher auch Anni Lai, Head of Global Business Development bei Huawei, indem sie den Sinn und Zweck der Live-Demo in der praktischen Demonstration dessen sieht, was theoretisch auch vorher schon möglich war: „Viele Unternehmen haben daran gezweifelt, dass die Portabilität von OpenStack-Workloads besteht und tatsächlich auch funktioniert. Mit der Interop Challenge ist jetzt der praktische Beweis erbracht.“

Wie Xavier Poisson gibt aber auch Anni Lai zu bedenken, dass die Ergebnisse der Interop Challenge nur der erste Schritt sein können. Mit jeder OpenStack-Version ändere sich schließlich das API-Set, zudem gibt es rund um eine OpenStack-Bereitstellung auch Hardware mit spezifischen Treibern, beispielsweise für Storage. Mit der Live-Demo, so also auch ihr Resümee, steht die Community gerade erst am Anfang der tatsächlichen Workload-Portabilität.

Interoperabilität auf App- statt Infrastrukturebene

Kritik an der Interop Challenge findet sich innerhalb der OpenStack-Community kaum, einzig Boris Renski, Mitgründer und CMO von Mirantis, gibt eine volle Breitseite ab: „Die Interop Challenge ist nicht mehr als ein Marketing-Gag. In Wirklichkeit interessieren sich Unternehmen nicht besonders für die Interoperabilität auf Infrastrukturebene, zusätzlich wird es dauerhaft nicht gelingen, 16 oder mehr OpenStack-Anbieter mit kommerziellen Eigeninteressen vereint am Ziel der App-Portabilität arbeiten zu lassen.“

Auch wenn aus der OpenStack-Community unisono das Mantra zu vernehmen ist, OpenStack habe als Plattform Vorrang vor kommerziellen Interessen, sollten sich Unternehmen also lieber nicht auf die dauerhafte Kooperation unterschiedlicher OpenStack-Anbieter verlassen. Auf der sicheren Seite seien Unternehmen nur, so Boris Renski, wenn sie die Workload-Portabilität auf einem höheren Level, also der Applikationsebene, selbst in die Hand nehmen. Dort gehört sie für ihn hin, und nicht auf die Ebene der Infrastruktur, wie dies die Interop Challenge versucht.

Eine weitere Möglichkeit wäre die Ebene von Management-Tools oder aber auch Containerplattformen, mit denen die Applikationen von der darunterliegenden Infrastruktur abstrahiert werden. Gerade Container werfen im Zusammenhang mit großen Enterprise-Applikationen aber noch mehr Fragen auf, als sie beantworten können, beispielsweise bei persistentem Storage für Stateless-Cloud-Apps.

Weitere Artikel zu OpenStack:

Azure Stack: Die OpenStack-Alternative, die keine mehr ist.

5 Tipps zur Planung einer erfolgreichen OpenStack-Cloud.

TestLab: OpenStack auf Ubuntu installieren.

Zukünftig könnten Container aber auch nach Meinung von Rackspace-CTO John Engates eine komfortable Lösung darstellen, um die Workload-Portabilität zwischen verschiedenen Cloud-Umgebungen sicherzustellen. Derzeit sei die Implementierung auf Anwendungs- oder Management-Ebene aber noch weitaus komplizierter, als auf der Infrastrukturebene mit so populären Tools wie Ansible und Heat. Zukünftig, so Jonathan Bryce, sollen zudem auch Puppet und Chef eingebunden werden.

Was bleibt also von der Interop Challenge, deren erfolgreichen Abschluss Don Rippert nach der Live-Demo verkündete? Einerseits die Gewissheit, dass die Workload-Portabilität zwischen OpenStack-Distributionen innerhalb gewisser Grenzen tatsächlich funktioniert. Und zwar, das bestätigte Jonathan Bryce auf Nachfrage, auch über unterschiedliche Versionen hinweg. So sollen im Rahmen der Live-Demonstration mit OpenStack Liberty, Mitaka und Newton drei unterschiedliche OpenStack-Releases beteiligt gewesen sein.

Andererseits aber auch die Frage, welche praktische Relevanz sich aus dem Beweis der Interoperabilität ergibt. Natürlich meiden Unternehmen den Vendor-Lock-in, wo immer es geht, gerade auch im Zusammenhang mit per Definition offenen Plattformen wie OpenStack.

Produktiv genutzte OpenStack-Umgebungen dürften aber in vielen Fällen so speziell angepasst sein, dass entsprechende Workloads sowieso (noch) nicht auf andere OpenStack-Distributionen migrierbar sind, oder aber kaum überhaupt ein anderer OpenStack-Anbieter ähnliche Funktionen bietet. Man denke beispielsweise nur an die OpenStack-Module Sahara und Manila, die von kommerziellen OpenStack-Anbietern höchst unterschiedlich unterstützt werden.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im Oktober 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Private-Cloud-Infrastruktur

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close