Tag: EC2


Amazon Web Services (AWS) präsentieren neuen EC2 High I/O Instanz-Typ mit 2 TB SSD Speicher. Netflix mit erstem Benchmark.

Immer mehr moderne Web- und mobile Applikationen sind von einem hohen I/O Durchsatz abhängig. Für das Darstellen umfangreicher Informationen und Graphiken sowie der Reaktion auf Interaktionen in Echtzeit, sind die Anwendungen darauf angewiesen eine Menge an Daten zu speichern und auf diese zuzugreifen. Die Amazon Web Services (AWS) haben nun darauf reagiert und gestern einen neuen EC2 Instanz-Typ für Anwendungen mit einem hohen I/O Durchsatz und einer geringen Latenz präsentiert. Nach Angaben von Amazon ist die Instanz ideal für den Einsatz von NoSQL Datenbanken wie Cassandra und MongoDB.

Amazon Web Services (AWS) präsentieren neuen EC2 High-Performance Instanz-Typ mit 2 TB SSD Speicher. Netflix mit erstem Benchmark.

Eigenschaften der High I/O EC2 Instanz

Die erste Instanz aus der neuen High I/O Reihe nennt sich High I/O Quadruple Extra Large (hi1.4xlarge) und verfügt über die folgende Spezifikation:

  • 8 virtuelle Kerne, insgesamt 35 ECU (EC2 Compute Units)
  • HVM und PV Virtualisierung
  • 60,5 GB RAM
  • 10 Gigabit Ethernet
  • 2TB lokaler SSD Speicher, ein Paar von jeweils 1TB

Die High I/O Quadruple Extra Large Instanzen stehen aktuell in den Regionen US East (Northern Virginia) und EU West (Ireland) bereit. Die Kosten betragen 3,10 Dollar bzw. 3,41 Dollar pro Stunde.

Netflix präsentiert ersten Benchmark

Netflix Cloud Architekt Adrian Cockcroft hatte bereits im März 2012 während eines Interviews darüber philosophiert, dass es in Zukunft schnellere I/O Mechanismen in der Cloud geben muss und hatte sich den Einsatz von SSDs (Solid-State-Drives) als Speichertechnologie für die Amazon Cloud gewünscht.

Nach Ankündigung der neuen Technologie, lies es sich Cockcroft natürlich nicht nehmen, eigene Test durchzuführen und hat dazu einen umfangreichen Benchmark veröffentlicht, der hier zu finden ist.

Neue EC2 Instance Status Metriken

Neben dem neuen High I/O Instanz-Typ hat AWS ebenfalls weitere Status Metriken für EC2 eingeführt. Es existieren zwei unterschiedliche Tests, die System Status Checks und Instanz Status Checks. Die Ergebnisse der Tests werden auf der AWS Management Console veröffentlicht und können ebenfalls über die Kommandozeile und den EC2 APIs abgerufen werden.

Zudem können die Metriken nun auch über Amazon CloudWatch abgefragt werden. Zu jeder Instanz gehören drei Metriken, die alle 5 Minuten aktualisiert werden:

  • StatusCheckFailed_Instance = "0" wenn der Instanz-Check positiv ist, ansonsten "1".
  • StatusCheckFailed_System = "0" wenn der System-Check positiv ist, ansonsten "1".
  • StatusCheckFailed = "0" wenn keiner der beiden oben genannten Wert "0" ist, sonst "1".


AWS Identity and Access Management (IAM) Rollen für EC2 Instanzen

Amazon erweitert seinen AWS Identity and Access Management (IAM) Service um Rollen für Amazon EC2 Instanzen. Das schreibt das Unternehmen auf seinem Blog. Die neue Funktion ermöglicht den sicheren API-Zugriff von Amazon EC2 Instanzen auf andere AWS Services.

Bisher mussten die Access Keys in irgendeiner Form sicher auf die EC2 Instanzen transportiert und dort hinterlegt werden. Das stellt insbesondere beim Aufbau großer skalierbarer Infrastrukturen eine Herausforderungen dar. Zudem muss sichergestellt werden, dass sich die Schlüssel regelmäßig ändern. Die neuen IAM Rollen für EC2 Instanzen kümmern sich ab sofort automatisch um beides. Dazu wird eine IAM Rolle erstellt und diese den entsprechenden Berechtigungen zugewiesen. Die EC2 Instanzen müssen anschließend mit dieser Rolle gestartet werden. Anschließend sorgt das System dafür, das die jeweiligen Access Keys mit den vorher zugewiesenen Berechtigungen auf den EC2 Instanzen hinterlegt sind.

IAM Rollen für EC2 Instanzen können mit folgenden Ressourcen genutzt werden:

  • Alle EC2 Instanten
  • Linux und Windows Instanzen
  • Alle AMIs
  • Amazon VPC
  • Spot und Reserved Instances
  • Regionen: Nordamerika, Südamerika, Europa, Asien/Pazifik

Das Rollenkonzept wurde ebenfalls in die Services Auto Scaling und AWS CloudFormation integriert, wodurch auch diese nun EC2 Instanzen inkl. IAM starten können. Die Unterstützung für AWS GovCloud wird demnächst folgen.


Bildquelle: http://www.busmanagement.com



Amazon hilft mit CloudFormation beim Aufbau einer Virtual Private Cloud

Die Amazon Web Services ermöglichen nun den automatisierten Aufbau einer vollständigen Virtual Private Cloud (VPC) auf Basis eines einzelnen AWS CloudFormation Templates. Laut Jeff Barr, beschreibt das Template alle Eigenschaften, die notwendig sind, um den dafür notwendigen Ressourcenstack zu erstellen.

Amazon VPC kann bereits seit mehreren Jahren genutzt werden und erlaubt dem Nutzer den Aufbau eines für sich isolierten Bereichs auf der Amazon Cloud. Hier können Ressourcen in einem virtuellen Netzwerk ausgeführt werden und darauf mittels öffentlichen und privaten Subnetzen sowie VPNs zugegriffen werden.

Mit dem Einsatz von AWS CloudFormation müssen Anwender nicht die Reihenfolge der Provisionierung der jeweiligen AWS Services sowie deren Abhängigkeiten berücksichtigen. CloudFormation nutzt dazu Templates, die als in JSON (JavaScript Object Notation) formatierte Textdateien geschrieben werden. JSON basiert auf einer Teilmenge der Programmiersprache JavaScript und ist sowohl für Menschen als auch Maschinen lesbar.

Um Entwicklern und Systemadministratoren ein wenig unter die Arme zugreifen, hat Amazon zwei Beispiel Templates erstellt, um zu zeigen wie diese aufgebaut sind. Das erste Template erstellt eine Amazon VPC mit einer EC2 Instanz. Das zweite Template baut eine VPC inkl. einem Public und Private Subnetz sowie einem Elastic Load Balancer und einer EC2 Instanz auf.

Beide Templates können in Jeff Barrs Blogpost nachvollzogen werden.


Bildquelle: http://www.allmystery.de



Pinterest macht die Amazon Cloud für den eigenen Erfolg verantwortlich

Pinterest ist seit dem Start zu einem der Lieblinge im Internet geworden und hat ein beachtliches Wachstum zu verzeichnen. Ryan Park, Operations Engineer bei Pinterest, führt diesen Erfolg auf die Skalierbarkeit des Cloud Computing, genauer den Amazon Web Services zurück. Ohne Cloud Computing wäre der Erfolg von Pinterest nicht möglich gewesen, so Park kürzlich auf dem Amazon Web Services Summit in New York.

Pinterest ist eine Online Pinnwand. Es handelt sich dabei um einen Service der es erlaubt, Dinge zu sammeln und zu organisieren, die für jemanden von besonderem Interesse sind. Zudem können diese Dinge von anderen Nutzern auf der Pinnwand angeschaut werden.

Pinterest macht die Amazon Cloud für den eigenen Erfolg verantwortlich

Die Cloud hat es Pinterest ermöglicht, effizient zu arbeiten und kostengünstig zu experimentieren. Zudem konnte die Webseite sehr schnell wachsen, während sich nur ein sehr kleines Team um die Wartung kümmern musste. Im Dezember beschäftigte Pinterest insgesamt nur 12 Mitarbeiter. Laut der Rating Agentur ComScore konnte Pinterest im Monat März fast 18 Millionen Besucher gewinnen, eine 50-prozentige Steigerung gegenüber dem Vormonat. Die Webseite gehört demnach zu einer der am schnellsten wachsenden Webseiten in der Geschichte des Webs.

Pinterest setzt bei seinem Service auf Amazon S3 und Amazon EC2. Dabei ist die Nutzung von S3 seit dem letzten August um den Faktor 10 gestiegen. EC2 im selben Zeitraum um den Faktor 3. In Zahlen bedeutet das in etwa 80 Millionen Objekte die in Amazon S3 gespeichert sind, was ca. 410 Terabyte an Nutzerdaten entspricht.

Nach Park, wäre dies mit einem eigenen Rechenzentrum niemals möglich gewesen. Zunächst hätte das einen riesen Aufwand in Bezug auf die Kapazitätsplanungen bedeutet und die Hardware hätte noch bestellt und selbst installiert werden müssen. Zudem wäre Pinterest nicht in der Lage gewesen so schnell zu skalieren.

Aktuell nutzt Pinterest ca. 150 EC2 Instanzen, um damit die Kern Services bereitzustellen. Diese sind in Python geschrieben. Zudem setzt Pinterest auf das Django Framework. Der Traffic wird über die Instanzen mit Hilfe von Amazon ELB (Elastic Load Balancer) verteilt. Weitere 90 EC2 Instanten werden für das Caching eingesetzt und noch einmal 35 Instanzen für interne Zwecke.

Im Hintergrund der Anwendungen laufen etwa 70 Master-Datenbanken auf EC2 sowie eine Reihe von Backup-Datenbanken, die sich in verschiedenen Regionen auf der ganzen Welt befinden, um für die Redundanz zu sorgen.

Um seinen Nutzern Daten in Echtzeit zu liefern, sind die Datenbank-Tabellen über mehrere Server hinweg verteilt. Wenn ein Datenbankserver mehr als 50 Prozent Last fährt, wird die Hälfte des Inhalts auf einen anderen Server verschoben. Dieser Prozess wird auch als Sharding bezeichnet. Im vergangenen November nutzte Pinterest acht Master-Slave-Datenbank-Paare. Heute sind es schon 64 Paare.

Ein weiterer Vorteil, der Pinterest entgegenkommt, ist das pay-as-you-go Modell. Da Pinterest bei AWS nur für die Ressourcen bezahlt die sie benötigen, konnte Kapital gespart werden. Der meiste Datenverkehr entsteht in den USA während den Nachmittags-und Abendstunden. Mit Amazon Autoscaling fügt Pinterest in diesen Zeiträumen entsprechend mehr Instanzen hinzu, um die Anfragen zu bewältigen. In der Nacht werden die Instanzen dann wieder entfernt.

Mit diesem Ansatz ist Pinterest in der Lage, die Anzahl der Server die sie in der Nacht verwenden, um rund 40 Prozent zu reduzieren. Da Amazon pro Stunde abrechnet, führt diese Reduktion zu Kosteneinsparungen. Während der Lastspitzen, zahlt Pinterest etwa 52 US-Dollar pro Stunde für Amazon EC2. In den frühen Morgenstunden liegen die Kosten dann bei 15 US-Dollar pro Stunde.

Das pay-as-you-go Modell lässt Pinterest ebenfalls neue Services testen, ohne dafür langfristig in eigene Serverhardware- oder software zu investieren. Ein gelungenes Experiment war, laut Park, die Nutzung von Amazon Elastic Map Reduce, Amazons Hadoop-basierten Service für die Datenanalyse.

Fazit

Pinterest ist nur ein gutes Beispiel dafür, wie Cloud Computing dabei unterstützt neue Geschäftsmodelle mit einem minimalen Ressourcen- und Kapitalaufwand zu realisieren und im Erfolgsfall für die entsprechende Flexibilität und Skalierbarkeit zu sorgen.



Amazon Web Services: König der Cloud?

Liegen die restlichen Cloud Anbieter den Amazon Web Services zu Füßen? Es scheint fast so. Zumindest setzt Amazon unbeeindruckt von den Grabenkämpfen zwischen den Open Source Clouds OpenStack und CloudStack seine Entwicklung fort und veröffentlicht fleißig immer weiter neue Cloud Services.

OpenStack vs. CloudStack - Amazon der lachende Dritte

Die Kuriosität der Auseinandersetzung zwischen OpenStack und CloudStack besteht insbesondere darin, dass ca. 95% aller IaaS Anbieter von dem Kampf um die Herrschaft um die Open Source Cloud direkt oder indirekt betroffen sind. Nur die Amazon Web Services nicht. Im Gegenteil, das Unternehmen aus Seattle profitiert sogar noch davon, indem es auf Grund seiner APIs EC2 und S3 immer wieder im Gespräch ist.

Und genau um diese APIs geht es im Kern. So gut wie jeder IaaS Anbieter wirbt mit der Kompatibilität zur Amazon Elastic Compute Cloud (Amazon EC2) und Amazon Simple Storage Service (Amazon S3). EC2 erlaubt das Starten und Verwalten von virtuellen Maschinen in der Amazon Cloud. S3 ist für das Speichern und Verwalten von Daten ebenfalls in der Amazon Cloud zuständig.

So ermöglicht es bspw. Terremark seinen Kunden die Daten aus der Private Cloud ggf. per Cloud Bursting in die Amazon Cloud auszulagern. Ein Blick auf mobile Apps für Android oder iOS zeigt eine Vielzahl von Anwendungen, mit denen die Amazon Cloud gesteuert werden kann oder die mit der Unterstützung der AWS APIs werben. Ubuntu springt ebenfalls auf den Zug auf und wird ab der Version 12.04 Funktionen bieten, um OpenStack Installationen mit den Amazon Web Services zu verbinden.

Ein Grund von Citrix, sich aus dem OpenStack Projekt zurückzuziehen, war die angeblich schlechte Unterstützung der Amazon APIs. Was unverständlich ist, da OpenStack von Beginn mit der Kompatibilität von EC2 und S3 wirbt.

Als ein weiterer Gewinner, im Schatten der Schlacht zwischen OpenStack und CloudStack, wird sich Eucalyptus herauskristallisieren. Die Kooperation der Open Source IaaS Software mit Amazon hat sowohl für Eucalyptus als auch Amazon nur Vorteile. Eucalyptus erhält Unterstützung direkt von der Quelle und kann besser als die anderen Open Source Clouds eine perfekte Integration zur Amazon Cloud bieten. Amazon hingegen kann das Hybrid Cloud Geschäft weiter ausbauen und ist somit bereits mit einem Bein in dem hart umkämpften Unternehmensmarkt. Zudem wird durch diese Kooperation eine erste Brücke zwischen den Private Cloud Installation auf Basis von Eucalyptus und der Public Cloud von Amazon geschaffen, um damit insbesondere das Big Data Geschäft auszubauen.

Ich möchte Amazon hiermit keinen Freifahrtsschein für den Thron in der Cloud ausstellen. Dennoch können einzig die wirklich Großen der Branche wie HP, IBM, T-Systems und Microsoft es sich erlauben nicht auf den Zug aufzuspringen und Kompatibilität zu den Amazon APIs bieten. Wobei auch HP bereits OpenStack für sich entdeckt hat.


Bildquelle: http://gigaom2.wordpress.com



Amazon erweitert CloudFront mit Live-Streaming Funktion für iOS und Silverlight

Amazon hat seinen Content Delivery Network (CDN) Services um Live-Streaming Funktionen für Apples iOS und Microsofts Silverlight erweitert. Das wurde gestern im offiziellen Unternehmensblog angekündigt.

Mit Amazon CloudFront können Inhalte wie Bilder, Videos andere Mediadaten und Software so verteilt werden, dass auf sie schnell und performant zugegriffen werden kann. Dazu nutzt CloudFront, typisch für ein CDN, unterschiedliche Edge Locations in Asien, Europa, Südamerika und den USA, um die Inhalte möglichst nah an den Nutzer auszuliefern und damit die Zugriffszeit zu verkürzen.

Mit der neuen Funktion "Live Smooth Streaming for Amazon CloudFront" können Inhalte nun zusätzlich live auf Microsoft Silverlight Clients und Apple iOS Endgeräte wie iPhone, iPod Touch oder iPad streamen. Dazu werden Microsofts Live Smooth Streaming und Apples HTTP Live Streaming (HLS) Formate genutzt.

Amazon erweitert CloudFront mit Live-Streaming Funktion für iOS und Silverlight

Live Smooth Streaming Inhalte werden fragmentiert an die Clients übertragen, so dass die CloudFront Edge Server die Daten zwischenspeichern (cachen) können.

Die Clients selbst haben die Möglichkeit den aktuellen Netzwerk- und lokalen Systems-Status dynamisch zu überwachen. Sollte sich z.B. die Netzwerkleistung verschlechtern, kann der Client umgehend kommunizieren, dass das nächste Fragment mit einer niedrigeren Bitrate gesendet werden soll, um sich damit an die ändernden Bedingungen anzupassen. Laut Amazon sollen damit das Stottern, Puffern und Einfrieren des Streamings verhindert werden.

Der Stream kann über eine Amazon EC2 Instanz mit Windows IIS Media Services bereitgestellt werden. Wird der Live Stream von einem Client angefragt, lädt CloudFront den Inhalt automatisch von der EC2 Instanz, cached ihn in der Edge Location zwischen und liefert ihn an den Client aus. Um Inhalte mit Apples HLS Format zu streamen, wird auf der Amazon EC2 Instanz ein Adobe Flash Media Server 4.5 benötigt. Laut Amazon handelt es sich bei beiden Formaten aber um dieselbe Grundkonfiguration. Um die Nutzung von "Live Smooth Streaming for Amazon CloudFront" zu vereinfachen, hat Amazon ein CloudFormation Template erstellt, dass die notwendigen Ressourcen für ein Live Event bereitstellt.

Die CloudFront Preise orientieren sich an den regionalen Datentransferkosten für die jeweiligen Amazon Edge Locations, die Anzahl an HTTP-Anfragen und die Anzahl an ungültigen Anfragen. Letzteres wird verwendet, um ein Objekt aus der CloudFront Edge Location vor dem angegebenen Ablaufdatum zu entfernen.

Bspw. kosten in Europa und in den USA die ersten 10TB 0,12 US-Dollar pro Gigabyte und die weiteren 40TB 0,08 US-Dollar pro Gigabyte. Die Menge an verbrauchten Traffic wird dabei monatlich zurückgesetzt.


Bildquelle: http://www.ewdisonthen.com



How-To: Amazon EC2 Linux Micro Instanz um eine Swap Partition erweitern um deren Leistung zu erhöhen

Amazon EC2 Micro Instanzen stehen nur 613 MB Arbeitsspeicher zur Verfügung. Das reicht in den meisten Fällen nicht, um große Datenmengen performant zu verarbeiten. Hinzu kommt, dass die Linux Micro Instanzen standardmäßig keine Swap Partition haben.

Mit den folgenden Schritten wird einer Linux basierten Amazon EC2 Micro Instanz eine Swap Partition hinzugefügt, wodurch deren Leistung erhöht werden kann.

Zunächst melden wir uns als Root an und geben folgenden Befehl ein, um die Werte für die gewünschte Blockgröße anzugeben.

dd if=/dev/zero of=/swapfile bs=1M count=1024

Anschließend richten wir das Swapfile ein.

mkswap /swapfile

Nun aktivieren das Swapfile.

swapon /swapfile

Um das Swapfile während des Bootvorgangs zu aktivieren, tragen wir folgendes in die /etc/fstab ein.

/swapfile swap swap defaults 0 0

Bildquelle: http://tux.crystalxp.net



Zynga verlässt die Amazon Web Services und geht zurück in die Private Cloud

Mit Spielen wie CastleVille, Mafia Wars und Farmville wurde Zynga bekannt und hat einen wesentlichen Beitrag für die Online-Games Branche geleistet. Die Spiele wurden zunächst auf den Servern der Amazon Web Services (Amazon EC2) betrieben, da im Jahr 2009 die Zugriffe stiegen und mehr Speicher und Geschwindigkeit benötigt wurden. Die jüngsten Entwicklungen haben jedoch gezeigt, dass Zynga auch eine Private Cloud nutzen kann.

Die Statistiken zeigten, dass Zynga maximal ein Drittel der EC2 Server benötigt, die sie aktuell nutzen. Das mag im ersten Moment überraschend klingen. Aber während der diverser Tests stellte sich heraus, dass Zynga maximal eine virtuelle Maschine (VM) pro Server, wie es auf EC2 der Fall ist, benötigt. Der Vorteil der Private Cloud besteht darin, dass Zynga ihre zCloud Server auf die eigenen Bedürfnisse modifizieren und so für den Einsatz optimieren kann.

Dazu gehören die Optimierung der "Gaming Roles" und deren Zugriff auf die Datenbank und die Software-Infrastruktur sowie die Maximierung der Webserver und der verbesserten Ausführung der Spiellogik im Cloud-Framework. Diese neuen Entwicklungen und Veränderungen wurden während der letzten CloudConnect in Santa Clara, Kalifornien vorgestellt.

Das zCloud Konzept war das Ergebnis von mehr als sechs Monaten Software Design und Entwicklung von Zyngas Ingenieuren. Für Zynga war es ein logischer Schritt auf eine eigene Cloud-Infrastruktur zu setzen. Der Anfang auf der Amazon Cloud gab ihnen zunächst die Möglichkeit die rasant wachsende Nachfrage schnell zu befriedigen. Nach dem Start von Farmville wurden innerhalb von 5 Monaten 25 Millionen Spieler erreicht. Das wäre am Anfang mit einer eigenen Infrastruktur nicht zu schaffen gewesen.

Castle Ville war das erste Spiel das alleine auf der zCloud ausgerollt wurde. Mit dem Start wurden innerhalb von sechs Tagen ca. 5 Millionen Nutzer erreicht. Die zCloud arbeitet mit energieeffizienten Servern, die ähnlich dem Open Compute Project von Facebook sind. Die zCloud wurde entwickelt, um die Anforderungen auf das Cloud-Gaming-fokussierter Anwendungen zu erfüllen, wie bspw. der Bedarf an Speicher, CPU, I / O sowie weiterer Spielelemente und Anwendungen.

Zynga hat sich darüber hinaus auf die Entwicklung performanter Speichersysteme konzentriert, damit die Webserver auch starken Internetverkehr durch die Firewalls und Loadbalancer effizient transportieren können. Zudem wurden strategische Standorte in der Nähe von Facebook Rechenzentren gewählt.

Zynga sieht sich im Vergleich zu Amazon nun als ein hochpreisiger Sportwagen, wohingegen Amazon sich in der Klasse der viertürigen Limousinen befindet.

Der Weg von Zynga könnte zu einem Vorbild für andere Unternehmen werden, die mehr Kontrolle über ihre Cloud-Plattform gewinnen wollen.



Die Software AG geht in die Cloud

Die Software AG hat ihre Anwendungen WebMethods und Aris auf Amazon EC2 portiert und plant zudem einen eigenen PaaS Dienst.

Neben der Middleware WebMethods hat die Software AG ebenfalls sein Tool für die Prozessmodellierung Aris zertifizieren lassen, so dass beide Anwendungen nun auf Amazon EC2 sowie VMware betrieben werden können. Durch die Portierung auf EC2 sollen bestehende Kunde die Utility-Services Möglichkeiten der Cloud nutzen können. Nach Aussage der Software AG nutzen einige Kunden sogar bereits Lösungen auf VMware Basis, wodurch die jetzige Zertifizierung ihnen nur ein weiteres Maß an Sicherheit gewährleisten soll.

Um WebMethods bzw. Aris auf Amazon EC2 zu nutzen, müssen die Kunden einen separaten Vertrag mit Amazon eingehen. Die Lizenzen würden hingegen von Seiten der Software AG geliefert. Dazu sind die CPU-Lizenzen der Software AG kompatible mit den Virtual Core Lizenzen von Amazon. Was bedeutet, dass ein Kunde seine bestehenden Lizenzen zu Amazon umziehen kann.

Unternehmen können die Amazon Cloud somit für die Entwicklung, Test und Produktion nutzen. Die Software AG erwartet hingegen die meiste Nutzung in den beiden erstgenannten Bereichen.

Development-as-a-Service

Das Hauptziel der Software AG besteht jedoch im Aufbau eines umfangreichen Platform-as-a-Service Angebots. Die PaaS Umgebung wird dazu neben einem Java Application Server (WebMethods) ebenfalls einen In-Memory Cache (Terracotta) beinhalten. Darüber hinaus soll dem PaaS eine IDE (Integrated Development Environment) einverleibt werden, was aus dem Platform-as-a-Service im Grunde genommen ein Development-as-a-Service macht.

Hinzu kommt eine Kollaborationsschicht, die es virtuellen Teams ermöglichen soll gemeinsam, in Echtzeit und ortsunabhängig miteinander zu arbeiten.

Wann der PaaS erscheint steht derzeit noch nicht fest, jedoch befindet sich das nächste Major Release für WebMethods in den Startlöchern.



Was bei der Nutzung von EC2 Instanzen zu beachten ist

Nachdem eine AMI gestartet wurde steht eine sogenannte Instanz bereit, die sich im Status "running" befindet. Eine Instanz die zentrale Komponente, wenn es darum geht, in der Amazon Cloud Daten zu verarbeiten. Dazu stellt Amazon mehrere unterschiedliche Instanz Typen für unterschiedliche Einsatzszenarien zur Verfügung.

Für die bestmögliche Nutzung von Amazon EC2 Instanzen sollten folgende Hinweise beachtet werden:

  • Wichtige und langfristig benötigte Daten sollten nicht auf dem lokalen Instanzspeicher abgelegt werden.
    Wenn eine Instanz ausfallen sollte, sind die Daten auf dem lokalen Speicher nicht mehr vorhanden. Das kann umgangen werden, indem eine Replikationsstrategie angewendet wird, bei der die Daten über mehrere Instanzen repliziert werden. Weiterhin kann Amazon S3 oder Amazon EBS für das dauerhafte Speichern von Daten verwendet werden.
  • Erstellen von Images die regelmäßig für eine bestimmte Aufgabe benötigt werden.
    Für den Einsatz von Web Anwendungen wird z.B. ein Image für Datenbank Instanzen und ein weiteres für Web Server Instanzen erstellt.
  • Überwachen des Zustands der Instanzen
    Das kann z.B. mit Amazon CloudWatch vorgenommen werden.
  • Die Firewall Regeln von Amazon EC2 sollten so restriktiv wie möglich sein.
    Es sollten zunächst nur die Berechtigungen vergeben werden, die auch tatsächlich benötigt werden. Weiterhin sollten für alle Instanzen mit unterschiedlichen Sicherheitsanforderungen separate Security Groups erstellt werden. Es sollten ggf. zusätzliche Sicherheitsmaßnahmen innerhalb einer Instanz getroffen werden, z.B. der Einsatz der eigenen Firewall. Für den SSH Zugriff auf eine bestimmte Instanz sollte eine Bastion Group erstellt werden, die ausschließlich einen externen Login erlaubt. Alle weiteren Instanzen sollten einer Security Group zugewiesen werden die einen externen Login verbietet.

Quelle




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



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

Continue reading “Amazon EC2 mit Ubuntu Images (erste Schritte)” »



Ubuntu Enterprise Cloud Terminologie

Bei dem Einsatz der Ubuntu Enterprise Cloud (UEC) wird eine eigene Terminologie verwendet, die für das Verständnis und dem Umgang doch wichtig ist. Dieses Glossar fasst alle notwendigen Begriffe und ihre Bedeutung zusammen.

Cloud
Ein Verbund von physikalischen Maschinen, die mit Hilfe von virtuellen Maschinen Rechnerressourcen dynamisch bereitstellen und "wieder einsammeln".

Cloud Controller (CLC)
Komponente von Eucalyptus die eine Weboberfläche (HTTPS Server auf Port 8443) bereitstellt und die Amazon EC2 API implementiert. Es sollte maximal einen Cloud Controller für eine UEC Installation geben. Der CLC wird durch das Ubuntu Package eucalyptus-cloud zur Verfügung gestellt.

Cluster
Ein Verbund von Nodes, die einem Cluster Controller zugeordnet sind. Dabei kann es mehr als einen Cluster in einer UEC Installation geben. Cluster bestehen in einigen Fällen aus physikalisch räumlich voneinander getrennten Nodes.

Cluster Controller (CC)
Eine Eucalyptus Komponente die für die Verwaltung der Node Ressourcen zuständig ist. Der CC wird durch das Ubuntu Package eucalyptus-cc zur Verfügung gestellt.

EBS
Elastic Block Storage

EC2 - Elastic Compute Cloud
Amazons Public Cloud Computing Angebot auf Basis von virtuellen Servern, bei dem die Abrechnung pro Stunde bzw. pro Gigabyte erfolgt.

EKI
Eucalyptus Kernel Image

EMI
Eucalyptus Machine Image

ERI
Eucalyptus Ramdisk Image

Eucalyptus
Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems.
Bei Eucalyptus handelt es sich um ein Open Source Projekt, welches ursprüglich an der University of California in Santa Barbara entwickelt wurde und mittlerweile durch Eucalyptus Systems unterstützt wird.

Front-end
Ein oder mehrere physikalische Server, auf denen die Eucalytpus Komponenten (cloud, walrus, storage controller, cluster controller) ausgeführt werden.

Node
Bei einem Node handelt es sich um eine phyiskalische Maschine, die in der Lage ist virtuelle Maschinen und einen Node Controller auszuführen. Innerhalb von Ubuntu bedeutet dies, dass eine CPU die VT Erweiterung unterstützt und den KVM Hypervisor ausführen kann.

Node Controller (NC)
Eine Eucalyptus Komponente die auf den Nodes ausgeführt wird, welche die virtuellen Maschinen beherbergen die wiederum der Cloud zugeordnet sind. Der NC wird durch das Ubuntu Package eucalyptus-nc zur Verfügung gestellt.

S3 - Simple Storage Service
Amazons Public Cloud Computing Angebot für das Speichern der EC2- und anderer Daten, bei dem die Abrechnung pro Gigabyte erfolgt.

Storage Controller (SC)
Eine Eucalyptus Komponente die zur Verwaltung des dynamic block storage services (EBS) dient. Jeder Cluster innerhalb einer Eucalyptus Installation kann seinen eigenen Storage Controller besitzen. Der SC wird durch das Ubuntu Package eucalyptus-sc zur Verfügung gestellt.

UEC
Ubuntu Enterprise Cloud
Ubuntu's Cloud Computing Lösung auf der Basis von Eucalyptus.

VM
Virtual Machine

VT
Virtualization Technology
Moderne CPUs unterstützen diese Funktion, um die Arbeit (das Hosting) mit den virtuellen Maschinen zu beschleunigen.

Walrus
Eine Eucalyptus Komponente welche die Amazon S3 API implementiert und dafür benötigt wird, die Images der virtuellen Maschinen, sowie die Daten der Benutzer in S3 Buckets mittels put/get zu speichern.



Scalarium

Scalarium, das Cloud Computing Produkt der Peritor GmbH dient zur Automatisierung der Kommunikation und Konfiguration von Amazon EC2 Cluster.

Eine Beispielkonfiguration für einen Cluster würde z.B. aus einem Load Balancer, drei Rails Applikations-Servern und einem Datenbankserver bestehen. Für den Start dieses Clusters ist anschließend Scalarium verantwortlich, indem es eine Verbindung zur Amazon Compute Cloud (EC2) herstellt und die entsprechenden Instanzen startet. Die Images werden geladen und der Scalarium Agent installiert.

Der Scalarium Agent wird auf jedem Server ausgeführt und ist über eine verschlüsselte Verbindung ständig mit Scalarium in kontakt. Webserver werden dabei automatisch mit Nginx konfiguriert, während Datenbankserver eine MySQL Installation erhalten. Nachdem der Scalarium Agent auf einer Instanz installiert wurde und das System konfiguriert hat, wird die Instanz als online markiert und kann durch den Cluster verwendet werden.

Scalarium bietet die folgenden vier Funktionen, die im Anschluß jeweils kurz vorgestellt werden.

  • Auto Config
  • Auto Healing
  • Auto Scaling
  • One Click Deploy

Auto Config

Mittels der Auto Configuration werden die Server automatisiert konfiguriert, indem die benötigte Software installiert und eingerichtet wird. Werden weitere Instanzen hinzugefügt, konfiguriert Scalarium automatisch die Anwendungen und den gesamten Cluster. Die einzigen Informationen die von Scalarium dazu benötigt werden sind die gewünschten Ubuntu Packages und Rubygems. Anschließend werden alle Pakete und Libraries auf jedem Server installiert und das zu jederzeit.

Weitere Informationen zu Auto Config sind HIER zu finden.

Auto Healing

Mit Auto Healing sorgt Scalarium dafür, dass die vorher festgelegten Services und Hosts des Cluster im Fehlerfall automatisch wiederhergestellt werden. Fällt z.B. ein Server aus, wird dieser durch Scalarium entfernt und in kurzer Zeit durch eine neue Instanz ersetzt, wodurch der gesamte Cluster automatisch neu konfiguriert wird.

Weitere Informationen zu Auto Healing sind HIER zu finden.

Auto-Scaling

Durch das Auto-Scaling können Schwellwerte festgelegt werden die dafür sorgen, dass entweder weitere Instanzen gestartet oder nicht mehr benötigte Instanzen beendet werden. Dazu überwacht Scalarium die CPU- und Arbeitspeicher-Auslastung, sowie die durchschnittliche Belastung jeder Instanz.

Weitere Informationen zu Auto Scaling sind HIER zu finden.

One Click Deploy

Mittels One Click Deploy können Anwendungen über den gesamten Cluster hinweg zu einem Zeitpunkt vollständig automatisiert verteilt, installiert und konfiguriert werden.

Weitere Informationen zu One Click Deploy sind HIER zu finden.

Demo Video

http://www.youtube.com/watch?v=F2UzrYOZNM4

Preise

Quelle



Peecho's Printcloud – Printing as a Service

Mit der Printcloud bietet das Unternehmen Peecho aus den Niederlanden einen Cloud Service, mit der ein einheitlicher Zugang zu allen Druckumgebungen auf der ganzen Welt ermöglicht wird. Es reicht dafür aus, lediglich eine eigene Benutzerschnittstelle zu erstellen. Der Rest wird von der Printcloud auf Basis von pay-per-use und ohne eine erforderliche Menge abgewickelt. Der gesamte Prozess vom Auftragseingang über die Verarbeitung bis hin zur Produktion und dem Versand von personalisierten Produkten wird von der Printcloud übernommen.

Was bietet die Printcloud?

  • Grafik-Design
    Vollständige Unterstützung von Adobe Indesign IDML. Weltweit kann jeder Graphikdesigner für ein Unternehmen, dass die Printcloud nutzt, Produkte entwerfen.
  • Einfache Konnektivität
    Mit Hilfe der REST API kann sich jede Anwendung (z.B. eine Webseite, eine mobile Anwendung, eine Desktop Anwendung oder ein Gadget eines Sozialen Netzwerks) mit der Printcloud verbinden.
  • Software
    Programme stehen für das iPhone und Adobe Flex zur Verfügung.
  • Skalierbarkeit
    Auf Grund von Cloud Computing Technologien können die Kapazitäten in wenigen Minuten erhöht werden, wodurch kein Engpass entsteht.
  • Weltweite Produktion
    Auf Basis von Druckstandards wie JDF und JMT kommuniziert die Printcloud mit einem weltweiten Netzwerk von Druckumgebungen, um das endgültig gedruckte Produkt so nah wie möglich am Ziel der Auslieferung zu produzieren und dadurch die Versandkosten zu minimieren.
  • Faire Abbrechung
    Es müssen keine langfristigen Verträge eingegangen werden was ebenfalls bedeutet, dass Terminierungsentgelte, Vorab-Investitionen oder Einrichtungskosten entstehen. Die Abbrechnung erfolgt vollständig auf einer pay per use Basis. Es wird also tatsächlich nur das bezahlt, was genutzt wird.

Funktionen

  • Produktkatalog
    Es steht ein Produktkatalog für Anwendungen/ Produkte von Kunden bereit, die schnell erstellt werden können.
  • Produktvorlagen
    Schnelle Erstellung von Produktvorlagen durch die Nutzung von Adobe InDesign IDML.
  • Einkaufswagen
    Es können mehrere Produkte in einer Bestellung zusammengefasst werden.
  • Abbrechnung
    Die Rechnungsstellung an die Endkunden kann von der Printcloud ebenfalls übernommen werden.
  • Gutschein-Codes
    Für werden mobile Zahlungen oder Marketing-Kampagnen können Gutschein-Codes erstellt werden.
  • Status-Updates
    Der Status des gesamten Prozessverlaufs kann zu jederzeit mittels einer eigens entwickelten Anwendung oder via der Webseite der Printcloud dem Endkunden angezeigt werden.

  • REST API
    Zur Kommunikation steht eine REST API zur Verfügung.
  • iPhone
    Hilfe bei der Entwicklung einer iPhone Anwendung für eigene Produkte mittels der Printcloud Open Source iPhone Anwendung.
  • Adobe Flex
    Vollständige Unterstützung von Adobe Flex.
  • Skalierbarkeit
    Hohe Skalierbarkeit und Verfügbarkeit durch Cloud Computing Technologien.
  • Weltweite Produktion
    Mit der Printcloud kann jede Druckumgebung auf der ganzen Welt angesprochen werden.

Technik

Die Printcloud Plattform basiert vollständig auf der Architektur der Amazon Web Service.

  • Simple Storage Service
    Alle Daten werden in Amazons Cloudspeicher Simple Storage Service (S3), wodurch eine unbegrenzte Menge an Daten verwaltet und gespeichert werden kann und von überall aus verfügbar ist.
  • Elastic Compute Cloud
    Das Versprechen der Skalierbarkeit realisiert die Printcloud durch den Einsatz von Amazons Elastic Compute Cloud (EC2), mit der je nach Bedarf die Systeme erweitert oder verkleinert werden können und damit saisonale Lastspitzen abgefangen werden können.
  • Simple Queue Service
    Mit dem Amazon Simple Queue Service (SQS) werden die einzelnen Prozesse der Printcloud separiert, wodurch kein neuer Auftrag den gesamten Prozess stören kann.
  • Relational Database Service
    Mit dem Relational Database Service (RDS) steht der Printcloud eine skalierbare Datenbank in der Cloud zur Verfügung.
  • Cloudfront
    Mit Amazon CloudFront werden die benötigten Daten eines Druckauftrags der am nächsten gelegenen Druckumgebung des Auslieferungsorts bereitgestellt.

Für Druckereien

Die Printcloud stellt Anwendungen von Drittanbietern (Händlern) eine REST API für die Kommunikation bereit. Der gesamte Prozess vom Auftragseingang über die Verarbeitung bis hin zur Produktion und dem Versand von personalisierten Produkten wird von der Printcloud für den Händler übernommen.

Aus der Sicht einer Druckerei arbeitet Peecho als eine Art Broker für die eigenen Produkte. Dazu steht ein einziger Einstiegspunkt zur Verfügung, wodurch Peecho's Partner ihren Kunden jegliche Art von Produkt anbieten können. Diese Produkte können in verschiedenen Produktionsstätten auf der ganzen Welt hergestellt werden.

Die Infrastruktur basiert vollständig auf den Amazon Web Services, wobei Technologien wie Elastic Load Balancing und Auto-Scaling genutzt werden, um innerhalb von wenigen Minuten die Skalierung der Systeme vorzunehmen.

Der (Kommunikations)-Prozess zwischen einem Partner und der Printcloud funktioniert wie folgt:

Die Ausgabe der Printcloud für 2D Drucker basiert auf den folgenden Elementen:

  • Job Ticket in JMF (Job Messaging Format) und JDF (Job Definition Format).
  • Produktbeschreibung als Adobe Indesign IDML (InDesign Markup Language).

Die Bestellungen werden dabei nicht direkt zu den Druckereien geschickt, um diese nicht zu überlasten. Vielmehr basiert der gesamte Vorgang auf dem Pull Mechanismus, wodurch die Druckereien die Möglichkeiten haben, die Arbeitslast selber zu bestimmen und können die Aufträge in ihren Produktionsfluss integrieren.

  • Erster Schritt: Ein Jobticket beziehen
    Jeder Job wird einer Druckerei in einer eigenen Amazon SQS Job Ticket Queue abgelegt. Diese können z.B. mittels SOAP abgefragt werden. Das Job Ticket basiert auf einer kleinen XML Datei, in der ein Zeiger auf die Produktionsdatei und die Produkbeschreibung zeigt. Mit der JDF Datei kann die Druckerei entscheiden, wann und wie das Produkt gedruckt werden soll.

    Ist das Ticket von der Druckerei heruntergeladen worden, wird der Status des Tickets auf "Queue" gesetzt, was gleichermaßen bedeutet, dass der Auftrag in Produktion ist.

  • Zweiter Schritt: Das Produkt erhalten
    Jedes Job Ticket zeigt zusätzlich auf einer Produktdatei, die in Amazon S3 gespeichert ist. Auf diesen Service kann mit SOAP oder REST mittels eines Schlüssels oder direkt mit einer URL zugegriffen werden. Abhängig von der Job Beschreibung kann die Druckerei die Produktdatei herunterladen, wenn sie bereit sind zu produzieren.
  • Dritter Schritt: Produzieren, Versenden und auf "versendet" setzen
    Jetzt kann die Druckerei die IDML Datei in ein für sie passendes Format übersetzen, wie z.B. PDF oder PPML. Die Druckerei produziert das Produkt und versendet es an die Empfänger. Anschließend wird der Status des Job Tickets auf "versendet" gesetzt.

    Für die ersten Schritte wird eine Open Source Beispielanwendung bereitgestellt, die Job Tickets und Produkt Dateien aus der Printcloud in einen bestimmten Ordner herunterlädt.

Quelle

  • PRINTCLOUD by Peecho



Erste Schritte mit Amazon EC2 – Windows

Dieses Tutorial beschreibt das Einrichten einer virtuellen Instanz mit einem Windows Server 2008 AMI (Amazon Machine Image) auf Basis der Amazon Elastic Compute Cloud (Amazon EC2). Dazu gehören die vollständige Einrichtung der Instanz und der anschließende Zugriff per Remote Desktop Verbindung von einem Windows 7 Computer.

Voraussetzungen

  • Amazon Web Service Account
  • Amazon EC2 ist für den Account bereits aktiviert
  • RDP Client

Auswahl, Einrichten und Starten der Instanz

Zuerst öffnen wir die Webseite der Amazon Web Services und melden uns dort an.

Anschließend starten wir die AWS Management Console für EC2.

Hier klicken wir auf Launch Instance.

Ein weiteres Fenster öffnet sich, in dem bereits fertig vor-konfigurierte Amazon Machine Images (AMIs) von Amazon angezeigt werden. Hier wählen wir das erste AMI - Getting Started on Microsoft Windows Server 2008 (AMI Id: ami-a4698bcd)

Nun wählen wir folgende Konfiguration:

  • Number of Instances: 1
  • Availability Zone: No Preference
  • Instance Type: Small (m1.small 1.7 GB)

Als erweiterte Konfiguration wählen wir:

  • Kernel ID: Use Default
  • RAM Disk ID: Use Default
  • Monitoring: Nein

Anschließend erstellen wir ein Schlüsselpaar, hier mit dem Namen clouduser_key und speichern es auf unserem Rechner.

Im nächsten Schritt konfigurieren wir die Firewall, indem wir für unsere AMI eine Security Group erstellen. Die Standardvorgabe ist der externe Zugriff auf die Ports 3389 (RDP), MS SQL Server (1433) und 80 (HTTP). Die Freigaben für den Port 80 und 1433 habe ich entfernt, da wir sie in diesem Fall nicht benötigen. Wir geben der Security Group einen Namen, hier Security_Group_2 und eine Beschreibung, hier RDP_Only und wählen continue.

Danach erhalten wir eine Zusammenfassung unserer Konfiguration, wo wir mittels Launch unsere Instanz starten.

Über Your instances are now launching kommen wir zur Console zurück.

Dort sehen wir, dass unsere soeben erstellte Instanz aktiv ist und wir uns nun mit ihr verbinden können. Dazu notieren wir uns zunächst den Namen in der Spalte Public DNS.

Verbinden mit der Instanz

Um uns mit der Instanz zu verbinden öffnen wir zunächst die Datei mit unserem erstellten Private Key und kopieren den gesamten Inhalt inkl. der Kommentare -----BEGIN RSA PRIVATE KEY----- und -----END RSA PRIVATE KEY-----.

Nun gehen wir zurück zur AWS Management Console, klicken mit der rechten Maustaste auf die Instanz und wählen Get Windows Password

In das Feld Private Key* fügen wir den privaten Schlüssel inkl. der Kommentare -----BEGIN RSA PRIVATE KEY----- und -----END RSA PRIVATE KEY----- ein.

Nach dem Klick auf Decrypt Password wird uns der Benutzername und das Passwort für die Anmeldung an unserer Instanz angezeigt.

Jetzt öffnen wir die Remote Desktop Verbindung und tragen dort den Public DNS Namen ein.

Nach dem Klick auf Verbinden geben wir den Benutzernamen und das Passwort, das wir oben erhalten haben, ein.

Die Verbindung wird hergestellt.

Nun müssen wir noch das Zertifikat unserer Instanz akzeptieren.

Wir sind mit unserer Instanz verbunden.

Beenden der Instanz

Um die Instanz wieder zu beenden gehen wir zurück zu der AWS Management Console klicken mit der rechten Maustaste auf die Instanz und wählen Terminate.

Nach dem Bestätigen wird die Instanz beendet.

In der AWS Management Console ist am gelben Punkt zu sehen, dass die Instanz beendet wird. Das benötigt ein wenig Zeit.



Erste Schritte mit Amazon EC2 – Linux

Dieses Tutorial beschreibt das Einrichten einer virtuellen Instanz mit einem Fedora Linux AMI (Amazon Machine Image) auf Basis der Amazon Elastic Compute Cloud (Amazon EC2). Dazu gehören die vollständige Einrichtung der Instanz und der anschließende Zugriff per SSH von einem Windows 7 Computer.

Voraussetzungen

Auswahl, Einrichten und Starten der Instanz

Zuerst öffnen wir die Webseite der Amazon Web Services und melden uns dort an.

Anschließend starten wir die AWS Management Console für EC2.

Hier klicken wir auf Launch Instance.

Ein weiteres Fenster öffnet sich, in dem bereits fertig vor-konfigurierte Amazon Machine Images (AMIs) von Amazon angezeigt werden. Hier wählen wir das erste AMI - Getting Started on Fedora Core 8 (AMI Id: ami-b232d0db)

Nun wählen wir folgende Konfiguration:

  • Number of Instances: 1
  • Availability Zone: No Preference
  • Instance Type: Small (m1.small 1.7 GB)

Als erweiterte Konfiguration wählen wir:

  • Kernel ID: Use Default
  • RAM Disk ID: Use Default
  • Monitoring: Nein

Anschließend erstellen wir ein Schlüsselpaar, hier mit dem Namen clouduser_key und speichern es auf unserem Rechner.

Im nächsten Schritt konfigurieren wir die Firewall, indem wir für unsere AMI eine Security Group erstellen. Die Standardvorgabe ist der externe Zugriff auf die Ports 22 (SSH) und 80 (HTTP). Die Freigabe für den Port 80 habe ich entfernt, da wir sie in diesem Fall nicht benötigen. Wir geben der Security Group einen Namen, hier Security_Group_1 und eine Beschreibung, hier SSH_Only und wählen continue.

Danach erhalten wir eine Zusammenfassung unserer Konfiguration, wo wir mittels Launch unsere Instanz starten.

Über Your instances are now launching kommen wir zur Console zurück.

Dort sehen wir, dass unsere soeben erstellte Instanz aktiv ist und wir uns nun mit ihr verbinden können. Dazu notieren wir uns zunächst den Namen in der Spalte Public DNS.

Verbinden mit der Instanz

Um uns mit der Instanz zu verbinden starten wir zunächst PuTTYgen und laden uns über Load den privaten Schlüssel den wir uns oben erstellt haben.

Wenn dieser geladen ist, klicken wir auf Save private Key und ignorieren das Fenster mit der Passphrase!

Jetzt öffnen wir unseren PuTTY SSH Client und tragen den Public DNS Namen in das Feld Host Name. Der Port 22 (SSH) ist der Standardwert.

Wir navigieren im PuTTY SSH Client auf der linken Seite zu dem Punkt SSH >> Auth. Dort laden wir bei dem Punkt Authentication parameters unseren oben mit PuTTYgen erzeugten privaten Schlüssel.

Nach einem klick auf Open wird eine Verbindung zu unserer Instanz hergestellt.

Dort melden wir uns mit dem Benutzer root an. Nun können wir mit unserer erstellten Linux Instanz arbeiten.

Beenden der Instanz

Um die Instanz wieder zu beenden gehen wir zurück zu der AWS Management Console klicken mit der rechten Maustaste auf die Instanz und wählen Terminate.

Nach dem Bestätigen wird die Instanz beendet.

In der AWS Management Console ist am gelben Punkt zu sehen, dass die Instanz beendet wird. Das benötigt ein wenig Zeit.



Skalierung eines Cluster mit Amazon EC2

Dieses Beispiel zeigt welche Komponenten erstellt und konfiguriert werden müssen, um einen Mini Cluster innerhalb eines privaten Netzwerks unter der Verwendung von NIS und NFS aufzubauen. Zusätzlich werden externe Amazon EC2 Nodes per VPN mit dem Server verbunden und am Ende der Cluster mittels der Sun Grid Engine (SGE) aufgebaut.

Architektur

Folgende technische Voraussetzungen werden benötigt:

  • Das private Netzwerk darf nur über ein VPN erreichbar sein, damit die Nodes die sich darin befinden vollständig isoliert sind.
  • Der Server muss NFS, NIS und VPN unterstützen.
  • Die internen Nodes müssen den NFS und NIS Dienst automatisch vom Server starten.
  • Die externen Nodes sind von Amazon EC2.
  • Die externen Nodes müssen automatisch eine Verbindung in das VPN aufbauen und den NFS und NIS Dienst vom Server starten.

Auf Basis dieser Anforderungen werden 3 Images benötigt.

  • 2 Xen Images - einen Server und einen internen Node
  • 1 Amazon Machine Image (AMI) von Amazon EC2 mit derselben Konfiguration wie der interne Node.

Die Konfigurationen sehen in diesem Beispiel wie folgt aus:

Server

  • Private IP-Adresse: eth0 10.1.1.99
  • Öffentliche IP-Adresse: eth1 147.96.1.100
  • Hostname: oneserver

Xen Node (lokal)

  • Private IP-Adresse: eth0 10.1.1.55
  • Hostname: local01

Amazon EC2 Node (IP-Adress Bereich: 10.1.1.100 bis 10.1.1.254)

  • VPN IP-Adresse: tap0 10.1.1.100 (wird durch den VPN Server vergeben)
  • Öffentliche IP-Adresse: eth0 - wird automatisch von Amazon vergeben
  • Hostname: workernode0

Konfiguration

Konfiguration der Images

Nun wird eine Kopie des Image erstellt und die /etc/hostname und /etc/network/interfaces für den Server (oneserver) editiert. Eine weitere Kopie des Image dient als Node, die oben genannten Dateien müssen für diesen ebenfalls angepasst werden. Nach dem unmount der Images werden diese mit Xen gestartet. Für die Konfiguration von NFS und NIS helfen die beiden nachfolgend verlinkten Howtos.

Bei der Konfiguration des VPN Server ist darauf zu achten, dass alle Clients die Zertifikate doppelt verwenden können. Das liegt daran, da keine separaten Amazon EC2 Instanzen erstellt werden sollen und es sich bei den EC2 Instanzen daher um dieselben handelt. Dazu muss in der Konfigurationsdatei von OpenVPN /etc/openvpn/server.conf in Zeilt "duplicate-cn" eingefügt werden. Die Konfiguration von OpenVPN findet nur auf dem Server statt. Eine Howto für die Konfiguration von OpenVPN ist unter dem folgenden Link zu finden.

Für das Erstellen eines Amazon Machine Images wird der Befehl bundle benötigt, dazu kann der lokale Node genutzt werden. Weiterhin muss der VPN Client und die Sun Grid Engine installiert und konfiguriert werden. Auf dem schnellsten Wege sollte das funktionieren, indem eine Kopie des lokalen Node erstellt und konfiguriert wird, anschließend wird es mit dem Befehl ec2-bundle-image gebündelt.

Während des Boot-Vorgangs wird nun noch ein Skript benötigt, in welchem der IP-Adressbereich von OpenVPN für die Amazon EC2 Instanzen von 10.1.1.100 bis 10.1.1.254 reserviert wird. die Konfiguration erfolgt in der /etc/hosts auf dem Server (oneserver).

EC2 Konfiguration mit OpenNebula

Nach der Konfiguration werden nun die Templates benötigt, um die Maschinen zu starten. Für alle lokalen Maschinen wie den oneserver und die Nodes wird jeweils ein Template benötigt, für die EC2 Maschinen reicht ein Template aus.

clouduser@machine:bin$ ec2-describe-images
IMAGE ami-e4a94d8d one-w2/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-cdb054a4 sge-dolphin/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-d8b753b1 sge-parrot/image.manifest.xml 587384515363 available private i386 machine
IMAGE ami-dcb054b5 sge-squirrel/image.manifest.xml 587384515363 available private i386 machine

Auf Basis des Images "ami-dcb054b5" wird das EC2 Template erstellt.

CPU=1

MEMORY=1700

EC2=[ AMI="ami-dcb054b5", KEYPAIR="gsg-keypair", ELASTICIP="75.101.155.97", INSTANCETYPE="m1.small", AUTHORIZED_PORTS="22-25"]

REQUIREMENTS = 'HOSTNAME = "ec2"'

Deployment und Tests

Um den Test zu starten muss zunächst OpenNebula gestartet und der EC2 Host hinzugefügt werden.

clouduser@machine:one$ one start
oned and scheduler started
lgonzalez@machine:one$ onehost create ec2 im_ec2 vmm_ec2
lgonzalez@machine:one$ onehost list
HID NAME RVM TCPU FCPU ACPU TMEM FMEM STAT
0 ec2 0 0 100 on

Als nächstes wird die EC2 Instanz gestartet.

clouduser@machine:one$ onevm create ec2.template
ID: 0

Die virtuelle Maschine wird später automatisch auf Amazon EC2 bereitgestellt.

clouduser@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 pend 0 0 00 00:00:05
lgonzalez@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 boot 0 0 ec2 00 00:00:15

Mittels onevm show id können alle Informationen eingesehen werden.

clouduser@machine:one$ onevm show 0
VID : 0
AID : -1
TID : -1
UID : 0
STATE : ACTIVE
LCM STATE : RUNNING
DEPLOY ID : i-1d04d674
MEMORY : 0
CPU : 0
PRIORITY : -2147483648
RESCHEDULE : 0
LAST RESCHEDULE: 0
LAST POLL : 1216647834
START TIME : 07/21 15:42:47
STOP TIME : 01/01 01:00:00
NET TX : 0
NET RX : 0

....: Template :....
CPU : 1
EC2 : AMI=ami-dcb054b5,AUTHORIZED_PORTS=22-25,ELASTICIP=75.101.155.97,INSTANCETYPE=m1.small,KEYPAIR=gsg-keypair
IP : ec2-75-101-155-97.compute-1.amazonaws.com
MEMORY : 1700
NAME : one-0
REQUIREMENTS : HOSTNAME = "ec2"

In diesem Beispiel ist die EC2 Instanz über die Adresse ec2-75-101-155-97.compute-1.amazonaws.com zu erreichen.

Nun muss geprüft werden, ob alle virtuellen Maschinen im Cluster gestartet sind. Es existiert eine lokale virtuelle Maschine auf Basis von Xen (local01) und eine von Amazon EC2 (workernode0).

oneserver:~# qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.05 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.04 lx24-x86
----------------------------------------------------------------------------

Um den Cluster zu testen können ein paar Jobs mittels qsub an die Sun Grid Engine geschickt werden.

oneserver:~# qsub test_1.sh; qsub test_2.sh;

Nun ist zu sehen, welche Jobs im Hybrid Cluster geplant und gestartet sind.


clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 0/1 0.02 lx24-x86
----------------------------------------------------------------------------
all.q@workernode0 BIP 0/1 0.01 lx24-x86
----------------------------------------------------------------------------
############################################################################
- PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
1180 0.00000 test_1.sh clouduser qw 07/21/2008 15:26:09 1
1181 0.00000 test_2.sh clouduser qw 07/21/2008 15:26:09 1

clouduser@oneserver:~$ qstat -f
queuename qtype used/tot. load_avg arch states
----------------------------------------------------------------------------
all.q@local01 BIP 1/1 0.02 lx24-x86
1181 0.55500 test_2.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------
all.q@workernode0 BIP 1/1 0.07 lx24-x86
1180 0.55500 test_1.sh clouduser r 07/21/2008 15:26:20 1
----------------------------------------------------------------------------

Es können beliebig viele externe Amazon EC2 Instanzen automatisch zum Cluster als Nodes hinzugefügt werden und damit die Skalierbarkeit dynamisch erhöht werden.

Quelle



Skalierung von Web-Servern auf Amazon EC2

Dieses Beispiel zeigt, wie eine skalierbare Web Anwendung auf einer virtuellen Infrastruktur bereitgestellt wird. Um dies zu erreichen wird ein Load Balancer als Master Node für diese Web Anwendung eingesetzt. Hinter dem Load Balancer werden Slave Nodes eingesetzt, die über eine Kopie dieser Web Anwendung verfügen, für den Fall, dass eine Anfrage zu ihnen weitergeleitet wird. Die Leistung (Anfragen pro Sekunde) der Web Anwendung kann durch das Starten oder Herunterfahren von virtuellen Instanzen, die als Nodes des Load Balancer dienen, dynamisch erhöht oder verringert werden.

Ein Teil dieses Beispiels zeigt, wie Remote Nodes (Amazon EC2) eingesetzt werden, wenn die lokale Infrastruktur (auf Basis von Xen) ausgelastet ist.

Architektur

Folgende Komponenten werden für den Aufbau der virtuellen Infrastruktur genutzt:

  • Ein NGinx Server als Load Balancer - zur Aufteilung der Anfragen an die Webserver.
  • Mehrere NGinx Server als Webserver (die einzelnen Nodes des Load Balancer), die jeweils auf einer virtuellen Maschine ausgeführt werden.

Mit den folgenden Eigenschaften:

  • Die virtuellen Maschinen, auf welchen die Webserver ausgeführt werden, können sich lokal (auf dem Xen Hypervisor innerhalb der lokalen Infrastruktur) oder remote (auf Amazon EC2 Instanten) befinden.
  • Die Verwaltung (Monitoring, Deployment, Miration, ...) der virtuellen Maschinen wird mit OpenNebula vorgenommen.

Die obere Graphik beschreibt folgende Eigenschaften:

  • Die grünen Pfeile stehen für Web-Anfragen durch die Web-Clients an den Load Balancer.
  • Die roten Pfeile sind die Anfragen der Web-Clients, die von dem Load Balancer an die Webserver weitergeleitet werden.
  • Die orangen Pfeile stehen für das Monitoring und der Verwaltung durch den Virtual Machine Manager (OpenNebula).

Durch das dynamische Bereitstellen und Hinzufügen weiterer virtueller Webserver zu dem Load Balancer, verfügt diese Infrastruktur über eine hohe Fehlertoleranz, Verfügbarkeit und Skalierbarkeit. Darüber hinaus unterstützt die (virtuelle) Infrastruktur zwei unterschiedliche Virtualisierungs-Technologien (Xen und Amazon EC2), wodurch eine Erweiterung der lokalen Infrastruktur durch eine externe Infrastruktur möglich ist.

Konfiguration
Zunächst muss OpenNebula für das Deployment der virtuellen Infrastruktur konfiguriert werden. Weiterhin muss NGinx auf die Systeme installiert werden, die später den Load Balancer und die Webserver beherbergen sollen. Das Vorgehen dazu ist in dem folgenden Howto beschrieben.

Für die Konfiguration des Load Balancer gelten dieselben Schritte wie in dem oben genannten Howto. Als Konfigurationsdatei kann die nachfolgend aufgeführte genutzt werden. Hier ist der Host definiert, der als Load Balancer verwendet wird und welche Auswahlmethode (round-robin, gewichtet) genutzt werden soll.


clouduser@machine:one$ vim nginx.conf

user www-data;
worker_processes 1;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
sendfile on;
keepalive_timeout 65;
tcp_nodelay on;
gzip on;
server {
listen 80;
server_name localhost;
access_log /var/log/nginx/localhost.access.log;
location / {
proxy_pass http://one_loadbalancer;
}
}
upstream one_loadbalancer {
server 10.1.1.11:80 ;
server 10.1.1.22:80 ;
server 10.1.1.33:80 ;
server 10.1.1.44:80 ;
}
}

Im Bereich upstream der Konfigurationsdatei werden die virtuellen Webserver definiert, auf welche die Anfragen für den Lastausgleich aufgeteilt werden. Hier müssen ggf. weitere virtuelle Webserver hinzugefügt werden.

In diesem Beispiel haben die Webserver die IP-Adressen 10.1.1.11, 10.1.1.22, 10.1.1.33 und 10.1.1.44. Damit können also vier Nodes verwendet werden.

Der Load Balancer verfügt über:

  • eine private IP-Adresse für die Kommunikation mit den Nodes im privaten Netzwerks. (in diesem Beispiel 10.1.1.99)
  • eine öffentliche IP-Adresse für die Kommunikation mit den Web-Clients und den Amazon EC2 Instanzen.

Die Amazon EC2 haben öffentliche IP Adressen und kommunizieren mit OpenNebula und dem Load Balancer über das Internet.

Um OpenNebula für die Kommunikation mit Amazon EC2 zu konfigurieren und die Instanzen mit NGinx bereitzustellen sind folgende Schritte notwendig.

Jetzt können die Templates für die lokalen und remote Machinen erstellt werden.

Für den Load Balancer wird folgendes Template verwendet:

clouduser@machine:one$ cat xen.loadbalancer
CPU = 0.5
MEMORY = 128
OS = [kernel="/boot/vmlinuz",initrd= "/boot/initrd",root="sda1" ]
DISK = [source="/images/loadbalancer.disk",target="sda",readonly="no"]

Die lokalen Maschinen verwenden diese Templates:

clouduser@machine:one$ cat xen.local01
CPU = 0.5
MEMORY = 128
OS = [kernel="/boot/vmlinuz",initrd= "/boot/initrd",root="sda1" ]
DISK = [source="/images/local01.disk",target="sda",readonly="no"]

Die Pfade zu den Images und dem Kernel müssen entsprechend der eigenen Umgebung angepasst werden. Aus den Images können beliebig viele Klone für die lokalen Nodes erstellt werden.

Die folgenden Templates werden für die remote Maschinen (Amazon EC2) verwendet.

clouduser@machine:one$ cat ec2.template
CPU=1
MEMORY=1700
EC2=[
AMI="ami-yao044b1",
KEYPAIR="gsg-keypair",
INSTANCETYPE="m1.small",
AUTHORIZED_PORTS="22-25"
]
REQUIREMENTS = 'HOSTNAME = "ec2"'

Die Parameter AMI Identifier, Key-Pair, Memory etc. müssen entsprechend der eigenen Umgebung angepasst werden.

Deployment und Test

Jetzt wird der virtuelle Cluster initialisiert. Zunächst wird der OpenNebula Daemon gestartet und mit dem onehost Befehl eine Host in die Liste der Ressourcen aufgenommen.

clouduser@machine:one$ one start
oned and scheduler started
clouduser@machine:one$ onehost create ec2 im_ec2 vmm_ec2
clouduser@machine:one$ onehost create ursa03 im_xen vmm_xen

Anschließend werden die virtuellen Maschinen mit dem onevm Befehl erstellt.

clouduser@machine:one$ onevm create xen.loadbalancer
ID: 0
clouduser@machine:one$ onevm create xen.local01
ID: 1
clouduser@machine:one$ onevm create xen.local02
ID: 2
clouduser@machine:one$ onevm create xen.local03
ID: 3
clouduser@machine:one$ onevm create xen.local04
ID: 4
clouduser@machine:one$ onevm create ec2.template
ID: 5
clouduser@machine:one$ onevm create ec2.template
ID: 6
clouduser@machine:one$ onevm create ec2.template
ID: 7
clouduser@machine:one$ onevm create ec2.template
ID: 8

Mit dem onevm Befehl kann anschließend der Status der Instanzen überprüft werden.

clouduser@machine:one$ onevm list
ID NAME STAT CPU MEM HOSTNAME TIME
0 one-0 runn 12 512 ursa03 00 00:01:15
1 one-1 runn 8 512 ursa03 00 00:01:11
2 one-2 runn 10 512 ursa03 00 00:01:10
3 one-3 runn 11 512 ursa03 00 00:01:02
4 one-4 runn 23 512 ursa03 00 00:00:51
5 one-5 runn 0 512 ec2 00 00:00:48
6 one-6 runn 0 512 ec2 00 00:00:48
7 one-7 runn 0 512 ec2 00 00:00:45
8 one-7 runn 0 512 ec2 00 00:00:43

Nachdem alle virtuellen Maschinen gestartet sind, kann der Load Balancer die Anfragen der Webclients annehmen. Nun muss noch für jede virtuelle Maschine die IP-Adresse in die /etc/nginx/nginx.conf eingetragen werden. Darüber wird dem NGinx Load Balancer mitgeteilt welcher Node bereit ist.

Die Leistung der Webanwendung kann durch das Hinzufügen weiterer lokaler oder Amazon EC2 Nodes mittels xen.localXX oder ec2.template und der Aktualisierung der Load Balancer Konfigurationsdatei erhöht werden.

Das Hinzufügen kann durch die Entwicklung eines Service Managers automatisiert werden.

Quelle