Deployment und Upgrades von OpenStack: So lässt sich die Komplexität reduzieren

Eines der größten Probleme von OpenStack ist die Komplexität bei Deployment und Upgrade. So begegnen Red Hat, Mirantis, SUSE und VMware dem Problem.

OpenStack gilt vielen als die Cloud-Infrastruktur der Zukunft schlechthin, um auf Basis herkömmlicher x86-Server...

eine hochskalierbare Private Cloud für moderne, zustandslose Cloud-Applikationen bereitzustellen. OpenStack ist dabei eine noch recht junge Technologie, deren erste finale Version Austin vor gerade einmal fünf Jahren im Oktober 2010 veröffentlicht wurde. Inzwischen hat sich ein sechsmonatiger Release-Zyklus etabliert, wodurch die OpenStack-Entwicklung inzwischen bei der zwölften Version (Liberty) angekommen ist.

Während Enterprise-Lösungen meist mehrjährige Abstände zwischen neuen Versionen aufweisen, müssen sich Unternehmen also bei OpenStack zwei Mal im Jahr die Frage stellen, ob die neuen Funktionen ein OpenStack-Upgrade rechtfertigen. Durch die enormen Entwicklungsfortschritte zwischen den einzelnen Versionen und die hohe Komplexität von OpenStack ist ein Upgrade auf eine neuere OpenStack-Version in Produktivumgebungen zudem quasi unmöglich, wodurch ein Upgrade bisher eher der Bereitstellung einer komplett neuen Cloud-Umgebung glich.

Deployment und Upgrade sind aufgrund der hohen Komplexität von OpenStack also die zwei zentralen Probleme, denen sich Nutzer des Cloud-Frameworks gegenübersehen. Um OpenStack auf dem weiteren Weg in Richtung Mainstream zum Erfolg zu verhelfen, arbeiten OpenStack-Anbieter wie VMware, Red Hat, SUSE und Mirantis mit Hochdruck daran, die Komplexität genau in diesen beiden Bereichen zu vereinfachen.

Deployment und Upgrades von OpenStack vereinfachen

Während man für ein Upgrade bis vor kurzem noch jeden Hypervisor einzeln anfassen musste, erledigen das mittlerweile spezielle Tools, in ähnlicher Weise sind auch etliche Werkzeuge zur einfacheren Bereitstellung erhältlich – bei denen aber jeder Anbieter einen eigenen Weg mit spezifischen Vor- und Nachteilen geht.

VMware: Der Platzhirsch beim Thema Server-Virtualisierung sieht sich gegenwärtig Druck von zwei Seiten ausgesetzt, einerseits durch konkurrierende Hypervisoren wie KVM und zunehmend auch Microsoft Hyper-V, andererseits durch Open-Source-Trends wie Docker und eben OpenStack, die ein ganz anderes Virtualisierungs-Konzept als die klassische Virtualisierung auf Basis virtueller Maschinen vorantreiben.

Getreu dem alten Motto „Halte deine Freunde nahe bei dir, aber deine Feinde noch näher“ reagiert VMware auf dieses absehbare Problem mit einer tiefen Integration von Docker und OpenStack in die eigenen Management-Tools. Auf Docker-Seite kommen hier die Photon-Plattform und Project Lightweight sowie Project Bonneville und AppCatalyst ins Spiel, VMware Integrated OpenStack (VIO) dagegen bietet VMware-Kunden eine eigene OpenStack-Distribution.

Für Dan Wendlandt, als Director Product Management for Cloud Native Infrastructure bei VMware auch für OpenStack zuständig und schon zu Nicira-Zeiten an den ersten OpenStack-Releases beteiligt, ist die enge Integration von OpenStack in VMware-Tools der Schlüssel zur Reduzierung der Komplexität. Mit VIO geht VMware laut Dan Wendlandt bewusst einen anderen Weg als viele andere OpenStack-Distributionen und bietet eine geringere Flexibilität und Funktionsvielfalt, dafür aber eine höhere Stabilität und eine garantierte und getestete Funktionalität.

Im Umgang mit VMware Integrated OpenStack müssen sich VMware-Admins also nicht mit neuen Tools und Hypervisoren oder Storage-Backends auseinandersetzen, sondern können gewohnte Technologien wie VMware NSX, vSphere Distributed Switch (vDS) und vSphere nutzen. Anders als der Großteil der OpenStack-Anbieter nutzt VMware für VIO keine Bare-Metal-Provisionierung zur Bereitstellung, sondern schlicht virtuelle Maschinen auf Basis von vSphere, was den Deployment-Prozess enorm vereinfache, immerhin, so Dan Wendlandt, sei die Bereitstellung virtueller Maschinen mit vSphere mittlerweile gängige Praxis vieler Tausend VMware-Admins.

Da sich OpenStack direkt in Management-Tools wie vCenter oder vRealize Operations integrieren lässt, verspricht Dan Wendlandt auch den „einfachsten Upgrade-Pfad der gesamten Industrie“. Dabei kommt allerdings kein klassisches In-Place-Upgrade zum Einsatz, bei dem eine bestehende Version auf eine neuere aktualisiert wird, sondern ein sogenanntes Blue-Green-Upgrade. Dabei wird neben der aktuellen Umgebung eine zweite auf Basis der neuen OpenStack-Version aufgebaut, erst wenn auch die neue Umgebung einwandfrei läuft erfolgt die Workload-Migration. Auf diese Weise kann man bei Problemen wieder zur alten Umgebung wechseln, während man bei In-Place-Upgrades das Risiko eingeht, direkt in der Produktionsumgebung Probleme zu verursachen.

Red Hat: Für seine RHEL OpenStack Platform (OSP) setzt Red Hat mit dem erst im August 2015 veröffentlichten RHEL OSP director den nicht unumstrittenen TripleO-Prozess ein. TripleO, oder OpenStack on OpenStack, nutzt zur Bereitstellung der eigentlichen OpenStack-Umgebung (die sogenannte Overcloud) eine kleinere, im Funktionsumfang abgespeckte OpenStack-Bereitstellung (die Undercloud). So weist die Undercloud beispielsweise keine High-Availability-Funktionauf, was deren Bereitstellung wesentlich vereinfacht. Die Undercloud dient dann als skalierbare Deployment- und Management-Schicht, mit der in der Overcloud Produktions- und Testumgebungen bereitgestellt werden können.

Alessandro Perilli, General Manager Cloud Management Strategy bei Red Hat, sieht gerade bei sehr großen OpenStack-Bereitstellungen einen klaren Vorteil von TripleO, da hier die Skalierbarkeit der Undercloud voll zum Tragen komme. Einfache Installer-Tools, die bei kleinen OpenStack-Deployments vielleicht noch gute Arbeit leisteten, kämen ab einer bestimmten Größe an deutliche Grenzen.

Kritiker von TripleO weisen in diesem Zusammenhang gerne auf die Problematik hin, mit TripleO eine Software zur eigenen Bereitstellung zu nutzen, die ja selbst bereits enorm komplex ist. Diese höhere Komplexität, so Dan Wendlandt von VMware, könne durch den geringen Mehrwert nicht gerechtfertigt werden. Im Gegensatz zum reinen Community-Projekt TripleO steht für RHEL OSP director allerdings eine grafische Benutzeroberfläche zur Verfügung, die die Bedienung erleichtert.

Letztlich, so Alessandro Perilli von Red Hat, könne man die Komplexität von OpenStack aber nicht leugnen, sondern lediglich durch geeignete Tools zu reduzieren versuchen. Red Hats Antwort auf die Komplexitätsprobleme von OpenStack besteht also in der Integration des RHEL OSP director in Red Hat CloudForms, um OpenStack über das director-Tool bereitzustellen und anschließend über CloudForms zu verwalten. Derzeit bietet RHEL OSP director keine Möglichkeit für In-Place-Upgrades von OpenStack, eine entsprechende Funktion soll allerdings in Kürze folgen.

SUSE: Die OpenStack-Distribution von SUSE hört auf den Namen SUSE OpenStack Cloud und setzt auf SUSE Linux Enterprise Server 12 (SLES) und SUSE Enterprise Storage auf. Zur Bereitstellung seiner OpenStack Cloud nutzt SUSE das ursprünglich von Dell ins Leben gerufene Open-Source-Projekt Crowbar, mit dem sich Gruppen physischer Bare-Metal-Nodes als Cluster in Produktionsumgebungen bereitstellen lassen.

Crowbar nutzt zum OpenStack-Deployment die Möglichkeiten des PXE-Boots (Prebot Execution Environment), über die die Server-Nodes wahlweise als Kontrollknoten, Administrationsserver oder auch Compute- oder Swift-Knoten bereitgestellt werden. Über Crowbar verspricht SUSE zudem Inplace-Rolling-Upgrades ohne Downtime der OpenStack-Umgebung.

Mirantis: Rajiv Sodhi, Managing Director EMEA bei Mirantis, sieht das größte Potenzial zur Reduzierung der OpenStack-Komplexität vor allem im Fachwissen der IT-Mitarbeiter. Damit lasse sich die Komplexität zwar nicht einfach auflösen, wohl aber beherrschen. Im Grunde geht aber auch Mirantis die Deployment- und Update-Problematik mit ähnlichen Ansätzen an wie Red Hat, VMware und SUSE, nämlich mit speziellen Tools, in diesem Fall mit den beiden Open-Source-Tools Fuel und Octane.

Fuel ist ein Community-Projekt, mit dem sich über eine grafische Benutzeroberfläche OpenStack bereitstellen und verwalten lässt. Von Haus aus unterstützt Fuel als Betriebssysteme Ubuntu und CentOS, allerdings kann das Tool um die Unterstützung weiterer Linux-Distributionen erweitert werden. Update-Prozesse automatisiert Mirantis dagegen über das Open-Source-Tools Octane, mit dem sich allerdings nur eingeschränkte OpenStack-Deployments upgraden lassen, beispielsweise wird als Betriebssystem lediglich Ubuntu unterstützt, als Hypervisor kann lediglich KVM zum Einsatz kommen. Zudem dürfen zum Zeitpunkt des Updates keine weiteren Services wie Sahara oder Murano installiert sein.

Wie bei allen IT-Prozessen verringert die Automatisierung das Fehlerrisiko, daher sind Installer- und Update-Tools für Rajiv Sodhi so wichtig, um gerade diese beiden fehleranfälligen Vorgänge möglichst weitgehend zu entschärfen. Kritik übt der frühere Red-Hat-Manager vor allem an anderen OpenStack-Anbietern, die Open-Source-Lösungen aufgreifen und dann als proprietäre Software verwenden. Mirantis verfolge demgegenüber einen anderen Ansatz, so Rajiv Sodhi, und gebe alle vorgenommenen Änderungen und Verbesserungen wieder vollständig an die Community zurück.   

Tipps für den OpenStack-Einstieg

Am Anfang jeder OpenStack-Initiative muss die Frage stehen, ob im eigenen Unternehmen genug Fachwissen im Umgang mit OpenStack vorhanden ist und wie sich dieses aufbauen lässt. OpenStack steht und fällt mehr als manch andere Technologie mit der fachlichen Expertise der Mitarbeiter.

In diesem Sinne ist es auch wichtig, die Organisationsstruktur einem prüfenden Blick zu unterziehen, da viele Unternehmen laut Rajiv Sodhi von Mirantis auf der Organisationsebene noch gar nicht bereit für OpenStack seien. Wenn dann kurzfristig zusätzlich zur Bereitstellung von OpenStack auch Unternehmensstrukturen verändert werden, führe dies oft zu einer starken Ablehnung, die sich später nur schwer wieder abmildern lässt.

Alessandro Perilli von Red Hat empfiehlt ganz generell eine Strategie der kleinen Schritte. Gerade bei der tatsächlichen Migration von Produktivsystemen auf die OpenStack-Umgebung kommt das größte Risiko zum Tragen, weil ein Scheitern an diesem Punkt das Ende des ganzen OpenStack-Projektes nach sich ziehen kann. Daher empfiehlt es sich, mit einer kleinen Applikationen mit begrenztem Funktionsumfang zu beginnen.

Die einzelnen Geschäftsbereiche müssen erst von der Private Cloud überzeugt werden, da deren Mitarbeiter ja meist in die vermeintlich unkompliziertere Public Cloud streben. Daher bedarf es für den Anfang einer Vorzeige-App, deren Migration unbedingt gelingen muss – der Erfolg dieser Anwendung sorgt dann laut Alessandro Perilli von alleine für die Akzeptanz von OpenStack auch bei anderen Abteilungen.

Für Kevin Smith, Technical Sales Director EMEA bei SUSE, seien es aber noch immer viel zu oft finanzielle Gründe, die Unternehmen den Schritt hin zu OpenStack gehen lassen. Die Support-Kosten nähmen viele Unternehmen dabei mit Blick auf die in Aussicht gestellten Einsparpotenziale in Kauf, die sich durch die hochskalierbare Infrastruktur erwarten. Dabei sei es viel wichtiger, die anvisierten Anwendungsfälle zu betrachten, und erst auf deren Analyse hin zu entscheiden, ob OpenStack bei den spezifischen Workloads überhaupt die gewünschten Vorteile bieten kann.

Fachwissen, Struktur und Side-Projects: OpenStack-Probleme gibt es genug

Es kann hier natürlich nicht um eine Analyse des gesamten OpenStack-Marktes gehen, vielmehr handelt es sich bei VMware, Red Hat, SUSE und Mirantis um zufällig ausgewählte OpenStack-Gesprächspartner auf der VMworld Europe 2015 in Barcelona. Die Beispiele zeigen aber, dass sich OpenStack-Anbieter durchaus der Deployment- und Update-Problematik bewusst sind und an unterschiedlichen Lösungen arbeiten.

Dabei gibt es mit dem großen Defizit an OpenStack-Spezialisten, der oftmals ungeeigneten Unternehmensstruktur und den ausufernden Side-Projects noch einige weitere Probleme, die die Komplexität im Umgang mit OpenStack eher noch vergrößern. Hat sich ein Unternehmen aber erst einmal für OpenStack entschieden, hängt die Wahl der richtigen Plattform schließlich von vielen verschiedenen Faktoren ab.

Für VMware spricht beispielsweise die hohe Integration in bekannte VMware-Tools, für Red Hat der durchgängige IT-Stack aus Betriebssystem (Red Hat Enterprise Linux, RHEL), Hypervisor (Red Hat Enterprise Virtualization, RHEV) und OpenStack-Distribution (RHEL OSP), für SUSE wiederum die horizontale Flexibilität durch die Partnerschaft mit Microsoft und SAP und für Mirantis zu guter Letzt die Offenheit in Richtung PaaS-Plattform (Platform as a Sevice). Wie sich gezeigt hat kann es aber gerade bei OpenStack nicht schaden, vor der Auswahl einer OpenStack-Plattform auch einen Blick auf die Deployment- und Update-Tools zu werfen.

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

Artikel wurde zuletzt im Oktober 2015 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Virtualisierung: Anbietervergleich

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