Alta disponibilidad multisitio

Tenemos una aplicación SaaS que necesitamos para estar altamente disponible. Ya tenemos un clúster de conmutación por error Hyper-V costoso y bien mantenido, pero hoy el centro de datos donde alojamos ese clúster tuvo un corte de energía de cinco horas que nos dejó completamente fuera de línea. Así que ahora nos preguntamos si un mejor enfoque podría ser utilizar servidores en dos centros de datos separados. Suponiendo que conseguimos que toda la replicación de archivos de fondo y la replicación de datos funcionen entre estos dos sitios, nos preguntamos cómo manejar el enrutamiento de front-end: no es de extrañar cómo abordamos el problema, siempre terminamos con el balanceador de carga siendo Un solo punto de falla.

Entonces, la pregunta es ... ¿cómo podemos configurar el equilibrio de carga entre dos sitios de alojamiento de modo que el equilibrador de carga no sea el único punto de falla? ¿Hay alguna manera de usar dos equilibradores de carga separados, uno en cada sitio? ¿Deberíamos estar considerando DNS round-robin?

Para hacer esto correctamente, debe tener:

• Dos instancias separadas en dos centros de datos (como ya ha determinado)
• Sincronización entre los dos centros de datos (como ya ha determinado)
• Una forma de redirigir a los clientes de uno a otro en caso de falla

Hay dos formas comunes de hacer esto. Uno simple, uno ... no.

DNS

Round-Robin DNS no es exactamente lo que desea, porque es probable que desee que todas las solicitudes vayan al DC primario, y el segundo DC solo se usa durante el tiempo de inactividad del primero.

Sin embargo, lo que puede hacer es establecer un TTL muy bajo en su DNS (por ejemplo, 30 segundos o 5 minutos), lo que significa que si su DC se cae, simplemente actualice su DNS y dentro de 5 minutos más o menos, todo sus clientes apuntarán a su otro DC.

Esto significa que debido a que sus dos DC tendrán diferentes diseños de IP, debe ajustar esto en su configuración del centro de datos.

BGP

Básicamente, si está haciendo esta pregunta, entonces está fuera de su alcance. En resumen, sus direcciones IP permanecen igual, pero se "mueven" de un centro de datos a otro. Esto implica enrutadores caros, rangos de IP caros y suscripciones costosas a su registro local para números AS y rangos de IP.

Sus enrutadores BGP dejan de anunciar en su centro de datos principal y comienzan a anunciar en su centro de datos secundario. Luego, Internet se enruta alrededor del centro de datos fuera de línea y envía tráfico a su nuevo DC.

Si está virtualizado con ESXi y vSphere, VMWare tiene un producto bastante bueno que probamos una vez llamado VMWare Site Recovery Manager , que básicamente hace todo por usted. Mantiene sus configuraciones de VM sincronizadas y las enciende en el segundo sitio cuando el primer sitio se desconecta. Sin embargo, es mucho dinero.

Necesita equilibrar la carga de los equilibradores de carga.

Usted puede hacer esto con la rotación en DNS, pero que el enfoque tiene muchos problemas. No puede controlar a los clientes que almacenan en caché las entradas más de lo que desea y no puede forzar el tráfico para ir a una determinada ubicación.

También puede hacer esto con Global Server Load Balancing (GSLB). Esta es una forma más avanzada de aprovechar DNS para brindarle visibilidad en múltiples centros de datos desde Internet. En resumen, configura algún mecanismo para dividir su tráfico en segmentos y utilizar DNS para elegir un segmento. Usamos un hash de la resolución DNS configurada para hacer búsquedas para el cliente. Otras personas usan la geografía para dirigirse al centro de datos "más cercano". Deberá agregar algún mecanismo para eliminar rápidamente una IP del GSLB en caso de que algún punto de falla único para ese centro de datos o clúster se caiga.

http://www.eukhost.com/web-hosting/kb/global-server-load-balancing/

Finalmente, algunas personas realmente avanzadas abordan este problema con Anycast DNS. Esto nuevamente intenta aprovechar el enfoque del centro de datos "más cercano". Cualquier transmisión de su servicio significa que deberá eliminar cualquier "estado de plenitud". Esto puede resultar difícil.

Años más tarde ... pero para aquellos que todavía buscan, estas parecen ser las soluciones más asequibles / simples para la conmutación por error de DNS:

• DynDNS
• DNS hecho fácil
• Ruta amazónica 53