© Markus Feilner, BY-CC-SA 4.0

Bei Open Stack stapeln sich die Dienste hoch und mit ihnen die Abhängigkeiten. Vor allem Upgrades bereiten Admins Kopfzerbrechen: Ist es überhaupt möglich, Open Stack sinnvoll zu aktualisieren? Und wie verhalten sich die kommerziellen Open-Stack-Produkte? Das Linux-Magazin hat getestet.

Im laufenden Betrieb ist Open Stack recht problemlos. Kritisch wird es erst in dem Moment, in dem ein Unternehmen von einer Version von Open Stack auf die nächste Version aufrüsten möchte. Die erscheinen gleich zweimal pro Jahr, und an Upgrade-Pfade hat die Community offenbar in der Vergangenheit wenige Gedanken verschwendet. Das Linux-Magazin hat den Versuch gemacht und sowohl ein selbst gestricktes Setup als auch die fertigen Lösungen der diversen Open-Stack-Distributionen Upgrades unterzogen. Am Ende stand vor allem eine Erkenntnis: Leicht geht anders.

Die Sinne schärfen

Um zu verstehen, warum Admins Angst vor Open-Stack-Updates haben, ist ein kleiner Ausflug in die Geschichte des Projekts hilfreich. So alt ist das Projekt ja noch gar nicht: Zum ersten Mal sinnvoll einsetzen ließ sich Open Stack Essex, die damalige Version 2012.1, und selbst die besaß noch diverse Ecken und Kanten. Interessanterweise ist Essex jene Version von Open Stack, die Ubuntu 12.04 als Default beilag, sodass sich Installationen mit dieser Open-Stack-Version bis heute regelmäßig finden.

Die Plattform bestand damals im Wesentlichen aus den Komponenten, die für den elementaren Betrieb nötig waren:

• Keystone, der Authentifizierungsdienst
• Nova, das virtuelle Maschinen verwaltet
• Glance für die Imageverwaltung
• Swift, der Open-Stack-Objektspeicher
• Horizon, das Webinterface von Open Stack

Bekanntlich bildeten sich im Essex-Nachfolger Folsom noch zwei weitere Komponenten heraus, die beide aus Nova herausgelöst wurden: Quantum, das in Open Stack echte SDN-Funktionalität brachte, und Cinder, das zuvor als »nova-volume« die Verwaltung von dynamischen Blockspeichern für VMs in der Cloud leistete. Quantum heißt mittlerweile Neutron, ist aber immer noch der gleiche Dienst mit der selben Intention.

Die sieben Kernkomponenten sind heute: Keystone, Glance, Nova, Horizon, Neutron und Cinder sowie Swift, wenn der Admin einen Objektspeicher betreiben möchte. Die Kenntnis der Struktur ist wichtig, denn sie macht Blick auf das Wesentliche frei: Wer ein Update von einer Open-Stack-Version auf die nächste plant, sollte sich zunächst mit den Kernkomponenten befassen.

Nun ist es nicht so, als würde Open Stack der Nimbus einer ordentlich und sinnvoll zu aktualisierenden Lösung anhaften. Ganz im Gegenteil: Noch vor zwei Jahren hatten die Open-Stack-Entwickler kein größeres Problem damit, von einer Version zur nächsten die APIs ohne jede Vorwarnung durch neue Versionen zu ersetzen. Auch die Kommandos und die Parameter der Open-Stack-CLIs veränderten sich regelmäßig, freilich ohne dass jemand die Dokumentation angepasst hätte. So war ein Wartungsfenster zum Open-Stack-Upgrade für Admins ohne Staging-Setups im Grunde stets wie ein Sprung ins kalte Wasser.

Erfreulich ist, dass die Entwickler mittlerweile deutlich behutsamer bei der Einführung neuer Funktionen vorgehen. API-Versionen verschwinden nicht mehr einfach so aus Open Stack und die Einführung neuer API-Versionen wird über mehrere Versionen hinweg vorbereitet. Damit ein neues API in Open Stack ein altes ersetzen kann, muss das alte für mindestens eine Release ausdrücklich als “Deprecated” markiert sein.

Ähnlich verhält es sich bei den Kommandozeilen-Werkzeugen: Hier ersetzen die Entwickler entweder vorhandene Programme durch neue, die zeitgleich mit ihren Vorgängern installiert sein können. Oder sie dokumentieren die Änderungen so ausführlich, dass für Admins schnell ersichtlich ist, was nun anders funktioniert als vorher.

Heute besser in Schuss

Auch ihre Tools unter der Haube haben die Open-Stack-Entwickler besser im Griff als vor zwei Jahren. Besonders gut merken Admins das an den Schemata der Dienste, die MySQL betreffen. Die meisten Open-Stack-Dienste sind im Hintergrund an MySQL angebunden, um dort ihre eigenen Metadaten abzulegen. Zwischen zwei Open-Stack-Versionen ändert sich da so einiges, indem Tabellen vorhandene Spalten verlieren oder neue Spalten hinzubekommen.

Es wäre aber unpraktikabel, dem Admin das händische Pflegen der MySQL-Datenbanken als regelmäßige Aufgabe umzuhängen. Deshalb kommt jede Kernkomponente von Open Stack, die von dem Problem betroffenen ist, mit einem eigenen Werkzeug. Merkt der jeweilige Dienst beim ersten Start nach dem Update, dass das vorhandene Datenbankschema zu einer älteren Version gehört, tritt er ein Update der Datenbank in MySQL eigenhändig an. Danach läuft er weiter, als sei nichts gewesen.

Trotz aller Prozessverbesserungen bleibt ein Open-Stack-Update problematisch und voller Fallstricke, in denen sich Admins verheddern. Am Ende weist jedes Open-Stack-Setup spezifische Eigenheiten auf, die nicht zum Lieferumfang der eigenen Distribution gehören. Besonders oft finden sich etwa lokale Modifikationen beim Neutron-Netzwerkstack. Nicht alle Hersteller von SDN-Lösungen haben ihren Code nämlich bereits in Neutron integriert. Wer zum Beispiel Open Contrail mit Juniper-Hardware einsetzt, braucht dafür ein externes Neutron-Plugin des Herstellers.

Andere Beispiele für lokale Modifikationen sind Storage-Treiber, die nicht Bestandteil von Open Stack Cinder sind. Alle Anbieter von Open-Stack-Distributionen betrachten bei ihren Upgrade-Zyklen lediglich das Standardsetup. Wenn eine Vorgängerversion sich problemlos aus der Defaultkonfiguration auf die nächste Version bringen lässt, gilt der Test des Upgrade als bestanden. Für Admins ist es deshalb von großer Bedeutung, vor einem Upgrade eine Liste zu führen: Welche Komponenten gehören zum Setup, sind aber nicht offizieller Teil des Release-Zyklus? Welche Komponenten sind an das Setup angehäkelt? Sind Automatisierungen angeflanscht (Kasten “Automatisiertes Update”).

Automatisiertes Update

Wenn Admins sich mit Open Stack beschäftigen, interessieren sie sich früher oder später für eine der verfügbaren Automatisierungslösungen. Zwar ist ein alleinstehendes Setup mit wenigen Knoten noch halbwegs erträglich mit der Hand zu pflegen. Doch produktive Setups mit Dutzenden Computing-Knoten sind ein anderes Kaliber; hier ist Automatisierung unumgänglich.

Schwankende Qualität

Die Integration von Open Stack in Automatisierer wie Puppet oder Chef schwankt in ihrer Qualität erheblich (Abbildung 1). Hier zeigt sich, dass Open Stack ein Community-Projekt ist: Einzelne Facetten deckt die Lösung dann ab, wenn es Hersteller gibt, die sich für ein Thema speziell interessieren. Genau jene investieren dann Geld, um Entwickler für die Arbeit an einem Aspekt zu bezahlen. Die Open-Stack-Puppet-Module sind dafür ein hervorragendes Beispiel, denn diese sponsert seit Jahren ein französisches Unternehmen.

Abbildung 1: Automatisierte Setups setzen intelligente Updatestrategien voraus. Dabei helfen Puppet und Chef.

Das bedeutet jedoch nicht automatisch, dass die Module zu jedem Zeitpunkt in einem guten Zustand wären. Fast noch schlimmer ist jedoch, dass die Open-Stack-Module für Puppet bis zur aktuellen Version ein gutes Beispiel für mangelnde Upgrade-Fähigkeit waren. Beim Update von einer Open-Stack-Version zur nächsten ändern sich unter Umständen Konfigurationsparameter oder es kommen Optionen hinzu, für die neue Puppet-Module notwendig sind. Den Wechsel von Icehouse zu Juno haben die Puppet-Open-Stack-Entwickler aber richtig gut hingekriegt: Site-Manifeste, die für Icehouse gültig waren, brauchten für Juno-Support höchstens kleine Änderungen.

Ähnliches gilt für Chef: Seit Suse und Dell die Chef-Integration merklich vorantreiben, lässt sich Open Stack damit brauchbar deployen. Auch hier ist im Falle eines Upgrade aber das Warten auf neue Cookbooks normal – und wie im Puppet-Beispiel gibt es regelmäßig nervige Kinderkrankheiten.

Egal was eine Plattform zur Automatisierung nutzt: Wenn das Update von einer Open-Stack-Version auf die nächste ansteht, sind Puppet oder Chef stets erste Wahl. Idealerweise unterstützt die gesamte Automatisierungs-Infrastruktur die neue Open-Stack-Version bereits vor der Installation der ersten neuen Pakete.

Im Selbstversuch hat sich das Linux-Magazin zunächst mit dem Upgrade einer Ubuntu-Cloud (Abbildung 2) beschäftigt, wobei “Ubuntu-Cloud” in diesem Falle nicht das Produkt bezeichnet. Gemeint ist eine Cloud aus Ubuntu-Installationen, die mit den Open-Stack-Paketen der Distribution ausgestattet sind. Komponenten wie MaaS und Juju haben beim Vorgang also keine Rolle gespielt, wenigstens MaaS wäre als Komponente aber sowieso außen vor. Denn MaaS kümmert sich ja vor allen Dingen um das Deployment von Blech.

Abbildung 2: Ubuntu ist in Sachen Upgrades sehr unkompliziert, auch weil Canonical Upgrades testet.

Nachdem die Tester die Infrastruktur zunächst in einen Upgrade-fähigen Zustand versetzt hatten, folgte die Aktualisierung der Puppet-Manifeste auf dem Puppet-Master. Es hat sich als sinnvoll herausgestellt, alle durch Puppet induzierten Änderungen vor dem eigentlichen Open-Stack-Upgrade auf den Rechnern zu deployen.

Im Falle von »nova-compute« , also der Computing-Komponente von Nova, führte das zwar zum Absturz sämtlicher Instanzen innerhalb des gesamten Clusters. Das war allerdings zu verschmerzen, denn auch dann, wenn »nova-compute« abstürzt, laufen die zunächst durch jenen Dienst gestarteten VMs weiter. Der Absturz von »nova-compute« führt also nicht zu einer Downtime, die der Kunde bemerkt. Ähnliches gilt auch für alle anderen Open-Stack-Komponenten in gleicher Weise.

Im Anschluss an das Deployment der Konfigurationsänderungen folgt ein sehr unspektakuläres »apt-get dist-upgrade« auf allen Hosts. Zuvor hatten die Tester sichergestellt, dass die Paketquellen in »/etc/apt/sources.list.d« Einträge für die nächste Open-Stack-Version enthielten. Spezifisch also für das Juno-Repository des Ubuntu-Server-Teams.

Insgesamt hat das Upgrade dieser Konstellation deutlich weniger Reibereien verursacht, als die Tester im Vorfeld erwartet hatten (Abbildung 2). Am Ende des Vorgangs stand eine Open-Stack-Cloud in der Juno-Version, die ihren Dienst zuverlässig wie ihre Vorgängerin verrichtete. Der Vollständigkeit halber sei angemerkt, dass das Testsetup auf zehn Knoten beschränkt war. Ob das Upgrade von Hunderten oder gar Tausenden Knoten ähnlich reibungslos verläuft, lässt sich daraus freilich noch nicht ablesen. Offenkundige Gründe, daran zu zweifeln, zeigten sich jedoch beim Test nicht.

Suse und Red Hat

Wer sich gegen eine selbst gestrickte Lösung entscheidet und stattdessen auf ein fertiges Cloudprodukt setzt, erwartet einiges an Service durch eben jenes Produkt. Upgrades sind davon keine Ausnahme. Der Admin erwartet hier völlig legitim, dass er von der einen Version einer kommerziellen Distribution mit Open Stack zur nächsten Version springen kann, ohne dass dabei sein Setup in Rauch aufgeht (Abbildung 3).

Abbildung 3: Suse bietet für die Suse Cloud einen gut dokumentierten Pfad zu Upgrades.

Für Suse Cloud war der Zeitpunkt dieses Tests ungünstig – Suse hat ein Upgrade der Suse Cloud auf Version 5 inklusive Support für Juno bereits vor Wochen angekündigt. Das neue Produkt steht also vermutlich schon beim Erscheinen dieses Heftes in den Regalen – für den Test kam die Version 5 allerdings zu spät.

Ein Blick in die Vergangenheit zeigt allerdings, dass Suse sich durchaus der Upgrade-Problematik bewusst ist. So steht für das Upgrade von Suse Cloud 3 auf Suse Cloud 4 unter [1] ein ausführlicher Guide zur Verfügung, der auf die vorgeschlagene Methodik und eventuelle Fallstricke eingeht. Ein Werkzeug im Suse-Github-Account legt nahe, dass Suse beim Upgrade von Version 4 zu Version 5 ganz ähnlich vorgehen dürfte (Abbildung 4, [2]). Denn dort finden sich gleich mehrere Skripte, die vor und nach dem Upgrade aufzurufen sind und das System in einen Upgrade-bereiten Zustand versetzen oder nach dem Upgrade die Überbleibsel der Vorgängerversion beseitigen.

Abbildung 4: Die Skripte im Suse-Git deuten an, dass es Upgrades auch von Suse Cloud 4 zur 5 geben wird.

Kunden dürfen davon ausgehen, dass Suse auch das Thema HA im Blick hat; eine entsprechende Anleitung wird der Hersteller wohl zusammen mit Suse 5 der Öffentlichkeit zur Verfügung stellen. Suse macht also eine durchaus schlanke Figur in Sachen Open-Stack-Upgrades. Wenn es der Firma auch noch gelingt, das Upgrade von 4 auf 5 eleganter in Sachen Benutzbarkeit zu gestalten, als es sich zwischen den Versionen 3 und 4 präsentiert, ist das Upgrade eine runde Sache.

Red Hat fischt mit seinem Open-Stack-Produkt natürlich ebenfalls im Segment der Businesskunden und stellt – wie Suse – regelmäßig neue Versionen in seiner “RHEL Open Stack Platform” zur Verfügung. Wie bei Suse zeichnen sich auch bei Red Hat Major-Releases dadurch aus, dass sie die neuen Major-Versionen von Open Stack beherrschen. In seiner Upgrade-Policy hält der Hersteller eindeutig fest, dass er Upgrade-Pfade zwischen zwei Versionen bereitstellt. Doch – wie zuvor bereits erwähnt – bezieht sich das stets nur auf den “Standard”, also den kleinsten gemeinsamen Nenner im Sachen Open-Stack-Setup.

Im Rahmen der offiziell unterstützten Setups gibt Red Hat sich aber offensichtlich große Mühe, wirklich alle Eventualitäten abzudecken (Abbildung 5). In der Dokumentation zum Open-Stack-Enterprise-Paket auf RHEL-Basis finden sich diverse Beschreibungen erfolgreicher Open-Stack-Upgrades [3].

Abbildung 5: Red Hat verpflichtet sich sogar per Release-Policy zu funktionierenden Upgrade-Pfaden.

Die Firma Red Hat geht so weit und unterscheidet zwischen einzelnen Upgrade-Typen, zwischen denen sich der Admin entscheiden darf: Rolling Upgrades ohne für den Kunden bemerkbare Downtime, Downtime aller Dienste im Tausch für ein schnelleres Upgrade, jeweils kombiniert mit dem Faktor Live-Migration. In Sachen Qualität nehmen Red Hats und Suses Anleitungen sich dabei nicht viel: Bei beiden Anbietern watet der Admin knöcheltief in Paketen und führt diverse Befehle von Hand aus, um am Ende eine aktualisierte Cloud zu erhalten.

Upgrades bei Ubuntu Cloud

Wer sich seine Ubuntu-Cloud nicht selber bastelt, sondern Ubuntu Cloud ins Rechenzentrum stellt, erwartet ähnliche Leistungen wie bei Suse oder Red Hat. Ubuntu profitiert an dieser Stelle maßgeblich davon, dass die Ubuntu-Engineers Upgrade-Pfade zwischen den einzelnen Open-Stack-Releases sowieso regelmäßig testen. Wenn die Konfiguration der Wolke dann nicht von den Nutzern kommt, sondern aus einer standardisierten Juju-Installation, schafft das eigentlich mehr Probleme aus dem Weg, als es verursacht. Ubuntu-Upgrades auf offiziellem Weg sind deshalb eine eher angenehme Sache, solange man kein Setup mit eigens für diesen Zweck entworfenen Vorrichtungen hat.

Fazit

Die Ergebnisse des Upgrade-Tests sind aus Sicht des Admin sehr erfreulich. Anders als vor anderthalb Jahren ist es heute durchaus möglich, eine Wolke mit Open Stack von einer Major-Version auf die nächste anzuheben – zumindest solange sich das Setup an den Standards des jeweiligen Vendors orientiert.

Wenn angeschraubte Komponenten hinzukommen, wird das Thema allerdings hakelig. Hier hängt es letztlich vom Einzelfall ab, ob das Upgrade überhaupt funktioniert. Admins sollten sich jedenfalls dringend eine Testumgebung bauen, in der sie das Upgrade eines nahe am Livesystem orientierten Staging-Setups üben können. Die dabei gewonnene Erfahrung hilft jedenfalls dabei, sich beim Upgrade der Produktionsplattform Probleme vom Leibe zu halten.