¿Correcto modo de configurar DNS primario / secundario / … para redundancia y reducción de latencia?

Pensé DNS primaria / secundaria para fines de redundancia fue sencillo. Mi comprensión es que usted debe tener una primaria y al menos una secundaria, y que debe configurar su secundaria en una ubicación geográficamente diferente, pero también detrás de un enrutador diferente (ver, por ejemplo, https://serverfault.com/questions/48087 / Why-are-there-several-nameservers-for-my-domain )

Actualmente, tenemos dos servidores de nombres tanto en nuestro centro de datos principal. Recientemente, hemos sufrido algunos apagones por varias razones que sacaron ambos servidores de nombres, y nos dejaron a nosotros ya nuestros clientes sin trabajar DNS por unas horas. He pedido a mi equipo de sysadmin que termine de configurar un servidor DNS en otro centro de datos y lo configure como servidor de nombres secundario.

Sin embargo, nuestros administradores de sistemas afirman que esto no ayuda mucho si el otro centro de datos no es al menos tan confiable como el centro de datos principal. Afirman que la mayoría de los clientes todavía no pueden buscar correctamente, o tiempo demasiado largo, cuando el centro de datos principal está abajo.

Personalmente, estoy convencido de que no somos la única empresa con este tipo de problema y que lo más probable es que ya es un problema resuelto. No puedo imaginar que todas las compañías de Internet se vean afectadas por nuestro tipo de problema. Sin embargo, no puedo encontrar buenos documentos en línea que expliquen lo que ocurre en casos de falla (por ejemplo, tiempos de espera de clientes) y cómo trabajar alrededor de ellos.

¿Qué argumentos puedo usar para hacer agujeros en el razonamiento de nuestros administradores de sistemas? Cualquier recurso en línea que pueda consultar para entender mejor los problemas que dicen que existen?

Algunas notas adicionales después de leer las respuestas:

  • Estamos en Linux
  • Tenemos necesidades adicionales complicadas de DNS; Nuestras entradas de DNS son manejadas por algún software personalizado, con BIND actualmente slaving de una implementación de Twisted DNS, y algunas vistas en la mezcla también. Sin embargo, somos completamente capaces de configurar nuestros propios servidores DNS en otro centro de datos.
  • Estoy hablando de DNS autorizado para que los forasteros encuentren nuestros servidores, no servidores de DNS recursivos para nuestros clientes locales.

9 Solutions collect form web for “¿Correcto modo de configurar DNS primario / secundario / … para redundancia y reducción de latencia?”

Hay un muy buen, aunque muy técnico "Best Practices" documento que puede resultar útil al combatir su sysadmin. http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

Si él / ella no reconoce la validez de los artículos escritos por Cisco, entonces usted también podría dejar de discutir con el administrador de sistemas – subir un nivel de gestión.

Muchos otros documentos de "Prácticas recomendadas" recomiendan separar sus servidores de nombres primario y secundario no sólo por bloqueo de IP, sino por ubicación física. De hecho, RFC 2182 recomienda que los servicios secundarios del DNS se separen geográficamente. Para muchas empresas, esto significa alquilar un servidor en otro centro de datos, o suscribirse a un proveedor de DNS alojado como ZoneEdit o UltraDNS .

Desafortunadamente la resolución del DNS de Linux no parece tener soporte directo para detectar y hacer failovers para servidores DNS. Mantiene las solicitudes de alimentación a su servidor de nombres de resolución principal, espera un tiempo de espera configurado, intenta de nuevo, etc.

Esto a menudo significa hasta 30 segundos de retraso para cualquier solicitud. Sin primero intentar el secundario mientras el primario esté abajo.

Quería resolver esto como nuestro servidor de nombres de resolución de Amazon EC2 es inalcanzable para muchos de nuestros trabajadores. Esto provoca grandes retrasos en nuestros procesos e incluso el tiempo de inactividad en algunos casos porque nos basamos en la resolución. Quería una buena conmutación por error a los servidores de nombres de Google / Level3 en caso de que Amazon volviera a caer. Y caer lo antes posible, porque entonces Amazon resolverá nombres de host a direcciones locales donde sea aplicable, resolviendo en latencia más baja por ejemplo a la comunicación de instancia.

Pero sea cual sea el uso, hay una necesidad de una mejor conmutación por error. Quería resolver esto. Quería mantenerse alejado de los daemons proxy-ing, servicios, etc. Como eso solo introduciría más Single Point Of Failures. Quería usar la tecnología más arcaica y robusta que pude.

Decidí usar crontab & bash, y escribí nsfailover.sh . Espero que esto ayude.

Sin embargo, nuestros administradores de sistemas afirman que esto no ayuda mucho si el otro centro de datos no es al menos tan confiable como el centro de datos principal. Afirman que la mayoría de los clientes todavía no pueden buscar correctamente, o tiempo demasiado largo, cuando el centro de datos principal está abajo.

Ah, el enfoque es confiable . Suena como que están tomando un jab en su enlace hacia el exterior, en lugar de configurar el DNS secundario. De todas maneras, configurar DNS secundario y proceder desde allí. Ayudará con la carga y las cosas de apoyo en una pizca … pero no preguntar por qué piensan que la otra ubicación no es confiable .

Personalmente, estoy convencido de que no somos la única empresa con este tipo de problema y que lo más probable es que ya es un problema resuelto. No puedo imaginar que todas las compañías de Internet se vean afectadas por nuestro tipo de problema.

Usted no es la única empresa, y esto probablemente ha sido rehashed un millón de veces en empresas de todo el mundo.

Sin embargo, no puedo encontrar buenos documentos en línea que expliquen lo que ocurre en casos de falla (por ejemplo, tiempos de espera de clientes) y cómo trabajar alrededor de ellos.

¿Qué argumentos puedo usar para hacer agujeros en el razonamiento de nuestros administradores de sistemas? Cualquier recurso en línea que pueda consultar para entender mejor los problemas que dicen que existen?

  • Estoy hablando de DNS autorizado para que los forasteros encuentren nuestros servidores, no servidores de DNS recursivos para nuestros clientes locales.

Usted puede hacer todo tipo de cosas, incluyendo la configuración de un servicio DNS externo que está registrado como la autoridad para su zona, pero secretamente haciendo que los servidores de autoridad fuera de sus propios servidores DNS. Esta configuración es horrible, equivocada, muestra que soy verdaderamente un mal SysAdmin, y un gatito muere cada vez que lo recomiendo. Pero hace dos cosas:

  • Usted obtiene su servicio de DNS para manejar el peso de la carga, haciendo preguntas sobre la capacidad de su propio (interno) DNS como punto muerto.
  • Usted consigue que su servicio DNS se mantenga al día mientras sus servidores DNS internos pueden estar inactivos, por lo que no importa cuán confiable sea su enlace, lo que importa es cuán confiable es su proveedor de servicios DNS .

Las razones por las que esto no es lo correcto :

  • Usted estaría configurando lo que se llama un "servidor de nombres sigilo", porque mientras se mostrará en sus registros de zona, y usted puede consultar la IP para el nombre del servidor, nunca será tocado por el exterior. Las consultas del cliente nunca lo alcanzarán.
  • Si bien su DNS seguiría funcionando bien (ya que el servicio alojado resolvería el problema), no significa que los sitios web que tenga funcionen si su conexión a Internet se ha reducido, es decir, solo se ocupa de la mitad del problema . Realmente suena como que hay otros problemas que los administradores están preocupados.

Parece que el problema es que los clientes -que podría ser cualquier persona, en cualquier lugar- verán dos servidores DNS y si falla, tampoco hacen failover al servidor secundario o hay un tiempo de espera largo antes de hacerlo.

Estoy de acuerdo en que los servidores DNS primarios y secundarios deben estar ubicados en diferentes instalaciones como una buena práctica, pero no veo cómo resolvería este problema en particular.

Si el cliente va a insistir en la consulta de una dirección IP específica, haciendo caso omiso de la dirección IP de la secundaria (o tomar un tiempo para el tiempo de espera para que), entonces simplemente tienes que llegar a una solución que mantiene esa dirección IP funcionando, Servidor primario está inactivo.

Algunas direcciones para explorar sería un equilibrador de carga que puede redirigir el tráfico de una única dirección IP a varios servidores en diferentes centros de datos; O tal vez anycast encaminamiento.

Siempre y cuando cada uno de sus datacenters se encuentre en circuitos diferentes (idealmente con diferentes proveedores ascendentes hasta llegar a la nube), puede configurar un DNS bastante confiable con sólo dos datacenters. Sólo tiene que asegurarse de que su registrador de elección rellena los registros de pegamento adecuados a los grandes servidores en el cielo.

Nuestra configuración es:

  • 2 datacenters físicos (circuitos separados, ISPs, y abastecedores ascendentes)
  • 2 servidores de consultas físicas en un clúster detrás de un SLB en cada instalación
  • 2 dispositivos de balanceo de carga para servir registros específicos que queremos gestionar el equilibrio entre los dos datacetners
  • Maestro oculto internamente accesible por ambos clústeres de servidores (creo muy fuertemente en las configuraciones maestras ocultas para la seguridad)

Esta configuración ha sido lo suficientemente eficaz para darnos aproximadamente 5 9 de tiempo de actividad en los últimos 6 o 7 años, incluso con el tiempo de inactividad del servidor ocasional de actualizaciones, etc Si está dispuesto a gastar unos dólares adicionales, puede mirar a terceros Hospedaje de la zona con alguien como ultradns …

En cuanto a la conversación de carga que KPWINC mencionó, que es 100% correcto. Si su datacenter más pequeño no puede manejar el 100% de su carga, entonces es probable que deshuesado de todos modos porque su interrupción va a ocurrir cuando menos lo desea =)

Tomo la carga máxima de todos mis routers de borde, los agrego todos juntos, y luego dividir por 0.65 … que es el ancho de banda mínimo que debemos tener en cada datacenter. Puse esa regla en el lugar hace unos 5 años, con algunos documentos para justificar lo que recogí de CCO y sobre el Internet, y nunca nos ha fallado. Sin embargo, debe revisar esas estadísticas al menos trimestralmente. Hemos tenido nuestro aumento de tráfico casi 3 veces entre noviembre y febrero del año pasado y yo no estaba preparado para ello. Esa parte brillante es que la situación me permitió generar algunos datos muy claros que dice a una carga del 72% en nuestro circuito WAN, empezamos a dejar paquetes. No se ha requerido ninguna justificación adicional de mí para más ancho de banda.

Me di cuenta de la lectura de su descripción que no está claro si quiere decir DNS autorizado para que los forasteros encuentren sus servidores, o servidores DNS recursivos para sus clientes locales. El comportamiento de esos dos es muy diferente.

Para los servidores DNS autorizados, los "clientes" serán otros servidores DNS que tengan almacenamiento en caché y mucha inteligencia. Ellos tienden a probar varios servidores a la vez si el primero es lento y tenderá a preferir el que les dé respuestas más rápidas. El tiempo de inactividad para un centro de datos en ese caso tendría un impacto de rendimiento muy ligero.

Para los servidores DNS recursivos, los clientes son sus clientes locales que probablemente tienen los servidores DNS enumerados en DHCP. Intentarán sus servidores en la orden enumerada cada vez, con un tiempo de espera dolorosamente largo (varios segundos) antes de moverse del primer servidor al segundo servidor.

Si su centro de datos principal está inactivo, nadie podrá llegar a esos servidores de todos modos, pero a menudo los errores de que son más inteligibles que los errores de inaccesibles servidores DNS. "No se pudo contactar con el servidor" o "se agotó el tiempo de conexión" en lugar de "no se pudo encontrar el servidor" o "ningún servidor". Por ejemplo, la mayoría de los servidores SMTP harán cola en el correo durante una semana si ven el servidor en DNS pero no pueden alcanzarlo; Si no pueden encontrarlo en DNS en absoluto, pueden inmediatamente negarse incluso a tratar de entregarlo a su dominio.

El DNS secundario está geográficamente y separado de la red es una buena cosa. Es posible que pueda intercambiar DNS secundario con una empresa amigable, y hay un montón de proveedores de DNS que puede pagar para hacerlo por usted. Algunos registradores tienen DNS secundario como un servicio, también.

Thomas,

Después de leer su actualización, he revisado mi publicación (la publicación anterior hace referencia al software de Windows).

Casi me suena como su sysadmin (s) le están diciendo que su ubicación secundaria no tiene el hardware necesario para manejar la carga completa?

Suena como si estuviera diciendo: "Hey amigo, si nuestra ubicación principal (que incluye el DNS principal) se cae, entonces DNS es el MENOS de nuestras preocupaciones porque si COLO1 está abajo entonces COLO2 no puede manejar la carga de todos modos".

Si ese es el caso, entonces le sugiero que revise su infraestructura y tratar de llegar a un mejor diseño. Esto es más fácil decirlo que hacerlo, especialmente ahora que usted vive en un entorno de producción.

Todo eso aparte, en un mundo perfecto, COLO1 y COLO2 podrían estar solos y manejar su carga.

Una vez que estaba en su lugar … el DNS es realmente nada más que tener suficientes servidores DNS con una actualización lo suficientemente rápido y si un lado falla puede reescribir su DNS para apuntar a los servidores que son UP.

He utilizado este método en entornos de tamaño pequeño a razonable y funciona muy bien. La conmutación por error suele tardar menos de 10 minutos.

Sólo tiene que asegurarse de que sus servidores DNS pueden manejar la carga extra de un TTL corto (tiempo de vida).

Espero que esto ayude.

Sus administradores de sistemas están (en su mayoría) equivocados.

Los servidores recursivos que consultan a sus servidores autorizados se darán cuenta muy rápidamente si cualquiera de los sitios no responde.

Sí, existe la posibilidad de que los clientes experimenten retrasos de resolución de DNS muy modestos cuando hay una interrupción, pero sólo serán un segundo o dos y una vez que los propios servidores DNS del cliente hayan aprendido que uno de los servidores está inactivo utilizarán Los servidores restantes en preferencia a la que falló.

Si es necesario (para apaciguar los administradores de sistemas) continúe ejecutando dos servidores en su centro de datos principal, pero ponga al menos uno más fuera.

Un servidor de DNS secundario nunca duele, dependiendo de dónde se hospeda le dará más o menos funcionalidad.

Si el host primario falla, un secundario puede asumir el control sin importar si está sentado junto a él o en una ubicación remota. Sin embargo, si el enlace ascendente del centro de datos falla, es posible que reciba las respuestas de DNS del servidor en otro centro de datos, pero no podrá llegar a los servidores de ninguna manera. Por lo tanto, sus usuarios finales no se beneficiarán directamente del DNS secundario en la ubicación remota.

Los clientes diferentes reaccionan de otras maneras a los servidores DNS que no están disponibles, así que hay algo de verdad para los clientes, pero no todos.

Un DNS secundario en un centro de datos remoto, sin embargo, todavía será capaz de resolver la dirección IP del servidor que desea alcanzar para que pueda depurar el enrutamiento y ver cuándo vuelven a aparecer. Y si ha configurado correctamente los servidores MX secundarios, ni siquiera perderá el correo.

  • ¿Cómo asegurarse de que en caso de que nuestro servidor de correo sea inaccesible (conexión abajo) el correo todavía se pone en cola y se vuelve a enviar una vez que está de nuevo?
  • Redundancia y disponibilidad de la red del servidor
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.