Hay algo interesante sobre esta pregunta, específicamente con respecto a la idea del tiempo de inactividad. Parte de la idea es que si una aplicación es sensible al tiempo de inactividad, el tiempo de recuperación también debe tenerse en cuenta. (Como argumento extremo, las copias de seguridad no requieren tiempo de inactividad, a menos que necesite esas copias de seguridad, en cuyo caso el tiempo de inactividad puede llegar al infinito )
Un poco sobre EBS
Los volúmenes y las instantáneas de EBS funcionan a nivel de bloque, lo que permite tomar instantáneas mientras se ejecuta una instancia, incluso si el volumen de EBS está en uso. Sin embargo, solo los datos que están realmente en el disco (es decir, no en un caché de archivos) se incluirán en la instantánea. Es la última razón que da lugar a la idea de instantáneas consistentes.
- La forma recomendada es separar el volumen, tomar una instantánea y volver a conectarlo, generalmente no es práctico.
- La siguiente mejor opción consiste en vaciar las memorias caché de escritura en el disco, congelar el sistema de archivos y tomar su instantánea
Un punto interesante aquí es que en los dos casos anteriores, no necesita esperar a que la instantánea termine para volver a conectarse / descongelarse y reanudar la escritura en el disco; una vez que se haya iniciado la instantánea, sus datos serán consistentes en ese momento. Por lo general, esto solo requiere unos segundos durante los cuales su disco está bloqueado contra escritura. Además, dado que la mayoría de las bases de datos estructuran sus archivos en el disco de manera razonable, existe una buena posibilidad de que las inserciones tengan un efecto mínimo en los bloques existentes, lo que minimiza los datos agregados a la instantánea.
Considere el punto de la copia de seguridad
Los volúmenes EBS ya están replicados dentro de una zona de disponibilidad, por lo que hay un cierto grado de redundancia incorporada. Si su instancia finaliza, simplemente puede adjuntar el volumen EBS a una nueva instancia y (después de superar la falta de coherencia) reanudar donde Parado. En muchos aspectos, esto hace que el volumen de EBS se parezca mucho a una instantánea inconsistente, siempre que pueda acceder a él. Dicho esto, la mayoría de los usuarios de EC2 probablemente recuerden las fallas en cascada de los volúmenes de EBS desde principios de 2011: los volúmenes fueron inaccesibles durante varios días y algunos usuarios también perdieron datos.
RAID1
Si está intentando protegerse contra la falla de un disco EBS (sucede), puede considerar una configuración RAID1. Dado que los volúmenes EBS son dispositivos de bloque, puede usar fácilmente mdadm para configurarlos en la configuración deseada. Si uno de sus volúmenes EBS no está funcionando según las especificaciones, es bastante fácil fallarlo manualmente (y luego reemplazarlo con otro volumen EBS). Por supuesto, esto tiene desventajas: mayor tiempo para cada escritura, mayor susceptibilidad al rendimiento variable, el doble del costo de E / S (monetariamente, no en términos de rendimiento), no hay protección real contra una falla de AWS más extendida (un problema común el año pasado fue la incapacidad de separar los volúmenes de EBS que estaban en estado bloqueado) y, por supuesto, el estado inconsistente del disco en caso de falla.
S3FS
Una opción para ciertas aplicaciones (definitivamente NO para bases de datos) es montar S3 como un sistema de archivos local (por ejemplo, a través de s3fs). Esto es lento, carece de algunas de las características que uno esperaría de un sistema de archivos y puede no comportarse como se espera (consistencia eventual). Dicho esto, para un propósito simple como hacer que los archivos cargados estén disponibles en todas las instancias, puede tener mérito. Obviamente no es para nada que requiera un buen rendimiento de lectura / escritura.
MySQL bin-log
Una opción más específica para MySQL puede ser el uso del bin-log. Puede configurar un segundo volumen EBS que almacenará su bin-log (para minimizar el efecto de las escrituras agregadas en su base de datos), y usarlo junto con los volcados de la base de datos que realice. Incluso es posible que pueda hacer esto con s3fs, lo que en realidad puede tener mérito si el rendimiento es tolerable (un rsync probablemente sería mejor que tratar de usar s3fs directamente, y definitivamente querrá comprimir lo que pueda).
Una vez más, sin embargo, volvemos a la idea del propósito. Considere lo que sucedería con las sugerencias anteriores:
- Volúmenes EBS inaccesibles:
- RAID1: inútil, ya que no puede acceder a los datos
- bin-log, inútil, a menos que lo haya exportado a S3, aunque probablemente haya un retraso si lo hizo
- La instancia termina inesperadamente:
- RAID1: sus discos están disponibles, pero no son consistentes, su base de datos puede recuperarse de la inconsistencia por sí sola
- bin-log: sus datos deben estar accesibles, aunque es posible que deba revisar los últimos eventos
- Alguien ejecuta DROP DATABASE como root:
- RAID1: tiene dos copias perfectas de una base de datos inexistente
- bin-log: debería poder reproducir los eventos justo antes del comando, por lo que debería estar bien
Entonces, realmente, RAID1 es inútil en su mayoría, y bin-log lleva demasiado tiempo; ambos pueden tener mérito en ciertas circunstancias, pero están lejos de ser la idea de copia de seguridad.
Instantáneas
Es importante tener en cuenta que las instantáneas son diferenciales y solo almacenan los bloques reales que contienen datos (y están comprimidos). A diferencia de un volumen EBS, donde si tiene un volumen de 20 GB, pero solo usa 1 GB, todavía se le cobrará por el almacenamiento 'provisto' (20 GB). Con una instantánea, solo se le cobra por lo que usa. Si no hay cambios de datos entre las instantáneas, (teóricamente) no hay cargo. (Las instantáneas se cobran por PUTS / GETS y el almacenamiento usado).
Por otro lado, recomendaría encarecidamente que los datos de su aplicación (incluidas las bases de datos) no se almacenen en su volumen raíz (que ya puede haber configurado). Una de las ventajas es que, con suerte, su volumen raíz verá un mínimo de cambio, lo que significa que sus instantáneas pueden ser menos frecuentes (o tendrán un mínimo de cambio) reduciendo el costo y la facilidad de uso.
También es importante mencionar que puede eliminar instantáneas antiguas en cualquier momento; aunque sean diferenciales, no afectarán a las otras instantáneas. Dicho esto, cada bloque asignado a una instantánea no se entregará hasta que no haya una instantánea que aún haga referencia a ese bloque.
El problema con los volcados periódicos es, en primer lugar, el tiempo entre volcados (posiblemente abordado mediante el uso del bin-log de MySQL) y también la dificultad de la recuperación. Se necesita tiempo para importar un volcado grande y reproducir todos los eventos desde un bin-log. Además, crear un volcado no está exento de implicaciones de rendimiento. Podría decirse que estos vertederos probablemente requieren mucho más almacenamiento que una instantánea. Configurar un volumen EBS únicamente para las bases de datos e instantáneas que sería preferible en la mayoría de los aspectos (dicho esto, tomar una instantánea también tiene un poco de implicación en el rendimiento).
La belleza de las instantáneas y los volúmenes de EBS es que pueden usarse en otros casos. Si su instancia no se inicia, puede adjuntar el volumen raíz a otra instancia para diagnosticar y solucionar el problema, o simplemente para copiar sus datos, y puede cambiar los volúmenes raíz con solo unos minutos de tiempo de inactividad (detener la instancia, desconectar el volumen raíz, adjunte un nuevo volumen raíz, inicie la instancia). Esta misma idea se aplica a tener sus datos en un segundo volumen de EBS. Esencialmente, simplemente activa una nueva instancia desde su AMI personalizada y adjunta su volumen EBS actual, lo que ayuda a minimizar el tiempo de inactividad.
(Se podría argumentar (y probablemente no lo recomendaría) que podría configurar dos copias de MySQL en el mismo servidor (Maestro-esclavo), utilizando dos volúmenes EBS, y luego apagar su esclavo para tomar una instantánea de su Volumen de EBS: será constante, sin tiempo de inactividad, pero es probable que los costos de rendimiento no valgan la pena).
AWS tiene escala automática, que podrá mantener un número constante de instancias (incluso si ese número es 1), sin embargo, se implementaría desde una instantánea, por lo que si su instantánea no es útil, entonces la premisa no es de mucha utilidad .
Otro par de puntos: puede implementar tantas instancias como desee desde una única instantánea (a diferencia de un volumen EBS, que solo se puede adjuntar a una única instancia en un momento dado). Además, los volúmenes de EBS están restringidos para su uso dentro de una zona de disponibilidad, mientras que las instantáneas se pueden usar dentro de una región.
Idealmente, con una instantánea, si su servidor se cae, puede iniciar una nueva usando la última instantánea, especialmente si separa su volumen raíz de sus datos, una mala actualización debería resultar en un mínimo de tiempo de inactividad (ya que simplemente transfiera el volumen de EBS que contiene sus datos, y tome una instantánea para preservar cualquier cosa que pueda corromperse debido a la inconsistencia).
Como nota al margen, Amazon afirma que la tasa de falla de los volúmenes de EBS aumenta con la cantidad de datos modificados desde la última instantánea.
Recomendaciones finales
- Use instantáneas, son geniales, reducen el tiempo de inactividad mucho más de lo que lo causan
- Separe los datos y el volumen raíz, tal vez incluso poniendo las bases de datos en su propio volumen, e instantáneas antes de las actualizaciones si es necesario
- Use el bin-log para mantenerse lo más 'caliente' posible - suba esto (comprimido) a S3
- Asegúrese de obtener los datos de la instancia (incluso si los datos están intactos en un volumen EBS, el volumen en sí podría ser temporalmente inaccesible).
Lectura recomendada:
(Creo que he escrito demasiado, pero no dije lo suficiente, pero espero que encuentre algo que valga la pena leer).