it-swarm.com.de

Vorteile von EBS gegenüber Instance-Store (und umgekehrt)

Ich bin mir nicht sicher, welche Vorteile EBS gegenüber dem Instance-Store für meine Instances auf Amazon EC2 bietet. Wenn überhaupt, scheint es, dass EBS bei relativ geringen Kostenunterschieden viel nützlicher ist (Stopp, Start, Ausdauer + bessere Geschwindigkeit) ...? Gibt es auch eine Messgröße dafür, ob jetzt, da EBS verfügbar ist, mehr Benutzer EBS verwenden, da es noch relativ neu ist?

374
HelloWorldy

Unter dem Strich sollten Sie fast immer von EBS unterstützte Instanzen verwenden.

Hier ist warum

  • Von EBS unterstützte Instanzen können so eingestellt werden, dass sie nicht (versehentlich) über die API beendet werden können.
  • Von EBS gesicherte Instanzen können angehalten werden, wenn Sie sie nicht verwenden, und bei Bedarf fortgesetzt werden (z. B. Anhalten eines virtuellen PCs), da meine Nutzungsmuster viel mehr Geld sparen, als ich für ein paar Dutzend GB EBS-Speicher ausgeben kann.
  • Von EBS unterstützte Instanzen verlieren bei einem Absturz nicht ihren Instanzenspeicher (nicht für alle Benutzer erforderlich, beschleunigt jedoch die Wiederherstellung erheblich).
  • Sie können die Größe des EBS-Instanzenspeichers dynamisch ändern.
  • Sie können den EBS-Instanzspeicher auf eine brandneue Instanz übertragen (nützlich, wenn die Hardware bei Amazon, auf der Sie ausgeführt wurden, abfällt oder abstirbt, was gelegentlich vorkommt).
  • Das Starten einer von EBS unterstützten Instanz ist schneller, da das Image nicht aus S3 abgerufen werden muss.
  • Wenn die Hardware Ihrer EBS-gesicherten Instanz für die Wartung geplant ist, wird das Stoppen und Starten der Instanz automatisch auf neue Hardware migriert. Ich konnte auch eine von EBS unterstützte Instanz auf fehlerhafter Hardware verschieben, indem ich die Instanz erzwang und erneut startete (Ihre Laufleistung kann bei fehlerhafter Hardware variieren).

Ich bin ein starker Amazon-Nutzer und habe alle meine Instanzen auf EBS-Backup-Speicher umgestellt, sobald die Technologie aus der Betaphase kommt. Ich bin sehr zufrieden mit dem Ergebnis.

EBS kann immer noch scheitern - keine Silberkugel

Denken Sie daran, dass jede Cloud-basierte Infrastruktur jederzeit ausfallen kann. Planen Sie Ihre Infrastruktur entsprechend. Von EBS unterstützte Instanzen bieten zwar eine gewisse Lebensdauer im Vergleich zu Instanzen mit kurzlebigem Speicher, können jedoch ausfallen. Verfügen Sie über ein AMI, von dem aus Sie neue Instanzen nach Bedarf in einer beliebigen Verfügbarkeitszone starten, Ihre wichtigen Daten (z. B. Datenbanken) sichern und, wenn Ihr Budget dies zulässt, mehrere Instanzen von Servern zum Lastenausgleich und zur Redundanz ausführen können (idealerweise in mehreren Verfügbarkeitszonen) ).

Wann nicht

Zu bestimmten Zeitpunkten kann es billiger sein, schnellere IO auf Instance Store-Instanzen zu erzielen. Es gab eine Zeit, in der dies mit Sicherheit zutraf. Jetzt gibt es viele Optionen für den EBS-Speicher, die vielen gerecht werden Die Optionen und ihre Preise ändern sich ständig, wenn sich die Technologie ändert. Wenn Sie über eine erhebliche Anzahl von Instanzen verfügen, die wirklich verfügbar sind (sie haben keine großen Auswirkungen auf Ihr Unternehmen, wenn sie einfach wegfallen), rechnen Sie mit Kosten und Leistung. Von EBS unterstützte Instanzen können auch zu jedem Zeitpunkt ausfallen, aber meiner praktischen Erfahrung nach ist EBS haltbarer.

289
Eric J.

99% unseres AWS-Setups können recycelt werden. Für mich spielt es also keine Rolle, ob ich eine Instanz beende - nichts geht jemals verloren. Z.B. Meine Anwendung wird automatisch auf einer Instanz von SVN bereitgestellt. Unsere Protokolle werden auf einen zentralen Syslog-Server geschrieben.

Der einzige Vorteil des Instanzenspeichers, den ich sehe, sind Kosteneinsparungen. Ansonsten gewinnen EBS-gestützte Instanzen. Eric erwähnte alle Vorteile.


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

Ich habe im letzten Jahr oder so keine guten Erfahrungen mit von EBS unterstützten Instanzen gemacht. Die letzten Ausfallzeiten auf AWS haben EBS ebenfalls ziemlich ruiniert.

Ich vermute, dass ein Dienst wie RDS auch eine Art EBS verwendet und dies zum größten Teil zu funktionieren scheint. In den Fällen, in denen wir uns selbst verwalten, haben wir, wo immer möglich, EBS beseitigt.

Wir haben uns so weit entfernt, dass wir einen Datenbankcluster wieder auf Eisen (= echte Hardware) umgestellt haben. Das einzige verbleibende Teil unserer Infrastruktur ist ein DB-Server, auf dem wir zwei Mal am Tag mehrere EBS-Volumes in ein Software-RAID einteilen und sichern. Was auch immer zwischen Backups verloren gehen würde, wir können damit leben.

EBS ist eine Flakey-Technologie, da es sich im Wesentlichen um ein Netzwerk-Volume handelt: Ein Volume, das von einem entfernten Standort aus an Ihren Server angeschlossen wird. Ich negiere die damit geleistete Arbeit nicht - es ist ein erstaunliches Produkt, da im Wesentlichen unbegrenzt dauerhaft Speicher ist nur ein API-Aufruf entfernt. Es ist jedoch kaum für Szenarien geeignet, 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 (z. B. t1.micro, m1.small) ist, desto schlimmer wird es, weil Ihre Netzwerkschnittstellen auf dem tatsächlichen Host-System von mehreren VMs (= Ihrer EC2-Instanz) gemeinsam genutzt werden, die darauf ausgeführt werden.

Je größer die Instanz, desto besser wird es natürlich. Besser hier heißt im Rahmen der Vernunft.

Wenn Persistenz erforderlich ist, würde ich den Leuten immer raten, so etwas wie S3 zu verwenden, um zwischen Instanzen zu zentralisieren. S3 ist ein sehr stabiler Dienst. Dann automatisieren Sie Ihr Instanz-Setup so weit, dass Sie einen neuen Server booten können und dieser sich selbst fertig macht. In diesem Fall ist kein Netzwerkspeicher erforderlich, der länger als die Instanz gültig ist.

Alles in allem sehe ich keinen Nutzen für von EBS unterstützte Instanzen. Ich füge lieber eine Minute zum Bootstrap hinzu und starte dann mit einem möglichen SPOF.

68
Till

Wir mögen Instance-Store. Dies zwingt uns dazu, unsere Instanzen vollständig recycelbar zu machen, und wir können den Prozess des Aufbaus eines Servers auf einem bestimmten AMI problemlos von Grund auf automatisieren. Dies bedeutet auch, dass wir AMIs leicht austauschen können. Außerdem hat EBS von Zeit zu Zeit immer noch Leistungsprobleme.

41
sehugg

Eric hat es so ziemlich geschafft. Wir ( Bitnami ) sind ein beliebter Anbieter von kostenlosen AMIs für beliebte Anwendungen und Entwicklungsframeworks (PHP, Joomla, Drupal, Sie haben die Idee). Ich kann Ihnen sagen, dass EBS-unterstützte AMIs wesentlich beliebter sind als S3-unterstützte. Im Allgemeinen denke ich, dass s3-gesicherte Instanzen für verteilte, zeitlich begrenzte Jobs verwendet werden (z. B. für die Verarbeitung großer Datenmengen), bei denen ein Computer ausfällt und ein anderer einfach hochgefahren wird. EBS-gestütztes AMIS wird in der Regel für "herkömmliche" Serveraufgaben verwendet, z. B. für Web- oder Datenbankserver, die den Status lokal beibehalten und daher die Verfügbarkeit der Daten im Falle eines Absturzes erfordern.

Ein Aspekt, den ich nicht erwähnt habe, ist die Tatsache, dass Sie während der Ausführung Snapshots einer EBS-gesicherten Instanz erstellen können, sodass Sie sehr kostengünstige Backups Ihrer Infrastruktur erstellen können (die Snapshots sind blockbasiert und inkrementell).

17
Daniel Lopez

Die EC2 "Hardware"

Wenn eine EC2-Instanz gestartet wird, ist eine virtuelle Maschine für die Ausführung der Instanz reserviert. Diese virtuelle Maschine weist je nach Instanztyp bestimmte Spezifikationen auf: 32-Bit- oder 64-Bit-CPU, Anzahl der virtuellen Kerne, Größe der Festplatte usw. Einzelheiten zu den Instanzspezifikationen finden Sie unter http: // aws .Amazon.com/ec2/# instance .

Wenn sich Ihre EC2-Instanz im Status "Wird ausgeführt" befindet, bedeutet dies, dass sie auf der virtuellen Maschine ausgeführt wird. Dafür wird Ihnen eine Gebühr berechnet.

Die Festplatte der virtuellen Maschine wird als "kurzlebig" eingestuft. Der Begriff "kurzlebig" kommt vom griechischen Wort "Ephemeros", was "nur einen Tag dauern" bedeutet. Alles, was sich auf einer solchen Festplatte befindet, sollte als vorübergehend betrachtet werden. Wenn die Daten nicht von der Festplatte kopiert werden und die virtuelle Maschine gestoppt wird, gehen sie verloren. Dies umfasst Daten, Software und sogar ein Betriebssystem, das sich auf diesen Festplatten befindet.

Amazon Web Services bietet EC2-Instanzen zwei Arten von Root-Geräten: "EBS-backed" und "Instance Store".

Instanzen "Instance Store"

Eine "Instance Store" -Instanz ist eine EC2-Instanz, deren Root-Gerät sich auf der Festplatte der virtuellen Maschine befindet. Beim Erstellen der Instanz wird das Basis-AMI auf die Festplatte der virtuellen Maschine kopiert und gestartet. Die Instanz kann so lange ausgeführt werden, wie Sie möchten, kann jedoch nicht gestoppt werden. Da das Root-Gerät der Instanz die eigentliche Festplatte ist, hängt es an der Hardware und Sie können die Instanz nur beenden. In diesem Fall wird die Instanz gelöscht und niemals wiederhergestellt. Sie laufen auch Gefahr, dass Sie bei einem Hardwareausfall der virtuellen Maschine auch etwas auf der Festplatte verlieren.

Wenn Sie eine Instanz des "Instanzspeichers" starten, können Sie sie so lange ausführen, bis Sie damit fertig sind. Beachten Sie, dass Ihnen ab dem Start der Instanz bis zu deren Beendigung eine Gebühr berechnet wird.

"EBS-Backed" -Instanzen

Eine "EBS-backed" -Instanz ist eine EC2-Instanz, die ein EBS-Volume als Root-Gerät verwendet. EBS-Volumes sind redundante, "virtuelle" Laufwerke, die nicht an eine bestimmte Hardware gebunden sind, jedoch auf eine bestimmte EC2-Verfügbarkeitszone beschränkt sind. Dies bedeutet, dass ein EBS-Volume innerhalb derselben Verfügbarkeitszone von einem Hardwareteil auf ein anderes verschoben werden kann. Sie können sich EBS-Volumes als eine Art Network Attached Storage vorstellen.

Wenn die Hardware der virtuellen Maschine ausfällt, kann das EBS-Volume einfach auf eine andere virtuelle Maschine verschoben und neu gestartet werden. Theoretisch verlieren Sie keine Daten.

Ein weiterer Vorteil ist, dass EBS-Volumes problemlos gesichert und dupliziert werden können. Auf diese Weise können Sie einfache Backup-Snapshots Ihrer Volumes erstellen, neue Volumes erstellen und neue EC2-Instanzen basierend auf diesen doppelten Volumes starten.

Der wahrscheinlich größte Vorteil von "EBS-backed" -Instanzen gegenüber "Instance Store" -Instanzen besteht darin, dass sie gestoppt werden können. Wenn Sie dies tun, wird die virtuelle Maschine heruntergefahren und das EBS-Volume zum späteren Abrufen gespeichert. Die Hardware steht dann einer anderen Person zur Verfügung. Während dieser Zeit wird Ihnen außerdem keine laufende Gebühr für die EC2-Instanz berechnet. Ihnen wird jedoch der EBS-Speicher in Rechnung gestellt. Wenn Sie möchten, dass die Instanz erneut ausgeführt wird, müssen Sie sie nur erneut starten. Eine neue virtuelle Maschine wird reserviert, Ihr EBS-Volume wird angehängt und Ihre Instanz wird gestartet.

Aber was ist mit den Festplatten der virtuellen Maschine?

Ja, diese Festplatten können auch dann verwendet werden, wenn Ihre EC2-Instanz "EBS-gesichert" ist. Standardmäßig sind sie nicht verfügbar. Wenn Sie zum Starten Ihrer Instanz die Befehlszeilenprogramme verwenden, können Sie die Option "-b" im Befehl ec2-run-instance verwenden, um die Laufwerke "instance store" an Ihre EC2-Instanz anzuhängen.

Die Verfügbarkeit dieser Laufwerke kann hilfreich sein, wenn Sie temporäre Daten speichern möchten. Der Lese- und Schreibzugriff sollte schneller sein als das Lesen und Schreiben auf ein EBS-Volume, da Sie keine Daten über das Netzwerk senden. Darüber hinaus werden Ihnen keine Gebühren für die Datenübertragung oder -speicherung berechnet. Dies funktioniert jedoch nur, wenn die Daten jederzeit verloren gehen können.

Quelle: http://help.skeddly.com/Amazon-web-services/ebs-backed-versus-instance-store

16

Ich habe genau die gleiche Erfahrung wie Eric in meiner letzten Position gemacht. Jetzt in meinem neuen Job durchlaufe ich den gleichen Prozess, den ich bei meinem letzten Job durchgeführt habe. Ich erstelle alle AMIs für EBS - gestützte Instanzen neu - und möglicherweise als 32 - Bit - Rechner (billiger - aber ich kann nicht denselben AMI auf 32 - und 32 - Bit - Rechnern verwenden 64 Maschinen).

Von EBS unterstützte Instanzen werden so schnell gestartet, dass Sie die Amazon AutoScaling API verwenden können, mit der Sie mithilfe von CloudWatch-Metriken den Start zusätzlicher Instanzen auslösen und diese bei ELB (Elastic Load Balancer) registrieren können. und sie auch herunterzufahren, wenn sie nicht mehr benötigt werden.

Um diese Art der dynamischen automatischen Skalierung geht es bei AWS - wo die tatsächlichen Einsparungen bei der IT-Infrastruktur zum Tragen kommen können. Mit den alten Instanzen von s3 mit "InstanceStore" -Back ist es so gut wie unmöglich, die automatische Skalierung richtig durchzuführen.

16
j2d3

Ich fange gerade erst an, EC2 selbst zu verwenden, also kein Experte, aber Amazons eigene Dokumentation sagt:

es wird empfohlen, den lokalen Instanzspeicher für temporäre Daten zu verwenden, und für Daten, die eine höhere Lebensdauer erfordern , die Verwendung von Amazon EBS-Volumes oder das Sichern zu empfehlen die Daten an Amazon S3.

Betonung meiner.

Ich mache mehr Datenanalyse als Webhosting, daher ist mir die Persistenz weniger wichtig als für eine Website. Angesichts der von Amazon selbst vorgenommenen Unterscheidung würde ich nicht davon ausgehen, dass EBS für jeden das Richtige ist.

Ich werde versuchen, mich daran zu erinnern, wieder zu wiegen, nachdem ich beide benutzt habe.

13
isomorphismes

EBS ist wie die virtuelle Festplatte einer VM:

  • Dauerhaft, Instanzen, die von EBS unterstützt werden, können frei gestartet und gestoppt werden (Geld sparen)
  • Sie können jederzeit einen Snapshot erstellen, um Backups zu einem bestimmten Zeitpunkt zu erstellen
  • AMIs können aus EBS-Snapshots erstellt werden, sodass das EBS-Volume als Vorlage für neue Systeme dient

Instanzenspeicher ist:

  • Lokal, also in der Regel schneller
  • Nicht vernetztes EBS-I/O geht im Normalfall zu Lasten der Netzwerkbandbreite (mit Ausnahme von EBS-optimierten Instanzen mit separater EBS-Bandbreite).
  • Hat begrenzte E/A pro Sekunde IOPS. Sogar bereitgestellte E/A sind auf einige Tausend E/A begrenzt
  • Fragil. Sobald die Instanz gestoppt wird, verlieren Sie alles im Instanzenspeicher.

Hier ist, wo man sie benutzt:

  • Verwenden Sie EBS für die Backup-Betriebssystempartition und den permanenten Speicher (DB-Daten, kritische Protokolle, Anwendungskonfiguration).
  • Verwenden Sie den Instanzenspeicher für In-Process-Daten, unkritische Protokolle und den vorübergehenden Anwendungsstatus. Beispiel: externer Sortierspeicher, tempfiles usw.
  • Der Instanzenspeicher kann auch für leistungskritische Daten verwendet werden, wenn eine Replikation zwischen Instanzen stattfindet (NoSQL-DBs, verteilte Warteschlangen-/Nachrichtensysteme und DBs mit Replikation).
  • Verwenden Sie S3 für Daten, die zwischen Systemen geteilt werden: Eingabedatensatz und verarbeitete Ergebnisse oder für statische Daten, die von jedem System beim Starten verwendet werden.
  • Verwenden Sie AMIs für vorgebackene, startfähige Server
8
BobMcGee

Die meisten Benutzer entscheiden sich für die Verwendung einer von EBS unterstützten Instanz, da diese statusbehaftet ist. Es ist zu sicherer, da alles, was Sie ausgeführt und installiert haben, Stopp/Stopp oder Instanzenfehler überlebt.

Der Instanzspeicher ist statusfrei. Sie verlieren ihn mit allen darin enthaltenen Daten, falls eine Instanz ausfällt. Es ist jedoch kostenlos und schneller, da das Instanz-Volume an den physischen Server gebunden ist, auf dem VM ausgeführt wird.

4
mezi

Für jemanden, der dies alles neu ist und aus Versehen hier gelandet ist

Ab sofort sind alle AMIs in der Schnellstart-Sektion EBS-unterstützt

enter image description here

Es gibt auch eine gute Erklärung unter offizielles Dokument für den Unterschied zwischen [~ # ~] ebs [~ # ~] und Instanzspeicher

& dieses Bild bringt es auf den Punkt enter image description here

1
Aishwat Singh

Wenn Sie mehrere Instanzen ausführen und einen geplanten Service der AWS-Instanz als eine Ihrer Prioritäten für Vermeiden unerwarteter Kosten zuweisen, würde ich empfehlen, den Instanzspeicher nicht zu verwenden.

Wie in der Dokumentation zu EBS Volumes und der Antwort von j2d und Siddharth Sharma erläutert, kann der Instanzspeicher so lange ausgeführt werden, wie Sie möchten. aber es kann nicht gestoppt werden . Bedeutet, dass der Service nicht von einem Automatischer Start/Stopp oder Instanzwiederherstellung geplant werden kann.

Darüber hinaus gibt es für diese Art von Schema auch keinen Vorteil, EBS Backed auf Elastic Beanstalk zu verwenden, da es so konzipiert ist, dass alle Ressourcen, die Sie benötigen, sichergestellt werden brauchen sind lauf weiter . Es werden immer automatisch alle Dienste neu gestartet, die Sie beenden. enter image description here Überprüfung aller Rest , von den Gesamtkosten für die Verwendung des VPC , EBS und ELB , die zu EC2-Classic hinzugefügt wurden, dem EC2-VPC mit ELB ist meistens die beste Wahl, wenn im Gegensatz zu EC2-Classic eine gestoppte Instanz behält die zugehörigen elastischen IP-Adressen und das EBS-Volume ist gespeichert automatisch.

Als Fazit nehmen Sie den Hauptteil Ihrer Frage:

es scheint, dass EBS viel nützlicher ist (Stop, Start, Persist + bessere Geschwindigkeit) bei relativ geringem Kostenunterschied ...?

Die Antwort lautet yes, aber wenn Ihre Instanz EBS-basiert ist, kann sie gestoppt werden. Es verbleibt in Ihrem Konto, es wird Ihnen nichts berechnet . Es wird nur das Volumen berechnet, jedoch EBS wird stündlich berechnet . Sie können auch berücksichtigen, dass Sie unter allen verfügbaren Typen die Flexibilität haben, Größe des EBS-Volumes ändern .

Neben den Vorteilen, die bereits von Eric aufgeführt wurden, muss bekannt sein, dass S3 möglicherweise günstiger als EBS ist oder nicht. Ich bin damit einverstanden, dass es einen relativ geringen Kostenunterschied darstellt, wenn Sie beide Instanztypen die ganze Zeit über auf derselben Plattform und Architektur der Anwendung ausführen.

Wenn es jedoch ein Szenario gibt, in dem die Anwendung auf einem kostengünstigeren Service ausgeführt werden soll, alle nicht bearbeiteten Tasks ziehen und sie rollen zu VPC/EBS über a pipeline oder lambda sagen innerhalb kurzer Zeit <1 Stunde pro Tag, was unmöglich ist, wenn Sie eine Instanz verwenden -store , dann wird es eine andere Geschichte sein.

0
Chetabahana