Tag: Cloud Computing

Categories
Grundlagen Services @de

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

Categories
Analysen

Wir brauchen eine transparente Cloud!

Stellen wir uns das folgende Szenario vor:

Wir haben unsere IT Infrastruktur erfolgreich in die Cloud eines Anbieters migriert. Alles bestens, wir sagen uns: “Super, alles funktioniert einwandfrei! Wir senken unsere Kosten. Unsere Infrastruktur ist nun so skalierbar, dass sie unseren Anforderungen immer gerecht wird. Uns stehen immer die aktuellen Software Versionen zur Verfügung und wir können von jedem Ort unabhängig von den lokalen Systemen miteinander kollaborieren.”

Was machen wir aber, falls wir uns nun doch dazu entscheiden wieder in das eigene Rechenzentrum zurückzukehren oder den Cloud Anbieter zu wechseln, weil dieser z.B. günstiger ist? Oder gehen wir noch einen Schritt weiter. Wie können wir unsere gesamten Geschäftsprozesse in der Cloud über mehrere Anbieter hinweg verteilt abbilden? Stellen wir uns vor, dass ein Anbieter den Prozess A verarbeitet, ein weiterer den Prozess B. Ein dritter Anbieter verarbeitet den Prozess C und nutzt dabei die Prozesse A und B. Oder wir verwenden eine Vielzahl voneinander unabhängiger Services von unterschiedlichen Anbietern und integrieren diese zu einem einzigen Service. Wir wir sehen, sind der Komplexität keine Grenzen gesetzt. Ein vermeintlich einfacheres Beispiel: Unsere Daten sind bei dem Anbieter A gespeichert und ein Anbieter B soll diese Daten verarbeiten.

Ist das möglich?

Ein weiterhin sehr kritischer Punkt des Cloud Computing ist das Fehlen von Standards. Jeder Anbieter verwendet unterschiedliche Technologien und kocht innerhalb seiner Infrastruktur seine eigene Suppe. Die meisten Anbieter versuchen in der Regel mittels des gefürchteten Vendor-Lockin ihre Kunden “an sich zu binden”. Denn leider haben es bisher die Wenigsten verstanden, Kunden über guten Service und weitere Dienstleistungen von sich abhängig zu machen.

Aus diesem Grund ist jede Beziehung zwischen einem Anbieter und seinem Kunden anders und eine anbieterübergreifende Zusammenarbeit – die für einen Kunden in vielen Fällen unerlässlich ist – kann nicht stattfinden.

Wir brauchen eine transparente Cloud!

Ein möglicher Ansatz wäre libcloud (http://libcloud.org). Dabei handelt es sich um eine Standard Bibliothek u.a. für Anbieter wie Amazon, Rackspace oder Slicehost, die eine einheitliche API bereitstellt. Sie ist in Python implementiert und kostenlos (Apache License 2.0) zu nutzen, um mit unterschiedlichen Cloud Anbietern zu kommunizieren.

libcloud

Allerdings ist die libcloud Bibliothek nur ein Ansatz. Wir müssen, wenn wir von Cloud Standards reden, uns auf eine noch wesentlich tieferer Ebene begeben. Was ich damit sagen will ist, dass ein Cloud Anbieter sich selber in die Pflicht nehmen muss und seine Schnittstellen so offen und sorgfältig zu dokumentieren, dass ein Wechsel oder eine Integration unterschiedlicher Services, Prozesse etc. zwischen verschiedenen Anbietern ohne weiteres möglich ist.

Ein Kunde muss mit einem guten Gefühl seine Daten, Prozesse etc. zu einem Cloud Anbieter auslagern, weil er sich sicher sein kann über diese frei zu verfügen und einen Wechsel sowie eine Integration sorgenfrei vornehmen zu können.

Categories
Grundlagen Services @de

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

Categories
Analysen

Sind die Amazon Web Services der Standard der Cloud?

Nach dem Artikel Amazon ist das Mass aller Dinge im Cloud Computing Markt! stellt sich ebenfalls die Frage, ob Amazon mit seinen Amazon Web Services (AWS) auch die Standards in der Cloud setzt.

Die Amazon Web Services sind der aktuelle und unangefochtene Marktführer aus dem Bereich der Infrastruktur as a Service (IaaS) Anbieter und decken soweit alle Segmente und Möglichkeiten des Cloud Computing ab. Durch die langjährige Erfahrung verfügt Amazon über einen signifikanten Vorsprung vor allen anderen Anbietern in diesem Segment. Die Expertise entstand dabei durch den Aufbau einer Privat Cloud, um die Ansprüche an die eigene Infrastruktur (Skalierbarkeit des Webshops, etc.) zu erfüllen, woraus dann die Public Cloud Angebote (Amazon Web Services) entstanden sind.

Zunächst können wir natürlich aus einer Vielzahl von “Standards” auswählen, da jeder Anbieter versucht, seine proprietäre Lösung als Standard am Markt zu positionieren. Daher kann nicht einfach davon ausgegangen werden, das die Amazon Web Services der Standard der Cloud sind. Zudem benötigt ein Standard einen gewissen Zeitraum, um sich als Standard zu etablieren.

Was sind also Anzeichen dafür, dass die Amazon Web Services bereits der Standard bzw. der kommende Standard des Cloud Computing sind?

Ein Blick auf die Angebote der Drittanbieter im Cloud Computing Markt verrät, AWS hat einen hohen Stellenwert. Vor allem Amazons Speicherdienst Amazon S3 ist dabei sehr beliebt. Mit JungleDisk, CloudBerry S3 Explorer, CloudBerry Backup oder Elephant Drive, stehen nur ein Paar Clients bereit, mit denen die Daten vom lokalen PC oder Server in die Amazon Cloud übertragen werden können. Zudem stehen mit S3 Curl, S3cmd oder S3 Sync weitere OpenSource Lösungen bereit, welche die Amazon S3 API zum Speichern von Daten nutzen.

Ein weiteres deutliches Indiz dafür, dass sich die Amazon Web Services als Cloud Computing Standard etablieren werden, ist das Angebot des deutschen Cloud Computing Anbieters ScaleUp Technologies, die mit ihrem eigenen Cloud Storage die Amazon S3 API vollständig adaptiert hat. Weiterhin stehen mit Eucalyptus bzw. der Ubuntu Enterprise Cloud “Klone” der Amazon Elastic Compute Cloud (EC2) zur Verfügung, mit denen eine Private Cloud nach dem Vorbild von EC2 aufgebaut werden kann. Auch hier existiert mit den Euca2ools bereits eine EC2 API Adaption.

Schaut man sich zudem die Liste der AWS Solution Provider an, erkennt man, wie wichtig die Bedeutung von AWS mittlerweile geworden ist.

Nicht alle AWS Angebote haben derzeit das Potential als Standard bezeichnet zu werden. Dazu zähle ich wie bereits oben erwähnt nur die Amazon Simple Storage Service (Amazon S3) sowie die Amazon Elastic Compute Cloud (Amazon EC2), wobei S3 dabei deutlich Populärer ist als EC2.

Wie man anhand der Angebote und Adaptionen erkennt, ist vor allem S3 weit verbreitet und anerkannt und es ist davon auszugehen, dass weitere Drittanbieter auf diesen Zug aufspringen werden. Zudem werden die meisten Anbieter davon absehen, dass Rad neu zu erfinden. Amazon war der erste Anbieter im IaaS Cloud Computing Markt und hatte dadurch ausreichend Zeit, seine proprietären Standards bekannt zu machen. Zudem haben es die restlichen großen Anbieter verpasst schnell nachzuziehen und eigene Angebote zu präsentieren. Sollten sie noch länger warten, wird die Zeit zu Gunsten von Amazon entscheiden.

Amazon S3 ist derzeit der Defacto Standard im Bereich Cloud Storage. Amazon EC2 wird voraussichtlich in Kürze nachziehen und sich etablieren. Wann und ob es die restlichen AWS Angebote ebenfalls zu Defacto Standards schaffen, bleibt abzuwarten.

Categories
Grundlagen Services @de

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

Categories
Services @de

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?
Categories
Management @de

Ein globale Studie zeigt, Cloud Computing ist real!

Eine unabhängige Studie des Cloud ICT zeigt, dass Cloud Computing in den Unternehmen angekommen ist. Die Kernfragen der Studie, in der mehr als 200 IT-Entscheider befragt wurden, kommen zu folgendem Ergebnis.

Setzt Ihr Unternehmen Cloud Computing ein?

  • Ja: 51%
  • Nein: 49%

Auf welche Art und Weise setzt Ihr Unternehmen Cloud Computing Technologien ein?

  • Kombination von Cloud und Traditionell: 60,58%
  • Experimentell: 24,93%
  • Ausschließlich Cloud Technologie: 13,19%
  • keine Angaben: 1,3%

War das durchgeführte Cloud Computing Projekt erfolgreich?

  • Ja: 96,18%
  • Nein: 3,82%

Warum Unternehmen derzeit kein Cloud Computing einsetzen.

  • Es ist zu früh die internen Systeme abzulösen: 37%
  • Cloud Computing wird als eine praktikable Technologie Option gesehen: 42%
  • Beabsichtigung, Cloud Computing in den nächsten 12 Monaten einzusetzen: 21%

Top Gründe, warum ein Wechsel in die Cloud nicht in Frage kommt:

  • Sicherheit
  • Integration
  • Zuverlässigkeit
  • Datenschutz
  • Kosten
  • Vendor Lock-In
  • Skalierbarkeit
  • Rechtlich und Ethisch

Top Cloud Computing Einsatzszenarien:

  • Unternehmensanwendungen
  • Infrastructure as a Service
  • IT Management
  • Productivity Anwendungen
  • Anwendungen zur Kollaboration
  • Entwicklung / Deployment

Erwarten Sie, dass die Adaption von Cloud Computing dazu führt, neue Lieferanten an Ihr Unternehmen anzubinden?

  • Ja: 61,9%
  • Nein: 14,5%
  • keine Angaben: 22,6%

Wird Cloud Computing eine zusätzliche Komplexität in die gesamte Verwaltung von IT-Ressourcen bringen?

  • Ja: 26,9%
  • Nein: 54,9%
  • keine Angaben: 16,7%

Sind Sie der Meinung, dass Cloud Computing zu einer kleineren IT-Abteilung führen könnte?

  • Ja: 55,9%
  • Nein: 25,7%
  • keine Angaben: 16,9%

Zusammenfassend zeigt die Studie, dass über 96% aller Befragten ihre Cloud Computing Projekte erfolgreich umsetzen konnten und 72% die derzeit keine Cloud Technologie einsetzen, dem aber sehr positiv gegenüber eingestellt sind. Dagegen sehen 60% der Befragten Datenschutz, Integration und die Zuverlässigkeit als die zu lösenden Probleme des Cloud Computing, wobei 85% den Punkt Sicherheit derzeit als den Hauptfaktor ansehen, nicht in die Cloud zu wechseln.

Categories
Tutorials @de

Virtuelle Maschinen für Amazon EC2 mit dem VMBuilder erstellen

Dieses Tutorial beschreibt wie ein offizielles Amazon EC2 Image mit dem VMBuilder deployed wird.

Installation

Installation auf Karmic Koala (9.10) und späteren Versionen

Für alle Ubuntu Versionen ab Karmic Koala (9.10) sind fertige Pakete vorhanden.

Continue reading “Virtuelle Maschinen für Amazon EC2 mit dem VMBuilder erstellen”
Categories
Services @de

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
Categories
News

Südafrikanische Tourismusbehörde informiert WM-Fans via Cloud Computing

Südafrikanische Tourismusbehörde bietet WM-Besuchern mit Salesforce.com mobilen Kundenservice in Echtzeit

300.000 WM-Fans erfahren exzellenten Service mit der Service Cloud 2, Google und Twitter

München – South African Tourism, offizieller Gastgeber der Fußball WM 2010 bietet den rund 300.000 WM-Besuchern aus aller Welt „sozialen Kundenservice“. Technologische Basis dafür ist die Service Cloud 2, die Cloud Computing-Anwendung für Kundenservice und -support von salesforce.com. Die Lösung unterstützt zahlreiche Sprachen wie Deutsch, Englisch, Französisch, Italienisch, Spanisch, Portugiesisch und Niederländisch.

Rund um das weltgrößte Sportereignis liefert die Service Cloud 2 ortsbezogene Echtzeit-Informationen zu Unterkünften, Attraktionen und Dienstleistungen. Auch mobil integriert die Lösung dabei klassischen Kundenservice mit Diensten wie Google und Twitter. Beispielsweise können die Besucher Fragen zu Restaurant-, Hotel- oder Veranstaltungsvorschlägen via Twitter an @gotosouthafrica senden. Lokale Tourismusexperten verfolgen und beantworten diese Anfragen über die Service Cloud 2.

Salesforce Ideas, ein interaktives Online Ideen-Forum bietet den Reisenden eine weitere Möglichkeit der Echtzeit-Interaktion. Mit Salesforce Ideas kann South African Tourism sofort auf auftretende Fragen und Probleme reagieren. Für die Nutzer besonders bequem ist die Integration von Salesforce Ideas mit einer iPhone Applikation, die auch mobil den Zugriff auf eine Vielzahl von Informationen ermöglicht.

Die Service Cloud 2 ersetzt die von South African Tourism bisher genutzte Eigenlösung. Diese auf Excel basierende Anwendung war der Größenordnung der Veranstaltung sowie den Bedürfnissen der Besucher nicht mehr gewachsen. Mit Enterprise Cloud Computing gelang es South African Tourism, sich binnen kürzester Zeit für die umfassenden Anforderungen, die Kunden heute an Service stellen, zu rüsten – ohne jegliche Kosten für Software, Hardware oder die Wartung von IT-Infrastruktur. Nach dem Ansturm durch die Weltmeisterschaft kann South African Tourism die Kapazitäten seines Kontaktcenters schnell und einfach wieder reduzieren und so an den üblichen Umfang seines Tagesgeschäftes anpassen.