Avantages d'EBS par rapport au magasin d'instances (et vice-versa) [fermé]


381

Je ne sais pas quels avantages j'obtiens d'EBS par rapport au magasin d'instances pour mes instances sur Amazon EC2. Si quoi que ce soit, il semble que l'EBS soit beaucoup plus utile (arrêt, démarrage, persistance + meilleure vitesse) à une différence de coût relativement faible ...? En outre, existe-t-il une mesure quant à savoir si plus de gens utilisent EBS maintenant qu'il est disponible, étant donné qu'il est encore relativement nouveau?



"micro" n'est également disponible que si vous utilisez des instances soutenues par EBS.
Ali

1
Les volumes du magasin d'instances sont beaucoup plus rapides et ne constituent pas un stockage basé sur le réseau!
Matt

J'utilise personnellement l'instance-store pour y vider ma collection MongoDB opérationnelle et la mettre sur S3 pour deux raisons. Tout d'abord, il est séparé et il ne réduira pas la vitesse d'écriture sur mon RAID EBS à 10 volumes. Deuxièmement, c'est beaucoup plus rapide qu'EBS et, comme il est fourni avec mon instance, il ne sert à rien de créer des volumes EBS supplémentaires pour effectuer le dumping et les détruire après les avoir mis sur S3. j'espère que ça aide et pas constructif mon un ..
Maziyar

2
Je suis à mi-chemin du guide de l'utilisateur AWS (700 pages). J'ai lu attentivement EBS et le stockage d'instance. Je ne comprends toujours pas pourquoi il y a de telles différences. Et encore plus perplexe quant à la raison pour laquelle le magasin d'instances est équivalent à S3 mais est nommé différemment. La question doit être rouverte pour recevoir plus de contributions à des réponses utiles.
Polymerase

Réponses:


293

L'essentiel est que vous devriez presque toujours utiliser des instances soutenues par EBS.

Voici pourquoi

  • Les instances soutenues par EBS peuvent être définies de sorte qu'elles ne puissent pas être (accidentellement) arrêtées via l'API.
  • Les instances soutenues par EBS peuvent être arrêtées lorsque vous ne les utilisez pas et reprises lorsque vous en avez besoin à nouveau (comme mettre en pause un PC virtuel), au moins avec mes modèles d'utilisation, économisant beaucoup plus d'argent que je ne dépense sur quelques dizaines de Go de stockage EBS.
  • Les instances soutenues par EBS ne perdent pas leur stockage d'instance lorsqu'elles se bloquent (pas une exigence pour tous les utilisateurs, mais accélère la récupération)
  • Vous pouvez redimensionner dynamiquement le stockage d'instance EBS.
  • Vous pouvez transférer le stockage de l'instance EBS vers une toute nouvelle instance (utile si le matériel d'Amazon sur lequel vous fonctionniez devient floconneux ou meurt, ce qui arrive de temps en temps)
  • Il est plus rapide de lancer une instance soutenue par EBS car l'image n'a pas besoin d'être extraite de S3.
  • Si le matériel de votre instance soutenue par EBS est planifié pour la maintenance , l'arrêt et le démarrage de l'instance migrent automatiquement vers un nouveau matériel. J'ai également pu déplacer une instance soutenue par EBS sur du matériel défaillant en arrêtant de force l'instance et en la relançant (votre kilométrage peut varier sur du matériel défaillant).

Je suis un grand utilisateur d'Amazon et j'ai basculé toutes mes instances vers un stockage soutenu par EBS dès que la technologie est sortie de la version bêta. Je suis très content du résultat.

EBS peut toujours échouer - pas une solution miracle

Gardez à l'esprit que tout élément de l'infrastructure basée sur le cloud peut à tout moment échouer. Planifiez votre infrastructure en conséquence. Bien que les instances soutenues par EBS offrent un certain niveau de durabilité par rapport aux instances de stockage éphémères, elles peuvent échouer et échouent. Avoir une AMI à partir de laquelle vous pouvez lancer de nouvelles instances selon les besoins dans n'importe quelle zone de disponibilité, sauvegarder vos données importantes (par exemple, des bases de données), et si votre budget le permet, exécuter plusieurs instances de serveurs pour l'équilibrage de charge et la redondance (idéalement dans plusieurs zones de disponibilité ).

Quand ne pas le faire

À certains moments, il peut être moins coûteux d'obtenir des E / S plus rapides sur les instances du magasin d'instances. Il fut un temps où c'était certainement vrai. Il existe désormais de nombreuses options de stockage EBS, répondant à de nombreux besoins. Les options et leurs prix évoluent constamment à mesure que la technologie évolue. Si vous avez un nombre important d'instances vraiment jetables (elles n'affectent pas beaucoup votre entreprise si elles disparaissent), faites le calcul du coût par rapport aux performances. Les instances soutenues par EBS peuvent également mourir à tout moment, mais mon expérience pratique est qu'EBS est plus durable.


4
Oui, ce qui précède était aussi mes pensées ... J'espère que d'une manière ou d'une autre, ici, écrit à propos de leurs préférences pour le magasin d'instance à titre de comparaison ...
HelloWorldy

5
EC2 sauvegardé par l'instance peut également être défini pour ne pas se terminer accidentellement.
Jim Soho

44
En fait, je passe la plupart de mes instances EC2 soutenues par EBS à l'utilisation de magasins d'instances. Cela dépend vraiment de ce que vous voulez réaliser. Je change en raison d'une meilleure E / S et parce que je considère chaque instance EC2 comme jetable à tout moment, ou: elle tombera en panne d'une minute à l'autre et je perdrai tout ce qui se trouve sur une telle instance. L'architecture de cette façon permet d'obtenir un véritable système HA. Voir aussi stu.mp/2011/04/the-cloud-is-not-a-silver-bullet.html
Jim Soho

2
@Jim: Au moins lorsque j'ai écrit la réponse il y a un an, vous avez obtenu une bien meilleure E / S en répartissant un certain nombre d'instances EBS dans une configuration RAID logicielle que d'utiliser le stockage d'instances. Il est également beaucoup plus rapide de lancer une instance de remplacement à partir du support EBS que du support S3 (le stockage d'instance est chargé à partir de S3, ce qui peut être lent). Je n'ai pas fait grand chose sur AWS au cours des 6 derniers mois environ; les choses ont peut-être changé.
Eric J.31

2
Semble un peu déséquilibré - bien qu'il soit possible d'exécuter des instances soutenues par EBS et de maintenir un fort accent sur la recyclabilité, je pense qu'avoir de nouveaux arrivants en regardant ce post et en créant ensuite des instances soutenues par EBS est dangereux car ils ne le maintiendront probablement pas même accent sur la recyclabilité, qui est peut-être la composante la plus cruciale de toute infrastructure cloud. Et la bonne majorité des gens qui regardent ceci sont sûrs d'être nouveaux dans ce genre de choses
Peter Berg

69

99% de notre configuration AWS est recyclable. Donc, pour moi, cela n'a pas vraiment d'importance si je résilie une instance - rien n'est jamais perdu. Par exemple, mon application est déployée automatiquement sur une instance de SVN, nos journaux sont écrits sur un serveur Syslog central.

Le seul avantage du stockage d'instance que je vois sont des économies de coûts. Sinon, les instances soutenues par EBS gagnent. Eric a mentionné tous les avantages.


[2012-07-16] Je formulerais cette réponse très différemment aujourd'hui.

Je n'ai pas eu de bonne expérience avec les instances soutenues par EBS au cours de la dernière année environ. Les derniers temps d'arrêt sur AWS ont également détruit EBS.

Je suppose qu'un service comme RDS utilise également une sorte d'EBS et cela semble fonctionner pour la plupart. Sur les instances que nous gérons nous-mêmes, nous nous sommes débarrassés d'EBS lorsque cela était possible.

Se débarrasser d'une extension où nous avons déplacé un cluster de base de données vers le fer (= matériel réel). Le seul élément restant dans notre infrastructure est un serveur de base de données où nous répartissons plusieurs volumes EBS dans un RAID logiciel et sauvegardons deux fois par jour. Tout ce qui serait perdu entre les sauvegardes, nous pouvons vivre avec.

EBS est une technologie quelque peu floconneuse car il s'agit essentiellement d'un volume réseau: un volume attaché à votre serveur à distance. Je ne nie pas le travail effectué avec elle - c'est un produit incroyable car le stockage persistant essentiellement illimité est juste un appel d'API. Mais il n'est guère adapté aux scénarios où les performances d'E / S sont essentielles.

Et en plus du comportement du stockage réseau, tout le réseau est partagé sur les instances EC2. Plus une instance est petite (par exemple t1.micro, m1.small), plus elle est mauvaise, car vos interfaces réseau sur le système hôte réel sont partagées entre plusieurs machines virtuelles (= votre instance EC2) qui s'exécutent par-dessus.

Plus vous obtenez d'instance, mieux c'est, bien sûr. Mieux ici signifie dans la raison .

Lorsque la persévérance est requise, je conseillerais toujours aux gens d'utiliser quelque chose comme S3 pour centraliser entre les instances. S3 est un service très stable. Automatisez ensuite la configuration de votre instance à un point où vous pouvez démarrer un nouveau serveur et il se prépare par lui-même. Ensuite, il n'est pas nécessaire d'avoir un stockage réseau qui dure plus longtemps que l'instance.

Donc, dans l'ensemble, je ne vois aucun avantage pour les instances soutenues par EBS. J'ajoute plutôt une minute au bootstrap, puis je lance avec un SPOF potentiel.


1
Y a-t-il une amélioration significative des performances d'E / S avec des volumes de type EBS IOPS par rapport au volume standard? Supposons que ce qui précède s'applique également aux volumes d'EBS IOPS.
honzajde

4
Les deux technologies évoluent. Je suis en train de contourner ce commentaire en 2014, lorsque j'ai EBS "IOPS provisionné", mais - le "magasin d'instances" est maintenant SSD, ce qui est encore plus rapide qu'auparavant !! Le stockage éphémère gagnera toujours en vitesse. Donc j'utilise les deux - garder les trucs "persistants" sur EBS, avoir tous les fichiers temporaires, les journaux, la base de données "TempDB", le fichier d'échange et d'autres trucs sur Instance-store. PROFITEZ DES DEUX!
Alex

Et si vous aviez besoin d'une base de données distribuée qui doit stocker ses données de manière distribuée et persistante. N'auriez-vous pas besoin d'EBS car le stockage d'instance n'est pas persistant?
CMCDragonkai

@CMCDragonkai Bien sûr que vous le faites. Il existe de nombreuses options de nos jours, par exemple, AWS a commencé à offrir un stockage sur SSD. Je voudrais les examiner et refaire l'analyse (single vs RAID, etc.). J'examinerais également comment obtenir les plus grandes instances possibles en raison du débit du réseau. EBS est toujours un problème sur des instances comme t1.micro.
jusqu'au

La partie de cette réponse sur les performances du réseau est assez obsolète - depuis un certain temps maintenant, il existe une variété d'instances qui peuvent être "optimisées EBS" à un petit coût supplémentaire, et certaines qui le sont par défaut (sans supplément) ), qui disposent d'interfaces réseau dédiées à l'EBS, cf. docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
Josip Rodin

41

Nous aimons l'instance-store. Cela nous oblige à rendre nos instances entièrement recyclables et nous pouvons facilement automatiser le processus de construction d'un serveur à partir de zéro sur une AMI donnée. Cela signifie également que nous pouvons facilement échanger les AMI. De plus, EBS a toujours des problèmes de performances de temps en temps.


6
Netflix fait également les mêmes recommandations.
Kingz

2
Alors, où stockez-vous vos fichiers persistants basés sur des blocs?
CMCDragonkai

17

Eric l'a cloué à peu près. Nous ( Bitnami ) sommes un fournisseur populaire d'AMI gratuites pour des applications et des cadres de développement populaires (PHP, Joomla, Drupal, vous avez l'idée). Je peux vous dire que les AMI basées sur EBS sont beaucoup plus populaires que celles basées sur S3. En général, je pense que les instances soutenues par s3 sont utilisées pour des travaux distribués et limités dans le temps (par exemple, le traitement à grande échelle des données) où si une machine tombe en panne, une autre est simplement lancée. AMIS soutenu par EBS a tendance à être utilisé pour des tâches de serveur «traditionnelles», telles que les serveurs Web ou de base de données qui gardent l'état localement et nécessitent donc la disponibilité des données en cas de plantage.

Un aspect que je n'ai pas vu mentionné est le fait que vous pouvez prendre des instantanés d'une instance soutenue par EBS pendant l'exécution, vous permettant ainsi d'avoir des sauvegardes très rentables de votre infrastructure (les instantanés sont basés sur des blocs et incrémentiels)


S3 a une redondance intégrée . EBS n'en a pas , vous devrez donc déployer un logiciel de redondance par-dessus.
Pacerier

2
@Pacerier C'est incorrect, selon la documentation officielle sur docs.aws.amazon.com/AWSEC2/latest/UserGuide/raid-config.html
Josip Rodin

16

J'ai eu exactement la même expérience qu'Eric à mon dernier poste. Maintenant, dans mon nouveau travail, je suis en train de suivre le même processus que celui que j'ai effectué lors de mon dernier travail ... reconstruire toutes leurs AMI pour des instances soutenues par EBS - et peut-être comme des machines 32 bits (moins cher - mais ne peut pas utiliser la même AMI sur 32 et 64 machines).

Les instances soutenues par EBS se lancent assez rapidement pour que vous puissiez commencer à utiliser l' API Amazon AutoScaling qui vous permet d'utiliser les métriques CloudWatch pour déclencher le lancement d'instances supplémentaires et les enregistrer sur l'ELB (Elastic Load Balancer), ainsi que pour les arrêter lorsque ne sont plus nécessaires.

Ce type de mise à l'échelle dynamique dynamique est la raison d'être d'AWS - où les économies réelles dans l'infrastructure informatique peuvent entrer en jeu. Il est pratiquement impossible de faire une mise à l'échelle automatique avec les anciennes instances sauvegardées par "InstanceStore" s3.


13

Je commence juste à utiliser EC2 moi-même, donc pas un expert, mais la propre documentation d'Amazon dit:

nous vous recommandons d'utiliser le magasin d'instances local pour les données temporaires et, pour les données nécessitant un niveau de durabilité plus élevé , nous vous recommandons d'utiliser des volumes Amazon EBS ou de sauvegarder les données sur Amazon S3.

Je souligne.

Je fais plus d' analyse de données que d'hébergement Web, donc la persistance n'a pas autant d'importance pour moi que pour un site Web. Compte tenu de la distinction faite par Amazon lui-même, je ne suppose pas que EBS est bon pour tout le monde.

Je vais essayer de me rappeler de peser à nouveau après avoir utilisé les deux.


9

EBS est comme le disque virtuel d'une machine virtuelle:

  • Durable, les instances soutenues par EBS peuvent être démarrées et arrêtées librement (économie d'argent)
  • Peut être instantané à tout moment pour obtenir des sauvegardes ponctuelles
  • Les AMI peuvent être créées à partir d'instantanés EBS, de sorte que le volume EBS devient un modèle pour les nouveaux systèmes

Le stockage d'instance est:

  • Local, donc généralement plus rapide
  • Non en réseau, dans des cas normaux, les E / S EBS se font au détriment de la bande passante du réseau (à l'exception des instances optimisées pour EBS, qui ont une bande passante EBS distincte)
  • Possède un nombre limité d'E / S par seconde IOPS. Même les E / S provisionnées atteignent quelques milliers d'E / S par seconde
  • Fragile. Dès que l'instance est arrêtée, vous perdez tout dans le stockage d'instance.

Voici où les utiliser:

  • Utilisez EBS pour la partition de sauvegarde du système d'exploitation et le stockage permanent (données DB, journaux critiques, configuration d'application)
  • Utilisez le stockage d'instance pour les données en cours, les journaux non critiques et l'état transitoire de l'application. Exemple: stockage de tri externe, fichiers temporaires, etc.
  • Le stockage d'instance peut également être utilisé pour les données critiques en termes de performances, en cas de réplication entre les instances (bases de données NoSQL, systèmes de file d'attente / de messages distribués et bases de données avec réplication)
  • Utilisez S3 pour les données partagées entre les systèmes: jeu de données d'entrée et résultats traités, ou pour les données statiques utilisées par chaque système lors du lancement.
  • Utiliser des AMI pour des serveurs précuits et lancables

4

La plupart des gens choisissent d'utiliser l'instance soutenue par EBS car elle est dynamique. C'est plus sûr car tout ce que vous avez en cours d'exécution et installé à l'intérieur, survivra à l'arrêt / à l'arrêt ou à toute défaillance d'instance.

Le magasin d'instances est sans état, vous le perdez avec toutes les données à l'intérieur en cas de situation d'échec d'instance. Cependant, il est gratuit et plus rapide car le volume d'instance est lié au serveur physique sur lequel la machine virtuelle s'exécute.


2

Pour quelqu'un de nouveau dans tout cela et s'il a atterri accidentellement ici

À partir de maintenant, toutes les AMI dans la section de démarrage rapide sont soutenues par EBS

entrez la description de l'image ici

Il y a aussi une bonne explication dans la documentation officielle pour la différence entre EBS et Instance Store

et cette image résume assez bien entrez la description de l'image ici


0

Si vous exécutez plusieurs instances et attribuez un service planifié d'instance AWS comme l'une de vos priorités pour éviter les frais inattendus , je vous recommande de ne pas utiliser le magasin d'instances .

Comme expliqué sur la documentation des volumes EBS et la réponse de j2d3 et Siddharth Sharma, le magasin d'instances peut fonctionner aussi longtemps que vous le souhaitez, mais il ne peut pas être arrêté . Signifie que le service ne peut pas être planifié par un démarrage / arrêt automatique ou une récupération d'instance .

De plus, pour ce type de schéma, il n'y a aucun avantage à utiliser EBS Backed on Elastic Beanstalk car il est conçu pour garantir que toutes les ressources dont vous avez besoin continuent de fonctionner . Il fera toujours relancer automatiquement tous les services que vous arrêtez. entrez la description de l'image ici En examinant tout le reste , sur les charges totales d'utilisation du VPC , EBS et ELB ajoutées à EC2-Classic , l' EC2-VPC avec ELB est principalement le meilleur choix où, contrairement à EC2-Classic , une instance arrêtée conserve son élastique associé Adresses IPet le volume EBS est stocké automatiquement.

En conclusion , en prenant l'essentiel de votre question:

il semble que l'EBS soit bien plus utile (arrêt, démarrage, persistance + meilleure vitesse) à relativement peu de différence de coût ...?

La réponse est oui mais si votre instance est basée sur EBS, elle peut être arrêtée. Il restera dans votre compte, vous ne serez pas facturé pour cela . Vous serez facturé uniquement le volume mais EBS est facturé toutes les heures . Vous pouvez également considérer que parmi tous les types disponibles, vous avez la possibilité de redimensionner le volume EBS .

Outre les avantages déjà énumérés par Eric , il faut également savoir qu'en termes de coût, S3 peut ou non être moins cher qu'EBS . Je conviens que la différence de coût est relativement faible si vous continuez à exécuter les deux types d'instance sur la même plate-forme et la même architecture de l'application tout le temps.

Cependant, s'il existe un scénario pour exécuter l'application sur un service à moindre coût, tirez toutes les tâches non gérées et attribuez-les au VPC / EBS via un pipeline ou lambda dans un court laps de temps, par exemple <1 heure par jour, ce qui est impossible à faire lorsque vous utiliser un magasin d'instances , alors ce sera une autre histoire.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.