Categories
Grundlagen Services @de

Der Amazon EC2 Instanzspeicher

Jede Instanz verfügt über eine festen Speicherplatz, auf dem Daten gespeichert werden können. Dieser wird im EC2 Kontext als Instanzspeicher bezeichnet und ist nicht als permanente Speicherlösung gedacht.

Wird eine Instanz neu gestartet, bleiben die Daten auf dem Instanzspeicher bestehen. Wird die Instanz higegen beendet, gestoppt oder ein Fehler tritt auf, dann sind die Daten verloren.

Für den Einsatz einer dauerhaften Speicherlösung empfiehlt Amazon daher Amazon Elastic Block Store.

Sollte Amazon EBS nicht eingesetzt werden, sollten wichtige Daten auf Amazon S3 gesichert werden.

Speicherort

Wo sich der Speicher auf den jeweiligen Instanz Typen befindet, kann der folgenden Tabelle entnommen werden.

Ort
Beschreibung
/dev/sda1 Auf allen Linux/Unix Instanz Typen als root (/) formatiert und gemounted. Auf allen Windows Instanz Typen als C: formatiert und gemounted.
/dev/sda2 oder xvdb (Windows) Auf allen m1.small und c1.medium Instanzen als /mnt formatiert und gemounted. Auf allen small Windows Instanzen formatiert und gemounted.
/dev/sda3 Auf allen m1.small und c1.medium Instanzen für Linux/Unix Instanz Typen als /swap formatiert und gemounted. Für Windows Instanzen nicht verfügbar.
/dev/sdb oderr xvdb (Windows) Auf allen m1.large, m1.xlarge, c1.xlarge, m2.xlarge, m2.2xlarge, und m2.4xlarge Instanzen für Linux/Unix Instanz Typen als /mnt formatiert und gemounted. Für alle m1.large, m1.xlarge, c1.xlarge, m2.xlarge, und m2.2xlarge Windows Instanzen formatiert und gemounted.
/dev/sdc oder xvdc (Windows) Verfügbar auf m1.large, m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.large, m1.xlarge, c1.xlarge und m2.4xlarge Windows Instanzen formatiert und gemounted.
/dev/sdd or xvdd (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/UNIX Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.
/dev/sde or xvde (Windows) Verfügbar auf m1.xlarge und c1.xlarge Linux/Unix Instanzen. Auf m1.xlarge und c1.xlarge Windows Instanzen formatiert und gemounted.

Quelle

Categories
Grundlagen Services @de

Amazon Machine Images (AMI)

Eine Amazon EC2 Instanz kann auf Basis eines Amazon Machine Image (AMI) welches sich in Amazon EBS befindet oder eines AMI welches in Amazon S3 gespeichert ist gestartet werden. Dabei verwenden Instanzen, bei denen die AMIs in Amazon EBS gespeichert sind, EBS Volumes als Root Device (von wo gebooted wird). Dagegen nutzen Instanzen, deren AMIs in Amazon S3 abgelegt sind einen Instanzspeicher als das Root Device.

Die folgende Tabelle beschreibt die Unterschiede zwischen AMIs die in Amazon EBS abgelegt sind und AMIs die sich in Amazon S3 (Instanzspeicher) befinden.

Eigenschaften
Amazon EBS
Amazon S3 (Instanzspeicher)
Bootzeit Gewöhnlich weniger als 1 Minute. In der Regel weniger als 5 Minuten.
Größenbeschränkung 1 Terrabyte (TB) 10 Gigabyte (GB)
Speicherort Amazon EBS volume Instanzspeicher
Datenpersistenz Die Daten bleiben vorhanden, wenn die Instanz ausfällt und können gespeichert werden, wenn die Instanz beendet wird. Die Daten bleiben nur für die Lebensdauer der Instanz erhalten.
Erweiterung Der Instanz-Typ, Kernel, die RAM Disk und die Benuterdaten können geändert werden, während die Instanz gestoppt (angehalten) ist. Die Attribute einer Instanz sind für ihre Lebensdauer festgesetzt und können währenddessen nicht geändert werden.
Kosten Instanz Nutzung, Amazon EBS Volume Nutzung und Amazon EBS Snapshot Kosten zum Speichern der AMI. Instanz Nutzung und Amazon S3 Kosten zum Speichern der AMI.
AMI Erstellung / Bundling Verwendet einen einzigen Befehl / Anweisung Erfordert die Installation und die Nutzung der AMI Tools
Stoppen / Anhalten Kann in den Zustand “angehalten” überführt werden, wenn eine Instanz nicht ausgeführt wird, aber in Amazon EBS gespeichert ist. Kann nicht gestoppt werden, Instanzen werden ausgeführt oder nicht.

Öffentliche AMIs können direkt über Amazon oder die Amazon EC2 Community bezogen werden. Öffentliche AMIs dienen als Basis und können dazu benutzt werden, um eigene maßgeschneidert AMIs zu erstellen.

Private AMIs sind AMIs die einem selbst gehören. Auf diese kann daher nur selbst bzw. von Leuten zugegriffen werden, denen man den Zugriff erlaubt hat.

Shared AMIs werden von Entwicklern erstellt und anderen Entwicklern für die Nutzung zur Verfügung gestellt.

Paid AMIs können von Entwicklern oder Unternehmen wie z.B. RedHat gekauft werden. Es existieren ebenfalls AMIs die an spezielle Serviceverträge gekoppelt sind.

Quelle

Categories
Analysen

Klassischer Fall für den Einsatz von Cloud Computing (ZDF – WM 2010)

Heute haben wir es wieder einmal Live miterlebt. Ein klassisches Szenario, wo Cloud Computing hätte helfen können. Das ZDF übertrug das WM Spiel Deutschland gegen Serbien ab 13:30 Uhr, also zu einer Uhrzeit wo die Vielzahl der Menschen in Deutschland arbeiten muss.

Parallel zur Fernsehübertragung existiert(e) ganz modern ebenfalls ein Live Stream, erreichbar über die Internetseite des ZDF – http://zdf.de. Die Vorberichte des Spiels wurden stabil übertragen. Es wurde nicht einmal der Eindruck vermittelt, einen Internet Stream zu sehen. Doch bereits während der Nationalhymnen zeigte sich grausames!

.

ERROR

The requested URL could not be retrieved


While trying to retrieve the URL: http://www.zdf.de

The following error was encountered:

  • Unable to forward this request at this time.

Footprint 4.6/FPMCP
Generated Fri, 18 Jun 2010 11:46:18 GMT by 4.23.38.126 (Footprint 4.6/FPMCP)

.

Heißt, die Systeme sind auf Grund zu vieler Anfragen überlastet, wodurch eine Antwort nicht möglich ist!

Das hätte nicht passieren müssen! Durch den Einsatz von Cloud Computing Technologien hätten hier präventive Maßnahmen ergriffen werden können, indem auf eine automatische Skalierbarkeit der Infrastruktur und Systeme geachtet worden wäre. Ausreichend Zeit war vorhanden, eine Fußball Weltmeisterschaft steht schließlich nicht plötzlich vor der Tür.

Weitere Informationen gibt es z.B. unter Autoscaling und Cloud Computing Nutzen: Bereitstellung von Medieninhalte.

Categories
Grundlagen Services @de

Der Amazon EC2 Workflow

Die folgende Graphik verdeutlicht den grundsätzlichen Ablauf zum Verwenden von Amazon EC2.

  • 1. Zunächst wird ein AMI (Amazon Machine Image) von Grund auf neu, oder auf Basis eines bereits vorhandenen AMIs erstellt. Dieser Vorgang ist optional, da Instanzen aus bereits vorhandenen AMIs gestartet werden können, ohne diese vorab zu verändern.
  • 2. Für ein AMI das einen lokalen Instanzspeicher für sein Root Device verwendet, muss der Prozess zum bundlen und registrieren des AMIs erfolgen. Für ein AMI hingegen, dass ein Amazon EBS Volume verwendet, reicht es aus, den create Image Befehl auf einer bereits gestarteten Instanz auszuführen. Amazon EC2 gibt anschließend eine AMI ID zurück, wodurch auf Basis des AMI so viele Instanzen wie gewünscht gestartet werden können.
  • 3. Starten einer oder mehrerer Instanzen eines AMI.
  • 4. Verwalten und verwenden der Instanzen als wären es gewöhnliche Server.

Quelle

Categories
Tutorials @de

Amazon EC2 mit Ubuntu Images (erste Schritte)

Dieser Artikel beschreibt die Nutzung der offiziellen Ubuntu Images unter Amazon EC2.

Um die Ubuntu Server Edition unter den Amazon Web Services auszuführen, sind folgende Schritte notwendig.

  • Erstellen eines Amazon Web Services Account
  • Konfigurieren der Keys
  • Installation der Amazon EC2 API Tools
  • Instanziierung der Images
  • Konfiguration der Instanz
Categories
Grundlagen Services @de

Das Konzept der Amazon Virtual Private Cloud

Bei der Amazon Virtual Private Cloud (VPC) handelt es sich um eine sichere und lückelose Integrationsmöglichkeit zwischen der bereits vorhandenen IT Infrastruktur eines Unternehmens und der Amazon Cloud und dient zum Aufbau einer Hybrid Cloud. Mit Amazon VPC können Unternehmen ihre existierende Infrastruktur mit speziell isolierten AWS Ressourcen mittel eines Virtual Private Network (VPN) verbinden, um damit die Verwaltungsmögklichkeiten wie die Bereiche Sicherheit, Firewall und Intrusion Dection für die AWS Ressourcen zu erweitern.

Um die Amazon Virtual Private Cloud zu nutzen, muss zunächst der IP-Adressraum für die VPC festgelegt werden. Die IP-Adressen innerhalb dieses Adressraums sind privat und bilden ein Netzwerk das mittels paketbasierten Routing von anderen Netzwerken inkl. dem Internet vollständig isoliert ist.

Als nächstes müssen Subnetze erstellt werden, welche Segmente eines VPC IP-Adressraums sind. Damit können die Amazon EC2 Instanzen innerhalb des VPC separiert und sicher betrieben werden. Existiert mehr als ein Subnetz in einem VPC, werden diese mittels eines logischen Routers sternförmig (Stern-Topologie) miteinander verbunden.

Um sich mit der VPC zu verbinden, wird eine VPN Verbindung benötigt, die als VPN Tunnel zwischen der VPC und dem Rechenzentrum, dem Heimnetzwerk oder jeder anderen Co-Location dient. Dazu muss das eigene bestehende Netzwerk so konfiguriert werden, dass jeglicher VPC Datenverkehr zu dem Gateway geroutet wird, welches das Ende der VPN Verbindung darstellt.

Mit einer aktiven VPN Verbindung können anschließend Amazon EC2 Instanzen in einem VPC subnetz starten. Mit den entsprechenden Sicherheitsrichtlinen ist diese Instanz dann ebenfalls im eigenen Netzwerk sichtbar und kann von dort aus wie eine “lokale” Instanz genutzt werden.

VPC basierter Datenverkehr der für das Internet bestimmt ist, wird zunächst automatisch über das VPN in das eigene Netzwerk gerouted. Dort kann dieser von bereits vorhandenen Sicherheitssystemen, wie Firewalls, Intrusion Detection Systemen untersucht werden, bevor die Daten in das Internet weitergeleitet werden. Das ist dann besonders sinnvoll, wenn spezielle Hardware- und Softwaresysteme eingesetzt werden, um bestimmte Sicherheitsrichtlinien zu erfüllen.

Quelle

Categories
Services @de

Die Amazon S3 Konsole

Mit der Amazon S3 Konsole hat Amazon seine AWS Management Console erweitert. Wie schon von den bisherigen Konsolen, wie z.B. der für EC2 bekannt, handelt es sich um eine Weboberfläche, mit der sämtliche Amazon S3 Ressourcen verwaltet werden können. Dazu gehören das Erstellen neuer Buckets sowie das Hochladen von Objekten.

Um die Amazon S3 Konsole zu nutzen, reicht es aus sich mit seinem AWS Benutzeraccount und dem dazugehörigen Passwort anzumelden. Die Access Key ID und der Secrect Access Key werden nicht benötigt, diese werden automatisch durch AWS im Hintergrund geladen.

Damit integriert die AWS Management Console mit Amazon S3, Amazon EC2, Amazon CloudFront, Amazon Elastic MapReduce und Amazon RDS nun fünf Services an einer zentralen Stelle.

Mit der Amazon S3 Konsole können weiterhin Ordner angelegt, sowie Objekte der Öffentlichkeit zugänglich gemacht werden. Ordner und Objekte die mit S3 Tools von einem Drittanbieter erstellt wurden, können mit der Konsole ebenfalls bearbeitet werden.

Die Amazon S3 Konsole ist unter http://console.aws.amazon.com/s3 zu finden.

Categories
Tutorials @de

UEC: Zusammenstellen von Images für Ubuntu 9.10

Dieser Artikel beschreibt das Vorgehen (Bundling) für das Erstellen und die Registrierung von VM Images mit dem UEC Cloud Controller für Ubuntu 9.10. Dazu benötigen wir ein Image, dass von den Daily Builds heruntergeladen werden kann, verknüpfen alles miteinander und laden es in unsere Ubuntu Cloud.

1. Um den Vorgang von der Kommandozeile aus zu starten nutzen wird die folgenden Befehle. Hierbei wird automatisch ein UEC Image heruntergeladen.

TIMESTAMP=$(date +%Y%m%d%H%M%S)
RELEASE=karmic
ARCH=amd64 # Or this might be i386
[ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
UEC_IMG=$RELEASE-server-uec-$ARCH
URL=http://uec-images.ubuntu.com/$RELEASE/current/
[ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz # This may take a bit, depending on your connectivity

2. Als nächstes muss alles verpackt, hochgeladen und registriert werden. In dem Package cloud-utils befindet sich das Tool uec-publish-tarball. Mit diesem können die oben genannten Aktionen in einem Schritt durchgeführt werden. Weiterhin ist in den cloud-utils das Tool uec-publish-image vorhanden. Mit diesem kann direkt mit einem ungepackten Image gearbeitet werden.

uec-publish-tarball ${UEC_IMG}.tar.gz "${RELEASE}-${TIMESTAMP}" "${ARCH}"

Diese Schritte sind nur dann notwendig, wenn nicht das Tool uec-publish-tarball verwendet wird!

1. Entpacken des UEC Image Tarball

[ ! -e $UEC_IMG.img ] && tar -S -xzf $UEC_IMG.tar.gz

2. Zusammenstellen des Kernels

BUCKET_KERNEL="k-$TIMESTAMP"
UEC_KERNEL=$UEC_IMG-vmlinuz-virtual
euca-bundle-image -i $UEC_KERNEL -r $IARCH --kernel true
euca-upload-bundle -b $BUCKET_KERNEL -m /tmp/$UEC_KERNEL.manifest.xml
EKI=$(euca-register $BUCKET_KERNEL/$UEC_KERNEL.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EKI

3. Zusammenstellen der initrd (Wird nur benötigt, wenn keine Ramdisk vorhanden ist)

BUCKET_INITRD="r-$TIMESTAMP"
UEC_INITRD=$UEC_IMG-initrd-virtual
euca-bundle-image -i $UEC_INITRD -r $IARCH --ramdisk true
euca-upload-bundle -b $BUCKET_INITRD -m /tmp/$UEC_INITRD.manifest.xml
ERI=$(euca-register $BUCKET_INITRD/$UEC_INITRD.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $ERI

4. Zusammenstellen des Images

BUCKET_IMAGE="i-$TIMESTAMP"
UEC_IMG=$RELEASE-server-uec-$ARCH
euca-bundle-image -i $UEC_IMG.img -r $IARCH --kernel $EKI ${ERI:+--ramdisk ${ERI}} # This will take a long time (~10m)
euca-upload-bundle -b $BUCKET_IMAGE -m /tmp/$UEC_IMG.img.manifest.xml
EMI=$(euca-register $BUCKET_IMAGE/$UEC_IMG.img.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EMI

3. Damit ist der Kernel und das Image in unsere Ubuntu Cloud (Eucalyptus) hochgeladen worden und kann nun genutzt werden.

euca-describe-images

Wir sollten einen registrierten Kernel sowie ein Image sehen, die als “available” markiert sind.

Mit dem anschließenden Befehl können wir das überprüfen.

Quelle

Categories
Videos

Video: Automatische WordPress Aktualisierung mit mehr Speicher bei Rackspace

Dieses Video zeigt, wie sich WordPress automatisch mit mehr Speicher auf der Rackspace Cloud aktualisieren kann.

via YouTube

Categories
Tutorials @de

Eucalyptus: Erstellen eines Image aus einem ISO (Xen)

Dieser Artikel beschreibt, wie mittels Xen und dem ISO Image eines Gast Betriebssystems das installiert werden soll, ein Root Dateiystem für Eucalyptus erstellt wird.

Voraussetzung

  • Hardware Virtualisierung Unterstützung auf dem System (Hardware-assisted virtualization)
  • Funktionsfähige Xen Umgebung (domU muss gestartet werden können)