Kategorien
Analysis

Amazon Web Services vs. Microsoft Windows Azure – A direct comparison

Many companies are currently in the evaluation of public cloud services such as IaaS. The first thoughts brush the two large and supposedly known providers in the scene – Amazon Web Services and Microsoft Windows Azure. Both have an extensive and growing range of cloud services today. But, if you want to compare both portfolios the challenges increase with the number of services.

Amazon Cloud vs. Windows Azure

The following table shows the cloud service portfolio towards 1:1 and provides clarity. Who provides what in which area, what is the name of the respective service and under what URL to find more information about it.

Feature

Amazon Web Services

Microsoft Windows Azure

Computing power

Virtual machines Elastic Compute Cloud Role Instances
High Performance Computing Cluster Compute Instances HPC Scheduler
MapReduce Elastic Map Reduce Hadoop on Azure
Dynamic scaling Auto Scaling Auto Scaling Application Block

Storage

Unstructured storage Simple Storage Service Azure Blob
Flexible entities SimpleDB Azure Tables
Block Level Storage Elastic Block Store Azure Drive
Archiving Amazon Glacier
Storage Gateway AWS Storage Gateway

Databases

RDBMS Relational Database Service SQL Azure
NoSQL DynamoDB Azure Tables

Caching

CDN CloudFront CDN
In-Memory ElastiCache Cache

Network

Load Balancer Elastic Load Balancer Fabric Controller / Traffic Manager
Hybrid Cloud Virtual Private Cloud Azure Connect
Peering Direct Connect
DNS Route 53

Messaging & Applications

Async Messaging Simple Queue Service Azure Queues
Push Notifications Simple Notification Service Service Bus
Bulk Email Simple Email Service
Workflows Amazon Simple Workflow Service
Search Amazon CloudSearch

Monitoring

Resource monitoring CloudWatch System Center

Securiry

Identity Management Identity Access Management Azure Active Directory

Deployment

Resource creation CloudFormation
Web Application Container Elastic Beanstalk Web Role
Kategorien
Kommentar

Mehrwert-Services sind die Zukunft von Infrastructure-as-a-Service

Der Titel dieses Beitrags mag ein wenig irritieren. Schließlich handelt es sich bei Infrastructure-as-a-Service (IaaS) bereits um Services. Aber ich habe meinen Grund dafür. Von Beginn an bezeichnet Gartner die Amazon Web Services, in seinem Magic Quadrant, als den führenden Anbieter im IaaS Markt. Wen ich hier mittlerweile jedoch vermisse ist Windows Azure. Aber warum ist es gerade Amazon, die den Markt anführen und warum gehört Windows Azure meiner Meinung nach ebenfalls in denselben Quadranten wie Amazon.

Frühe Präsenz und ein ausgeprägtes Angebot zahlen sich aus

Ein Grund für Amazons Erfolg liegt unumstritten in der frühen Präsenz am Markt. Als erster IaaS Anbieter (2006) haben sie den Markt geprägt und dem Cloud Computing damit die Richtung vorgegeben, an der sich viele Anbieter orientieren. Microsoft folgte mit Windows Azure zwar relativ spät (2010), hat sein Portfolio aber schnell ausgebaut.

Ein weiterer aber viel prägnanter Grund sind die Services beider Anbieter. Wie bei den anderen IaaS Anbietern am Markt, stehen bei Amazon AWS und Microsoft Windows Azure nicht nur die reine Infrastruktur im Vordergrund, sondern viel mehr Lösungen drum herum. Das Angebot beider Anbieter ist im Vergleich zum restlichen Markt sehr ausgeprägt und bietet deutlich mehr als nur virtuelle Server und Speicherplatz. Und das ist der Knackpunkt.

Die Infrastruktur nutzbar machen

IaaS bedeutet im Kern das Angebot von Rechenleistung, Speicherplatz und Netzwerkkapazitäten als Service im Pay as you go Modell. Das beherzigen die meisten Cloud Anbieter am Markt. Nur nicht Amazon AWS und Windows Azure. Beide bieten viele Mehrwert-Services um ihre Infrastruktur herum an und machen diese damit nutzbar. Kunden sind damit in der Lage die „dumme“ Infrastruktur direkt produktiv zu nutzen.

Egal welchen Anbieter man sich aus dem Public Cloud Bereich zur Brust nimmt, in der Regel besteht das Angebot aus Compute (Rechenleistung), Storage (Speicherplatz) und Database (Datenbanken). Der eine oder andere bietet zudem noch ein CDN (Content Delivery Network) und Tools für das Monitoring. Das war es dann aber auch schon. Hingegen zeigt ein Blick auf die Services von Amazon AWS und Windows Azure, wie umfangreich deren Portfolio mittlerweile ist.

Daher, Mehrwert-Services sind der Schlüssel und die Zukunft von Infrastructure-as-a-Service, mit denen sich die Infrastruktur gewinnbringender nutzen lässt.

Kategorien
Analysis

Amazon acquires Eucalyptus cloud – It's merely a matter of time

In the public cloud Amazon Web Services (AWS) is currently the undisputed leader. Regarding private or hybrid cloud solutions providers such as Microsoft and HP are in a better position. AWS itself has currently no own offering in this area. Instead, an exclusive partnership with Eucalyptus Systems was received in March 2012. Eucalyptus is some kind of an image of the basic AWS functions. This strategic decision is understandable and will have consequences for the future.

The cooperation between AWS and Eucalyptus

In March 2012, AWS and Eucalyptus Systems, a provider of a private cloud infrastructure software that can be used to build up the basic functions of the Amazon cloud in the own data center, have decided to work together in closer. This cooperation was strengthened by Eucalyptus CEO Marten Mickos and has the background to support the better migration of data between the Amazon Cloud and an Eucalyptus private cloud. Furthermore, and even more important is that the customer should be able to use the same management tools and their knowledge for both platforms. In addition, the Amazon Web Services will provide Eucalyptus with further information to improve the compatibility with the AWS APIs.

The competition is catching up

Although it is currently very rosy in the public cloud, the future lies in the hybrid cloud. In addition, many companies are flirting with their own private cloud rather than changing into the public cloud. This means that the private respectively the hybrid cloud gain increasingly important. Here the Amazon Web Services, except for the virtual private cloud, offer nothing. Microsoft and HP already have a very balanced portfolio that offers solutions and services both for the public and for the private cloud. Furthermore, both have a large customer base.

Also, another point is clear. Where Microsoft and HP focus on the big enterprises, Amazon Web Services are presently the Mecca for startups. The success speaks for itself. However, if we look at Amazon’s efforts in recent months, the target direction is clear. AWS needs and wants in the enterprise. But that’s only possible with a private / hybrid cloud strategy. Therefore Amazon will arrive at some point where it is actively looking to conquer these markets aggressively, too.

Amazon is a service provider

AWS did not make any acquisitions in the cloud space so far, because they easily do not have to. As an innovation leader, they set the standards in the public cloud. In the private / hybrid cloud, it looks different. Here, in my point of view, there is almost no expertise. Even if Amazon operates its own data centers, the operation of a quasi-standard solution for enterprise is different. Here, Microsoft and HP have years of experience, and thus a clear advantage. The Amazon Web Services are a typical service provider. This means they deliver their services from the cloud, which will simply be consumed only. Cloud software for the mass market is not developed. Providing, delivering, maintaining and rolling out updates and new releases as well as appease the customers the experience is missing. Therefore, the cooperation with Eucalyptus has been the first right step. What is not part of the core business will be outsourced. Just as Amazon market cloud computing, they seem to live it themselves.

However, Amazon will want to have more influence on the private and hybrid cloud, and also want to enjoy a piece of this cake. Therefore, the next logical step will be to acquire Eucalyptus Systems. On the one hand it is about more impact on Eucalyptus. Because even though Marten Mickos has promoted the cooperation with AWS, he will not bow to anything that Amazon requires. On the other hand, the hybrid cloud integration needs to be strengthened. In addition, qualified staff is needed for private cloud consulting, which Eucalyptus including its affiliates also brings along.

It’s merely a matter of time

When Eucalyptus Systems is taken over by Amazon is a matter of time. Perhaps in 2013 or in 2014/2015. In any case, it will happen. How Eucalyptus is then integrated is difficult to say. I assume that Eucalyptus will initially operate independently and put under the umbrella brand of Amazon described as „An Amazon company“. According to the saying, concentrate on your core business, AWS will continue to focus on the public cloud and quite look how the hybrid and private cloud will develop under their own influence. In any case, with Eucalyptus they would have the right solution for their needs in their own portfolio.

Kategorien
Analysen

Amazon kauft Eucalyptus Cloud – Es ist nur eine Frage der Zeit

In der Public Cloud sind die Amazon Web Services (AWS) derzeit die unangefochtene Nummer Eins. Bei Private bzw. Hybrid Cloud Lösungen sind Anbieter wie Microsoft oder HP allerdings besser aufgestellt. AWS selbst hat hier zur Zeit kein eigenes Angebot zu bieten. Stattdessen wurde im März 2012 eine exklusive Kooperation mit Eucalyptus Systems eingegangen, die ein Abbild der grundlegenden AWS Funktionen bieten. Diese strategische Entscheidung ist nachvollziehbar und wird Folgen für die Zukunft haben.

Die Kooperation zwischen AWS und Eucalyptus

Im März 2012 haben AWS und Eucalyptus Systems, Anbieter einer Private Cloud Infrastruktur-Software, mit der sich die grundlegenden Funktionen der Amazon Cloud auch im eigenen Rechenzentrum aufbauen lassen, sich zu einer engeren zusammenarbeiten entschlossen. Diese Kooperation ging verstärkt von Eucalyptus CEO Marten Mickos aus und hat den Hintergrund, die Migration von Daten zwischen der Amazon Cloud und Eucalyptus Private Clouds besser zu unterstützen.

Dabei ist die Kooperation unterschiedlich aufgebaut. Zunächst konzentrieren sich Entwickler aus beiden Unternehmen darauf, Lösungen zu schaffen, die Unternehmenskunden dabei helfen sollen, Daten zwischen bestehenden Rechenzentren und der AWS Cloud zu migrieren. Weiterhin und noch bedeutender ist jedoch, dass die Kunden in der Lage sein sollen, dieselben Management Tools und die eigenen Kenntnisse für beide Plattformen zu nutzen. Darüber hinaus werden die Amazon Web Services Eucalyptus mit weiteren Informationen versorgen, um die Kompatibilität mit den AWS APIs zu verbessern.

Der Mitbewerb holt auf

Auch wenn es in der Public Cloud derzeit sehr rosig aussieht, die Zukunft liegt in der Hybrid Cloud. Hinzu kommt, dass viele Unternehmen eher mit einer eigenen Private Cloud liebäugeln, als in die Public Cloud zu wechseln. Das bedeutet, dass die Private bzw. die Hybrid zunehmend an Bedeutung gewinnen. Hier haben die Amazon Web Services, bis auf die Virtual Private Cloud, jedoch selbst nichts zu bieten. Microsoft und HP verfügen bereits über ein sehr ausgeglichenes Portfolio, das sowohl Lösungen und Angebote für die Public als auch für die Private Cloud bietet. Weiterhin verfügen beide über eine große Kundenbasis.

Außerdem ist ein weiterer Punkt klar. Wo sich Microsoft und HP auf Unternehmen konzentrieren, sind die Amazon Web Services derzeit noch verstärkt das Mekka für Startups. Der Erfolg spricht für sich. Dennoch, schaut man sich Amazons Bemühungen in den letzten Monaten an, ist die Zielrichtung klar. AWS muss und will in die Unternehmen. Das ist jedoch nur mit einer echten Private/ Hybrid Cloud Strategie möglich. Amazon wird daher irgendwann an einem Punkt ankommen, wo es aktiv darum geht, auch diese Märkte aggressiv zu erobern.

Amazon ist ein Serviceanbieter

Bisher hat AWS im Cloud-Umfeld keine Akquisitionen getätigt, da sie es einfach nicht mussten. Als Innovation-Leader setzen sie die Maßstäbe in der Public Cloud. In der Private/ Hybrid Cloud sieht es jedoch anders aus. Hier besteht, meiner Einschätzung nach, so gut wie keine Expertise. Auch wenn Amazon eigene Rechenzentren betreibt, ist der Betrieb einer quasi Standardlösung für Unternehmen anders. Hier haben Microsoft oder HP jahrelange Erfahrungen und somit einen klaren Vorteil. Die Amazon Web Services sind ein typischer Service-Anbieter. Das bedeutet, sie liefern ihre Services aus der Cloud aus, die einfach nur konsumiert werden sollen. Cloud-Software für den Massenmarkt wird nicht entwickelt. Für das Bereitstellen, Ausliefern, Warten und Ausrollen von Updates und neuer Versionen sowie die Kunden zu besänftigen fehlt die Erfahrung. Daher ist die Kooperation mit Eucalyptus der erste richtige Schritt gewesen. Was nicht zum Kerngeschäft gehört wird ausgelagert. So wie Amazon Cloud Computing vermarktet, scheinen sie es auch selbst zu leben.

Dennoch wird Amazon mehr Einfluss auf auf die Private und Hybrid Cloud nehmen und ebenfalls ein Stück von diesem Kuchen genießen wollen. Daher wird der nächste logische Schritt darin bestehen, Eucalyptus Systems zu kaufen. Zum Einen geht es um mehr Einfluss auf Eucalyptus. Denn auch auch wenn Marten Mickos die Kooperation mit AWS vorangetrieben hat, wird er sich nicht allem beugen, was Amazon verlangt. Auf der anderen Seite muss die Hybrid Cloud Integration gestärkt werden. Hinzu kommt, dass für die Private Cloud Beratung qualifiziertes Personal benötigt wird, das Eucalyptus inkl. seiner Partnerunternehmen ebenfalls mitbringt.

Es ist nur eine Frage der Zeit

Wann Eucalyptus Systems von Amazon übernommen wird ist eine Frage der Zeit. Vielleicht schon in 2013 oder doch erst in 2014/ 2015. Auf jedenfall wird es dazu kommen. Wie Eucalyptus dann integriert wird ist schwer zu sagen. Ich gehe davon aus, dass Eucalyptus zunächst eigenständig agieren wird und als „Ein Amazon Unternehmen“ unter die Dachmarke von Amazon gesetzt wird. Ganz nach dem Motto, konzentriere dich auf dein Kerngeschäft, wird AWS sich weiterhin auf die Public Cloud konzentrieren und in Ruhe schauen, wie sich die Hybrid und Private Cloud, unter dem eigenen Einfluss, entwickeln wird. Auf jedenfall hätten sie mit Eucalyptus dann schon einmal die richtige Lösung für ihre Zwecke im eigenen Portfolio.

Kategorien
Management @en

Amazon Web Services suffered a 20-hour outage over Christmas

After a rather bumpy 2012 with some heavy outages the cloud infrastructure of the Amazon Web Services again experienced some problems over Christmas. During a 20 hour outage several big customers were affected, including Netflix and Heroku. This time the main problem was Amazons Elastic Load Balancer (ELB).

Region US-East-1 is a very big problem

This outage is the last out of a series of catastrophic failure in Amazon’s US-East Region-1. It is the oldest and most popular region in Amazon’s cloud computing infrastructure. This new outage precisely in US-East-1 raises new questions about the stability of this region and what Amazon has actually learned and actually improved from the past outages. Amazon customer awe.sm had recently expressed criticism of the Amazon cloud and especially on Amazon EBS (Amazon Elastic Block Store) and the services that depend on it.

Amazon Elastic Load Balancer (ELB)

Besides the Amazon Elastic Beanstalk API the Amazon Elastic Load Balancer (ELB) was mainly affected by the outage. Amazon ELB belongs to one of the important services if you try to build a scalable and highly available infrastructure in the Amazon cloud. With ELB users can move loads and capacities between different availability zones (Amazon independent data centers), to ensure availability when it comes to problems in one data center.

Nevertheless: both Amazon Elastic Beanstalk and Amazon ELB rely on Amazon EBS, which is known as the „error prone-backbone of the Amazon Web Services„.

Kategorien
Management

Amazon Web Services mit 20-stündigen Ausfall über Weihnachten

Nach einem eher holprigen Jahr 2012 mit einigen schweren Ausfällen, zeigten sich über Weihnachten erneut Probleme in der Cloud Infrastruktur der Amazon Web Services. Während eines 20-stündigen Ausfalls waren mehrere größere Kunden betroffen, darunter Netflix und Heroku. Das Hauptproblem bestand dieses Mal mit Amazons Elastic Load Balancer (ELB).

Region US-East-1 sehr großes Problemkind

Bei diesem Ausfall handelt es sich um den bisher letzten aus einer Reihe von schweren Ausfällen in Amazons Region US-East-1. Dabei handelt es sich um die älteste und meist genutzte Region in Amazons Cloud Computing Infrastruktur. Dieser erneute Ausfall eben in US-East-1 wirft neue Fragen bzgl. der Stabilität dieser Region auf und was Amazon aus den letzten Ausfällen tatsächlich gelernt und vor allem verbessert hat. Erst kürzlich hatte Amazon Kunde awe.sm Kritik an der Amazon Cloud und hier insbesondere an Amazon EBS (Amazon Elastic Block Store) und den Services die davon abhängig sind geäußert.

Amazon Elastic Load Balancer (ELB)

Von dem Ausfall war neben der Amazon Elastic Beanstalk API hauptsächlich der Amazon Elastic Load Balancer (ELB) betroffen. Dabei gehört Amazon ELB zu einem der wichtigen Services, wenn eine skalierbare und hochverfügbare Infrastruktur innerhalb der Amazon Cloud aufgebaut werden soll. Nutzer können mit dem ELB die Lasten zwischen verschiedenen Availability Zones (unabhängiges Amazon Rechenzentrum) verschieben und damit die Verfügbarkeit sicherstellen, wenn es in einem Rechenzentrum zu Problemen kommt.

Allerdings: Sowohl Amazon Elastic Beanstalk als auch Amazon ELB setzen auf Amazon EBS, welches als das „fehlerhafte Rückgrat der Amazon Web Services gilt„.

Kategorien
Analysis

Lessons learned: Amazon EBS is the error-prone backbone of AWS

In a blog article awe.sm writes about their own experiences using the Amazon Web Services. Beside the good things of the cloud infrastructure for them and other startups you can also derived from the context that Amazon EBS is the single point of failure in Amazon’s infrastructure.

Problems with Amazon EC2

awe.sm criticized Amazon EC2’s constraints regarding performance and reliability on which you absolutely have to pay attention as a customer and should incorporate into your own planning. The biggest problem awe.sm is seeing in AWS zone-concept. The Amazon Web Services consist on several worldwide distributed „regions“. Within this regions Amazon divided in so called „availability zones“. These are independent data center. awe.sm mentions three things they have learned from this concept so far.

Virtual hardware does not last as long as real hardware

awe.sm uses AWS for about 3 years. Within this period, the maximum duration of a virtual machine was about 200 days. The probability that a machine goes in the state „retired“ after this period is very high. Furthermore Amazon’s „retirement process“ is unpredictable. Sometimes you’ll notify ten days in advance that a virtual machine is going to be shut down. Sometimes the retirement notification email arrives 2 hours after the machine has already failed. While it is relatively simple to start a new virtual machine you must be aware that it is also necessary to early use an automated deployment solution.

Use more than one availability zone and plan redundancy across zones

awe.sm made ​​the experience that rather an entire availability zone fails than a single virtual machine. That means for the planning of failure scenarios, having a master and a slave in the same zone is as useless as having no slave at all. In case the master failures, it is possibly because the availability zone is not available.

Use multiple regions

The US-EAST region is the most famous and also oldest and cheapest of all AWS regions worldwide. However, this area is also very prone to error. Examples were in April 2011, March 2012 and June 2012 (twice). awe.sm therefore believes that the frequent regions-wide instability is due to the same reason: Amazon EBS.

Confidence in Amazon EBS is gone

The Amazon Elastic Block Store (EBS) is recommended by AWS to store all your data on it. This makes sense. If a virtual machine goes down the EBS volume can be connected to a new virtual machine without losing data. EBS volumes should also be used to save snapshots, backups of databases or operating systems on it. awe.sm sees some challenges in using EBS.

I/O rates of EBS volumes are bad

awe.sm made ​​the experiences that the I/O rates of EBS volumes in comparison to the local store on the virtual host (Ephemeral Storage) are significantly worse. Since EBS volumes are essentially network drives they also do not have a good performance. Meanwhile AWS provides Provisioned IOPS to give EBS volumes a higher performance. Because of the price they are too unattractive for awe.sm.

EBS fails at regional level and not per volume

awe.sm found two different types of behavior for EBS. Either all EBS volumes work or none! Two of the three AWS outages are due to problems with Amazon EBS. If your disaster recovery builds on top of moving EBS volumes around, but the downtime is due to an EBS failure, you have a problem. awe.sm had just been struggling with this problem many times.

The error status of EBS on Ubuntu is very serious

Since EBS volumes are disguised as block devices, this leads to problems in the Linux operating system. With it awe.sm made very bad experiences. A failing EBS volume causes an entire virtual machine to lock up, leaving it inaccessible and affecting even operations that don’t have any direct requirement of disk activity.

Many services of the Amazon Cloud rely on Amazon EBS

Because many other AWS services are built on EBS, they fail when EBS fails. These include e.g. Elastic Load Balancer (ELB), Relational Database Service (RDS) or Elastic Beanstalk. As awe.sm noticed EBS is nearly always the core of major outages at Amazon. If EBS fails and the traffic subsequently shall transfer to another region it’s not possible because the load balancer also runs on EBS. In addition, no new virtual machine can be started manually because the AWS Management Console also runs on EBS.

Comment

Reading the experiences of awe.sm I get the impression that Amazon do not live this so often propagandized „building blocks“ as it actually should. Even when it is primary about the offering of various cloud services (be able to use them independently), why let they depend the majority of these services from a single service (EBS) and with that create a single point of failure?

Kategorien
Analysen

Erfahrungen: Amazon EBS ist das fehlerhafte Rückgrat von AWS

In einem Blogartikel schreibt das Unternehmen awe.sm über die eigenen Erfahrungen mit der Nutzung der Amazon Web Services (AWS). Neben den Vorteilen, die sich für das Unternehmen und andere Startups durch die Cloud Infrastruktur ergeben, lässt sich aus dem Kontext aber auch ableiten, dass Amazon EBS der Single Point of Failure in Amazons Infrastruktur ist.

Die Probleme von Amazon EC2

awe.sm kritisiert Amazon EC2s Beschränkungen hinsichtlich der Geschwindigkeit und Zuverlässigkeit, auf die man als Kunde unbedingt achten und in die eigene Planung mit einfließen lassen sollte. Das größte Problem besteht in dem Zonen-Konzept von AWS. Die Amazon Web Services bestehen aus mehreren „Regionen“ die weltweit verteilt sind. Innerhalb dieser Regionen unterteilt Amazon noch einmal in die sogenannten „Availability Zones„. Dabei handelt es sich um eigenständige Rechenzentren. awe.sm nennt drei Dinge, die sie aus diesem Konzept bisher gelernt haben.

Virtuelle Hardware hält nicht so lange wie echte Hardware

awe.sm nutzt AWS seit ca. 3 Jahren. Innerhalb dieses Zeitraums betrug die maximale Laufzeit einer virtuellen Maschine ungefähr 200 Tage. Die Wahrscheinlichkeit, dass sie nach dieser Zeit in den Zustand „retired“ geht sei sehr hoch. Zudem sei Amazons „retirement process“ unberechenbar. Manchmal wird man bereits zehn tage vorher informiert, dass eine virtuelle Maschine heruntergefahren wird. Es kam aber auch vor, dass eine Info zwei Stunden eintraf, nachdem die virtuelle Maschine bereits ausgefallen war. Zwar ist es relativ simple neue virtuelle Maschinen hochzufahren, aber man sollte sich bewusst machen, dass es auch notwendig ist frühzeitig eine automatisierte Deploymentlösung zu nutzen.

Man muss mehr als eine Availability Zone nutzen und die Redundanz zonenübergreifend planen

awe.sm hat die Erfahrungen gemacht, dass eher eine ganze Availability Zone ausfällt als eine einzige virtuelle Maschine. Das bedeutet für die Planung von Fehlerszenarios, dass es genauso nutzlos ist, einen Master und einen Slave in derselben Region zu haben wie gar keinen Slave einzusetzen. Sollte der Master ausfallen liegt es möglicherweise nämlich nur daran, weil die Availability Zone nicht verfügbar ist.

Man sollte mehrere Regionen verwenden

Die Region US-EAST ist die bekannteste und ebenfalls älteste und günstigste aller AWS Regionen weltweit. Allerdings ist auch gerade diese Region sehr fehleranfällig. Beispiele gab es im April 2011, März 2012 oder auch Juni 2012 [1][2]. awe.sm geht daher davon aus, das die häufige Regionen weite Instabilität auf die gleiche Ursache zurückzuführen ist: Amazon EBS.

Das Vertrauen in Amazon EBS ist verschwunden

Der Amazon Elastic Block Store (EBS) wird von AWS empfohlen, um darauf sämtliche Daten zu speichern. Das macht auch Sinn. Fällt eine virtuelle Maschine aus, kann das EBS Volume an eine neue virtuelle Maschine angebunden werden, ohne dabei Daten zu verlieren. EBS Volumes sollen ebenfalls dazu genutzt werden, um dort Snapshots, Backups der Datenbanken oder die Betriebssysteme darauf zu speichern. awe.sm sieht in EBS jedoch manche Herausforderungen.

Die I/O Raten von EBS Volumes sind schlecht

awe.sm hat die Erfahrungen gemacht, dass die I/O Raten von EBS-Volumes im Vergleich zu dem lokalen Speicher auf dem virtuellen Host (Ephemeral Storage) deutlich schlechter sind. Da es sich bei EBS Volumes im wesentlichen um Netzlaufwerke handelt, haben sie ebenfalls auch keine gute Performance. AWS stellt mit IOPS zwar mittlerweile EBS Volumes mit einer höheren Performance bereit. Für awe.sm sind diese auf Grund des Preises jedoch viel zu unattraktiv.

EBS versagt auf der Regionen-Ebene und nicht pro Volume

awe.sm hat an EBS zwei unterschiedliche Verhaltensarten festgestellt. Entweder funktionieren alle EBS Volumes oder keines! Zwei von den drei AWS Ausfällen sind auf Probleme mit Amazon EBS zurückzuführen. Sollte das eigene Disaster Recovery also darauf aufbauen, im Fehlerfall EBS Volumes zu transferieren, der Ausfall jedoch auf Grund eines EBS Fehlers auftritt, hat man ein Problem. awe.sm habe genau mit diesem Problem schon öfters zu kämpfen gehabt.

Der Fehlerzustand von EBS auf Ubuntu ist sehr schwerwiegend

Da EBS Volumes als Block-Devices getarnt werden, führt das zu Problemen im Linux Betriebssystem. Damit hat awe.sm sehr schlechte Erfahrungen machen müssten. So hat bspw. ein fehlerhaftes EBS Volume dazu geführt, dass eine virtuelle Maschine vollständig eingefroren ist und keine Möglichkeit mehr bestand auf die Maschine zuzugreifen oder weitere Aktionen durchzuführen.

Viele Services der Amazon Cloud setzen auf Amazon EBS

Da viele weitere AWS Services auf EBS aufsetzen, fallen diese ebenfalls aus, wenn EBS ausfällt. Dazu gehören u.a. der Elastic Load Balancer (ELB), die Relational Database Service (RDS) oder Elastic Beanstalk. Wie awe.sm festgestellt hat ist EBS so gut wie immer das Hauptproblem größerer Ausfälle bei Amazon. Fällt EBS also aus und soll der Datenverkehr daraufhin in eine andere Region übertragen werden, funktioniert das nicht, da der Load Balancer ebenfalls auf EBS läuft. Darüber hinaus kann keine neue virtuelle Maschine manuell gestartet werden, da die AWS Management Console ebenfalls auf EBS läuft.

Kommentar

Wenn man sich die Erfahrungen von awe.sm so durchliest erhält man den Eindruck, dass dieses so oft propagierte „Building Blocks“ bei Amazon doch nicht so gelebt wird wie es eigentlich sollte. Auch wenn es dabei primär um das Angebot der einzelnen Cloud Services geht (diese unabhängig nutzen zu können), wieso macht man den Großteil dieser Services dann von einem einzigen Service (EBS) abhängig und schafft damit einen Single Point of Failure?

Kategorien
Management

Cloud Computing Ausfälle im Jahr 2012

Das Jahr neigt sich dem Ende und nicht alles ist 2012 in der Public Cloud so glatt gelaufen, wie es sich die meisten gewünscht haben. Ich denke bei dem einen oder anderen Cloud Admin und vor allem Nutzer werden sich in diesem Jahr wahrscheinlich ähnliche Gefühlsregungen gezeigt haben.

Public Cloud Ausfälle 2012

Ich habe mal eine kleine Auswahl aller Artikel zum Thema „Cloud Computing Ausfälle“ zusammengestellt, die ich im Jahr 2012 hier auf CloudUser veröffentlicht habe.

  1. Microsoft Azure mit 12-stündigem Ausfall – War der Schalttag (29. Februar) das Problem?
  2. CloudStore der britischen Regierung ebenfalls vom Windows Azure Ausfall betroffen
  3. Microsoft bestätigt: Windows Azure Ausfall war ein Schaltjahr Problem
  4. Azure Nutzer erhalten für den Ausfall am 29. Februar eine Gutschrift über 33%
  5. Amazon Web Services mit kurzzeitigem Ausfall
  6. Erneute Probleme in der Amazon Cloud – Ausfall bei den Amazon Web Services in North Virginia
  7. Der Himmel weint. Nicht! Public Cloud Ausfälle sind nun einmal öffentlich.
  8. Armutszeugnis: Cloud Computing Ausfälle haben seit 2007 mehr als 71 Million US-Dollar an Kosten verursacht.
  9. Salesforce hatte mit Ausfall zu kämpfen
  10. Amazon Web Services (AWS) erneut mit Ausfall. Wieder ein Stromausfall. Wieder in North Virginia. Schwere Stürme sind die Ursache.
  11. Der Ausfall der Amazon Web Services (AWS) zeigt die schlechte Systemarchitektur von Instagram
  12. Amazon Web Services (AWS) Ausfall: Erklärungen | Erster Kunde geht | Netflix hält die Treue | Okta versteht die Cloud-Architektur
  13. Der Amazon Web Services (AWS) Ausfall: Letzte Chance – So etwas darf nicht noch einmal passieren!
  14. Ausfall: Salesforce erneut mit schwerwiegenden Problemen
  15. Ausfallprävention: Diese Fragen sollte man seinem Cloud Computing Anbieter stellen
  16. Microsoft Windows Azure Compute in der Region „West Europe“ ausgefallen
  17. Fehlerhafte Netzwerkkonfiguration war Schuld am Windows Azure Ausfall für die Region „West Europe“
  18. Ausfall: Salesforce erneut mit Performance-Problemen
  19. Microsoft erklärt den Grund für den Ausfall von Windows Azure in der Region „West Europe“
  20. Schuldzuweisungen in Zeiten des Cloud Computing
  21. Erneuter Ausfall der Amazon Web Services zeigt, dass Cloud Nutzer nicht aus den eigenen Fehlern lernen
  22. Ausfall der Google App Engine – Load Balancer waren die Ursache
  23. Windows Azure Compute in „South Central US“ und „West Europe“ mit Problemen
  24. Ausfälle in der Cloud liegen in der Natur des Menschen

Da ist schon einiges zusammengekommen. Aber ich wette, tragen wir weltweit sämtliche Ausfälle in von Unternehmen selbst betriebenen Rechenzentren zusammen, schneidet die Public Cloud gut ab.

Hat jemand hierzu vielleicht Statistiken?

Kategorien
Management @en

Amazon improves EC2 with automatic failover and details their billing reports

Amazon improves one of their biggest „weak points“ and with that comes towards their customers. It’s about the failover for individual EC2 instances. Typically, a customer must take care themselves to ensure that a new EC2 instance boots up, when a running fails. Amazon has now optimized its infrastructure and introduces automatic failover for EC2 instances. Furthermore there are more detailed information on the bills.

Automatic failover for Amazon EC2

As an Amazon customer it is not easy to build your own infrastructure in the AWS cloud. For the promised high availability in public cloud computing it is necessary that the customer ensures that for themselves, which many users have not been implemented.

Amazon comes towards their customers now and extends its Auto Scaling function with the Amazon EC2 status checks. That means, when an instance in an Auto Scaling group becomes unreachable and fails a status check, it will be replaced automatically.

As Amazon writes, it is not necessary to take any action to begin using EC2 status checks in Auto Scaling groups. Auto Scaling already incorporates these checks as part of the periodic health checks it already performs.

More details within the invoices

Furthermore new detailed billing reports give access to new reports which include hourly line items of the Amazon infrastructure.