dns distributed failover redundancy

Diseño de fail-over cross-colo, conmutación por error de nivel DNS



distributed failover (3)

En cuanto al DNS, me gusta hacer referencia a "Por qué el Equilibrio de carga del servidor global basado en DNS no funciona" . Para todo lo demás, use BGP .

Diseñar redes con el fin de equilibrar la carga utilizando BGP no es una tarea fácil, y ciertamente yo no soy un experto en esto. También es más complejo de lo que Wikipedia puede decirte, pero hay un par de artículos interesantes en la web que detallan cómo se puede hacer:

Siempre hay más si busca BGP y equilibrio de carga. También hay un par de documentos en la red que describen cómo Akamai hace su balance de carga global (creo que también es BGP), que siempre es interesante de leer y conocer.

Más allá de los conceptos obvios que puede usar para lograr el software y el hardware, también puede consultar con su ISP / proveedor / colo si pueden configurarlo.

Además, no se ofenda con respecto a su elección de colo (¿Quién es el proveedor?), Pero la mayoría de los lugares deben configurarse para lidiar con los tiempos de inactividad, y así sucesivamente, no deberían exigirle que tome medidas. Por supuesto, las inundaciones o los extraterrestres siempre pueden golpear, pero en ese caso, creo que hay cuestiones más importantes. :-)

Me interesan las estrategias de conmutación cruzada de colores cruzados para aplicaciones web, de modo que si el sitio principal falla, los usuarios aterrizan sin problemas en el sitio de recuperación en otro sitio.

El aspecto de la aplicación de las cosas parece que se resuelve en su mayoría con una configuración de base de datos maestro-esclavo entre los colos y los servicios diseñados para recuperar y poder recoger a mitad de camino. Estoy intentando descubrir la estrategia para mover el tráfico del sitio principal al sitio de conmutación por error. La conmutación por error de DNS, incluso con TTL bajos, parece llevar bastante tiempo de latencia .

¿Qué estrategias recomendaría para mover rápidamente el tráfico entre colos, suponiendo que los servidores en el colo principal son inalcanzables?

Si tienes otras experiencias / palabras de sabiduría sobre la migración tras error de varios colores, me encantaría escucharlas también.

Los mecanismos basados ​​en DNS son problemáticos, incluso si pone bajos TTL en sus archivos de zona.

La razón de esto es que muchas aplicaciones (por ejemplo, MSIE) mantienen sus propios cachés que ignoran el TTL. Otro software hará un solo gethostbyname() o llamada equivalente y almacenará el resultado hasta que se reinicie el programa.

Peor aún, se sabe que muchos servidores DNS recursivos de los ISP ignoran los TTL por debajo de su mínimo preferido e imponen sus propios TTL más altos.

En última instancia, si el sitio se va a ejecutar desde ambos centros de datos sin cambiar su dirección IP, entonces necesita ver los arreglos para "Multihoming" a través de anuncios de rutas globales BGP4.

Con multihoming necesita obtener al menos un bloque de red / 24 de espacio de direcciones IP "independiente del proveedor" (también conocido como "PI"), y luego solo debe anunciarse en la tabla de enrutamiento global desde el sitio de respaldo si el sitio principal se desconecta.