Der Online-Händler Amazon hat sein Angebot bereits seit einiger Zeit um IT-Services zur Miete erweitert. Zu den Diensten, die wir bereits in InfoWeek 02/2008 vorgestellt haben, gehören mit der Elastic Compute Cloud (EC2) und dem Simple Storage Service (S3) virtuelle Rechnerinstanzen sowie Online-Speicher. Bezahlt wird nach Verbrauch – sprich Rechenzeit, belegten Speicherplatz oder Bandbreite. Gleichzeitig kann man fast unbegrenzt viele Rechnerinstanzen starten respektive Online-Speicher belegen und den Verbrauch jederzeit wieder zurückfahren. So lässt sich skalieren, ohne dass Kosten für ungenutzte Ressourcen anfallen. Entsprechend interessant ist dies für Webangebote, die über kurze Zeit grosse Leistung benötigen (beispielsweise parallel zu einem Anlass), oder für Firmen, die die Kosten für die Anschaffung einer eigenen Infrastruktur scheuen.
Amazons EC2 basiert auf einer modifizierten Version von Xen, auf der Linux-Images mit Kernel 2.6 betrieben werden können. Zu jeder Instanz erhält man eine gewisse Menge Rechenkapazität, Arbeitsspeicher und Storage, wobei man zwischen verschiedenen Varianten wählen kann, die sich von der Menge der bereitgehaltenen Ressourcen unterscheiden (Details siehe Tabelle). Zusätzlich kann man zwischen einer 32- und einer 64-Bit-Plattform wählen.
Für die Nutzung von EC2 kommt man nicht direkt mit Xen in Kontakt. Die Steuerung funktioniert statt dessen über eine Web-Services-API (SOAP oder REST), für die auch Bibliotheken in Java sowie Kommandozeilenwerkzeuge (Java und Ruby) bereitstehen. Sie dienen unter anderem zur Inbetriebnahme und Überwachung der Maschinen. Für Perl existiert mittlerweile in CPAN ein Modul. Python-Programmierer erhalten mit Boto (code.google.com/p/boto/) ein Interface zu mehreren Amazon Web Services.
Die Inbetriebnahme eines vorgefertigten AMI geht recht einfach vonstatten. Hat man einmal die Kommandozeilen-Werkzeuge inklusive aller Schlüssel zur Authentifizierung gemäss Dokumentation eingerichtet, kann man die vorhandenen AMI mit ec2-describe-images -a auflisten. Mit ec2-describe-images -o self -o Amazon erhält man alle Images, die einem selber gehören oder von Amazon bereitgestellt werden.
Als nächstes gilt es, SSH-Keys zu erzeugen, mit denen man sich später per SSH an der EC2-Instanz anmelden kann. Dies geschieht mit ec2-add-keypair aws-test-infoweek > id_rsa-aws-test-infoweek, wobei man den Schlüsselnamen (in diesem Fall aws-test-infoweek) frei wählen kann. Der Schlüssel wird in einer Datei namens id_rsa-aws-test-infoweek im aktuellen Arbeitsverzeichnis gespeichert.
Ist die Instanz einmal gebootet, kann man sich aber noch nicht mit ihr verbinden. Grund ist die Firewall, die standardmässig jede EC2-Instanz mit einem 1:1-NAT schützt. Sie arbeitet auf Basis von Gruppen, denen jeweils eine oder mehrere Instanzen zugewiesen werden können. Standardmässig existiert eine Gruppe namens default, der automatisch alle Instanzen zugewiesen werden. Weitere Gruppen können angelegt und die Gruppenzugehörigkeit jeweils beim Start der Instanz beeinflusst werden.
Die Firewall-Einstellungen können pro Gruppe festgelegt werden. Um beispielsweise Port 22 für die Gruppe default freizugeben, dient der Befehl ec2-authorize default -p 22. Hat man diesen ausgeführt, kann man sich per SSH mit dem Server verbinden. Um Zugriff auf den Webserver zu gestatten, muss ebenfalls Port 80 mit ec2-authorize default -p 80 freigegeben werden.
Wer kein vorgefertigtes AMI nutzen möchte, kann entweder ein vorgefertigtes AMI modifizieren oder ein Image selber bauen. In der Regel dürfte man sich für den Bau eines eigenen Image entscheiden. Dieser besteht aus zwei Schritten: Der Vorbereitung des Betriebssystems und der «Installation» in EC2.
Zur Vorbereitung des Betriebssystems bietet es sich an, auf einem Testsystem eine entsprechende Xen-Instanz zu erstellen und nach Wunsch zu konfigurieren. Wer damit nicht vertraut ist, findet beispielsweise in InfoWeek 01/2008 eine entsprechende Anleitung. Zu achten ist einzig darauf, dass die Netzwerk- und Festplatten-Konfiguration der von Amazon erwarteten entspricht. So muss die Netzwerkadresse mit DHCP bezogen werden, man muss je nach Instanzgrösse die richtige Architektur (x86 oder x86-64) wählen und die /etc/fstab für die jeweilige Anzahl Festplatten vorbereiten. Zudem muss man die SSH-Authentifizierung vorkonfigurieren, da man sich sonst nicht an der Konsole anmelden kann. Hat man dies erledigt, kann man die virtuelle Instanz herunterfahren und die Root-Partition in ein Image verpacken: dd if=/dev/vservers/infoweek-test of=infoweek-test.fs bs=1M.
Dieses Image muss nun für EC2 vorbereitet werden. Dafür werden die AMI-Tools benötigt, die – da kein Teil der EC2 API Tools – separat installiert werden müssen. Der erste Schritt besteht darin, das Image zu «bündeln». Dabei wird es mit dem Werkzeug ec2-bundle-image in mehrere kleine Stücke aufgeteilt, die sich einfacher nach S3 hochladen lassen, und mit einer Manifest-Datei versehen, die eine Art Inhaltsverzeichnis ist: ec2-bundle-image -u $EC2_USER -k $EC2_PRIVATE_KEY -c $EC2_CERT --image infoweek-test.fs --destination /tmp/infoweek-test.
Das gebündelte Image liegt nun in /tmp/infoweek-test und ist bereit zum Upload nach EC2, was mit ec2-upload-bundle erfolgt: ec2-upload-bundle -b infoweek-test -m /tmp/infoweek-test/infoweek-test.fs.manifest.xml -a $S3_ACCESS_KEY -s $S3_SECRET_KEY.
Hat man den Upload nach S3 absolviert, muss das Image noch registriert werden, um es nutzen zu können. Dies erfolgt mit Hilfe des Werkzeugs ec2-register, an das man den Pfad für die Manifest-Datei auf S3 verfüttern muss: ec2-register infoweek-test/infoweek-test.fs.manifest.xml. Als Rückgabewert erhält man die Kennung des soeben registrierten Image, beispielsweise ami-d00beeb9. Dies kann mit ec2-run-instances ami-d00beeb9 sofort gestartet werden und sollte nach wenigen Minuten seinen Dienst aufnehmen.
Amazon EC2: Instanzgrössen und Preise
Wie man sieht, sind die ersten Schritte mit EC2 keine Hexerei. Das Toolkit ist einfach zu benutzen und selbst die Vorbereitung eigener Images ist eine schmerzlose Angelegenheit. Die wahren Herausforderungen warten mit der Konfiguration der Applikationen respektive mit dem Betrieb. Denn EC2 ist, wie vielleicht bereits bemerkt wurde, dynamischer als man es vom klassischen Serverhosting kennt.
Das Hauptproblem ist, dass der Festplattenspeicher volatil ist. Während er einen Reboot noch problemlos überlebt, wird er nach Deaktivierung einer Instanz respektive einem Crash ausradiert. Zwar heisst es in den Amazon-Foren, ein persistenter Speicher sei geplant, doch ob und wann der kommt, ist ungewiss. Dies bedeutet, dass man einen zusätzlichen persistenten Speicher braucht. Dieser steht in Form von S3 zwar zur Verfügung, allerdings eignet er sich nur für statische Daten.
Von Datenbanken lassen sich beispielsweise nur Dumps unterbringen. Allerdings lassen sich diese nur in gewissen Zeitabständen erstellen, zumal man dazu die Datenbank sperren, wenn nicht gar herunterfahren muss. Entsprechend muss ein Setup her, das weiterarbeitet und keine Daten verliert, selbst wenn mal eine oder mehrere Instanzen (wenn sie beispielsweise auf demselben Rechner liegen sollten) aussteigen. Ausserdem muss es häufige Backups ohne Betriebsunterbrüche ermöglichen. Nebst Eigenbaulösungen existieren zur Umschiffung dieses Problems mittlerweile Angebote von Start-ups wie Elastra (www.elastra.com), die Images zum einfachen Aufbau von Datenbank-Clustern mit MySQL oder PostgreSQL anbieten. Zur Synchronisation des lokalen Speichers und S3 sind ebenfalls diverse Werkzeuge vorhanden, die rsync-ähnliche Funktionalität bieten. Ein Beispiel ist die Ruby-Software S3sync (www.s3sync.net).
Die nächste Herausforderung ist, dass sich die virtuellen Maschinen beim Start selber konfigurieren müssen, da sich beispielsweise während des Betriebs vorgenommene Konfigurationsänderungen nicht zurücksichern lassen. Sonst muss man für jede Instanz ein separates Image vorbereiten, was aber wartungsintensiv und bei einer grossen Anzahl von Instanzen wenig praktikabel ist. Da die IP-Adressen per DHCP vergeben werden, muss man ausserdem einen dynamischen DNS-Service wie EasyDNS oder DynDNS nutzen, wenn man eine Domain mit einer EC2-Instanz verbinden will.
