Multi-sitio de alta disponibilidad

Tenemos una aplicación SaaS que necesitamos estar altamente disponible. Ya tenemos un clúster de conmutación por error Hyper-V caro y bien mantenido, pero hoy en día el centro de datos donde hospedamos ese clúster tuvo un corte de energía de cinco horas que nos dejó completamente sin conexión. Así que ahora nos estamos preguntando si un mejor enfoque podría ser el uso de servidores en dos centros de datos diferentes. Suponiendo que tengamos toda la replicación de archivos de fondo y replicación de datos funcionando entre estos dos sitios, nos preguntamos cómo manejar el enrutamiento front-end – no es de extrañar cómo abordamos el problema, siempre terminamos con el equilibrador de carga siendo Un único punto de falla.

Así que la pregunta es … ¿cómo podemos configurar el equilibrio de carga entre dos sitios de alojamiento de tal manera que el equilibrador de carga no es el único punto de error? ¿Hay una manera de utilizar dos equilibradores de carga independientes, uno en cada sitio? ¿Deberíamos considerar el DNS round-robin?

3 Solutions collect form web for “Multi-sitio de alta disponibilidad”

Para hacer esto correctamente, usted necesita tener:

  • Dos instancias separadas en dos datacenters (como ya lo has determinado)
  • La sincronización entre los dos datacenters (como usted ya ha determinado)
  • Una manera de redirigir a los clientes de uno a otro en caso de un fallo

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

DNS

Round-Robin DNS no es exactamente lo que quieres, porque lo más probable es que quieras todas las solicitudes para ir a la principal DC, y la segunda DC sólo se utiliza durante el tiempo de inactividad de la primera.

Lo que puedes hacer es establecer un TTL muy bajo en tu DNS (digamos, 30 segundos, o 5 minutos), lo que significará que si tu DC se va abajo, solo actualizas tu DNS y dentro de 5 minutos o así, todo Sus clientes estarán apuntando a su otro DC.

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

BGP

Básicamente, si usted está haciendo esta pregunta, entonces esto está fuera de su alcance. En resumen, sus direcciones IP permanecen iguales, pero se "trasladan" de un datacenter a otro. Esto implica costosos routers, rangos de IP caros y costosas suscripciones a su registro local para números AS y rangos IP.

Sus enrutadores BGP dejan de publicitar en su centro de datos principal y comienzan a publicar en su centro de datos secundario. Entonces el Internet viaja alrededor del datacenter sin conexión y envía tráfico a su nuevo DC.


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

Es necesario equilibrar la carga de los equilibradores de carga.

Puede hacerlo con DNS round-robin, pero ese enfoque tiene muchos problemas. No puede controlar los clientes que almacenan entradas en caché más de lo que desea y no puede forzar al tráfico a ir a una ubicación determinada.

También puede hacer esto con Global Server Load Balancing (GSLB). Esta es una forma más avanzada de aprovechar el DNS para darle visibilidad a múltiples centros de datos de Internet. En resumen, configurar algunos mecanismos para dividir su tráfico en rodajas y el uso de DNS para recoger una rebanada. Utilizamos un hash de la resolución DNS configurada para realizar búsquedas en 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 si algún punto de fallo para ese centro de datos o clúster desaparece.

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

Finalmente, algunas personas realmente avanzadas abordan este problema con Anycast DNS. Esto nuevamente trata de aprovechar el enfoque de centro de datos "más cercano". Anycasting su servicio significa que usted tendrá que eliminar cualquier "statefullness". 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
  • Amazon Route 53
El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.