© kran77 / 123RF.com

OpenStack ist seit zwölf Jahren auf dem Markt und gilt als eines der großen Open-Source-Projekte. Thierry Carrez und Jeremy Stanley arbeiten an der Software und geben Auskunft zu Problemen, Neuerungen und künftigen Plänen.

Linux-Magazin: Die OpenStack Foundation hat ihren Namen in OpenInfra Foundation geändert. Können Sie etwas zu der Rolle sagen, die OpenStack in diesem neuen Umfeld spielt?

Thierry Carrez: Die Stiftung wurde ursprünglich gegründet, um das OpenStack-Projekt zu hosten und zu fördern. Dabei haben wir in den letzten zehn Jahren eine große Community von Betreibern, Organisationen und Entwicklern aufgebaut, die sich für das Konzept der Nutzung von Open-Source-Lösungen zur Bereitstellung von Infrastruktur interessieren. Bei einer solchen Zielgruppe erscheint es nur folgerichtig, dass wir andere Projekte unterstützen und hosten, die für dieselbe Zielgruppe relevant sind.

Aus diesem Grund haben wir uns zur OpenInfra Foundation zusammengeschlossen, um über OpenStack hinaus weitere offene Infrastrukturprojekte zu unterstützen, die für die von uns zusammengestellte Gruppe von Infrastrukturanbietern von Interesse sind. OpenStack ist jedoch nach wie vor das mit Abstand größte Projekt, das die Foundation hostet, und steht daher im Mittelpunkt all unserer Aktivitäten. Mit der Veränderung und dem neuen Projekt-Hosting-Angebot, das wir auf dem Summit 2018 in Berlin vorgestellt haben, sind wir bereit, das nächste Jahrzehnt der Open-Infrastructure-Projekte in Angriff zu nehmen.

LM: OpenStack feiert dieses Jahr sein 12-jähriges Bestehen. Wo sehen Sie es in den kommenden Jahren? Und was wird sich ändern?

TC: Heute gilt OpenStack als De-facto-Open-Source-Standard für das Bereitstellen von Cloud-Infrastrukturdiensten, sei es, um private Ressourcen für eine bestimmte Organisation anzubieten oder öffentliche Ressourcen für Kunden mit einer Kreditkarte auf der ganzen Welt. In Kombination mit dem Linux-Kernel und Kubernetes für die Anwendungsorchestrierung bildet es ein sehr beliebtes Open-Source-Framework, die Linux OpenStack Kubernetes Infrastructure (LOKI). Die Nutzung nimmt deutlich zu, angetrieben durch neue Anforderungen und neue Praktiken.

Da OpenStack funktional ausgereift und sein Anwendungsbereich nun klar definiert ist, gehe ich davon aus, dass sich die Neuentwicklung verlangsamen und auf die Wartung konzentrieren wird. Genauso wie neue Fähigkeiten der Computerhardware die Entwicklung des Linux-Kernels antreiben, erwarte ich, dass auch die Entwicklung von OpenStack von neuen Fähigkeiten der Rechenzentrumshardware weiter vorangetrieben wird, die es dann für die Software verfügbar zu machen gilt.

LM: OpenStack ist immer noch ein sehr erfolgreiches Projekt mit großen Zahlen. Kritiker sagen jedoch, das Wachstum der Installationen sei eher auf bestehende als auf neue Kunden zurückzuführen. Stimmt das?

TC: Tatsächlich findet das Wachstum in beiden Bereichen statt. Im Juni haben wir unser erstes persönliches Event seit der Pandemie abgehalten, den OpenInfra Summit in Berlin. Wir haben dort viele neue Nutzer getroffen. Davon arbeiten etliche in beeindruckenden Settings mit mehr als 100 000 Rechenkernen auf OpenStack. Neue Anforderungen wie die digitale Souveränität treiben die Akzeptanz von OpenStack voran, insbesondere bei wissenschaftlichen Anwendungsfällen und der Public Cloud in Europa. Die Notwendigkeit, neue kommunale und Forschungssysteme für die Pandemiebekämpfung schnell bereitzustellen, führte zu vielen zusätzlichen Deployments weltweit. Bestehende Implementierungen wachsen ebenfalls weiter. Das bedeutet ein gesundes Gleichgewicht von Energie und Kreativität für die Gemeinschaft.

LM: Wenn Sie einen Blick auf mögliche Konkurrenten werfen, warum sollten sich Nutzer für OpenStack entscheiden und nicht für AWS? Und wo liegen die Hauptunterschiede?

TC: Anwender sollten immer die Lösung wählen, die sich am besten für ihre spezifischen Bedürfnisse eignet. Es gibt viele Gründe, warum sich jemand für das eine, das andere oder beides entscheiden würde. Unsere Community sagt uns, dass sie in OpenStack einen wichtigen Faktor sieht, um ihre Infrastrukturkosten zu kontrollieren, ihre regulatorischen Anforderungen zu erfüllen oder um sehr spezifische Anwendungsfälle abzudecken, für die Hyperscaler keine gute Lösung bieten.

Bei diesen Strategien werden private OpenStack-Clouds oft in Kombination mit AWS, Azure, Google oder einer der vielen OpenStack-basierten öffentlichen Clouds in einer Multi- oder Hybrid-Cloud-Bereitstellung verwendet. Der Hauptunterschied zwischen OpenStack und proprietären Clouds liegt jedoch in der Möglichkeit, sich an einer offenen, aktiven Community zu beteiligen und die Richtung des Projekts durch eigenes Engagement direkt zu beeinflussen. Das werden proprietäre Lösungen nie bieten können.

LM: Unternehmen suchen händeringend nach Entwicklern und IT-Experten. Welche Schritte planen Sie, um die Nutzung von OpenStack zu vereinfachen und den Personalmangel zu lindern?

Jeremy Stanley: Es ist lustig: Wenn ich Leute darüber reden höre, wie schwer OpenStack zu implementieren und zu verwalten sei, haben sie es in der Regel seit Jahren nicht mehr angerührt. Die Community hat den laufenden Betrieb zu einem zentralen Punkt bei der Entwicklung gemacht, und während die Infrastruktur immer ein schwieriges Unterfangen blieb, sind die stereotypen Herausforderungen bei der Bereitstellung und dem Betrieb von OpenStack längst kein Thema mehr.

LM: Gibt es Pläne, die Bereitstellung zu vereinfachen?

JS: In den letzten Jahren steckte die Community viel Energie in die Unterstützung von Installationen für eine Vielzahl beliebter Konfigurationsmanagement- und Orchestrierungslösungen wie Ansible, Chef, Helm und Puppet und hat sich auf die Paketierung von Server-Distributionen und Container-basierten Frameworks wie Kubernetes konzentriert.

LM: Und was könnte Ihrer Meinung nach die Installation erleichtern?

JS: Vielen neuen Nutzern ist nicht klar, dass OpenStack keine Alles-oder-nichts-Lösung ist. Es umfasst eine modulare Suite von Diensten, von denen die meisten optional sind – einige lassen sich sogar ganz unabhängig nutzen. Wir arbeiten daran, diese Botschaft zu verbreiten. Ein Großteil der wahrgenommenen Komplexität resultiert in Wirklichkeit daraus, dass die Anwender irrtümlicherweise mehr installieren, als sie eigentlich brauchen.

LM: Können Sie die modulare Architektur von OpenStack beschreiben?

JS: Alle OpenStack-Projekte basieren auf dem grundlegenden Designprinzip, dass Dienste über REST-Schnittstellen (also HTTP-basiert) miteinander interagieren, um gemeinsam genutzte Ressourcen zu koordinieren. Die in einer konsistenten Programmiersprache und einem konsistenten Codierungsstil geschriebenen Dienste vermeiden durch das Nutzen zentraler Bibliotheken eine Duplizierung, und es gibt einen Konsens zu Abhängigkeiten. Das Ergebnis ist eine Suite von optionalen Service-Optionen, die Unternehmen auf ihre speziellen Anwendungsfälle zuschneiden können, indem sie nur das installieren, was sie benötigen. Gleichzeitig halten sie sich die Möglichkeit offen, ihre Lösung durch Hinzufügen weiterer Services zu erweitern, wenn sich ihre Anforderungen ändern.

LM: Gibt es Pläne, den Upgrade-Prozess weniger komplex und mit weniger Ausfallzeiten zu gestalten?

TC:Heute präsentiert sich das Upgrade eines OpenStack-Clusters als gut etablierter Prozess, der keine signifikanten Ausfallzeiten nach sich zieht. Aber gleichzeitig ist die Größe der Bereitstellungen erheblich gewachsen, wobei einige inzwischen die Millionen-Core-CPU-Marke deutlich überschreiten. Das sind eine Menge OpenStack-Cluster, und sie alle sechs Monate mit einem Release auf dem neuesten Stand zu halten, verursacht noch immer einen erheblichen Aufwand. Um den Upgrade-Druck für etablierte Bereitstellungen zu verringern, bietet OpenStack ab dem “Antelope”-Release im März 2023 die Möglichkeit, direkt jährlich statt halbjährlich zu aktualisieren. Das dürfte OpenStack-Betreibern das Leben erleichtern.

LM: Was sollte sich an der Architektur von OpenStack ändern, um das Management zu vereinfachen?

JS: Ein wichtiges und bereits in vollem Gange befindliches Vorhaben ist die Implementierung eines erweiterbaren, rollenbasierten Zugriffskontrollmodells. Es versetzt Betreiber in die Lage, Berechtigungen für bestimmte Aufgaben an andere Nutzer zu delegieren und so ihre eigene Arbeitslast zu reduzieren. Die Nutzer der Cloud-Ressourcen haben dann ebenfalls die Möglichkeit, den relevanten Akteuren in ihren Unternehmen eine feinkörnigere Kontrolle über bestimmte Aktionen zu geben. Dieses Vorhaben befindet sich noch im Anfangsstadium. Es hat mit der Einführung der Unterstützung für eine Nur-Lese-Rolle begonnen, die den Zugang zu Audit-Systemen ermöglicht, ohne dass die Gefahr besteht, dass der Benutzer Änderungen vornimmt. In den kommenden Versionen wird die Möglichkeit folgen, spezifischere Rollen zu erstellen.

LM: Worin liegen Ihrer Meinung nach die größten Herausforderungen bei der Bereitstellung von OpenStack für Unternehmen?

JS: Die mit Abstand schwierigsten Herausforderungen liegen in der Planung und Dimensionierung der Infrastruktur, da kein Anwendungsfall dem anderen gleicht. Vor allem aufgrund der zusätzlichen Komplikationen bei der Beschaffung von Hardware ist es heute wichtiger denn je, so exakt wie möglich zu planen und nicht zu viel auszugeben. Allerdings ist die Dimensionierung eines Deployments, wenn es über die triviale Ebene hinausgeht, eher eine Kunst als eine Wissenschaft, und das gilt nicht nur für OpenStack. Wenn Anwender diese Aufgabe nicht oft und auch für eine Vielzahl von Lösungen bewältigt haben, fällt es ihnen schwer zu erkennen, wo sie ansetzen sollen. Das ist einer der wichtigsten Gründe, Verbindung zu einem Anbieter von OpenStack-Distributionen aufzubauen: Er hat mehr Erfahrung als jeder andere, wenn es darum geht abzuschätzen, wie viel und welche Hardware man wahrscheinlich benötigt und wie sich die Bereitstellung am besten gestalten lässt, um die Effizienz zu maximieren und die Kosten zu minimieren.

LM: In welcher Weise trägt das neue Release “Yoga” dazu bei, die Dinge zu vereinfachen?

JS: Es fällt schwer, da einzelne Funktionen herauszugreifen. Ein gutes Beispiel ist aber, dass Ironic seine Standardeinstellungen weiterentwickelt hat, um sie an modernere Server-Infrastrukturen anzupassen. Dazu stellt es von Legacy-BIOS auf UEFI um und wertet lokale Boot-Workflows für bereitgestellte Images auf. Ein weiteres Beispiel bietet Kolla, das sich auf ein einziges Set von Container-Images konzentriert, anstatt zu versuchen, zwei verschiedene Lösungen parallel zu pflegen. Zudem vereinfacht es sein Design durch eine neue Ansible-Sammlung, die alle Komponenten gemeinsam nutzen. Darüber hinaus hat Nova die Unterstützung für die Auslagerung der Netzwerkkontrollebene auf eine Smart NIC hinzugefügt, was mehr Kapazität für Hypervisor-Workloads freimacht. Zudem kann Nova nun auch die Emulation von Prozessorarchitekturen für Benutzer bereitstellen, die Software für ARM-, MIPS-, PowerPC- oder S/390-Systeme auf demselben Host ausführen möchten.

LM: Neutron bietet in “Yoga” eine neue Funktion namens Local**IP — können Sie deren Leistungsvorteile erklären?

Thierry Carrez: Local IP ist in erster Linie auf eine hohe Effizienz und Leistung der Netzwerkdatenebene für sehr große Clouds oder solche mit hohen Anforderungen an den Netzwerkdurchsatz ausgerichtet. Dabei handelt es sich um eine virtuelle IP, die mehrere Ports oder VMs gemeinsam nutzen können, solange sie nur innerhalb der Grenzen desselben physischen Servers oder Knotens erreichbar sind. Local IP ist für genau solche Leistungsanwendungen optimiert.

LM: Auf dem Open Infrastructure Summit haben Sie einen Vortrag gehalten, um Erfahrungen zur Skalierung zu sammeln. Können Sie einen kurzen Überblick darüber geben, was die Benutzer dort berichteten? Und welcher Art könnten die Probleme bei der Skalierung sein?

TC: Es gab bei diesem Vortrag nur noch Stehplätze, und es war großartig zu sehen, wie die Betreiber großer Implementierungen bei Ubisoft, Bloomberg, Ovhcloud, CERN, Workday oder Adavinta ihre Erfahrungen und Probleme während dieser Sitzung mitteilten. Sie diskutierten vor allem zwei klassische Skalierungsprobleme in großen OpenStack-Clustern: RabbitMQ und Neutron. Insbesondere tauschten sie Tipps aus, wie man Lastspitzen am besten erkennt und entschärft. Diese Diskussion haben die Betreiber selbst innerhalb der OpenStack Large Scale SIG angeregt. Das ist ein großartiges Beispiel dafür, was offene Gemeinschaften gemeinsam erreichen können – etwas, das nur mit Open-Source-Software wirklich gelingt.

LM: Haben Sie vielen Dank für die aufschlussreichen Einblicke in das OpenStack-Universum!