¿Qué deben hacer los sitios que usan EC2 de manera diferente como resultado de la interrupción para garantizar el tiempo de actividad?

Como dijo Matthew, todo depende de su infraestructura, su pila y cuánto trabajo (lea: tiempo / dinero / fuerza laboral).

Hay dos conceptos que me gustaría definir: recuperación de fallas y tolerancia a fallas. La recuperación de fallas es cuando un desastre puede desactivar su aplicación, pero la aplicación puede recuperarse de ella. La tolerancia a fallas es cuando un desastre interrumpe el servicio, pero no quita la aplicación. La tolerancia a fallas es más costosa que la recuperación de fallas, ya que debe tener servidores redundantes en ejecución. Si su aplicación es lo suficientemente importante para usted, puede preferir la tolerancia a fallas sobre la recuperación de fallas.

Trabajo en SCALR (www.scalr.net) y nuestro software ofrece varias estrategias de recuperación ante desastres, ya que buscamos ser un alivio masivo del estrés. No los describiré a todos, pero aquí hay algunos puntos de partida que un administrador de sitios web puede considerar:

  1. Distribuya las instancias por igual entre las AZ de Ec2 para el servidor de aplicaciones / DB: la activación de nuevas instancias en una zona de disponibilidad diferente será automática: (recuperación de fallas: la aplicación está inactiva pero se recupera en breve). Por supuesto, si todos los Ec2 AZ experimentan interrupción, no es suficiente.
  2. Clone las granjas en una región diferente y programe la base de datos como esclavos. Luego, cambie la zona DNS para redirigir el tráfico a la granja us-west si el us-est falla. Una herramienta como Chef / Puppet le ayuda a implementar la misma configuración en ambas regiones. (tolerancia a fallas: su aplicación no se cae porque tiene servidores redundantes ejecutándose, también es más extensa);
  3. Tome instantáneas más regularmente.
  4. La recuperación ante desastres en varias nubes es muy compleja de configurar manualmente, pero no imposible si realmente lo desea.

En general, depende de su tolerancia al tiempo de inactividad frente a la pérdida de datos. La mayoría de los sitios con los que trabajamos pueden tolerar el tiempo de inactividad, pero no pueden perder una transacción o registros de visitantes. En ese caso, la replicación de la base de datos a otra nube como un servidor ‘frío’ protege la integridad de los datos, incluso si lleva tiempo migrar a través de máquinas virtuales o VAA a la otra nube, así como redirigir DNS.

Obviamente, si usted es Facebook o Twitter o está en su categoría, quiere cero tiempo de inactividad, pero puede sacrificar más fácilmente algunos tweets de algunos usuarios. Los sitios como estos deben construirse desde el principio a través de proveedores en la nube con equilibradores de carga de DNS que permitan una redirección perfecta en caso de tiempo de inactividad.

Trabajar con VAA (dispositivos de aplicación virtual) en lugar de solo VM (máquinas virtuales) permite una mejor migración entre nubes en caso de un problema.

Me gustaría decir que Amazon no tendrá interrupciones en el futuro, pero creo que estamos llegando a un punto de inflexión en el que las empresas están mirando seriamente a la nube como una solución con la cantidad de nuevas instancias de EC2 que tienen el potencial de continuar. para aumentar a un ritmo que a veces puede superar la capacidad de Amazon para agregar nuevos nodos.

existen algunas prácticas recomendadas comunes que puede seguir para garantizar la resistencia de su aplicación en EC2, como el uso de servicios autónomos y sin estado, la difusión de copias en caliente redundantes y la recuperación automática. Aquí hay algunos detalles sobre lo anterior y más buenas prácticas:
Retrospectiva sobre la reciente interrupción de AWS y la arquitectura resistente basada en la nube

También recomendaría familiarizarse con los mecanismos incorporados de AWS para ayudarlo, como CloudWatch para monitorear el estado de su sistema y la función de recuperación automática recién lanzada para volver a crear instancias fallidas. Puedes leer aquí para más detalles:
Amazon agrega recuperación automática a sus instancias de nube EC2