OpenStack

Die Private Cloud bleibt ein aufwändiges Unterfangen

13.11.2017
Von 
Björn Böttcher ist Senior Analyst und Data Practice Lead bei Crisp Research mit dem Fokus auf Analytics, BI, datenbasierte Geschäftsmodelle und Künstliche Intelligenz. Mit mehr als 10 Jahren Berufserfahrung in der IT und einem wissenschaftlichen Hintergrund und Fokus stehen moderne Lösungen mit praktischem Nutzen im Fokus seiner Betrachtung.
Keine Open-Source-Cloud-Infrastruktur-Software erregt so viel Aufmerksamkeit wie OpenStack. Dennoch bleiben Private-Cloud-Vorhaben meist komplex und aufwändig.

Die Popularität von OpenStack liegt einerseits an finanzstarken und engagierten Sponsoren und Entwicklern, andererseits an den Möglichkeiten, die die Plattform bietet. Auf Basis der Technologie lassen sich die immer mehr geforderten Hybrid- und Multi-Cloud-Ansätze in den IT-Strategien der Unternehmen abbilden. Dieses Unterfangen ist jedoch immer auch mit einer großen Expertise und personellem Aufwand verbunden. Kerntreiber für die Nutzung und Implementierung einer eigenen OpenStack-basierten Cloud-Infrastruktur ist neben der Nutzung unterschiedlicher Cloud-Modelle immer noch der Wunsch nach Offenheit und Kontrolle.

OpenStack ist in der neuen Version einfacher und flexibler geworden. Dennoch bleibt es aufwändig und ressourcenintensiv, eine eigene Private Cloud-Infrastruktur zu betreiben.
OpenStack ist in der neuen Version einfacher und flexibler geworden. Dennoch bleibt es aufwändig und ressourcenintensiv, eine eigene Private Cloud-Infrastruktur zu betreiben.
Foto: Raywoo - shutterstock.com

Flexibilität und Offenheit sprechen für OpenStack

Die Erfahrungen der letzten Jahre im Cloud-Betrieb haben zur Verbesserung der Infrastruktur beigetragen. In die aktuelle OpenStack-Version sind daher auch viele Tools und Möglichkeiten eingezogen, um Administratoren und Nutzern das Leben zu erleichtern. Ein Beispiel hierfür sind die Erweiterungen der Nova-Zellen. Die Idee hinter den Zellen ist es, die Skalierung und Flexibilität zu erhöhen und die Fehleranfälligkeit des Gesamtsystems zu minimieren. Weiterhin lassen sich so auch die Compute-Dienste näher zu den Daten bringen, um die Effizienz und Performance zu steigern und die Latenz zu minimieren. Innerhalb einer Federation kann man dann die gesamte Landschaft via API als eine Cloud für den Nutzer abbilden. Ebenfalls lassen sich über diesen Ansatz geteilte und private Zellen einrichten, um bestimmten Anforderungen oder Regularien nachzukommen. Die Zellen werden dazu in einer Baumstruktur organisiert und entsprechend verteilt eingesetzt. Auf der obersten Ebene befindet sich der API-Dienst, der Anfragen entgegennimmt und weiterverteilt. In den Kinderzellen laufen dann die eigentlichen Compute-Dienste. Diese Architektur hat den Vorteil, dass man unterschiedliche Zellen für bestimmte Dienste einrichten kann und bei einem Ausfall oder einem Angriff die einzelnen Zellen vom Rest der Infrastruktur trennen kann. Mit der neuen Version der Zellen-Architektur sind nun viele Probleme gelöst worden.

Die bekanntesten Beispiele für die intensive Nutzung von Multi-Zellen Implementierung sind das CERN und Rackspace. Beide haben tausende von virtuellen Maschinen über geographisch unterschiedlichen Regionen in Zellstrukturen organisiert.
Die bekanntesten Beispiele für die intensive Nutzung von Multi-Zellen Implementierung sind das CERN und Rackspace. Beide haben tausende von virtuellen Maschinen über geographisch unterschiedlichen Regionen in Zellstrukturen organisiert.
Foto: OpenStack

Cloud Native Computing Foundation beeinflusst OpenStack

Trotz vieler Entwickler, Bemühungen und auch dem Potenzial hat die OpenStack Community es nicht gewagt, sich über die Eigenschaften einer Infrastrukturplattform hinaus zu entwickeln. Der Glanz eines vollständigen und offenen Cloud-Stacks lugt zwar hier und dort immer mal wieder durch, dennoch fokussiert sich die Gemeinschaft auf die Verstärkung durch andere Open Source Communities und Technologiepartner. Die schnelle und einflussreiche Entwicklung derCloud Native Computing Foundation(CNCF) und die Förderung der einzelnen Projekte innerhalb des Ökosystems haben so wohl auch zu dem Einzug von etcd in die Plattform gesorgt. Etcd bietet als Key-Value-Store eine Vielzahl von Einsatzmöglichkeiten. So können Entwickler es nutzen, um beispielsweise Service Discovery, Scheduling, Load Balancing und auch verteilte Locks zu implementieren. Genau für den letzten Einsatzzweck kommt nun auch etcd bei OpenStack zum Einsatz. Die Version drei ist in der ersten Integrationsstufe nun bereits enthalten. Ebenso gab es ein Update bei Python hin zur Version 3.5. Denn die bisherige Version wird demnächst nicht mehr weiter gepflegt werden. Dass OpenStack sich gerade in Hinblick auf die eigene Weiterentwicklung an der CNCF orientiert, ist sicherlich ein guter und richtiger Schritt, denn viele Unternehmen orientieren sich aktuell bei der Ausgestaltung der eigenen IT-Strategie ebenso an den Projekten. Die Unterstützung rund um Kubernetes und Container für die OpenStack-Plattform war somit ein wichtiger Schritt, aber zum Glück nicht das Ende der Reise.

Die eigene Private Cloud bleibt ein aufwändiges Projekt

OpenStack ist zwar in der neuen Version einfacher und wesentlich flexibler geworden, dennoch bleibt es aufwändig und ressourcenintensiv eine eigene Private Cloud-Infrastruktur zu betreiben. Wer als Entscheider dennoch einen guten Plan im digitalen Transformationsprozess für die Notwendigkeit einer eigenen flexiblen Infrastruktur hat und ebenfalls die Ressourcen mit dem entsprechenden Know-how zur Verfügung stellen kann, der kann weiterhin sehr gut auf OpenStack bauen und die Hybrid-Cloud Szenarien entsprechend abbilden. Für Unternehmen, die weniger stark auf die eigene Kompetenz setzen oder lieber bei einem proprietären Stack bleiben, lohnt sich vielleicht eher ein Blick auf Angebote von Microsoft oder Oracle. Hier bekommt man zwar aktuell noch wesentlich weniger als bei einer OpenStack-Installation, aber dennoch zumindest einige Cloud Features im eigenen Rechenzentrum ohne viel Eigenleistung.