159 votos

¿Por qué no se recomienda el failover de DNS?

A partir de la lectura, parece que la conmutación por error de DNS no está recomendado sólo porque el DNS no está diseñado para ello. Pero si tienes dos servidores web en subredes diferentes de alojamiento de contenido redundante, ¿qué otros métodos existen para asegurar que todo el tráfico se envía al servidor en vivo si un servidor se cae?

A mí me parece como 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 proporcionar, por lo que debe haber mérito para ello. Cualquier comentario?

86voto

Zameer Manji Puntos 1213

Por "conmutación por error de DNS' puedo tomar te refieres DNS Round Robin combinado con algunos de monitoreo, es decir, la publicación de varias direcciones IP para un nombre de host DNS, y la eliminación de un muerto de dirección cuando el monitoreo detecta que un servidor está caído. Esto puede ser viable para los pequeños, menos víctimas de la trata de sitios web.

Por diseño, al responder a una petición de DNS también puede ofrecer un Tiempo De vida (TTL) para la respuesta de la mano. En otras palabras, usted está diciendo a otros servidores DNS y cachés "usted puede almacenar esta respuesta y el uso que por x minutos antes de comprobar de nuevo conmigo". Los inconvenientes provienen de este:

  • Con la conmutación por error de DNS, un porcentaje desconocido de sus usuarios tendrán sus datos de DNS en caché con cantidades variables de TTL a la izquierda. Hasta el TTL estos pueden conectarse a los muertos servidor. Hay maneras más rápidas de la cumplimentación de conmutación por error de este.
  • Debido a lo anterior, usted está inclinado a establecer el período de vida muy bajo, digamos de 5 a 10 minutos. Pero la configuración que más le da a un (muy pequeño) la ventaja de rendimiento, y puede ayudar a su propagación de las DNS de trabajo de forma fiable, incluso si hay un pequeño fallo en el tráfico de la red. Así que el uso de DNS de conmutación por error basada va en contra de alta TTLs, pero de alta TTLs son una parte de los DNS y puede ser útil.

Los métodos más comunes de conseguir un buen tiempo de actividad implica:

  • La ubicación de los servidores juntos en la misma LAN.
  • Lugar de la red LAN en un centro de datos con alta disponibilidad de energía de la red y de los aviones.
  • El uso de un HTTP equilibrador de carga para distribuir la carga y la tolerancia a fallos individuales de fallas en el servidor.
  • Obtener el nivel de redundancia y / o espera de tiempo de actividad que usted requiere para sus firewalls, balanceadores de carga y los interruptores.
  • Tener una estrategia de comunicación en el lugar para todo el centro de datos de fallos y la falta ocasional de un interruptor / servidor de base de datos / otros recursos que no pueden ser a la inversa.

Una muy pequeña minoría de los sitios web utilizan multi-centro de datos de configuraciones, con geo-equilibrio entre los centros de datos.

42voto

Scott McDonald Puntos 275

Conmutación por error de DNS rockera de las grandes obras. He estado utilizando durante muchos años para cambiar de forma manual el tráfico entre los centros de datos, o de forma automática cuando los sistemas de monitoreo detecta las interrupciones, problemas de conectividad, o una sobrecarga en los servidores. Al ver la velocidad a la que trabaja, y los volúmenes de tráfico que se pueden desplazar con facilidad - nunca voy a mirar hacia atrás. Yo uso Zabbix para el seguimiento de todos mis sistemas y la visual de los gráficos que muestran lo que sucede durante una conmutación por error de DNS situación de poner todas mis dudas y final. Puede haber algunos ISPs hay que ignorar TTLs, y hay algunos usuarios todavía existe, con navegadores antiguos - pero cuando usted está buscando en el tráfico de millones de páginas vistas en un día en 2 ubicaciones de centros de datos y hacer un tráfico de DNS cambio - el residual de tráfico que viene en que ignora TTLs es de risa. Conmutación por error de DNS es una técnica sólida.

DNS no fue diseñado para la conmutación por error -, pero fue diseñado con TTLs que funcionan sorprendentemente para la conmutación por error necesidades cuando se combina con un sólido sistema de monitoreo. TTLs puede ser muy corto. He usado efectivamente Ttl de 5 segundos en la producción para el alivio rápido de conmutación por error de DNS basado en soluciones. Usted tiene que tener los servidores DNS es capaz de manejar la carga adicional - y el nombre no se corte. Sin embargo, powerdns se ajusta a la ley, cuando con el respaldo de una base de datos mysql bases de datos replicadas en redundante de servidores de nombres. También se necesita un sólido sistema distribuido de monitoreo que usted puede confiar para la conmutación por error automatizada de integración. Zabbix trabaja para mí - me pueda verificar los cortes de múltiples distribuidos Zabbix sistemas casi al instante - actualización de mysql registros utilizados por powerdns sobre la marcha - y casi instantánea de conmutación por error durante los cortes y picos de tráfico.

Pero bueno - he construido una empresa que ofrece servicios de conmutación por error de DNS después de años de lo que es trabajar para las grandes empresas. Así que tome mi opinión con un grano de sal. Si quieres ver algunos de zabbix tráfico gráficos de sitios de gran volumen durante un corte de luz - para ver exactamente cómo buena conmutación por error de DNS funciona - email yo estoy más que feliz de compartir.

9voto

Ryan Puntos 81

Hay un montón de personas que utilizan nosotros (Dyn) para la conmutación por error. Es la misma razón por sitios puede hacer una página de estado cuando tienen tiempo de inactividad (pensar en cosas como la de Twitter Fail Whale)...o simplemente desviar el tráfico en función de la TTLs. Algunas personas pueden pensar que la Conmutación por error de DNS es el ghetto...pero en serio diseñado nuestra red con conmutación por error desde el principio...así que iba a funcionar tan bien como de hardware. No estoy seguro de cómo DME hace, pero tenemos 3 de 17 de nuestro más cercano anycasted Cop supervisar el servidor de la ubicación más cercana. Cuando se detecta a partir de dos de los tres que es, simplemente redirigir el tráfico a la otra IP. El tiempo de inactividad sólo es para aquellos que se fueron, a los que pidió para el resto de TTL intervalo.

Algunas personas les gusta usar los dos servidores a la vez...y en ese caso se puede hacer algo así como un equilibrio de carga round robin...o geo basado en el equilibrio de carga. Para aquellos que realmente se preocupan por el rendimiento... nuestro tráfico en tiempo real administrador de monitor de cada servidor...y si uno es más lento...redirigir el tráfico de la forma más rápida con base en lo IPs enlace en sus nombres de host. De nuevo...esto funciona basado en los valores que se pongan en marcha en nuestra interfaz de usuario/API/Portal.

Supongo que mi punto es...que hemos diseñado una conmutación por error de dns a propósito. Mientras que el DNS no estaba hecho para la conmutación por error cuando originalmente fue creado...nuestro DNS de la red fue diseñada para implementar desde el principio. Usualmente puede ser tan eficaz como el hardware..sin depreciación o el costo del hardware. Espero que no me haga parecer cojo para conectar Dyn...hay un montón de otras empresas que lo hacen...solo estoy hablando de nuestro equipo de perspectiva. Espero que esto ayude...

4voto

vmiazzo Puntos 536

La opinión predominante es que con DNS RR, cuando una IP va hacia abajo, algunos de los clientes seguirán usando el roto IP minutos. Esto fue afirmado en alguna de las anteriores respuestas a la pregunta y es también escribió en la Wikipedia.

De todos modos,

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

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

El uso de varios registros no es un truco de el comercio, o una característica concebido por el equilibrio de carga de los proveedores de equipos. El protocolo DNS, fue diseñado con el apoyo de varios registros por esta misma razón. Aplicaciones como navegadores y los servidores proxy y servidores de correo de hacer uso de esa parte del protocolo DNS.

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

Gracias,

Valentino

PS: lo siento por el enlace roto, pero, como usuario nuevo, no puedo publicar más de 1

3voto

jjnguy Puntos 62123

El problema con failover DNS es que es, en muchos casos, poco fiables. Algunos ISP ignorará sus TTLs, no ocurre inmediatamente incluso si respetan tus TTLs, y cuando vuelva su sitio, puede conducir a algunas rarezas con sesiones cuando expira la caché de DNS de un usuario, y terminan por dirigirse a otro servidor.

Desafortunadamente, es prácticamente la única opción, si no eres lo suficientemente grande para hacer su propio encaminamiento (externo).

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: