Avantages d’EBS par rapport au magasin d’instance (et vice-versa)

L’essentiel est que vous devez presque toujours utiliser des instances sauvegardées par EBS.

Voici pourquoi

• Les instances sauvegardées EBS peuvent être définies de sorte qu’elles ne puissent pas être (accidentellement) terminées via l’API.
• Les instances sauvegardées par EBS peuvent être arrêtées lorsque vous ne les utilisez pas et reprenez quand vous en avez besoin à nouveau (par exemple, en mettant un PC virtuel en pause), au moins avec des modèles économisant beaucoup plus que quelques dizaines de Go de stockage EBS.
• Les instances sauvegardées par EBS ne perdent pas leur stockage d’instance lorsqu’elles se bloquent (ce n’est pas obligatoire pour tous les utilisateurs, mais rend la récupération beaucoup plus rapide)
• Vous pouvez redimensionner dynamicment le stockage des instances EBS.
• Vous pouvez transférer le stockage de l’instance EBS sur une nouvelle instance (utile si le matériel sur Amazon sur lequel vous exécutez devient instable ou meurt, ce qui se produit de temps en temps)
• Il est plus rapide de lancer une instance sauvegardée EBS car il n’est pas nécessaire de récupérer l’image depuis S3.
• Si le matériel dont votre instance EBS est planifiée pour la maintenance , l’arrêt et le démarrage de l’instance migre automatiquement vers le nouveau matériel. J’ai également pu déplacer une instance soutenue par EBS sur un matériel défaillant en arrêtant l’instance et en la relançant (votre kilométrage peut varier en fonction du matériel défectueux).

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

EBS peut toujours échouer – pas une solution miracle

N’oubliez pas que toute infrastructure en nuage peut échouer à tout moment. Planifiez votre infrastructure en conséquence. Bien que les instances basées sur EBS fournissent un certain niveau de durabilité par rapport aux instances de stockage éphémères, elles peuvent et doivent échouer. Avoir une AMI à partir de laquelle vous pouvez lancer de nouvelles instances selon vos besoins, sauvegarder vos données importantes (bases de données, par exemple) et, si votre budget le permet, exécuter plusieurs instances de serveurs pour l’équilibrage de charge et la redondance ).

Quand ne pas le faire

À certains moments, il peut être plus économique d’obtenir des E / S plus rapides sur les instances du magasin d’instances. Il fut un temps où c’était certainement vrai. Maintenant, il existe de nombreuses options pour le stockage EBS, répondant à de nombreux besoins. Les options et leurs prix évoluent constamment au fur et à mesure que la technologie évolue. Si vous avez un nombre important de cas qui sont vraiment jetables (ils n’affectent pas beaucoup votre entreprise s’ils s’en vont), faites le calcul des coûts par rapport aux performances. Les instances basées sur EBS peuvent également mourir à tout moment, mais mon expérience pratique est que EBS est plus durable.

99% de notre configuration AWS est recyclable. Donc, pour moi, ce n’est pas grave si je résilie une instance – rien n’est jamais perdu. Par exemple, mon application est automatiquement déployée sur une instance à partir de SVN, nos journaux sont écrits sur un serveur Syslog central.

Le seul avantage du stockage d’instance que je vois est la réduction des coûts. Sinon, les instances sauvegardées par EBS sont gagnantes. Eric a mentionné tous les avantages.

[2012-07-16] Je dirais que cette réponse est très différente aujourd’hui.

Au cours de l’année écasting, je n’ai pas eu de bonne expérience avec les instances appuyées par EBS. Les dernières temps d’arrêt sur AWS ont en grande partie détruit EBS.

Je suppose qu’un service comme RDS utilise également une sorte d’EBS et que cela semble fonctionner pour la plupart. Sur les cas que nous gérons nous-mêmes, nous avons éliminé EBS dans la mesure du possible.

Débarrasser une extension où nous avons déplacé un cluster de firebase database sur fer (= matériel réel). Le seul élément restant dans notre infrastructure est un serveur de firebase database où nous répartissons plusieurs volumes EBS dans un RAID logiciel et effectuons des sauvegardes deux fois par jour. Tout ce qui pourrait être perdu entre les sauvegardes, nous pouvons vivre avec.

EBS est une technologie quelque peu floue car elle est essentiellement un volume réseau: un volume attaché à votre serveur à distance. Je ne nie pas le travail effectué avec ce produit – c’est un produit étonnant, car le stockage persistant essentiellement illimité n’est qu’un appel API. Mais cela ne convient guère aux scénarios dans lesquels les performances d’E / S sont essentielles.

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

Plus l’instance est grande, mieux c’est. Mieux vaut ici dans la raison .

Lorsque la persistance est requirejse, je conseille toujours aux gens d’utiliser quelque chose comme S3 pour centraliser entre les instances. S3 est un service très stable. Ensuite, automatisez votre configuration d’instance au point où vous pouvez démarrer un nouveau serveur et le préparer lui-même. Ensuite, il n’est pas nécessaire d’avoir un stockage réseau qui dure plus longtemps que l’instance.

Dans l’ensemble, je ne vois aucun avantage pour les instances adossées à EBS. Je préfère append une minute au bootstrap, puis exécuter avec un potentiel SPOF.

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

Eric a très bien réussi. Nous ( Bitnami ) sums un fournisseur populaire d’AMI gratuites pour les applications et les frameworks de développement populaires (PHP, Joomla, Drupal, vous avez l’idée). Je peux vous dire que les AMI adossées à EBS sont beaucoup plus populaires que celles soutenues par S3. En général, je pense que les instances basées sur S3 sont utilisées pour les tâches dissortingbuées, limitées dans le temps (par exemple, le traitement de données à grande échelle) où, si une machine tombe en panne, une autre est simplement lancée. Les systèmes AMIS adossés à EBS ont tendance à être utilisés pour les tâches serveur «traditionnelles», telles que les serveurs Web ou de firebase database qui conservent leur é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 en cours d’exécution, ce qui vous permet 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 à ma dernière position. Maintenant, dans mon nouveau travail, je suis en train de passer par le même processus que lors de mon dernier travail … reconstruire toutes leurs AMI pour les instances sauvegardées par EBS – et éventuellement comme machines 32 bits (moins chères mais 64 machines).

Les instances sauvegardées EBS se lancent suffisamment rapidement pour que vous puissiez commencer à utiliser l’ API Amazon AutoScaling, qui vous permet d’utiliser les mésortingques CloudWatch pour déclencher le lancement d’instances supplémentaires et les enregistrer sur ELB (Elastic Load Balancer). ne sont plus nécessaires.

Ce type d’autoscaling dynamic est l’object de l’AWS – où les économies réelles d’infrastructure informatique peuvent entrer en ligne de compte. Il est quasiment impossible d’effectuer une mise à l’échelle automatique avec les anciennes instances sauvegardées par “InstanceStore”.

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é supérieur , nous vous recommandons d’utiliser des volumes Amazon EBS ou de sauvegarder les données sur Amazon S3.

Accent mis à moi.

Je fais plus d’ parsings de données que d’hébergement Web, donc la persistance ne compte pas autant pour moi que pour un site Web. Compte tenu de la distinction faite par Amazon elle-même, je ne supposerais pas que EBS est bon pour tout le monde.

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

Le “matériel” EC2

Lorsqu’une instance EC2 est lancée, une machine virtuelle est réservée à l’instance à exécuter. Cette machine virtuelle a des spécifications particulières en fonction du type d’instance: processeur 32 bits ou 64 bits, nombre de cœurs virtuels, taille du disque dur, etc. Des détails sur les spécifications de l’instance sont disponibles à l’ adresse http://aws.amazon.com. / ec2 / # instance .

Lorsque votre instance EC2 est dans un état “en cours d’exécution”, cela signifie qu’elle s’exécute sur la machine virtuelle, et c’est ce qui vous est facturé.

Le disque dur de la machine virtuelle est considéré comme “éphémère”. Le terme “éphémère” vient du mot grec “ephemeros” qui signifie “ne dure qu’un jour”. Tout ce qui est sur un disque dur doit être considéré comme temporaire. À moins que les données ne soient copiées du disque dur, si la machine virtuelle est arrêtée, les données sont perdues. Cela inclut les données, les logiciels et même un système d’exploitation qui réside sur ces disques durs.

Amazon Web Services fournit des instances EC2 avec deux types de périphériques racine: “EBS-backed” et “instance store”.

Instances du “magasin d’instances”

Une instance de “magasin d’instances” est une instance EC2 dont le périphérique racine réside sur le disque dur de la machine virtuelle. Lorsque l’instance est créée, l’AMI de base est copiée sur le disque dur de la machine virtuelle et lancée. L’instance peut fonctionner aussi longtemps que vous le souhaitez, mais elle ne peut pas être arrêtée. Comme le périphérique racine de l’instance est le disque dur réel, il est “bloqué” sur le matériel, et la seule chose que vous pouvez faire est de terminer l’instance. Si vous faites cela, l’instance est supprimée pour ne jamais être récupérée. Vous courez également le risque que si le matériel de la machine virtuelle tombe en panne, vous perdiez également tout ce qui se trouve sur le disque dur.

Si vous lancez une instance de “magasin d’instance”, préparez-vous à le laisser fonctionner jusqu’à ce que vous en ayez complètement terminé. Notez que vous serez facturé à partir du moment où l’instance est démarrée, jusqu’au moment où elle est terminée.

Instances “soutenues par EBS”

Une instance “EBS-backed” est une instance EC2 qui utilise un volume EBS comme périphérique racine. Les volumes EBS sont des lecteurs «virtuels» redondants, qui ne sont liés à aucun matériel particulier. Ils sont toutefois limités à une zone de disponibilité EC2 particulière. Cela signifie qu’un volume EBS peut se déplacer d’un morceau à un autre dans la même zone de disponibilité. Vous pouvez considérer les volumes EBS comme une sorte de stockage en réseau.

En cas de défaillance du matériel de la machine virtuelle, le volume EBS peut simplement être déplacé vers une autre machine virtuelle et relancé. En théorie, vous ne perdrez aucune donnée.

Un autre avantage est que les volumes EBS peuvent être facilement sauvegardés et dupliqués. Ainsi, vous pouvez effectuer des sauvegardes simples de vos volumes, créer de nouveaux volumes et lancer de nouvelles instances EC2 en fonction de ces volumes dupliqués.

Le plus grand avantage des instances “sauvegardées par EBS” sur les instances de “magasin d’instance” est probablement qu’elles peuvent être arrêtées. Lorsque vous faites cela, la machine virtuelle est arrêtée et le volume EBS est stocké pour une récupération ultérieure. Le matériel est alors disponible pour que quelqu’un d’autre l’utilise. De plus, pendant cette période, vous ne payez pas les frais d’exécution de l’instance EC2. Mais vous êtes facturé pour le stockage EBS. Lorsque vous voulez que l’instance soit à nouveau exécutée, vous devez la redémarrer. Une nouvelle machine virtuelle est réservée, votre volume EBS est connecté et votre instance est démarrée.

Mais qu’en est-il des disques durs de la machine virtuelle?

Oui, il est possible d’utiliser ces disques durs, même si votre instance EC2 est “soutenue par EBS”. Par défaut, ils ne sont pas disponibles. Si vous utilisez les programmes de ligne de commande pour lancer votre instance, vous pouvez utiliser l’option “-b” de la commande ec2-run-instances pour associer les lecteurs “d’instance store” à votre instance EC2.

Avoir ces lecteurs disponibles peut être bénéfique si vous souhaitez stocker des données temporaires. L’access en lecture et en écriture doit être plus rapide que la lecture et l’écriture sur un volume EBS, car vous n’envoyez pas de données sur le réseau. De plus, vous ne serez pas facturé pour le transfert de données ou le stockage de données. Mais cela ne fonctionne que si les données peuvent être perdues à tout moment.

Source: https://skeddly.desk.com/customer/portal/articles/1346918-ebs-backed-versus-instance-store

EBS est comme le disque virtuel d’une VM:

• Durable, les instances sauvegardées par EBS peuvent être librement démarrées et arrêtées (économie d’argent)
• Peut être photographié à tout moment pour obtenir des sauvegardes ponctuelles
• Les AMI peuvent être créées à partir des 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 mis en réseau, dans les cas normaux, les E / S EBS se font au désortingment de la bande passante réseau (sauf pour les instances optimisées pour EBS, qui ont une bande passante EBS distincte)
• Possède des E / S limitées par seconde IOPS. Même les E / S provisionnées atteignent quelques milliers d’IOPS
• Fragile. Dès que l’instance est arrêtée, vous perdez tout dans le stockage de l’instance.

Voici où les utiliser:

• Utiliser EBS pour la partition de système d’exploitation de sauvegarde et le stockage permanent (données de firebase database, journaux critiques, configuration d’application)
• Utilisez le stockage d’instance pour les données en cours de traitement, les journaux non critiques et l’état d’application transitoire. Exemple: stockage externe, fichiers temporaires, etc.
• Le stockage d’instance peut également être utilisé pour les données critiques en termes de performances, lorsqu’il existe une réplication entre les instances (bases de données NoSQL, systèmes de files d’attente / messages dissortingbué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 en entrée et résultats traités, ou pour les données statiques utilisées par chaque système lors de la mise en service.
• Utiliser des AMI pour des serveurs pré-préparés et pouvant être lancés

La plupart des utilisateurs choisissent d’utiliser l’instance sauvegardée EBS car elle est à l’état de veille. Il est plus sûr car tout ce que vous avez en cours d’exécution et installé à l’intérieur de celui-ci survivra à l’arrêt / arrêt ou à toute défaillance d’instance.

Le magasin d’instances est sans état, vous le perdez avec toutes les données qu’il contient en cas de défaillance d’une instance. Toutefois, il est gratuit et plus rapide car le volume de l’instance est lié au serveur physique sur lequel la machine virtuelle s’exécute.

Pour quelqu’un de nouveau à tout cela et si accidentellement atterri ici

A ce jour, toutes les AMI de la section Quickstart sont sauvegardées par EBS

Il y a aussi une bonne explication à la doc officielle pour la différence entre EBS et le magasin d’instance

& cette image résume bien

Si vous exécutez plusieurs instances et atsortingbuez une priorité à un service planifié d’AWS Instance pour éviter les frais inattendus , je vous déconseille d’utiliser le magasin d’instances .

Comme expliqué dans 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, l’utilisation d’ EBS Backed sur Elastic Beanstalk ne présente aucun avantage, car elle est conçue pour garantir que toutes les ressources dont vous avez besoin continuent à fonctionner . Il fera toujours un redémarrage automatique de tous les services que vous arrêtez. En examinant tout le rest , sur le total des frais d’utilisation des VPC , EBS et ELB ajoutés à EC2-Classic , l’ EC2-VPC avec ELB est généralement le meilleur choix, contrairement à EC2-Classic , une instance arrêtée conserve son Elastic Les adresses IP et le volume EBS sont stockés automatiquement.

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

il semble que l’EBS soit beaucoup 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 restra dans votre compte, vous ne serez pas facturé pour cela . Vous ne facturerez que le volume, mais EBS est chargé à l’heure . 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 être ou non moins cher qu’EBS . Je suis d’accord que cela ne représente qu’une différence de coût relativement faible si vous continuez à utiliser les deux types d’instance dans la même plate-forme et l’architecture de l’application tout le temps.

Toutefois, s’il existe un scénario pour exécuter l’application sur un service à moindre coût, extrayez toutes les tâches non gérées et leur rôle vers le VPC / EBS via un pipeline ou un lambda , par exemple <1 heure par jour, impossible à faire. utiliser un magasin d’instances , ce sera une autre histoire.