Das ist mein Blog.

Hier gibts, was ich tue, getan habe und vielleicht tun werde. Auch, wenn und weil das total unwichtig für den weiteren Verlauf der Geschichte ist. Viel Spaß damit.

Wer mich möglichst zeitnah erreichen und/oder beschimpfen will, versuche dies per Email (s.u.), per Twitter, auf Facebook oder im ircnet oder suche mich persönlich auf.

TMG §5 Kontaktdaten.

RSS-Feed Startseite

Einträge nach Kategorien

Einträge nach Datum

RSS-Feed
Startseite

07.12.2009

21:34 Uhr  Will it scale? Rechnen mit der Wolke - Amazon WebServices - Teil 2

Okay, nach den einführenden Worten zu den Amazon Webservices, nun mal etwas Butter bei die Fische - Arbeiten in der Cloud.

Der erste Schritt: Eine passende AMI finden und sich so hinfummeln, wie man es gerne hätte. Das geht mit ec2-describe-images, allerdings zeigt das folgende Kommando den Irrsin des Unterfangens an:

$ ec2-describe-images -a | wc -l
     970

Dafür ist dann Elasticfox ganz gut, um ein genehmes Image zu finden - oder man muß entsprechend seinen Vorlieben filtern:

$ ec2-describe-images -a|grep -i lenny|wc -l
      27

Ok, wenn man nach Debian AMIs sucht, kommt man schnell auf alestic, und kann sich das dort genauer ansehen. Ich hab mich dann erstmal für

IMAGE   ami-b8446fcc alestic-32-eu-west-1/debian-5.0-lenny-base-20091011.manifest.xml \
063491364108    available       publii386     machine aki-02486376 ari-fa4d668e

entschieden, also die aktuellste Version eines i386 (im Gegensatz zu amd64, eine Kostenfrage) Minimalimages (die anderen haben schnell mal nen komplettes KDE/Gnome dabei) entschieden. AMIs gibts in drei unterschiedlichen Größen, wobei sich Größe auf CPU-Büms und Plattenplatz bezieht. Zum Spielen reicht die kleinste locker aus.

Dieses AMI startet man sich:

$ ec2-run-instances ami-b8446fcc -k aleks-testkeypair 
RESERVATION     r-c8f104bf      737588137133    default
INSTANCE        i-0444b873      ami-b8446fcc    pending \
aleks-testkeypair       0               m1.small \
2009-11-28T20:36:14+0000      eu-west-1a      aki-02486376 \
ari-fa4d668e            monitoring-disabled

Damit wird eine Instanz dieser AMI in der eigenen Umgebung gestartet, und zwar mit der Security-Group default, und meinem passenden ssh-Key in die AMI gefrickelt (das erzeugen mit ec2-add-key ist nervig und untypisch für Leute, die ssh-keygen gewohnt sind).

Nach einer Minute (oder so, kann man mit ec2-describe-instances überprüfen, das pending muß durch running ersetzt sein) ist die Instanz gebootet, und man kann sich, nachdem man in der Default-Security-Group die eigene IP freigeschaltet hat

$ ec2-authorize default -P tcp -p 22 -s 213.39.215.21/32
GROUP           default
PERMISSION              default ALLOWS  tcp     22      22 \
FROM CIDR    213.39.215.21/32

per ssh dort einloggen:

$ ssh -i .ec2/id-aleks-testkeypair root@ec2-79-125-34-231.eu-west-1.compute.amazonaws.com 

Amazon EC2 Debian 5.0.3 lenny AMI built by Eric Hammond
http://alestic.com  http://ec2debian-group.notlong.com

ip-10-227-89-159:~# 

Und etwas umschauen, und sich die Instanz so hinfummeln, wie man es möchte (z.B. erstmal die normalen authorized_keys hinterlegen), und die Packages installieren, die man so normalerweise braucht. Achtung, stirbt die Instanz durch Deine Dummheit, kannst Du von vorne anfangen, Änderungen werden nicht wirklich gesichert (reboot funktioniert aber ohne Gedächnisverlust).

Will man die eigene Vermackelungen für die Nachwelt oder sich selbst erhalten, muß man aus dieser Instanz wieder ein AMI machen, dafür braucht man ein S3-bucket, x509-Key und Zertifikat, dazu auch noch die AWS-ID und die passenden Keys. Die x509-pems legt man auf der Instance ab, am besten dort, wo das AMI ge'bundled' wird, weil sie damit nicht in der neu erstellten AMI auftauchen (zur Sicherheit sollte man die nicht in AMIs rumliegen lassen). Ich mache das in /mnt.

Genauer: Ich habe dafür ein Skript gebaut, daß das alles sehr exemplarisch automatisiert (und z.B. vorher Services runterfährt und ein EBS umounted (dazu später mehr))

Das Skript muß natürlich auf der laufenden Instanz ausgeführt werden, die nachfolgenden Kommandos stammen nicht aus den ec2-api-tools, sondern aus den ec2-ami-tools :)

Letzlich ist das dann auch nur ein Kommando (wenn alle Keys da sind und kein EBS mehr im Weg rumgammelt):

$ ec2-bundle-vol -d ${bundledir} -k ${pkkey} -c ${pkcert} \
 -u $awsuserid -r i386 -p ${imgname}

Genauer ist das im Skript erkennbar. Das Bündel muß dann ins S3-Bucket geladen werden, dazu gibts das Kommando ec2-upload-bundle

$ ec2-upload-bundle -b ${s3bucket} -m ${bundledir}/${imgname}.manifest.xml \
-a $awsaccesskey -s $awssecretkey

Mit S3Fox kann man dann sehen, wie es im entsprechenden bucket anschwillt (das Bucket wird automatisch angelegt, wenn es noch nicht vorhanden ist).

Als letzte Amtshandlung muß man das entsprechende AMI noch im AWS registrieren - das geht wieder durch einen ec-api-tool-Aufruf, also lokal am Arbeitsplatz.

$ ec2-register ${s3bucket}/${imgname}.manifest.xml

Dieses Kommando gebiert wiederum einen AMI-Namen, den man wiederum wie oben als neue Instanz laufen lassen kann, und für die man nun seine normalen sshkeys verwenden kann (wenn man sie reingefummelt hat). Allerdings sucht man dann eben nach dem eigenen Imagenamen zur Auswahl.

Ein Problem hat so eine Instanz aber noch, sie ist ziemlich vergesslich und sie ist nicht unter einer vorher bekannten IP ansprechbar. Die Vergesslichkeit regelt man mit einem EBS - elastic block storage, die IP-Vorhersage über Elastic-IPs.

Ein EBS legt man sich einfach mit ec2-create-volume an:

$ ec2-create-volume -s 10 -z eu-west-1a
VOLUME  vol-aa8a6ec3    10              eu-west-1a      creating \
2009-11-28T23:19:26+0000

Die passende Zone kann man sich aus der Ausgabe von ec2-describe-instances herausfischen. Danach muß das EBS-Volume an die Instanz gebunden werden:

$ ec2-attach-volume vol-aa8a6ec3 -i i-3c3fc34b -d /dev/sdb
ATTACHMENT      vol-aa8a6ec3    i-3c3fc34b      /dev/sdb \
attaching       2009-11-28T23:21:41+0000

Ab diesem Moment steht die Platte sdb der Instanz ztur Verfügung und kann normal partitioniert und formatiert werden.

Ein Tipp (das hat mich Tage gekostet): Wenn man in einer ursprünglichen Alestic-Instanz mit XFS rummacht, muss man zwingend Logversion 1 (mkfs.xfs -l version=1 /dev/sdb1) verwenden, sonst gibts beim ersten Zugriff ne Kernelpanic, und wenn man das Image mit den bisherigen Änderungen nicht gesichert hat, fängt man von weiter vorne wieder neu an. Die Ursache dafür scheinen Inkompatibilitäten in den von EC2 verwendeten Fedora-Kerneln mit den entsprechenden Debian-XFS-Modulen zu sein. Es gibt dazu reichlich Fundstellen im Netz.

XFS ist gut, weil man mit xfs_freeze und S3 sehr nette Backupstunts hinlegen kann, z.B. mit der Hilfe von ec2-consistent-snapshot, das auch noch ein FLUSH in den mysqld peitscht.

Ich verwende das aber bisher noch nicht, weil ec2-consistent-snapshot ein (jedesmal neues) EBS-Volume erzeigt und nicht in ein S3-Bucket schreibt. Da man den Namen nicht vorher weiß, ist ein sinnvolles Haushalten mit verschiedenen Snapshots aufwendig und letztlich durch den verbrauchten Speicherplatz teuer. Ich verwende stattdessen ein selbstgeschriebenes Skript, das mit Hilfe von s3cmd (s.u.) in ein S3-Bucket schreibt und dort Versionen mit vorhersagbaren Namen erzeugt, die es auch nach einer definierten Zeit wieder löscht.

Generell kann man sich das partitionierte EBS mounten, wie man lustig ist - ich habe mir das der Einfachheithalber erstmal unter /mnt/persistent gemounted, und alle Verzeichnisse oder Dateien, von denen ich weiß, daß sie sich unabhängig von der Maschineninstanz ändern (Home-Verzeichnisse, Datenbankspool, andere Spools, die man nicht verlieren will, Anwendungen, die unabhängig vom System gepflegt und upgedated werden, Konfigurationsdateien von Webservern, /usr/local, ... dort hin verschoben und dann ins System hineingelinkt.

Das EBS wird immer erst nach dem Booten an die Instanz gebunden, man sollte es also tunlichst vermeiden, dort zum Booten notwendige Dinge abzulegen.

Genauso wie das EBS läßt sich auch eine Elastic IP mit ec2-allocate-address bereitstellen und dann mit ec2-associate-address an eine Instanz binden. Das geht auch schon während des Bootens, also direkt, nach dem ec2-run-instances den Instanznamen preisgegeben hat.

Ich habe dafür ein Skript, daß eine passende AMI auswählt, mit den passenden security-groups startet, die IP dranklatscht, und immer wieder überprüft, ob der Status pending in den Status running gewechselt ist - wenn ja, wird das EBS attached.

Services, die auf Informationen auf dem EBS zugreifen, starten also nicht automatisch, bzw. brechen mit einer Fehlermeldung weg, wenn man das vorher weiß, kann man sich das aber entsprechend hinfummeln.

Die eigene Instanz läuft also - wichtig ist, immer daran zu denken, daß man nach Umbauten am System, die nicht im EBS zu liegen kommen, ein neues AMI erzeugen muß, um diese Änderungen für die Zukunft zu erhalten.

Es gibt die Möglichkeit, eine laufende Instanz direkt aus den AWS heraus zu überwachen, und bei bestimmten Triggern weitere, gleiche Instanzen zu starten - da fängt das Wolken erst richtig an. Damit habe ich aber noch nicht viele Erfahrungen, das reiche ich in einem gesonderten Artikel nach.

Praxis

Naja, es verhält sich wie ne normale Maschine :-)

Zum Arbeiten mit S3 hab ich noch s3cmd gefunden, damit kann man von der Shell aus in einem (oder mehreren) S3-Buckets herumfuhrwerken, das läßt sich aus meiner Perspektive in Skripten besser handhaben als als die im S3-Guide vorgestellten php, java, ruby, python, c++ und sonstigen Programmierbeispielen, um mal eben ne Konfiguration im Backup zu sichern und ähnliches. s3cmd funktioniert auch gut aus ec2-Instanzen heraus.
Debianer sollten nicht die paketierte Version verwenden, die kann z.B. kein -r (recursive).

$ s3cmd ls
2009-11-25 09:11  s3://s2-master-img
$ s3cmd put Desktop/jahrbuch2009_export.pdf s3://s2-master-img
Desktop/jahrbuch2009_export.pdf -> s3://s2-master-img/jahrbuch2009_export.pdf  [1 of 1]
 13526575 of 13526575   100% in  206s    64.01 kB/s  done

Zur Praxis schreibe ich später noch mal was, wenn ich mehr rausgefunden habe.

Was kostet der Spaß?

Kurz: ich weiß es noch nicht genau.

Lang: Das AWS-Bezahlsystem ist eigentlich simpel, aber kompliziert, weil jeder kleine Furz einzeln abgerechnet wird.

Eine kleine EC2 Unix Instanz kostet z.B. in Europa USD 0.095 pro Stunde, dazu kommt Datenverkehr (USD 0.10 per GB rein und USD 0.17 per GB raus (wird billiger mit mehr Traffic). Dazu kommt EBS mit USD 0.11 pro GB im Monat für die Größe des Devices und USD 0.11 für 1.000.000 I/Os...

Okay, ich kann mir darunter nicht so irre viel vorstellen, Du auch nicht? Dafür gibts den Simple Monthly Calculator - der nicht so ganz simpel ist, will er doch Daten haben, die ich aus der hohlen Hand nicht einfach so weiß. Einfach mal selbst probieren...

Der dritte Teil wird etwas auf sich warten lassen, probiert einfach mal selbst damit rum.

[Kategorie: /computers] - [permanenter Link] - [zur Startseite]