¿Se puede adjuntar Amazon EBS a varias instancias?

Actualmente utilizamos múltiples servidores web que acceden a un servidor mysql y servidor de archivos. En cuanto a pasar a la nube, ¿puedo usar esta misma configuración y adjuntar el EBS a varias instancias de máquinas o qué otra solución?

ACTUALIZACIÓN (abril de 2015) : para este caso de uso, debe comenzar a mirar el nuevo Sistema de archivos elásticos de Amazon (EFS) , que está diseñado para conectarse de manera múltiple exactamente de la manera que desee. La diferencia clave entre EFS y EBS es que proporcionan diferentes abstracciones: EFS expone el protocolo NFSv4, mientras que EBS proporciona acceso de E / S de bloque sin procesar.

A continuación encontrará mi explicación original de por qué no es posible montar de forma segura un dispositivo de bloque sin procesar en varias máquinas.

POSTE ORIGINAL (2011):

Incluso si pudiera obtener un volumen EBS adjunto a más de una instancia, sería un _REALLY_BAD_IDEA_. Para citar a Kekoa, "esto es como usar un disco duro en dos computadoras a la vez"

¿Por qué es una mala idea? ... La razón por la que no puede adjuntar un volumen a más de una instancia es que EBS proporciona una abstracción de "almacenamiento en bloque" sobre la cual los clientes ejecutan un sistema de archivos como ext2 / ext3 / etc. La mayoría de estos sistemas de archivos (p. Ej., Ext2 / 3, FAT, NTFS, etc.) están escritos asumiendo que tienen acceso exclusivo al dispositivo de bloque. Dos instancias que acceden al mismo sistema de archivos casi seguramente terminarían en lágrimas y corrupción de datos.

En otras palabras, el montaje doble de un volumen EBS solo funcionaría si estuviera ejecutando un sistema de archivos de clúster diseñado para compartir un dispositivo de bloque entre varias máquinas. Además, incluso esto no sería suficiente. EBS necesitaría ser probado para este escenario y asegurar que proporciona las mismas garantías de consistencia que otras soluciones de dispositivos de bloques compartidos ... es decir, que los bloques no se almacenan en caché en niveles intermedios no compartidos como el núcleo Dom0, la capa Xen, y núcleo DomU. Y luego están las consideraciones de rendimiento de la sincronización de bloques entre múltiples clientes: la mayoría de los sistemas de archivos en clúster están diseñados para trabajar en SAN dedicadas de alta velocidad, no en un ethernet básico de mejor esfuerzo. Suena muy simple, pero lo que estás pidiendo es algo muy trivial.

Alternativamente, vea si su escenario de intercambio de datos puede ser NFS, SMB / CIFS, SimpleDB o S3. Todas estas soluciones usan protocolos de capa superior que están destinados a compartir archivos sin tener un subsistema de dispositivo de bloque compartido. Muchas veces, tal solución es en realidad más eficiente.

En su caso, aún puede tener una única instancia de MySql / servidor de archivos al que acceden varios front-end web. Ese servidor de archivos podría almacenar sus datos en un volumen EBS, lo que le permite realizar copias de seguridad de instantáneas nocturnas. Si se pierde la instancia que ejecuta el servidor de archivos, puede desconectar el volumen EBS y volver a conectarlo a una nueva instancia de servidor de archivos y volver a ejecutarlo en minutos.

"¿Hay algo como S3 como sistema de archivos?" - si y no. Sí, hay soluciones de terceros como s3fs que funcionan "bien", pero aún así tienen que hacer llamadas de servicio web relativamente caras para cada lectura / escritura. Para un directorio de herramientas compartidas, funciona muy bien. Para el tipo de uso de FS en clúster que se ve en el mundo de HPC, no es una posibilidad. Para hacerlo mejor, necesitaría un nuevo servicio que proporcione un protocolo binario orientado a la conexión, como NFS. Ofrecer un sistema de archivos de este tipo con un rendimiento y un comportamiento razonables sería un GRAN complemento de funciones para EC2. Durante mucho tiempo he sido un defensor de Amazon para construir algo así.

Actualización (2020) ¡Ahora es posible!

Esto es posible ahora con los tipos de instancia más nuevos que se ejecutan en AWS Nitro dentro de la misma zona de disponibilidad. Hay algunas advertencias, pero esto es excelente para ciertos casos de uso que necesitan la velocidad de EBS y donde EFS no es factible.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

Publicación original (2009)

No, esto es como usar un disco duro en dos computadoras.

Si desea compartir datos, puede configurar un servidor al que puedan acceder todas sus instancias. Si desea un área de almacenamiento simple para todas sus instancias, puede usar el servicio de almacenamiento S3 de Amazon para almacenar datos distribuidos y escalables.

Al pasar a la nube, puede tener exactamente la misma configuración, pero posiblemente puede reemplazar el servidor de archivos con S3, o hacer que todas sus instancias se conecten a su servidor de archivos.

Tiene muchas opciones, pero compartir un disco duro entre instancias probablemente no sea la mejor opción.

No, según los documentos de EBS: "Un volumen solo se puede adjuntar a una instancia a la vez".

¿Cómo estás usando el almacenamiento compartido actualmente? Si es solo para servir archivos desde el servidor de archivos, ¿ha considerado configurar un sistema para poder enviar ciertas solicitudes a un proceso en el servidor de archivos en lugar de hacer que los servidores web sirvan esos archivos?

Estoy bastante seguro de que no puede, pero puede clonar un EBS y adjuntarlo a otra instancia.

Esto es útil para conjuntos de datos fijos o para probar datos 'reales', pero no permite que más de 1 instancia opere en un único almacén de bloques

Múltiples servidores web que acceden a MySQL Server y File Server es normal en AWS. Algunas de las mejores prácticas a seguir para la arquitectura mencionada anteriormente son:

Punto 1) MySQL en EC2 se puede configurar como maestro-esclavo en modo asíncrono / semi-sincronización en AWS. Se recomienda EBS-OPT + PIOPS en RAID 0 para DB de alto rendimiento

Punto 2) Alternativamente, puede usar el modo Amazon RDS + Multi-AZ. Para el escalado de lectura, se pueden conectar múltiples réplicas de lectura RDS a MySQL RDS.

Punto 3) El volumen EBS no se puede conectar a múltiples EC2 simultáneamente. Puede crear un servidor de archivos basado en GlusterFS en Amazon EC2 utilizando EBS. Varios servidores web pueden comunicarse con un solo GlusterFS simultáneamente en AWS infra.

Punto 4) En caso de que su aplicación pueda integrarse con S3 como almacén de archivos, entonces es preferible debido a la estabilidad que aporta a la arquitectura. También puede acceder a S3 utilizando herramientas como S3fuse, así como desde su aplicación.

EBS acaba de anunciar que esto es posible: https://aws.amazon.com/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

Hay algo en el mundo de TI conocido como Clustered Filesystem, Redhat GFS, Oracle OCFS2, Veritas CFS ...

La respuesta corta es un "No" categórico. Otros lo han dicho anteriormente.

Los que dijeron "sí" no respondieron la pregunta, sino una pregunta diferente. Si EFS es solo un servicio NFS, entonces no es la respuesta a la pregunta como se indicó originalmente. Y no importa si EFS se "implementa en todas las zonas" o no, porque puedes hacer tu propia instancia de NFS y hacer que varios servidores monten NFS. Eso no es nada nuevo, ya lo hicimos en 1992. SMB y sshfs, todas estas son solo formas de montar unidades como un sistema de archivos remoto.

Los que dijeron "por qué querrías hacer eso" o "todo terminará en lágrimas" están equivocados. Hemos estado montando múltiples discos en múltiples servidores durante décadas. Si alguna vez trabajó con una SAN (Red de área de almacenamiento), la capacidad de conectar el mismo dispositivo a múltiples nodos, generalmente a través de FibreChannel SAN, es completamente normal. Por lo tanto, cualquiera que haya ejecutado servidores hace una década antes de que los servidores de virtualización / nube se volvieran ubicuos tiene cierta exposición a eso.

Pronto hubo sistemas de archivos en clúster donde dos sistemas podían leer y escribir exactamente en el mismo volumen. Creo que esto comenzó con el tiempo VAX y Alpha VMS en la historia ya. Los sistemas de archivos en clúster utilizan un esquema distribuido de exclusión mutua para poder manipular bloques directamente.

La ventaja de montar el mismo disco en múltiples nodos es la velocidad y la reducción de puntos únicos de fallas.

Ahora, los sistemas de archivos en clúster no se han vuelto muy populares en el negocio de alojamiento de "consumidores", eso es cierto. Y son complicados y tienen algunas dificultades. Pero ni siquiera necesita un sistema de archivos en clúster para utilizar un disco conectado a múltiples nodos de cómputo. ¿Qué pasa si quieres una unidad de solo lectura? ¡Ni siquiera necesita un sistema de archivos en clúster! Simplemente coloca en su / etc / fstab el mismo dispositivo físico que solo lectura (ro). Luego monta en 2 o 10 servidores EC2 y todos pueden leer directamente desde ese dispositivo.

Hay un caso de uso obvio para esto en el mundo de los servidores en la nube cuando se construyen granjas de gran escala. Puede tener todo el disco del sistema preparado y usar un disco de arranque y configuración muy pequeño para cada uno de los servidores. Incluso puede hacer que todos arranquen desde el mismo disco de arranque, y justo antes de volver a montar / en modo lectura / escritura, puede insertar un Union-FS con 3 capas:

1. El disco principal del sistema de solo lectura, con arranque, kernel e instalación de usuario
2. Un sistema de archivos de configuración, con solo unos pocos archivos (principalmente en / etc) que son específicos del servidor individual. Este disco puede ser escrito por otro servidor para prepararse para arrancar una nueva instancia. Los archivos de ejemplo aquí serían / ​​etc / hostname y muy pocos archivos de configuración que deben permanecer diferentes por nodo.
3. El disco grabable, que puede que no necesite en absoluto, podría ser simplemente / tmp como un sistema de archivos de memoria.

Entonces, sí, la pregunta tenía mucho sentido, y desafortunadamente la respuesta es (todavía) "No". Y ningún NFS no es un gran reemplazo para ese caso de uso, ya que penaliza toda la actividad de lectura del disco del sistema. Sin embargo, el arranque en red desde un disco del sistema NFS es la única alternativa para implementar el caso de uso que describí anteriormente. Desafortunadamente, desde configurar el agente de arranque de red y NFS es mucho más complicado que simplemente acceder al mismo dispositivo de bloque físico.

PD: Me hubiera gustado presentar una versión más corta de esto como comentarios, pero no puedo debido al límite tonto de 51 puntos de crédito, así que tengo que escribir una respuesta con el mismo "No" esencial pero incluir mi punto de por qué esto es Una pregunta relevante que no ha recibido una respuesta merecida.

PPS: Acabo de encontrar a alguien en StackExchange que menciona iSCSI. iSCSI es algo así como NFS, pero lógicamente como una SAN FibreChannel. Puede acceder (y compartir) dispositivos de bloque físico. Haría que el uso compartido del disco de arranque sea más fácil, por lo que no necesita configurar el arranque de la red de arranque, lo que puede ser complicado. Pero luego, en AWS, tampoco hay arranque de red disponible.

Aunque EBS anteriormente solo permitía adjuntar una sola instancia de EC2 a un volumen dado, ahora es posible la conexión múltiple, al menos para volúmenes io1. Para obtener más información, consulte esta publicación de blog de AWS .

¿Por qué no creará una instancia con volumen y sshfs para ese volumen en otras instancias?

Puede usar totalmente una unidad en varios servidores en AWS. Utilizo sshfs para montar una unidad externa y compartirla con varios servidores en EC2.

La razón por la que necesitaba conectar una sola unidad a múltiples servidores es tener un solo lugar para colocar todas mis copias de seguridad antes de eliminarlas localmente.