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

Según 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 subredes diferentes 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 se cae?

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 tener mérito. ¿Algún comentario?

Por "conmutación por error DNS" entiendo que se refiere a DNS Round Robin combinado con algo de monitoreo, es decir, publicar múltiples 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 viable para sitios web pequeños y con menos tráfico.

Por diseño, cuando responde 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 consultarme". Los inconvenientes provienen de esto:

• Con la conmutación por error de DNS, un porcentaje desconocido de sus usuarios tendrá sus datos DNS en caché con cantidades variables de TTL restantes. Hasta que caduque el TTL, estos pueden conectarse al servidor muerto. Hay formas más rápidas de completar la conmutación por error que esta.
• Debido a lo anterior, está inclinado a establecer el TTL bastante bajo, digamos 5-10 minutos. Pero establecerlo más alto brinda un beneficio de rendimiento (muy pequeño) y puede ayudar a que su propagación de DNS funcione de manera confiable, incluso si hay una pequeña falla en el tráfico de red. Por lo tanto, el uso de la conmutación por error basada en DNS va en contra de 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 actividad implican:

• Colocando servidores juntos en la misma LAN.
• Coloque la LAN en un centro de datos con planos de red y alimentación de alta disponibilidad.
• Use 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, equilibradores de carga y conmutadores.
• Tenga implementada una estrategia de comunicación para fallas de centros de datos completos y la falla ocasional de un conmutador / servidor de base de datos / otro recurso que no se puede reflejar fácilmente.

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

La conmutación por error de DNS definitivamente funciona muy bien. Lo he estado usando durante muchos años para cambiar manualmente el tráfico entre 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 se pueden cambiar 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 a punto. Puede haber algunos ISP por ahí que ignoren los TTL, y todavía hay algunos usuarios con navegadores antiguos, pero cuando observa el tráfico de millones de visitas por día en 2 ubicaciones de 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.

DNS no se diseñó para la conmutación por error, pero se diseñó con TTL que funcionan de manera sorprendente para las necesidades de conmutación por error cuando se combinan 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 soluciones rápidas basadas en failover de DNS. Debe tener servidores DNS capaces de manejar la carga adicional, y named no lo cortará. Sin embargo, powerdns cumple los requisitos cuando se respalda con bases de datos replicadas 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 de failover automatizada. Zabbix funciona para mí: puedo verificar las interrupciones de varios sistemas Zabbix distribuidos casi instantáneamente, actualizar los registros mysql utilizados por 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, construí 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 zabbix de sitios de alto volumen durante una interrupción, para ver por sí mismo exactamente qué tan bueno es el failover de DNS, envíeme un correo electrónico, estoy más que feliz de compartirlo.

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 de inmediato, incluso si respetan sus TTL, y cuando su sitio vuelve a funcionar, puede generar cierta rareza con las sesiones cuando se agota el tiempo de espera de la caché de DNS de un usuario, y terminan en rumbo. 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).

La opinión predominante es que con DNS RR, cuando una IP se cae, algunos clientes continuarán usando la IP rota durante 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 próxima 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 del comercio, 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. Aplicaciones como navegadores y servidores proxy y 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: lo siento por el enlace roto pero, como nuevo usuario, no puedo publicar más de 1

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

Funciona bien, pero hay al menos tres sutilezas que aprendí por las malas.

1) Los navegadores conmutarán por error de una IP que no funciona a una IP que funcione después de 30 segundos (la última vez que lo verifiqué) si ambos se consideran activos en cualquier DNS en caché disponible para sus clientes. Esto es básicamente algo bueno.

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

2) Si uno de sus servidores de nombres (o una de sus dos geografías por completo) se cae, lo que sirve a su dominio de round-robin, y si el principal se cae, recuerdo vagamente que puede encontrarse con otros problemas tratando de eliminar eso servidor de nombres caído de DNS si no ha configurado su SOA TTL / caducidad para el servidor de nombres en un valor suficientemente bajo también. Podría tener los detalles técnicos incorrectos aquí, pero hay más de una configuración TTL que debe acertar para defenderse realmente contra puntos únicos de falla.

3) Si publica API web, servicios REST, etc., esos navegadores no suelen llamarlos 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 lo pones "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 DNS o si 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, más exactamente cómo son llamados por la aplicación cliente API / REST. (Debajo de las cubiertas, ¿la biblioteca llama a get_addr y cuándo? Si los sockets se bloquean o cierran, ¿la aplicación vuelve a abrir sockets nuevos? ¿Hay algún tipo de lógica de tiempo de espera? Etc., etc.)

Es barato, bien probado y "funciona principalmente". Entonces, como con la mayoría de las cosas, su millaje puede variar.

Hay un montón de personas que nos usan (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 tiempo de inactividad (piense en cosas como Fail Whale de Twitter) ... o simplemente redirigir el tráfico en función de los TTL. Algunas personas pueden pensar que DNS Failover es un gueto ... pero diseñamos seriamente nuestra red con failover desde el principio ... para que funcione tan bien como el hardware. No estoy seguro de cómo lo hace DME, pero tenemos 3 de 17 de nuestros PoP emitidos más cercanos que monitorean su servidor desde la ubicación más cercana. Cuando detecta de dos de los tres que está inactivo, simplemente redirigimos el tráfico a la otra IP. El único tiempo de inactividad es para aquellos que estaban en lo solicitado por 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 equilibrio de carga round robin ... o un equilibrio de carga basado en geo. 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 ... redirigirá el tráfico al más rápido en función de las IP que enlace en sus nombres de host. Nuevamente ... esto funciona en función de los valores que establezca en nuestra UI / API / Portal.

Supongo que mi punto es ... diseñamos dns failover 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 depreciación o el costo del hardware. Espero que eso no me haga parecer cojo por enchufar a Dyn ... hay muchas otras compañías que lo hacen ... Solo estoy hablando desde la perspectiva de nuestro equipo. Espero que esto ayude...

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 de modo que todos los registros A en NS1 apunten el tráfico a las IP para la ubicación A, y en NS2 todos los registros A apunten a las 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 forma, se cargará automáticamente el equilibrio y se conmutará por error si un servidor o un enlace a una ubicación se apaga.

He usado 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 un software simple que extrae automáticamente los registros NS1, actualiza las direcciones IP de un registro para zonas seleccionadas y empuja esas zonas a NS2.

La alternativa es un sistema de conmutación por error basado en BGP. No es fácil de configurar, pero debería ser a 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 IP que sean portátiles y configure la redirección de las IP portátiles a las IP locales.

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

Una opción para la conmutación por error de múltiples centros de datos es capacitar a sus usuarios. Anunciamos a nuestros clientes que proporcionamos 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 si un servidor está inactivo y pueden usar el enlace al otro servidor.

Esto evita totalmente el problema de la conmutación por error de DNS simplemente manteniendo múltiples 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 marcarlos como favoritos si notan que obtienen un mejor rendimiento usando uno u otro . Si uno cae, los usuarios están entrenados para ir al otro servidor.

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 se pueden mitigar. BGP, aunque superior en algunos aspectos no es una solución al 100%, ya sea con una mayor complejidad, probablemente costos adicionales de hardware, tiempos de convergencia, etc.

He descubierto que combinar el equilibrio de carga local (basado en LAN), GSLB y el alojamiento de zona basado en la nube está funcionando bastante bien para cerrar algunos de los problemas normalmente asociados con el equilibrio de carga de DNS.

Todas estas respuestas tienen cierta validez, pero creo que realmente depende de lo que esté haciendo y de su presupuesto. Aquí en CloudfloorDNS, un gran porcentaje de nuestro negocio es DNS y ofrece no solo un DNS rápido, sino también opciones TTL bajas y conmutación por error de DNS. No estaríamos en el negocio si esto no funcionara y funcionara bien.

Si usted es una corporación multinacional con un presupuesto ilimitado en tiempo de actividad, sí, los equilibradores de carga de hardware GSLB y los centros de datos de nivel 1 son excelentes, pero su DNS aún debe ser rápido y sólido. Como muchos de ustedes saben, el DNS es un aspecto crítico de cualquier infraestructura, aparte del nombre de dominio en sí, es el servicio de nivel más bajo en el que se basa cualquier otra parte de su presencia en línea. Comenzando con un registrador de dominio sólido, el DNS es tan crítico como no permitir que su dominio caduque. El DNS se cae, significa que todo el aspecto en línea de su organización también se cae.

Cuando se utiliza la conmutación por error de DNS, los otros aspectos críticos son el monitoreo del servidor (siempre se deben verificar múltiples ubicaciones geográficas desde y siempre múltiples (al menos 3) para evitar falsos positivos) y al administrar los registros DNS correctamente se detecta una falla. Los TTL bajos y algunas opciones con la conmutación por error pueden hacer que este sea un proceso perfecto, y es mejor que despertar a un buscapersonas en el medio de la noche si eres un administrador del sistema.

En general, DNS Failover realmente funciona y puede ser muy asequible. En la mayoría de los casos de nosotros o de la mayoría de los proveedores de DNS administrados, obtendrá Anycast DNS junto con la supervisión y la conmutación por error del servidor por una fracción del costo de las opciones de hardware.

Entonces, la verdadera respuesta es sí, funciona, pero ¿es para todos y para todos los presupuestos? Tal vez no, pero hasta que lo pruebe y haga las pruebas usted mismo, es difícil ignorar si es una empresa pequeña o mediana con un presupuesto de TI limitado que quiere el mejor tiempo de actividad posible.

"y por qué te arriesgas a usarlo para la mayoría de los entornos de producción (aunque es mejor que nada)".

En realidad, "mejor que nada" se expresa mejor como "la única opción" cuando las presencias son geográficamente diversas. Los equilibradores de carga de hardware son excelentes para un único punto de presencia, pero un solo punto de presencia también es un único punto de falla.

Hay muchos sitios importantes que utilizan la manipulación de tráfico basada en DNS con buenos resultados. Son el tipo de sitios que saben por hora si las ventas están bajas. Parece que son los últimos en estar dispuestos a "correr el riesgo de usarlo para la mayoría de los entornos de producción". De hecho, han revisado sus opciones cuidadosamente, seleccionaron la tecnología y pagaron bien por ella. Si pensaran que algo era mejor, se irían en un instante. El hecho de que aún elijan quedarse dice mucho sobre el uso en el mundo real.

La conmutación por error basada en DNS sufre una cierta cantidad de latencia. No hay manera de evitarlo. Pero, sigue siendo el único enfoque viable para la gestión de conmutación por error en un escenario multi-pop. Como única opción, es mucho más que "mejor que nada".

Hoy en día, buenos equilibradores de carga global que funcionan con esa técnica y funcionan bastante bien. Compruebe, por ejemplo, Azure Traffic Manager https://azure.microsoft.com/en-us/services/traffic-manager/

Si desea obtener más información, lea las notas de la aplicación en

http://edgedirector.com

Cubren: conmutación por error, equilibrio de carga global y una gran cantidad de asuntos relacionados.

Si su arquitectura de back-end lo permite, la mejor opción es el equilibrio de carga global con la opción de conmutación por error. De esa manera, todos los servidores y el ancho de banda están en juego tanto como sea posible. En lugar de insertar un servidor adicional disponible en caso de falla, esta configuración retira un servidor fallido del servicio hasta que se recupera.

La respuesta corta: funciona, pero hay que entender las limitaciones.

Creo que la idea de la conmutación por error estaba destinada a la agrupación en clúster, pero debido a que también podía ejecutarse en solitario, todavía era posible operar en una disponibilidad individual.

Le recomendaría que A, seleccione un centro de datos que sea multihomed en su propio AS, o B, aloje sus servidores de nombres en una nube pública. Es REALMENTE improbable que EC2, HP o IBM se caigan. Solo un pensamiento. Si bien DNS funciona como una solución, en este caso es simplemente una solución a un diseño deficiente en la base de la red.

Otra opción, dependiendo de su entorno, es usar una combinación con IPSLA, PBR y FHRP para satisfacer sus necesidades de redundancia.