Amazon bietet seit ca. einem Jahr unter den Bezeichnungen "Elastic Compute Cloud " (EC2) und "Amazon Simple Storage Service " (S3) zwei sehr interessante Produkte im Bereich Web-Appliance und Clustering bzw. Computing an.
Mit EC2 kann man virtuelle Rechner Instanzen in einer XEN Umgebung starten.
S3 dient als unendlich großes Speichermedium und zum stabilen ausliefern von Daten auch bei hohen Zugriffszahlen. Kunden von uns setzen S3 z.B. ein um große Downloads wie Videos, Magazin PDFs und ISO Images von CD-ROMs auszulagern und somit den Webserver zu entlasten.
Bei ESONO experimentieren wir schon seit einigen Monaten mit den von Amazon angebotenen technischen Möglichkeiten um unseren Kunden kostengünstige und schnell skalierbare Clusterlösungen anbieten zu können.
Bisher war man wegen der knappen CPU Leistung vergleichbar mit einem 1,2Ghz Opteron dazu gezwungen rechenintensive Funktionen auf mehrere Instanzen zu verteilen, was je nach Anwendungsgebiet nicht so einfach ist. In unserem Fall gab es hier Engpässe bei der Generierung von Wasserzeichen in MP3 Dateien und der CPU fressenden ZIP Datei Erstellung.
Nun hat aber Amazon die Kundenwünsche erhört und bietet ab sofort auch leistungsfähigere Server Instanzen an, nämlich mit 4-facher und 8-facher CPU Leistung und mit bis zu 15GB RAM. Natürlich zu angepassten Preisen, aber das nimmt man gerne in Kauf, wenn man sich dafür das filigrane zerschneiden von CPU lastigen Prozessen sparen kann. (Amazon AWS Blog)
In einem Gespräch mit Björn Schotte von Mayflower, der gerade eine PHP/Oxid Shop Lösung für Premiere auf Basis eines Server Clusters fertiggestellt hat, wies er mich darauf hin, dass er einen produktiven Einsatz von EC2/S3 wegen des Beta Stadiums nicht empfehlen würde. Da hat er natürlich recht, die Stabilität und vor allem eine Aussage seitens Amazons zu Ausfallsicherheit und maximalen Downtimes ist für einen professionellen Einsatz unabdingbar.
Zum Glück kommt aber Amazon auch hier endlich in die Gänge und hat zumindest mal bei S3 den Beta Status auf "produktiv einsatzfähig" geändert und ein SLA (Service Level Agreement) angeboten, welches 99,9% Verfügbarkeit je Monatseinheit vorsieht. Das bedeutet eine maximale Downtime von 7,2 Stunden im Monat, was im dümmsten Fall einen Arbeitstag am Stück entspräche. Sollte die Verfügbarkeit tiefer als 99,9% sinken gibt´ Dollars zurück.
Jetzt muss man aber wissen, dass als downtime jeder request gerechnet wird, der vom S3 System nicht vollständig durchgeführt werden konnte. z.B. wenn bei einem PUT Befehl die Dateiübertragung abbricht und noch einmal gestartet werden muss. Somit handelt es sich nicht wirklich um eine downtime eines services, sondern um die Sammlung von Errors, die beim Arbeiten mit S3 entstehen. Fängt man diese also ab und sendet gegebenenfalls eine Datei nach einem Error nochmal, dann kann man wohl eine 100% Verfügbarkeit erzielen.
Zumindest während unserer Tests ist S3 nie ausgefallen, übertragungsfehler gab es mit einer Ruby Komponente allerdings bei einer Load des Servers über 1 (was man ja tunlichst vermeiden sollte).
Die EC2 Instanzen sind da schon etwas instabiler. Je nach eingesetzter Linux Distro kann die auch mal abschmieren. Hier muss man auf eine Xen kompatible Distro achten.
Wir hatten auch den Fall, dass uns Amazon per E-Mail darauf aufmerksam gemacht hat, dass sie in wenigen Tagen unsere Instanze abschalten müssen, weil auf dem Host System ein Hardware Problem bestehe. Halb so wild, denn einmal kurz den Stopp Button im Firefox EC2 plugin geklickt und die Instanze fährt runter. Nochmal klicken und eine neue Instanze fährt auf einem anderen Host System wieder hoch. Man kann also mit 15sec reboot weiterarbeiten als wäre nichts gewesen.
Unser Fazit bisher: Wir bleiben Amazon treu und fangen in kleinen Schritten an, Dienste auf EC2 zu testen und zu betreiben. Das Preismodell ist attraktiv und die Technik überzeugt. Der Virtualisierung gehört definitiv die Zukunft.
