RAID-Technologie verspricht höhere Performance und mehr Sicherheit beim permanenten Speichern von Daten. Die ADMIN-Redaktion gibt einen Überblick über ... (mehr)

Was es sonst noch braucht

Zu jeder OpenStack-Installation gehören zwei Komponenten, die nicht unmittelbar Teil von OpenStack sind: MySQL und RabbitMQ. MySQL setzen sämtliche OpenStack-Komponenten mit Ausnahme von Swift ein, um ihre internen Datenbanken zu pflegen. Weil alle OpenStack-Komponenten in Python geschrieben sind, haben die Entwickler auf das Python-Modul »sqlalchemy« gesetzt, um die Datenbankzugriffe aus ihren Applikationen heraus umzusetzen. Zwar unterstützt »sqlalchemy« auch andere Datenbanken wie PostgreSQL, nahezu sämtliche OpenStack-Installation dürften gegenwärtig allerdings auf MySQL bauen – was der offiziellen Dokumentation entspricht.

RabbitMQ ist der Teil des Setups, der insbesondere Nova und Quantum dazu dient, die Kommunikation über alle Knoten des Virtualisierungsetups hinweg zu realisieren. Wer Erlang nicht mag oder mit RabbitMQ bereits schlechte Erfahrungen gemacht hat, kann alternativ auch auf eine andere Umsetzung des AMQP-Standards vertrauen: Auch mit Qpid funktioniert OpenStack sehr gut.

Das leidige Thema Hochverfügbarkeit

Die vorangegangene Aufzählung hat bewiesen: Sämtliche Komponenten, die in einer modernen Wolke nötig sind, bietet OpenStack grundsätzlich an. Ein Test des Autors dieses Artikels im Linux-Magazin 12/11 [2] förderte damals jedoch einen echten Makel zutage. Denn im Hinblick auf Hochverfügbarkeit schlug die junge Cloud-Umgebung sich alles andere als wacker. Faktisch fehlten nutzbare HA-Lösungen für OpenStack damals vollständig: Ein abgestürzter Hypervisor, der etliche VMs mit in den Abgrund gerissen hat, war der Umgebung seinerzeit genauso gleichgültig wie die Tatsache, dass eine der Kernkomponenten – Nova, Glance, Keystone & Co. – das Zeitliche gesegnet hatten.

Dabei sind brauchbare Werkzeuge vorhanden, um auf Linux-Systemen Hochverfügbarkeit zu gewährleisten. In Form des Linux-HA Cluster-Stacks steht ein kompletter HA-Werkzeugkasten parat, der im Kontext von OpenStack nur auf seinen Einsatz wartete.

Ein knappes Jahr nach dem ersten Test stellt sich die Situation dann auch nicht mehr ganz so trist dar: Spezifische Resource Agents, die die einzelnen OpenStack-Teile in Pacemaker nutzbar machen, stehen mittlerweile in Form des »openstack-resource-agents« -Repositories zur Verfügung [3] .

Dem Aufruf des Autors dieses Artikels, der die ersten Agents für »keystone« und die beiden Teile von Glance entwarf [4] , folgten insbesondere die beiden aus Frankreich stammenden Entwickler Emilien Macchi und Sebastien Han, die nach und nach Agents für die anderen Dienste beisteuerten. So ist es nun kein Problem mehr, alle Kern-Dienste von OpenStack durch Pacemaker verwalten und überwachen zu lassen ( Abbildung 5 ). Hinzu kommt die Tatsache, dass die einzelnen Dienste durchaus auch verteilt laufen können: Nicht alle Kern-Komponenten müssen auf dem gleichen System wohnen, solange sie per Netzwerk miteinander verbunden sind. Theoretisch wäre es sogar denkbar, Instanzen aller Kern-Projekte auf jedem Knoten einer OpenStack-Wolke zubetreiben, solange diese auf dieselbe hochverfügbare MySQL-Datenbank und auf denselben RabbitMQ Zugriff haben.

Abbildung 5: Neben den Agents für Keystone und Glance stehen mittlerweile auch für alle anderen Open-Stack-Komponenten Resource Agents für Pacemaker bereit.

Noch nicht ganz so rosig verhält es sich hingegen mit Hochverfügbarkeit für virtuelle Maschinen. Bei dieser Frage prallen zwei Philosophien hart aufeinander, nämlich die amerikanische und die europäische Idee dessen, wofür eine Cloud eigentlich gut ist.

Denn in Amerika gilt die Wolke vor allem als Werkzeug zum Schaffen von massiv skalierenden IT-Setups. Ein klassisches Beispiel ist der berühmte Versandhändler, der zur Weihnachtszeit deutlich mehr Last abfedern muss, als während des übrigen Jahres. Wenn er mit mehr Last zurechtkommen muss, startet er einfach neue virtuelle Maschinen, auf die weitere Last verteilt wird. Die Voraussetzung dafür, dass dieses Prinzip funktioniert, ist, dass einzelne VMs keine veränderlichen Daten enthalten, sondern dass sämtliche virtuellen Instanzen stets aus dem gleichen Image stammen. Und wenn, so die Logik, alle VMs aus dem gleichen Image bestehen, dann fällt es nicht weiter ins Gewicht, wenn eine einzelne virtuelle Maschine den Geist aufgibt. Denn im Handumdrehen lässt sich ja aus dem laufenden Betrieb heraus eine neue VM schaffen, welche die alte, nun ausgefallene VM vollständig ersetzt.

Im europäischen Kontext liegen die Dinge anders. Hierzulange verbinden Anbieter von IT-Infrastruktur mit der Einführung einer Cloud-Lösung fast immer das Stichwort Rechenzentrumskonsolidierung. Gemeint ist, das viel Blech durch weniger Blech ersetzt wird, das die vormals physischen Systeme dann in Form virtueller Maschinen weiter betreibt. Die vormals erwähnte Scale-Out-Logik funktioniert hier nicht mehr: Spezifische Kunden-Systeme sind nicht generisch, enthalten veränderliche Daten und lassen sich nicht zu einem späteren Zeitpunkt problemlos durch eine neue Instanz aus dem frischen Image ersetzen. In diesem Szenario schmerzt der Ausfall einer VM oder eines Hypervisors mit vielen VMs deutlich heftiger.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023