Pregunta ¿Por qué no se recomienda la conmutación por error de DNS?


De la lectura, parece que la conmutación por error de DNS no se recomienda solo porque DNS no fue diseñado para ello. Pero si tiene dos servidores web en diferentes subredes que alojan contenido redundante, ¿qué otros métodos existen para garantizar que todo el tráfico se enrute al servidor en vivo si un servidor deja de funcionar?

Para mí, parece que la conmutación por error de DNS es la única opción de conmutación por error aquí, pero el consenso es que no es una buena opción. Sin embargo, servicios como DNSmadeeasy.com lo proporcionan, por lo que debe haber mérito. ¿Algún comentario?


166
2017-08-30 17:57


origen


Mira aquí para una discusión actualizada sobre el tema. La conmutación por error ahora se realiza automáticamente por los navegadores modernos. - GetFree


Respuestas:


Por 'DNS failover', entiendo que se refiere a DNS Round Robin combinado con algo de monitoreo, es decir, publicar varias direcciones IP para un nombre de host DNS, y eliminar una dirección muerta cuando el monitoreo detecta que un servidor está inactivo. Esto puede ser factible para sitios web pequeños con menos tráfico.

Por diseño, cuando responde a una solicitud de DNS, también proporciona un Tiempo de vida (TTL) para la respuesta que entrega. En otras palabras, le está diciendo a otros servidores DNS y cachés "puede almacenar esta respuesta y usarla durante x minutos antes de volver a consultar conmigo". Los inconvenientes vienen de esto:

  • Con la conmutación por error de DNS, un porcentaje desconocido de sus usuarios tendrá sus datos de DNS en caché con cantidades variables de TTL a la izquierda. Hasta que el TTL caduque, estos pueden conectarse al servidor muerto. Hay formas más rápidas de completar la conmutación por error que esto.
  • Debido a lo anterior, está inclinado a establecer el TTL bastante bajo, digamos 5-10 minutos. Sin embargo, si lo establece más alto, obtendrá un beneficio (muy pequeño) en el rendimiento, y puede ayudar a que la propagación de su DNS funcione de manera confiable, incluso si hay un pequeño fallo en el tráfico de la red. Por lo tanto, el uso de la conmutación por error basada en DNS va contra los TTL altos, pero los TTL altos son parte de DNS y pueden ser útiles.

Los métodos más comunes para obtener un buen tiempo de funcionamiento incluyen:

  • Colocando servidores juntos en la misma LAN.
  • Coloque la LAN en un centro de datos con alta disponibilidad de energía y planos de red.
  • Utilice un equilibrador de carga HTTP para distribuir la carga y conmutar por error en fallas de servidores individuales.
  • Obtenga el nivel de redundancia / tiempo de actividad esperado que necesita para sus firewalls, balanceadores de carga y switches.
  • Establezca una estrategia de comunicación para las fallas del centro de datos completo, y la falla ocasional de un conmutador / servidor de base de datos / otro recurso que no se pueda reflejar fácilmente.

Una minoría muy pequeña de sitios web utiliza configuraciones de centros de datos múltiples, con 'equilibrio geográfico' entre centros de datos.


93
2017-08-30 18:39



Creo que está tratando específicamente de gestionar la conmutación por error entre dos centros de datos diferentes (tenga en cuenta los comentarios sobre diferentes subredes), por lo que colocar los servidores juntos / usar balanceadores de carga / redundancia adicional no lo ayudará (aparte de los centros de datos redundantes. Pero usted aún necesito decirle a internet que vaya a la que todavía está arriba). - Cian
Agregue anycast a la configuración del centro de datos múltiple y se convierte en una prueba de falla del centro de datos. - petrus
entrada de wikipedia en anycast (en.wikipedia.org/wiki/Anycast) discute esto en relación con la resiliencia del servidor raíz DNS. - dunxd
Los ataques DDoS son tan comunes ahora que los centros de datos completos pueden desconectarse (sucedió en Linode London y sus otros centros de datos en diciembre de 2015). Por lo tanto, no se recomienda utilizar el mismo proveedor en el mismo centro de datos. Por lo tanto, varios centros de datos con diferentes proveedores serían una buena estrategia, lo que nos lleva de nuevo a la conmutación por error de DNS a menos que exista una mejor alternativa. - Laurence Cope
¿No es así por qué existe una conmutación por error, ya que necesita mantener su sitio activo cuando un dispositivo está inactivo / defectuoso? ¿De qué servirá la conmutación por error cuando esté en la misma red que comparte los mismos dispositivos, por ejemplo? enrutadores? - user2128576


La conmutación por error de DNS definitivamente funciona muy bien. Lo he estado utilizando durante muchos años para cambiar manualmente el tráfico entre los centros de datos, o automáticamente cuando los sistemas de monitoreo detectaron interrupciones, problemas de conectividad o servidores sobrecargados. Cuando vea la velocidad a la que funciona y los volúmenes de tráfico del mundo real que pueden cambiarse con facilidad, nunca mirará hacia atrás. Utilizo Zabbix para monitorear todos mis sistemas y los gráficos visuales que muestran lo que sucede durante una situación de conmutación por error de DNS ponen todas mis dudas y terminan. Es posible que haya algunos proveedores de servicios de Internet (ISP) que ignoran los TTL, y hay algunos usuarios que todavía tienen navegadores antiguos, pero cuando observa el tráfico de millones de visitas a la página por día en 2 centros de datos y realiza un cambio de tráfico de DNS: el tráfico residual que entra y que ignora los TTL es ridículo. La conmutación por error de DNS es una técnica sólida.

El DNS no fue diseñado para la conmutación por error, pero fue diseñado con TTL que funcionan de manera sorprendente para las necesidades de la conmutación por error cuando se combina con un sistema de monitoreo sólido. Los TTL se pueden configurar muy cortos. He utilizado efectivamente TTL de 5 segundos en producción para aligerar las soluciones basadas en failover DNS rápidas. Debe tener servidores DNS capaces de manejar la carga adicional, y el nombre no lo cortará. Sin embargo, powerdns encaja a la perfección cuando está respaldado con una base de datos replicada de mysql en servidores de nombres redundantes. También necesita un sistema de monitoreo distribuido sólido en el que pueda confiar para la integración automatizada de conmutación por error. Zabbix funciona para mí: puedo verificar las interrupciones de los sistemas distribuidos de Zabbix de forma casi instantánea, actualizar los registros mysql utilizados por las powerdns sobre la marcha y proporcionar una conmutación por error casi instantánea durante las interrupciones y los picos de tráfico.

Pero bueno, creé una empresa que proporciona servicios de conmutación por error de DNS después de años de hacer que funcione para grandes empresas. Así que toma mi opinión con un grano de sal. Si desea ver algunos gráficos de tráfico de zabbix de sitios de gran volumen durante una interrupción, para ver exactamente cómo funciona la conmutación por error de DNS, envíeme un correo electrónico que estoy más que contento de compartir.


44
2017-10-20 17:17



La respuesta de cian serverfault.com/a/60562/87017 contradice directamente tu uno ... entonces, ¿quién tiene razón? - Pacerier
Es mi experiencia que los TTL cortos NO FUNCIONAN a través de Internet. Es posible que esté ejecutando servidores DNS que respeten los RFC, pero hay muchos servidores que no lo hacen. Por favor, no asuma que este es un argumento en contra de Round Robin DNS (vea también la respuesta de vmiazzo a continuación). Corrí sitios ocupados usando RR DNS y lo probé, funciona. Los únicos problemas que encontré fueron con algunos clientes basados ​​en Java (no con navegadores) que ni siquiera intentaron reconectarse en caso de fallo, y mucho menos realizar un ciclo de la lista de hosts en un RST - symcbean
Apuesto a que las personas que dicen que el failover de DNS monitoreado es excelente y las personas que dicen que apesta están teniendo experiencias similares, pero con diferentes expectativas. La conmutación por error de DNS NO es perfecta, pero SÍ evita tiempos de inactividad significativos. Si necesita un acceso completamente transparente (nunca pierda una sola solicitud, incluso durante una falla del servidor), probablemente necesite una arquitectura mucho más sofisticada y costosa. Eso no es un requisito para muchas aplicaciones. - Tom Wilson


El problema con la conmutación por error de DNS es que, en muchos casos, no es confiable. Algunos ISP ignorarán sus TTL, no sucede inmediatamente, incluso si respetan sus TTL, y cuando su sitio vuelve a aparecer, puede ocasionar cierta extrañeza en las sesiones cuando el caché de DNS del usuario se agota, y terminan encabezando al otro servidor.

Desafortunadamente, es prácticamente la única opción, a menos que sea lo suficientemente grande como para hacer su propio enrutamiento (externo).


31
2017-08-30 18:27



+1 lento y poco fiable - Chris S
Ver también serverfault.com/q/315199/87017 - Pacerier


La opinión predominante es que con DNS RR, cuando se cae una IP, algunos clientes continuarán usando la IP rota por minutos. Esto se afirmó en algunas de las respuestas anteriores a la pregunta y también se escribió en Wikipedia.

De todas formas,

http://crypto.stanford.edu/dns/dns-rebinding.pdf explica que no es cierto para la mayoría de los navegadores HTML actuales. Intentarán la siguiente IP en segundos.

http://www.tenereillo.com/GSLBPageOfShame.htm Parece ser aún más fuerte:

El uso de múltiples registros A no es un truco comercial, o una característica concebida por los proveedores de equipos de equilibrio de carga. El protocolo DNS fue diseñado con soporte para múltiples registros A por esta misma razón. Las aplicaciones como los navegadores y servidores proxy y los servidores de correo hacen uso de esa parte del protocolo DNS.

Tal vez algún experto pueda comentar y dar una explicación más clara de por qué DNS RR no es bueno para la alta disponibilidad.

Gracias,

Valentino

PD: perdón por el enlace roto pero, como nuevo usuario, no puedo publicar más de 1


19
2017-09-29 10:06



Se han diseñado varios registros A, pero para equilibrar la carga, en lugar de para la conmutación por error. Los clientes almacenarán en caché los resultados y continuarán usando la agrupación completa (incluida la IP rota) durante unos minutos después de cambiar el registro. - Cian
Entonces, es lo que se escribe en crypto.stanford.edu/dns/dns-rebinding.pdf capitulo 3.1 falso? << Internet Explorer 7 fija los enlaces DNS durante 30 minutos.1 Desafortunadamente, si el dominio del atacante tiene varios registros A y el servidor actual deja de estar disponible, el navegador intentará una dirección IP diferente dentro de un segundo. >> - Valentino Miazzo
Moví mi subpregunta aquí serverfault.com/questions/69870/… - Valentino Miazzo


Ejecuté failover DNS RR en un sitio web de producción de tráfico moderado pero crítico para la empresa (en dos geografías) durante muchos años.

Funciona bien, pero hay al menos tres sutilezas que aprendí de la manera más difícil.

1) Los navegadores cambiarán de una IP que no funciona a una IP funcional después de 30 segundos (la última vez que verifiqué) si ambos se consideran activos en cualquier DNS almacenado en caché que esté disponible para sus clientes. Esto es básicamente una buena cosa.

Pero tener "la mitad" de que los usuarios esperen 30 segundos es inaceptable, por lo que probablemente querrá actualizar sus registros TTL en unos pocos minutos, no en unos pocos días o semanas para que, en caso de una interrupción, pueda eliminar rápidamente el servidor inactivo. de su DNS. Otros han aludido a esto en sus respuestas.

2) Si uno de sus servidores de nombres (o una de sus dos geografías en su totalidad) se desactiva y sirve a su dominio round-robin, y si la principal de ellas falla, recuerdo vagamente que puede encontrar otros problemas al intentar eliminar eso. Si no ha configurado su SOA TTL / vencimiento para el servidor de nombres en un valor suficientemente bajo, también se eliminará el servidor de nombres. Podría tener los detalles técnicos equivocados aquí, pero hay más de una configuración TTL que necesita para defenderse realmente contra puntos únicos de falla.

3) Si publica API web, servicios REST, etc., estos no suelen ser llamados por los navegadores y, por lo tanto, en mi opinión, la conmutación por error de DNS comienza a mostrar fallas reales. Esta puede ser la razón por la que algunos dicen, como usted dice "no se recomienda". He aquí por qué digo eso. Primero, las aplicaciones que consumen esas URL generalmente no son navegadores, por lo que carecen de las propiedades / lógica de conmutación por error de 30 segundos de los navegadores comunes. En segundo lugar, si se llama o no a la segunda entrada de DNS o incluso se vuelve a sondear DNS depende en gran medida de los detalles de programación de bajo nivel de las bibliotecas de red en los lenguajes de programación utilizados por estos clientes API / REST, además de cómo los llaman La aplicación cliente API / REST. (Debajo de ellos, ¿llama la biblioteca a get_addr y cuándo? Si los sockets se cuelgan o se cierran, ¿la aplicación vuelve a abrir sockets nuevos? ¿Hay algún tipo de lógica de tiempo de espera? Etc, etc.)

Es barato, está bien probado y "en su mayoría funciona". Así como con la mayoría de las cosas, su kilometraje puede variar.


11
2018-04-12 01:21



una biblioteca que no vuelve a intentar en los otros RR para una dirección está rota. dirija a los desarrolladores a las páginas del manual para getaddrinfo (), etc. - Jasen


Hay un grupo de personas que nos utilizan (Dyn) para la conmutación por error. Es la misma razón por la que los sitios pueden hacer una página de estado cuando tienen un tiempo de inactividad (piense en cosas como la Whale Fail Ball de Twitter) ... o simplemente redireccionar el tráfico en función de los TTL. Algunas personas pueden pensar que DNS Failover es un ghetto ... pero diseñamos seriamente nuestra red con failover desde el principio ... para que funcionara tan bien como el hardware. No estoy seguro de cómo lo hace DME, pero tenemos 3 de 17 de nuestros PoPs más cercanos y monitoreados desde su ubicación más cercana. Cuando detecta que dos de los tres están inactivos, simplemente redirigimos el tráfico a la otra IP. El único tiempo de inactividad es para aquellos que se solicitaron para el resto de ese intervalo TTL.

A algunas personas les gusta usar ambos servidores a la vez ... y, en ese caso, pueden hacer algo como un balanceo de carga por turnos ... o un balanceo de carga basado en información geográfica. Para aquellos que realmente se preocupan por el rendimiento ... nuestro administrador de tráfico en tiempo real monitoreará cada servidor ... y si uno es más lento ... redireccione el tráfico al más rápido en función de las IP que enlace en sus nombres de host. Nuevamente ... esto funciona según los valores que ha establecido en nuestra UI / API / Portal.

Supongo que mi punto es ... diseñamos la conmutación por error de DNS a propósito. Si bien el DNS no se creó para la conmutación por error cuando se creó originalmente ... nuestra red DNS fue diseñada para implementarlo desde el principio. Por lo general, puede ser tan efectivo como el hardware ... sin la depreciación o el costo del hardware. Espero que eso no me haga sentir mal por conectar a Dyn ... hay muchas otras compañías que lo hacen ... Estoy hablando desde la perspectiva de nuestro equipo. Espero que esto ayude...


9
2018-05-25 19:38



¿Qué quiere decir con "puede ser tan efectivo como el hardware"? ¿Qué tipo de hardware hace el enrutamiento DNS? - mpen
@Ryan, ¿qué quieres decir cuando dices "ghetto"? - Pacerier
Para esa palabra, el diccionario urbano no da definiciones con connotación positiva, debo asumir que "la solución de un mendigo" podría ser una traducción adecuada. - Jasen


Otra opción sería configurar el servidor de nombres 1 en la ubicación A y el servidor de nombres 2 en la ubicación B, pero configurar cada uno para que todos los registros A en el punto NS1 se dirijan a las direcciones IP para la ubicación A, y en el NS2 todos los registros A apunten a las direcciones IP para ubicación B. Luego configure sus TTL para un número muy bajo y asegúrese de que su registro de dominio en el registrador se haya configurado para NS1 y NS2. De esa manera, automáticamente cargará el saldo, y la conmutación por error en caso de que un servidor o un enlace a una ubicación se caiga.

He utilizado este enfoque de una manera ligeramente diferente. Tengo una ubicación con dos ISP y uso este método para dirigir el tráfico a través de cada enlace. Ahora, puede ser un poco más de mantenimiento de lo que está dispuesto a hacer ... pero pude crear una pieza simple de software que extrae automáticamente los registros NS1, actualiza las direcciones IP de registros para zonas seleccionadas y las empuja a zonas NS2.


5
2017-08-07 05:13



¿No toman los servidores de nombres demasiado para propagarse? Si cambia un registro DNS con un TTL bajo, funcionará instantáneamente, pero cuando cambie el servidor de nombres tardará 24 horas o más en propagarse, por lo tanto, no veo cómo esto podría ser una solución de conmutación por error. - Marco Demaio


La alternativa es un sistema de conmutación por error basado en BGP. No es fácil de configurar, pero debería ser una prueba de balas. Configure el sitio A en una ubicación, el sitio B en un segundo, todos con direcciones IP locales, luego obtenga una clase C u otro bloque de direcciones IP que sean portátiles y configure la redirección de las direcciones IP portátiles a las IP locales.

Hay dificultades, pero es mejor que las soluciones basadas en DNS si necesita ese nivel de control.


4
2017-08-30 21:40



Sin embargo, las soluciones basadas en BGP no están disponibles para todos. Y son mucho más fáciles de romper en formas particularmente horribles que el DNS. Columpios y rotondas, supongo. - Cian


Una opción para la conmutación por error de múltiples centros de datos es capacitar a sus usuarios. Nos comunicamos a nuestros clientes que brindamos múltiples servidores en varias ciudades y en nuestros correos electrónicos de registro y que incluyen enlaces directamente a cada "servidor" para que los usuarios sepan que si un servidor está inactivo pueden usar el enlace al otro servidor.

Esto omite totalmente el problema de la conmutación por error de DNS simplemente manteniendo varios nombres de dominio. Los usuarios que visitan www.company.com o company.com e inician sesión se dirigen a server1.company.com o server2.company.com y tienen la opción de marcar cualquiera de ellos si notan que obtienen un mejor rendimiento al usar uno u otro . Si uno se cae, los usuarios están entrenados para ir al otro servidor.


3
2017-10-11 22:11



Capacitar a sus usuarios de esta manera ... ¿Esto no los hace más propensos a ser engañados? - Pacerier


He estado utilizando el equilibrio de sitios basado en DNS y la conmutación por error durante los últimos diez años, y hay algunos problemas, pero esos pueden ser mitigados. BGP, aunque superior en algunos aspectos, no es una solución al 100% con mayor complejidad, probablemente con costos adicionales de hardware, tiempos de convergencia, etc.

Descubrí que la combinación del equilibrio de carga local (basado en LAN), GSLB y el hospedaje de zonas basado en la nube funciona bastante bien para cerrar algunos de los problemas normalmente asociados con el equilibrio de carga de DNS.


2
2017-08-23 01:50