Die eigene AWS-kompatible Cloud mit Eucalyptus

Aus ADMIN 05/2013

Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Dienstevielfalt

Auf welchen der Knoten welche Maschinen laufen, entscheidet das Frontend. Es stellt zudem die Weboberfläche bereit und nimmt die Befehle des Administrators entgegen. Tatsächlich besteht auch das Frontend aus mehreren weiteren, einzelnen Diensten, die der Kasten »Fünf ist Trumpf« vorstellt. Dem Frontend sollte man ebenfalls einen eigenen Rechner spendieren. Eine erste kleine Cloud besteht somit aus zwei oder mehr Node-Controllern, die die eigentliche Arbeit verrichten und einem weiteren Rechner mit dem Frontend (wie in Abbildung 2 ). Dank der Trennung in die Komponenten kann man später die Cloud sukzessive vergrößern, indem man zum Beispiel weitere Node Controller hinzufügt.

Fünf ist Trumpf

Eucalyptus besteht aus fünf Komponenten. Jeder von ihnen läuft als Webdienst und greift auf die Funktionen der anderen Dienste zurück ( Abbildung 2 ).

Node Controller (NC): Auf den Knoten arbeitet der sogenannte Node Controller (kurz NC). Er startet, stoppt und verwaltet die auf seinem Rechner laufenden virtuellen Maschinen.

Cluster Controller (CC): Mehrere Knoten fasst der Cluster Controller (kurz CC) zu einem Cluster zusammen. Der Cluster Controller entscheidet darüber, welche virtuelle Maschine auf welchem Knoten startet und verwaltet das Netzwerk, in dem die virtuellen Maschinen hängen.

Cloud Controller (CLC): Die Befehlsgewalt über die einzelnen Cluster hat der Cloud Controller (kurz CLC). Er bastelt aus den Clustern die eigentliche Cloud, trifft alle übergeordneten Entscheidungen und nimmt die Anfragen der Benutzer entgegen. Er stellt auch die Weboberflächen bereit.

Storage Controller (SC): Der Storage Controller fasst Speicherplatz zu sogenannten Volumes zusammen, die dann wiederum eine virtuelle Maschine einbinden oder als Block Device ansprechen kann. Der Funktionsumfang entspricht dabei Amazons Elastic Block Store (EBC).

Walrus: Schließlich stellt die Komponente namens Walrus noch einen zu Amazon Simple Storage Service (S3) kompatiblen Speicherdienst bereit. Wie das Vorbild legt er Daten in sogenannten Buckets in der Cloud ab. Walrus kann man zum einen über die erwähnten Kommandozeilenwerkzeuge nutzen oder aber auch aus den virtuellen Maschinen heraus in Anspruch nehmen.

Abbildung 1: Eucalyptus besteht aus mehreren Einzelteilen, die aufeinander aufbauen.

Abbildung 2: Für eine erste kleine Cloud genügen drei physische Rechner und ein Client für den Zugriff. Die Node Controller übernehmen die eigentliche Arbeit, das Frontend koordiniert sie.

Gordische Knoten

Das FastStart-Installationsmedium in Form eines kleinen ISO-Images erhalten Administratoren unter [3] . Das ISO-Image dient nur als Boot-Medium und holt sowohl ein komplettes CentOS 6 als auch die Eucalyptus-Pakete aus dem Internet nach. Die Rechner, die später die Cloud bilden sollen, müssen folglich an das Internet angebunden sein.

Zunächst startet man das FastStart-Image auf den Rechnern, die später als Node Controller arbeiten sollen. In Abbildung 1 würde man das Image auf den Rechnern mit der IP-Adresse 192.168.100.11 und 192.168.100.12 starten. Im Bootmenü fällt die Entscheidung für den Punkt »Install CentOS 6 with Eucalyptus Node Controller« . Das Angebot, das Installationsmedium zu prüfen, lässt sich mit »Skip« überspringen. Anschließend geht es mit »Next« zur Wahl der Sprache, gefolgt von der Tastaturbelegung.

Eine virtuelle Maschine starten und stoppen kann man auch auf der Kommandozeile mit der Werkzeugsammlung Euca2ools. Viele Linux-Distributionen bieten sie in ihren Repositories an, auch auf dem Frontend-Rechner sind sie bereits installiert. Um die Euca2ools einsetzen zu können, muss man sich zunächst als rechtmäßiger Benutzer der Cloud ausweisen. Dazu holt sich der Adminstrator zunächst sein Credentials-Paket vom Frontend ab:

usr/sbin/euca_conf --get-credentials admin.zip
unzip admin.zip
source eucarc

Den ersten Befehl muss man als Benutzer root ausführen, der letzte Befehl setzt ein paar Umgebungsvariablen für die Euca2ools. Anschließend erzeugt man noch ein Schlüsselpaar, im Folgenden unter dem Namen »eucatest« . Der private Schlüssel landet dabei in der Datei »eucatest.private« :

euca-add-keypair eucatest > eucatest.private
chmod 0600 eucatest.private

Jetzt kann man sich zunächst alle verfügbaren Betriebssystem-Images anzeigen lassen, die man in einer virtuellen Maschine starten kann:

euca-describe-images

Aus dem dann ausgespuckten Textgewirr muss man sich das entsprechende Image heraussuchen. Jedes Betriebssystem-Image besteht aus drei Dateien: dem Kernel, einer Ramdisk und dem eigentlichen Image. Letzteres erkennt man am Kürzel ».img« im Dateinamen. Um eine virtuelle Maschine zu starten, benötigt man das Image. Dessen Zeile findet man am schnellsten anhand der Beschreibung in der zweiten Zeile. Wichtig ist dabei die interne Identifikationsnummer, die hinter »IMAGE« steht. In Abbildung 9 heißt das Image mit dem kleinen CentOS-6-System »emi-AF4736C9« . Diesen Namen behält man jetzt im Hinterkopf. Alle möglichen virtuellen Computermodelle spuckt der folgende Befehl aus:

Abbildung 9: Die Arbeit mit den Euca2ools ist nicht so eingängig wie die Benutzeroberflächen.

euca-describe-availability-zones verbose

In der zweite Spalte stehen die Namen der virtuellen Computermodelle, ihre Hardware-Konfiguration folgt auf der rechten Seite. So hat der Computer mit dem Namen »m1.small« nur eine CPU und 256 MByte Hauptspeicher. Interessant ist dabei auch die Spalte »free / max« : Die Zahl unter »free« verrät, wieviele virtuelle Maschinen man selbst von diesem Modell noch anwerfen könnte, während »max« die maximal mögliche Anzahl der Maschinen nennt. Sobald man sich für ein Modell entschieden hat, kann man die virtuelle Maschine starten:

euca-run-instances -k eucatest emi-AF4736C9 -t m1.small

Eucalyptus zeigt jetzt die gleiche Statuszeile, wie man sie auch in der User Console zu Gesicht bekommt. Wenn noch keine IP-Adressen angegeben sind, kann man nach ein paar Sekunden den Zustand wieder erneut abrufen:

euca-describe-instances

Die interne Identifikationsnummer neben »INSTANCE« sollte man sich unbedingt notieren (sie beginnt mit einem »i-« ), um sie mit bestimmten Befehlen zu benutzen:

euca-terminate-instances i-45C44614

Damit kann man eine laufende Instanz später wieder abschalten.

Anschließend richtet man die Netzwerkkarte ein ( Abbildung 3 ). Wer den Rechnern der Cloud ihre IP-Adressen per DHCP zuweist, muss sicherstellen, dass sie immer dieselbe Adresse erhalten, die dynamische Zuweisung unterstützt Eucalyptus nicht. »Weiter« geht es zu den Zeiteinstellungen, anschließend folgt das Passwort für den Benutzer »root« und die Festplattenaufteilung. Da die Node Controller viel Speicher benötigen, sollte man dem Assistenten den »Gesamten Platz« überlassen – was gleichzeitig die Festplatte komplett löscht. Nach dem Abnicken der Sicherheitsfrage teilt Eucalyptus die Festplatte dann nach eigenen Vorstellungen auf, holt das System aus dem Internet und richtet es ein. Dies kann je nach Rechnergeschwindigkeit einige Zeit benötigen. Abschließend muss man das System ohne das FastStart-Medium neu starten und sich als Benutzer »root« einloggen.

Abbildung 3: Bei der Einrichtung der Netzwerkkarten kann man über Advanced Network Configuration auch den unter Linux allseits bekannten Network Manager zu Hilfe rufen.

Das jetzt startende Konfigurationsskript möchte als Erstes wissen, über welche Netzwerkschnittstelle der Rechner später mit dem Frontend erreichbar ist ( Abbildung 4 ). Die Eingabetaste übernimmt den Vorschlag. Bei der anschließenden Einrichtung richtet das Skript eine Netzwerk-Bridge ein (in der Regel heißt sie »br0« ), an die alle virtuellen Maschinen andocken und nach draußen kommunizieren. Per »ifconfig« kann man anschließend prüfen, ob die Netzwerkschnittstellen korrekt erkannt und zugeordnet wurden. Sollte man versehentlich die falsche Netzwerkschnittstelle erwischen, lässt sich das Einrichtungsskript per »/usr/local/sbin/eucalyptus-nc-config.sh« jederzeit erneut anwerfen. Die Rechner mit den Node Controllern können weiterlaufen.