Actualmente utilizamos múltiples servidores web que acceden a un servidor mysql y al servidor de archivos. En cuanto a mudarme a la nube, ¿puedo usar esta misma configuración y conectar el EBS a múltiples instancias de máquina o qué otra solución?¿Puede conectar Amazon EBS a varias instancias?
Estoy bastante seguro de que no puedes, pero puedes clonar un EBS y adjuntarlo a otra instancia.
Esto es útil para los conjuntos de datos fijos, o para las pruebas en los datos 'reales', pero no permite más de 1 instancia para operar en un solo almacén de bloque
No, esto es como usar un disco duro en dos ordenadores.
Si desea datos compartidos, 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 tener todas sus instancias conectadas 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á utilizando actualmente el almacenamiento compartido? Si solo se trata de servir archivos desde el servidor de archivos, ¿ha considerado configurar un sistema para que pueda proxy ciertas solicitudes a un proceso en el servidor de archivos en lugar de que los servidores web sirvan esos archivos?
Aquí hay un enlace para esa cita: https://aws.amazon.com/articles/1667. Ver preguntas frecuentes en la parte inferior del artículo.Me hace preguntarme por qué 'aws ec2 describe-volumes' devuelve una * matriz * de archivos adjuntos. –
ACTUALIZACIÓN (abril de 2015): Para este caso de uso, se debe empezar a buscar en el nuevo Amazon Elastic File System (EFS), que está diseñado para ser conectado multiplican exactamente de la manera que usted está deseando. La diferencia clave entre EFS y EBS es que proporcionan diferentes abstracciones: EFS expone el protocolo NFSv4, mientras que EBS proporciona acceso de IO de bloque sin formato.
A continuación encontrará mi explicación original de por qué no es posible montar de forma segura un dispositivo de bloques sin formato en varias máquinas.
post original (2011):
Incluso si fueron capaces de conseguir un volumen EBS conectado 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" en la que los clientes ejecutan un sistema de archivos como ext2/ext3/etc. La mayoría de estos sistemas de archivos (por ejemplo, ext2/3, FAT, NTFS, etc.) se escriben suponiendo que tienen acceso exclusivo al dispositivo de bloques. Dos instancias que acceden al mismo sistema de archivos casi con certeza terminarán 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 que está diseñado para compartir un dispositivo de bloques entre varias máquinas. Además, incluso esto no sería suficiente. EBS necesitaría ser probado para este escenario y para garantizar que ofrezca las mismas garantías de coherencia 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 kernel Dom0, la capa Xen y el kernel 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.
Como alternativa, vea si su escenario de uso compartido 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 esa solución es en realidad más eficiente.
En su caso, aún puede tener una sola instancia de MySql/servidor de archivos a la que accedan varios front-ends web. Ese servidor de archivos podría almacenar sus datos en un volumen de 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 de EBS y volver a conectarlo a una nueva instancia del servidor de archivos y realizar una copia de seguridad en minutos.
"¿Hay algo así como S3 como sistema de archivos?" - sí y no. Sí, hay soluciones de terceros como s3fs que funcionan "bien", pero aún tienen que realizar llamadas de servicio web relativamente caras para cada lectura/escritura. Para un directorio de herramientas compartidas, funciona muy bien. Para el tipo de uso agrupado de FS que ve en el mundo de HPC, no es una oportunidad. 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 montaje múltiple con un rendimiento y comportamiento razonables sería un GRAN complemento de funciones para EC2. Durante mucho tiempo he sido un defensor de Amazon para construir algo así.
El problema con NFS (y enfoques similares SMB) es que una máquina actuará como servidor (a lo que el sistema de archivos se montará físicamente). El hecho de que la máquina se apague causará que el volumen de EBS (o el disco también baje). ¿Hay algo así como S3 como sistema de archivos ?. – sheki
Solo para aclarar: si un volumen de EBS está conectado a una instancia y la instancia fallece catastróficamente, el volumen de EBS estará bien. Solo "bajará" en el sentido de que para acceder a él, deberá separarlo de la instancia de bajada y volver a conectarlo a una nueva instancia. –
"... casi con certeza terminaría en lágrimas y corrupción de datos". Clásico. @DaveDopson – Beachhouse
Hay algo en el mundo de la informática conocida como sistema de archivos en clúster, Redhat GFS, Oracle OCFS2, Veritas SFC ...
verifique el comentario a la respuesta de ddopson – sheki
@sheki Creo que su comentario a la respuesta de ddopson es completamente irrelevante para los sistemas de archivos en clúster. Los sistemas de archivos en clúster están diseñados para ser montados simultáneamente por varios servidores. El objetivo de un clusteredfs es evitar puntos únicos de falla. – Ryan
¿Por qué no crear una instancia con el volumen y sshfs a ese volumen en otros casos?
Varios servidores web que acceden al servidor MySQL & Servidor de archivos 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 Master-Slave en modo asincrónico/semi sincrónico en AWS. Se recomienda EBS-OPT + PIOPS en RAID 0 para alto rendimiento DB
Punto 2) Alternativamente, puede utilizar el modo Amazon RDS + Multi-AZ. Para la escala de lectura Se pueden adjuntar múltiples réplicas de lectura RDS a MySQL RDS.
Punto 3) El volumen de EBS no se puede conectar a varios EC2 simultáneamente. Puede crear un servidor de archivos basado en GlusterFS en Amazon EC2 usando EBS. Varios servidores web pueden hablar con un solo GlusterFS simultáneamente en AWS infra.
Punto 4) En caso de que su aplicación se pueda integrar con S3 como almacén de archivos, es preferible dada la estabilidad que aporta a la arquitectura. También puede acceder a S3 utilizando herramientas como S3fuse y su aplicación.
Puede usar totalmente una unidad en varios servidores en AWS. Uso 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 bajarlas localmente.
¿Qué ocurre con la lectura/solo? – alexus