2009-03-15 11 views
12

Pasé el día experimentando con AWS por primera vez. Tengo una instancia de EC2 ejecutándose y monté una Elastic Block Store (EBS) para mantener las bases de datos MySQL.EBS para almacenar bases de datos versus archivos de sitios web

¿Tiene sentido poner también mis archivos de aplicación web en el EBS, o debería simplemente implementarlos en el sistema de archivos EC2 normal?

+0

Nadie conoce sus necesidades excepto usted. Tal vez deberías eludir ... –

+0

Votó una copia de seguridad porque es una pregunta perfectamente legítima. –

+0

Como señala Kevin Peterson en su respuesta, sería muy relevante saber si se refería a los archivos implementados de código o de datos. – Jonik

Respuesta

7

Cuando dice los archivos de su aplicación web, no estoy seguro de a qué se refiere exactamente.

Si se refiere a su código implementado, probablemente no tenga sentido usar EBS. Lo que quiere hacer es crear una AMI con sus requisitos previos, luego tener una secuencia de comandos para crear una instancia de esa AMI e implementar su último código. Le recomiendo que automatice y pruebe este proceso, ya que es fácil olvidarse de alguna configuración que debe cambiar manualmente en algún lugar.

Si está almacenando archivos de datos, que son modificados por la aplicación en ejecución, EBS puede tener sentido. Si esto es algo así como imágenes cargadas por el usuario o similares, es probable que encuentre que S3 le brinda un modelo mucho más simple.

EBS sería bueno para: bases de datos, índices lucene, archivo basado en CMS, repositorio SVN, o algo similar a eso.

+1

+1, esta es la respuesta más clara aquí.Además, si OP se está preguntando sobre la velocidad de EBS frente al almacenamiento de instancias, debería verificar esto: http://serverfault.com/questions/111594/which-is-faster-for-read-access-on-ec2-local -drive-or-ebs – Jonik

2

EBS le ofrece almacenamiento persistente, por lo que si la instancia de EC2 falla, los archivos aún existen. Aparentemente, su rendimiento de IO es mayor, pero lo probaría para estar seguro.

2

Si sus archivos van a cambiar con frecuencia (como lo hace un DB) y no desea seguir sincronizándolos con S3 (o con otro lugar), entonces un EBS es una buena forma de hacerlo. Si realiza cambios infrecuentes y puede sincronizar manualmente (o con guiones) los archivos según sea necesario, guárdelos en S3. Si necesita apagar o perder su instancia por el motivo que sea, puede simplemente tirar de ellos cuando inicie la nueva instancia. Esto también supone que le importan los costos. Si el costo no es un problema, usar el EBS es menos complicado. No estoy seguro de si planea tener un EBS separado para su base de datos y sus archivos web, pero si solo planea tener un EBS y tiene suficiente espacio vacío para sus archivos web, entonces nuevamente, el EBS es menos Complicado. Si su rendimiento le preocupa, como se mencionó, lo mejor es probar su aplicación en particular.

1

Nuestro enfoque consiste en tener una secuencia de comandos implementada previamente en nuestra AMI que obtenga la versión más reciente y mejor del código del control de código fuente. Eso hace que sea muy sencillo lanzar nuevas instancias rápidamente o actualizar todas las instancias en ejecución (las sacamos de la rotación del balanceo de carga de a una por vez, ejecutamos el script y las volvemos a colocar en la rotación).

ACTUALIZACIÓN:

Leyendo entre líneas parece que se está montando un volumen EBS a una instancia separada respaldado ejemplo las tiendas. Recientemente, AWS introdujo instancias respaldadas por EBS que tienen una tonelada de beneficios en comparación con las antiguas instancias de tienda de instancias. Sin embargo, sigo montando mis datos de MySQL en una partición EBS separada, de modo que puedo montarlos fácilmente en un servidor diferente si es necesario.

Sugiero una instancia respaldada por EBS con un volumen EBS aparte para los datos de MySQL.

Cuestiones relacionadas