Estrategia de conmutación por error del servidor de base de datos EC2

Question

Estoy planeando implementar mi aplicación web en EC2. Tengo varias instancias de servidor web. Tengo 1 instancia de base de datos primaria. Tengo 1 instancia de base de datos de conmutación por error. Necesito una estrategia para redireccionar los servidores web al IP de la instancia de la base de datos de conmutación por error cuando la instancia de la base de datos primaria falla.

Esperaba poder usar una IP Elástica en mis cadenas de conexión. Pero los servidores web no pueden acceder/hacer ping a Elastic IP. Tengo varias ideas de fuerza bruta para resolver el problema. Sin embargo, estoy tratando de encontrar la solución más elegante posible.

Estoy usando todos .Net y SQL Server. Mis cadenas de conexión están encriptadas.

¿Alguien tiene una estrategia para fallar sobre una instancia de base de datos en EC2 usando alguna forma de automatización o configuración de DNS?

Háganme saber.

Answer 1

http://alestic.com/2009/06/ec2-elastic-ip-internal

le indica cómo usar el DNS público elástico IP.

Answer 2

no ha utilizado EC2 pero seguramente que o bien:

(a) poner su front-end en algún modo de mantenimiento a medida, que defina, mientras se cambia la IP a través de; y hacer que el front-end realice los pasos necesarios para gestionar posibles problemas de integridad de datos y pérdida de datos relacionados con el servidor anterior y que salga el nuevo servidor cuando entre y salga de su modo de mantenimiento personalizado

O, para un cero abajo -sistema de tiempo:

(b) diseñe el sistema a nivel de objeto/relacional y de transacción desde cero para soportar el fail-over sin tiempo de inactividad. No es algo que pueda apilar rápidamente a cualquier aplicación.

(c) utilice algún soporte de base de datos para failover automático. No estoy al tanto si existe soporte de SQL Server para failover adecuado para su aplicación o si es apropiado aquí. Sugiero agregar una etiqueta "sql-server" a la pregunta para comenzar una búsqueda para la audiencia correcta.

Si las IP elásticas no funcionan (lo que suena raro, por decir lo menos, ¿no debería hablar con EC2 sobre eso), es posible que pueda instruir a su front-end qué nueva base de datos IP usar en el al mismo tiempo que le dice que pase del modo de mantenimiento al modo normal.

Answer 3

Si está dispuesto a desembolsar un poco de dinero extra, eche un vistazo a las herramientas Rightscale's; han creado imágenes de servidor personalizadas y herramientas de soporte que manejan la conmutación por error de la base de datos (entre muchas otras cosas). This link explica cómo hacerlo con MySQL, por lo que con suerte le mostrará algunos principios aunque no use SQL Server.

Answer 4

siempre pensé que había esta posibilidad en la cadena connnection

Esto está tomado (pero aún no probado) de How to add Failover Partner to a connection string in VB.NET:

Si conecta con ADO.NET o el SQL Native Client a una base de datos que es siendo duplicada, su aplicación puede aprovechar la capacidad de los controladores para redirigir automáticamente las conexiones cuando ocurre una conmutación por error de base de datos .Debe especificar el servidor principal y la base de datos iniciales en la cadena de conexión y el servidor asociado de conmutación por error .

Data Source=myServerAddress;Failover Partner=myMirrorServerAddress; 
Initial Catalog=myDataBase;Integrated Security=True; 

Hay muchas otras maneras ofcourse a escribir la cadena de conexión usando reflejo de base, esto es sólo un ejemplo señalando la funcionalidad de conmutación por error . Puede combinar este con las otras cadenas de conexión opciones disponibles.

Answer 5

Para ampliar la respuesta de gareth, los softwares de gestión de la nube suelen resolver este tipo de problemas. RightScale es uno de ellos, pero puede probar enStratus o Scalr (descargo de responsabilidad: yo trabajo en Scalr). Estas herramientas proporcionan soluciones de conmutación por error como:

• copias de seguridad: se puede programar instantáneas automatizadas del volumen EBS que contiene los datos de base de datos
• tolerante a fallos: en caso de fallo, un esclavo se promueve principal y montado de almacenamiento será ser cambiado si el maestro fallado y nuevo maestro están en la misma AZ, o una instantánea tomada del volumen

Si usted quiere construir su propia solución, se podría replicar el proceso se detalla a continuación que utilizamos en Scalr:

• ¿Hay un esclavo en la misma AZ? Si es así, promuévalo, cambie los volúmenes de EBS (que están limitados a una sola AZ), cambie cualquier ElasticIP que tenga, reconfigure la replicación de los esclavos restantes.
• Si no, ¿hay un esclavo completamente replicado en otro AZ? Si es así, promociónalo, y luego haz lo anterior.
• Si no hay esclavos en mismo AZ, y ningún esclavo totalmente replicado en otro AZ, a continuación, crear una instantánea del volumen de maestría , y utilizar esta instantánea para crear un nuevo volumen en un AZ, donde se está ejecutando un esclavo . Entonces haz lo de arriba.