Die Eigenbau-Cloud

Wer auf ein Cloud-typisches Konfigurationsinterface verzichtet, kann sich mit den Bordmitteln jeder Linux-Distribution eine Mini-Cloud bauen, die in Sachen Hochverfügbarkeit wesentlich mehr Features hat als mancher Softwarestack von der Stange. Das alternative Konzept fußt auf der Idee, dass die typische Aufgabe einer Cloud darin besteht, Benutzern Ressourcen zum Betrieb virtueller Maschinen zu verschaffen, und dass es außerdem schnell und einfach geht, neue VMs zu erstellen.

Am Anfang steht immer der Storage. Damit virtuelle Maschinen in größerem Maßstab laufen können, muss Plattenplatz vorhanden sein. In einer typischen Cloud handelt es sich dabei fast zwangsläufig um Shared Storage. Nur der macht die Cloud später problemlos an gestiegene Bedürfnisse anpassbar – wovon der Admin besser von Anfang an ausgeht. Welche Art von geteiltem Speicher zum Einsatz kommt, ist der Präferenz des Admin sowie den finanziellen und zeitlichen Ressourcen überlassen.

Klassische SANs verfügen meist über ordentliche Frontends für die Administration und funktionieren dank aktueller FC-Treiber für Linux problemlos [15], verursachen bei der Anschaffung jedoch horrende Kosten und binden eine Plattform zumindest über den Zeitraum der Garantie (meist handelt es sich um fünf Jahre) an den Hersteller des SAN.

Wer einen kleineren Geldbeutel hat, greift auf DRBD [16] zurück: Zwei Server von der Stange, LVM und DRBD sorgen dafür, dass sich Platz nahtlos zuweisen lässt. In Kombination mit Pacemaker und einem der verschiedenen I-SCSI-Targets wird aus den Stangen-Rechnern ein echter Ersatz für SAN-Devices – der auch den Ausfall eines Knotens ohne Schwierigkeiten überlebt. Das Verwalten des verfügbaren Speichers passiert in diesem Falle nicht über ein Webinterface, sondern über die jeweiligen Kommandozeilen-Werkzeuge. Alternativ steht die Linux Cluster Management Console LCMC [17] zur Verfügung, mit der sich die Administration auch grafisch erledigen lässt.

Frontends, Monitoring, HA

Wo der Speicherplatz für virtuelle Maschinen herkommt, ist damit klar – es fehlen aber noch die Server, auf denen die virtuellen Maschinen tatsächlich laufen. Bei der hier vorgestellten Mini-Cloud unterliegen Admins im Hinblick auf die Virtualisierung keinen Zwängen. Sämtliche mit einem I-SCSI-Terminator ausgestatteten Linux-Distributionen sind mögliche Zielsysteme, genauso aber auch VMware oder Citrix Xen Server. Vorteilhaft ist freilich der Einsatz von Linux-Distributionen, die mit Pacemaker [18] ausgestattet sind.

Dann lassen sich nämlich auch die Frontends in die Clusterverwaltung des SAN-Ersatzes aufnehmen. Pacemaker kümmert sich darum, dass tatsächlich all jene VMs laufen, die auch laufen sollen. Stürzt ein Virtualisierungsfrontend ab, merkt Pacemaker das und startet die fehlenden VMs auf einem der anderen Hosts. Mit der eingebauten Monitoringfunktion von Pacemaker lässt sich dieses Prinzip so weit aufbohren, dass es bei einzelnen VMs auch prüft, ob die Prozesse tatsächlich da sind.

Unverzichtbar ist in einem Cloudsetup dennoch auch ein leistungsfähiges und umfassendes externes Monitoringsystem. Es stellt sicher, dass Admins von Ausfällen einzelner Rechner zumindest frühzeitig erfahren. Verfügen die Nodes der eigenen Virtualisierungsplattform über Managementkarten mit IPMI-Schnittstelle, lassen sie sich auch direkt aus Nagios heraus rebooten. Über Shellskripte lässt sich sogar eine nahezu automatische Verwaltung der virtuellen Maschinen realisieren.

Über die gleiche Monitoringfunktion, die per IPMI den Reboot durchführt, wäre es freilich auch möglich, die virtuellen Maschinen wieder zu starten, die einem bestimmten Node zugeordnet sind. Der Aufwand, ein solches Setup nachzubauen, ist aber beträchtlich.

Auch die Cloudkunden haben die Möglichkeit, sich durch die typischen Tools des Linux-Cluster-Stack innerhalb ihrer virtuellen Maschinen zu schützen. Dazu müssen sie jedoch mindestens zwei virtuelle Maschinen zur Verfügung haben – und diese sollten nicht auf demselben Host laufen. Neben einer gemeinsamen, alternierenden Service-IP bedarf es noch der typischen Werkzeuge Corosync oder Heartbeat für die Kommunikation der Clustermanager in den VMs, Pacemaker als Cluster Resource Manager und möglicherweise auch DRBD, um sicherzustellen, dass beide virtuellen Maschinen stets die neuesten Daten erhalten.

Eine ausführliche Anleitung vom Autor dieses Artikels, die sich mit der Einrichtung von Pacemaker beschäftigt, findet sich unter [19] und [20], zwei weitere Artikel in der Titelstrecke dieser Linux-Magazin-Ausgabe schildern den Eigenbau-Ansatz von mehreren Seiten.