Múltiples centros de datos y tráfico HTTP: ¿DNS Round Robin es la ÚNICA forma de garantizar una conmutación por error instantánea?

Varios registros A que apuntan al mismo dominio parecen usarse casi exclusivamente para implementar DNS Round Robin como una técnica de equilibrio de carga barata.

La advertencia habitual contra DNS RR es que no es bueno para la alta disponibilidad. Cuando 1 IP caiga, los clientes continuarán usándolo durante minutos.

A menudo se sugiere un equilibrador de carga como una mejor opción.

Ambas afirmaciones no son completamente ciertas:

1. Cuando el tráfico es HTTP, la mayoría de los navegadores HTML pueden probar automáticamente el siguiente registro A si el anterior está inactivo, sin una nueva búsqueda de DNS. Lea aquí el capítulo 3.1 y aquí .

2. Cuando intervienen varios centros de datos, DNS RR es la única opción para distribuir el tráfico entre ellos.

Entonces, ¿es cierto que, con múltiples centros de datos y tráfico HTTP, el uso de DNS RR es la ÚNICA forma de garantizar una conmutación por error instantánea cuando un centro de datos se cae?

Gracias,

Valentino

Editar:

• Por supuesto, cada centro de datos tiene un equilibrador de carga local con repuesto dinámico.
• Está bien sacrificar la afinidad de sesión por una conmutación por error instantánea.
• AFAIK, la única forma en que un DNS puede sugerir un centro de datos en lugar de otro es responder solo con la IP (o IP) asociada a ese centro de datos. Si el centro de datos se vuelve inalcanzable, entonces todas esas IP también son inalcanzables. Esto significa que, incluso si los navegadores HTML inteligentes pueden probar instantáneamente otro registro A, todos los intentos fallarán hasta que caduque la entrada de caché local y se realice una nueva búsqueda de DNS, obteniendo las nuevas IP que funcionan (supongo que DNS sugiere automáticamente a un nuevo centro de datos cuando uno falla). Por lo tanto, el "DNS inteligente" no puede garantizar la conmutación por error instantánea.
• Por el contrario, un round-robin de DNS lo permite. Cuando un centro de datos falla, los navegadores HTML inteligentes (la mayoría de ellos) prueban instantáneamente los otros registros A en caché que saltan a otro centro de datos (en funcionamiento). Por lo tanto, DNS round-robin no garantiza la afinidad de sesión o el RTT más bajo, pero parece ser la única forma de garantizar la conmutación por error instantánea cuando los clientes son navegadores HTML "inteligentes".

Edición 2:

• Algunas personas sugieren TCP Anycast como una solución definitiva. En este documento (capítulo 6) se explica que la conmutación por error Anycast está relacionada con la convergencia BGP. Por esta razón, Anycast puede emplear de 15 minutos a 20 segundos para completarse. Son posibles 20 segundos en redes donde la topología fue optimizada para esto. Probablemente solo los operadores de CDN puedan otorgar tales fallas rápidas.

Edición 3: *

• Hice algunas búsquedas de DNS y traceroutes (tal vez algún experto puede verificar) y:
  • El único CDN que usa TCP Anycast parece ser CacheFly, otros operadores como las redes CDN y BitGravity usan CacheFly. Parece que sus bordes no pueden usarse como proxies inversos. Por lo tanto, no se pueden usar para otorgar conmutación por error instantánea.
  • Akamai y LimeLight parecen utilizar DNS con reconocimiento geográfico. ¡Pero! Devuelven múltiples registros A. Desde traceroutes parece que las IP devueltas están en el mismo centro de datos. Entonces, estoy desconcertado sobre cómo pueden ofrecer un SLA 100% cuando un centro de datos deja de funcionar.

Cuando uso el término "DNS Round Robin" generalmente me refiero en el sentido de la "técnica de equilibrio de carga barata" como lo describe OP.

Pero esa no es la única forma en que se puede utilizar DNS para la alta disponibilidad global. La mayoría de las veces, es difícil para las personas con diferentes antecedentes (tecnológicos) comunicarse bien.

La mejor técnica de equilibrio de carga (si el dinero no es un problema) generalmente se considera:

1. Una red global de servidores DNS 'inteligentes' de Anycast
2. y un conjunto de centros de datos distribuidos globalmente,
3. donde cada nodo DNS implementa Split Horizon DNS,
4. y el monitoreo de la disponibilidad y los flujos de tráfico están disponibles para los nodos DNS 'inteligentes' de alguna manera,
5. para que la solicitud DNS del usuario fluya al servidor DNS más cercano a través de IP Anycast ,
6. y este servidor DNS entrega un registro / conjunto de registros A de bajo TTL para el centro de datos más cercano / mejor para este usuario final a través de DNS 'inteligente' de horizonte dividido.

Usar anycast para DNS generalmente está bien, porque las respuestas de DNS no tienen estado y son extremadamente cortas. Entonces, si las rutas BGP cambian, es muy poco probable que interrumpa una consulta DNS.

Anycast es menos adecuado para las conversaciones HTTP más largas y con estado, por lo que este sistema utiliza DNS de horizonte dividido. Una sesión HTTP entre un cliente y un servidor se mantiene en un centro de datos; generalmente no puede conmutar por error a otro centro de datos sin interrumpir la sesión.

Como indiqué con "conjunto de registros A", lo que yo llamaría 'DNS Round Robin' se puede usar junto con la configuración anterior. Por lo general, se usa para distribuir la carga de tráfico en múltiples equilibradores de carga de alta disponibilidad en cada centro de datos (para que pueda obtener una mejor redundancia, usar equilibradores de carga más pequeños / más baratos, no abrumar los búferes de red Unix de un solo servidor host, etc.).

Entonces, ¿es cierto que, con múltiples centros de datos y tráfico HTTP, el uso de DNS RR es la ÚNICA manera de asegurar una alta disponibilidad?

No, no es cierto, no si por 'DNS Round Robin' nos referimos simplemente a entregar múltiples registros A para un dominio. Pero es cierto que el uso inteligente de DNS es un componente crítico en cualquier sistema global de alta disponibilidad. Lo anterior ilustra una forma común (a menudo la mejor) de hacerlo.

Editar: El documento de Google "Más allá de la información de ruta de extremo a extremo para optimizar el rendimiento de CDN" me parece lo último en distribución de carga global para el mejor rendimiento del usuario final.

Edición 2: leí el artículo "Por qué DNS basado ... GSLB ... no funciona" con el que OP se vinculó, y es una buena descripción general. Recomiendo mirarlo. Léelo desde arriba.

En la sección "La solución al problema de almacenamiento en caché del navegador", aboga por las respuestas DNS con múltiples registros A que apuntan a múltiples centros de datos como la única solución posible para la conmutación por error instantánea.

En la sección "Diluirlo" cerca de la parte inferior, se expande en lo obvio, que el envío de múltiples registros A no es bueno si apuntan a centros de datos en varios continentes, porque el cliente se conectará al azar y, por lo tanto, a menudo se vuelve "lento" DC en otro continente. Por lo tanto, para que esto funcione realmente bien, se necesitan múltiples centros de datos en cada continente.

Esta es una solución diferente a mis pasos 1 - 6. No puedo proporcionar una respuesta perfecta sobre esto, creo que se necesita un especialista en DNS de personas como Akamai o Google, porque gran parte de esto se reduce a conocimientos prácticos sobre las limitaciones de los cachés y navegadores DNS implementados hoy AFAIK, mis pasos 1-6 son lo que Akamai hace con su DNS (¿alguien puede confirmar esto?).

Mi sensación, proveniente de haber trabajado como PM en portales de navegador móvil (teléfonos celulares), es que la diversidad y el nivel de quiebra total de los navegadores son increíbles. Personalmente, no confiaría en una solución HA que requiera que el terminal de usuario final 'haga lo correcto'; Por lo tanto, creo que la conmutación instantánea global sin interrumpir una sesión no es factible hoy en día.

Creo que mis pasos 1-6 anteriores son los mejores que están disponibles con la tecnología de productos básicos. Esta solución no tiene una conmutación por error instantánea.

Me encantaría que uno de esos especialistas en DNS de Akamai, Google, etc. venga y demuestre que estoy equivocado. :-)

Su pregunta es: "¿Es DNS Round Robin la ÚNICA forma de asegurar una conmutación por error instantánea?"

La respuesta es: "DNS Round Robin NUNCA es la forma correcta de garantizar una conmutación por error instantánea".

(al menos no solo)

La forma correcta de lograr una conmutación por error instantánea es usar el enrutamiento BGP4 de modo que ambos sitios usen las mismas direcciones IP. Al usar esto, las tecnologías de enrutamiento central de Internet se utilizan para enrutar las solicitudes al centro de datos correcto, en lugar de utilizar la tecnología de direccionamiento central de Internet .

En la configuración más simple, esto solo proporciona conmutación por error. También se puede usar para proporcionar Anycast, con la advertencia de que los protocolos basados ​​en TCP fallarán en el momento del cambio si hay alguna inestabilidad en el enrutamiento.

Entonces, ¿es cierto que, con múltiples centros de datos y tráfico HTTP, el uso de DNS RR es la ÚNICA manera de asegurar una alta disponibilidad?

Claramente, es una afirmación falsa: solo tiene que mirar a Google, Akamai, Yahoo, para ver que no están usando respuestas de round-robin [*] como su única solución (algunos pueden usarlo en parte, junto con otros enfoques .)

Hay muchas opciones posibles, pero realmente depende de las otras restricciones que tenga, con su servicio / aplicación en cuanto a la que elija.

Es posible utilizar técnicas round-robin en un enfoque de servidor simple y compartido, y no tener que preocuparse por la falla del servidor, si también se arregla para la 'conmutación por error' de la dirección IP. (Pero la mayoría opta por técnicas de equilibrio de carga, una sola dirección IP y conmutación por error entre equilibradores de carga).

¿Quizás necesite todas las solicitudes para que una sola sesión vaya a los mismos servidores, pero desea que las solicitudes se distribuyan en diferentes grupos de servidores regionales? Round robin no es apropiado, para eso: debe hacer algo que garantice que un cliente determinado acceda al mismo clúster de servidores físicos cada vez (excepto cuando ocurran 'excepciones', como una falla del servidor). O reciben una dirección IP coherente de una consulta DNS o se enrutan al mismo clúster de servidores físicos. Las soluciones para eso incluyen varios "equilibradores de carga" DNS comerciales y no comerciales, o (si tiene más control de su red) anuncios de red BGP. Simplemente puede hacer arreglos para que los servidores de nombres de su propio dominio den respuestas completamente diferentes (pero, como las solicitudes de DNS se pueden enviar a todas partes, ganó '

[* Voy a usar "round-robin", porque 'RR' en la terminología DNS significa "registro de recursos".]

Muy buena observación vmiazzo +1 para ti !! Estoy atrapado exactamente donde estás ... desconcertado con la forma en que estos CDN hacen su magia.

Los siguientes son mis conjeturas sobre cómo CDN ejecuta su red:

• Use Anycast DNS (mencionado por Jesper Mortensen) para obtener el centro de datos más cercano
• Ejecutan una red local que abarca diferentes centros de datos que les permite hacer algo como CARP en sus hosts en diferentes centros de datos.

O

• Emplean el Protocolo de equilibrio de carga de la puerta de enlace en sus enrutadores o el Protocolo de enrutador de espera en caliente (HSRP) . que se ocupan de la interrupción del centro de datos.
• La razón por la que incluyen IP múltiples es para que el cliente vuelva a intentarlo, y para cuando el cliente vuelva a intentarlo, la ruta de enrutamiento podría haber cambiado.

En el momento siguiente, la solución funciona para mí: - DNS devuelve IP múltiple, por ejemplo:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Último punto de entrada a un proxy inverso en Amazon Cloud, que pasa de manera inteligente al servidor disponible (o proporciona en la página de mantenimiento)

El proxy inverso todavía recibe un golpe pero es tan pesado como el principal.

¿Por qué RFC 2782 (aplicar lo mismo que MX / prioridad para servicios como http, imap, ...) no se implementa en ningún tipo de navegador? Las cosas serían más fáciles ... ¡Hay un error al respecto, abierto durante diez años en Mozilla! ¿Porque será el fin de la industria del balanceador de carga comercial? Estoy muy decepcionado por eso.

2 - Puedes hacer esto con Anycast usando Quagga

(Incluso si hay alguna información de que Anycast es malo con TCP, hay varias grandes compañías que lo usan como CacheFly)

Me pregunto cuántas personas que responden estas preguntas están ejecutando una gran red mundial de servidores. Google está usando round robin y mi compañía lo ha estado usando durante años. Puede funcionar bastante bien, con algunas limitaciones. Sí, debe aumentarse con otras medidas.

La clave real es estar dispuesto a aceptar un hipo o dos si un servidor deja de funcionar. Cuando desconecto un servidor, si un navegador está intentando acceder a ese servidor, habrá un retraso de aproximadamente un minuto mientras el navegador se entera de que la dirección IP está inactiva. Pero luego va a otro servidor muy rápidamente.

Funciona muy bien, y las personas que afirman que causa muchos problemas no saben de qué están hablando. Solo requiere el diseño correcto.

La conmutación por error es una mierda. La mejor HA utiliza todos los recursos todo el tiempo.

He estado trabajando con HA desde 1986. Realicé una amplia capacitación para crear sistemas de conmutación por error y no soy fanático de la conmutación por error.

Además, RR funciona para distribuir la carga, incluso de forma pasiva en lugar de activa. Nuestros registros del servidor muestran claramente el porcentaje apropiado de tráfico en cada servidor, dentro de lo razonable.

Otra opción muy simple es usar un TTL bajo (qué tan bajo depende de sus necesidades) en el registro DNS A o CNAME y actualizar este registro para elegir qué IP se usará.

Tenemos 2 ISP y varios servicios públicos y estamos utilizando con éxito este método para una alta disponibilidad a partir de 3 años.

Una de las claves en las obras es que varios ISP tienen resolvers mal configurados que almacenan en caché los registros durante un intervalo establecido e ignoran por completo la configuración TTL. No debería ser así y no hay excusa para ello, pero lamentablemente, según mi experiencia con la migración de numerosos sitios web y servicios, sucede.

TCP Anycast es realmente muy estable y es utilizado al menos por CacheFly (desde 2002), Prolexic y BitGravity. Se realizó una buena presentación sobre TCP Anycast en NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Múltiples registros A es la única forma de eliminar un posible punto único de falla. Cualquier otra solución obliga a todas las solicitudes entrantes a pasar por un solo dispositivo en algún lugar entre el servidor y el cliente.

Entonces, para una redundancia absoluta, es necesario. Es por eso que google lo hace, o cualquier otra persona que quiera estar seguro de la disponibilidad continua del servicio.

Es bastante obvio por qué este es el caso ... múltiples registros A son la única forma de mover el punto en el que las solicitudes se enrutan al navegador del cliente. Cualquier otro método dependerá de un punto único entre el navegador del cliente y el servidor en el que puede producirse una falla, lo que derribaría su servicio. Al usar registros A, el único punto único de falla del cliente al servidor se convierte en el cliente mismo.

Si no tiene múltiples registros A configurados, está solicitando tiempo de inactividad ...

Sin embargo, obviamente no se puede confiar en este método para el equilibrio de carga.