domain-name-system – Múltiples centros de datos y tráfico HTTP: DNS Round Robin es la ÚNICA forma de asegurar una conmutación por error instantánea.

Pregunta:

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

La advertencia habitual contra DNS RR es que no es bueno para alta disponibilidad. Cuando 1 IP deja de funcionar, los clientes seguirán utilizá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. Lea 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 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 asegurar una falla instantánea 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 la sesión por una conmutación por error instantánea.
  • AFAIK, la única forma de que un DNS sugiera un centro de datos en lugar de otro es responder solo con la IP (o IP) asociadas a ese centro de datos. Si el centro de datos se vuelve inalcanzable, todas esas IP también lo serán. Esto significa que, incluso si los navegadores HTML inteligentes pueden probar instantáneamente otro registro A, todos los intentos fallarán hasta que la entrada de la caché local expire y se realice una nueva búsqueda de DNS, obteniendo las nuevas IP de trabajo (supongo que DNS sugiere automáticamente a un nuevo centro de datos cuando uno falla). Por lo tanto, el "DNS inteligente" no puede garantizar una conmutación por error instantánea.
  • Por el contrario, una operación por turnos de DNS lo permite. Cuando falla un centro de datos, los navegadores HTML inteligentes (la mayoría de ellos) intentan instantáneamente que los otros registros A almacenados en caché salten a otro centro de datos (en funcionamiento). Por lo tanto, el round-robin de DNS no asegura la afinidad de sesión o el RTT más bajo, pero parece ser la única forma de asegurar una conmutación por error instantánea cuando los clientes son navegadores HTML "inteligentes".

Edición 2:

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

Edición 3: *

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

Respuesta:

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

Pero esa no es la única forma en que se puede utilizar el DNS para lograr una 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 que es:

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

El uso de anycast para DNS generalmente está bien, porque las respuestas de DNS no tienen estado y son casi extremadamente cortas. Entonces, 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 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 utilizar junto con la configuración anterior. Por lo general, se usa para distribuir la carga de tráfico entre múltiples balanceadores de carga de alta disponibilidad en cada centro de datos (para que pueda obtener una mejor redundancia, usar balanceadores 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 forma de asegurar una alta disponibilidad?

No, no es cierto, no si por 'DNS Round Robin' simplemente nos referimos 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 manera común (a menudo la mejor) de hacerlo.

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

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

En la sección "La solución al problema del almacenamiento en caché del navegador", aboga por respuestas de DNS con varios registros A que apuntan a varios 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 amplía lo obvio, que enviar varios 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á una "lentitud". 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 dar una respuesta perfecta a esto, 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 navegadores y cachés de DNS implementados en la actualidad. AFAIK, mis pasos 1-6 son los que hace Akamai con su DNS (¿alguien puede confirmar esto?).

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

Creo que los pasos del 1 al 6 anteriores son los mejores que están disponibles con la tecnología básica. Esta solución no tiene conmutación por error instantánea.

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

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım