Kategorien
Management

Amazon erweitert EC2 mit automatischem Failover und liefert detaillierte Rechnungen

Amazon hat einen seiner größten „Schwachpunkte“ ausgebessert und kommt seinen Kunden damit weit entgegen. Es geht um die Ausfallsicherung einzelner EC2 Instanzen. Normalerweise muss sich ein Kunde selbst darum kümmern und dafür sorgen, dass eine neue EC2 Instanz hochfährt, wenn eine laufende ausfällt. Amazon hat nun seine Infrastruktur optimiert und führt das automatische Failover von EC2 Instanzen ein. Zudem gibt es nun detaillierte Informationen in den Rechnungen.

Automatischer Failover für Amazon EC2

Als Amazon Kunde hat man es nicht leicht, wenn man seine Infrastruktur in der AWS Cloud aufbauen will. Für die vom Public Cloud Computing versprochene Hochverfügbarkeit muss man als Kunde nämlich selbst sorgen, was viele Nutzer nicht umgesetzt haben.

Amazon kommt den Kunden nun ein Stück entgegen und erweitert seine Auto Scaling Funktion mit den Amazon EC2 Status Checks. Das bedeutet, wenn eine Instanz innerhalb einer Auto Scaling Gruppe nicht mehr verfügbar ist und den status check nicht besteht, wird diese Instanz automatisch durch eine neue Instanz ersetzt.

Wie Amazon schreibt, ist es nicht notwendig dafür selbst aktiv zu werden, da die EC2 Status Checks automatisch in die Auto Scaling Gruppen integriert wurden.

Mehr Details innerhalb der Rechnungen

Darüber hinaus geben neue Abrechnungen nun mehr Informationen über die stündliche Nutzung der Amazon Infrastruktur.

Kategorien
Kommentar

Cloud Computing: Offen oder Geschlossen? Vendor Lock-in ist kein Argument!

Cloud Computing spaltet sich derzeit in zwei Lager. Die Liebhaber eines geschlossenen, proprietären Systems und die Befürworter einer offenen (Open-Source) Cloud. Interessanterweise stellen verstärkt die Open-Source Jünger, allen voran das OpenStack Projekt die größten Lautsprecher dar (Rackspace: Linux der Cloud). Sei es auch nur, um mehr Aufmerksamkeit von den derzeit erfolgreichen geschlossenen Systemen (Amazon Web Services (AWS), Microsoft Windows Azure) auf sich zu lenken. Eines vorweg, pauschal lässt sich nicht sagen, welcher Ansatz der „Bessere“ ist. Es hängt immer von den eigenen Anforderungen und Möglichkeiten ab. Zudem sollte man schauen, wie geschlossen die proprietären Systeme wirklich sind. Man wird zum einen merken, dass viel mehr religiöse Ansichten dahinter stecken als man denkt und das die Argumentation Vendor Lock-in bei Open-Source Clouds nicht zwangsläufig zutrifft. Denn einen Vendor Lock-in hat man immer.

Geschlossene Cloud gleich Lock-in?

Hauptargumentation aus dem Open-Source Lager gegen proprietare Cloud Angebote ist das Risiko eines Lock-in. Um diesen zu umgehen, solle man stattdessen auf Angebote setzen, die auf Open-Source basieren, um sich über eine eigene Private Cloud die Freiheit zu verschaffen, also die Infrastruktur und Daten dann ggf. in die eigene Cloud zu transferieren.

Eines sollte man jedoch nicht vergessen, ohne Open-Source funktioniert derzeit so gut wie kein Cloud Angebot. So besteht die AWS Cloud aus wahrscheinlich der größten XEN (Hypervisor) Installation weltweit. Zudem wird argumentiert, dass mann sich bei AWS in einen Lock-in begibt. Bei der DynamoDB mag dies richtig sein. Aber für alle anderen Services gibt es Lösungen wie Eucalyptus, openQRM oder sogar OpenStack selbst, die entsprechende Schnittstellen bereitstellen. Und auch Microsoft ermöglicht es, zwischen Windows Azure und einer auf Microsoft basierenden Private Cloud mit dem Microsoft Server 2012 und dem System Center 2012 Daten usw. hin und her zu schieben. Man ist hier also auch nicht zwangsläufig auf die Public Cloud angewiesen.

Wo versteckt sich der Lock-in?

Ein Vendor Lockin besteht dann, wenn ein System, Angebot oder Lösung sehr stark abhängig macht.

Ein analoges Beispiel dafür ist Ikea. Das Design der Möbel ist so markant, dass es für einen Innenarchitekten Laien (wie mich) schwierig ist, es mit einem anderen Design zu kombinieren. Also geht man dazu über, weitere Möbel bei Ikea zukaufen. Zudem verfügt Ikea über eigene Maße und proprietäre Techniken z.B. bei den Waschbecken oder auch bei den Küchen, Schrauben und sonstigen Verbindungen.

Das Risiko des Lock-ins in der Cloud befindet sich hauptsächlich bei den Daten und Prozessen, wenn diese dort ebenfalls abgebildet werden. Denn in beiden Fällen befinden sich hier die geschäftskritischen Bereiche, die so beweglich wie möglich in der Cloud liegen sollten.

Die Ressourcen wie virtuelle Maschinen sind nicht, wie möglicherweise vermutet, von dem Lock-in betroffen. Hierzu existieren bereits diverse Import/ Export Tools z.B. von VMware für AWS oder speziell V2V (Virtual to Virtual) oder V2P (Virtual to Physical) Mechanismen von openQRM. Das bedeutet, das sich virtuelle Maschinen und deren Inhalte bequem hin und her schieben lassen.

Die Daten selbst sind in der Cloud in der Regel ebenfalls nicht von einem Lock-in betroffen. Die meisten Anbieter verfügen über entsprechende Schnittstellen, über die sich die Daten bewegen und transferieren lassen. Bei den Prozessen wird es schon schwieriger. Aber, wie viele Unternehmen haben in der Vergangenheit ihre Prozesse in die Hände von SAP Systemen gelegt und damit einen Lock-in verursacht?

Ein Lock-in ist nichts Schlechtes

Ein Lock-in, wenn er denn vorliegt, muss nicht immer etwas Schlechtes sein. Im Gegenteil, er führt zu Innovationen und verringert die Komplexität. Der Anbieter nimmt einem beim Design und der Auswahl Stückweit die Entscheidung ab und sorgt für eine stetige Weiterentwicklung und Verbesserung des Systems.

Zudem sollte man schauen, wer sich einen Lock-in nicht leisten kann. Kleine und mittelständische unternehmen, die ggf. über eine kleine oder keine IT-Abteilung verfügen, nehmen das gerne in Kauf, da sie sich die Implementation einer komplexen Umgebung nicht leisten können bzw. nicht über die Expertise verfügen. Analoges Beispiel, Ikea: Man bekommt relativ günstig gute Möbel und kann alles miteinander gut kombinieren.

Außerdem, schaut man sich Open-Source Projekte wie OpenStack an, wird deutlich, dass es nicht immer einfach ist, alle Interessen unter einen Hut zu bekommen. Open-Source mag zwar offen sein. Auf Grund der vielen beteiligten Unternehmen können so manche Konflikte den Innovationsgrad jedoch verringern. Aus diesem Grund kann ein Vorteil darin bestehen, wenn nur ein Unternehmen an der Spitze des Projekts/ Angebots steht und die Koordination übernimmt. Auch wenn mehrere Teilnehmer mehr Input und Expertise liefern. Hier haben auch geschlossene Anbieter einen Vorteil, da sie alleine verantwortlich sind, und damit schneller handeln. Das kann im Umkehrschluss bedeuten, dass der Lock-in von OpenStack in den potentiellen Konflikten und dem daraus folgenden langsamen Innovationsgrad besteht.

APIs sind entscheidend

Wichtig für jedes Cloud Computing Angebot sind die APIs. Auf diese muss sowohl von Innen als auch von Außen zugegriffen werden können, um auf dieser Basis die Daten in aus der Cloud zu transferieren.

Vorteile vs. Nachteile von Open-Source

Open-Source Cloud-Implementierungen gibt es erst seit ein paar Jahren und haben bis jetzt noch nicht ausreichend Anwendungsfälle im produktiven Betrieb. Obwohl eine Reihe von Early-Adoptern aus dem Telkosektor, Finanzdienstleister und wissenschaftliche Einrichtungen bereits Alternativen in Open-Source Cloud Systeme suchen, ist die Vielzahl an Unternehmen darüber nicht informiert. Es lohnt sich daher mal einen Blick auf die Vor- und Nachteile zu werfen.

Vorteil: Flexibilität

Per Definition bieten Open-Source Clouds ein höheres Maß an Flexibilität als der proprietäre Mitbewerb. Statt sich einfach nur mit dem Lesen von Anleitungen zufrieden zugeben oder an Schulungen teilzunehmen, können Nutzer selbst Änderungen an dem Code vornehmen und sich selbst mit eigenem Code an verschiedenen Projekten beteiligen. Zudem können sie eigene Projekte starten, eigene Dokus zur Verfügung stellen oder Seminare abhalten. Interaktionen mit der Gemeinschaft und der damit verbundenen Weiterbildung ermöglichen dem Anwender mehr Flexibilität bei der Gestaltung ihres Cloud-Designs und fördert innovative interne oder externe Lösungen.

Vorteil: Vendor Lock-In

Ein Argumente der Open-Source Cloud Community ist die Prävention vor einem Vendor Lock-in. Die Argumente sind einfach. Wird eine Cloud auf Basis einer offenen und weit verbreiteten Open-Source Technologien aufgebaut, hat kein Anbieter die Möglichkeit die volle Kontrolle über das Open-Source Framework zu erhalten. Damit können Anwender schneller auf die Entwicklung der Technologien im Rahmen des Open-Cloud Stacks reagieren. Darüber hinaus geben Open-Source Clouds dem Nutzer die Freiheit, seine Cloud an seine individuellen Bedürfnisse und Unternehmensziele anzupassen, statt diese anhand einer einzigen proprietäre Lösung aufzubauen.

Vorteil: Einsparung

Open-Source Software ermöglicht auf Grund seiner Lizenzierung die kostenlose Nutzung und hat damit preislich einen enormen Vorteil gegenüber dem kommerziellen Mitbewerb. Egal ob sich ein Nutzer nun für ein reines Open-Source Angebot oder für eine kommerzielle Open-Source Lösung entscheidet, wird er im Vergleich zu einer proprietären Software Kosten sparen können. In jedem Fall besteht für jedes Unternehmen die Möglichkeit, durch Open-Source Software, bei gleichzeitiger Erhöhung der Flexibilität, die Kosten zu senken, was einen Gewinn für jede Organisation darstellt.

Vorteil: Kontrolle, Offene Standards, APIs

Eine Open-Source Cloud setzt auf offene Standards und APIs und wird nicht von einem einzigen Hersteller kontrolliert. Das erlaubt es Unternehmen, die Kontrolle über die darunter liegende Hardware Infrastruktur und Managementplattform zu behalten, unabhängig davon, um welche Technologie es sich handelt. Des Weiteren ermöglichen offene APIs eine bessere Integration in bestehende offene oder proprietäre Lösungen, womit sichergestellt wird, dass aktuelle IT-Investitionen innerhalb der neuen Architektur weiterhin relevant sind.

Vorteil: Portabilität

Baut man seine Cloud auf Basis von Open-Source auf, sollte man immer schauen, wie es mit der Interoperabilität zu anderen Public, Private oder Hybrid Cloud Lösungen ausschaut. Entscheidet man sich für eine offene Technologie erhält man damit ein höheres Maß an Portabilität innerhalb des großen Cloud Ökosystems. Anstatt ihre eigenen Möglichkeiten auf proprietäre Technologien zu beschränken, können sich Nutzer an unterschiedlichen Open-Source Cloud Technologien bedienen und damit ihre IT-Entscheidungen unterstreichen und die eigenen Bedürfnisse und Unternehmensziele damit unterstützen.

Nachteil: Mangel an Unterstützung

Anwender die sich dafür entscheiden, ihre Cloud auf reiner Open-Source Software aufzubauen, begeben sich bzgl. Support in die Abhängigkeit des Open-Source Projekts. Das kann ganz schön zäh und schmerzhaft werden. Denn der Support kommt hier anhand von Foren, Chats, Q&A Systemen und Bug-Tracking Systemen von der Crowd. Zudem sollte man sich als Nutzer aktiv in der Community beteiligen und etwas dazu beitragen, was in der Welt der kommerziellen Software nicht notwendig ist. Auf der anderen Seite kann man sich für kommerzielle Open-Source Cloud Lösungen entscheiden, die für professionellen Support sorgen.

Nachteil: Kosten

Zwar haben Open-Source Lösungen auf Grund der in der Regel kostenlosen Lizenzen, im Vergleich zu kommerzieller Software, einen Kostenvorteil, allerdings gibt es auch hier Kosten die nicht zu vernachlässigen sind. Zum einen wird für den Aufbau einer Open-Source Cloud ein nicht zu unterschätzendes Wissen für die Entwicklung benötigt. Zum anderen müssen auch die Administratoren für einen einwandfreien Betrieb der Infrastruktur sorgen, wofür intensive Kenntnisse für die Verwaltung und Wartung der Lösung erforderlich sind. Darüber hinaus wird externes Fachwissen in Form von Beratung oder Entwicklung-Ressourcen benötigt.

Nachteil: Reifegrad

Je schneller sich das Open-Source Cloud Ökosystem entwickelt, kann sich ein Anwender nicht zwangsläufig darauf verlassen, das und wie lange ein Open-Source Projekt bestand hat. Wenn sich ein Cloud Architekt während des Designs einer Open-Source heute für eine bestimmte Technologie entscheidet, kann es durchaus passieren, das ihn diese in Zukunft einholen wird, da das Projekt eingestellt und nicht mehr weiterentwickelt wird. Mit den stetig steigenden Open-Source Projekten und unterschiedlichen Ansichten ist es für den Anwender zunehmend schwieriger geworden sich für den „richtigen“ Weg zu entscheiden.

Fazit

Verantwortliche die sich für eine Cloud Infrastruktur entscheiden, wollen diese hochverfügbar, einfach zu bedienen und so agil, dass sie sich mit den Bedürfnissen der Unternehmensziele verändert. Es ist daher entscheidend, dass sich ein Entscheider zunächst über die Unternehmensziele im klaren ist und sich mit seiner bestehenden IT-Infrastruktur auseinandersetzt, bevor er über eine Open-Source oder proprietären Cloud Infrastruktur nachdenkt. Möglicherweise kann man auch zu dem Ergebnis kommen, dass eine Open-Source Cloud für das Unternehmen keinen nennenswerten Vorteil bietet und eine proprietäre Cloud besser für den eigenen Innovationsgrad ist oder auch andere Möglichkeiten evaluiert werden müssen.

Kategorien
Analysen

Wer als IaaS-Anbieter zu Amazon konkurrenzfähig sein will muss mehr als nur Infrastruktur im Portfolio haben

Immer mehr Anbieter versuchen ihr Glück im Bereich Infrastructure-as-a-Service (IaaS) und wollen dem Platzhirsch Amazon Web Services (AWS) ein Stück vom Kuchen abnehmen. GigaOm hat bereits die Frage gestellt, ob es eine AWS Kopie aus Europa geben wird, die ähnlich wie Amazon in den USA den europäischen Markt dominieren wird. Sie kamen zu einem klaren Nein. Ich bin ebenfalls der Meinung, dass es in naher Zukunft keine nennenswerte Konkurrenz aus Europa geben wird. Ich gehe sogar einen Schritt weiter und gehe davon aus, dass es weltweit derzeit keinen Anbieter gibt und erst einmal geben wird, der – Stand heute – Amazon das Wasser reichen kann. Denn anders als es GigaOm macht, muss man den Cloud Markt global betrachten. Es gibt auf Grund der Strukturen grundsätzlich keine regional begrenzte Cloud. Jeder Nutzer kann sich weltweit bedienen. Es sei denn ein Anbieter entscheidet sich strikt dagegen. Das gibt es sogar – in Deutschland. Ich möchte Amazon an dieser Stelle keinen Freifahrtsschein ausstellen, aber für den Mitbewerb wird es sehr schwierig im IaaS Bereich diesen Marktanteil zu erreichen.

Der Markt ist groß genug aber…

Der IaaS Markt ist groß genug und bietet genug Platz für mehrere Infrastruktur-Anbieter. Jedoch sollte man sich vor Augen halten, wer sich derzeit für die Public Cloud und wer für die Private Cloud entscheidet. Danach lohnt sich ein Blick auf die Angebote der jeweiligen IaaS Anbieter, um die Spreu vom Weizen zu trennen. Dann wird auch klar, warum Amazon die Nase vorn hat und es für Neulinge schwer werden wird, wenn sie sich einfach nur auf reine Infrastruktur konzentrieren. So mancher Anbieter versucht gegen Amazon zum Beispiel mit einer höheren (Netzwerk)-Performance anzutreten. Das ist sicherlich ein netter Versuch, aber kein ausschlaggebendes Argument.

Public Cloud: Entwickler & Startups

Die Public Cloud wird bevorzugt von Entwicklern und Startups genutzt, die auf Basis des unkomplizierten Ressourcenbezugs und dem pay per use Modell ihre Geschäftsmodelle aufbauen. Mein Lieblingsbeispiel ist Pinterest, die nach eigener Aussage ohne Cloud Computing nicht so erfolgreich sein könnten. Das lag zum einem an der Möglichkeit stetig zu wachsen und die Ressourcen den Bedürfnissen nach zu erweitern ohne das Kapital für eine eigene riesige Serverfarm zu besitzen. Auf der anderen Seite hat die Cloud 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.

Private Cloud: Unternehmen

Viele etablierte Unternehmen stellen das Thema Datenschutz respektive Sicherheit über die hohen Investitionskosten und Wartungskosten einer Private Cloud. Hinzu kommt, dass ich in Gesprächen immer wieder höre, dass „eh bereits Investitionen in Hard-/ Software getätigt wurden“ und das nun noch ausgenutzt werden muss. Laut einer Gartner Umfrage planen 75% der Befragten bis 2014 eine Strategie in diesem Bereich. Bereits viele unterschiedliche Unternehmen haben Private Cloud Lösungen in Pilot-Projekten und im produktiven Betrieb im Einsatz. Dabei ist das Hauptziel, für sich den größten Nutzen aus der Virtualisierung zu ziehen.

Infrastruktur bedeutet mehr als nur Infrastruktur

Den Fehler den – vor allem – neue IaaS Anbieter machen ist, sich nur auf reine Infrastruktur zu konzentrieren. Das bedeutet, sie bieten nur die typischen Ressourcen wie Rechenleistung, Speicherplatz, Betriebssystem-Images, weitere Software und Lösungen wie Datenbanken an. Das mag vom IaaS Grundgedanken her auch alles richtig sein, reicht aber mittlerweile nicht mehr aus, um gegen Amazon zu bestehen.

Services, Services, Services

Schaut man sich das Angebot der Amazon Web Services genauer an, besteht es mittlerweile aus viel mehr als nur virtuellen Ressourcen, Rechenleistung und Speicherplatz. Es handelt sich dabei um ein umfangreiches Service-Portfolio, welches stetig und mit einem riesen Tempo ausgebaut wird. Alle Services sind ineinander vollständig integriert und bilden ein eigenes Ökosystem, mit dem ein eigenes Rechenzentrum aufgebaut und komplexe Anwendungen entwickelt und gehostet werden können.

Entwickler sind Amazons Jünger

Auf Grund dieses in sich stimmigen Angebots ist Amazon eine beliebte Anlaufstelle für Entwickler und Startups, die hier viele Möglichkeiten finden, ihre eigenen Ideen umzusetzen. Ich habe über diese Situation schon kritisch geschrieben und bleibe dabei, dass Amazon sich ebenfalls verstärkt auf die Bedürfnisse von Unternehmen konzentrierten sollte. Dennoch sind Entwickler derzeit Amazons Trumpf, welche den Cloud Anbieter zum führenden IaaS weltweit machen.

Komfort

Was AWS derzeit fehlt ist der Komfort. Hier setzen neue Anbieter an und bündeln mit „Infrastructure-as-a-Platform“ Lösungen verschiedene IaaS Ressourcen wie Rechenleistung, Speicherplatz, Netzwerkkomponenten usw. und ermöglichen Unternehmen damit den Aufbau eines eigenen Rechenzentrum on-Demand, also ein “Data-Centre-as-a-Service” (DCaaS). In diesem Bereich muss Amazon damit beginnen aufzuholen und ihren bestehenden und neuen Kunden mehr Convenience bieten, mit der diese die Infrastrukturen bequemer nutzen können und während der Konfiguration zudem weniger Zeit und Expertenwissen benötigen. Denn insbesondere IT-Abteilungen von kleinen- und mittelständischen Unternehmen werden in Zukunft auf diesen Komfort achten.

Schwer aber nicht unmöglich

Amazon gehört zu den Cloud Anbietern der ersten Generation und es gibt Bereiche in denen sie aufholen müssen. Aber das Konzept ist sehr ausgefeilt. Unter der Haube sind sie möglicherweise technologisch nicht mehr auf dem neuesten Stand. Aber die Frage ist, wie sehr es einen Kunden interessiert, ob nun Technologie A oder Technologie B in der „Blackbox“ eingesetzt wird, solange die Services zur Verfügung stehen, mit denen das verfolgte Ziel realisiert werden kann. Zudem lassen sich bestimmte Technologien auf Grund der losen Kopplung der Infrastruktur und der Services (Building Blocks) austauschen.

Wie ich oben geschrieben habe, ist der Markt groß genug und nicht alle Unternehmen werden zu Amazon gehen. Ich möchte nur darauf aufmerksam machen, dass es mittlerweile nicht mehr reicht, sich nur auf die grundlegenden IaaS-Eigenschaften zu konzentrieren, wenn man ein IaaS-Angebot gegen Amazon in den Ring schickt. Ich hatte vor längerer Zeit die Amazon Web Services der Google Cloud Platform (AWS vs. Google Cloud) bzw. Microsoft Windows Azure (AWS vs. Azure) gegenübergestellt. Beide sind für mich diejenigen Public IaaS Anbieter, die derzeit in der Lage sind, aufzuholen. Allerdings sieht man besonders an Googles Tabelle, dass an einigen Stellen noch so manche Service-Lücken bestehen.


Bildquelle: ©Stephanie Hofschlaeger / PIXELIO

Kategorien
Kommentar

Erneuter Ausfall der Amazon Web Services zeigt, dass Cloud Nutzer nicht aus den eigenen Fehlern lernen

Gestern war es dann wieder einmal soweit. Amazon hatte erneut mit einem schweren Ausfall in seiner Region US-East-1 zu kämpfen und zog direkt die üblichen Verdächtigen Reddit, Foursquare, Heroku und Co. mit. Dabei handelt es sich bereits um den fünften signifikanten Ausfall in den letzten 18 Monaten in dieser Region. Nach April 2011, März 2012 sowie dem 15. und 30. Juni 2012 plus vier weitere Ausfälle innerhalb nur einer Woche im Jahr 2010, nun der nächste Ausfall.

Die Hintergründe des AWS Ausfall

Die Region US-East-1 ist die älteste aller AWS Regionen. Dabei handelt es sich um das Rechenzentrum in Virginia, das erst vor kurzer Zeit wegen schwerer Gewitter in die Schlagzeilen geraten war. Letzte Woche hatte ich noch geschrieben, dass neue Public Cloud Anbieter zwar mittlerweile über aktuellere Technologien verfügen, es für Amazon auf Grund der losen Kopplung sämtlicher Services aber leicht fallen sollte, einen Austausch vorzunehmen. Es scheint, dass der Zeitpunkt mehr als überschritten ist. Das Grab US-East-1 ist größer als vermutet.

Was ist passiert?

Was genau passiert ist, kann der AWS Statusseite zu Beginn verständlicherweise nicht immer direkt entnommen werden. In der Regel wird ein paar Tage nach dem Ausfall ein ausführlicher Blogpost mit ein paar Details veröffentlicht.

Aus den Statusmeldungen lässt sich nur entnehmen, dass es wieder Performanceprobleme „mit einer kleinen Anzahl von EBS Volumes (Elastic Block Store)“ gibt.

10:38 AM PDT We are currently investigating degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region.
11:11 AM PDT We can confirm degraded performance for a small number of EBS volumes in a single Availability Zone in the US-EAST-1 Region. Instances using affected EBS volumes will also experience degraded performance.
11:26 AM PDT We are currently experiencing degraded performance for EBS volumes in a single Availability Zone in the US-EAST-1 Region. New launches for EBS backed instances are failing and instances using affected EBS volumes will experience degraded performance.

12:32 PM PDT We are working on recovering the impacted EBS volumes in a single Availability Zone in the US-EAST-1 Region.
1:02 PM PDT We continue to work to resolve the issue affecting EBS volumes in a single availability zone in the US-EAST-1 region. The AWS Management Console for EC2 indicates which availability zone is impaired.EC2 instances and EBS volumes outside of this availability zone are operating normally. Customers can launch replacement instances in the unaffected availability zones but may experience elevated launch latencies or receive ResourceLimitExceeded errors on their API calls, which are being issued to manage load on the system during recovery. Customers receiving this error can retry failed requests.

2:20 PM PDT We’ve now restored performance for about half of the volumes that experienced issues. Instances that were attached to these recovered volumes are recovering. We’re continuing to work on restoring availability and performance for the volumes that are still degraded.

Zudem waren auch „eine kleine Anzahl von RDS Instanzen (Relational Database Service)“ betroffen. Hier kam es zu Problemen bei der Verbindung und ebenfalls bei der Performance.

11:03 AM PDT We are currently experiencing connectivity issues and degraded performance for a small number of RDS DB Instances in a single Availability Zone in the US-EAST-1 Region.
11:45 AM PDT A number of Amazon RDS DB Instances in a single Availability Zone in the US-EAST-1 Region are experiencing connectivity issues or degraded performance. New instance create requests in the affected Availability Zone are experiencing elevated latencies. We are investigating the root cause.

Die üblichen Verdächtigen: Reddit, Foursquare, Heroku und Co.

Interessant ist, dass immer die üblichen Verdächtigen u.a. Reddit, Heroku und Foursquare von einem Ausfall der US-East-1 Region betroffen sind. Das bedeutet im Umkehrschluss, dass alle Beteiligten nicht aus den eigenen Fehlern vorheriger Ausfälle gelernt haben und genau so weitermachen wie zuvor. Das „Schöne“ an solchen Ausfällen ist, dass man einen schönen öffentlichen Rundumblick auf die Robustheit der jeweiligen Angebote der Anbieter erhält, die ihre Anwendungen auf den Amazon Web Services laufen lassen. Auch Instagram, dass bekannterweise für 1 Milliarde Dollar an Facebook verkaufte wurde, war bei einem der letzten Ausfälle schwer getroffen. Da scheint die technische Due Diligence Prüfung nicht funktioniert zu haben.

Es stellt sich die Frage, wie lange die Verantwortlichen von Reddit, Foursquare, Heroku (gehört übrigens zu Salesforce) und Co. noch warten, bis etwas an der Architektur geändert wird. Die Systemarchitekten sollten langsam damit beginnen etwas zu ändern. Gute Vorbilder sind Netflix und Okta.

Was ist zu tun?

Das ist im Einzelfall zu entscheiden. Jedoch reicht es zunächst einmal nicht aus, nur eine Region oder eine Availability Zone zu nutzen. Man muss einfach verstehen, dass Cloud Computing viel mehr bedeutet, als nur ein paar Server zu nutzen und miteinander zu verbinden. Es geht um die gesamte Architektur des eigenen Systems bzw. der eigenen Anwendung, die auf der virtuellen Infrastruktur (IaaS) aufgebaut wird. Wie ich schon in einem Artikel für die Computerwoche geschrieben habe:

Viele Unternehmen entwickeln ihre Cloud-Applikation „daheim“ in den eigenen vier Wänden. Erst nach der Fertigstellung soll der Rollout auf eine Cloud-Infrastruktur oder Cloud-Plattform erfolgen. Das ist ein Fehler.

Inbesondere IaaS-Umgebungen (Infrastructur as a Service) wie die Amazon Web Services oder Microsoft Windows Azure vermitteln den Eindruck, nur eine Vielzahl von virtuellen Maschine bereitzustellen. Den Rest übernehme die „Cloud automatisch“. Das ist fatalerweise auch der Tenor, der von vielen Medien verbreitet wird und damit ein völlig falscher Eindruck von einer Cloud entsteht.

Eine Cloud-Anwendung ist nur so viel wert wie die Architektur, auf der sie basiert. Eine Anwendung muss direkt für die Cloudentwickelt werden – Skalierbarkeit und Hochverfügbarkeit sind von Beginn an mit zu bedenken. Eine Anwendung sollte eigenständig weitere virtuelle Maschinen hochfahren können, wenn mehr Leistung benötigt wird (Skalierbarkeit) bzw. die nicht mehr benötigten virtuellen Maschinen auch selbstständig wieder herunterfahren. Genauso verhält es sich, wenn eine virtuelle Maschine in einen fehlerhaften Zustand gerät. Auch hier muss die Anwendung selbst dafür sorgen, dass entsprechend eine virtuelle Maschine als Ersatz hochgefahren wird und die defekte Maschine aus dem System verschwindet (Hochverfügbarkeit).

Die Anwendung muss daher in der Lage sein, auf jeder beliebigen virtuellen Maschine (VM) einer Cloud-Infrastruktur zu funktionieren. Das liegt unter anderem daran, dass jederzeit eine VM ausfallen kann und eine andere neu hochgefahren werden muss. Und auch die Daten, auf die eine Anwendung operiert, befinden sich zwangsläufig nicht mehr an einem einzigen Ort, sondern sind über die Cloud verteilt gespeichert.

Mehr…

Für den Fehlerfall vorbereitet sein

Selbstverständlich darf man Amazon von diesem erneuten Ausfall auf keinen Fall freisprechen. Die Region US-EAST-1 in North Virginia scheint das Problemkind zu sein. Dennoch weißt Amazon regelmäßig und vehement darauf hin: „Design for failure!“

Hierfür hat das Unternehmen eine Webseite geschaffen, auf der Whitepapers zum Download bereitstehen, die dabei helfen, fehlertolerante Anwendungen zu entwickeln und Cloud Architekturen zu verstehen. Dazu gehören u.a. die Folgenden.

AWS Cloud Architecture Best Practices Whitepaper

Dieses Whitepaper gibt einen technischen Überblick aller AWS Services und verschiedener Best Practice Ansätze für die architektonische Gestaltung, um damit effiziente und skalierbare Architekturen zu entwerfen.
Link

Building Fault-Tolerant Applications on AWS Whitepaper

In diesem Whitepaper werden Funktionen für die Erhöhung der Fehlertoleranz vorgestellt, die dazu dienen, um hoch zuverlässige und hochverfügbare Anwendungen innerhalb der AWS Cloud zu entwickeln.
Link

Web Hosting Best Practices Whitepaper

Dieses Whitepaper überprüft detailliert Lösungen für das Web Application Hosting. Dazu gehört unter anderem, wie jeder AWS Service genutzt werden kann, um eine hochverfügbare und skalierbare Webanwendung zu entwerfen.
Link

Leveraging Different Storage Options in the AWS Cloud Whitepaper

Dieses Whitepaper dient dazu, einen Überblick über die Speichermöglichkeiten in der AWS Cloud zu geben und darüber hinaus Szenarien vorzustellen, um eine effektive Nutzung zu erzielen.
Link

AWS Security Best Practices Whitepaper

In diesem Whitepaper werden bestimmte Tools, Funktionen und Richtlinien beschrieben, um zu verstehen, wie Cloud Anwendungen innerhalb der AWS Infrastruktur von Grund auf geschützt werden können.
Link

Netflix und sein Chaos Monkey

Ein Grund warum Netflix ein so robustes und hochverfügbares System auf der Amazon Cloud betreibt, ist der selbst entwickelte und sogenannte Chaos Monkey. Der Chaos Monkey hilft Netflix dabei sicherzustellen, dass alle einzelnen Komponenten unabhängig voneinander arbeiten. Dazu zerstört der Chaos Monkey wahllos Instanzen und Services innerhalb der Netflix AWS Infrastruktur, um seinen Entwicklern dabei zu helfen, zu gewährleisten, dass jede einzelne Komponente antwortet, auch wenn die System-Abhängigkeiten nicht einwandfrei funktionieren.

Das gilt für die gesamte Cloud!

Alle genannten Bereiche gelten nicht nur für die Amazon Web Services, sondern ebenfalls für Windows Azure, Rackspace usw. Bevor man in die IaaS-Cloud eines Anbieter geht, sollte man sich vorher damit auseinandersetzen und verstehen, wie die Infrastruktur funktioniert und wie das eigene Systeme daraufhin entwickelt werden muss.

Kategorien
Kommentar

Schuldzuweisungen in Zeiten des Cloud Computing

Gestern ist mir wieder ein Tweet über den Weg gelaufen, der nicht nachvollziehbar ist. Der Bilderservice Mobypicture twittert „Mobypicture is currently unavailable because of system maintenance by Amazon….“. Währenddessen waren auf dem Statusboard der Amazon Web Services unter http://status.aws.amazon.com keine Auffälligkeiten erkennbar. Der Mobypicture Service hingegen war nicht erreichbar. Ich werde hier Amazon nicht verteidigen. Aber die Schuld per Tweet einfach auf den Anbieter zu schieben, scheint mir dann doch zu einfach. Es scheint eher so, dass Mobypicture die Möglichkeiten der AWS Cloud nicht kennt bzw. diese nicht nutzt – wie schon Instagram.

Wer ist denn „schuld“ in der Cloud?

Das kommt darauf an. Nämlich unter anderem davon, was von der Cloud Infrastruktur bzw. dem Cloud Service ausfällt. Bei SaaS als auch PaaS sind mir als Nutzer weitestgehend die Hände gebunden. Beim IaaS halte jedoch ich größtenteils die Fäden selbst in der Hand und muss dafür sorgen, dass meine Applikation auf der Infrastruktur einwandfrei arbeitet. Selbst dann, wenn die darunterliegende Infrastruktur Stückweit ausfällt. Dafür gibt es Mittel und Wege. Wenn ich alles daheim im eigenen Rechenzentrum mache, sorge ich schließlich auch für Redundanz und kann maximal mit dem Finger auf bspw. die kaputte Festplatte zeigen. In der Cloud stehen mir aber deutlich mehr Möglichkeiten zur Verfügung. Extrem(!) gesagt dürfte eine eigene Applikation erst dann ausfallen, wenn die gesamte IaaS-Cloud eines Anbieters ausfällt.

Mehr Eigenverantwortung bitte!

Es ist nicht das erste Mal, dass ich das schreibe. „Beim Cloud Computing geht es um Selbstverantwortung.

Mehr Eigenverantwortung und IaaS bedeutet, darauf zu achten die Möglichkeiten der verteilten Cloud Infrastruktur zu nutzen und die Architektur der Applikation genau diesen Begebenheiten anzupassen und diese dafür zu entwickeln. Stichworte: Parallelität, Skalierbarkeit usw.

Im Falle der Amazon Web Services bedeutet dies:

  • Nicht nur eine virtuelle Maschine einsetzen.
  • Sich nicht nur auf eine Availability Zone verlassen.
  • Nicht nur eine Region nutzen.
  • Eine Multivendor Strategie in Betracht ziehen.

Dann sieht es schon anders aus.


Bildquelle: http://www.akademische.de

Kategorien
News

Amazon baut Marktplatz für seine EC2 Reserved Instances

Amazon hat vorgestern seinen Reserved Instance Marketplace vorgestellt. Dabei handelt es sich um einen Marktplatz, auf dem AWS Kunden ihre EC2 Reserved Instances an andere Unternehmen verkaufen oder Instances anderer Kunden kaufen können.

Amazon baut Marktplatz für seine EC2 Reserved Instances

Flexibilisierung von Reserved Instances

Reserved Instances erlauben es AWS Kunden, sich für einen geringen einmaligen Betrag reservierte Rechenleistungen zu kaufen, die ihnen garantiert zur Verfügung stehen, wenn sie diese benötigen.

Mit dem Reserved Instances Marketplace ermöglicht es AWS seinen Kunden nun diese reservierten Instanzen wieder zu verkaufen, wenn z.B. die AWS Region gewechselt werden soll, sich der Instanztyp ändern muss oder Kapazitäten verkauft werden sollen bei denen noch Laufzeit besteht.

Darüber hinaus lassen sich über den Marktplatz nun auch Reserved Instances einkaufen, die nicht an die bekannten Laufzeiten von einem oder gar drei Jahren gebunden sind. Damit lassen sich auch Projekte mit einer garantierten Rechenleistung von bspw. sechs Monaten absichern.

Der Marktplatz und weitere Informationen befinden sich unter http://aws.amazon.com/de/ec2/reserved-instances/marketplace

Kategorien
News

FastGlacier: Der erste Windows Client für Amazon Glacier

Es ist nicht einmal eine Woche her, dass die Amazon Web Services ihren Tape-Library Killer bzw. Service für das Langzeit-Backup Amazon Glacier präsentiert haben. Nun steht der erste Windows Client – FastGlacier – von NetSDK Software zum Download bereit. Da Amazon sich i.d.R. nicht um eigene GUI Clients für seine Services kümmert, zeigt dies, dass das Ökosystem um die Amazon Web Services herum gut funktioniert.

FastGlacier: Der erste Windows Client für Amazon Glacier

FastGlacier – Windows Client für Amazon Glacier

FastGlacier ist ein kostenloser Windows Client für Amazon Glacier, mit dem Daten von einem Windows basierten System auf den Speicher von Amazon Glacier hoch- und heruntergeladen sowie verwaltet werden können. Die Software unterstützt das parallele Hochladen von Dateien inkl. Pause und Resume Funktion. Darüber hinaus können mehrere Amazon Glacier Accounts genutzt werden. Mit FastGlacier lassen sich Dateien mit einer Größe von bis zu 40TB verwalten, die ebenfalls via Drag and Drop mit dem Windows Explorer hin- und hergeschoben werden können.

Für die private Nutzung ist FastGlacier kostenlos. Wer die Software im Unternehmen, Regierungsbereich oder anderweitig kommerziell einsetzen möchte, zahlt pro Lizenz 29,95 US-Dollar. Wobei es bereits ab der zweiten Lizenz Ermäßigungen gibt.

Amazon Glacier

AWS beschreibt Amazon Glacier als einen kostengünstigen Storage Service, der dafür entwickelt wurde, um Daten dauerhaft zu speichern. Zum Beispiel für die Datenarchivierung bzw, die Datensicherung. Der Speicher ist, entsprechend der aktuellen Marktsituation, sehr günstig. Kleine Datenmengen können ab 0,01 US-Dollar pro GB pro Monat gesichert werden. Um den Speicher so kostengünstig anzubieten, ist der Service, im Vergleich zu Amazon S3, für solche Daten gedacht, auf die selten zugegriffen wird und deren Zugriffszeit mehrere Stunden betragen darf. Dateien, die per Glacier gesichert werden, sollen laut Amazon eine Langlebigkeit von 99,999999999 Prozent aufweisen. Bei einer Speichermenge von 100 Milliarden Objekten entspricht das den Verlust von einem Objekt pro Jahr.

Weitere Lösungen von NetSDK Software

Neben FastGlacier bietet NetSDK Software mit TntDrive bereits eine Lösung für das Mapping von Amazon S3 Buckets als Windows Laufwerk und mit dem S3 Browser einen kostenlosen Windows Client (Browser) für Amazon S3.

Kategorien
News

Die Amazon Web Services erweitern Amazon RDS um weitere Funktionen für Oracle Datenbanken

Die Amazon Web Services haben vier neue Funktionen für Amazon RDS for Oracle präsentiert. Darunter die Möglichkeit, die Datenbank in einer Private Cloud zu betreiben. Dazu können Unternehmen nun RDS (Relational Database Service) Instanzen mit einer Oracle Datenbank innerhalb einer VPC (Virtual Private Cloud) nutzen. Administratoren erhalten, im Vergleich zu einer Standard Instanz oder einer virtuellen Maschine, damit mehr Kontrolle.

Die Amazon Web Services erweiterten Amazon RDS um weitere Funktionen für Oracle Datenbanken

Erweiterter Oracle Support

Weitere neue Funktionen sind die Unterstüzung für Oracle APEX (Application Express), XML DB und Time Zone. Mit Time Zone können Administratoren Informationen zu Timestamps persistent speichern, wenn Benutzer die Amazon Web Services über mehrere Zeitzonen hinweg verteilt einsetzen.

Bei APEX handelt es sich um eine freies Web-basiertes Entwicklungstool für Oracle Datenbanken. Mit dem Tool sollen ebenfalls Entwickler mit geringen Programmierkenntnissen Anwendungen entwickeln und ausrollen können. Das Entwicklungs-Framework für APEX bietet Wizards und Eigenschaftsfenster für die jeweiligen Objekte, mit denen Anwendungen geschrieben und gewartet werden sollen. Amazon RDS unterstützt die APEX Version 4.1.1.

XML DB ist eine Funktion von Oracle Datenbanken und bietet native XML Speicher- und Abfrage-Möglichkeiten.

Amazon RDS for Oracle

Mit Amazon RDS lassen sich Oracle Database 11g auf der Amazon Cloud bereitstellen. Der Service bietet Datenbank-Administrationsaufgaben wie das Provisioning, Backups, Software-Patches, Monitoring und Hardware-Skalierung.

Unternehmen können entweder ihre eigenen Datenbanken-Lizenzen nutzen oder lassen Amazon sich um die Lizenzierung kümmern. Die Preise betragen dann 0,11 Dollar pro Stunde bzw. 0,16 Dollar pro Stunde.

Erst kürzlich hatte Amazon eine Reihe von Verbesserungen für seinen Cloud-basierten Datenbank-Service Dynamo vorgestellt. Darunter die Aktualisierung der DynamoDB Management-Konsole.

Kategorien
News

Fehlerhafte Netzwerkkonfiguration war Schuld am Windows Azure Ausfall für die Region "West Europe"

Grund für den ca. 2,5-stündigen Ausfall von Microsoft Cloud Service Windows Azure Compute am vergangenen Donnerstag (26.07.12) war offenbar eine fehlerhafte Netzwerkkonfiguration. Das schreibt Windows Azure General Manager Mike Neil in einem Blogbeitrag.

Fehlerhafte Netzwerkkonfiguration war Schuld an Windows Azure Ausfall für die Region

Fehlerhaft konfiguriertes Netzwerk-Device

Wie Neil schreibt, war nur Azure Compute in der Region „West Europe“ von dem Ausfall betroffen. Das Problem sei auf ein falsch konfiguriertes Netzwerk-Device zurückzuführen, was dafür gesorgt hat, dass der Datenverkehr nicht mehr zu einem zuständigen Cluster in dieser Region übertragen wurde. Als die Grenze für ausgehende Verbindungen erreicht wurde, führte dies zu weiteren Problemen in einem anderen Netzwerk-Device innerhalb dieses Clusters, was das Netzwerkmanagement und die Wiederherstellung erschwerte.

Microsoft will in der kommenden Woche weitere detaillierte Informationen zu dem Ausfall veröffentlichen.

Microsoft holt gegenüber Amazon auf – Salesforce spielt auch mit

Es handelt sich bereits um den zweiten schweren Ausfall von Windows Azure in den letzten Monaten. Erst am 29. Februar 2012 wurde die Microsoft Azure Cloud Opfer des diesjährigen Schaltjahres und war damit für 12 Stunden nicht erreichbar.

Ausfall-Könige bleiben in diesem Jahr jedoch (noch) die Amazon Web Services, die das negative Duell mit einem Vorsprung von einem Ausfall anführen. Zwischenstand 3 (AWS) zu 2 (Microsoft). Aber auch Salesforce spielt langsam in der Liga mit und bietet bereits zwei Ausfälle.

Kategorien
News

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“.