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

28.11.2009

23:05 Uhr  Erfahrungen im Rechnen mit der Wolke - Amazon WebServices - Teil 1

Okay, wenn der pointy-haired boss das so will, dann machen wir das mal.
Seit ungefähr 4 Wochen vor dem passenden Dilbert beschäftige ich mich mit Cloud Computing, und versuche herauszufinden, ob das für unsere Firma eine brauchbare Möglichkeit ist. Genauer, ob es für uns interessant ist, entsprechende Resourcen zu nutzen, weil sie angeblich schnell und auf den Punkt verfügbar sind, sehr gut skalieren und erst genau im Moment der Nutzung Kosten verursachen.

Ziel der Untersuchung ist einer der ganz großen Cloud Computing Anbieter, Amzon. Genauer AWS - Amazon WebService. Das gute daran: Jeder, der einen 'normalen' Amazonk-Account hat, kann darüber eventuelle Experimente abrechnen.

Da das für die meisten Leser ein relativ neues Feld sein wird, gibts erstmal ein paar AWS-Konzepte erklärt. AWS bietet sehr viel mehr als ich hier darstelle - siehe die Produktseite, ich beschränke mich hier erstmal auf EC2 und S3.

Grob gesagt stellt Amazon EC2 (Elastic Compute Cloud) die eigentlichen virtuellen Maschinen-Resourcen zur Verfügung. EC2 ist auf gute Skalierbarkeit und pay-per-compute ausgerichtet. D.h., es ist sehr einfach, zusätzliche, identisch konfigurierte Instanzen auch kurzfristig zu den vorhandenen dazuzustarten. Abgerechnet wird streng nach Verbrauch (CPU, Traffic, Plattenplatz, genutzte IPs usw). Was man nicht nutzt (und deswegen abschaltet), zahlt man auch nicht. Eine gute Einführung in die Konzepte gibts im EC2 GettingStartedGuide und die eigentliche Bedienungsanleitung im EC2 UserGuide. Da, wo mein Geschreibsel ins Nebulöse abgleitet, ist man beim Nachspielen gut beraten, diese Dokus zu lesen (die gibts auch als html und auch diverse weitere, gute Doku).

Amazon S3 (Simple Storage Service) bietet eine einfache Mögllichkeit, beliebige Daten im Netz vorzuhalten. S3 wird über eine eigene API angesprochen und kann nicht direkt als Filesystem in eine EC2-Instanz gemounted werden. Auch S3 wird streng nach Verbrauch (verbrauchter Plattenplatz, Traffic) abgerechnet.

Alle AWS Komponenten laufen selbst auch in Clouds, die Amazon als Regions bezeichnet. Derzeit gibt es zwei Regionen, eine an der US-Ostküste, eine in Europa. Wichtig ist hier nur, daß in der Regel alle Services in der gleichen Region läufen müssen, wenn diese in einem Projekt gemeinsam genutzt werden sollen. Ein Umzug in die andere Region ist möglich, aber umständlich.

Die konkrete Anzahl von Rechenzentren hinter diesen Regionen ist erstmal verborgen und unwichtig.

Im EC2 gibt es ein paar tolle Marketingschwurbel-Begriffe, die ich trotzdem verwende, weil ich sonst andere, die ebenfalls EC2 verwenden, nicht verstehe.

• Die wichtigste Resource ist dabei ein AMI - Amazon Machine Image.
  Amazon (und auch andere) hält eine große Anzahl von unterschiedlichen AMIs zur Benutzung bereit, darunter befinden sich unter anderem auch Linux- und Windows-Images. Diese Images kann man sich so anpassen, wie sie für den eigenen Einsatzzweck am besten geeignet sind, d.h., die entsprechenden Packages installieren, die man immer benötigt, User und Keys hinterlegen usw.
  Hat man sich aus einem Default-AMI ein entsprechendes laufendes System zusammengeschustert, kann man dies in ein neues AMI überführen und entsprechend im AWS (genauer im S3) ablegen. Je nach Wunsch kann man dieses Image öffentlich zur Nutzung bereitstellen oder es nur selbst nutzen.
  Ein AMI ist grundsätzlich vergesslich - wird eine laufende Instanz abgeschaltet, gehen ALLE Änderungen, die seit dem Starten vorgenommen wurden, verloren, ebenso gehen alle dyanmisch zugewiesenen Resourcen verloren, wie IP-Addresse, ssh-hostkeys, gemountete externe Filesysteme. Dies betrifft allerdings keine Reboots.
  Aus diesem Grund ist an einigen Stellen ein Umdenken erforderlich, um die nichtvorhandene Persistenz des Filesystems durch andere Konzepte zu ersetzen.
• Elastic IP - AWS verwendet für neu gestartete AMIs eine interne, nicht routingfähige RfC1918 IP-Adresse, die nicht persistent ist. Auf diese interne IP wird von außen über eine ebenfalls nicht persistente routingfähige IP genattet.
  Damit ein Angebot auch bei wechselnden AMI immer unter der gleichen IP (und damit letztlich einem DNS-Namen) erreichbar ist, gibt es das Konzept der Elastic IP.
  Damit kann eine IP unabhängig von laufenden AMI definiert werden, diese IP hat einen festen, einigermaßen vorhersagbaren DNS-Namen, und diese IP kann an eine gerade laufende AMI gebunden werden.
  Da die Elastic IP auf eine beim Start eines AMI nicht vorhersagbare IP genattet wird, wird ein anderer Weg benötigt, ein AMI intern persistent ansprechen zu können (Klassiker: Datenbank-Verbindung auf einen anderen Host).
  AWS verwendet ein DNS-System, das intern in der AWS anders auflöst als bei einer Anfrage aus dem Internet. Fragt man von Intern nach dem PTR der Elastic IP, bekommt man die interne IP des AMI, auf das gerade die Elastic IP gemappt ist. D.h., man kann den PTR als Hostnamen in Konfigurationsdateien sicher verwenden.
  
• EBS - Elastic Block Storage ist ein in ein AMI hineinmountbares Blockdevice, das unabhängig von einer AMI existiert und damit als Persistenzlayer dienen kann.
  Mit EBS ist es möglich, Daten über einen Neustart hinaus zu erhalten. Das Blockdevice kann frei konfiguriert und z.B. mit einem Dateisystem versehen werden.
  Es ist möglich, mehrere EBS an ein AMI zu binden, allerdings ist es nicht möglich, ein EBS an mehrere AMI gleichzeitig zu binden.
  EBS verfügt über die Möglichkeit, snapshots vom Device zu erstellen, um es zu sichern oder es zu klonen und anderen AMI zur Verfügung zu stellen.
  In meinem Test-Projekt ist in jede laufende AMI-Instanz ein EBS als Partition gemounted und alle erhaltenswerten Daten (z.B. Userhomes, Anwendungsdaten, Datenbank-Daten, per AMI individuelle Konfigurationsdaten, ... sind entsprechend in die vorgesehenen Stellen im Filesystem des AMI hineingelinkt.
  Dabei darf man es nicht übertreiben - ein Linux bootet z.B. logischerweise nicht ohne ein lokales /etc. :-)
  
• Die Security Groups stellen die Firewallkonfiguration des EC2 dar. Um für unterschiedliche Instanzen unterschiedliche Zugriffsmöglichkeiten zu ermöglichen, gibt es ein entsprechendes Gruppenkonzept.
  Das ist pille palle, das einzige, auf das man achten muß: Eine AMI kann nur VOR DEM START einer oder mehrerer Security-Gruppen zugeordnet werden.

Eigentlich kommt man mit dem oben dargestellten Möglichkeiten gut zurecht, allerdings nur, wenn man keine selbst vergurkten AMIs verwendet :-)

Die sinnvollste Möglichkeit, größere Datenmengen (z.B. eben AMIs) unabhängig von einer laufenden Instanz in der Amazon Wolke abzulegen, bietet S3 - Simple Storage Service. Zum S3 gibts auch wieder diverse Dokumentationen, Einstieg ist wieder der entsprechende GettingStartedGuide.

S3 ist nicht direkt mit mount als klassisches Filesystem mountbar, sondern über eine REST- bzw SOAP-API, für die es in jeder aktuell gängigen Programmiersprache Beispiele zum Anflanschen eigener Software gibt. Aktuelle Software zum Handhaben von Dateien (z.B. cyberduck aufm Mac, S3fox für Firefox und eben EC2-AMIs) hat entsprechende Schnittstellen implementiert.
Informationen werden in sogenannten buckets organisiert und bieten eine relativ granulare Möglichkeit der Zugangsberechtigungssteuerung.

Die AWS nutzen eine mehrstufige Authentifizierung, die sich auch je nach Komponente unterscheidet.

• Für den Login in die AWS-Management-Webseite wird als Userkennung eine Emailaddresse und ein Password benutzt (die Amazonk-Buchladenkennung).
• Für die direkte Arbeit mit EC2 und S3 benötigt man wiederum unterschiedliche Credentials, diese werden im AWS-Account generiert bzw. können dort ausgelesen werden.
• Um einen Service anzusprechen, benötigt man die Accesskeys
• Um AMIs zu bauen, benötigt man zusätzlich x509-Keys
• Um sich auf Amis einzuloggen noch zusätzlich ssh-keys.

Neben den oben genannten Tools für S3 gibt es noch ein paar weitere, mit denen man sich an die Möglichkeiten von EC2 rantasten kann:

• Die AWS Management Console ist per Webbrowser erreichbar, damit kann vorallem EC2 administriert werden. Von der Bedienung eher unhandlich, Benutzer, die Firefox verwenden, sollten lieber Elasticfox und S3Fox verwenden.
• Elasticfox ist ein Plugin für Firefox und ermöglicht alle üblichen Operationen an EC2 per Webinterface.
  Achtung, die in Elasticfox verwendeten Tags sind LOKAL (werden nicht in die Cloud geschrieben) für den User, dem Firefox gehört - aus diesem Grund taugen die Tags auch nicht zur Namensgebung, wenn man im Team arbeitet.

Seine ganze geballte Kraft entfaltetet sich aber erst, wenn man die ec2-api-tools einsetzt, die man einigermaßen vernünftig skripten kann. Die ec2-api-tools sind in java geschrieben, und durch clevere wrapper für so ziemlich jede Betriebssystemsumgebung geeignet, wo man ein java und eine shell draufgewämst bekommt. Meine Beispiele beziehen sich auf nen Unix, genauer nen Mac. Das geht aber auch gut unter Windows.

Wenn man sich an die traditionellen Regeln für shell-Betrieb hält, und alle einigermaßen konstanten Parameter als Umgebungsvariablen exportiert (

$ set|grep EC2
EC2_CERT=/Users/alesti/.ec2/cert-test.pem
EC2_HOME=/usr/local/ec2-api-tools
EC2_PRIVATE_KEY=/Users/alesti/.ec2/pk-test.pem
EC2_URL=https://eu-west-1.ec2.amazonaws.com

), sind die Tools angenehm zu nutzen, ansonsten hat man schnell ekelhafte Kommandowürmer:

ec2-describe-instances -K ~/.ec2/pk-test.pem -C ~/.ec2/cert-test.pem \
	-U https://eu-west-1.ec2.amazonaws.com i-04f60b73

gegen

ec2-describe-instances i-04f60b73

Das Ergebnis ist in beiden Fällen (auf zwei Zeilen):

RESERVATION     r-b07398c7 \
		358240633166 \
		testgroup,default
INSTANCE        i-04f60b73 \
		ami-370e2543 \
		ec2-79-125-2-112.eu-west-1.compute.amazonaws.com \
		ip-10-224-99-79.eu-west-1.compute.internal \
		running \
		0 \
		m1.small \
		2009-11-24T16:56:00+0000 \
		eu-west-1a \
		aki-02486376 ari-fa4d668e \
		monitoring-disabled \
		79.125.2.112 \
		10.224.99.79

Das kann man gut mit shell-Mitteln auseinanderfummeln und weiter verwursten.

Soviel erstmal zu den Basics, im folgenden zweiten Teil folgt dann der praktische Umgang mit AWS EC2 und S3.

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