Kategorien
Grundlagen Services

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

Kategorien
Grundlagen Services

Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen

Amazon EC2 bietet die Möglichkeit, Instanzen über mehrere Standorte zu verteilen. Dabei sind die Standorte in Verfügbarkeitszonen (Availability Zones) und Regionen aufgeteilt. Die Regionen sind verstreut und befinden sich in getrennten geographischen Gebieten wie den USA und Europa. Verfügbarkeitszonen sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Verfügbarkeitszonen nicht betroffen sind. Dazu bieten sie eine kostengünstige Konnektivität mit einer geringen Netzwerklatenz zu anderen Verfügbarkeitszonen in der gleichen Region.

Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden.

Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Verfügbarkeitszonen ausgeführt werden.

Die folgende Graphik zeigt eine Darstellung der Amazon EC2 Regionen und Verfügbarkeitszonen. Jede Region ist völlig unabhängig. Jede Verfügbarkeitszone ist vollständig isoliert, aber durch Netzwerkverbindungen mit einer geringen Latenz mit anderen Verfügbarkeitszonen verbunden.

Regionen

Amazon EC2 verfügt über mehrere Regionen, wodurch EC2 Instanzen an den Standorten ausgeführt werden können, die den eigenen Anforderungen entsprechen. Um z.B. als nicht europäisches Unternehmen Kunden in Europa Dienstleistungen anzubieten und zudem den dort gesetzlichen Anforderungen gerecht zu werden, können die EC2 Instanzen in einer Verfügbarkeitszone der Region Europa ausgeführt werden.

Jede Amazon EC2 Region ist so konstruiert, dass sie vollständig isoliert von allen anderen Amazon EC2 Regionen betrieben wird. Damit wird die größtmögliche Unabhängigkeit und Stabilität erzielt und macht den Ort einer jeden EC2 Ressource eindeutig.

Um Instanzen zu starten oder mit diesen zu arbeiten, muss zunächst die korrekte URL eines Endpunkts einer Region definiert werden. Soll z.B. eine Instanz in der Region US-East (Standard Region) betrieben werden, wird als Endpunkt URL ec2.us-east-1.amazonaws.com verwendet.

In der folgenden Tabelle sind alle Regionen mit ihren zugehörigen Endpunkten dargestellt.

Region Endpoint
US-East (Northern Virginia) Region ec2.us-east-1.amazonaws.com
US-West (Northern California) Region ec2.us-west-1.amazonaws.com
EU (Ireland) Region ec2.eu-west-1.amazonaws.com
Asia Pacific (Singapore) Region ec2.ap-southeast-1.amazonaws.com

Verfügbarkeitszonen

Fehler können auftreten, die Auswirkungen auf die Verfügbarkeit von Instanzen haben, die sich an dem gleichen Standort befinden. Auch wenn das ziemlich selten vorkommt – wenn alle Amazon EC2 Instanzen an einem einzigen Standort gehostet werden, der von einer Störung betroffen ist, sind diese Instanzen nicht mehr verfügbar.

Sind z.B. Instanzen über drei Verfügbarkeitszonen verteilt und eine dieser Instanzen fällt aus, kann eine Anwendung zu konzipiert werden, dass die Instanzen in den übrigen Verfügbarkeitszonen die Anfragen automatisch entgegennehmen und verarbeiten.

Quelle

Kategorien
Grundlagen Services

Das Konzept des Amazon Elastic Block Store

Der Amazon Elastic Block Store (Amazon EBS) ist eine spezielle Speicherart, die speziell für Amazon EC2 Instanzen konstruiert wurde. Mit Amazon EBS können Volumes erstellt werden, die von Amazon EC2 Instanzen wie externe Geräte eingebunden (gemounted) werden können. Amazon EBS Volumes verhalten sich wie unformatierte externe Block-Devices. Sie können durch den Benutzer benamt werden und stellen eine Block-Device-Schnittstelle bereit. EBS Volumes können mit einem Dateisystem ausgestattet oder wie ein gewöhnliches Block-Device genutzt werden.

Ein AWS Account ist auf 100 EBS Volumes oder in der Summe auf eine Volume Gesamtspeichergröße von 20 Terrabyte begrenzt. Dabei beträgt die maximale Größe eines Volumes 1 Terrabyte. Jedes EBS Volume kann jeder EC2 Instanz innerhalb derselben Verfügbarkeitszone hinzugefügt werden.

Mit Amazon EBS können Snapshots (Backups) der EBS Volumes erstellt und auf Amazon S3 gespeichert werden. Diese Snapshots können als Ausgangspunkt für neue EBS Volumes genutzt werden und schützen die Daten langfristig. Weiterhin können Snapshots mit bestimmten Benutzern geteilt oder öffentlich verfügbar gemacht werden.

Amazon EBS Volumes verfügen über folgende Eigenschaften:

  • Speichern ausserhalb der Instanz
  • Persistenz jenseits der Lebensdauer von Instanzen
  • Hohe Verfügbarkeit und Zuverlässigkeit
  • Hinzufügen und Entfernen der Volumes für bereits ausgeführte Instanzen
  • Darstellung als ein eigenes Gerät innerhalb der Instanz

Amazon EBS Snapshots verfügen über folgende Eigenschaften:

  • Erfassung des aktuellen Zustands eines Volumes
  • Datensicherung
  • Instanziierung neuer Volumes, die den exakten Inhalt eines Snapshots beinhalten

Amazon EBS Anwendungsfälle


Fehlertoleranz

Amazon EBS ist so konstruiert, dass jede Instanz zu einem Speichervolumen hinzugefügt werden kann. Fällt eine Instanz auf Grund eines Fehlers aus, löst sich das EBS Volume automatisch mit den intakten Daten von der Instanz. Anschließend kann das Volume zu einer neuen Instanz hinzugefügt werden und der Wiederherstellungprozess beginnen.

Erklärung

  • 1. Eine Amazon EC2 Instanz ist mit einem EBS Volume verbunden. Die Instanz fällt aus, bzw. Probleme treten auf.
  • 2. Zur Wiederherstellung muss das EBS Volume nun von der Instanz gelöst werden. Das kann auch automatisch durch das EBS Volume erfolgen. Anschließend wird eine neue Instanz gestartet und das Volume dieser neuen Instanz hinzugefügt.
  • 3. Für denn Fall das ein Amazon EBS Volume ausfällt, kann eines neues EBS Volume auf Basis des jüngsten Snapshots des Volumes erstellen, dass ausgefallen ist.

Neue Volumes auf Basis von Snapshots erstellen

Amazon EBS Snapshots ermöglichen den schnellen Einsatz neuer Volumes, indem ein bereits vorhandener Snapshot als Ausgangspunkt für diese neuen Volumes dient.

Erklärung

  • 1. Es wird ein Web-Service mit einer großen Datenmenge verwendet.
  • 2. Wenn die Daten fertig sind, kann ein Snapshot des Volumes in Amazon S3 zur langfristigen Datensicherung gespeichert werden.
  • 3. Wenn der Datenverkehr und Ressourcenverbrauch ansteigt, kann aus dem Snapshot ein neues Volume erstellt, eine neue Instanz gestartet und anschließend dieser neuen Instanz das neue Volume hinzugefügt werden.
  • 4. Wenn sich der Datenverkehr wieder verringert, können eine oder mehrere Amazon EC2 Instanzen heruntergefahren und ihre EBS Volumes gelöscht werden.

Datenpersistenz

EBS Volumes existieren unabhängig von den aktuell vorhandenen Instanzen und bleiben solange vorhanden, bis sie explizit gelöscht werden. Das ermöglicht das Speichern von Daten, ohne dass eine Instanz gestartet sein muss.

Erklärung

  • 1. In regelmäßigen Abständen wird eine Instanz zur Batchverarbeitung von großen und wachsenden Datenmengen ausgeführt.
  • 2. Am Ende der Verarbeitung wird die EC2 Instanz beendet. Das EBS Volume wird aber weiterhin ausgeführt.
  • 3. Werden die Daten das nächste Mal verarbeitet, wird eine neue EC2 Instanz gestartet und dem bereits vorhandenen EBS Volume hinzugefügt.

Auf Basis dieses Vorgehens können die Daten nur mit den Ressourcen auf unbestimmte Zeit verarbeitet und gespeichert werden, die auch tatsächlich benötigt werden.

Root Partition

EBS Volumes können als Root Device (Partition) für Linux und Windows Instanzen verwendet werden. Dadurch besteht die Möglichkeit Root Partitionen mit der Größe von bis zu 1 Terrabyte zu nutzen.

Weiterhin kann das EBS Volume (als Root Partition) von einer anderen Instanz gemounted werden, falls eine Instanz ausfällt.

Die Größe der Partition kann während des Startvorgangs mittels Block Device Mapping geändert werden.

Erklärung

  • 1. Ein vorhandenes AMI ist in Amazon EBS gespeichert. Es Änderungen daran vorgenommen und ein neues AMI erstellt.
  • 2. Falls die Größe der Root Partition nicht mehr ausreicht, wird die Instanz gestoppt und mit einem größeren EBS Volume neu gestartet.
  • 3. Falls eine Instanz ausfallen sollte, wird eine neue Instanz gestartet und die Root Partition (EBS Volume) der ausgefallenen Instanz gemounted.

Große Datenmengen

Amazon EBS bietet größere Volumes als Amazon EC2 Instanzen. Jedes EBS Volume kann bis zu einem Terrabyte groß sein.

Quelle

Kategorien
Grundlagen Services

Das Amazon EC2 Adressierungskonzept

Dieser Artikel beschreibt das Adressierungskonzept von Amazon EC2. Das beinhaltet die Arten von IP-Adressen, die für EC2 Instanzen zur Verfügung stehen.

Alle Amazon EC2 Instanzen erhalten während des Starts zwei IP Adressen zugewiesen. Eine private Adresse (RFC 1918) und eine öffentliche Adresse (public), die mittels Network Address Translation (NAT) direkt aufeinander abgebildet werden. Private Adressen sind nur innerhalb des Amazon EC2 Netzwerks erreichbar. Öffentliche Adressen hingegen sind aus dem Internet erreichbar.

Weiterhin stellt Amazon EC2 einen internen, sowie einen öffentlichen DNS Namen zur Verfügung, der jeweils der privaten bzw. öffentlichen IP-Adresse zugewiesen wird. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der interne DNS Name kann nur innerhalb des Amazon EC2 Netzwerk aufgelöst werden. Der öffentliche DNS Name hingegen löst die öffentliche IP-Adresse außerhalb des Amazon EC2 Netzwerks und die private IP-Adresse innerhalb des EC2 Netzwerks auf.

Private Adressen (RFC 1918)

Alle Amazon EC2-Instanzen erhalten eine private Adresse per DHCP zugewiesen. Die Adressbereiche sind in RFC 1918 definiert und können nur innerhalb des Amazon EC2 Netzwerks gerouted werden. Die privaten IP-Adressen werden für die Kommunikation zwischen den jeweiligen Instanzen verwendet.

Die private Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird. Anschließend wird die Adresse wieder an Amazon EC2 zurückgegeben und kann dann erneut an eine andere Instanz vergeben werden.

Es sollte darauf geachtet werden, dass immer die internen Adressen verwendet werden, wenn zwischen Amazon EC2 Instanzen kommuniziert wird. Damit ist sichergestellt, dass der Datenverkehr immer mit der höchsten Bandbreite übertragen wird und die Latenz innerhalb des Amazon EC2 Netzwerks so gering wie möglich ist.

Interner DNS Name

Jede Instanz verfügt über einen internen DNS Namen, der zu der entsprechenden privaten IP-Adresse der Instanz innerhalb des Amazon EC2 Netzwerks aufgelöst wird. Der interne DNS Name wird nicht ausserhalb von Amazon EC2 aufgelöst.

Öffentliche Adressen

Während des Starts wird eine öffentliche Adresse einer EC2 Instanz mittels Network Address Translation (NAT) zugewiesen. Die öffentliche Adresse ist mit einer Instanz solange verknüpft, bis diese Instanz wieder beendet wird oder durch eine Elastic IP-Address ausgetauscht wird.

Kommunizieren Instanzen mit anderen Instanzen über ihre öffentliche IP Adresse entstehen zusätzliche Kosten, basierend auf regionalen oder dem Internet Datenverkehr, je nachdem ob sich die Instanzen in der selben Region befinden.

Öffentlicher DNS Name

Jede Instanz verfügt über einen externen DNS Namen, der zu der entsprechenden öffentlichen IP-Adresse der Instanz ausserhalb des Amazon EC2 Netzwerks und von innerhalb des EC2 Netzwerks aufgelöst wird.

Quelle

Kategorien
Grundlagen Services

Typen von EC2 Instanzen

Amazon EC2 Instanzen sind in drei Gruppen unterteilt. Standard, High-CPU und High-Memory. Standard Instanzen sind so ausgestattet, dass sie allen Anforderungen von gewöhnlichen Anwendungen gerecht werden. High-CPU Instanzen verfügen über verhältnismäßig mehr Prozessoren als Arbeitsspeicher und sind auf rechenintensive Anwendungen ausgelegt. High-Memory Instanzen hingegen verfügen über mehr Arbeitsspeicher und sind für Anwendungen mit einem hohen Datendurchsatz, wie z.B. Datenbanken und Caching, ausgelegt.

Bei der Auswahl einer Instanz kann somit jedem Server seine eigene Instanz zugewiesen werden. Für einen Webserver wird z.B. eine weniger leistungsstarke Instanz benötigt als für einen Datenbankserver.

Verfügbare Instanz-Typen

Die folgende Tabelle beschreibt die verfügbaren EC2 Instanz-Typen.

Typ
CPU
Arbeitsspeicher
Lokaler Speicher
Plattform
I/O
Name
Small 1 EC2 Compute Unit (1 virtual core mit 1 EC2 Compute Unit) 1.7 GB 160 GB instance storage (150 GB plus 10 GB root partition) 32-bit Moderate m1.small
Large 4 EC2 Compute Units (2 virtual cores mit je 2 EC2 Compute Units) 7.5 GB 850 GB instance storage (2 x 420 GB plus 10 GB root partition) 64-bit High m1.large
Extra Large 8 EC2 Compute Units (4 virtual cores mit je 2 EC2 Compute Units) 15 GB 1690 GB instance storage (4 x 420 GB plus 10 GB root partition) 64-bit High m1.xlarge
High-CPU Medium 5 EC2 Compute Units (2 virtual cores mit je 2.5 EC2 Compute Units) 1.7 GB 350 GB instance storage (340 GB plus 10 GB root partition) 32-bit Moderate c1.medium
High-CPU Extra Large 20 EC2 Compute Units (8 virtual cores mit je 2.5 EC2 Compute Units) 7 GB 1690 GB instance storage (4 x 420 GB plus 10 GB root partition) 64-bit High c1.xlarge
High-Memory Extra Large 6.5 EC2 Compute Units (2 virtual cores mit 3.25 EC2 Compute Units) 17.1 GB 420 GB instance storage (1 x 420 GB) 64-bit Moderate m2.xlarge
High-Memory Double Extra Large 13 EC2 Compute Units (4 virtual cores mit je 3.25 EC2 Compute Units) 34.2 GB 850 GB instance storage (1 x 840 GB plus 10 GB root partition) 64-bit High m2.2xlarge
High-Memory Quadruple Extra Large 26 EC2 Compute Units (8 virtual cores mit je 3.25 EC2 Compute Units) 68.4 GB 1690 GB instance storage (2 x 840 GB plus 10 GB root partition) 64-bit High m2.4xlarge
HCluster Compute 33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core „Nehalem“ architecture) 23 GB 1690 GB instance 64-bit storage (2 x 840 GB plus 10 GB root partition) 64-bit Very high (10 Gbps Ethernet) cc1.4xlarge

Quelle

Kategorien
Services

Amazon ist das Mass aller Dinge im Cloud Computing Markt!

Amazon ist mit seinen Amazon Web Services (AWS) derzeit der Player im Cloud Computing Markt. Was wir bereits erahnt haben bzw. wussten, haben die Analysten Brian Pitz und Brian Fitzgerald von der UBS nun anhand von Zahlen bestätigt.

Die beiden gehen davon aus, dass AWS im Jahr 2010 etwa einen Umsatz von 500 Millionen US Dollar generieren und diesen im Jahr 2011 auf 750 Millionen US Dollar erhöhen wird. Bis zum Jahr 2014 wird ein Umsatz in der Höhe von 2,54 Milliarden US Dollar erwartet.

Weiterhin wird davon ausgegangen, dass der Gesamtmarkt für AWS-Dienste zwischen 5 Milliarden und 6 Milliarden US Dollar im Jahr 2010 und schließlich bis zu 15 Milliarden und 20 Milliarden US Dollar im Jahr 2014 wachsen wird.

Quelle

  • How Big is Amazon’s Cloud Computing Business?
Kategorien
Grundlagen Services

Das Konzept der Amazon Elastic IP Addresses

Standardmäßig erhalten alle Amazon EC2 Instanzen zwei IP Adressen wenn sie gestartet werden. Eine private Adresse (RFC 1918) und eine öffentliche Adresse, die mit der privaten Adresse mittels Network Address Translation (NAT) verknüpft wird.

Sollte Dynamic DNS eingesetzt werden, um einen vorhandenen DNS Namen auf eine öffentliche IP-Adresse einer neuen Instanz abzubilden kann es bis zu 24 Stunden dauern, bis die IP Adresse im Internet bekannt ist. Das kann dazu führen, dass neue Instanzen noch keinen Datenverkehr empfangen, während bereits beendete Instanzen noch weitere Anfragen erhalten.

Diese Problematik umgeht Amazon EC2 mit den Elastic IP Addresses. Elastic IP Addresses sind statische IP-Adressen die für dynamisches Cloud Computing entwickelt wurden. Die Adressen werden einem AWS Account und nicht einer bestimmten Instanz zugeordnet. Jede Adresse die mit einem AWS Account verbunden ist, bleibt es auch solange, bis die Adresse wieder explizit freigegeben wird. Im Gegensatz zu herkömmlichen statischen IP-Adressen verbergen Elastic IP Addresses auftretende Fehler von Instanzen oder Verfügbarkeitszonen, indem die öffentliche IP-Adresse schnell einer anderen Instanz des AWS Accounts zugewiesen werden kann.

Es kann nur eine Elastic IP Address mit einer Instanz zur Zeit verknüpft werden. Wird eine Elastic IP Address mit einer Instanz verknüpft, wird die öffentliche IP Adresse der Instanz wieder für den öffentlichen IP-Adressen Pool von Amazon EC2 freigegeben. Wird die Elastic IP Address wieder von der Instanz gelöst, erhält die Instanz innerhalb von ein paar Minuten automatisch eine neue öffentliche IP-Adresse.

Im folgenden Bild sind die Web Server über Elastic IP Addresses mit dem Internet und über ihre privaten Adressen mit den Datenbankservern verbunden.

Der Administrator hat sich entschieden, einen Web Server durch einen größeren Instanz Typ zu ersetzen. Dazu startet er eine neue Instanz mit einem größeren Instanz Typ (1). Anschließend löst er eine Elastic IP Address von einer bereits gestarteten Instanz (2). Nun verknüpft er die Elastic IP Address mit der neuen Instanz (3) und beendet die alte Instanz (4).

Elastic IP Addresses die nicht mit einer Instanz verknüpft sind, werden stündlich berechnet. Dagegen sind Elastic IP Addresses die mit einer Instanz verbunden sind kostenlos.

Quelle

Kategorien
Services

Facebook macht CRM mit Sales Cloud

München – Facebook hat für das Management seiner wachsenden Vertriebsaktivitäten die CRM-Lösung Sales Cloud von salesforce.com ausgewählt. Der Social Networking Anbieter stand vor der Entscheidung, das eigene System weiter auszubauen oder eine komplett neue Lösung einzusetzen. Die Vorteile eines webbasierten Ansatzes haben überzeugt: Durch die schnelle Implementierung und die hohe Skalierbarkeit kann die Cloud Computing Lösung mühelos mit der rasanten Wachstumsgeschwindigkeit eines Unternehmens wie Facebook Schritt halten. Das neue CRM-System wird bei allen Vertriebsteams sowie für das Management der Entwicklerpartnerschaften eingesetzt, um komplexe Workflows und Freigabeprozesse zu automatisieren.

Kommentare:
Sheryl Sandberg, Chief Operations Officer bei Facebook: „Facebook und salesforce.com teilen eine Vision: Wir wollen Menschen dabei unterstützen, miteinander in Kontakt zu treten und Informationen effizienter auszutauschen. Das Cloud Computing Modell von salesforce.com passt perfekt zu uns. Mit unserer derzeitigen Wachstumskurve und den zukünftigen Vertriebszielen brauchen wir ein Produkt, das mit uns mit wachsen kann.“

Marc Benioff, Gründer und CEO von salesforce.com: „Facebook schließt sich den Tausenden von Unternehmen an, die ihre Vertriebsaktivitäten bereits in der Cloud verwalten. Damit können sich Vertriebsverantwortliche auf das Wachstum des Unternehmens konzentrieren, anstatt auf die Bedienung von Hard- und Software.“

Kategorien
Services

AppLogic

Bei AppLogic handelt es sich um eine vorgefertigte Cloud Computing Plattform, auf der verteilte Anwendungen skalierbar ausgeführt werden können. Mittels AppLogic können Cloud Angebote und Utility Computing Services für transaktionale sowie Streaming Anwendungen im eigenen Rechenzentrum betrieben werden.

Auf Grund der Transparenz und Herstellerunabhängigkeit ist AppLogic zu den gängigen Betriebsystemen, Middlewares und Web Anwendungen kompatibel, wodurch eine Vielzahl von vorhandener Infrastruktursoftware, Middleware und Anwendungen unverändert genutzt werden können.

Mit AppLogic kann eine vollständig verteilte Anwendung (N-tier) oder Service in eine logische Einheit zusammengefasst und anschließend wie ein einziges System verwaltet werden. Dazu erfasst und arbeitet AppLogic auf der logischen Struktur der Anwendung. Dieser Ansatz ermöglicht zudem das Zusammenstellen, das Deployment, das Monitoring, die Steuerung und die Fehlersuche visuell mittels eines Webbrowsers.

Jede Anwendung beinhaltet alles was sie benötigt, um innerhalb eines Grids von Commodity-Servern ausgeführt zu werden, wie z.B. die Infrastrukturkomponenten (Firewalls, Loadbalancer, Netzwerkkonfiguration, etc.) bis hin zur Anwendungslogik, Web- und Datenbankservers, inkl. dem Anwendungscode und der Anwendungsdaten. Tools für das Monitoring und Messen gehören des Weiteren ebenso dazu wie vorbereitete operative Funktionen wie z.B. Backup-Scheduler und SLA Richtlinien.

Aus den oben beschriebenen Gründen können auf AppLogic ausgeführte Anwendungen von einer geringen Anzahl von Servern auf mehrere Hundert skaliert werden. Dazu kommt die Möglichkeit der On-Demand Replizierung und das mehrfache Deployment auf dem selben Grid oder über mehrere Standorte hinweg, ohne Code Änderungen vorzunehmen.

Funktionen


Paketieren von Anwendungen zur on-Demand Bereitstellung
Mit AppLogic können mehrere Instanzen bereits vorgefertigter Web Anwendungen ausgeführt werden, wodurch on-Demand Anwendungen wie CRM, E-Mail oder VoIP PBX schnellt bereitgestellt werden können.

Hierzu können für jeden Kunden eine gewünschte Anwendung mit einer IP-Adresse und den benötigten Hardware Ressourcen ohne manuellen Eingriff konfiguriert und in kurzer Zeit zur Verfügung gestellt werden.

Anwendungsbereitstellung auf einer vorgefertigten Infrastruktur
Web Anwendungen können ohne den notwendigen Konfigurationsaufwand der Server und der Infrastruktur skalierbar bereitgestellt werden. Dazu wird eine Standard Infrastruktur aus einem Katalog ausgewählt, die benötigten HTML Dateien, Skripte, und Datenbanken auf ein logisches Volume kopiert und die Anwendung gestartet.

Weiterhin kann der Deploymentvorgang über Skripte in den Build-Vorgang intergriert werden, wodurch alle vorgenommen Änderung automatisch über das gesamte Grid verteilt werden, wenn der Code neu generiert wird.

Skalierung ohne den Aufbau eines mandantenfähigen Systems
SaaS Anwendungen haben den Anspruch voneinander getrennt betrieben zu werden, so das maximal nur Benutzer aus der selben Organisation den Zugriff auf dieselben Daten erhalten. Nutzer anderer Organisationen dürfen dagegen keinen Einblick auf die Anwendung und Daten haben, auch wenn sich diese logisch auf dem selben System befinden.

Innerhalb von AppLogic erhält jede Anwendung ihre eigene separierte Infrastruktur wie Datenbanken, Applikationsserver etc., wodurch der oben genannte Anspruch erfüllt und Ausfälle in Systemen eines Kunden nicht die Systeme anderer Kunden beeinflussen.

Entwicklung neuer Web Anwendungen
AppLogic bietet die Möglichkeit (neue) Anwendungen mit exakt derselben Infrastruktur (Middleware / Systemkonfiguration) zu testen, wie sie auch später in der Produktion eingesetzt wird. Dazu kann die Anwendung weiterhin in einer Sandbox auf einem einzigen Server betrieben, oder über das gesamte verfügbare Grid verteilt werden, um die Last unter Echtzeitbedingungen zu testen.

Aufbau einer N-Tier Anwendungsinfrastruktur
Mit Hilfe des AppLogic Visual Infrastructure Editor können komplex und verteilte Infrastrukturen skizziert, aufgebaut und repliziert werden. Dazu steht ein Katalog unterschiedlicher virtueller Appliances zur Verfügung, mit dem die Systeme visuell konfiguriert und Fehler identifiziert werden.

Weiterhin können oft und bereits vorkonfigurierte Subsysteme wie z.B. Datenbankcluster oder Applikationsserver Cluster für viele unterschiedliche Anwendungen mehrfach verwendet werden.

Neben dem Monitoring System, mit welchem visuell u.a. die aktuelle Last dargestellt werden kann, besteht ebenfalls der Zugriff per SSH auf jede vorhandene Appliance. Abgerundet werden die Funktionen mit der Möglichkeit eine Art Snapshot von dem aktuellen Stand einer Applikation vorzunehmen, um im Bedarfsfall einen Rollback zurück zu diesem Stand durchzuführen.

Zielgruppe


Alle Utility Computing Benutzern haben gemein, dass Online-Dienste ihre Hauptgeschäft sind. Dabei wirkt sich die Skalierbarkeit und die Kosten ihrer Infrastruktur unmittelbar auf die Bruttomarge und die Fähigkeit aus zu wachsen.

IT Outsourcer die auf SaaS und Online Services fokusiert sind
Unternehmen die Internet Service Provider dabei unterstützen, Online Anwendungen anzubieten und dabei serviceorientiert und skalierbar zu agieren.

Managed Hosting Provider
Unternehmen deren Schwerpunkt im Bereich Datacenter Operations liegt, können ihre bereits vorhandenen Hosting-Angebote mittels vorgefertigten Umgebungen erweitern.

Software-as-a-service (SaaS) Anbieter
Software as a Service Anbieter die regelmäßig neue Web Anwendungen entwickeln, können ihre Go-To-Market Kosten sowie den Time-To-Market reduzieren.

Web 2.0 Unternehmen
Unternehmen im Web 2.0 Umfeld können ihre Online Services skalierbar anbieten, so dass auch in lastintensiven Zeiten ihre Angebote performant zur Verfügung stehen.

Funktionsumfang


Virtual Appliances
Innerhalb von AppLogic werden IT-Infrastrukur Komponenten wie Firewalls, Load Balancer, Server und SANs als bereits vorab integrierte und vorab getestete Virtual Appliances abgebildet. Dabei wird jede Appliance in ihrer eigenen virtualisierten Umgebung ausgeführt. Sie startet ihr eigenes Linux System und erscheint gegenüber der auf der Appliance laufenden Software wie ein physikalischer Server. Neben der bereits vorhandenen Open Source Infrastruktur Software wie Fedora Linux, Apache, MySQL JBoss etc., können die Appliances auf die eigenen Bedürfnisse angepasst bzw. von Grund auf neu aufgesetzt werden.

„Einweg“ Infrastruktur
Die Infrastruktur wird graphisch zusammengesetzt und als Teil einer Anwendung innerhalb von AppLogic gespeichert. Dabei kann die Infrastruktur im wesentlichen als „Einweg“ Komponente bezeichnet werden, da sie auf dem Grid instanziiert wird wenn die Anwendung ausgeführt wird, die Wartung solange erfolgt, bis die Anwendung sie benötigt und entsorgt wird, wenn sich die Anwendung beendet.

Vorgefertigte verteilte Anwendungen
AppLogic verpackt den gesamten Code, die dazugehörigen Daten, sowie die Infrastruktur die zum Ausführen einer skalierbaren Web Anwendung benötigt werden in eine logische Einheit. Diese Einheit kann anschließend gestartet, gestoppt, verwaltet, kopiert oder in ein anderes Grid exportiert werden, ohne eine Änderung daran vornehmen zu müssen.

Zentrale Verwaltung
AppLogic fügt mehrere Commodity Server in ein skalierbares Grid zusammen, das mittels eines Browser oder einer Kommandozeile wie ein einzelnes System verwaltet wird. Zu den Verwaltungsmöglichkeiten gehören Dinge wie das Hinzufügen und Entfernen von Servern „on the fly“, also während das Grid weiterhin ausgeführt wird, die Überwachung der Hardware, das Verwalten von Benutzerdaten, Neustart der Server, Installation von Software, erstellen virtueller Appliances, Systembackups, Reparatur defekter Speichervolumes oder das Prüfen der Logs.

Skalierung von Anwendungen
Anwendungen auf Basis von AppLogic sind vollständig virtualisiert und können von einer kleinen Anzahl von Servern auf viele skaliert werden.

Überwachung der Operationen
AppLogic verfügt über ein Monitoring System, welches völlig transparent zu den Operationen der Web Anwendungen auf dem Grid agiert. Das System kombiniert die Hardware-Infomationen zur Laufzeit, die Informationen der virtuellen Infrastruktur sowie die Informationen der Anwendungen und macht diese über eine graphische Oberfläche verfügbar. Dabei können die System Ressourcen auf Basis der Anwendungen, der virtuellen Appliances/Server oder dem Netzwerkverkehr, sowie diversen Parametern bekannter Softwareinstallation wie Apache oder MySQL überwacht werden.

Hohe Verfügbarkeit
Zur Erhöhung der Verfügbarkeit bietet AppLogic neben der Spiegelung der gespeicherten Daten über mehrere Server hinweg die Möglichkeit einzelne Systeme wiederherzustellen. Weiterhin können zwei identische Instanzen einer Anwendung auf dem selben Grid oder in verschiedenen Rechenzentren parallel betrieben werden, um auf Basis von „Hot Standby“ den Ausfall der Anwendung abzufangen und damit die Verfügbarkeit zu erhöhen.

Überwachung der Ressourcen
AppLogic verfügt über ein integriertes System zur Überwachung der Ressourcen, die von jeder Anwendung genutzt werden. Dazu werden alle Events im Lebenszyklus einer Anwendung verfolgt und protokolliert, um den Ressourcenbedarf wie die Anzahl an Speicher, Prozessorleistung und Bandbreite zu ermitteln, die einer Anwendung zu dem Zeitpunkt des Events zugewiesen waren. Die Protokollierung kann weiterhin dazu genutzt werden, um ein Abrechnungssystem mit Daten zu versorgen und einen Kunden damit exakt die Ressourcen zu berechnen, die er benötigt hat.

Automation und Integration
AppLogic verfügt über eine umfangreiche Kommandozeile inkl. Skripting Funktion und der Möglichkeit zur Anbindung an weitere Management Systeme für Rechenzentren. Auf Basis der Skripte können logische Bedingungen definiert werden, die z.B. den Start, Neustart oder das Beenden von Anwendungen und Appliances hervorrufen.

Ausführen bestehender Anwendungen
Nahezu alle bestehenden Multi-Tier-Anwendung auf Basis von Linux können auf AppLogic ausgeführt werden.

Benutzeroberfläche


AppLogic stellt eine auf AJAX basierende graphische Web-Oberfläche bereit, mit der die gesamte Infrastruktur Umgebung konzipiert und überwacht werden kann.

Die vier folgenden Komponenten bilden das Herzstück von AppLogic und werden durch Screenshots anschließend illustiert.

  • System Dashboard
  • Infrastruktur Editor
  • Graphische Monitoring Konsole
  • Kommandozeile

System Dashboard

Infrastruktur Editor

Graphische Monitoring Konsole

Kommandozeile

Auf die Kommandozeile wird mittels einer Browser basierten Shell zugegriffen. Diese bietet die vollständige Kontrolle über die Anwendungen und Appliances. Dazu gehören das Starten und Stoppen, sowie das reparieren von Volumes oder die Migration von Anwendungen zwischen einzelnen Rechenzentren.

Quelle

  • AppLogic
Kategorien
Services

Amazon stellt Cluster Compute Instanzen für Amazon EC2 bereit

Amazon gibt mit dem heutigen Tag einen neuen Instanz Typ für ihre Amazon Elastic Compute Cloud (EC2) bekannt. Dabei handelt es sich um einen Typ, der speziell für Anwendungen aus dem High-Performance Computing (HPC) konzipiert wurde. Damit haben Nutzer von Amazon EC2 nun die Möglichkeit, eine große Menge von komplexen Daten und rechenintensiven Aufgaben, die eine hohe Auslastung bedeuten, wie z.B. Finanzdienstleistungen, zu verarbeiten.

Der Vorteil der Cluster Compute Instanzen besteht darin, dass diese so entwickelt wurden, deutlich mehr Rechenleistung als die bisherigen Amazon EC2 Instanz Typen bereitzustellen. Weiterhin können Cluster Compute Instanzen in Cluster gruppiert werden, wodurch Anwendungen von der geringeren Netzwerklatenz und der höheren Performanz zwischen den einzelnen Nodes, durch eine bessere und schnellere Kommunikation, profitieren.

Jede Cluster Compute Instanz besteht aus einem Paar von Quad-Core Intel „Nehalem“ X5570 Prozessoren, mit einer maximalen Anzahl von 33,5 ECU (EC2 Compute Units), 23 GB RAM und 1690 GB lokalen Instanzspeicher. Der Preis beträgt $1.60 pro Stunde.

Die EC2 API, die Kommandozeilen Tools, sowie die AWS Management Console wurden bereits aktualisiert, um das Erstellen von Cluster Gruppen zu erstellen.

Die folgenden Befehle erstellen eine Placement Group mit dem Namen biocluster. Anschließend werden 8 Cluster Compute Instanzen innerhalb dieser Gruppe gestartet.

$ ec2-create-placement-group biocluster -s cluster

$ ec2-run-instances ami-2de43f55 --type cc1.4xlarge --placement-group biocluster -n 8