Deutsche OpenStack Tage 2016

Vom 21. bis am 22. Juni fanden die diesjährigen Deutschen OpenStack-Tage in Köln statt. Auch Puzzle ITC war vertreten, um sich umzuhören, wie es mit OpenStack im Enterprise-Einsatz aussieht.

Vom POC in die Produktion

Es war erstaunlich, wie viele Leute OpenStack effektiv schon einsetzen und sich umfassend mit dem Thema IaaS auseinander gesetzt haben. Man würde erwarten, dass sich vor allem grössere Unternehmen für OpenStack interessieren würden, da es sich bekannterweise um keine leichte Kost handelt. Aber fehl am Platz: Auch kleinere Unternehmen haben den Mehrwert einer agilen IT erkannt und setzen auf OpenStack. Die Phase des Proof of Concepts ist für viele Unternehmen vorbei. OpenStack ist definitiv in der Produktion angekommen: Zum Beispiel bei der Metro Group. Die Metro Group ist Hauptgesellschaft von Rewe, Media Markt, Saturn und Cash+Carry und betreibt schon jetzt drei grössere Openstack Installationen. Auch VW und BMW setzten intern auf OpenStack.

Vanilla oder Distribution

Auch die namhaften OpenStack-Distributoren haben den Weg nach Köln gefunden, um dem interessierten Publikum ihre Lösungen zur vereinfachten Installation von OpenStack vorzustellen. Canonical warb mit den Tools MaaS (Metal as a Service) und Juju, um eine fixfertige OpenStack Installation bereitzustellen, welche dann auch nachträglich skaliert werden kann. Mirantis bietet ähnliches mit dem Fuel-Installer. SUSE setzt bei der SUSE Cloud auf das Tool ‚crowbar‘ und Red Hat hat sich dem OpenStack Direktor Triple0 (OpenStack On OpenStack) verschrieben.

Die verschiedenen Installer könnten nicht unterschiedlicher sein. Interessanterweise sind fast alle namhaften Configuration Management Tools „behind the scenes“ im Einsatz: Bei der SUSE Cloud kommen Chef und Saltstack, bei der Red Hat OpenStack Distribution und Mirantis OpenStack Puppet und bei Canonical kommen mit den Juju Charms meistens einfache Skripte zum Einsatz.

Es stellt sich die Frage, ob man einen solchen Installer benutzen soll, oder ob man doch lieber das Upstream-OpenStack verwendet und die Services selbst konfiguriert. Ohne Frage kommt man mit einem Installer zuerst schneller ans Ziel. Eine initiale OpenStack-Umgebung ist mit allen Lösungen schnell deployed. Sobald man jedoch an den Enden und Ecken schrauben will, wird’s schwierig, da man nicht drumherum kommt, alle eingesetzten Technologien selbst zu verstehen. Wer will schon eine Technologie betrieben, die er nicht versteht? Bei dieser Frage spalten sich die Geister, da sie auch stark von den Möglichkeiten der jeweiligen Anwender abhängt. Nicht alle IT-Departements haben genügend Ressourcen, um sich in das Thema OpenStack einzuarbeiten. Da kann eine Distribution Abhilfe schaffen, jedoch sollte man dann die OpenStack-Installation als Blackbox betreiben und darauf verzichten, selbst daran herumzuschrauben. Klar, man verliert damit Flexibilität, das ist jedoch der Preis den man zahlen muss.

Bimodal – Zuhause in zwei Welten

Der Begriff bimodal wurde oft gebraucht und es wurde davor gewarnt, alte monolithische Applikationen auf OpenStack betreiben zu wollen. Der Tenor war allgemein so, dass man im Sinne von bimodal die alte IT stehen lassen soll, und alle bestehenden alten Applikationen wie bisher betreiben soll. Zusätzlich solle man eine IaaS aufbauen, auf welcher Applikationen betrieben werden sollen, welche dafür designt wurden, also Cloud-Ready sind. Eigentlich ist es bei einer Cloud so, dass eine virtuelle Maschine jederzeit ausfallen kann, ohne dass sich dadurch die Erreichbarkeit des entsprechenden Services beeinträchtigt. Dies geht nur, in dem eine einzelne VM stateless ist. Viele ältere Applikationen sind jedoch nicht so konzipiert.

Oft wurde auch das Beispiel von „Pets“ und „Cattle“ herangezogen. In der alten IT muss man einer VM viel Aufmerksamkeit widmen: Einen eigenen, speziellen Namen, manuelle Installationen, viel Handarbeit. Im Gegensatz dazu wird bei den „Cattle“ eher eine Massen-VM-Haltung praktiziert: Eine einzelne VM ist nichts spezielles, hat keinen speziellen Namen, wird in Sekundenschnelle vollautomatisch provisioniert. Und es ist auch keine Tragödie, falls die VM verloren geht: Sie speichert selbst keine Daten.

Thore Bahr von SUSE demonstrierte in seinem Vortrag eine elegante Lösung, um auch auf OpenStack legacy Applikationen zu betreiben: Mittels Pacemaker-Remote
können einzelne Compute-Nodes überwacht werden. Falls ein Compute-Node nicht mehr verfügbar sein sollte, dann werden mit „nova evacuate“ die entsprechenden
virtuellen Maschinen auf einem der verbleibenden Computes-Nodes neu gestartet.

Pacemaker-Remote [1, 2, 3] erlaubt es, neue Nodes in den Controller-Cluster zu integrieren, welche keinen vollständigen Cluster-Stack installiert haben. Jedoch zählt die Stimme solcher Nodes nicht für das Quorum.

Meiner Meinung nach ist dies ein interessanter Ansatz, beide Welten zu kombinieren. Falls man selbst eine IaaS betreibt, dann wird das Ganze noch einfacher: Man kann selbst entscheiden, wann man einen Compute-Node updaten oder herunterfahren will, und kann dann zuerst alle VMs mittels nova migrate auf einen anderen Compute-Node verschieben. Die HA-Compute-Nodes können in OpenStack schön mittels einer eigenen Availability-Zone verfügbar gemacht werden. Beim Starten einer VM kann man dann selektieren, ob man eine „beinahe hochverfügbare“ VM möchte oder nicht.

[1] http://blog.clusterlabs.org/blog/2015/openstack-ha-compute

[2] http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Remote/

[3] https://access.redhat.com/articles/1544823

Kommentare sind geschlossen.