OpenStack-Automatisierung: Auch mit Heat und Graffiti noch nicht am Ziel

Eines der größten Probleme beim OpenStack-Deployment ist die fehlende Automatisierung. Trotz Heat und Graffiti ist die Industrie noch nicht am Ziel.

Viele Unternehmen wenden sich für ihre neue Private-Cloud-Plattform OpenStack zu. Während in den meisten Firmen...

aber nach wie vor Pilotprojekte vorherrschen, ist der Übergang hin zu einem großen, produktiven OpenStack-Deployment für die viele IT-Abteilungen ein enorm schwieriges Unterfangen. Zum Teil liegt dies an der schnellen Einführung von OpenStack. OpenStack ist enorm populär, aber was Training und Fachwissen betrifft, hinken viele Unternehmen den Anforderungen weit hinterher.

Zu all dem kommt erschwerend hinzu, dass OpenStack in gewisser Weise ein sich bewegendes Ziel ist, und zwar sowohl in seiner schnellen Weiterentwicklung als auch was konkurrierende Ökosysteme um OpenStack herum betrifft. In manchen Fällen kann es schwer sein, kommerziellen Support zu finden, die Open-Source-Plattform selbst ist für den durchschnittlichen IT-Mitarbeiter aber nur sehr schwer zu verwalten.

Eine Möglichkeit, um die Komplexität von OpenStack zu reduzieren, besteht in der Automatisierung, was sich Projekte wie Heat und Graffiti auf die Fahne geschrieben haben. Heat ist ein Orchestrierungs-Tool, dessen Template-Design kompatibel mit AWS CloudFormation Templates ist und die Integration mit der Public Cloud erleichtern soll. Heat bietet auch Möglichkeiten zur Autoskalierung, während Graffiti die Zusammenarbeit zwischen verschiedenen Ressourcenmetadaten verbessern soll.

Aber selbst diese beiden Tools vereinfachen die OpenStack-Bereitstellung nicht in ausreichendem Maße. Die meisten OpenStack-Installationen sind daher noch immer meilenweit davon entfernt, die für den Produktivbetrieb erforderlichen Verfügbarkeitslevel oder SLAs zu erfüllen. Es gibt viele Anbieter, die verschiedene Automatisierungs-Tools im Portfolio haben und damit zumindest einen Teil dieser Probleme lösen. Aber die enorme Anzahl möglicher Konfigurationsoptionen und die oft fehlende Interoperabilität der Tools machen den Scale-out-Prozess von OpenStack zu einem regelrechten Minenfeld.

Die Orchestrierung von Servern und virtuellen Instanzen ist ein elementarer Teil von Heat, aber Serverhersteller wie HP Enterprise, Dell oder auch IBM haben natürlich ein berechtigtes Eigeninteresse daran, in Sachen OpenStack eine führende Rolle einzunehmen und bieten eigene Integrations- und Support-Dienste, oft mit speziellen proprietären Eigenentwicklungen. Ein möglicher Nachteil des Ganzen ist dann natürlich die Gefahr eines Vendor-Lock-ins.

Ein anderer Anbieter im OpenStack-Bereich ist Red Hat. 2015 hat Red Hat das Automatisierungs-Tool Ansible aufgekauft, mit dem sich einfach zu nutzende Playbooks zur Konfiguration erstellen lassen. Red Hat ist zudem einer der Marktführer bei Ceph Storage, was letztlich auf die Inktank-Übernahme im Mai 2014 zurückgeht. Mit diesen Tools können Templates erstellt werden, um sich wiederholende Aufgaben zu automatisieren und so das Fehlerrisiko zu minimieren.

Die Rolle von SDN bei der OpenStack-Automatisierung

Ein wachsender Trend im Netzwerkbereich ist das Konzept von Software-defined Networking. Gerade in der Cloud kann das Management virtueller Netzwerke sehr schwer sein, da Performance, Sicherheit und Benutzererfahrung noch immer nicht mit physischen Netzwerken vergleichbar ist. Software-defined-Konzepte versuchen dies zu vereinfachen, indem Netzwerkdienste virtualisiert und Bare-Metal-Switches verwendet werden.

Immer mehr setzt sich dabei die Sichtweise von SDN als Policy- und Template-basierter Ansatz durch. Eine zentrale IT-Abteilung könnte so zum Beispiel Policies und Templates aufsetzen, während Endanwender darauf aufbauend ihre eigenen Arbeitskonfigurationen vornehmen. Dies würde Administratoren sehr viel Verwaltungsaufwand ersparen und so ein wesentlich schnelleres OpenStack-Deployment ermöglichen.

Mit Blick zurück auf das Jahr 2015 wird deutlich, welch weiten Weg die Industrie zurückgelegt hat, wenn es um OpenStack-Private-Clouds und um die Weiterentwicklung der OpenStack-Automatisierung geht. Wir sind sicherlich noch nicht am Ziel angekommen, aber viele der bisher manuell zu erledigenden Arbeiten können mittlerweile über Orchestrierung und Templates erledigt werden.

Mit Blick auf das neue Jahr 2016 lauten die größten neuen Herausforderungen, wie OpenStack mit bestehenden Public Clouds verbunden werden kann und wie die Integration mit bestehenden Systemen wie VMware aussehen kannoder auch gleich deren Austausch.

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

Artikel wurde zuletzt im Januar 2016 aktualisiert

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Private-Cloud-Infrastruktur

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close