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

Introducción

Cuando se pierde un extremo, una zona o un sitio completo, ninguna IP individual puede moverse para rescatarlo, e IONOS CLOUD no vende un dispositivo de conmutación por error administrado que realice la dirección por usted. La respuesta se encuentra un nivel superior, en el nombre: un registro DNS que apunta a los clientes hacia un extremo operativo y se reorienta cuando ese extremo deja de ser operativo. La verdad arquitectónica importante es que Cloud DNS no realiza las comprobaciones de estado ni la reorientación por usted. Cloud DNS no es consciente del estado; sirve el registro que usted configure. La comprobación de estado que determina que un extremo ha dejado de funcionar, y la llamada a la API que reorienta el registro, son automatizaciones que usted debe gestionar. Esto convierte la conmutación por error de extremos basada en DNS en un patrón construido por el cliente, en el que Cloud DNS es un componente (altamente disponible), no un producto de conmutación por error nativo. Esta unidad establece la base bien documentada, una zona primaria y sus registros, destaca las fortalezas reales de Cloud DNS, y luego aborda el comportamiento de conmutación por error de manera honesta: lo que la plataforma proporciona de forma nativa y lo que usted orquesta usted mismo mediante la API.

1. Cloud DNS: Qué proporciona y dónde reside realmente el conmutado por fallo

Cloud DNS es un servicio DNS autoritativo totalmente gestionado con anycast: sus zonas se sirven desde 14 puntos de presencia en Europa y Estados Unidos, y el servicio cuenta con un SLA de disponibilidad del 99,995 por ciento. El anycast es importante porque cada resolver alcanza automáticamente el nodo más cercano y saludable, por lo que el plano DNS en sí mismo es de alta disponibilidad, de forma independiente de los puntos finales hacia los que dirige el tráfico. Sus fortalezas nativas merecen una declaración clara, porque son sobre las que realmente se construye: servicio autoritativo anycast, zonas primarias y secundarias, un TTL que puede configurarse tan bajo como 60 segundos, DNSSEC y DNS inverso.

Dos de esas fortalezas es fácil confundirlas, por lo que deben separarse con claridad.

La resiliencia del servidor autoritativo es nativa: zonas secundarias. Una zona secundaria es un espejo AXFR de una zona primaria. Su función es la recuperación ante desastres para el servidor de nombres autoritativo en sí mismo: si el servidor de nombres primario se desconecta, el secundario continúa respondiendo a las consultas con los registros transferidos por última vez. Las zonas secundarias se sirven desde un conjunto de servidores de nombres distinto (nscs.ui-dns.*) y son una característica de resiliencia genuina y nativa de la plataforma. Lo que no son es un conmutado por fallo de salud de los puntos finales. Una zona secundaria continúa sirviendo los mismos registros; no supervisa si el punto final al que apuntan esos registros está activo, y no cambia una respuesta porque un backend se haya caído.

El conmutado por fallo 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 basándose en la salud. No existe un tipo de registro de conmutado por fallo de verificación de salud. Cuando la gente dice "conmutado por fallo de DNS", lo que significa en IONOS CLOUD es un patrón que el cliente construye: un monitor o script externo ejecuta la verificación de salud, y en caso de fallo, llama a la API de Cloud DNS para redirigir un registro de TTL bajo hacia un punto final saludable. Cloud DNS simplemente sirve el registro que usted configure. La automatización de verificación de salud y redirección es suya; Cloud DNS proporciona el registro anycast, respaldado por SLA y de TTL bajo, que hace que el patrón sea rápido y fiable una vez que usted lo dirige.

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

Primero, DNS solo dirige nuevas conexiones. Redirigir un registro cambia dónde se resuelven las búsquedas futuras; no hace nada por las conexiones ya establecidas con el punto final fallido, y no hace nada por los clientes que aún mantienen una respuesta en caché. La consecuencia estricta es que cualquier capa fronted por conmutado por fallo de DNS debe ser sin estado: un cliente que sea redirigido al punto final secundario debe poder continuar sin afinidad de sesión a nivel de servidor, porque la plataforma no realiza ningún intento de transportar el estado a través del conmutado. La sesión y otros estados deben residir en una capa compartida (la capa de caché en memoria de la Unidad 5), no en el punto final que acaba de fallar.

Segundo, el TTL es la palanca dominante sobre el tiempo de recuperación. El TTL que configure en un registro es el tiempo durante el cual los resolvers pueden almacenar en caché la respuesta anterior, por lo que es efectivamente un límite inferior sobre la rapidez con la que los clientes redirigidos pueden descubrir el nuevo punto final después de que cambie el registro. Cloud DNS permite TTLs 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, que es lo que su presupuesto de RTO realmente paga; la contrapartida es que se realizan búsquedas de resolver con mayor frecuencia. Para un registro fronted por conmutado por fallo, configure un TTL bajo a propósito y trátelo como el control de tiempo de recuperación que es, no como un valor predeterminado heredado. Tenga en cuenta también que la propagación de servidores de nombres puede tardar hasta 48 horas, lo cual concierne a la delegación de una nueva zona, no al paso de conmutado por fallo por registro, por lo que planifique la delegación con mucha antelación a cualquier cambio.

Guía de implementación de DCD

Creará la zona autoritativa de FinCorp, agregará los registros que resuelven su servicio público y, a continuación, configurará la conmutación por error orquestada por el cliente entre un par de dos puntos de acceso (por ejemplo, el punto de acceso de la región principal y el punto de acceso de la región secundaria). La creación de la zona y de los registros es una ruta de consola bien documentada; la reorientación basada en la comprobación de estado se aborda a nivel de diseño y de API, porque Cloud DNS no es consciente del estado y no expone ningún tipo de registro de conmutación por error que ejecute su propio monitor de estado. La comprobación de estado y la reorientación son responsabilidad del cliente.

Objetivo de la construcción: Crear una zona y sus registros, y luego configurar una conmutación por error orquestada por el cliente (comprobación de estado externa más una reorientación mediante API) entre un par de dos puntos de acceso.

Requisito previo: Debe ser un administrador de contrato, un propietario o un usuario que posea el privilegio "Access and manage DNS" para crear y gestionar zonas y registros.

Pasos (en Data Center Designer):

Abra Cloud DNS y seleccione Create primary DNS zone.
En la ventana Create Primary Zone, configure Enabled/Disabled (deje habilitado), el Name (el dominio o subdominio, por ejemplo app.fincorp.example) y una Descripción opcional. Haga clic en Create zone. (Desactivar una zona elimina su registro SOA y la desconecta de los servidores de nombres de IONOS CLOUD, por lo que debe dejarla habilitada.)
A partir de la confirmación de creación de la zona, copie los servidores de nombres de IONOS CLOUD asignados (el conjunto ns-ic.ui-dns.*) y configúrelos en su registrador para delegar el dominio. Permita la propagación antes de cualquier puesta en producción.
Abra la zona (Primary Zones, luego la zona, o Details & Records) y haga clic en Create record.
En la ventana Create Record, configure: Enabled, el Name (dejarlo vacío crea un registro Apex/ráiz de zona; * crea un comodín), el TTL en segundos (el valor predeterminado es 3600, pero para un registro con conmutación por error establezca un valor bajo, por ejemplo 60, como palanca de tiempo de recuperación), el Type (por ejemplo A para la dirección IPv4 del punto de acceso principal) y el Content (la dirección del punto de acceso). Guarde.
Agregue el o los registros para el punto de acceso secundario para que ambas direcciones de destino existan como registros gestionados entre los que puede conmutar.

El paso de conmutación por error (orquestado por el cliente; Cloud DNS no es consciente del estado): Cloud DNS no tiene un tipo de registro de conmutación por error que ejecute su propio monitor de estado y cambie el destino automáticamente, porque el servicio no comprueba el estado de los puntos de acceso en absoluto. No invente un flujo de consola que haga esto. En su lugar, usted lo orquesta: ejecute una comprobación de estado desde fuera del servicio DNS (un monitor externo, o una comprobación en sus herramientas de operaciones) contra el punto de acceso principal, y cuando falle, llame a la API de Cloud DNS para actualizar el Content del registro al punto de acceso secundario. Dado que cada registro lleva el TTL bajo establecido en el paso 5, los clientes redirigidos adoptan el nuevo destino rápidamente. Una actualización de registro es una única llamada de API autenticada contra los UUID de la zona y del registro; el estado del registro pasa de Provisioning a Available a medida que el cambio surte efecto. Esta es la forma honesta de la "conmutación por error de DNS" en la plataforma hoy en día: la gestión de zonas y registros es nativa y bien documentada, y la automatización de comprobación de estado y reorientación es responsabilidad del cliente, construida en torno a esa API. Cloud DNS sirve el registro que usted configura; 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 su límite inferior de RTO; un TTL alto obsoleto mantiene a los clientes anclados a un punto de acceso caído mucho después de que usted cambie el registro.
Suponer que Cloud DNS realiza la comprobación de estado o la conmutación por error por usted. No lo hace; no es consciente del estado. Construya la comprobación de estado y la reorientación mediante API usted mismo, en lugar de suponer que existe un tipo de registro de conmutación por error nativo.
Confundir las zonas secundarias con la conmutación por error de puntos de acceso. Las zonas secundarias son un espejo AXFR para la recuperación ante desastres del servidor de nombres (siguen respondiendo si el servidor de nombres principal falla); no detectan un punto de acceso caído ni cambian un registro. La conmutación por error de puntos de acceso es la reorientación orquestada por el cliente.
Colocar un nivel con estado detrás de una conmutación por error de DNS. DNS solo dirige nuevas conexiones, por lo que externalice la sesión/estado a la capa de caché compartida o los usuarios redirigidos perderán su sesión.
Olvidar la delegación del servidor de nombres y su propagación de hasta 48 horas al establecer una zona nueva; esta es una tarea previa al cambio, no una de conmutación por error.

Resumen

Cloud DNS es un servicio autoritativo anycast respaldado por un SLA, y es un componente sólido 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 del estado de salud: sirve el registro que usted configure y nunca cambia una respuesta por su cuenta. Dos cosas que proporciona de forma nativa son importantes aquí: anycast, que mantiene el plano de DNS altamente disponible, y zonas secundarias, que mantienen el servidor de nombres respondiendo si el servidor primario se desconecta. La conmutación por error de puntos de acceso es diferente y la construye el cliente: una comprobación de salud externa que usted ejecuta detecta un punto de acceso inactivo y llama a la API de Cloud DNS para redirigir un registro con TTL bajo hacia uno saludable. La gestión de zonas y registros es la parte de la consola bien documentada; la comprobación de salud y la redirección son automatizaciones que usted administra, aceleradas por un TTL deliberadamente bajo. Dado que el mecanismo dirige solo nuevas conexiones, cada nivel que se encuentre detrás de él debe ser sin estado, con el estado de la sesión trasladado a un nivel compartido.

Puntos clave:

Cloud DNS no es consciente del estado de salud: no realiza comprobaciones de salud de puntos de acceso ni conmutación por error automatizada. Sirve el registro que usted configure.
La conmutación por error de puntos de acceso es un patrón construido por el cliente: su propia comprobación de salud externa más una redirección de registro mediante la API de Cloud DNS, dado que no existe un producto de conmutación por error administrado.
Las zonas secundarias son nativas, pero son recuperación ante desastres del servidor autoritativo (un espejo AXFR que sigue respondiendo si el servidor de nombres primario falla), no conmutación por error de salud de puntos de acceso.
El TTL es el palanca dominante de RTO (Cloud DNS permite de 60 a 604800 segundos); establézcalo bajo en los registros con conmutación por error de forma deliberada.
DNS dirige solo nuevas conexiones, por lo que los niveles detrás de 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 SLA de disponibilidad del 99,995 por ciento; la delegación del servidor de nombres puede tardar hasta 48 horas y es una tarea previa al cambio.

Terminología importante:

TTL (Time To Live): Cuánto tiempo pueden los resolvers almacenar en caché un registro; en un registro de conmutación por error, limita la rapidez con la que los clientes redirigidos descubren el nuevo punto de acceso.
Registro Apex (raíz de la zona): Un registro en el nombre de zona sin prefijo, creado dejando el nombre del registro vacío.
Anycast: Servir la misma dirección desde muchos puntos de presencia para que los resolvers alcancen el nodo saludable más cercano, lo que hace que el plano de DNS en sí mismo sea altamente disponible.

Lectura adicional