Beneficios de EBS vs. instancia-tienda (y viceversa)

No estoy seguro de qué beneficios obtengo de EBS frente a instancia-tienda para mis instancias en Amazon EC2. En todo caso, parece que EBS es mucho más útil (detener, iniciar, persistir + mejor velocidad) con una diferencia de costo relativamente pequeña … Además, ¿hay alguna métrica en cuanto a si más personas están usando EBS ahora que está disponible, considerando que todavía es relativamente nuevo?

La conclusión es que casi siempre debería usar instancias respaldadas por EBS.

Este es el por qué

  • Las instancias respaldadas de EBS pueden configurarse para que no puedan (accidentalmente) rescindirse a través de la API.
  • Las instancias respaldadas de EBS se pueden detener cuando no las está usando y se reanudan cuando las necesita de nuevo (como pausar una PC virtual), al menos con mis patrones de uso ahorrando mucho más dinero de lo que gasto en unas pocas docenas de GB de almacenamiento EBS.
  • Las instancias respaldadas de EBS no pierden su almacenamiento de instancias cuando fallan (no es un requisito para todos los usuarios, pero hace que la recuperación sea mucho más rápida)
  • Puede cambiar el tamaño dinámicamente del almacenamiento de instancias de EBS.
  • Puede transferir el almacenamiento de instancia de EBS a una nueva instancia (útil si el hardware en Amazon en el que se ejecuta se vuelve escamoso o muere, lo que sucede de vez en cuando)
  • Es más rápido lanzar una instancia respaldada por EBS porque la imagen no tiene que ser captada desde S3.
  • Si el hardware de su instancia respaldada por EBS está progtwigdo para mantenimiento , la detención e inicio de la instancia migra automáticamente al nuevo hardware. También pude mover una instancia respaldada por EBS en un hardware fallido mediante la detención forzosa de la instancia y su inicio nuevamente (su millaje puede variar en hardware fallado).

Soy un gran usuario de Amazon y cambié todas mis instancias al almacenamiento respaldado de EBS tan pronto como la tecnología salió de la versión beta. He estado muy feliz con el resultado.

EBS aún puede fallar, no es una bala de plata

Tenga en cuenta que cualquier pieza de infraestructura basada en la nube puede fallar en cualquier momento. Planifica tu infraestructura en consecuencia. Si bien las instancias respaldadas por EBS brindan cierto nivel de durabilidad en comparación con las instancias de almacenamiento efímeras, pueden fallar y fallan. Tener un AMI desde el que pueda iniciar nuevas instancias según sea necesario en cualquier zona de disponibilidad, hacer una copia de seguridad de sus datos importantes (p. Ej. Bases de datos) y si su presupuesto lo permite, ejecutar múltiples instancias de servidores para balanceo de carga y redundancia (idealmente en múltiples zonas de disponibilidad )

Cuando no

En algunos momentos, puede ser más barato lograr IO más rápido en las instancias del Instance Store. Hubo un momento en que era ciertamente cierto. Ahora hay muchas opciones para el almacenamiento de EBS, que satisfacen muchas necesidades. Las opciones y sus precios evolucionan constantemente a medida que cambia la tecnología. Si tiene una cantidad significativa de instancias que son realmente desechables (no afectan mucho a su negocio si simplemente desaparecen), haga los cálculos de costo versus rendimiento. Las instancias respaldadas por EBS también pueden morir en cualquier momento, pero mi experiencia práctica es que EBS es más duradero.

El 99% de nuestra configuración de AWS es reciclable. Entonces, para mí, realmente no importa si termino una instancia, nada se pierde nunca. Por ejemplo, mi aplicación se implementa automáticamente en una instancia de SVN, nuestros registros se escriben en un servidor syslog central.

El único beneficio del almacenamiento de instancias que veo son los ahorros de costos. De lo contrario, las instancias respaldadas por EBS ganan. Eric mencionó todas las ventajas.


[2012-07-16] Hoy diría que esta respuesta es muy diferente.

No he tenido ninguna buena experiencia con instancias respaldadas por EBS en el último año más o menos. Los últimos tiempos de inactividad en AWS arruinaron bastante a EBS también.

Supongo que un servicio como RDS también utiliza algún tipo de EBS y que parece funcionar en su mayor parte. En las instancias que manejamos nosotros mismos, nos hemos librado de EBS siempre que sea posible.

Deshacerse en una extensión en la que movimos un clúster de base de datos a plancha (= hardware real). La única pieza que queda en nuestra infraestructura es un servidor de bases de datos donde rastreamos múltiples volúmenes de EBS en un RAID de software y copias de seguridad dos veces al día. Lo que sea que se pierda entre las copias de seguridad, podemos vivir con.

EBS es una tecnología un tanto falsa, ya que se trata esencialmente de un volumen de red: un volumen conectado a su servidor desde remoto. No estoy negando el trabajo hecho con él, es un producto asombroso ya que el almacenamiento persistente esencialmente ilimitado es solo una llamada API de distancia. Pero no es apta para escenarios donde el rendimiento de E / S es clave.

Y además de cómo se comporta el almacenamiento en red, toda la red se comparte en instancias EC2. Cuanto menor sea una instancia (por ejemplo, t1.micro, m1.small) peor será porque las interfaces de red en el sistema host real se comparten entre varias máquinas virtuales (= su instancia EC2) que se ejecutan en la parte superior.

La instancia más grande que obtienes, mejor se pone, por supuesto. Mejor aquí significa dentro de lo razonable .

Cuando se requiere persistencia, siempre aconsejo a las personas que utilicen algo como S3 para centralizar entre instancias. S3 es un servicio muy estable. Luego, automatice la configuración de su instancia a un punto donde pueda iniciar un nuevo servidor y se prepare solo. Entonces no hay necesidad de tener un almacenamiento de red que viva más tiempo que la instancia.

Así que, en general, no veo beneficio alguno para las instancias respaldadas por EBS. Prefiero agregar un minuto al bootstrap, luego ejecutar con un SPOF potencial.

Nos gusta instancia-tienda. Nos obliga a que nuestras instancias sean completamente reciclables, y podemos automatizar fácilmente el proceso de construir un servidor desde cero en un AMI determinado. Esto también significa que podemos cambiar fácilmente las AMI. Además, EBS todavía tiene problemas de rendimiento de vez en cuando.

Eric casi lo clavó. Nosotros ( Bitnami ) somos un proveedor popular de AMI gratuitas para aplicaciones populares y marcos de desarrollo (PHP, Joomla, Drupal, ya entiendes). Puedo decirles que las AMI respaldadas por EBS son mucho más populares que las respaldadas por S3. En general, creo que las instancias respaldadas por s3 se usan para trabajos distribuidos de tiempo limitado (por ejemplo, procesamiento de datos a gran escala) donde si una máquina falla, otra simplemente se centrifuga. El AMIS respaldado por EBS tiende a ser utilizado para tareas del servidor ‘tradicionales’, como servidores web o de bases de datos que mantienen el estado localmente y por lo tanto requieren que los datos estén disponibles en caso de fallas.

Un aspecto que no vi mencionar es el hecho de que puede tomar instantáneas de una instancia respaldada por EBS mientras se ejecuta, lo que le permite tener copias de seguridad de su infraestructura muy rentables (las instantáneas están basadas en bloques e incrementales)

He tenido exactamente la misma experiencia que Eric en mi última posición. Ahora en mi nuevo trabajo, estoy pasando por el mismo proceso que realicé en mi último trabajo … reconstruyendo todas sus AMI para instancias respaldadas por EBS, y posiblemente como máquinas de 32 bits (más baratas), pero no puedo usar el mismo AMI en 32 y 64 máquinas).

Las instancias respaldadas de EBS se inician lo suficientemente rápido para que pueda comenzar a utilizar la API de AutoScaling de Amazon que le permite usar las métricas de CloudWatch para activar el lanzamiento de instancias adicionales y registrarlas en ELB (Elastic Load Balancer) y también apagarlas cuando ya no es requerido.

Este tipo de autoscaling dynamic es de lo que se trata AWS, donde los ahorros reales en la infraestructura de TI pueden entrar en juego. Es prácticamente imposible hacer autoescalado a la derecha con las antiguas instancias respaldadas por s3 “InstanceStore”.

Estoy empezando a usar EC2 yo mismo, así que no soy un experto, pero la propia documentación de Amazon dice:

le recomendamos que use el almacén de instancias local para obtener datos temporales y, para los datos que requieren un mayor nivel de durabilidad , le recomendamos utilizar los volúmenes de Amazon EBS o hacer una copia de seguridad de los datos en Amazon S3.

Énfasis mío

Hago más análisis de datos que el alojamiento web, por lo que la persistencia no me importa tanto como lo haría para un sitio web. Dada la distinción hecha por Amazon, no asumiría que EBS es adecuado para todos.

Trataré de recordar volver a pesar después de haber usado ambos.

El “Hardware” EC2

Cuando se lanza una instancia de EC2, se reserva una máquina virtual para que se ejecute la instancia. Esa máquina virtual tiene especificaciones particulares según el tipo de instancia: CPU de 32 bits o de 64 bits, número de núcleos virtuales, tamaño del disco duro, etc. Los detalles sobre las especificaciones de la instancia están disponibles en http://aws.amazon.com / ec2 / # instancia .

Cuando su instancia EC2 está en estado “en ejecución”, eso significa que se está ejecutando en la máquina virtual, y esto es por lo que le cobran.

El disco duro de la máquina virtual se considera “efímero”. El término “efímero” proviene de la palabra griega “ephemeros” que significa “dura solo un día”. Cualquier cosa en un disco duro de este tipo debe considerarse temporal. A menos que los datos se copien del disco duro, si la máquina virtual se detiene, entonces los datos se pierden. Esto incluye datos, software e incluso un sistema operativo que reside en esos discos duros.

Amazon Web Services proporciona instancias EC2 con dos tipos de dispositivos raíz: “EBS-backed” y “instance store”.

Instancias de “Instance Store”

Una instancia de “instancia de tienda” es una instancia de EC2 cuyo dispositivo raíz reside en el disco duro de la máquina virtual. Cuando se crea la instancia, la base AMI se copia en el disco duro de la máquina virtual y se inicia. La instancia puede ejecutarse durante el tiempo que desee, pero no se puede detener. Como el dispositivo raíz de la instancia es el disco duro real, está “bloqueado” en el hardware, y lo único que puede hacer es finalizar la instancia. Si hace esto, la instancia se elimina, nunca se recuperará. También corre el riesgo de que si el hardware de la máquina virtual falla, también perderá algo en el disco duro.

Si inicia una instancia de “almacén de instancias”, prepárese para dejarla en ejecución hasta que haya terminado con ella. Tenga en cuenta que se le cobrará desde el momento en que se inicia la instancia, hasta el momento en que finaliza.

Instancias “respaldadas por EBS”

Una instancia “respaldada por EBS” es una instancia de EC2 que utiliza un volumen de EBS ya que es un dispositivo raíz. Los volúmenes de EBS son unidades redundantes, “virtuales”, que no están vinculadas a ningún hardware en particular, sin embargo están restringidas a una zona de disponibilidad EC2 en particular. Esto significa que un volumen de EBS puede pasar de una pieza de hardware a otra dentro de la misma zona de disponibilidad. Puede pensar en los volúmenes de EBS como un tipo de almacenamiento conectado a la red.

Si el hardware de la máquina virtual falla, el volumen de EBS simplemente se puede mover a otra máquina virtual y reiniciarse. En teoría, no perderá ningún dato.

Otro beneficio es que los volúmenes de EBS pueden respaldarse y duplicarse fácilmente. De modo que puede tomar instantáneas de respaldo fáciles de sus volúmenes, crear nuevos volúmenes y lanzar nuevas instancias EC2 basadas en esos volúmenes duplicados.

Probablemente la mayor ventaja que tienen las instancias “respaldadas por EBS” sobre las instancias de “instancias de instancia” es que pueden detenerse. Cuando hace esto, la máquina virtual se apaga y el volumen de EBS se almacena para su posterior recuperación. El hardware está entonces disponible para que otra persona lo use. Además, durante este tiempo, no se le cobrará el cargo de la instancia EC2. Pero se le cobra por el almacenamiento de EBS. Cuando desee que la instancia vuelva a ejecutarse, simplemente vuelva a iniciarla. Se reserva una nueva máquina virtual, se adjunta su volumen de EBS y se inicia su instancia.

Pero, ¿qué pasa con los discos duros de la máquina virtual?

Sí, es posible usar esos discos duros, incluso cuando su instancia EC2 está “respaldada por EBS”. Por defecto, no están disponibles. Si usa los progtwigs de línea de comando para iniciar su instancia, puede usar la opción “-b” en el comando ec2-run-instances para adjuntar las unidades “store de instancia” a su instancia EC2.

Tener estas unidades disponibles puede ser beneficioso si desea almacenar datos temporales. El acceso de lectura y escritura debe ser más rápido que leer y escribir en un volumen de EBS porque no está enviando datos a través de la red. Además, no se le cobrará por la transferencia de datos o el almacenamiento de datos. Pero esto solo funciona si los datos se pueden perder en cualquier momento.

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

EBS es como el disco virtual de una VM:

  • Duradero, las instancias respaldadas por EBS se pueden iniciar y detener de forma gratuita (ahorrando dinero)
  • Se puede tomar una instantánea en cualquier momento para obtener copias de seguridad puntuales
  • Los AMI se pueden crear a partir de instantáneas de EBS, de modo que el volumen de EBS se convierta en una plantilla para los nuevos sistemas.

El almacenamiento de instancias es:

  • Local, por lo general, más rápido
  • Sin conexión de red, en casos normales EBS I / O tiene el costo del ancho de banda de la red (excepto para las instancias optimizadas para EBS, que tienen ancho de banda EBS por separado)
  • Tiene I / O limitada por segundo IOPS. Incluso las E / S aprovisionadas tienen un máximo de miles de IOPS
  • Frágil. Tan pronto como la instancia se detiene, usted pierde todo en el almacenamiento de instancias.

Aquí es donde usar cada uno:

  • Utilice EBS para la partición del SO de respaldo y el almacenamiento permanente (datos de la base de datos, registros críticos, configuración de la aplicación)
  • Utilice el almacenamiento de instancia para datos en proceso, registros no críticos y estado de aplicación transitoria. Ejemplo: almacenamiento de clasificación externo, archivos temporales, etc.
  • El almacenamiento de instancias también se puede usar para datos de rendimiento crítico, cuando hay replicación entre instancias (DB NoSQL, sistemas de cola / mensaje distribuidos y DB con replicación)
  • Utilice S3 para datos compartidos entre sistemas: conjunto de datos de entrada y resultados procesados, o para datos estáticos utilizados por cada sistema cuando se lance.
  • Use AMI para servidores precocidos y ejecutables

La mayoría de las personas elige usar la instancia respaldada por EBS ya que es con estado. Es más seguro porque todo lo que tiene funcionando e instalado dentro de él, sobrevivirá a la detención / detención o cualquier falla en la instancia.

La tienda de instancias no tiene estado, se pierde con todos los datos dentro en caso de una situación de falla de instancia. Sin embargo, es gratis y más rápido porque el volumen de la instancia está vinculado al servidor físico donde se ejecuta la máquina virtual.

Para alguien nuevo en todo esto y si accidentalmente aterrizó aquí

A partir de ahora, todas las AMI en la sección de inicio rápido están respaldadas por EBS

enter image description here

También hay una buena explicación en el documento oficial de la diferencia entre EBS y la tienda Instance

y esta imagen lo resume bastante enter image description here

Si ejecuta varias instancias y asigna un servicio progtwigdo de Instancia de AWS como una de sus prioridades en Evitar cargos inesperados , le recomendaría no utilizar el almacén de instancias .

Como se explica en la documentación de EBS Volumes y la respuesta de j2d3 y Siddharth Sharma, el almacén de instancias puede ejecutarse durante el tiempo que desee, pero no se puede detener . Significa que el servicio no se puede progtwigr mediante un Inicio / Parada automático o Recuperación de instancias .

Además, para este tipo de esquema, tampoco es beneficioso utilizar EBS Backed on Elastic Beanstalk, ya que está diseñado para garantizar que todos los recursos que necesita se sigan ejecutando . Siempre hará un relanzamiento automático de cualquier servicio que detenga. enter image description here Revisando todo el rest , de los cargos totales por usar VPC , EBS y ELB que se agregaron a EC2-Classic , el EC2-VPC con ELB es la mejor opción, a diferencia de EC2-Classic , una instancia detenida conserva su Elastic asociado. Las direcciones IP y el volumen de EBS se almacenan automáticamente.

Como conclusión , tomando la parte principal de su pregunta:

parece que EBS es mucho más útil (detener, iniciar, persistir + mejor velocidad) con una diferencia de costo relativamente pequeña …

La respuesta es sí, pero si su instancia está basada en EBS, se puede detener. Permanecerá en su cuenta, no se le cobrará por ello . Solo se le cobrará el volumen, pero EBS se cobra cada hora . También puede considerar que entre todos los tipos disponibles tiene flexibilidad para Cambiar el tamaño del Volumen de EBS .

Además de los beneficios que ya figuran en la lista de Eric , también deberá tener en cuenta que, en términos de costo, S3 puede ser o no más económico que EBS . Estoy de acuerdo en que hay una diferencia relativamente pequeña en el costo si continúa ejecutando ambos tipos de instancia dentro de la misma plataforma y architecture de la aplicación todo el tiempo.

Sin embargo, si existe un escenario para ejecutar la aplicación en un servicio de menor costo, retire todas las tareas no controladas y ejecútelas a la VPC / EBS a través de una interconexión o lambda dentro de poco tiempo, por ejemplo <1 hora por día, lo que es imposible cuando usted usa un almacén de instancias , entonces será una historia diferente.

    Intereting Posts