Tag: EBS

Categories
Analysen

Amazon EBS: Wann beseitigen die Amazon Web Services ihren Single Point of Failure?

Innerhalb kürzester Zeit standen die Amazon Web Services in der Region US-EAST-1 in North Virginia wieder still. Zum einen am 19. August 2013, wobei anscheinend ebenfalls Amazon.com mit in die Tiefe gezogen wurde und zuletzt am 25. August 2013. Ursachen sollen wieder Unwetter gewesen sein. Dabei hat es dann natürlich auch wieder die üblichen Verdächtigen, allen voran Instagram und Reddit, erwischt. Instagram scheint vehement auf seine Cloud-Architektur zu vertrauen, die ihnen regelmäßig um die Ohren fliegt, wenn in North Virginia der Blitz einschlägt. Allerdings muss auch Amazon AWS scheinbar langsam etwas an seiner Infrastruktur verändern, denn so darf es nicht weitergehen.

US-EAST-1: Alt, günstig und brüchig

Die Amazon Region US-East-1 ist die älteste und meist genutzte Region in Amazons Cloud Computing Infrastruktur. Das hängt zu einem damit zusammen, das die Kosten im Vergleich zu anderen Regionen hier deutlich günstiger sind, wobei die Region Oregon mittlerweile preislich angepasst wurde. Zum anderen befinden sich hier auf Grund des Alters auch viele ältere Kunden mit vermutlich nicht für die Cloud optimierten Systemarchitekturen.

Alle Eier in einem Nest

Den Fehler, den die meisten Nutzer begehen ist, dass sie sich nur auf eine Region, in diesem Fall US-East-1, verlassen. Fällt diese aus, ist auch der eigene Service natürlich nicht mehr erreichbar. Das gilt für alle weltweiten Amazon Regionen. Um diese Situation zu umgehen, sollte ein Multi-Regionen Konzept gewählt werden, indem die Anwendung skalierbar und hochverfügbar über mehrere Regionen verteilt wird.

Amazon EBS: Single Point of Failure

Ich habe bereits im vergangenen Jahr die These aufgestellt, dass die Amazon Web Services über einen Single Point of Failure verfügen. Im Folgenden sind die Statusmeldungen vom 25. August 2013 zu sehen, die meine These unterstreichen. Das erste Mal bin ich durch einen Blogeintrag vom Amazon AWS Kunden awe.sm darauf aufmerksam geworden, die von ihren Erfahrungen in der Amazon Cloud berichten. Die fett markierten Stellen sind von entscheidender Bedeutung.

EC2 (N. Virginia)
[RESOLVED] Degraded performance for some EBS Volumes
1:22 PM PDT We are investigating degraded performance for some volumes in a single AZ in the US-EAST-1 Region
1:29 PM PDT We are investigating degraded performance for some EBS volumes and elevated EBS-related API and EBS-backed instance launch errors in a single AZ in the US-EAST-1 Region.
2:21 PM PDT We have identified and fixed the root cause of the performance issue. EBS backed instance launches are now operating normally. Most previously impacted volumes are now operating normally and we will continue to work on instances and volumes that are still experiencing degraded performance.
3:23 PM PDT From approximately 12:51 PM PDT to 1:42 PM PDT network packet loss caused elevated EBS-related API error rates in a single AZ, a small number of EBS volumes in that AZ to experience degraded performance, and a small number of EC2 instances to become unreachable due to packet loss in a single AZ in the US-EAST-1 Region. The root cause was a “grey” partial failure with a networking device that caused a portion of the AZ to experience packet loss. The network issue was resolved and most volumes, instances, and API calls returned to normal. The networking device was removed from service and we are performing a forensic investigation to understand how it failed. We are continuing to work on a small number of instances and volumes that require additional maintenance before they return to normal performance.
5:58 PM PDT Normal performance has been restored for the last stragglers of EC2 instances and EBS volumes that required additional maintenance.

ELB (N. Virginia)
[RESOLVED] Connectivity Issues
1:40 PM PDT We are investigating connectivity issues for load balancers in a single availability zone in the US-EAST-1 Region.
2:45 PM PDT We have identified and fixed the root cause of the connectivity issue affecting load balancers in a single availability zone. The connectivity impact has been mitigated for load balancers with back-end instances in multiple availability zones. We continue to work on load balancers that are still seeing connectivity issues.
6:08 PM PDT At 12:51 PM PDT, a small number of load balancers in a single availability zone in the US-EAST-1 Region experienced connectivity issues. The root cause of the issue was resolved and is described in the EC2 post. All affected load balancers have now been recovered and the service is operating normally.

RDS (N. Virginia)
[RESOLVED] RDS connectivity issues in a single availability zone
1:39 PM PDT We are currently investigating connectivity issues to a small number of RDS database instances in a single availability zone in the US-EAST-1 Region
2:07 PM PDT We continue to work to restore connectivity and reduce latencies to a small number of RDS database instances that are impacted in a single availability zone in the US-EAST-1 Region
2:43 PM PDT We have identified and resolved the root cause of the connectivity and latency issues in the single availability zone in the US-EAST-1 region. We are continuing to recover the small number of instances still impacted.
3:31 PM PDT The majority of RDS instances in the single availability zone in the US-EAST-1 Region that were impacted by the prior connectivity and latency issues have recovered. We are continuing to recover a small number of remaining instances experiencing connectivity issues.
6:01 PM PDT At 12:51 PM PDT, a small number of RDS instances in a single availability zone within the US-EAST-1 Region experienced connectivity and latency issues. The root cause of the issue was resolved and is described in the EC2 post. By 2:19 PM PDT, most RDS instances had recovered. All instances are now recovered and the service is operating normally.

Amazon EBS bildet die Basis vieler anderer Services

Die fett markierten Stellen sind aus diesem Grund von entscheidender Bedeutung, da alle diese Services gleichzeitig von einem einzigen Service abhängig sind: Amazon EBS. Zu dieser Erkenntnis ist awe.sm während seiner Analyse gekommen. Wie awe.sm festgestellt hat, ist EBS so gut wie immer das Hauptproblem größerer Ausfälle bei Amazon. So auch in dem obigen Ausfall. Mehr zum Amazon Elastic Block Store.

Zu den Services die von Amazon EBS abhängig sind gehören u.a. der Elastic Load Balancer (ELB), die Relational Database Service (RDS) oder Elastic Beanstalk.

Q: What is the hardware configuration for Amazon RDS Standard storage?
Amazon RDS uses EBS volumes for database and log storage. Depending on the size of storage requested, Amazon RDS automatically stripes across multiple EBS volumes to enhance IOPS performance.

Quelle: http://aws.amazon.com/rds/faqs/

EBS Backed
EC2: If you select an EBS backed AMI
ELB: You must select an EBS backed AMI for EC2 host
RDS
Elastic Beanstalk
Elastic MapReduce

Quelle: Which AWS features are EBS backed?

Load balancing across availability zones is excellent advice in principle, but still succumbs to the problem above in the instance of EBS unavailability: ELB instances are also backed by Amazon’s EBS infrastructure.

Quelle: Kommentar – How to work around Amazon EC2 outages

Wie man sieht hängen nicht wenige Services von Amazon EBS ab. Das bedeutet im Umkehrschluss, fällt EBS aus, sind diese Services ebenfalls nicht mehr verfügbar. Besonders tragisch verhält es sich mit dem Amazon Elastic Load Balancer (ELB), der dafür zuständig ist, im Fehlerfall oder bei großer Last den Datenverkehr zu leiten. Fällt also Amazon EBS aus und soll der Datenverkehr daraufhin in eine andere Region übertragen werden, funktioniert das nicht, da der Load Balancer ebenfalls von EBS abhängig ist.

Ich kann mich irren. Schaut man sich jedoch die vergangenen Ausfälle an, sprechen die Indizien dafür, dass Amazon EBS die zentrale Fehlerquelle innerhalb der Amazon Cloud ist.

Es darf daher die Frage erlaubt sein, ob einem Leader ständig dieselbe Komponente seiner Infrastruktur um die Ohren fliegen darf, die im Prinzip sogar als Single Point of Failure zu betrachten ist? Und ob ein Infrastructure-as-a-Service (IaaS) Anbieter, der die meisten Ausfälle von allen Anbietern am Markt zu verzeichnen hat, unter diesem Gesichtspunkt als Leader zu bezeichnen ist. Auch wenn ich immer wieder propagiere, dass man als Nutzer eines Public IaaS selbst für die Skalierbarkeit und Hochverfügbarkeit sorgen muss, hat der Anbieter selbst dennoch die Pflicht dafür zu sorgen, dass die Infrastruktur zuverlässig funktioniert.

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

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

Categories
Management @de

Pinterest macht die Amazon Cloud für den eigenen Erfolg verantwortlich

Pinterest ist seit dem Start zu einem der Lieblinge im Internet geworden und hat ein beachtliches Wachstum zu verzeichnen. Ryan Park, Operations Engineer bei Pinterest, führt diesen Erfolg auf die Skalierbarkeit des Cloud Computing, genauer den Amazon Web Services zurück. Ohne Cloud Computing wäre der Erfolg von Pinterest nicht möglich gewesen, so Park kürzlich auf dem Amazon Web Services Summit in New York.

Pinterest ist eine Online Pinnwand. Es handelt sich dabei um einen Service der es erlaubt, Dinge zu sammeln und zu organisieren, die für jemanden von besonderem Interesse sind. Zudem können diese Dinge von anderen Nutzern auf der Pinnwand angeschaut werden.

Pinterest macht die Amazon Cloud für den eigenen Erfolg verantwortlich

Die Cloud hat 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. Laut der Rating Agentur ComScore konnte Pinterest im Monat März fast 18 Millionen Besucher gewinnen, eine 50-prozentige Steigerung gegenüber dem Vormonat. Die Webseite gehört demnach zu einer der am schnellsten wachsenden Webseiten in der Geschichte des Webs.

Pinterest setzt bei seinem Service auf Amazon S3 und Amazon EC2. Dabei ist die Nutzung von S3 seit dem letzten August um den Faktor 10 gestiegen. EC2 im selben Zeitraum um den Faktor 3. In Zahlen bedeutet das in etwa 80 Millionen Objekte die in Amazon S3 gespeichert sind, was ca. 410 Terabyte an Nutzerdaten entspricht.

Nach Park, wäre dies mit einem eigenen Rechenzentrum niemals möglich gewesen. Zunächst hätte das einen riesen Aufwand in Bezug auf die Kapazitätsplanungen bedeutet und die Hardware hätte noch bestellt und selbst installiert werden müssen. Zudem wäre Pinterest nicht in der Lage gewesen so schnell zu skalieren.

Aktuell nutzt Pinterest ca. 150 EC2 Instanzen, um damit die Kern Services bereitzustellen. Diese sind in Python geschrieben. Zudem setzt Pinterest auf das Django Framework. Der Traffic wird über die Instanzen mit Hilfe von Amazon ELB (Elastic Load Balancer) verteilt. Weitere 90 EC2 Instanten werden für das Caching eingesetzt und noch einmal 35 Instanzen für interne Zwecke.

Im Hintergrund der Anwendungen laufen etwa 70 Master-Datenbanken auf EC2 sowie eine Reihe von Backup-Datenbanken, die sich in verschiedenen Regionen auf der ganzen Welt befinden, um für die Redundanz zu sorgen.

Um seinen Nutzern Daten in Echtzeit zu liefern, sind die Datenbank-Tabellen über mehrere Server hinweg verteilt. Wenn ein Datenbankserver mehr als 50 Prozent Last fährt, wird die Hälfte des Inhalts auf einen anderen Server verschoben. Dieser Prozess wird auch als Sharding bezeichnet. Im vergangenen November nutzte Pinterest acht Master-Slave-Datenbank-Paare. Heute sind es schon 64 Paare.

Ein weiterer Vorteil, der Pinterest entgegenkommt, ist das pay-as-you-go Modell. Da Pinterest bei AWS nur für die Ressourcen bezahlt die sie benötigen, konnte Kapital gespart werden. Der meiste Datenverkehr entsteht in den USA während den Nachmittags-und Abendstunden. Mit Amazon Autoscaling fügt Pinterest in diesen Zeiträumen entsprechend mehr Instanzen hinzu, um die Anfragen zu bewältigen. In der Nacht werden die Instanzen dann wieder entfernt.

Mit diesem Ansatz ist Pinterest in der Lage, die Anzahl der Server die sie in der Nacht verwenden, um rund 40 Prozent zu reduzieren. Da Amazon pro Stunde abrechnet, führt diese Reduktion zu Kosteneinsparungen. Während der Lastspitzen, zahlt Pinterest etwa 52 US-Dollar pro Stunde für Amazon EC2. In den frühen Morgenstunden liegen die Kosten dann bei 15 US-Dollar pro Stunde.

Das pay-as-you-go Modell lässt Pinterest ebenfalls neue Services testen, ohne dafür langfristig in eigene Serverhardware- oder software zu investieren. Ein gelungenes Experiment war, laut Park, die Nutzung von Amazon Elastic Map Reduce, Amazons Hadoop-basierten Service für die Datenanalyse.

Fazit

Pinterest ist nur ein gutes Beispiel dafür, wie Cloud Computing dabei unterstützt neue Geschäftsmodelle mit einem minimalen Ressourcen- und Kapitalaufwand zu realisieren und im Erfolgsfall für die entsprechende Flexibilität und Skalierbarkeit zu sorgen.

Categories
News

Amazon erweitert die Monitoring Funktionen für EBS Volumes

Die Amazon Web Services haben ihr Monitoring mit einer Funktion zum Überwachen von Elastic Block Store (EBS) Volumes erweitert. Das schreibt das Unternehmen in einem Blogbeitrag. Nutzer werden nun über inkonsistente EBS Volumes benachrichtigt.

Amazon erweitert die Monitoring Funktionen für EBS Volumes

Bereits im Januar hatte Amazon angekündigt, seinen Nutzern einen besseren Einblick in die Status ihrer Cloud Ressourcen über die AWS Management Konsole zu ermöglichen. Die erste Funktion gab einen Überblick darüber, was Amazon selbst in Zukunft machen wird und was Einfluss auf die Verfügbarkeit der Instanzen haben kann.

Als weitere Funktion wurde nun ein Statuscheck für EBS Volumes eingeführt. EBS Volumes ermöglichen die Nutzung eines Block Level Storage zusammen mit EC2 Instanzen. Über automatisierte Tests informieren die Statuschecks den Nutzer, wenn Inkonsistenzen in den Daten eines EBS Volumes auftreten sollten. Über die AWS Management Konsole erhält der Nutzer alle Statusinformationen geliefert und kann über die Auswahl eines bestimmten Volumes weitere Informationen bekommen.

Über eine API kann der Nutzer direkt reagieren, wenn der Statuscheck fehlschlagen sollte. Blockiert bspw. das I/O wird der Statuscheck für “IO Enabled” einen Fehler ausgeben. Mit dem Aufruf von EnableVolumeIO kann ein Nutzer das Volumen dann wieder reaktivieren. Über ModifyVolumeAttribute und DescribeVolumeAttribute können Volumes darüber hinaus so konfiguriert werden, dass sie I/O automatisch wieder reaktivieren.

Categories
Grundlagen

Ubuntu Enterprise Cloud Terminologie

Bei dem Einsatz der Ubuntu Enterprise Cloud (UEC) wird eine eigene Terminologie verwendet, die für das Verständnis und dem Umgang doch wichtig ist. Dieses Glossar fasst alle notwendigen Begriffe und ihre Bedeutung zusammen.

Cloud
Ein Verbund von physikalischen Maschinen, die mit Hilfe von virtuellen Maschinen Rechnerressourcen dynamisch bereitstellen und “wieder einsammeln”.

Cloud Controller (CLC)
Komponente von Eucalyptus die eine Weboberfläche (HTTPS Server auf Port 8443) bereitstellt und die Amazon EC2 API implementiert. Es sollte maximal einen Cloud Controller für eine UEC Installation geben. Der CLC wird durch das Ubuntu Package eucalyptus-cloud zur Verfügung gestellt.

Cluster
Ein Verbund von Nodes, die einem Cluster Controller zugeordnet sind. Dabei kann es mehr als einen Cluster in einer UEC Installation geben. Cluster bestehen in einigen Fällen aus physikalisch räumlich voneinander getrennten Nodes.

Cluster Controller (CC)
Eine Eucalyptus Komponente die für die Verwaltung der Node Ressourcen zuständig ist. Der CC wird durch das Ubuntu Package eucalyptus-cc zur Verfügung gestellt.

EBS
Elastic Block Storage

EC2 – Elastic Compute Cloud
Amazons Public Cloud Computing Angebot auf Basis von virtuellen Servern, bei dem die Abrechnung pro Stunde bzw. pro Gigabyte erfolgt.

EKI
Eucalyptus Kernel Image

EMI
Eucalyptus Machine Image

ERI
Eucalyptus Ramdisk Image

Eucalyptus
Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems.
Bei Eucalyptus handelt es sich um ein Open Source Projekt, welches ursprüglich an der University of California in Santa Barbara entwickelt wurde und mittlerweile durch Eucalyptus Systems unterstützt wird.

Front-end
Ein oder mehrere physikalische Server, auf denen die Eucalytpus Komponenten (cloud, walrus, storage controller, cluster controller) ausgeführt werden.

Node
Bei einem Node handelt es sich um eine phyiskalische Maschine, die in der Lage ist virtuelle Maschinen und einen Node Controller auszuführen. Innerhalb von Ubuntu bedeutet dies, dass eine CPU die VT Erweiterung unterstützt und den KVM Hypervisor ausführen kann.

Node Controller (NC)
Eine Eucalyptus Komponente die auf den Nodes ausgeführt wird, welche die virtuellen Maschinen beherbergen die wiederum der Cloud zugeordnet sind. Der NC wird durch das Ubuntu Package eucalyptus-nc zur Verfügung gestellt.

S3 – Simple Storage Service
Amazons Public Cloud Computing Angebot für das Speichern der EC2- und anderer Daten, bei dem die Abrechnung pro Gigabyte erfolgt.

Storage Controller (SC)
Eine Eucalyptus Komponente die zur Verwaltung des dynamic block storage services (EBS) dient. Jeder Cluster innerhalb einer Eucalyptus Installation kann seinen eigenen Storage Controller besitzen. Der SC wird durch das Ubuntu Package eucalyptus-sc zur Verfügung gestellt.

UEC
Ubuntu Enterprise Cloud
Ubuntu’s Cloud Computing Lösung auf der Basis von Eucalyptus.

VM
Virtual Machine

VT
Virtualization Technology
Moderne CPUs unterstützen diese Funktion, um die Arbeit (das Hosting) mit den virtuellen Maschinen zu beschleunigen.

Walrus
Eine Eucalyptus Komponente welche die Amazon S3 API implementiert und dafür benötigt wird, die Images der virtuellen Maschinen, sowie die Daten der Benutzer in S3 Buckets mittels put/get zu speichern.