9 Die Unternehmensreife von OpenStack fand auf dem OpenStack Summit in Vancouver Anfang dieses Sommers große Beachtung. Das ist besonders interessant, weil es zeigt, dass OpenStack einen gewissen Reifegrad erreicht hat. Aber bedeutet das auch, dass IT-Abteilungen in Unternehmen über die nötigen Tools verfügen, um OpenStack zu betreiben und eine Installation zu pflegen? Lassen sich Legacy-Unternehmensanwendungen in die Private Cloud verlagern? Ein wesentlicher Unterschied zwischen einer Cloud-Anwendung und einer klassischen Unternehmensanwendung besteht darin, dass Erstere mit Blick auf die dynamische Natur der Cloud entwickelt wurde. Sie weiß stets, welche Ressourcen hinzukommen oder wegfallen, und versucht nicht, mit einem Dienst zu interagieren, der nicht mehr vorhanden ist. Bei einer typischen Unternehmensanwendung ist das anders: Die Konfiguration ist oft statisch und hängt von hochverfügbaren (HA) Diensten ab, die sich nicht verändern. Die Zuverlässigkeit der zugrunde liegenden Cloud-Infrastruktur ist daher ein Eckpfeiler für HA-Konfigurationen. Hochverfügbarkeit in der gesamten Cloud Auf dem Summit hieß es, dass es durchaus möglich ist, eine resiliente OpenStack-Cloud zu betreiben, aber nicht einfach. Es gibt keinen einfachen Weg, OpenStack hochverfügbar zu konfigurieren. Beim Aufbau eines solchen Systems sind viele Entscheidungen zu treffen, angefangen bei der Hardware bis hinauf im Stack zur Konfiguration von OpenStack selbst. Hochverfügbarkeit in OpenStack (auf Englisch) ist eigentlich zweigeteilt: auf der einen Seite die Mandantenebene mit Netzwerk, Speicher, Rechenleistung usw., auf der anderen die OpenStack-Steuerungsebene, über die alle Cloud-Ressourcen gesteuert werden. In den letzten Releases hat sich in diesem Bereich viel getan, und ein Großteil der nötigen Funktionen für eine hochverfügbare Konfiguration auf beiden Seiten ist inzwischen vorhanden. Eine der wichtigsten Neuerungen betrifft meiner Meinung nach das Netzwerk, wo der virtuelle Routing-Dienst verbessert wurde. In älteren Releases war es schwierig, mit dem Ausfall eines Neutron-Netzwerkknotens umzugehen, der zu Ausfallzeiten der von ihm gesteuerten virtuellen Router führte. Dadurch wurden die von ihm bedienten virtuellen Maschinen isoliert – ein Single Point of Failure bis zum Release Juno, das das Problem mithilfe von VRRP löst. In einer HA-Konfiguration werden in der Regel zwei Netzwerkknoten gemeinsam eingerichtet, um den virtuellen Routing-Dienst bereitzustellen. Einer der Knoten fungiert als Master und synchronisiert seinen TCP-Sitzungsstatus mit dem anderen Netzwerkknoten, der als Backup dient. Fällt der Master aus, übernimmt der Backup-Netzwerkknoten den virtuellen Routing-Dienst. Auf Seiten der Compute-Knoten ist die Live-Migration von Instanzen möglich, was die Wartung von Knoten mit minimaler Unterbrechung erleichtert. Damit das funktioniert, müssen die Ressourcen der Compute-Knoten jedoch richtig dimensioniert sein. Andernfalls würde die Evakuierung der meisten Maschinen zu lange dauern. Aus betrieblicher Sicht ist das zwingend nötig, um das zugrunde liegende Betriebssystem aktuell halten zu können. Bei den Tools für den Betrieb sind wir allerdings noch weit davon entfernt, wo wir sein möchten. Upgrades sind definitiv kein einfacher Prozess, und es geht nicht nur darum, OpenStack aktuell zu halten, sondern auch das zugrunde liegende Betriebssystem – sowohl mit dringenden Sicherheitspatches als auch mit geplanten Updates. Der schwierigere Teil ist die Steuerungsebene. Das ist ein komplizierter Prozess, der im Grunde ein HA-Design voraussetzt, um die Ausfallzeiten der Service-APIs zu minimieren. Ein Upgrade unterbricht den Dienst, der aktualisiert wird, und ohne HA kommt es zu einem Ausfall. Derzeit sind die Tools für diese Aufgaben nicht gut. Es gibt keinen einfachen „Upgrade“-Button, und man muss viele Tools beherrschen, um ein Upgrade durchzuführen. Ohne einen DevOps-Ansatz mit einer Konfigurationsmanagement-Ebene ist es praktisch unmöglich. Mehrere Sessions auf dem Summit befassten sich mit den Problemen rund um Upgrades. Jede einzelne, die ich besucht habe, unterstrich, wie wichtig Planung (einschließlich eines Rollback-Plans für den Fall von Problemen) und Automatisierung in diesem Prozess sind. In diesem Bereich gibt es eindeutig Defizite, doch angesichts der Aufmerksamkeit und der Diskussionen auf dem Summit dürften wir in den nächsten Releases deutliche Verbesserungen sehen. Bei der Hardware ist die Auswahl der Komponenten wichtig und kann bei falschen Entscheidungen Probleme verursachen. Das heißt nicht, dass jeder Server ersetzt werden muss, um OpenStack zu betreiben. Es läuft im Grunde überall, wo Linux läuft, doch es ist immer eine gute Idee, sicherzustellen, dass die Kernel-Module für alle Serverkomponenten ausgereift sind. Natürlich ist die Wahl bestimmter Komponenten wichtiger als die anderer. Die Wahl der Netzwerkkarte kann beim Produktivbetrieb einen großen Unterschied machen, viel mehr als die Wahl der CPU. Hardwarehersteller haben begonnen, Referenzarchitekturen für OpenStack mit getesteten Hardwarekonfigurationen zu veröffentlichen. Wer bei null anfängt, findet darin also einen sehr interessanten Startpunkt. Die Hürde senken Ein Projekt, das OpenStack für Unternehmen noch attraktiver macht, ist Manila. Viele Sessions drehten sich um das gemeinsame Dateisystem, und auch an unserem Stand auf dem Summit erhielten wir Fragen zur Unterstützung von Manila. Mit Manila können Anwendungen in OpenStack auf einen Cloud-Dienst zurückgreifen, der Dateifreigaben bereitstellt. Früher hätten solche Anforderungen über Compute-Knoten abgedeckt werden müssen, die Freigaben exportieren – womit Anwendungsentwickler oder Ops-Engineers sich um Wartung und Ausfallszenarien des Freigabeservers kümmern mussten. Manila nimmt ihnen diese Sorgen ab und bietet einen Dateifreigabedienst als vollwertigen OpenStack-Dienst, genau wie Cinder für Blockgeräte. Das erleichtert auch die Skalierung von Anwendungen, die nicht nur von einem Object Store oder einer Datenbank abhängen, sondern auch von Dateien. Einfach weitere Instanzen starten und das von Manila bereitgestellte gemeinsame Dateisystem einbinden. Das ist vielleicht sogar noch interessanter für Legacy-Anwendungen, die überhaupt keinen Object Store nutzen, und könnte beim Wechsel in die Cloud den Ausschlag geben. Da Manila noch nicht releasereif ist, fehlt es an Dokumentation, und an vielen wichtigen Blueprints (auf Englisch) wird noch gearbeitet. Am auffälligsten ist das Fehlen einer automatisierten Einbindung, die eines der Themen der Design-Sessions auf dem Summit war. Es gibt viele Möglichkeiten, dieses Problem anzugehen, und mit der Verbreitung von Containern im OpenStack-Ökosystem gibt es nicht nur einen „richtigen“ Weg. Beim „Container-Weg“ wird die Freigabe höchstwahrscheinlich bereits auf dem Host eingebunden und dann per Bind-Mount eingehängt, bevor der Wechsel in das Container-Dateisystem erfolgt. Das unterscheidet sich deutlich vom Start einer VM, die die Freigabe beim Booten selbst finden und einbinden muss. Dazu wurden mehrere Techniken diskutiert, etwa die Einführung eines Agenten, der die Freigaben beim Booten erkennt und einbindet. Ein weiterer interessanter Punkt auf dem Design Summit war die Frage, ob Konsistenzgruppen für Manila sinnvoll sein könnten. Ein offensichtlicher Anwendungsfall für Cloud-Anwendungen ist schwer zu finden. Der klassische Fall für diese Art von Funktion ist eine Datenbank, die ihre Daten auf mehrere Volumes verteilt, wenn ein konsistentes Backup aller Daten erstellt werden muss. Diese Funktion ist vermutlich vor allem für Anwendungen auf Unternehmensniveau nützlich und könnte ihnen den Weg in die Cloud ebnen. Mit übergeordneten Cloud-Diensten wie Manila sinkt die Hürde, Unternehmensanwendungen in die Cloud zu verlagern. Für Hilfsdienste müssen weniger VMs bereitgestellt werden, sodass sich die IT-Mitarbeitenden weniger um bestimmte Dienst-VMs kümmern müssen. Interessante Sessions zu Hochverfügbarkeit und Unternehmensreife https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/lessons-learned-on-upgrades-the-importance-of-ha-and-automation (auf Englisch) https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/real-world-experiences-with-upgrading-openstack-at-time-warner-cable (auf Englisch) https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dell-and-red-hat-taking-openstack-to-the-enterprise (auf Englisch) Vorträge zu Manila https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/manila-an-update-on-openstack-and-039s-shared-file-services-program (auf Englisch) https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/manila-101-and-38-use-cases (auf Englisch)
