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

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?

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.

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.

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.

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)

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.

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.

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

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.

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

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

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. 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.