Open Stack im Reality-Check Auf dem Gipfel

6
tens dann, wenn sie sich tatsächlich an ein Open-Stack-Setup wagen und damit beginnen, ihre eigenen Erfahrungen zu sammeln. Bald stellt sich heraus, dass ein Open- Stack-Admin nicht der Raumfahrer ist, der aus seiner Kommandozentrale heraus die Geschicke des Setups leitet, sondern viel mehr der Feuerwehrmann, der die losen Enden seiner Wolke irgendwie zu- sammenzuhalten versucht. Anders als Open Stack selbst und die diversen Pro- duktanbieter es vorgaukeln, ist das Pro- dukt nämlich weder fertig noch aus der Dose für den Einsatz in jedem beliebigen Unternehmen geeignet. Die Gründe dafür sind vielfältig – einige Faktoren stechen jedoch heraus. Automatisierung ist ein Muss Einer der maßgeblichen Unterschiede zwischen konventionellen Setups und Cloudumgebungen ist der Umfang der Automatisierung. Bei klassischen Setups ist es noch die Aufgabe des Admin, auf Zuruf neue VMs anzulegen und sie so einzurichten, dass der Kunde sie nutzen kann. Dabei verbindet der Installateur eine größere Anzahl von Arbeitsschrit- ten miteinander: Zuerst ist Storage zu kommissionieren und an eine virtuelle Maschine anzuhängen, sodass in dieser anschließend die Installation des Be- triebssystems möglich ist. Danach spielt auch das Netzwerk eine große Rolle: VMs brauchen selbstver- ständlich eine Anbindung an das Inter- net. Die ist in konventionellen Setups meist dadurch herzustellen, dass die VM ein virtuelles Netzwerkinterface be- kommt, das an ein virtuelles LAN-Inter- face geklemmt ist. Seit Jahren hat es nun schon den An- schein, als seien die Begriffe „Cloud Computing“ und „Open Stack“ so gut wie Synonyme. Während es früher durchaus noch andere Cloudprodukte wie Euca- lyptus oder Cloudstack regelmäßig in die Berichterstattung schafften, scheint Open Stack inzwischen die öffentliche Aufmerksamkeit komplett für sich allein gepachtet zu haben. Kein Zweifel: Open Stack befindet sich aktuell auf dem Gipfel eines Hype. Buchstäblich jede Firma, die etwas auf sich hält, hat Produkte mit Open-Stack- Bezug ins Programm genommen. Da ist es ganz gleich, ob der Storagehersteller mit der guten Anbindung seiner Geräte an die Speicherkomponente Cinder wirbt oder ob VMware erklärt, dass sich sein Vcenter nun auch problemlos als Hyper- visor für Open Stack einsetzen lässt – der Tenor ist in allen Fällen der gleiche. Er lautet: Wir sind auch mit dabei! Open Stack ist toll! Für die großen Hersteller von Linux-Distributionen – allen voran Suse, Canonical und Red Hat – ist Open Stack mittlerweile von größter Bedeutung auch für den eigenen Erfolg. Alle drei Unternehmen haben Produkte im Portfolio, die Admins eine fertige Open-Stack-Wolke in kurzer Zeit und ohne viel Aufwand versprechen. Liest man die Werbeanzeigen für Suse Cloud oder Red Hats Open-Stack-Enterprise- Produkt, entsteht immer der gleiche Ein- druck: Nach der Installation legt sich der Admin ruhig in die Sonne und lässt Open Stack die Arbeit erledigen, die er sonst selbst tun müsste. Denn auf diese Art des Betriebs will Open Stack ausgelegt sein. Der Praxis-Check Dass mit der Werbung der Anbieter – zu denen mittlerweile auch HP und diverse andere Branchengrößen gehören (Ab- bildung 1) – irgendetwas nicht stimmen kann, merken Administratoren spätes- Auf dem Höhepunkt des Hype versprechen die Anbieter von Open-Stack-Produkten potenziellen Kunden eine eierlegende Wollmilchsau – doch geliefert wird meist nur eine lahme Ente. Martin Loschwitz Open Stack im Reality-Check Auf dem Gipfel Sysadmin 74 www.linux-magazin.de Open Stack 07/2015 © Yuryy Bezrukov, 123RF

Transcript of Open Stack im Reality-Check Auf dem Gipfel

Page 1: Open Stack im Reality-Check Auf dem Gipfel

tens dann, wenn sie sich tatsächlich an ein Open-Stack-Setup wagen und damit beginnen, ihre eigenen Erfahrungen zu sammeln. Bald stellt sich heraus, dass ein Open-Stack-Admin nicht der Raumfahrer ist, der aus seiner Kommandozentrale heraus die Geschicke des Setups leitet, sondern viel mehr der Feuerwehrmann, der die losen Enden seiner Wolke irgendwie zu-sammenzuhalten versucht. Anders als Open Stack selbst und die diversen Pro-duktanbieter es vorgaukeln, ist das Pro-dukt nämlich weder fertig noch aus der Dose für den Einsatz in jedem beliebigen Unternehmen geeignet. Die Gründe dafür sind vielfältig – einige Faktoren stechen jedoch heraus.

Automatisierung ist ein Muss

Einer der maßgeblichen Unterschiede zwischen konventionellen Setups und Cloudumgebungen ist der Umfang der Automatisierung. Bei klassischen Setups ist es noch die Aufgabe des Admin, auf Zuruf neue VMs anzulegen und sie so einzurichten, dass der Kunde sie nutzen kann. Dabei verbindet der Installateur eine größere Anzahl von Arbeitsschrit-ten miteinander: Zuerst ist Storage zu kommissionieren und an eine virtuelle Maschine anzuhängen, sodass in dieser anschließend die Installation des Be-triebssystems möglich ist. Danach spielt auch das Netzwerk eine große Rolle: VMs brauchen selbstver-ständlich eine Anbindung an das Inter-net. Die ist in konventionellen Setups meist dadurch herzustellen, dass die VM ein virtuelles Netzwerkinterface be-kommt, das an ein virtuelles LAN-Inter-face geklemmt ist.

Seit Jahren hat es nun schon den An-schein, als seien die Begriffe „Cloud Computing“ und „Open Stack“ so gut wie Synonyme. Während es früher durchaus noch andere Cloudprodukte wie Euca-lyptus oder Cloudstack regelmäßig in die Berichterstattung schafften, scheint Open Stack inzwischen die öffentliche Aufmerksamkeit komplett für sich allein gepachtet zu haben. Kein Zweifel: Open Stack befindet sich aktuell auf dem Gipfel eines Hype.Buchstäblich jede Firma, die etwas auf sich hält, hat Produkte mit Open-Stack-Bezug ins Programm genommen. Da ist es ganz gleich, ob der Storagehersteller mit der guten Anbindung seiner Geräte an die Speicherkomponente Cinder wirbt oder ob VMware erklärt, dass sich sein Vcenter nun auch problemlos als Hyper-visor für Open Stack einsetzen lässt – der Tenor ist in allen Fällen der gleiche. Er lautet: Wir sind auch mit dabei! Open Stack ist toll! Für die großen Hersteller

von Linux-Distributionen – allen voran Suse, Canonical und Red Hat – ist Open Stack mittlerweile von größter Bedeutung auch für den eigenen Erfolg. Alle drei Unternehmen haben Produkte im Portfolio, die Admins eine fertige Open-Stack-Wolke in kurzer Zeit und ohne viel Aufwand versprechen. Liest man die Werbeanzeigen für Suse Cloud oder Red Hats Open-Stack-Enterprise-Produkt, entsteht immer der gleiche Ein-druck: Nach der Installation legt sich der Admin ruhig in die Sonne und lässt Open Stack die Arbeit erledigen, die er sonst selbst tun müsste. Denn auf diese Art des Betriebs will Open Stack ausgelegt sein.

Der Praxis-Check

Dass mit der Werbung der Anbieter – zu denen mittlerweile auch HP und diverse andere Branchengrößen gehören (Ab-

bildung 1) – irgendetwas nicht stimmen kann, merken Administratoren spätes-

Auf dem Höhepunkt des Hype versprechen die Anbieter von Open-Stack-Produkten potenziellen Kunden eine eierlegende Wollmilchsau – doch geliefert wird meist nur eine lahme Ente. Martin Loschwitz

Open Stack im Reality-Check

Auf dem Gipfel

Sysa

dm

in

74

ww

w.lin

ux-m

agaz

in.d

eO

pen

Sta

ck07

/201

Yur

yy B

ezru

kov,

123R

F

Page 2: Open Stack im Reality-Check Auf dem Gipfel

In einer Cloud sollen all diese Arbeits-schritte automatisch ablaufen: Der An-bieter stellt die Infrastruktur zur Verfü-gung, also einen großen Haufen iden-tischer Hardware. Die Cloudplattform übernimmt ihre Verwaltung: Das Netz-werk existiert bloß noch virtuell in Form eines Software-defined Networking. Die gesamte Kontrolle der Paketflüsse erfolgt also nicht mehr in der Switch-Hardware, sondern durch Software innerhalb der Installation. Ähnlich ist es in Sachen Storage: Statt eines zentralen Speichers in typischer SAN-Manier sorgt Software-defined Storage dafür, dass jedem Kun-den jederzeit der Speicher zur Verfügung steht, den er braucht. Dem Admin kommt im Anschluss an das erstmalige Setup eigentlich bloß noch die Aufgabe zu, ein Auge auf die Auslastung der Hardware zu haben und gegebenenfalls die Plattform zu erwei-tern. Doch keine Panik: Auch dafür bietet Open Stack schon eine Lösung, denn das nachträgliche Anbauen von Hardware ist angeblich kein Problem.Ihre Erfüllung findet die Idee des Cloud Computing dann, wenn Kunden sich per Webinterface ihre virtuelle Rechenplatt-form selbst zusammenklicken und die vom Dienstleister aufgesetzte Umgebung sie problemlos betreiben kann.

Storage: Arg!

Open Stacks erstes Problem ist Storage. Die Anforderungen in einer Cloud sind schnell formuliert: Nahtlose Skalierbar-keit und die Möglichkeit, jeden Datensatz auf grundsätzlich jedem Host innerhalb der Cloud nutzen zu können, sind ein Muss. Auch die Performance muss stim-men. Entgegen schlecht informierten Vor-hersagen ist lokaler Speicher für die VMs keine Option: In einer Cloud muss jede VM zu jedem Zeitpunkt auf jedem Host laufen können, weil sonst das Skalieren in die Breite für die gesamte Plattform nicht möglich wäre.

All diesen Anforderungen begegnet Open Stack ab Werk, indem es einen zentral angebundenen Speicher über den inter-nen Volume-Dienst Cinder per I-SCSI an die Hypervisor-Knoten exportiert, die die I-SCSI-Geräte dann lokal an die laufen-den VMs anbinden. Das ist freilich so langsam, dass sich der Admin über The-men wie Performance oder Latenz schon gar keine Gedanken mehr zu machen braucht.Als Alternative zum I-SCSI-Wahnsinn vermarkten fast alle großen Unterneh-men zurzeit Ceph (Abbildung 2, [1]). Im ersten Moment macht Ceph einen wirklich sehr guten Eindruck: Dezentra-ler Speicher, der sich absolut flexibel an jeden Host anbinden lässt. Auch die Ska-lierbarkeit in die Breite ist gegeben, denn geht der Platz aus, hängt der Admin ein-fach neue Ceph-Knoten hinzu. Garniert wird das Ganze mit einem sehr hohen Datendurchsatz. Alles picobello also? Leider nicht: Was in der Euphorie rund um Ceph regelmäßig untergeht, ist seine völlig indiskutable Latenz-Performance. Beim Ceph Day in Berlin im April wurde deutlich, dass selbst solche Branchengrößen wie San-disk oder Fujitsu aktuell keine Lösung für das Problem parat haben. Wer MySQL in einer Open-Stack-Instanz betreibt, die im

Hintergrund auf Ceph setzt, kommt über 500 I/ O-Operationen pro Sekunde (IOPS) nicht hinaus. Für Webshops und viele an-dere Applikationen reicht das nicht mal annähernd.Tatsächlich gibt es mehrere kommerzi-elle SDN-Ansätze, die das Thema Latenz deutlich besser im Griff haben und mit denen sich Open Stack so betreiben lässt, dass zumindest 3000 IOPS nicht mehr illusorisch sind. Doch damit gilt leider auch, dass Open Stack dann kein reines Open-Source-Projekt mehr ist. Denn für den sinnvollen Einsatz ist ein kommer-zielles, proprietäres Storageprodukt im Augenblick unumgänglich.

Netzwerk: Grmpf!

Während in Sachen Storage schnell klar wird, dass der Standard mit I-SCSI un-brauchbar ist, dauert es bis zu dieser Erkenntnis in Sachen SDN etwas länger. Die SDN-Story von Open Stack basiert in der Standardkonfiguration auf Open Vswitch. Die Grundidee ist einfach: Alle Knoten innerhalb des Netzes sind über GRE-Tunnel miteinander verbunden, im Grunde entsteht also so etwas wie ein Full-Mesh-Netz. Open Vswitch sorgt auf den einzelnen Hosts über virtuelle Swit-ches mit eigenem Tagging dafür, dass

Abbildung 2: Ceph ist eine Alternative zum Open-Stack-Standard mit I-SCSI, die aber an Schwächen bei der Latenz leidet.

Abbildung 1: Praktisch kein namhaftes Unternehmen der IT-Szene ist aktuell nicht in Open Stack vertreten.

© A

aron

Hoc

kley

, CC-

by-S

A 2.

0

75

ww

w.lin

ux-m

agaz

in.d

e

Sysa

dm

inO

pen

Sta

ck07

/201

5

Page 3: Open Stack im Reality-Check Auf dem Gipfel

mit wie Midokura oder Cisco. Eine insge-samt überzeugende Lösung ist Contrail, das Juniper sich zwar einverleibt hat, aber nach wie vor als eigenes Team in der Firma bestehen lässt.

The Good, the Bad and the Ugly

Anders als Open Vswitch setzt Contrail – oder, in der offenen Variante, Open Contrail (Abbildung 3, [2]) – auf eine Vielzahl verschiedener Netzwerkpro-tokolle, die samt und sonders etabliert und gut bekannt sind. Einen speziellen Netzwerkknoten etwa sucht man in ei-ner Open-Contrail-Installation vergebens, denn jeder Hypervisor wird zum eigen-ständigen Netzwerkknoten für eine Viel-zahl von Instanzen. Fällt ein Hypervisor-Knoten aus, küm-mert sich Contrail zudem darum, dass die Anbindung der betroffenen VMs zur Außenwelt automatisch über an-dere Knoten hergestellt wird. Die Arbeit mit offiziellen IPs für VMs, die in Open Vswitch ebenfalls über die Netzwerk-knoten abgewickelt wird, machen die Hypervisors hier selbst – indem sie ein BGP-Announcement veröffentlichen, das zu sich selbst führt. Untereinander reden die VMs MPLS über GRE.Contrail besteht aus einer Vielzahl von Komponenten, darunter dem Dienst Ana-lytics, der umfassende Statistiken über die Netzwerknutzung anlegt und so die Ressourcenplanung erlaubt. Auch ein schickes Webinterface gehört dazu, über das sich die wichtigsten Contrail-Einstel-

lungen sinnvoll nutzen lassen. Sogar die Open-Stack-Anbindung steuert Juniper bei: Das Contrail-Plugin (Abbildung 4) lässt die Netzwerkkomponente von Open Stack, also Neutron, problemlos mit dem API von Open Contrail kommunizieren. Contrail wäre also der ideale Ersatz etwa für Open Vswitch, wenn …

Entwicklerchaos

… ja wenn die Software einen etwas weniger chaotischen Eindruck machen würde. Wer auf der Contrail-Entwickler-Mailingliste mitliest, gewinnt biswei-len den Eindruck, Releases seien eher Zufallsprodukte als geplante Vorgänge. Auch die Supportstrategie von Juniper ist wirr. Die fehlende Leitung schlägt sich aber vor allem im Chaos innerhalb von Contrail wieder: So benötigt Contrail etwa für Dienste wie DNSaaS einen ei-gens gepatchten Bind. Den lädt es sich beim eigenen Kompiliervorgang runter, Monkey-patcht daran herum und ver-packt das bei diesem Vorgang erstellte »named«-Binary anschließend in ein ei-genes Paket. Wenig überzeugt auch der Umstand, dass Contrail intern fast maßlos diverse Komponenten sowie Programmier- und Skriptsprachen einsetzt: XML über Thrift, C++, Python, Node.js, Java, Redis, Cas-sandra, Zookeeper, Kafka sind nur einige der Dinge, mit denen Contrail-Admins sich herumschlagen müssen. Die Lern-kurve ist also extrem steil, selbst erfah-rene Contrail-Admins bitten bisweilen bei den Entwicklern um Hilfe, weil sie ein bestehendes Problem partout nicht in den Griff bekommen.Mindestens so verstörend ist zudem die Tatsache, dass bei Contrail häufig der Eindruck von Stümperei entsteht – ob-gleich der Hersteller das eigentlich nicht als Ziel haben kann. Ein Patch für den »ifmap«-Client für Python, den Contrail als fixen Bestandteil enthält, macht das deutlich [3]: Weil in aktuellen Java-Versi-onen SSLv3 auf der Liste der verbotenen Algorithmen steht, stellten die Entwick-ler kurzerhand auf SSLv23 um. Jeden Security-Beauftragten fasst spätestens an dieser Stelle Entsetzen – auch wenn der »ifmap«-Teil von Contrail nicht nach au-ßen exponiert wird, sondern nur intern zur Anwendung kommt.

die Pakete einzelner Kunden voneinander getrennt sind. Auf zentralen Netzwerk-knoten findet die Anbindung nach außen statt; auch diese stehen unter der Fuchtel von Open Vswitch.Das Gemeine an Open Vswitch ist, dass sich kleine Clouds mit nur wenigen Hy-pervisor-Knoten und wenigen Kunden problemlos betreiben lassen. Wenn die Zahl der Compute-Nodes aber steigt oder mehr Kunden die Plattform in Beschlag nehmen, wird die Sache schnell unge-mütlich. Verschiedene Anbieter geben an, bereits bei 20 Knoten Probleme ge-habt zu haben, andere legen die Latte bei 50 Hypervisors oder mehr an. So oder so: Das Ende der Fahnenstange ist bei Open-Vswitch-basierten Setups absehbar. Das gilt übrigens auch für die Kommunikation nach draußen: Das Kon-zept eines einzelnen Netzwerkknotens für die Internetanbindung führt ganz au-tomatisch zum Entstehen eines Nadel-öhrs und eines Single Point of Failures (SPOF). Aktuelle Open-Stack-Versionen unterstützen zwar den Betrieb mehrerer Netzwerkknoten, doch funktioniert dann das automatische Rebalancing nicht. Fällt ein Netzwerkknoten aus, werden dessen Netze also nicht sofort auf andere Netz-werkknoten umgelegt.Open Vswitch ist daher als Netzwerk-komponente für Open Stack nur für kleine Schön-Wetter-Setups geeignet. Enterprise-Anforderungen lassen sich in Open Stack so aber nicht umsetzen. Als Alternative bieten sich gleich mehrere Lösungen verschiedener Hersteller an – VMware mischt im SDN-Markt genauso

Abbildung 3: Open Contrail ersetzt das mitgelieferte Open Vswitch sinnvoll, kommt aber mit einigen Ein-

stiegshürden.

Sysa

dm

in

76

ww

w.lin

ux-m

agaz

in.d

eO

pen

Sta

ck07

/201

5

Page 4: Open Stack im Reality-Check Auf dem Gipfel

Auch in Sachen SDN stehen proprietäre Alternativen bereit, die neben guter Tech-nik auch das gute Gefühl verkaufen, das Problem ausgelagert zu haben – nämlich an den Support-Anbieter. Doch einerseits fallen dann in der Folge horrende Sup-portgebühren an, andererseits verstärkt sich so einmal mehr der Eindruck, dass Open Stack alleine auf der Grundlage quelloffener Software nur bedingt sinn-voll zu betreiben ist.Die Analyse jedenfalls ergibt: Ganz so düster wie beim Thema Storage sieht es in Sachen SDN bei Open Stack zwar nicht aus, die Versprechungen der Anbieter, nur mit Open Vswitch ein funktionieren-des Cloud-Networking zu realisieren, las-sen sich in der Realität aber nicht durch Fakten untermauern.

Und noch mehr Probleme

Neben den beiden großen Baustellen SDN und SDS gibt es bei Open Stack mehr als genug kleinere, die technisch aber nicht minder problematisch sind. Ab Werk würde man von einer Open-Stack-Installation verschiedene Funktionen er-warten, einfach weil sie State of the Art sind: NTP-Unterstützung etwa oder zen-trales Logging und zentrales Monitoring. Oder dass alle im Setup vorhandenen Komponenten die eigene Funktionalität testen können, bevor sich die jeweilige Komponente überhaupt im Cluster an-meldet. Verschlüsselung in allen Teilen des Set ups wäre zum Beispiel genauso sinnvoll wie die Fähigkeit, innerhalb eines verteilten Systems rollende Upgrades zu erlauben – also das Upgrade von einer Open-Stack-Version auf die nächste. Schließlich ist funktionierendes Billing für den Betrieb oft unabdingbar, denn ein Anbieter will seinen Kunden die erbrachte Dienstleis-tung auch berechnen. All diese Features liefert Open Stack selbst schlicht nicht mit. Und dann ist da noch das Thema QA: Programmiersün-den sollten in einem System mit etlichen Entwicklern und mit eigener CI-Architek-tur eigentlich nur in begrenztem Umfang vorkommen. Doch bei Open Stack und den angrenzenden Projekten verhallt die Forderung ungehört.Ein konkretes Beispiel ist Keystone. Die Komponente ist in Open Stack für die

Authentifizierung von Nutzern wie der Dienste untereinander zuständig. Wie fast alle Open-Stack-Dienste hat Keystone Metadaten, die es in einer MySQL-Da-tenbank ablegt. Für den Zugriff auf ihre Metadaten-Datenbank nutzen die Dienste nicht direkt MySQL, sondern den Python-SQL-Wrapper SQL Alchemy.Offenbar trauten die Entwickler dem Braten aber nicht und implementierten rund um SQL Alchemy noch eine Art zweiten Wrapper – also einen Wrapper um den Wrapper –, der allerlei nutzlose Funktionalität nachrüstet. Darunter bei-spielsweise eine Ping-Funktion, die jede Sekunde testet, ob die Datenbank noch antwortet. Um im Rahmen eines Per-formance-Tests 250 Anmelde-Token pro Sekunde zu erstellen, prasseln schließ-lich mehrere Tausend Queries auf die MySQL-Datenbank nieder, die so unfrei-willig zum Flaschenhals wird. Für dieses spezielle Problem immerhin ist in Kilo eine Lösung vorhanden. Die Keystone-Lightweight-Tokens sind nicht mehr beständig, sodass der Zugriff auf MySQL gar nicht erst notwendig ist. Doch leider ist das nicht das einzige Beispiel für Code, der einem die Tränen in die Augen treibt.

Funktioniere ich? Egal!

Nova, die Computing-Komponente von Open Stack, ist in mehrere Subkompo-nenten gespalten – jede davon ist für eine

eigene Aufgabe zuständig. So läuft etwa »nova-compute« auf den Hyper visor-Knoten und startet dort VMs, wenn der Controller der Cloud sie entsprechend anweist. Leider übersieht das Programm dabei, dass es einen Pre-Flight-Check durchfüh-ren sollte, bevor es einen Computing-Knoten in Nova als „bereit“ anmeldet. Wenn sich per KVM keine VMs starten lassen, weil etwa das Kernelmodul dafür nicht geladen ist, wird das »nova-com-pute« nicht davon abhalten, den Rechner im Cluster zu registrieren. Das Ende vom Lied sind Nutzer, die statt einer laufenden VM nur krude Fehlermeldungen sehen.

Verrechnung geht auch nicht

Ein Beispiel für einen Totalausfall ist Ceilometer: Das Werkzeug war ganz am Anfang seiner Entwicklung als Park-uhr gedacht. Diese sollte sich einfach an die sowieso vorhandenen Notifica-tion Queues von Rabbit MQ hängen und dort mitschreiben, was sich im Cluster tut. Verschiedene Agents waren außer-dem auf den Hypervisor-Hosts dafür zuständig, Aufzeichnungen hinsichtlich verschiedener Verbrauchsparameter an-zufertigen.Praktisch ist Ceilometer nie auch nur ein ernsthaftes Projekt geworden. Ihm haftet der Ruf an, langsam und behäbig sowie instabil zu sein. Der erste Project

Abbildung 4: Das Contrail-Plugin für das Open-Stack-Dashboard lässt sich nur mit vielen Patches überhaupt

zur Kooperation bewegen.

77

ww

w.lin

ux-m

agaz

in.d

e

Sysa

dm

inO

pen

Sta

ck07

/201

5

Page 5: Open Stack im Reality-Check Auf dem Gipfel

Technical Lead (PTL) von Ceilometer und Quasi-Miterfinder Julien Danjou gab in einem Blogposting letztes Jahr bekannt, woran Ceilometer seiner Meinung nach gescheitert sei. Dabei erklärte er sich mitschuldig und legte kurz danach sein PTL-Amt nieder. Aus den Rewrite-Plänen, die Danjou damals öffentlich machte, ist bis auf den heutigen Tag nicht viel mehr entstanden als ein paar Proof of Concepts (Abbildung 5).

Was ist hier eigentlich los?

Die Liste von Was-zum-Teufel-Momenten im Leben eines Open-Stack-Admin ließe sich fast beliebig fortsetzen, doch ist da-mit niemandem geholfen. Wichtiger als die Feststellung, dass etwas nicht stimmt, ist die Frage nach dem Warum. Wie kann ein Projekt, das mit hinreichend viel Geld und sehr viel Manpower durch diverse große Unternehmen ausgestattet ist, derart chaotisch organisiert sein und so miese Resultate abliefern? Was läuft schief bei Open Stack? Die Antwort ist eigentlich denkbar simpel: Wer kein Ziel hat, der weiß auch nicht, wohin er fahren soll. Genau so präsentiert sich das Open Stack-Projekt aktuell: Wie ein Projekt, das kein konkretes Ziel hat. Ein Ansatz, um die nötigen Ziele zu schaffen, könnte dabei die obligatori-sche Frage nach dem Produkt sein, das Open Stack sein will. Dazu müsste die

sich vom „Vanilla Open Stack“ abzugren-zen. Red Hat, Suse, Canonical, HP und all die anderen Firmen haben also gar kein gesteigertes Interesse daran, eine solide Basisdistribution von Open-Stack-Komponenten zu haben – denn damit würden sie sich das Leben selbst nur schwerer machen.

Licht am Ende des Tunnels

Bei allen negativen Eigenschaften, die Open Stack aktuell ausmachen, ist eines unbestritten: Der Begriff der Open Source Cloud wird auf lange Zeit mit Open Stack verbunden bleiben, weil das Projekt die ganze PR seiner ehemaligen Konkurren-ten praktisch aufgesogen hat. Keine an-dere Software hat aktuell ein mit Open Stack vergleichbares Momentum. Alles Weinen hilft nicht, Open Stack ist aktuell ohne Alternative, wenn es um wirklich große ISPs geht.Doch ist noch nicht alle Hoffnung ver-loren. Folgt man dem Hype Cycle des IT-Analyse-Unternehmens Gartner [4], dann befindet sich Open Stack aktuell auf dem Gipfelpunkt seines eigenen Hype: Anbieter schüren demnach Erwartungen und Hoffnungen, die irrational sind. Dem Hype folgt meist ein eher unsanfter Ab-sturz in die Realität, also in den schnöden Alltag von IT-Firmen.Tatsächlich gibt es so manches Licht am Ende des Tunnels: Ceph löst zwar

Open Stack Foundation, die quasi die oberste Hüterin über das Wohlergehen des Projekts ist, allerdings die eigene Perspektive um ganze 180 Grad drehen. Denn aktuell erfolgt Entwicklung in Open Stack stets im Sinne der Hersteller: Die großen Unternehmen fragen sich, wel-che Art von Funktionalität in Open Stack nützlich wäre, um die eigenen Produkte so gut wie möglich zu unterstützen. Ge-nau diese Funktionalität entwickeln sie dann für den Open-Stack-Einsatz in ihrer kleinen Nische. Doch müsste es genau umgekehrt sein: Open Stack müsste sich die Frage stellen, welches Produkt ein ISP braucht, wenn er eine sinnvolle Cloudplattform betrei-ben will, und auf das Resultat dieser Überlegungen hinarbeiten. Gegenwärtig geht die Entwicklung aber andere Wege: Die Kilo-Release ist die erste Release nach dem Big-Tent-Schema. Vereinfacht aus-gedrückt ist die Idee hinter dem „großen Zelt“, dass so ziemlich jede Komponente Teil von Open Stack sein kann, solange sich deren Entwickler zur Einhaltung von wenigen grundsätzlichen Regeln verpflichten. Die meisten Unternehmen, die auf dem Markt für Open-Stack-Lösungen aktiv sind, unterstützen dieses Ansinnen. Das klingt absurd, ist aber nur folgerichtig: Wenn am Markt etliche Open-Stack-Pro-dukte aktiv sind, brauchen die einzelnen Produkte Alleinstellungsmerkmale, um

Glance Cinder Quantum

Horizon

Future Plugin

Billing & Rating System Keystone

Swift (v2) Nova

Compute Agent

CollectorData StoreAPI

Central Agent

Polls

Event Listener

Notification Events (Open-Stack-Common)

Cei

lom

eter

Eve

nt B

us

Abbildung 5: Ceilometer gilt mit seiner aktuellen Architektur als erledigt, doch die Arbeit am Rewrite kommt nicht voran.

Sysa

dm

in

78

ww

w.lin

ux-m

agaz

in.d

eO

pen

Sta

ck07

/201

5

Page 6: Open Stack im Reality-Check Auf dem Gipfel

nicht alle Probleme in Sachen Storage, ist aber dennoch ein guter Ansatz. Wer sich beharrlich durch Open Contrail beißt, bekommt auch ein funktionieren-des Netzwerk für die eigene Cloud. Der amerikanische Cloudanbieter Rackspace bietet in Form von Stacktach [5] eine Alternative zu Ceilometer, die diesem haushoch überlegen ist. Mit der Zeit wird sich bei den einzel-nen Open-Stack-Komponenten überdies auch die Erkenntnis durchsetzen, dass eine Kiste mit Schrauben und Ösen für

ISPs nur von begrenztem Nutzen ist. Sie wollen nicht mit einem Bausatz experi-mentieren, sondern brauchen ein fertiges Produkt. Auch das Thema Ausbildung spielt hier eine Rolle: Angesichts des Umfangs der einzelnen Open-Stack-Komponenten scheint es aktuell nur schwer möglich, das eigene Personal für Open Stack aus-zubilden. Stattdessen orientiert sich die Ausbildung stets an der eigenen, meist hochspezifischen Open-Stack-Installa-tion. Das Finden neuer Mitarbeiter mit entsprechender Vorerfahrung ist so aber fast unmöglich.Im Moment gilt für Unternehmen jeden-falls, dass Open Stack kein fertiges Pro-dukt ist – und ganz sicher nichts, das sich als Produkt eines Herstellers ohne großen Aufwand einfach so installie-ren ließe. Wenn Unternehmen für sich beschließen, die Einführung von Open Stack in Betracht zu ziehen, führt das in jedem Fall zu vielen Tests, viel Evaluation

und sehr viel Lernerei. Genau hier liegt die große Herausforderung, der Open Stack sich in nächster Zeit stellen muss. Das Problem ist die fehlende Produkt-definition und erst in zweiter Linie ein zu kleines Feature-Set aufgrund fehlender Komponenten.Festzustehen scheint: Open Stack wird eine dominierende Cloudlösung mit ho-hem Entwicklungsbedarf bleiben. Lang-weilig wird es nicht. (jcb) n

Infos

[1] Ceph:[http://www.ceph.com]

[2] OpenContrail:

[http://www.opencontrail.org]

[3] Ifmap-Patch:[https://github.com/

Juniper/contrail-third-party/blob/master/

ifmap-python-patch1.diff]

[4] Hype-CyclevonGartner:

[http://de.wikipedia.org/wiki/Hype-Zyklus]

[5] Stacktach:

[https://github.com/stackforge/stacktach]

Der Autor

Martin Gerhard Loschwitz

arbeitetalsCloudArchitect

beiSysEleven.Erbeschäf-

tigt sich dort intensiv mit

den Themen Open Stack,

Distributed Storage und

Puppet. Außerdem pflegt er in seiner Freizeit

PacemakerfürDebian.

79

ww

w.lin

ux-m

agaz

in.d

e

Sysa

dm

inO

pen

Sta

ck07

/201

5