Tag: Amazon

Categories
Services @de

Big Blues Kampf im Jungle – IBM gegen Amazon

Mit den “Smart Business Clouds” hat nun auch IBM seine Public Cloud Infrastruktur für Unternehmenskunden vollständig geöffnet und hat angekündigt im Laufe des Jahres ein weiteres Angebot mit einer deutlich höheren Verfügbarkeit zu veröffentlichen.

IBMs “Smart Business Clouds” (SmartCloud) bestehen aus den eigenen vorkonfigurierten x64-basierten CloudBurst Stacks und werden in einer Vielzahl von Cloud Rechenzentren überall auf der Welt betrieben. IBM unterscheidet seine SmartCloud in den Angeboten Enterprise und Enterprise+, die von den IBM’s Global Technology Services vertrieben werden.

Die bereits verfügbare “SmartCloud Enterprise” Infrastruktur umfasst ausschließlich x64-basierte Server und bietet ein Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,5%. Weiterhin unterstützt IBM auf seinen virtuellen Maschinen 32-bit und 64-bit Betriebssysteme wie Microsoft Windows 2003 und 2008, Red Hat Enterprise Linux 5.4 und 5.5 und Novell SUSE Linux Enterprise 11

Die “SmartCloud Enterprise+” Infrastruktur wird in der zweiten Jahreshälfte von 2011 erwartet. Kunden erhalten hier die Möglichkeit, x64 basierte oder Power Server zu kaufen, auf denen sie ihre Anwendungen betreiben können. Hier erhöht IBM zudem seine SLAs auf 99,9% Verfügbarkeit

Im Gegensatz zu seinem Angebot “Smart Business Development and Test on the IBM Cloud”, bei dem IBM als Hypervisor auf eine RedHat/ KVM Kombination setzt, nutzen die “SmartClouds” den VMware ESXi Hypervisor. Um auch Kunden zu bedienen, die auf andere Hypervisor setzen als den von VMware, wird IBM dazu übergehen müssen, ebenfalls KVM und Microsofts Hyper-V zu unterstützen. Auf den Power Servern in der “SmartCloud Enterprise+” setzt IBM auf seinen eigenen PowerVM Hypervisor und unterstützt hier die Betriebssysteme AIX Unix, Red Hat Enterprise Linux, sowie den SUSE Linux Enterprise Server.

Die Abrechnung der SmartClouds erfolgt pro VM pro Stunde. Zudem steht ein Softwarekatalog bereit, aus dem sich Kunden IBM spezifische Anwendungen wie Middleware, Groupware und Datenbanken, sowie Anwendungen von Drittanbietern wie die Cloud Management Software von Kaavo oder Plattformen zur Entwicklung von Webanwendungen wie von Aviarc, beziehen können.

Die Preise für die SmartClouds sind ebenfalls öffentlich. Vergleichbar mit Amazons EC2 rechnet IBM auch hier on-Demand ab und bietet seinen Kunden Optionen auf reservierte Kapazitäten. Das “SmartCloud Enterprise+” Angebot hingegen wird nicht stündlich on-Demand abgerechnet. Hier muss sich der Kunde entweder für eine monatliche Abrechnung oder einen festen Vertrag mit Laufzeit entscheiden. Jedoch stehen ihm hier weitere Managed Services, sowie mehrere Sicherheitsstufen zur Verfügung.

Wie ebenfalls von Amazon EC2 bekannt, kann ein Kunde auch bei den “SmartClouds” zwischen unterschiedlichen Konfigurationen von virtuellen Maschinen wählen. Je nach Leistungsstufe wird hier von Copper bis Platinum unterschieden.

Für eine 32-bit Konfiguration kann je nach Leistungsstufe zwischen 1 bis 4 virtuellen CPUs mit 1,25 GHz, zwischen 2GB bis 4GB virtuellen RAM und zwischen 60GB und 350GB virtuellen Instanzspeicher gewählt werden. Für einen Red Hat Enterprise Linux Server und einer Copper Konfiguration berechnet IBM 15.4 Dollar(cent) pro Stunde.

Für eine 64-bit Konfiguration kann je nach Leistungsstufe zwischen 2 bis 16 virtuellen CPUs mit 1,25 GHz, zwischen 4GB bis 16GB virtuellen RAM und zwischen 60GB und 2TB virtuellen Instanzspeicher gewählt werden.

Im Vergleich zu Amazon EC2 ist die IBM SmartCloud erheblich teurer, was aber daran liegt, das IBM mit seinem Angebot gezielt nur Unternehmen anspricht. So kostet die kleinste 32-bit Copper Instanz mit einem SUSE Enterprise Linux Server 11.0 0,095 Dollar pro Stunde und eine 64-bit Platinum Instanz mit einem Red Hat Linux Enterprise Server 5.4 und 5.5 1,84 Dollar pro Stunde. (Jeweils für nicht reservierte Kapazitäten.)

Das sich das Angebot an Unternehmen richtet, wird bei der Registrierung deutlich. Hier kann zwischen weiteren “Optional Premium Services” wie “On-boarding support” (Remote on-boarding support | Einmalig 3.000 Dollar), “Virtual Private Network service” (Network isolation of your instances through a virtual private network on the IBM Cloud | Einmalig 1.000 Dollar plus 300 Dollar monatlich) oder weiterem “Support” unterschieden in “Premium support” für 5% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 75$ pro Monat) und “Advanced Premium support” für 10% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 1000$ pro Monat), gewählt werden.

Die SmartCloud Enterprise Infrastruktur befindet sich in unterschiedlichen Cloud Rechenzentren überall auf der Welt. Kunden aus den USA beziehen die Services aus Raleigh in North Carolina und Boulder in Colorado. Kanadische Kunden werden aus Toronto in Ontario bedient. Für Europa, den mittleren Osten und Afrika werden die Services über ein Rechenzentrum aus Ehningen in Deutschland bereitgestellt, sowie für asiatische Kunden über ein Rechenzentrum in Singapur und Tokio.

Fazit

Für Unternehmenskunden sind die IBM “SmartCloud Enterprise Services” auf Grund ihrer umfangreichen Serviceleistungen ein attraktives wenn auch teures Angebot. Ob IBM damit tatsächlich den Kampf mit Amazon aufnehmen kann und möchte bleibt fraglich. Denn einen entscheidenen und attraktiven Vorteil hat Amazon gegenüber IBM. Die AWS Cloud ist ein echtes Public Cloud Angebot und ist für jedermann zugänglich. So haben auch Entwickler oder “normale Menschen” mit einer Idee die Möglichkeit die Services von Amazon zu nutzen. IBM hingegen richtet sich gezielt an Unternehmenskunden und hat nicht den Bedarf auf die Wünsche einfacher Benutzer einzugehen.

Aus eigener Sicht betrachtet, muss IBM sich darauf auch nicht einlassen, da die Dienstleistungen seit jeher Unternehmen adressierten. Spannend bleibt, ob und wie Amazon darauf reagiert. Wie bereits oben erwähnt, kann sich Amazon jedoch darauf berufen, die “Cloud für jedermann” zu sein. Vor allem Startups, Entwickler mit innovativen Ideen und Fachabteilungen die “nur mal etwas ausprobieren wollen”, werden weiterhin auf Grund des unkomplizierten Ressourcenbezugs und der einfachen und kostengünstigen Abrechnung auf die AWS Cloud zurückgreifen.

Categories
News

Amazon stellt Cloud DNS Dienst Amazon Route 53 vor

Bei Amazon Route 53 handelt es sich um einen hochverfügbaren und skalierbaren DNS (Domain Name System) Web Service. Route 53 verbindet Nutzeranfragen effektiver mit einer Infrastruktur die sich innerhalb der Amazon Web Services (AWS) befindet, wie bspw. einer Amazon Elastic Compute Cloud (Amazon EC2) Instanz, einem Amazon Elastic Load Balancer oder einem Amazon Simple Storage Service (Amazon S3) Bucket. Route 53 kann darüber hinaus ebenfalls dazu verwendet werden, um Nutzer zu einer Infrastruktur ausserhalb von AWS zu routen.

Route 53 löst DNS Anfragen mit einer geringen Latenz auf, indem ein globales Netzwerk von DNS Servern genutzt wird. Anfragen an eine Domain werden automatisch an den nächstgelegenen DNS Server weitergleitet und damit mit der best möglichen Performanz beantwortet. Route 53 stellt eine Web Service Schnittstelle bereit, über die Public DNS Einträge erstellt und verwaltet werden können und ist vollständig in alle bereits vorhandenen Amazon Web Services integriert. Zum Beispiel kann durch die Nutzung des AWS Identity and Access Management (IAM) in Kombination mit Route 53 bestimmt werden, wer Änderungen an den DNS Einträgen vornehmen kann.

Für die Nutzung von Route 53 müssen, wie bei alle anderen Amazon Web Services, keine langen Vertragslaufzeiten eingegangen oder Mindestumsätze generiert werden. Die Abrechnung erfolgt pro Domain, die mit dem Service verwaltet wird und pro Abfrage, die von Route 53 beantwortet wird.

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
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
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
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
Grundlagen Services @de

Der Amazon EC2 Instanzspeicher

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

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

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

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

Speicherort

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

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

Quelle

Categories
Grundlagen Services @de

Amazon Machine Images (AMI)

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

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

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

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

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

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

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

Quelle

Categories
Grundlagen Services @de

Der Amazon EC2 Workflow

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

  • 1. Zunächst wird ein AMI (Amazon Machine Image) von Grund auf neu, oder auf Basis eines bereits vorhandenen AMIs erstellt. Dieser Vorgang ist optional, da Instanzen aus bereits vorhandenen AMIs gestartet werden können, ohne diese vorab zu verändern.

  • 2. Für ein AMI das einen lokalen Instanzspeicher für sein Root Device verwendet, muss der Prozess zum bundlen und registrieren des AMIs erfolgen. Für ein AMI hingegen, dass ein Amazon EBS Volume verwendet, reicht es aus, den create Image Befehl auf einer bereits gestarteten Instanz auszuführen. Amazon EC2 gibt anschließend eine AMI ID zurück, wodurch auf Basis des AMI so viele Instanzen wie gewünscht gestartet werden können.

  • 3. Starten einer oder mehrerer Instanzen eines AMI.

  • 4. Verwalten und verwenden der Instanzen als wären es gewöhnliche Server.

Quelle