Unidad 3.7: DNS y enrutamiento de conmutación por error

Introducción

Cuando se pierde todo un punto de conexión, zona o sitio, no hay un solo IP que pueda moverse para rescatarlo, y IONOS no vende ningún dispositivo de conmutación administrada para hacer la dirección para usted. La respuesta se encuentra una capa más arriba, en el nombre: un registro DNS que dirige a los clientes hacia un punto de conexión saludable y se redirige cuando ese punto de conexión deja de ser saludable. La verdad arquitectónica importante es que Cloud DNS no realiza la comprobación de salud ni la reasignación para usted. Cloud DNS no es consciente de la salud; sirve cualquier registro que configure. La comprobación de salud que decide que un punto de conexión está muerto y la llamada API que reasigna el registro son automatismos que usted posee. Eso hace que la conmutación de punto de conexión basada en DNS sea un patrón creado por el cliente en el que Cloud DNS es un componente (altamente disponible), no un producto de conmutación nativo. Esta unidad construye la base bien documentada, una zona principal y sus registros, destaca las verdaderas fortalezas de Cloud DNS y luego trata el comportamiento de conmutación honestamente: lo que la plataforma proporciona de forma nativa y lo que usted orquesta usted mismo contra la API.

1. Cloud DNS: Lo que proporciona y dónde reside realmente el failover

Cloud DNS es un servicio de DNS autoritativo completamente administrado y anycast: sus zonas se sirven desde 14 puntos de presencia en Europa y EE. UU., y el servicio cuenta con un acuerdo de nivel de servicio (SLA) de disponibilidad del 99,995 por ciento. El anycast es importante porque cada resolutor alcanza automáticamente el Node saludable más cercano, por lo que el plano de DNS en sí es altamente disponible de forma independiente de los puntos finales hacia los que dirige. Sus fortalezas nativas vale la pena mencionarlas claramente, porque son lo que usted construye realmente: servicio autoritativo anycast, zonas primarias y secundarias, un TTL que se puede configurar tan bajo como 60 segundos, DNSSEC y DNS inverso.

Dos de esas fortalezas son fáciles de confundir, así que sepárelas limpiamente.

La resistencia del servidor autoritativo es nativa: zonas secundarias. Una zona secundaria es un espejo AXFR de una zona primaria. Su trabajo es la recuperación ante desastres para el servidor de nombres autoritativo en sí: si el servidor de nombres principal se desconecta, la zona secundaria sigue respondiendo a las consultas con los registros transferidos más recientes. Las zonas secundarias se sirven desde un conjunto de servidores de nombres distintos (nscs.ui-dns.*) y son una característica de resistencia genuina y nativa de la plataforma. Lo que no son es el failover de salud de los puntos finales. Una zona secundaria sigue sirviendo los mismos registros; no supervisa si el punto final al que apuntan esos registros está vivo, y no cambia una respuesta porque un backend se desconectó.

El failover de puntos finales no es nativo, porque Cloud DNS no es consciente de la salud. Cloud DNS no supervisa la salud de los puntos finales y no cambia automáticamente los registros en función de la salud. No hay un tipo de registro de failover de comprobación de salud. Cuando la gente dice "failover de DNS", lo que quieren decir en IONOS es un patrón que el cliente construye: un monitor o script externo ejecuta la comprobación de salud, y en caso de fallo, llama a la API de Cloud DNS para reenviar un registro de bajo TTL a un punto final saludable. Cloud DNS simplemente sirve cualquier registro que usted configure. La automatización de comprobación de salud y reenvío es suya; Cloud DNS proporciona el registro anycast con respaldo de SLA y bajo TTL que hace que el patrón sea rápido y confiable una vez que lo ejecute.

Dos propiedades dictan cómo diseñar alrededor de ese patrón construido por el cliente.

Primero, DNS solo dirige nuevas conexiones. Reenviar un registro cambia dónde se resuelven las futuras búsquedas; no hace nada para las conexiones ya establecidas con el punto final que falló, y no hace nada para los clientes que aún mantienen una respuesta en caché. La consecuencia difícil es que cualquier nivel frente a DNS failover debe ser sin estado: un cliente que se redirige al punto final secundario debe poder continuar sin afinidad de sesión en el servidor, porque la plataforma no intenta transportar el estado a través del cambio. La sesión y otros estados deben vivir en un nivel compartido (el nivel de caché en memoria del Módulo 5), no en el punto final que acaba de fallar.

Segundo, TTL es la palanca dominante en el tiempo de recuperación. El TTL que usted configura en un registro es durante cuánto tiempo los resolutores pueden almacenar en caché la respuesta antigua, por lo que es efectivamente un piso en cuánto tiempo los clientes redirigidos pueden descubrir el nuevo punto final después de que se cambie el registro. Cloud DNS permite TTL desde 60 segundos hasta 604800 segundos (7 días). Un TTL bajo acorta la ventana durante la cual los clientes siguen golpeando el punto final muerto, lo que es lo que su presupuesto de RTO realmente paga; el intercambio es que se realizan búsquedas de resolutores más frecuentes. Para un registro con failover, configure un TTL bajo a propósito y trátelo como la perilla de tiempo de recuperación que es, no como un valor predeterminado que heredó. Tenga en cuenta también que la propagación de los servidores de nombres puede tardar hasta 48 horas, lo que concierne a la delegación de una nueva zona, no al paso de failover por registro, así que planifique la delegación con mucha antelación de cualquier corte.

Implementación de DCD: Guía paso a paso

Usted creará la zona autoritativa de FinCorp, agregará los registros que resuelven su servicio público y luego organizará un conmutación por error dirigida por el cliente a través de un par de puntos finales (por ejemplo, el punto final de la región principal y el punto final de la región secundaria). La creación de la zona y los registros es un camino de consola bien documentado; la reasignación de la zona basada en la comprobación de salud se trata a nivel de diseño y API, porque Cloud DNS no es consciente de la salud y no expone ningún tipo de registro de conmutación por error que ejecute su propio monitor de salud. La comprobación de salud y la reasignación son de su responsabilidad.

Objetivo de la implementación: Crear una zona y sus registros, luego conectar una conmutación por error dirigida por el cliente (comprobación de salud externa más una reasignación de API) a través de un par de puntos finales.

Requisito previo: Debe ser un administrador de contrato, propietario o un usuario que tenga el privilegio "Acceso y gestión de DNS" para crear y gestionar zonas y registros.

Pasos (en el Data Center Designer):

Abra Cloud DNS y seleccione Crear zona principal de DNS.
En la ventana Crear zona principal, establezca Habilitado/Deshabilitado (deje Habilitado), el Nombre (el dominio o subdominio, por ejemplo app.fincorp.example) y una descripción opcional. Haga clic en Crear zona. (Deshabilitar una zona elimina su registro SOA y la desconecta de los servidores de nombres de IONOS, así que déjela habilitada.)
Desde el mensaje de confirmación de creación de zona, copie los servidores de nombres de IONOS asignados (el conjunto ns-ic.ui-dns.*) y configúrelos en su registrador para delegar el dominio. Permita la propagación antes de cualquier lanzamiento.
Abra la zona (Zonas principales, luego la zona, o Detalles y registros) y haga clic en Crear registro.
En la ventana Crear registro, establezca: Habilitado, el Nombre (dejarlo vacío crea un registro de Apex/raíz de zona; * crea un comodín), el TTL en segundos (el valor predeterminado es 3600, pero para un conjunto de registros con conmutación por error, establezca un valor bajo, por ejemplo 60, como palanca de tiempo de recuperación), el Tipo (por ejemplo, A para la dirección IPv4 del punto final principal) y el Contenido (la dirección del punto final). Guarde.
Agregue los registros para el punto final secundario para que ambas direcciones de destino existan como registros administrados que pueda cambiar.

El paso de conmutación por error (dirigida por el cliente; Cloud DNS no es consciente de la salud): Cloud DNS no tiene ningún tipo de registro de conmutación por error que ejecute su propio monitor de salud y cambie el destino automáticamente, porque el servicio no comprueba la salud del punto final en absoluto. No fabrique un flujo de consola que haga esto. En su lugar, usted lo orquesta: ejecute una comprobación de salud desde fuera del servicio DNS (un monitor externo o una comprobación en su herramienta de operaciones) contra el punto final principal, y cuando falle, llame a la API de Cloud DNS para actualizar el contenido del registro al punto final secundario. Como cada registro lleva el TTL bajo establecido en el paso 5, los clientes redirigidos recogen el nuevo destino rápidamente. Una actualización de registro es una sola llamada autenticada de API contra los UUID de zona y registro; el estado del registro pasa de Provisioning a Disponible a medida que el cambio tiene efecto. Esta es la forma honesta de "conmutación por error de DNS" en la plataforma hoy: la administración de zonas y registros es nativa y bien documentada, y la automatización de comprobación de salud y reasignación es suya, construida alrededor de esa API. Cloud DNS sirve el registro que establece; no decide cuándo cambiarlo.

Errores comunes:

Dejar el TTL predeterminado de 3600 segundos en un registro con conmutación por error. El TTL es el piso de su tiempo de recuperación; un TTL alto y obsoleto mantiene a los clientes conectados a un punto final muerto mucho después de que usted cambie el registro.
Suponer que Cloud DNS realiza la comprobación de salud o la conmutación por error por usted. No lo hace; no es consciente de la salud. Construya la comprobación de salud y la reasignación de API usted mismo en lugar de suponer que existe un tipo de registro de conmutación por error nativo.
Confundir zonas secundarias con conmutación por error de punto final. Las zonas secundarias son un espejo de AXFR para la recuperación de desastres del servidor de nombres (siguen respondiendo si el servidor de nombres principal muere); no detectan un punto final muerto ni cambian un registro. La conmutación por error de punto final es la reasignación dirigida por el cliente.
Poner un nivel de estado con DNS con conmutación por error. DNS solo dirige nuevas conexiones, así que externalice la sesión/estado al nivel de caché compartido o los usuarios redirigidos pierden su sesión.
Olvidar la delegación de servidores de nombres y su propagación de hasta 48 horas al configurar una nueva zona; esta es una tarea previa a la conmutación, no una tarea de conmutación por error.

Resumen

Cloud DNS es un servicio autoritativo con respaldo de SLA y anycast, y es un componente fuerte en un diseño de conmutación por error, pero no es en sí mismo un producto de conmutación por error. No es consciente de la salud: sirve cualquier registro que configure y nunca cambia una respuesta por sí solo. Dos cosas que proporciona de forma nativa son importantes aquí: anycast que mantiene el plano DNS con alta disponibilidad, y zonas secundarias que mantienen el servidor de nombres respondiendo si el primario se desconecta. La conmutación por error de endpoint es diferente y es construida por el cliente: una comprobación de salud externa que se ejecuta detecta un endpoint muerto y llama al Cloud DNS API para reenviar un registro de baja TTL a uno saludable. La administración de zonas y registros es la parte de la consola bien documentada; la comprobación de salud y la reenviación son automatizaciones que usted posee, hechas rápidas por una TTL deliberadamente baja. Debido a que el mecanismo solo dirige nuevas conexiones, cada nivel que se enfrenta debe ser sin estado, con el estado de sesión empujado a un nivel compartido.

Puntos clave:

Cloud DNS no es consciente de la salud: no realiza comprobaciones de salud de endpoint y no tiene conmutación por error automatizada. Sirve cualquier registro que configure.
La conmutación por error de endpoint es un patrón construido por el cliente: su propia comprobación de salud externa más un registro Cloud DNS API de reenviación, dado que no hay un producto de conmutación por error administrado.
Las zonas secundarias son nativas, pero son recuperación ante desastres de servidor autoritativo (un espejo AXFR que sigue respondiendo si el servidor de nombres primario muere), no conmutación por error de salud de endpoint.
La TTL es la palanca de RTO dominante (Cloud DNS permite 60 a 604800 segundos); configúrela baja en registros con conmutación por error frontal a propósito.
DNS solo dirige nuevas conexiones, por lo que los niveles con DNS deben ser sin estado y externalizar la sesión/estado a una caché compartida.
Cloud DNS es anycast en 14 puntos de presencia (Europa y EE. UU.) con un tiempo de actividad del 99,995 por ciento; la delegación de nameserver puede tardar hasta 48 horas y es una tarea pre-corte.

Terminología importante:

TTL (Tiempo de vida): Cuánto tiempo pueden almacenar en caché los resolutores un registro; en un registro de conmutación por error, limita cuán rápido los clientes redirigidos descubren el nuevo endpoint.
Apex (registro de raíz de zona): Un registro en el nombre de zona vacío, creado dejando el nombre de registro vacío.
Anycast: Servir la misma dirección desde muchos puntos de presencia para que los resolutores alcancen el Node más cercano y saludable, lo que hace que el plano DNS en sí mismo sea altamente disponible.

Lectura adicional