Eine beispielorientierte Einführung in die Amazon Elastic Compute Cloud

Transkript

1 Eine beispielorientierte Einführung in die Amazon Elastic Compute Cloud 15. März 2014 FernUniversität in Hagen

2 Abstract Die vorliegende Ausarbeitung ist eine beispielorientierte Einführung in die Amazon Elastic Compute Cloud (kurz: Amazon EC2) - ein Bestandteil der Amazon Web Services. Als Beispiel wird ein virtueller Server (eine sog. Instance) erzeugt und die Möglichkeiten des entfernten Zugriffs darauf aufgezeigt. Insbesondere die Möglichkeit, die Amazon Elastic Compute Cloud per Skript zu verwalten, wird am Beispiel von Python aufgezeigt. Die Anbindung und Nutzung zusätzlichen Speichers und die Nutzung von Netzwerkresourcen schließt die Einführung ab. Die Shell- und Python-Skripte sind mit abgedruckt und verdeutlichen die Inhalte. i

3 Inhaltsverzeichnis 1. Erste Schritte 1 2. Erstellung eines virtuellen Servers Erzeugung eines Benutzers Erzeugung eines Schlüsselpaares Erzeugung einer Security Group Erzeugung einer Instance Zugriff auf die Instance per SSH Zugriff auf die Amazon Web Services Zugriff per CLI Zugriff über Web Service API Zugriff via Python Zugriff über die REST API Anbindung von zusätzlichem Speicher Nutzung von Netzwerkresourcen Webserver installieren Elastic IPs Tags und Filters Instances klonen Standby-Redundanz mit mehreren Instances Lastverteilung über einen Load Balancer A. Skripte 20 Literaturverzeichnis 24 ii

4 1. Erste Schritte Um die Amazon Elastic Compute Cloud (kurz: Amazon EC2) nutzen zu können, muss zunächst ein Konto für die Amazon Web Services (AWS) eröffnet werden. Folgender Link führt direkt zur Kontoeröffnung: Nach erfolgreicher Kontoeröffnung, kann man auf die AWS Management Konsole (siehe Abbildung 1) zugreifen, mit der das Cloud Angebot eingerichtet und verwaltet werden kann. Abbildung 1: AWS Management Konsole im Browser Die Anmeldung erfolgt im Browser mit der folgenden URL und den bei der Kontoeröffnung festgelegten Zugangsdaten: 2. Erstellung eines virtuellen Servers Ziel dieses Abschnitts soll es nun sein, über die AWS Management Konsole einen neuen virtuellen Server (auch Amazon EC2 Instance oder kurz Instance genannt) einzurichten, auf 1

5 diesem ein Linux AMI (Amazon Machine Image) zu starten und den späteren Zugriff darauf vorzubereiten Erzeugung eines Benutzers Die Zugangsdaten, die bei der Eröffnung des Kontos festgelegt wurden, werden typischerweise nicht für die Nutzung und den Zugriff auf die Amazon Web Services verwendet. Statt dessen können im Bereich AWS Identity and Access Management (kurz: IAM) neue Benutzer angelegt werden, die dann mit den benötigten Rechten ausgestattet werden Amazon [2013d]. Die spätere Authentifizierung der Benutzer erfolgt über Security Credentials. Es wird hierbei unterschieden zwischen: Access Credentials Sign-In Credentials Die Access Credentials werden für den programmatischen Zugriff genutzt, während die Sign- In Credentials zur Anmeldung an der AWS Management Konsole im Browser dienen. Mit den Schritten in [Amazon, 2013d, Kapitel Create an IAM User ] wird nun ein neuer Benutzer awsmanager angelegt und mit Administrator-Rechten ausgestattet: Abbildung 2: AWS Identity and Access Management: Neuer Benutzer Im letzten Schritt werden die Security Credentials (genauer: die Access Credentials) des neuen Benutzers angezeigt. Diese müssen heruntergeladen bzw. gesichert werden. Damit der neue Benutzer Zugriff auf die AWS Management Konsole per Browser erhält, müssen auch Sign-In Credentials erstellt werden. Dazu wird der neue Benutzer in der Liste unter Users ausgewählt. Über Manage Password unter dem Tab Security Credentials kann dann ein Passwort für die Anmeldung an der AWS Management Konsole zugeordnet werden. Im letzten Schritt müssen die Sign-In Credentials heruntergeladen bzw. gesichert werden. Zu diesen gehört auch eine URL, über welche sich der Benutzer per Passwort und 2

6 Benutzernamen an der AWS Management Konsole anmelden kann. 1 Mit dem neuen Benutzer awsmanager können jetzt alle weiteren Schritte auf der AWS Management Konsole durchgeführt werden Erzeugung eines Schlüsselpaares Bei der Erzeugung einer Instance kann ein Schlüsselpaar (Key Pair) angegeben werden. Das Schlüsselpaar besteht aus einem öffentlichen Schlüssel (Public Key) und einem privaten Schlüssel (Private Key). Der öffentliche Schlüssel wird für die ausgewählte Region 2 in den Amazon Web Services hinterlegt, während der private Schlüssel nur dem Nutzer zur Verfügung steht. Das Schlüsselpaar wird für die spätere Nutzung von SSH benötigt. Ein neues Schlüsselpaar läßt sich in der AWS Management Konsole über Create Key Pair unter EC2 Network & Security Key Pairs erzeugen. Vor der Erzeugung muss die Region ausgewählt werden, zu welcher das Schlüsselpaar zugeordnet werden soll. Hier wurde die Region EU (Ireland) gewählt. Das Schlüsselpaar erhält für die spätere Identifizierung einen Namen. Hier wurde awsmanager-key-pair-ireland gewählt. Am Ende steht dann der private Schlüssel als awsmanager-key-pair-ireland.pem zum Download bereit: -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKC... ZGjkE6Jnf5w= -----END RSA PRIVATE KEY----- Vorsicht: Bei Verlust kann der private Schlüssel später nicht wieder rekonstruiert werden Erzeugung einer Security Group Eine Security Group regelt die Kommunikation mit einer Instance. Dazu werden der Security Group Regeln (Rules) zugeordnet, welche die zulässige eingehende und ausgehende Kommunikation beschreiben [Amazon, 2013d, siehe Kapitel Amazon EC2 Security Groups ]. Später bei der Erzeugung der Instance wird die zu nutzende Security Group angegeben. Mit der Eröffnung des Kontos wird automatisch eine Security Group erzeugt. Mit den Schritten in [Amazon, 2013d, Kapitel Create a Security Group ] soll hier dennoch eine eigene Security Group erzeugt werden und für diese die notwendigen Regeln erstellt werden. Eine 1 Bestandteil der URL ist insbesondere die Nummer des Kontos im Format: Alternativ läßt sich auch ein Alias vergeben. 2 Wie in [Amazon, 2013d, Kapitel Regions and Availability Zones ] ausführlicher dargelegt wird, gibt es eine dreifache Gliederung in Bezug auf die Zuordnung einer Resource. Nach der globalen Ebene, stellt die Region die räumliche Zuordnung zu einem örtlich abgrenzbaren Gebiet dar (z.b. der Standort des Rechenzentrums). 3

7 neue Security Group wird über Create Security Group unter EC2 Network & Security Security Groups erzeugt (siehe Abbildung 3): Abbildung 3: Security Group: Erzeugung Nachdem die Security Group erstellt wurde, kann sie in der Liste der Security Groups ausgewählt werden. Die Regeln für eingehende (Inbound) und ausgehende (Outbound) Kommunikation (jeweils aus Perspektive der Instance) lassen sich dann unter den gleichnamigen Reitern verwalten. Um später per SSH, CLI und die Web Service API auf die Instance zuzugreifen, werden dort für die eingehende Kommunikation (Inbound) folgende Regeln erzeugt: Abbildung 4: Security Group: Inbound Regeln Die hinzugefügten Regeln werden mit Apply Rule Changes übernommen. Vorsicht: Der zulässige IP-Adressbereich ist für dieses Beispiel nicht weiter eingeschränkt Erzeugung einer Instance Eine neue Instance wird in der AWS Management Konsole über Launch Instance unter EC2 Instances Instances erzeugt. Dazu muss zunächst die Region ausgewählt werden, in welcher die Instance erzeugt werden soll und in welcher zuvor auch das Schlüsselpaar erzeugt wurde. Danach sind folgende Schritte notwendig: 1. Unter Choose AMI erfolgt die Auswahl eines Amazon Machine Images (AMI). Dieses enthält Betriebssystem und Anwendungssoftware für die zu erzeugende Instance. Es wird hier das 64-Bit Amazon Linux AMI in der Version verwendet. 4

8 2. Unter Choose Instance Type erfolgt die Auswahl des Instance Typs. Über den Typ wird primär die Leistungsklasse und die Eigenschaften der virtuellen Hardware bestimmt. Es wird hier t1.micro verwendet - ein Typ geringer Leistungsklasse. 3. Über Configure Security Group wird die zuvor angelegte Security Group ausgewählt. In diesem Beispiel ist dies die Security Group awsmanager-sg-ireland. Alle weiteren Einstellungen werden unverändert übernommen. Im Schritt Review Instance Launch wird die Zusammenfassung aller Einstellungen angezeigt. Über Launch wird nun das zuvor erzeugte Schlüsselpaar (hier: awsmanager-key-pair-ireland ) der neuen Instance zugeordnet (siehe Abbildung 5). Die Instance wird danach über Launch Instances gestartet. Mit diesem Schritt können nun auch Kosten entstehen. Abbildung 5: Erzeugung einer Instanz: Auswahl des Schlüsselpaars und Starten der Instance Die Instance erscheint jetzt in der Liste der Instances. Das Starten der Instance kann eine kurze Zeit dauern. Sobald die Instance gestartet ist, wird sie unter Instance State mit dem Status running angezeigt (siehe Abbildung 6). Abbildung 6: Erzeugung einer Instanz: Gestartete Instance Ab diesem Zeitpunkt ist der Zugriff auf die neue Instance möglich Zugriff auf die Instance per SSH Der Zugriff per SSH auf die neue Instance wird hier exemplarisch für ein Debian (Squeeze) Linux System gezeigt. Hier wird SSH aus dem Package openssh-client verwendet. Bei der Schlüsselerzeugung wurde der private Schlüssel awsmanager-key-pair-ireland.pem erzeugt. Damit dieser Schlüssel mit SSH verwendet werden kann, wird zunächst die Zugriffsberechtigung angepaßt: 5

9 $ sudo chmod 0600./awsmanager-key-pair-ireland.pem Mit folgendem Aufruf wird nun die SSH Verbindung hergestellt: $ ssh -i./awsmanager-key-pair-ireland.pem <user>@<hostname> Der Benutzername <user> für die SSH Verbindung mit der Amazon Linux AMI Instance ist ec2-user. Der <hostname> kann entweder die Public IP oder die Public DNS der Instance sein. Beide werden unter EC2 Instances Instances im Reiter Description für die Instance angezeigt. Hier ist das Beispiel einer erfolgreichen Sitzung gezeigt: _ ) _ ( / Amazon Linux AMI \ 3 package(s) needed for security, out of 10 available Run "sudo yum update" to apply all updates. [<user>@<private-ip> ~]$ logout Connection to <hostname> closed. Über die SSH Sitzung kann nun auf der Instance gearbeitet werden. Wird primär Zugriff auf das Dateisystem der Instance benötigt, bietet sshfs eine einfachere Lösung. Mit sshfs kann das Dateisystem direkt auf dem lokalen Rechner gemountet werden. Sofern es nicht bereits installiert ist, kann dies mit $ sudo apt-get install sshfs nachgeholt werden. Als Beispiel wird hier das gesamte Dateisystem der Instance im lokalen Verzeichnis /media/instance gemountet 3 : $ sudo mkdir /media/instance $ sudo chmod ugo+rw /media/instance $ sshfs <user>@<hostname>:/ /media/instance -o \ IdentityFile=./awsmanager-key-pair-ireland.pem Das Lesen und Schreiben geschieht dann wie mit dem lokalen Dateisystem in gewohnter Art: $ ls /media/instance bin etc lib64 media proc selinux tmp boot home local mnt root srv usr dev lib lost+found opt sbin sys var 3 Tritt der Fehler read: Connection reset by peer auf, kann es helfen den Pfad zum Schlüssel beim Aufruf von sshfs absolut anzugeben 6

10 3. Zugriff auf die Amazon Web Services 3.1. Zugriff per CLI Die Amazon Web Services lassen sich nicht nur über die AWS Management Konsole steuern, sondern mit den Amazon EC2 API Tools auch per Command Line Interface (CLI). Die Tools können direkt über die folgende URL heruntergeladen werden: Die Installation unter Linux aus dem Download-Ordner heraus geschieht wie folgt: $ unzip./ec2-api-tools.zip $ sudo mv./ec2-api-tools-* /opt/ec2-opt-tools Für die Nutzung der Tools sind zusätzliche Umgebungsvariablen zu setzen. Um dies für jede Terminal-Sitzung automatisch durchzuführen, kann ~/.bashrc wie folgt ergänzt werden: source ~/setup_ec2_tools.sh <aws_access_key> <aws_secret_key> Hier wird ein Shell-Skript (siehe Anlage 14) verwendet, welches die notwendigen Aktionen automatisch durchführt. Die Platzhalter <aws_access_key> und <aws_secret_key> müssen mit den erhaltenen Access Credentials des Benutzers ersetzt werden. In einer neuen Terminal-Sitzung, können die Tools dann direkt genutzt werden. Die Installation kann mit $ ec2-version geprüft werden. Als Ausgabe wird die Version der Tools ausgegeben, in diesem Fall Mit den Tools kann nun jede Aktion, die auch über die AWS Management Konsole möglich wäre, ausgeführt werden. Zum Beispiel können über $ ec2-describe-instances --region eu-west-1 die Eigenschaften der zuvor erzeugten Instance ermittelt werden. Die Ausgabe (gekürzt) ist in diesem Fall: RESERVATION r-6e INSTANCE i-a3806ded ami-5256b BLOCKDEVICE /dev/sda1 vol-4fb1531b... NIC eni-f9cb92bf subnet-986c38de Mit der erhaltenen Instance ID (hier i-a3806ded) kann nun mit der Instance gearbeitet werden. Zum Beispiel kann die Instance gestoppt 7

11 $ ec2-stop-instances i-a3806ded --region eu-west-1 INSTANCE i-a3806ded running stopping und wieder gestartet werden $ ec2-start-instances i-a3806ded --region eu-west-1 INSTANCE i-a3806ded stopped pending Eine vollständige Übersicht und Beschreibung der verfügbaren Befehle findet sich in [Amazon, 2013b, Kapitel Commands (CLI Tools) ]. Die Tools bieten dem Benutzer die Möglichkeit, die Amazon Web Services per Command Line Interface zu verwalten. Damit lassen sich nun auch einfache Aufgaben automatisieren. Für eine komfortable Automatisierung ist der Ansatz allerdings nur bedingt geeignet, da alle Rückgaben über das Parsing der Textausgabe erhalten werden müssen. Für solche Aufgaben bietet sich die direkte Nutzung der Web Service API an, welche auch von den Amazon EC2 API Tools genutzt wird Zugriff über Web Service API Das Cloud-Angebot ist auch als Web Service verwendbar. Die Nutzung erfolgt dann über die Web Service API. Die Kommunikation findet über HTTP oder HTTPS statt. Die ausgehenden Daten werden als GET Parameter gesendet und die Antworten im XML Format empfangen 4. Die URL für die GET Anfragen wird auch Endpoint genannt. Die EC2 Funktionalität ist beispielsweise über den folgenden allgemeinen Endpoint nutzbar: Nicht immer ist ein solcher allgemeiner Endpoint verfügbar. Für jede Funktionalität existiert in der Regel eine Anzahl unterschiedlicher Endpoints, wobei jeder Endpoint einer Region zugeordnet ist [Amazon, 2014, Kapitel Regions and Endpoints ]. Dies wird genutzt, um bei der Arbeit mit den Web Services die Latenzzeiten zu minimieren, indem die Kommunikation mit einer günstig gelegenen Region erfolgt Zugriff via Python Der Zugriff auf die Web Services soll anhand der Skriptsprache Python für ein Debian Linux System gezeigt werden. Eine funktionsfähige Installation von Python wird hierbei vorausgesetzt. Hier wird Python Version verwendet. Zusätzlich wird das Python Package Management System pip verwendet. Falls es noch nicht installiert ist, kann dies mit $ sudo apt-get install python-pip 4 Weitere Details sind in [Amazon, 2013d, Kapitel Structure of a GET Request ] beschrieben. 8

12 nachgeholt werden. Im nächsten Schritt wird das Python Package Boto installiert. Dies geschieht mit 5 : $ sudo pip install boto Mit den Access Credentials des Benutzers muss das Boto Package konfiguriert werden. Dazu wird die Datei ~/.boto mit folgendem Inhalt erstellt, wobei die Platzhalter <aws_access_key> und <aws_secret_key> mit den Access Credentials ersetzt werden: [Credentials] aws_access_key_id = <aws_access_key> aws_secret_access_key = <aws_secret_key> Anschließend kann man mit Python auf die Web Services zugreifen. #! / u s r / b i n / python import import boto. ec2 s y s d e f s t a r t ( i n s t a n c e ) : i f i n s t a n c e. s t a t e!= r u n n i n g : p r i n t S t a r t i n g i n s t a n c e ID, i n s t a n c e. i d i n s t a n c e. s t a r t ( ) e l s e : p r i n t I n s t a n c e ID, i n s t a n c e. id, (, i n s t a n c e. i p a d d r e s s, ) a l r e a d y r u n n i n g d e f stop ( instance ) : i f i n s t a n c e. s t a t e!= s t o p p e d : p r i n t S t o p p i n g i n s t a n c e ID, i n s t a n c e. i d i n s t a n c e. s t o p ( ) e l s e : p r i n t I n s t a n c e ID, i n s t a n c e. id, (, i n s t a n c e. i p a d d r e s s, ) a l r e a d y s t o p p e d d e f s t a t e ( i n s t a n c e ) : p r i n t I n s t a n c e ID, i n s t a n c e. id, (, i n s t a n c e. i p a d d r e s s, ) i s, i n s t a n c e. s t a t e # e v a l u a t e arguments and s e l e c t a c t i o n to be p e r f o r m e d on a l l i n s t a n c e s t r y : i f l e n ( s y s. a r g v ) > 2 : r a i s e E x c e p t i o n ( Too many arguments ) e l s e : i f l e n ( s y s. a r g v ) == 2 : a c t i o n = { s t a r t : s t a r t, s t o p : stop, s t a t e : s t a t e } [ s y s. a r g v [ 1 ]. l o w e r ( ) ] e l s e : a c t i o n = s t a t e except : p r i n t Usage : i n s t a n c e s. py [ s t a r t s t o p s t a t e ] s y s. e x i t ( 0 ) # i t e r a t e t h r o u g h r e g i o n s and i n s t a n c e s and p e r f o r m t h e s e l e c t e d a c t i o n r e g i o n s = boto. ec2. r e g i o n s ( ) f o r r e g i o n i n r e g i o n s : p r i n t Looking f o r i n s t a n c e s i n, r e g i o n. name t r y : i n s t a n c e s = boto. ec2. c o n n e c t t o r e g i o n ( r e g i o n. name ). g e t o n l y i n s t a n c e s ( ) f o r i n s t a n c e i n i n s t a n c e s : a c t i o n ( i n s t a n c e ) except : p r i n t A c c e s s d e n i e d o r o p e r a t i o n f a i l e d Abbildung 7: instances.py Das Python Skript in Abbildung 7 zeigt ein Beispiel dafür. Es dient dazu, alle Instances in allen Regionen zu starten bzw. zu stoppen oder ihren Status anzuzeigen. Weitere Details zur API des Boto Package finden sich unter:

13 3.4. Zugriff über die REST API Ein spezieller (aber in der Praxis bedeutsamer) Fall ist die Nutzung der Web Service API aus einer laufenden Instance heraus. Dabei ist es oft notwendig, Informationen zur eigenen (der ausführenden) Instance zu ermitteln. Die REST API bietet eine einfache und plattformunabhängige Methode dazu. Der Zugriff auf die REST API erfolgt durch HTTP Anfragen (z.b. mit wget oder curl) an die URL: Die hier verwendete IP gehört zu den Amazon Web Services und kann nur von IP Adressen aus dem Pool der Amazon Web Services genutzt werden. Die über die REST API verfügbaren Daten sind in einer baumartigen Struktur organisiert, die über Pfadangaben traversiert wird. Beispielsweise kann die Instance ID der ausführenden Instance über die URL ermittelt werden. Die typische Nutzung in der Shell sieht wie folgt aus: $ baseurl=" $ instanceid=$(curl -s $baseurl/meta-data/instance-id) $ echo $instanceid i-a3806ded In Python erlaubt das requests Package eine ähnlich komfortable Arbeit mit der REST API. 4. Anbindung von zusätzlichem Speicher Mit der Erzeugung der Instance wurde automatisch ein virtueller Speicher, ein sog. Volume, als Root-Gerät-Datenträger erzeugt und mit der Instance verknüpft [Amazon, 2013c, Seite 7ff]. Er enthält das Amazon Machine Image (AMI) der Instance. Aus dem Amazon Elastic Block Store (Amazon EBS) kann zusätzlicher Speicher bezogen und als Volume mit der Instance verknüpft werden. Über ssh werden zunächst die verfügbaren Volumes auf der Instance bestimmt: $ cat /proc/partitions major minor #blocks name xvda1 Hier ist am Anfang nur der Root-Gerät-Datenträger als Volume xvda1 verfügbar. Mit dem Python Skript 15 (siehe Anhang) kann nun vom lokalen Rechner aus ein weiteres 1 GiB Volume erzeugt und mit der Instance verbunden werden: 10

14 $./add_volume.py eu-west-1 i-a3806ded 1 Looking up region eu-west-1 Connecting to region eu-west-1 Looking up instance ID i-a3806ded Looking for unused device identifier Selected unused device identifier /dev/sdb Creating a new volume of size 1 GiB in zone eu-west-1b Attaching volume vol-690de03d to instance i-a3806ded as /dev/sdb Volume /dev/sdb ready for use Das hinzugefügte Volume ist über ssh direkt als xvdb erkennbar: $ cat /proc/partitions major minor #blocks name xvda xvdb Um das Volume verwenden zu können, werden jetzt folgende Schritte durchgeführt: 1. Partitionierung des Volumes 2. Erzeugung der Dateisysteme 3. Mounten der Dateisysteme Die Partitionierung kann mit parted durchgeführt werden Clausen [2012]. Als Beispiel wird der Datenträger hier in 2 primäre Partitionen zu je ca. 500MB aufgeteilt: $ sudo parted /dev/xvdb mklabel gpt $ sudo parted /dev/xvdb mkpart primary 1 500M $ sudo parted /dev/xvdb mkpart primary 500M 1G Das Ergebnis (gekürzt) sieht dann wie folgt aus: $ sudo parted -l Modell: Xen Virtuelles Blockorientiertes Gerät (xvd) Festplatte /dev/xvdb: 1074MB Sektorgröße (logisch/physisch): 512B/512B Partitionstabelle: gpt Nummer Anfang Ende Größe Dateisystem Name Flags kB 500MB 499MB primary 2 500MB 1073MB 573MB primary 11

15 Wie bei /dev/xvda1 wird nun ein ext4 Dateisystem auf den Partitionen eingesetzt. Das Dateisystem wird wie folgt erzeugt: $ sudo mkfs.ext4 /dev/xvdb1 $ sudo mkfs.ext4 /dev/xvdb2 Jetzt können die Dateisysteme gemountet werden: $ sudo mkdir /mnt/xvdb1 $ sudo mkdir /mnt/xvdb2 $ sudo chmod ugo+rw /mnt/xvdb1 $ sudo chmod ugo+rw /mnt/xvdb2 $ sudo mount -t auto /dev/xvdb1 /mnt/xvdb1 $ sudo mount -t auto /dev/xvdb2 /mnt/xvdb2 Damit werden die Dateisysteme auch in der Liste der gemounteten Dateisysteme geführt: $ mount -l /dev/xvda1 on / type ext4 (rw,noatime) [/]... /dev/xvdb1 on /mnt/xvdb1 type ext4 (rw) /dev/xvdb2 on /mnt/xvdb2 type ext4 (rw) Die Dateisysteme unter /mnt/xvdb1 und /mnt/xvdb2 lassen sich nun wie gewohnt nutzen. 5. Nutzung von Netzwerkresourcen 5.1. Webserver installieren Über ein ssh Terminal wird der Apache Webserver auf einer Instance installiert [Amazon, 2013d, Seite 31ff]: $ sudo yum install httpd.x86_64 Um den Webserver zu testen, wird unterhalb von /var/www/html eine Datei index.html mit folgendem Inhalt erzeugt: <html> <head> <title>apache Web Server</title> </head> <body> <h1>apache Web Server</h1> </body> </html> 12

16 Der Webserver wird danach gestartet: $ sudo service httpd start Starting httpd: [ OK ] $ sudo service httpd status httpd (pid 1340) is running... Mit der vorkonfigurierten Einstellung 6 ist über die Public IP der Instance und Port 80 jetzt die Datei index.html abrufbar (siehe Abbildung 8). Abbildung 8: Auf der Instance laufender HTTP Webserver Bei einem Neustart der Instance wird der Webserver nicht automatisch wieder gestartet. Dies kann aber durch Anpassung der Datei /etc/rc.local erreicht werden. Es wird dazu folgendes Kommando angehängt: apachectl -f /etc/httpd/conf/httpd.conf -k start Bei jedem Start der Instance wird nun auch der Webserver automatisch gestartet Elastic IPs Mit jedem Start einer Instance wird ihr aus einem Pool eine neue Public IP zugeteilt. Mit dem Stoppen oder der Zerstörung der Instance geht diese Public IP wieder verloren. Da dies insbesondere für den Betrieb eines Webservers unpraktisch ist, besteht die Möglichkeit statische IP Adressen zu allokieren, die unabhängig von einer Instance existieren. Diese sog. Elastic IPs [Amazon, 2013d, Seite 427ff] können einer beliebigen Instance zugeordnet und auch an wechselnde Instances vergeben werden. Dies wird in diesem Beispiel genutzt, um den Webserver über eine statische IP verfügbar zu machen, die redundant von mehreren Instances bedient werden kann. 6 Änderungen an den vorkonfigurierten Einstellungen lassen sich bei Bedarf in /etc/httpd/conf/httpd.conf vornehmen. 13

17 5.3. Tags und Filters Instances können mit zusätzlichen Meta-Informationen (sog. Tags) verknüpft werden. Auch andere Resourcen lassen sich mit Tags verknüpfen. Eine Übersicht ist in [Amazon, 2013d, Seite 539] gegeben. Tags sind benutzerdefinierbare Schlüssel-Wert-Paare, die besonders für die programmatische Arbeit hilfreich sind. Sie können zum Beispiel das Ordnen und Auffinden von Resourcen erleichtern oder deren Zustand kennzeichnen. Unterstützt wird die programmatische Arbeit mit Tags durch das Konzept der Filter. Filter werden nicht exklusiv für Tags, aber häufig in Kombination mit diesen verwendet. Sie können bei vielen Funktionen der Web Service API angegeben werden, um die Ergebnismenge einzuschränken. Mit DescribeInstances [Amazon, 2013a, Seite 202ff] können zum Beispiel nur diejenigen Instances mit einem bestimmten Schlüssel-Wert-Paar als Tag ermittelt werden. In folgendem Beispiel in Python wird ein Filter genutzt, um nur diejenige Instance 7 in der Region eu-west-1 zu liefern, bei welcher der Tag name auf saturn gesetzt ist: import boto. ec2 i n s t a n c e = boto. ec2. c o n n e c t t o r e g i o n ( eu west 1 ). \ g e t o n l y i n s t a n c e s ( None, { tag : name : s a t u r n }) [ 0 ] 5.4. Instances klonen Ist eine Instance fertig eingerichtet und wie gewünscht konfiguriert, kann sie geklont werden, um weitere identische Instances von ihr abzuleiten. Dazu wird zunächst ein sog. Snapshot des Root Volumes der Instance erzeugt. Ein Snapshot ist ein (inkrementelles) Backup des Volumes, das in sog. Amazon S3 Speicher abgelegt wird [Amazon, 2013d, Seite 518ff]. Aus dem Snapshot wird dann ein AMI erstellt, das als Vorlage bei der Erzeugung einer neuen Instance verwendet werden kann. Beide Schritte lassen sich wie folgt gemeinsam ausführen: In der AWS Management Konsole wird unter EC2 Instances Instances die gewünschte Instance ausgewählt. Über Actions Create Image kann jetzt aus der Instance ein neues AMI erzeugt werden: 7 Existenz und Eindeutigkeit des Schlüssel-Wert-Paares wird hier vorausgesetzt. 14

18 Abbildung 9: Erzeugung eines neuen Images Sobald das AMI erstellt wurde, wird es unter EC2 Images AMIs gelistet. Beim Erzeugen einer neuen Instance über Launch Instance unter EC2 Instances Instances kann dieses AMI dann unter My AMIs als Vorlage ausgewählt werden. Abbildung 10: Erzeugung einer Instance aus einem Image 5.5. Standby-Redundanz mit mehreren Instances Das Python Skript im Anhang (siehe Anlage 16) realisiert für mehrere Instances eine Standby- Redundanz um eine einzelne Elastic IP (siehe Abbildung 11). Das Skript läuft auf den jeweiligen Instances und funktioniert wie folgt: Jede betriebsbereite Instance wird im Skript in einer Liste gehalten. Alle betriebsbereiten Instances in der Liste überwachen sich gegenseitig. Fällt eine Instance aus, wird sie neugestartet. War der ausgefallenen Instance die Elastic IP zugeordnet, wird sie von der Instance übernommen, welche den Ausfall festgestellt hat. Das Skript nutzt dazu zwei Tags: Der Tag mit dem Schlüssel eip 15

19 wird verwendet, um alle diejenigen Instances zu finden, welche einer gemeinsamen Elastic IP zugeordnet sind. Der Tag mit dem Schlüssel observer gibt an, ob sich das Skript auf der Instance in Ausführung befindet (running) oder beendet/gestoppt wurde (stopped). Damit wird die Betriebsbereitschaft der Instance angezeigt. Abbildung 11: Schematische Funktionsweise des Skripts in Anlage 16 für 2 Instances 5.6. Lastverteilung über einen Load Balancer Die Ausnutzung der Recheneinheiten ist bei einer Standby-Redundanz nicht optimal, da die im Standby gehaltenen Recheneinheiten im Normalbetrieb ungenutzt bleiben. In der Praxis werden daher sog. Load Balancer eingesetzt, welche die Netzwerklast auf eine Menge an Recheneinheiten verteilen. Jede der Recheneinheiten ist im Normalbetrieb an der Verarbeitung der Netzwerklast beteiligt. Der Ausfall einer Recheneinheit wird vom Load Balancer kompensiert, in dem die Netzwerklast auf die verbliebenen Recheneinheiten verteilt wird. Die Amazon Web Services verfügen mit dem Elastic Load Balancing über eine solche Funktionalität. Die Netzwerklast läßt sich damit innerhalb einer Region auf mehrere Instances verteilen (die in verschiedenen Availability Zones liegen können) [Amazon, 2012, Seite 4ff]. Über einen Health Check läßt sich die Einsatzbereitschaft der Instances (z.b. des Webservers) vom Load Balancer überwachen [Amazon, 2012, Seite 8]. Beispielhaft soll hier ein solcher Load Balancer erzeugt und getestet werden. Mit dem Load Balancer soll die Netzwerklast für Port 80 (HTTP) auf zwei Instances in den Availability Zones eu-west-1a und eu-west-1b verteilt werden. Um erkennen zu können, welche Instance die Kommunikation verarbeitet, soll die jeweilige Instance ID über SSI vom Webserver ausgeliefert werden. 16

20 Zunächst werden zwei Instances aus dem benutzerdefinierten AMI in den Availability Zones eu-west-1a und eu-west-1b erzeugt und gestartet. Für jede Instance wird für den Webserver SSI aktiviert und der Index auf index.shtml erweitert. Dazu wird die Konfiguration /etc/httpd/conf/httpd.conf wie folgt ergänzt: <Directory "/var/www/html"> Options Includes </Directory>... DirectoryIndex index.shtml... Jetzt kann die Datei index.shtml erzeugt werden: <html> <head><title>apache Web Server</title></head> <body> <h1>apache Web Server</h1> Running on instance <!--#set var="baseurl" value=" --> <!--#exec cmd="curl -s $baseurl/meta-data/instance-id" --> </body> </html> Nach dem Neustart des Webservers mit $ sudo service httpd restart Stopping httpd: [ OK ] Starting httpd: [ OK ] wird die jeweilige Instance ID angezeigt. Diese Schritte werden für die zweite Instance wiederholt. Abbildung 12 zeigt das Ergebnis: Abbildung 12: Webserver mit aktivierter SSI Unterstützung 17

21 Im nächsten Schritt wird der Load Balancer in der AWS Management Konsole erzeugt. Dies geschieht über Create Load Balancer in EC2 Network & Security Load Balancers. Der Load Balancer ist in Abbildung 13 gezeigt: Abbildung 13: Erzeugter Load Balancer Der erzeugte Load Balancer kann dann über den zugeteilten DNS Namen erreicht werden, in diesem Fall load-balancer eu-west-1.elb.amazonaws.com Dazu müssen die Instances vom Health Check als einsatzbereit erkannt sein. Der Health Check des Load Balancers funktioniert nach dem gleichen Prinzip wie im bereits vorgestellten Skript: Durch zyklische Abfrage (hier: 0,5 Minuten) der Webserver auf den Instances wird deren Funktionsfähigkeit geprüft. Ab einer Schwelle erfolgreicher Abfragen (hier: 4 Abfragen) wird die Instance als einsatzbereit angesehen. Die Instance wird dann in die Menge der Instances, die zur Verarbeitung der Netzwerklast genutzt werden, aufgenommen. Ab einer Schwelle erfolgloser Abfragen (hier: 2 Abfragen) wird die Instance aus dieser Menge wieder entfernt. Getestet wird der Load Balancer beispielsweise mit telnet, in dem mehrere Verbindungen wie folgt aufgebaut werden: 18