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


Los registros múltiples A que apuntan al mismo dominio parecen ser utilizados 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 una alta disponibilidad. Cuando se desactiva 1 IP, los clientes continuarán usándola 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. Leer aquí el capítulo 3.1 y aquí.

  2. Cuando hay varios centros de datos involucrados, DNS RR es la única opción para distribuir el tráfico a través de ellos.

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 un failover instantáneo cuando un centro de datos falla?

Gracias,

Valentino

Editar:

  • Por supuesto, cada centro de datos tiene un Load Balancer local con repuesto dinámico.
  • Está bien sacrificar la afinidad de sesión para 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, todas esas IP también son inalcanzables. Esto significa que, incluso si los navegadores de HTML inteligentes pueden intentar instantáneamente otro registro A, todos los intentos fallarán hasta que la entrada de la caché local caduque y se realice una nueva búsqueda de DNS, obteniendo las nuevas IP de trabajo (supongo que el DNS sugiere automáticamente una nuevo centro de datos cuando uno falla). Por lo tanto, el "DNS inteligente" no puede asegurar una conmutación instantánea.
  • A la inversa un DNS round-robin lo permite. Cuando un centro de datos falla, los navegadores HTML inteligentes (la mayoría de ellos) intentan instantáneamente que los otros A almacenados en caché salten a otro centro de datos (en funcionamiento). Por lo tanto, DNS round-robin no asegura la afinidad de sesión o el RTT más bajo, pero parece ser la única forma de asegurar un fallo instantáneo cuando los clientes son navegadores HTML "inteligentes".

Edición 2:

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

Edición 3: *

  • Hice algunas búsquedas de DNS y traceroutes (tal vez algún experto puede verificar dos veces) 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 ser utilizados como proxies inversos. Por lo tanto, no se pueden utilizar para otorgar conmutación por error instantánea.
    • Akamai y LimeLight parecen usar DNS con reconocimiento geográfico. ¡Pero! Devuelven múltiples registros A De traceroutes parece que las direcciones IP devueltas están en el mismo centro de datos. Por lo tanto, me sorprende cómo pueden ofrecer un SLA del 100% cuando un centro de datos falla.

76
2017-09-30 08:44


origen


Con alta disponibilidad impliqué conmutación casi instantánea. El cliente no debería notar ningún problema, incluso si un centro de datos falla. Refiné la pregunta. - Valentino Miazzo
MaxCDN usa el TCP anycast y sus bordes se pueden usar en el modo de proxy de almacenamiento en caché ("búsqueda de origen" en la terminología de la industria de CDN). - rmalayter
@vmiazzo, tu enlace pdf está caído ... ¿Quieres decir 15 minutos o 20 segundos a 15 minutos? - Pacerier


Respuestas:


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

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

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

  1. Una red global de servidores DNS 'inteligentes',
  2. y un conjunto de centros de datos a nivel mundial,
  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. de manera que la la solicitud de DNS del usuario fluye al servidor DNS más cercano a través de IP Anycast,
  6. y esto El servidor DNS distribuye un registro A de TTL bajo / un conjunto de registros A para el más cercano / mejor centro de datos para este usuario final a través del DNS de horizonte dividido 'inteligente'.

El uso de anycast para DNS generalmente está bien, porque las respuestas de DNS son sin estado y casi extremadamente cortas. Por lo tanto, si las rutas BGP cambian, es muy poco probable que interrumpa una consulta de 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; por lo general, no puede conmutar a otro centro de datos sin interrumpir la sesión.

Como indiqué con el "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 balanceadores de carga de alta disponibilidad en cada centro de datos (para que pueda obtener una mejor redundancia, use balanceadores de carga más pequeños / baratos, no abrume los buffers de red Unix de un solo servidor host, etc.).

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

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

Editar: El papel de google "Ir más allá de la información de ruta de extremo a extremo para optimizar el rendimiento de CDN" Me parece que es el estado de la técnica en distribución de carga global para el mejor rendimiento del usuario final.

Edición 2: Lei el articulo "Por qué DNS basado ... GSLB ... no funciona" a ese enlace OP, y es una buena visión general, recomiendo verlo. Léalo desde la parte superior.

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

En la sección "Regándola" cerca de la parte inferior, se expande lo obvio, que el envío de múltiples registros A no es genial si apuntan a centros de datos en varios continentes, porque el cliente se conectará al azar y, por lo tanto, a menudo obtendrá un "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 la de mis pasos 1 a 6. No puedo dar una respuesta perfecta, creo que se necesita un especialista en DNS como Akamai o Google, porque gran parte de esto se reduce a conocimientos prácticos sobre las limitaciones de los cachés y navegadores de DNS desplegados 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 teléfonos móviles (teléfonos celulares), es que la diversidad y el nivel de rotura total De los navegadores que hay es increíble. Personalmente, no confiaría en una solución de alta disponibilidad que requiera que el terminal del usuario final "haga lo correcto"; por lo tanto, creo que el fallo instantáneo global sin interrumpir una sesión no es posible hoy.

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 conmutación instantánea.

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


34
2017-09-30 10:56



Agregué más explicaciones en la pregunta. Si entiendo su "mejor técnica de equilibrio de carga" (punto 6), anuncia solo los registros A del "mejor" centro de datos. Como intenté explicar en la pregunta, esto no permite la conmutación instantánea en el cliente. - Valentino Miazzo
@vmiazzo: Sí, me entendiste correctamente. Estoy agregando una segunda edición a mi publicación para aclarar, pero básicamente creo que el fallo instantáneo que busca no es práctico / imposible. - Jesper Mortensen
Lo que me parece interesante es que nadie ha sugerido combinar los dos enfoques juntos. Si bien no es ideal, proporcionaría una velocidad razonable cuando las cosas funcionan correctamente y una resistencia adicional cuando no lo hacen. La penalización sería un gran retraso a medida que los clientes cambiaban de una dirección DNS basada en cualquier difusión a otra. - Avery Payne
@JesperMortensen, cuando dice DNS 'inteligente', ¿quiere decir DNS de horizonte dividido? ¿O te refieres a otra cosa (decidir en base a factores más allá IP de origen)? - Pacerier


Su pregunta es: "¿Es DNS Round Robin la ÚNICA forma de asegurar un fallo instantáneo?"

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

(al menos no por su cuenta)

La forma correcta de lograr una conmutación por error instantánea es usar el enrutamiento BGP4 de modo que ambos sitios utilicen las mismas direcciones IP. Usando esto el núcleo de internet enrutamiento las tecnologias estan acostumbradas a ruta las solicitudes al centro de datos correcto, en lugar de utilizar el núcleo de Internet direccionamiento tecnología.

En la configuración más simple esta solamente proporciona la conmutación por error. También se puede utilizar para proporcionar a 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.


18
2017-09-30 16:04



Se agregó información sobre la conmutación por error de Anycast en la pregunta. Básicamente también TCP Anycast no es una solución perfecta. - Valentino Miazzo
@vmiazzo re TCP Anycast - de hecho, de ahí la nota en mi respuesta sobre la inestabilidad del enrutamiento y cómo afecta a TCP. - Alnitak


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 tienes que mirar a Google, Akamai, Yahoo, para ver que no están utilizando las 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 qué otras restricciones tenga, con su servicio / aplicación en cuanto a lo que elija.

Es posible usar técnicas de round-robin en un enfoque de servidor simple y de ubicación conjunta, y no tener que preocuparse por la falla del servidor, si también se organiza el 'fail-over' de la dirección IP. (Pero la mayoría opta por técnicas de equilibrio de carga, una única dirección IP y conmutación por error entre equilibradores de carga).

¿Es posible que necesite todas las solicitudes de una sola sesión para ir 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 cualquier cliente dado acceda al mismo clúster de servidores físicos cada vez (excepto cuando se producen "excepciones", como una falla del servidor). O bien reciben una dirección IP consistente de una consulta de DNS o se enrutan al mismo clúster de servidores físicos. Las soluciones para eso incluyen varios "balanceadores de carga" de DNS comerciales y no comerciales, o (si tiene más control de su red) anuncios de red de BGP. Simplemente puede organizar que los servidores de nombres de su propio dominio den respuestas completamente diferentes (pero, como las solicitudes de DNS pueden enviarse a todas partes, no logrará ninguna afinidad de ubicación con ese enfoque).

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


6
2017-09-30 09:47



Agregué más explicaciones en la respuesta. Su sugerencia de usar "balanceadores de carga" de DNS no permite la conmutación instantánea de fallos. Sobre el BGP, ¿te refieres a una solución Anycast TCP? - Valentino Miazzo
No estoy sugiriendo ninguna solución en particular sobre otra. Estoy diciendo que debe elegir la solución correcta para su problema (que en realidad no ha expresado en su pregunta) y sus restricciones (ídem). DNS round-robin sí no proporciona una conmutación por error instantánea más que DNS LB, porque no se garantiza que los navegadores hagan "lo correcto" (principalmente porque lo "correcto" no está estrictamente definido o prescrito. No creo que haya suficientes "inteligentes" Los navegadores HTML ", incluso ahora, estoy de acuerdo con Jesper en que son muy variados en sus comportamientos como para confiar en ellos.) - jrg
Entiendo tu escepticismo. De todos modos, como podéis leer aquí. crypto.stanford.edu/dns/dns-rebinding.pdf la mayoría de los navegadores HTML actuales ya son "inteligentes". - Valentino Miazzo


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

A continuación, mi conjetura sobre cómo CDN ejecuta su red:

  • Utilice Anycast DNS (mencionado por Jesper Mortensen) para obtener el centro de datos más cercano
  • Corren un red local que abarcan diferentes centros de datos que les permiten hacer algo como CARPA en sus hosts a través de diferentes centros de datos

O

En el momento siguiente me funciona la solución: - 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
  • El último punto de entrada a un proxy inverso en la nube de Amazon, que pasa de manera inteligente al servidor disponible (o se proporciona en la página de mantenimiento)

El proxy inverso todavía es golpeado pero el bot es tan pesado como el principal.


5
2017-12-14 08:15



El orden de los múltiples registros de DNS que los clientes recibirán es aleatorizado de manera intencional, por lo que su proxy inverso probablemente será golpeado alrededor de 1/6 del tiempo (1/2 de 1/3). ¿Cómo es eso mejor o diferente que tener registros de 6 A? - ColinM


¿Por qué RFC 2782 (se aplica igual 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, abierto por diez años en Mozilla !!! ¿Porque será el fin de la industria del equilibrador de carga comercial? Estoy muy decepcionado por eso.


3
2018-04-16 15:05





2 - Puedes hacer esto con Anycast utilizando Quagga

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


2
2017-09-30 09:08



Absolutamente, pero no puedes hacer eso con los servidores alquilados, necesitas tu propia red. - Julien Tartarin
Se agregó información sobre la conmutación por error de Anycast en la pregunta. Básicamente también TCP Anycast no es una solución perfecta. - Valentino Miazzo


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

La verdadera clave es estar dispuesto a aceptar un problema o dos si un servidor falla. Cuando desconecto el enchufe de un servidor, si un navegador está tratando de acceder a ese servidor, habrá una demora de aproximadamente un minuto mientras el navegador descubre 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 apesta. La mejor HA usa todos los recursos todo el tiempo.

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

Además, RR trabaja 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.


2
2017-07-19 14:34





Otra opción muy simple es utilizar un TTL bajo (según el nivel 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.


1
2017-09-30 09:19



Agregué más explicaciones en la pregunta. Muchos navegadores HTML ignoran DNS TTL (fijación de DNS), consulte el documento vinculado en la pregunta. Cambiar la configuración de DNS cuando un centro de datos se desactiva no permite una conmutación instantánea en el cliente. - Valentino Miazzo