Die Wolke ist derzeit bekanntermaßen in aller Munde. Die Idee dahinter ist nicht neu, hieß früher nur anders: Infrastructure as a Service ist nichts anderes als das, was Cloud-Provider heute feilbieten. Im Grunde braucht es gar nicht viel, um sich eine eigene Wolke zu basteln. Schon der letzte Teil der vorliegenden Serie kam mit Hardware von der Stange, DRBD, KVM und Pacemaker schließlich zu einem voll funktionstüchtigen Virtualisierungscluster.

An dieser Stelle von einer "Mini-Cloud" zu sprechen, mag dem einen oder anderen etwas zu dick aufgetragen vorkommen. Denn der vorgestellte Cluster erfüllt zwar die grundsätzlichen Anforderungen – im Rahmen der Ressourcen, die er zur Verfügung stellt, lässt sich Rechenleistung unkompliziert in die Hände Dritter übergeben. Aber bei genau diesem Detail liegt das Problem: Die gängigen Cloud-Setups sind immer auch skalierbar. Brauchen die Benutzer mehr Leistung, lässt sich diese schnell bereitstellen. Der Virtualisierungscluster aus dem Beispiel im letzten Heft stößt aber an Grenzen, wenn er seine Möglichkeiten ausgeschöpft hat. Und spätestens mit der maximalen Ausbaustufe der Hardware des Clusters ist auch das Ende der Fahnenstange erreicht.

iSCSI zu Hilfe

Cloud-Setups verwenden für gute Skalierung üblicherweise zentralen, geshareten Speicher und viele Virtualisierungsfrontends. Die holen sich den Speicher aus dem Shared Storage, binden ihn lokal ein und starten dann virtuelle Maschinen damit. Shared Storage bietet genau die Skalierbarkeit, die in solchen Setups nützlich ist: Neuer Speicher lässt sich bei Bedarf per Kommandozeile zuweisen oder entfernen, zusätzlicher Speicher ist durch neue Platten oder JBods leicht bereitzustellen. Im Vergleich zum Zwei-Knoten-Cluster mit Virtualisierungsfunktion ist die Fahnenstange bei solchen Setups sehr viel länger.

Typischerweise arbeitet