Mathias Rosenthal - Fotolia

Neutron, Nova und Heat: Skalierbarkeit bleibt größtes OpenStack-Problem

OpenStack gilt als skalierbare Plattform für große Private Clouds. Module wie Neutron oder Nova stehen der Skalierbarkeit aber noch immer im Weg.

Die Skalierbarkeit bleibt trotzt aller Fortschritte das Sorgenkind von OpenStack-Administratoren. Auch wenn OpenStack gerade für die Bereitstellung großer, hochskalierter Cloud-Cluster entwickelt wurde, gibt es hierbei noch immer einige Probleme. Viele der Dinge, die in kleinen Testumgebungen noch reibungslos funktionieren, lassen sich später nur schwer auf große Produktivsysteme übertragen.

Die Skalierbarkeit von OpenStack zu verbessern ist dabei keine kleine Aufgabe, viele Hersteller-Plug-ins und -Tools für OpenStack beispielsweise lassen sich gar nicht skalieren. Als Alternative stehen dann proprietäre Tools bereits, die sich wesentlich besser Skalieren lassen, aber gleichzeitig auch das Risiko des Vendor-Lock-in mit sich bringen.

Herausforderung OpenStack-Skalierbarkeit

Das Kernproblem bei der OpenStack-Skalierbarkeit scheint dabei das Netzwerk zu sein: OpenStack Neutron skaliert auf höchstens um die 30 Nodes. Keine wirklich befriedigende Leistung, wenn man sich im Vergleich dazu Public-Cloud-Anbieter mit ihren Millionen virtueller Maschinen auf zehntausenden Servern ansieht.

Zum Teil resultiert das Skalierbarkeitsproblem von Neutron aber auch aus den Netzwerkmodellen, die OpenStack Nova als Kernmodul von OpenStack unterstützt. Dadurch wird die Größe eines Clusters enorm eingeschränkt, während gleichzeitig das Erstellen und Auflösen von VLANs verzögert wird. In Testumgebungen ergibt sich damit meist noch kein Problem, gerade in großen Produktivsystemen aber schon, in denen jederzeit die Möglichkeit zur großflächigen horizontalen Skalierbarkeit gegeben sein muss.

OpenStack-Anbieter wie Mirantis oder HPE haben hierfür eigene Lösungen im Portfolio, während Software-definierte Netzwerke (SDN) gerade erste in Mode kommen und so kostengünstige Alternativen bieten.

Wer sich stattdessen für die schlüsselfertige Lösung einer verwalteten OpenStack-Distribution entscheidet, der sollte als Entscheidungskriterium daher auch die mögliche Skalierbarkeit im Auge behalten und sich möglichst Tests und Architekturdesigns zeigen lassen.

Die offiziellen OpenStack-Releases seit OpenStack Austin (2010) bis OpenStack Mitaka (2016).

Dabei ist aber auch die automatische Skalierung mit OpenStack Heat, über die sich automatisch nach Bedarf mehr virtuelle Maschinen starten lassen, ein großes Problem. Das Ceilometer-Modul überwacht dabei Workloads innerhalb der VMs und löst über Heat automatisiert das Erhöhen oder Absenken der VM-Anzahl aus. Allerdings gibt es viele OpenStack-Distributionen, die auf proprietäre Tools setzen, die wiederum in Mainstream-Modulen wie Heat oder Ceilometer fehlen.

Wird Ceilometer hierbei nicht bedacht, wird dadurch beispielsweise ein individuell angepasster Monitoring-Agent nötig. Das breite Spektrum an Einsatzgebieten von OpenStack führt dann fast zwangsweise dazu, dass die Interoperabilität beeinträchtigt wird. Die einzige Lösung hierfür besteht wohl im Warten darauf, dass das Ceilometer-Modul eine breitere Akzeptanz in OpenStack-Umebungen findet.

Weitere Artikel zu OpenStack:

5 Tipps für eine erfolgreiche OpenStack-Cloud.

Open-Source-Tools für eine einfachere OpenStack-Installation.

OpenStack Cinder: Open-Source-Block-Storage.

Auch das Load Balancing hat mit ähnlichen Problemen zu kämpfen. OpenStack Neutron bietet Load Balancing as a Service (LBaaS), das auch von Heat vollständig unterstützt wird. Manche Distributionen haben Neutrons LBaaS-Funktionalität aber nicht implementiert, wodurch man in diesem Fall nach anderen Lösungen Ausschau halten muss. Eine Möglichkeit hierfür wäre HAProxy, das als Open-Source-Software auf GitHub erhältlich ist.

Lösung der Netzwerkprobleme

Bei den Skalierungsproblemen von OpenStack spielen aber auch erweiterte Netzwerkoperationen eine Rolle, ewa das Verbinden virtueller Netzwerkfunktionen. Das Verifizieren dieser Verbindungen ist nicht gerade einfach und damit besteht die Gefahr, dass sich falsche Verbindungen auf externe Funktionen wie Firewalls auswirken. Genauso ist es oft schwer, neue Services in bestehende Serviceketten zu integrieren. Hierfür müssen die Serviceketten zunächst vollkommen aufgelöst werden, um sie anschließend wieder aufzubauen.

Sogenannte Startup Storms, die sich in gewisser Weise mit Boot Storms in VDI-Umgebungen vergleichen lassen, können auftreten, wenn eine Verbindung unterbrochen und dann wieder aufgenommen wird. Das Neuverbinden tausender Nodes über einen langsamen Verschlüsselungsprozess und verteilte Agents kann einen dann schon einmal eine ganze Nacht kosten.

Diese Netzwerkprobleme, die der OpenStack-Skalierbarkeit im Wege stehen, kommen zum Teil von Nova, aber beispielsweise auch vom Security-Modul Keystone, die einfach gewissermaßen Flaschenhälse darstellen. Eine sorgfältige Nova-Konfiguration kann diese Probleme aber durchaus lösen und Netzwerkprozesse wesentlich beschleunigen. So können IT-Abteilungen etwa die Anzahl an Nova API und Conductor Worker erhöhen, um Flaschenhälse beim Verbindungsaufbau abzufedern. Neutron-Probleme dagegen lassen sich oft mit OpenContrail lösen, einer effizienten, leichtgewichtgien Plattform, mit der sich Netzwerkservices verteilen lassen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Erfahren Sie mehr über Cloud Computing

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close