Die Cloud-Computing-Plattformen Scalr und Rightscale

© BamRob, photocase.com

Auf dem Bauernhof

In der Theorie funktioniert in der Cloud alles von selbst. In der Praxis skalieren Anwendungen aber nicht so ohne Weiteres. Dienste wie Scalr und Rightscale wollen dabei helfen.
Egal, um welchen Dienst es sich dreht, den Benutzern geht es immer zu langsam. Der Schwerpunkt des ADMIN-Magazins 05/2011 verrät, mit welchen Tools man ... (mehr)

Als die neue Mode des Cloud Computing auf einmal in aller Munde war, probierten die meisten die neue Technologie auf Amazons EC2 aus. Dabei war es nicht schwer, mehr Speicherplatz zu bekommen oder auch einmal eine neue Instanz hinzuzubuchen, um ein neues Feature auszuprobieren. Automatisch skalieren ließen sich die eigenen Anwendungen damit aber nicht.

Dabei besteht der Witz des Cloud Computing gerade darin, dass sich Anwendungen quasi selbstständig und automatisch skalieren. Die erste Generation von Cloud-Diensten stellte aber eher einzelne Server-Instanzen zur Verfügung, deren Management noch einmal einen extra Aufwand bedeutete.

Automatik-Cloud

Software wie Scalr [1] und Rightscale [2] verschaffen in dieser Hinsicht mehr Komfort. Anders als die Low-Level-APIs und -Tools von Amazon, Rackspace und anderen ermöglichen Scalr und Rightscale das Management einer Cloud als Einheit, ohne sich um die einzelnen Elemente kümmern zu müssen. Je nach den aktuellen Anforderungen, fügen sie dabei Cloud-Ressourcen hinzu oder ziehen sie wieder ab, wenn sie gerade nicht mehr gebraucht werden.

Scalr überwacht die einzelnen Server und ersetzt ausgefallene Knoten selbstständig. Um Datenverlust zu verhindern, legt es selbstständig Backups im Amazon-Storage EBS an. Schließlich hilft Scalr auch Kosten sparen, indem es bei geringer Auslastung nicht gebrauchte Server abschaltet. Mit anderen Worten: Scalr stellt Anwendern ein einheitliches virtuelles System zur Verfügung, im Scalr-Jargon auch Farm genannt.

Damit lassen sich selbst geschriebene Skripte ersetzen, die häufig eher schlecht als recht diese Aufgabe übernehmen. Anwender können sich also auf ihren eigenen Code konzentrieren statt auf das Management der Cloud. Dabei skaliert Scalr nicht nur den Webserver, sondern auch die Datenbank, was nach Meinung des Herstellers der am schwierigsten zu skalierende Teil einer Webanwendung ist.

Scalr ist eine Open-Source-Anwendung [3], aber auch als Service erhältlich. Wenn Sie Scalr ausprobieren möchten, sollten Sie sich einen Entwickler-Account besorgen [4].

Gehöft

Mit einem Account ausgestattet, kann es losgehen. Zuerst legen Sie über den Menüpunkt »Server Farms« im Webinterface eine neue Farm an. Wählen Sie einen Speicherort in der Amazon-Cloud EC2 und drücken Sie auf »Next« . Scalr erlaubt es, vordefinierte Rollen auszuwählen, die bestimmten Einsatzzwecken der jeweiligen Cloud entsprechen. Sie stehen auf der folgenden Seite zur Verfügung (Abbildung 1). Nach dem Speichern lässt sich die Cloud einfach starten. Denken Sie dabei daran, dass Amazon den Betrieb jeder Instanz in Rechnung stellt, auch wenn sie nur ein paar Minuten läuft!

Abbildung 1: Über Rollen lassen sich einzelnen Farmen spezifische Funktionen zuweisen.

Eine Scalr-Instanz sieht aus wie ein Server, verhält sich wie ein Server, ist aber eben kein Server. Die Instanzen sind nur flüchtig und verbrauchen nur so wenig Ressourcen wie nötig. Wenn eine Instanz abstürzt, brauchen Sie sich darum nicht zu kümmern. Die Idee dahinter ist, eine virtuelle Maschine von der Stange zu nehmen, darauf mit eigenen Skripten die gewünschte Software zu installieren und sie dann in der Cloud laufen zu lassen.

Ein einfaches Skript legen Sie bei Scalr mit »Scripts« und dann »Add New« an. Nennen Sie das Skript beispielsweise »Tell me your name« und geben Sie den folgenden Code ein:

#!/bin/bash
echo "I am a %role_name%" | mail E-Mail-Adresse-s "Checking in"

Mit »OK« schließen Sie das Ganze ab. Ist das Skript gespeichert, wählen Sie im Skript-Menü »View All« und dann »Execute« aus dem »Options« -Dropdown auf der rechten Seite. Auf der Ausführungsseite klicken Sie auf »Execute« , um das Skript auf der Farm auszuführen. Einen Augenblick später sehen Sie die Ausgabe im Log, und wenn es Probleme damit gab, die Mails zu verschicken, können Sie das auch hier nachlesen.

Im nächsten Schritt soll das Skript eine etwas sinnvollere Aufgabe übernehmen. Ändern Sie es dazu folgendermaßen ab:

#!/bin/bash
apt-get -y install apache2
echo "I am a %role_name% and I have apache installed now"| mail E-Mail-Adresse -s "Installed Apache"

Zurück im Farm-Menü öffnen Sie im Navigationsbaum »Shared Roles« und dann »Application Servers« . Wählen Sie dort »app64« aus. Die dabei angezeigten Reiter beziehen sich auf diese Rolle. Öffnen Sie das »Scripting« -Tab und dann den Eintrag »OnHostUp« (Abbildung 2).

Abbildung 2: Ein Skript für den Systemstart wählen Sie im Menüpunkt OnHostUp aus.

Wenn die Farm schon läuft, starten Sie sie neu und lassen Sie sich von jeder Instanz ihre Identität mitteilen. Wie der Name nahelegt, laufen die unter »OnHostUp« hinterlegten Aktionen ab, wenn ein Knoten startet. Wenn Sie beispielsweise dem Apache-Webserver eine bestimmte Konfiguration geben wollen, können Sie das so machen:

cat <<-EOF >/etc/apache2/conf.d/our.conf
# This is our standard config...
EOF

Um eine komplette Website beim Start zu installieren, packen Sie sie in eine Tar-Datei und legen Sie sie irgendwo ab, von wo sie sich einfach herunterladen lässt. Schreiben Sie dann ein Skript, das etwa so aussieht wie Listing 1.

Listing 1

Webserver-Konfiguration

 

Binden Sie beim Booten den Dienst an die Rolle »app« und starten Sie die Farm neu. Alternativ zur obigen Methode können Sie den Website-Code auch sicher mit Amazons S3-Dienst speichern und ihn mit »s3cmd« herunterladen:

s3cmd get s3://your-bucket/your-code.tgz

Die meisten Anwendungen müssen noch ein bisschen angepasst werden, bevor sie einfach aus einem Tar-Archiv ausgepackt funktionieren. Achten Sie darauf, alle absoluten Konfigurationsparameter, wie etwa IP-Adressen, Pfade und so weiter, durch relative zu ersetzen. Stellen Sie sicher, dass die Webanwendung von jedem Ort aus funktioniert, dann wird sie auch laufen, wenn sich eine Instanz ändert.

Dynamisches DNS ist ein leistungsfähiges Werkzeug für elastische, selbstheilende Cloud-Installationen. Weil eine neue Instanz eine neue IP-Adresse erhält, kann es leicht zu Problemen beim Datenbankzugriff kommen. Woher sollen zum Beispiel replizierte Slaves wissen, wie die IP-Adresse eines neuen Masters lautet?

Die Lösung besteht darin, dem Master einen Hostnamen zu geben, beispielsweise »db.cloud.example.com« , diesem aber im DNS einen A-Record für die interne IP-Adresse zuzuweisen. Dann können sich alle Slaves und Clients mit »db.cloud.example.com« verbinden. Dynamisches DNS kommt dann ins Spiel, wenn sich die IP-Adresse ändert. Wenn eine Instanz beendet wird und eine neue startet, soll sich der A-Record ändern. Das lässt sich mit einer einzigen Zeile bewerkstelligen:

curl 'http://www.dnsmadeeasy.com/servlet/updateip?username=myuser&password=mypassword&id=99999999&ip=123.231.123.231'

In diesem Fall hilft bei der dynamischen Änderung der DNS-Einträge der Dienst DNS Made Easy [5]. Zu diesem Zweck gibt es eine Reihe von Alternativen im Internet. Gewiefte Administratoren können dynamische Updates auch auf dem eigenen Server konfigurieren und müssen dazu unter anderem kryptographische Schlüssel erzeugen.

Das Start-Skript für die Datenbank sieht fast genauso aus wie das des Webservers, enthält aber noch eine zusätzliche Zeile (Listing 2). Es installiert MySQL, lädt die SQL-Dateien herunter, installiert sie und startet den MySQL-Server neu. Schließlich aktualisiert es den Nameserver-Eintrag, damit der Webserver sich mit der Datenbank verbinden kann.

Listing 2

Datenbank-Start

 

Beruhigend an diesem Aufbau ist, dass auch dann nichts Gravierendes passiert, wenn der Datenbank-Master-Server ausfällt. Selbst wenn er abstürzt, ist die Farm schlimmstenfalls ein paar Minuten lang nicht mehr erreichbar.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
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

Google+

Ausgabe /2019