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

381

Ich bin mir nicht sicher, welche Vorteile EBS gegenüber Instance Store für meine Instanzen auf Amazon EC2 bietet. Wenn überhaupt, scheint EBS bei relativ geringen Kostenunterschieden viel nützlicher zu sein (Stopp, Start, Fortbestehen + bessere Geschwindigkeit) ...? Gibt es auch eine Metrik, ob mehr Menschen EBS verwenden, sobald es verfügbar ist, wenn man bedenkt, dass es noch relativ neu ist?

Hallo Welt
quelle
Außerdem ist "micro" nur verfügbar, wenn Sie von EBS unterstützte Instanzen verwenden.
Ali
1
Instance Store-Volumes sind viel schneller und kein netzwerkbasierter Speicher!
Matt
Ich persönlich verwende den Instanzspeicher, um meine laufende MongoDB-Sammlung darin abzulegen und sie aus zwei Gründen auf S3 zu stellen. Zuerst ist es getrennt und verringert nicht die Schreibgeschwindigkeit auf meinem 10-Volume-EBS-RAID. Zweitens ist es viel schneller als EBS und da es mit meiner Instanz geliefert wird, macht es für mich keinen Sinn, zusätzliche EBS-Volumes zu erstellen, um das Dumping durchzuführen und sie zu zerstören, nachdem ich sie auf S3 gestellt habe. hoffe es hilft und nicht konstruktiv mein a ..
Maziyar
2
Ich bin in der Mitte des AWS-Benutzerhandbuchs (700 Seiten). Lesen Sie EBS und Instance Storage sorgfältig durch. Ich kann immer noch nicht verstehen, warum es solche Unterschiede gibt. Und noch verwirrter, warum der Instance Store S3 entspricht, aber anders benannt ist. Die Frage muss erneut geöffnet werden, um mehr Beiträge zu nützlichen Antworten zu erhalten.
Polymerase

Antworten:

293

Unter dem Strich sollten Sie fast immer EBS-gestützte Instanzen verwenden.

Hier ist der Grund

  • Von EBS unterstützte Instanzen können so festgelegt werden, dass sie nicht (versehentlich) über die API beendet werden können.
  • Von EBS unterstützte Instanzen können gestoppt werden, wenn Sie sie nicht verwenden, und fortgesetzt werden, wenn Sie sie erneut benötigen (z. B. Anhalten eines virtuellen PCs), zumindest wenn meine Verwendungsmuster viel mehr Geld sparen, als ich für ein paar Dutzend GB EBS-Speicher ausgeben muss.
  • Von EBS unterstützte Instanzen verlieren beim Absturz nicht ihren Instanzspeicher (nicht für alle Benutzer erforderlich, beschleunigt jedoch die Wiederherstellung erheblich).
  • Sie können die Größe des EBS-Instanzspeichers 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, abblättert oder ausfällt, was von Zeit zu Zeit 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-gestützten Instanz gewartet werden soll , wird das Stoppen und Starten der Instanz automatisch auf neue Hardware migriert. Ich konnte auch eine EBS-gestützte Instanz auf fehlerhafter Hardware verschieben, indem ich die Instanz zwangsweise stoppte und erneut startete (Ihr Kilometerstand kann bei fehlerhafter Hardware variieren).

Ich bin ein starker Benutzer von Amazon und habe alle meine Instanzen auf EBS-gestützten Speicher umgestellt, sobald die Technologie aus der Beta herausgekommen ist. Ich war sehr zufrieden mit dem Ergebnis.

EBS kann immer noch scheitern - keine Silberkugel

Beachten Sie, dass jede Cloud-basierte Infrastruktur jederzeit ausfallen kann. Planen Sie Ihre Infrastruktur entsprechend. EBS-gestützte Instanzen bieten im Vergleich zu kurzlebigen Speicherinstanzen zwar eine gewisse Haltbarkeit, können jedoch fehlschlagen. Verfügen Sie über ein AMI, von dem aus Sie nach Bedarf in jeder Verfügbarkeitszone neue Instanzen starten, Ihre wichtigen Daten (z. B. Datenbanken) sichern und, wenn Ihr Budget dies zulässt, mehrere Serverinstanzen für Lastausgleich und Redundanz ausführen können (idealerweise in mehreren Verfügbarkeitszonen) ).

Wenn nicht

Zu bestimmten Zeitpunkten kann es billiger sein, schnellere E / A auf Instance Store-Instanzen zu erzielen. Es gab eine Zeit, in der es sicherlich wahr war. Jetzt gibt es viele Optionen für die EBS-Speicherung, die vielen Anforderungen gerecht werden. Die Optionen und ihre Preisgestaltung ä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 wirken sich nicht wesentlich auf Ihr Unternehmen aus, wenn sie einfach verschwinden), rechnen Sie über Kosten und Leistung. EBS-gestützte Instanzen können auch zu jedem Zeitpunkt sterben, aber meine praktische Erfahrung ist, dass EBS dauerhafter ist.

Eric J.
quelle
4
Ja, das oben Genannte waren auch meine Gedanken ... Hoffentlich schreibt hier irgendwie über ihre Vorlieben für Instanzspeicher als Vergleich ...
HelloWorldy
5
EC2 mit Instance Store-Unterstützung kann auch so eingestellt werden, dass es nicht versehentlich beendet wird.
Jim Soho
44
Ich stelle die meisten meiner EBS-gestützten EC2-Instanzen auf die Verwendung von Instanzspeichern um. Es kommt wirklich darauf an, was Sie erreichen wollen. Ich wechsle wegen besserer E / A und weil ich jede EC2-Instanz jederzeit als verfügbar betrachte oder: Sie wird jede Minute ausfallen und ich werde alles verlieren, was sich auf einer solchen Instanz befindet. Architektur auf diese Weise hilft, ein echtes HA-System zu erhalten. Siehe auch stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html
Jim Soho
2
@Jim: Zumindest als ich die Antwort vor einem Jahr schrieb, haben Sie viel bessere E / A erhalten, indem Sie eine Reihe von EBS-Instanzen in eine Software-RAID-Konfiguration gestreift haben, als wenn Sie Instanzspeicher verwenden. Es ist auch viel schneller, eine Ersatzinstanz aus dem EBS-Backing zu starten als aus dem S3-Backing (der Instanzspeicher wird aus dem S3 geladen, was langsam sein kann). Ich habe in den letzten 6 Monaten nicht viel mit AWS gemacht. Dinge können sich geändert haben.
Eric J.
2
Scheint ein wenig schief zu sein - obwohl es möglich ist, EBS-Backed-Instanzen auszuführen und einen starken Schwerpunkt auf die Recyclingfähigkeit zu legen, halte ich es für gefährlich, wenn Neulinge diesen Beitrag betrachten und anschließend EBS-Backed-Instanzen erstellen, da sie dies wahrscheinlich nicht beibehalten werden Dieselbe Betonung liegt auf der Recyclingfähigkeit, die möglicherweise die wichtigste Komponente jeder Cloud-Infrastruktur ist. Und die gute Mehrheit der Leute, die sich das ansehen, ist sicher neu in diesem Bereich
Peter Berg
69

99% unserer AWS-Einstellungen sind recycelbar. Für mich ist es also nicht wirklich wichtig, ob ich eine Instanz beende - nichts geht jemals verloren. Wenn meine Anwendung beispielsweise automatisch auf einer Instanz von SVN bereitgestellt wird, werden unsere Protokolle auf einen zentralen Syslog-Server geschrieben.

Der einzige Vorteil des Instanzspeichers, den ich sehe, sind Kosteneinsparungen. Andernfalls 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 EBS-gestützten Instanzen gemacht. Die letzten Ausfallzeiten bei AWS haben auch EBS ziemlich ruiniert.

Ich vermute, dass ein Dienst wie RDS auch eine Art EBS verwendet, und das scheint größtenteils zu funktionieren. In den Fällen, in denen wir uns selbst verwalten, haben wir EBS nach Möglichkeit entfernt.

In einem Ausmaß loswerden, in dem wir einen Datenbankcluster zurück auf iron (= echte Hardware) verschoben haben. Das einzige verbleibende Teil unserer Infrastruktur ist ein DB-Server, auf dem mehrere EBS-Volumes in ein Software-RAID integriert und zweimal täglich gesichert werden. Was auch immer zwischen den Backups verloren gehen würde, wir können damit leben.

EBS ist eine etwas flockige Technologie, da es sich im Wesentlichen um ein Netzwerk-Volume handelt: ein Volume, das von einem Remote-Server an Ihren Server angeschlossen ist. Ich negiere nicht die damit geleistete Arbeit - es ist ein erstaunliches Produkt, da im Wesentlichen unbegrenzter dauerhafter Speicher nur einen API-Aufruf entfernt ist. 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 schlechter wird sie, da Ihre Netzwerkschnittstellen auf dem tatsächlichen Hostsystem 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, etwas wie S3 zu verwenden, um zwischen Instanzen zu zentralisieren. S3 ist ein sehr stabiler Dienst. Automatisieren Sie dann Ihr Instanz-Setup bis zu einem Punkt, an dem Sie einen neuen Server starten können und dieser sich von selbst fertig macht. Dann ist kein Netzwerkspeicher erforderlich, der länger als die Instanz lebt.

Alles in allem sehe ich keinen Nutzen für EBS-gestützte Instanzen. Ich füge dem Bootstrap lieber eine Minute hinzu und starte dann mit einem potenziellen SPOF.

Bis
quelle
1
Gibt es eine signifikante Verbesserung der E / A-Leistung mit EBS IOPS-Volumes im Vergleich zum Standard? Angenommen, das oben Gesagte gilt auch für EBS IOPS-Volumes.
Honzajde
4
Beide Technologien entwickeln sich weiter. Ich verdrahte diesen Kommentar im Jahr 2014, als ich "Provisioned IOPS" EBS habe, aber - der "Instance Store" ist jetzt SSD, was sogar noch schneller ist als zuvor !! Ein kurzlebiger Speicher gewinnt immer an Geschwindigkeit. Also benutze ich beides - behalte das "persistente" Zeug in EBS, habe alle temporären Dateien, Protokolle, "TempDB" -Datenbank, Swap-Datei und andere Sachen im Instance-Store. VORTEIL VON BEIDEN!
Alex
Was wäre, wenn Sie eine verteilte Datenbank benötigen, in der die Daten verteilt und dauerhaft gespeichert werden müssen? Benötigen Sie kein EBS, da der Instanzspeicher nicht dauerhaft ist?
CMCDragonkai
@CMCDragonkai Natürlich tust du das. Heutzutage gibt es viele Optionen, z. B. bietet AWS SSD-basierten Speicher an. Ich würde diese untersuchen und die Analyse erneut durchführen (Single vs. RAID usw.). Ich würde auch versuchen, die größtmöglichen Instanzen aufgrund des Netzwerkdurchsatzes zu erhalten. EBS ist immer noch ein Problem in Instanzen wie t1.micro.
Bis zum
Der Teil dieser Antwort zur Netzwerkleistung ist ziemlich veraltet - seit einiger Zeit gibt es eine Vielzahl von Instanzen, die gegen einen geringen Aufpreis "EBS-optimiert" werden können, und einige davon sind standardmäßig (ohne Aufpreis) ), die über dedizierte Netzwerkschnittstellen für EBS verfügen, vgl. docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
Josip Rodin
41

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 auf einfache Weise automatisieren. Dies bedeutet auch, dass wir AMIs problemlos austauschen können. Außerdem hat EBS von Zeit zu Zeit immer noch Leistungsprobleme.

sehugg
quelle
6
Netflix gibt die gleichen Empfehlungen auch.
Kingz
2
Wo speichern Sie Ihre blockbasierten persistenten Dateien?
CMCDragonkai
17

Eric hat es ziemlich genau getroffen. 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-gestützte AMIs wesentlich beliebter sind als S3-gestützte. Im Allgemeinen denke ich, dass s3-gestützte Instanzen für verteilte, zeitlich begrenzte Jobs (z. B. die Verarbeitung von Daten in großem Maßstab) verwendet werden. Wenn ein Computer ausfällt, wird ein anderer einfach hochgefahren. 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 im Falle eines Absturzes die Verfügbarkeit der Daten erfordern.

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

Daniel Lopez
quelle
S3 verfügt über eine integrierte Redundanz. Da EBS keine hat , müssen Sie darüber hinaus Redundanzsoftware bereitstellen.
Pacerier
2
@ Pacerier Das ist falsch, laut
Josip Rodin
16

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

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

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

j2d3
quelle
13

Ich fange gerade erst an, EC2 selbst zu verwenden, also kein Experte, aber in der Dokumentation von Amazon heißt es:

Wir empfehlen, dass Sie den lokalen Instanzspeicher für temporäre Daten verwenden. Für Daten, die eine höhere Haltbarkeit erfordern , empfehlen wir die Verwendung von Amazon EBS-Volumes oder die Sicherung der Daten in Amazon S3.

Hervorhebung von mir.

Ich mache mehr Datenanalysen als Webhosting, daher ist mir die Persistenz nicht so wichtig wie für eine Website. Angesichts der Unterscheidung von Amazon selbst würde ich nicht davon ausgehen, dass EBS für alle geeignet ist.

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

Isomorphismen
quelle
9

EBS ist wie die virtuelle Festplatte einer VM:

  • Langlebige, von EBS unterstützte Instanzen können frei gestartet und gestoppt werden (Geld sparen)
  • Kann zu jedem Zeitpunkt als Snapshot erstellt werden, um Backups zu bestimmten Zeitpunkten zu erhalten
  • AMIs können aus EBS-Snapshots erstellt werden, sodass das EBS-Volume zu einer Vorlage für neue Systeme wird

Instanzspeicher ist:

  • Lokal, also generell schneller
  • Nicht vernetzte EBS-E / A gehen im Normalfall zu Lasten der Netzwerkbandbreite (mit Ausnahme von EBS-optimierten Instanzen mit separater EBS-Bandbreite).
  • Hat E / A pro Sekunde IOPS begrenzt. Selbst bereitgestellte E / A erreichen ein Maximum von einigen tausend IOPS
  • Fragil. Sobald die Instanz gestoppt wird, verlieren Sie alles im Instanzspeicher.

Hier ist, wo jeder verwendet werden kann:

  • Verwenden Sie EBS für die Backup-Betriebssystempartition und den permanenten Speicher (DB-Daten, kritische Protokolle, Anwendungskonfiguration).
  • Verwenden Sie den Instanzspeicher für In-Process-Daten, unkritische Protokolle und den vorübergehenden Anwendungsstatus. Beispiel: externer Sortierspeicher, temporäre Dateien usw.
  • Der Instanzenspeicher kann auch für leistungskritische Daten verwendet werden, wenn zwischen Instanzen repliziert wird (NoSQL-DBs, verteilte Warteschlangen- / Nachrichtensysteme und DBs mit Replikation).
  • Verwenden Sie S3 für Daten, die von Systemen gemeinsam genutzt 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
BobMcGee
quelle
4

Die meisten Benutzer verwenden eine von EBS unterstützte Instanz, da diese zustandsbehaftet ist. Es ist sicherer, weil alles, was Sie ausgeführt und installiert haben, Stop / Stop oder Instanzfehler überlebt.

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

Mezi
quelle
2

Für jemanden, der neu in all dem ist und versehentlich hier gelandet ist

Ab sofort sind alle AMIs im Schnellstartbereich von EBS unterstützt

Geben Sie hier die Bildbeschreibung ein

Außerdem gibt es im offiziellen Dokument eine gute Erklärung für den Unterschied zwischen EBS und Instance Store

& dieses Bild fasst es ziemlich gut zusammen Geben Sie hier die Bildbeschreibung ein

Aishwat Singh
quelle
0

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

Wie in der Dokumentation von EBS Volumes und der Antwort von j2d3 und Siddharth Sharma erläutert, kann der Instanzspeicher so lange ausgeführt werden, wie Sie möchten, er kann jedoch nicht gestoppt werden . Bedeutet, dass der Dienst nicht durch einen automatischen Start / Stopp oder eine Instanzwiederherstellung geplant werden kann .

Darüber hinaus bietet die Verwendung von EBS Backed on Elastic Beanstalk für diese Art von Schema keinen Vorteil, da sichergestellt werden soll, dass alle benötigten Ressourcen weiterhin ausgeführt werden . Es werden immer automatisch alle Dienste neu gestartet, die Sie beenden. Geben Sie hier die Bildbeschreibung ein Überprüfen Sie den Rest der Gesamtkosten für die Verwendung von VPC , EBS und ELB , die zu EC2-Classic , der EC2-VPC mit ELB , hinzugefügt wurden meistens die beste Wahl, wenn eine gestoppte Instanz im Gegensatz zu EC2-Classic ihre zugehörige Elastic beibehält IP-Adressenund das EBS-Volume wird automatisch gespeichert .

Nehmen wir zum Schluss den Hauptteil Ihrer Frage:

Es scheint, dass EBS bei relativ geringen Kostenunterschieden viel nützlicher ist (Stopp, Start, Bestehen + bessere Geschwindigkeit) ...?

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

Neben den bereits von Eric aufgeführten Vorteilen muss auch beachtet werden, dass S3 in Bezug auf die Kosten möglicherweise billiger als EBS ist oder nicht . Ich bin damit einverstanden, dass es relativ wenig Kostenunterschied gibt, wenn Sie beide Instanztypen immer auf derselben Plattform und Architektur der Anwendung ausführen.

Wenn es jedoch ein Szenario gibt, in dem die Anwendung auf einem kostengünstigeren Dienst ausgeführt werden kann, ziehen Sie alle nicht behandelten Aufgaben ab und übertragen Sie sie innerhalb kurzer Zeit über eine Pipeline oder ein Lambda an die VPC / EBS. Sagen Sie <1 Stunde pro Tag, was bei Ihnen nicht möglich ist Verwenden Sie einen Instanzspeicher , dann wird es eine andere Geschichte sein.

Chetabahana
quelle