Vorteile von EBS vs. Instance-Store (und umgekehrt)

Question

Ich bin mir nicht im Klaren darüber, welche Vorteile ich von EBS gegenüber Instance-Store für meine Instanzen auf Amazon EC2 habe. Wenn überhaupt, scheint es, dass EBS viel nützlicher ist (stoppen, starten, persistieren + bessere Geschwindigkeit) bei relativ wenig Unterschied in den Kosten...? Gibt es auch irgendwelche Daten darüber, ob mehr Leute EBS nutzen, jetzt wo es verfügbar ist, da es noch relativ neu ist?

Answer 1

Im Endeffekt sollten Sie fast immer EBS-gesicherte Instanzen verwenden.

Das sind die Gründe

• EBS-gesicherte Instanzen können so eingestellt werden, dass sie nicht (versehentlich) über die API beendet werden können.
• EBS-gesicherte Instanzen können gestoppt werden, wenn sie nicht gebraucht werden, und wieder aufgenommen werden, wenn sie wieder benötigt werden (wie das Pausieren eines virtuellen PCs), was zumindest bei meinem Nutzungsverhalten viel mehr Geld spart, als ich für ein paar Dutzend GB EBS-Speicher ausgebe.
• EBS-gesicherte Instanzen verlieren ihren Instanzspeicher nicht, wenn sie abstürzen (nicht für alle Benutzer erforderlich, aber die Wiederherstellung ist viel schneller)
• Sie können die Größe des EBS-Instanzspeichers dynamisch ändern.
• Sie können den Speicher der EBS-Instanz auf eine brandneue Instanz übertragen (nützlich, wenn die Hardware bei Amazon, auf der Sie bisher liefen, ausfällt oder stirbt, was von Zeit zu Zeit vorkommt)
• Der Start einer EBS-gesicherten Instanz ist schneller, da das Image nicht aus S3 geholt werden muss.
• Wenn die Hardware Ihrer EBS-gestützten Instanz zur Wartung vorgesehen Wenn Sie die Instanz stoppen und starten, wird sie automatisch auf die neue Hardware migriert. Ich konnte auch eine EBS-gestützte Instanz auf einer ausgefallenen Hardware verschieben, indem ich die Instanz zwangsweise gestoppt und neu gestartet habe (bei ausgefallener Hardware können Ihre Erfahrungen variieren).

Ich bin ein intensiver Nutzer von Amazon und habe alle meine Instanzen auf EBS-gesicherten Speicher umgestellt, sobald die Technologie aus der Beta-Phase kam. Ich bin sehr zufrieden mit dem Ergebnis.

EBS kann immer noch versagen - kein Allheilmittel

Denken Sie daran, dass jeder Teil der Cloud-basierten Infrastruktur jederzeit ausfallen kann. Planen Sie Ihre Infrastruktur entsprechend. Auch wenn EBS-gestützte Instanzen im Vergleich zu ephemeren Speicherinstanzen ein gewisses Maß an Beständigkeit bieten, können und werden sie ausfallen. Verfügen Sie über ein AMI, von dem aus Sie bei Bedarf neue Instanzen in jeder Verfügbarkeitszone starten können, sichern Sie Ihre wichtigen Daten (z. B. Datenbanken) und betreiben Sie, wenn Ihr Budget es zulässt, mehrere Serverinstanzen für Lastausgleich und Redundanz (idealerweise in mehreren Verfügbarkeitszonen).

Wann nicht

Zu bestimmten Zeitpunkten kann es billiger sein, schnellere IO auf Instance-Store-Instanzen zu erreichen. Es gab eine Zeit, in der dies sicherlich zutraf. Jetzt gibt es viele Optionen für EBS-Speicher, die viele Bedürfnisse abdecken. Die Optionen und ihre Preise entwickeln sich im Zuge des technologischen Wandels ständig weiter. Wenn Sie eine große Anzahl von Instanzen haben, die wirklich entbehrlich sind (sie haben keinen großen Einfluss auf Ihr Geschäft, wenn sie einfach verschwinden), sollten Sie die Kosten gegen die Leistung abwägen. Auch EBS-gestützte Instanzen können jederzeit ausfallen, aber meine praktische Erfahrung zeigt, dass EBS langlebiger ist.

Answer 2

Unsere AWS-Einrichtung ist zu 99 % recycelbar. Für mich spielt es also keine Rolle, wenn ich eine Instanz beende - nichts geht jemals verloren. Meine Anwendung wird z. B. automatisch auf einer Instanz aus SVN bereitgestellt, unsere Protokolle werden auf einen zentralen Syslog-Server geschrieben.

Der einzige Vorteil der Instance-Speicherung, den ich sehe, sind Kosteneinsparungen. Ansonsten gewinnen EBS-gestützte Instanzen. Eric hat alle Vorteile genannt.

---

[2012-07-16] Ich würde diese Antwort heute ganz anders formulieren.

Ich habe im letzten Jahr keine guten Erfahrungen mit EBS-gestützten Instanzen gemacht. Die letzten Ausfälle bei AWS haben auch EBS ziemlich ruiniert.

Ich vermute, dass ein Dienst wie RDS auch eine Art von EBS verwendet, und das scheint zum größten Teil zu funktionieren. Auf den Instanzen, die wir selbst verwalten, sind wir EBS losgeworden, wo es möglich war.

Wir haben einen Datenbank-Cluster zurück auf Iron (= echte Hardware) verlagert, um ihn so weit wie möglich loszuwerden. Der einzige verbleibende Teil unserer Infrastruktur ist ein DB-Server, auf dem wir mehrere EBS-Volumes in ein Software-RAID strippen und zweimal täglich ein Backup erstellen. Was auch immer zwischen den Backups verloren geht, wir können damit leben.

EBS ist eine etwas heikle Technologie, da es sich im Wesentlichen um ein Netzwerk-Volume handelt: ein Volume, das von einem entfernten Standort aus an Ihren Server angeschlossen ist. Ich will die damit geleistete Arbeit nicht negieren - es ist ein erstaunliches Produkt, da es im Wesentlichen unbegrenzte beständig Speicherung ist nur einen API-Aufruf entfernt. Aber das ist kaum geeignet für Szenarien, in denen die E/A-Leistung entscheidend ist.

Zusätzlich zum Verhalten des Netzwerkspeichers wird das gesamte Netzwerk auf EC2-Instanzen gemeinsam genutzt. Je kleiner eine Instanz ist (z. B. t1.micro, m1.small), desto schlimmer wird es, weil Ihre Netzwerkschnittstellen auf dem eigentlichen Host-System von mehreren VMs (= Ihrer EC2-Instanz) gemeinsam genutzt werden, die darauf laufen.

Je größer die Instanz, die Sie erhalten, desto besser wird es natürlich. Besser bedeutet hier in angemessenem Rahmen .

Wenn Persistenz erforderlich ist, würde ich immer dazu raten, etwas wie S3 für die Zentralisierung zwischen Instanzen zu verwenden. S3 ist ein sehr stabiler Dienst. Automatisieren Sie dann die Einrichtung Ihrer Instanzen so weit, dass Sie einen neuen Server booten können und dieser von selbst bereit ist. Dann braucht man keinen Netzwerkspeicher, der länger lebt als die Instanz.

Alles in allem sehe ich also keinerlei Vorteile für EBS-gestützte Instanzen. Ich füge lieber eine Minute für den Bootstrap hinzu, als mit einem potenziellen SPOF zu arbeiten.

Answer 3

Wir mögen Instanz-Lager. Es zwingt uns dazu, unsere Instanzen vollständig wiederverwendbar zu machen, und wir können den Prozess der Erstellung eines Servers von Grund auf mit einem bestimmten AMI leicht automatisieren. Das bedeutet auch, dass wir AMIs leicht austauschen können. Außerdem hat EBS von Zeit zu Zeit noch Leistungsprobleme.

Answer 4

Eric hat es so ziemlich auf den Punkt gebracht. Wir ( Bitnami ) sind ein beliebter Anbieter von kostenlosen AMIs für beliebte Anwendungen und Entwicklungs-Frameworks (PHP, Joomla, Drupal, Sie verstehen schon). Ich kann Ihnen sagen, dass EBS-gespeicherte AMIs deutlich beliebter sind als S3-gespeicherte. Im Allgemeinen denke ich, dass S3-gestützte Instanzen für verteilte, zeitlich begrenzte Aufgaben verwendet werden (z. B. die Verarbeitung von Daten in großem Umfang), bei denen bei einem Ausfall eines Rechners einfach ein anderer hochgefahren wird. EBS-gestützte AMIS werden eher für "traditionelle" Serveraufgaben verwendet, wie z. B. Web- oder Datenbankserver, die den Status lokal halten und daher die Daten im Falle eines Absturzes verfügbar sein müssen.

Ein Aspekt, der nicht erwähnt wurde, ist die Tatsache, dass Sie Snapshots einer EBS-gestützten Instanz im laufenden Betrieb erstellen können, wodurch Sie sehr kostengünstige Backups Ihrer Infrastruktur erstellen können (die Snapshots sind blockbasiert und inkrementell)

Answer 5

Bei meiner letzten Stelle habe ich genau die gleichen Erfahrungen gemacht wie Eric. In meinem neuen Job durchlaufe ich jetzt den gleichen Prozess wie bei meinem letzten Job... ich baue alle AMIs für EBS-gesicherte Instanzen neu auf - und möglicherweise als 32-Bit-Maschinen (billiger - aber ich kann nicht dasselbe AMI auf 32- und 64-Maschinen verwenden).

EBS-gesicherte Instanzen starten schnell genug, so dass Sie mit der Nutzung der Amazon AutoScaling-API die es Ihnen ermöglicht, mithilfe von CloudWatch-Metriken den Start zusätzlicher Instanzen auszulösen und sie beim ELB (Elastic Load Balancer) zu registrieren und sie auch wieder herunterzufahren, wenn sie nicht mehr benötigt werden.

Diese Art der dynamischen Autoskalierung ist das, worum es bei AWS geht - hier können die echten Einsparungen bei der IT-Infrastruktur zum Tragen kommen. Es ist so gut wie unmöglich, Autoscaling mit den alten s3-"InstanceStore"-gestützten Instances richtig durchzuführen.