HA-Workshop, Teil 5: Zentrales Cloud-Storage dank Pacemaker und iSCSI

Die Speicherwolke

Diese Fortsetzung des HA-Workshops setzt das Konzept des letzten Teils auf neue Füße und sorgt für die Skalierbarkeit. Dreh- und Angelpunkt: ein SAN-Drop-In mit DRBD, iSCSI und Pacemaker.
Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

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 Shared Storage mit Fibre Channel. Das belastet den Admin mit den Nachteilen, die solche SANs üblicherweise haben: Hohe Anschaffungskosten, Vendor Lock-in und die Verwendung eines nicht-ubiquitären Protokolls sind nur drei davon. Kleinere Betriebe, die auf der Suche nach einer günstigen Lösung für eine private Cloud sind, haben selten das Budget für ein typisches SAN samt der meist benötigten Fibre-Channel-Hardware.

Zentraler Speicher für eine skalierbare private Wolke lässt sich aber auch ohne SAN, dafür mit Standard-Hardware und Standard-Netzwerkhardware (1 GBit oder 10 GBit) realisieren. Die Komponenten, die dafür notwendig sind, hat die HA-Serie in den letzten zwei Ausgaben bereits vorgestellt: DRBD kümmert sich im Zwei-Knoten-Storagecluster um die Redundanz der eigentlichen Daten. Pacemaker managed mithilfe von Heartbeat 3 oder Corosync den Cluster. Bleibt noch der Weg zwischen Storage und Virtualisierungsfrontend: Hier ist Ethernet als Transport gesetzt, und die Kommunikation auf dem Kabel übernimmt iSCSI. Voila: Fertig ist das Jedermann-SAN.

Die passende Hardware

Das vorgestellte Setup hat zwei Dimensionen in Sachen Hardware. Einerseits gilt es, die Hardware für den iSCSI-Cluster ordentlich zu dimensionieren, es müssen aber auch die Virtualisierungsfrontends genug Dampf unter der Haube haben. Was den iSCSI-Cluster angeht, gilt: CPU ist von geringerem Interesse als RAM und Speicher; Letztere sollten ausreichend vorhanden sein. Sinnvoll ist es, von Anfang an Rechner einzusetzen, die über zusätzliche Controller zu einem späteren Zeitpunkt mit JBODs erweiterbar sind. Zum Flaschenhals wird gern auch die Backplane der Server selbst; im Idealfall sind die Platten über mehrere Backplanes angebunden. In Sachen Netzwerkanbindung empfiehlt sich 10 GBit; Controller hierfür sind schon unter 200 Euro zu bekommen ( Abbildung 1 ). Der Crosslink zwischen den zwei Knoten des Clusters sollte genauso über eine 10-Gbit-Verbindung realisiert sein wie die Anbindung des iSCSI-Clusters an den Rest des Netzwerks. Das setzt freilich passende Switches voraus; die meisten Mittelklasse-Switches erlauben es, 10-Gbit-Funktionen über entsprechende Zusatzmodule nachzurüsten. Insgesamt liegt ein Zwei-Knoten-Cluster mit diesen Eigenschaften selbst bei größeren Mengen an Plattenplatz trotzdem weit unter dem Preis, den ein SAN mit Fibre Channel hätte. Im Hinblick auf die Virtualisierungsfrontends gilt, dass sie eine starke CPU und viel RAM benötigen. 10 Gbit auf den Frontends ist toll, aber nicht zwingend notwendig. Dass die virtuellen Maschinen, die auf einer Kiste laufen, zusammen permanent 75-85 Megabyte konsumieren, die mit einer 1-GBit-Verbindung erreichbar sind, ist unwahrscheinlich. Außerdem lässt sich die Kapazität der Netzwerkanbindung mit Bonding noch entsprechend erhöhen. Plattenplatz ist bei den Frontends hingegen ein zu vernachlässigender Faktor, denn ihre wichtigen Daten beziehen diese ohnehin vom iSCSI-Cluster.

Abbildung 1: 50 GBit wie zwischen diesen optischen Intel-Adaptern müssen es nicht sein, aber 10 wären sehr gut.
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