Solución:
En algunos casos, Amazon notará que su hardware está en un estado degradado y le dirá que salga de él (detenga e inicie su instancia) en una fecha determinada o se detendrá automáticamente.
En algunos casos, no habrá ninguna advertencia y simplemente se detendrá. O no ingrese al estado STOP y simplemente se vuelva inalcanzable. Puede que se reinicie o no después de que se encarguen de él. A veces, habrá un correo de disculpas después del hecho.
Todavía no me ha fallado un volumen de EBS (he tenido muchas instancias que se han vuelto raras, pero no volúmenes), pero aún planeo eso. No sé cómo se ve eso.
Establecer una alarma para que falle la verificación del estado de accesibilidad es su mejor opción.
Es poco probable que AWS reinicie su instancia. Le brindan todas las herramientas para monitorear y reiniciar instancias, por lo que se lo dejan a usted. Es posible que le envíen un correo electrónico si necesita hacer algo. Si detiene y luego inicia su instancia, se moverá a un nuevo hardware, pero un reinicio no la moverá a un nuevo hardware. Los reinicios de mi instancia de Amazon Linux suelen tardar aproximadamente un minuto.
No debe perder datos de su disco de EBS si falla el hardware de EC2, ya que los volúmenes de EBS se almacenan de forma redundante dentro de una única zona de disponibilidad. Las instantáneas de EBS se almacenan en S3, que almacena datos en tres zonas de disponibilidad dentro de una sola región, por lo que son significativamente más robustas. Las instantáneas se pueden automatizar para que se tomen cada hora, diariamente, semanalmente, etc., utilizando una variedad de herramientas. La primera instantánea es grande, se dice que los diferenciales posteriores utilizan relativamente poco espacio. En mi experiencia, las instantáneas muy juntas ocupan poco espacio, pero con el tiempo suman tamaño y costo, por lo que elimino regularmente las instantáneas que no necesito.
Además de instantáneas También debe realizar copias de seguridad a nivel de la aplicación utilizando una aplicación como Borg Backup, Restic o una herramienta comercial.
Puede crear una alarma en CloudWatch que reinicie su instancia si se activa StatusCheckFailed. La documentación con instrucciones paso a paso está aquí.
Acabo de tener una falla de EBS que hizo que ambos EC2 ejecutaran un servicio supuestamente tolerante a fallas en Elastic Beanstalk.
Los síntomas indicaban que las solicitudes HTTP GET aún funcionaban, pero las POST fallaron. Esto significa que nuestras verificaciones de estado basadas en GET no detectaron ningún problema, pero los usuarios no pudieron iniciar sesión porque el proceso de inicio de sesión utilizó una POST.
Al mirar los registros, había muchos mensajes en /var/log/messages sobre errores de E / S.
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 3198976 size 4096 starting block 1475341)
Buffer I/O error on device dm-3, logical block 1475341
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 0 size 0 starting block 1475340)
Buffer I/O error on device dm-3, logical block 1475340
JBD2: Detected IO errors while flushing file data on dm-3-8
EXT4-fs warning (device dm-3): ext4_end_bio:314: I/O error -28 writing to inode 5905292 (offset 0 size 0 starting block 1475341)
Buffer I/O error on device dm-3, logical block 1475341
Había mensajes en los registros de nginx quejándose de que las solicitudes POST fallaron debido al estado de solo lectura resultante del sistema de archivos.
open() "/var/lib/nginx/body/0000522584" failed (30: Read-only file system)
open() "/var/lib/nginx/body/0000522585" failed (30: Read-only file system)
open() "/var/lib/nginx/body/0000522586" failed (30: Read-only file system)
Lo que parece haber sucedido es el comportamiento habitual de Linux, que es que un disco fallido deja el sistema de archivos en modo de solo lectura, lo que luego impidió que nginx creara archivos temporales para almacenar datos POST. Pero los GET funcionaron bien porque leer el sistema de archivos todavía estaba bien.
Curiosamente, debido a que las verificaciones de estado informaban que todo estaba bien, Elastic Beanstalk no finalizó ni volvió a crear ninguna instancia EC2, a pesar de que aproximadamente el 35% de las solicitudes fallaban con errores HTTP 500.
¿Lecciones aprendidas? Asegúrese de que las URL de su verificación de estado intenten escribir en el mismo sistema de archivos que utilizan otros procesos en su EC2, de modo que un disco defectuoso también provoque la falla de la verificación de estado. De lo contrario, es posible que el problema no se detecte automáticamente y requiera una intervención manual.