Cuando mi servidor web A se desconecta, ¿cómo redirecciono automáticamente a todos los usuarios a mi servidor web B en otra ciudad y viceversa?

Cuando mi servidor web A se desconecta, ¿cómo redirecciono automáticamente a todos los usuarios a mi servidor web B en otra ciudad y viceversa?

Un conmutador de equilibrio de carga hace lo que quiero, excepto que no puedo entender cómo hacerlo funcionar a menos que ambos servidores web estén en el mismo edificio.

Los sistemas de clústeres de alta disponibilidad hacen lo que quiero, excepto que no puedo entender cómo hacer que funcione a menos que ambos servidores web estén en el mismo edificio.

La respuesta aceptada para " redirigir a una página estática en otro servidor web cuando el servidor web principal está inactivo " parece admitir servidores web en 2 ciudades diferentes. Pero, ¿cómo me ayuda la instalación de una pieza de software en una caja después de que se desenchufa esa caja?

¿Cómo lo hacen las redes de entrega de contenido y DNS (CDN)?

Supongo que un enfoque comienza algo como:

1. Obtengo la dirección IP de todos y cada uno de mis servidores web físicos.
2. Pongo la dirección IP de todos y cada uno de mis servidores web físicos en el registro DNS para el nombre de dominio único de "el" sitio web (múltiples registros A o registros AAAA o ambos).
3. ... entonces, ¿qué necesito hacer?

Supongo que otro enfoque comienza algo como

1. Utilizo algún proveedor de DNS dinámico para el nombre de dominio único que espero que los usuarios escriban en el navegador web
2. Configuré un trabajo cron en cada servidor web que periódicamente le dice al proveedor de DNS su propia dirección IP (actualice el registro A o AAAA) o su propio nombre de dominio (actualice el registro CNAME o el registro DNAME).
3. ... entonces, ¿qué necesito hacer?

(Por ahora, estaría contento si mis usuarios obtuvieran una página web estática con mi información de contacto y una nota al pie de página que diga "el servidor web principal A parece estar inactivo" cuando el servidor web A está desconectado. Eso ya es mucho mejor que el sistema actual que simplemente da un error de "servidor no encontrado". Idealmente me gustaría que A y B estuvieran totalmente sincronizados y aparentemente idénticos, pero eso es algo para otra pregunta: ¿ equivalente a CDN pero para contenido dinámico? ).

Parece que puede estar buscando una solución Global Server Load Balancing (GSLB). GSLB generalmente usa DNS "inteligente" para dirigir a los usuarios a diferentes servidores en función de una serie de parámetros (es decir, servidor no disponible, alta carga, geolocalización de IP, etc.).

Como ejemplo, supongamos que tiene dos servidores web, uno en el oeste (10.10.10.1/24) y otro en el este (10.20.20.1/24). Digamos que su nombre de host web es www.connect.com.

GSLB se puede configurar para ser su DNS o como CNAME. De cualquier manera, un usuario escribe en www.connect.com, la consulta dns se dirige a la solución GSLB y responde con 10.10.10.1 o 10.20.20.1 dependiendo de los parámetros. El GSLB generalmente establece un TTL bajo, por lo que el host / navegador del cliente almacena en caché la respuesta durante el menor tiempo posible. Hay diferentes formas de abordar la persistencia, pero eso va más allá del alcance de este escenario.

Digamos que el servidor web este (10.20.20.1) se cae. GSLB generalmente implementa comprobaciones de estado para verificar el estado de los nodos de fondo. GSLB se da cuenta de que este está inactivo y todos los registros DNS posteriores para www.connect.com se resolverán a 10.10.10.1.

Si tiene una solución de equilibrio de carga del servidor local (SLB), puede configurarla de modo que www.connect.com sea un VIP / VS (digamos 192.168.1.1/24) con dos nodos de fondo (10.10.10.1/24 y 10.20.20.1/24). Técnicamente, los nodos podrían estar en diferentes segmentos de red, de modo que el SLB local pueda llegar al otro servidor. La solución SLB puede ser lo suficientemente inteligente como para redirigir a los usuarios a un servidor disponible si un nodo de fondo se cae. Si está utilizando F5 LTM, podría crear fácilmente una iRule para tal evento. Citrix NetScaler y otras soluciones SLB también deberían tener capacidades similares.

RR DNS no funciona en este caso. RR DNS no tiene inteligencia incorporada. La única forma de lograr el caso de uso con DNS es usar algún tipo de DNS "inteligente" a través de una solución GSLB (o similar).

CDN generalmente implementa soluciones GSLB / SLB para garantizar HA para sus clientes.

Desea examinar los equilibradores de carga globales como F5 y Cisco. Básicamente, hacen algunos trucos con DNS si el socio está inactivo y si el socio está activo, transmiten los datos al otro lado a través del equilibrador de carga.

Otra solución económica, rápida y confiable para evaluar podría ser utilizar Amazon Route 53 failover http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html . Esta característica fue lanzada el 11 de febrero de 2013 y proporciona alta disponibilidad y / o equilibrio de carga entre sitios primarios y secundarios.

Asim

Infórmeme si está utilizando algún tipo de proxy inverso en su entorno, de ser así, podría redirigirlo al servidor de respaldo.

si no, entonces F5 es una buena idea para usar.

Además, si ha registrado el dominio con un registrador de dominio de terceros, puede obtener la configuración del servidor DNS para redirigir al nuevo servidor o servidor de respaldo.

Puede hacerlo sin utilizar un dispositivo de red utilizando los dos métodos siguientes al menos, pero requerirán control de cambios:

• Proxy inverso, deberá eliminar el servidor que va a desconectar de los candidatos del proxy

• DNS, tendrá que planificar con anticipación, cambiar el DNS y esperar a que pase el TTL

También puede realizar un equilibrio de carga automático y una conmutación por error activa-activa, especialmente para un servidor web que sirve páginas estáticas mediante el uso de protocolos de enrutamiento. Echa un vistazo a EGP e IGRP. Debe haber material de ayuda en línea (especialmente relacionado con Cisco) que detalle cómo hacer esto con dos o más hosts a través de un enrutador.