Confiabilidad en Azure DNS

Este artículo contiene información detallada sobre la compatibilidad de la recuperación ante desastres entre regiones y la continuidad empresarial con Azure DNS.

Recuperación ante desastres entre regiones y continuidad empresarial

La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.

En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, es responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.

La solución de conmutación por error de Azure DNS para la recuperación ante desastres utiliza el mecanismo de DNS estándar para realizar la conmutación por error al sitio de copia de seguridad. La opción manual mediante Azure DNS funciona mejor cuando se utiliza junto con el enfoque de espera pasiva o de luz piloto.

Puesto que el servidor DNS está fuera de la zona de conmutación por error o zona de desastre, está aislado frente a los tiempos de inactividad. Puede diseñar un escenario de conmutación por error simple siempre y cuando el operador tenga conectividad de red durante el desastre y pueda realizar el cambio. Si la solución consiste en un script, es preciso asegurarse de que el servidor o el servicio que ejecuta el script también esté aislado del problema que afecta al entorno de producción. Además, un TTL bajo para la zona impide el almacenamiento en caché del solucionador durante largos períodos de tiempo, lo que permite al cliente acceder al sitio dentro del RTO. En los casos de espera pasiva y de luz piloto, dado que pueden ser necesarias algunas actividades de puesta en actividad y otras actividades administrativas, se debe dar tiempo suficiente antes de realizar el cambio.

Nota:

La zona DNS privada de Azure admite la resolución DNS entre redes virtuales entre regiones de Azure, incluso sin emparejar explícitamente las redes virtuales. Sin embargo, todas las redes virtuales están vinculadas a la zona DNS privada.

Para aprender a crear una zona DNS privada de Azure mediante Azure Portal, consulte Inicio rápido: Crear una zona DNS privada de Azure mediante Azure Portal.

Para crear una instancia de Azure DNS Private Resolver mediante Azure Portal, consulte Inicio rápido: Crear una instancia de Azure DNS Private Resolver mediante Azure Portal.

Recuperación ante desastres en la geografía de varias regiones

Hay dos aspectos técnicos en la configuración de la arquitectura de recuperación ante desastres:

• El uso de un mecanismo de implementación para replicar instancias, datos y configuraciones entre entornos principales y en espera. Este tipo de recuperación ante desastres se puede realizar de forma nativa a través de Azure Site Recovery, consulte Documentación de Azure Site Recovery mediante dispositivos o servicios de asociados de Microsoft Azure como Veritas o NetApp.

• El desarrollo de una solución para desviar el tráfico de red y el tráfico web desde el sitio principal al sitio en espera. Este tipo de recuperación ante desastres se puede lograr con Azure DNS, Azure Traffic Manager (DNS) o equilibradores de carga globales de otros fabricantes.

Este artículo se centra específicamente en la planificación de la recuperación ante desastres de Azure DNS.

Configuración de la recuperación ante desastres y la detección de interrupciones

La solución de conmutación por error manual de Azure DNS para la recuperación ante desastres utiliza el mecanismo de DNS estándar para realizar la conmutación por error al sitio de copia de seguridad. La opción manual mediante Azure DNS funciona mejor cuando se utiliza junto con el enfoque de espera pasiva o de luz piloto.

Figura: Conmutación por error manual con Azure DNS

Los supuestos realizados para la solución son:

• Los puntos de conexión principal y secundario tienen direcciones IP estáticas que no cambian con frecuencia. Supongamos que la dirección IP del sitio principal es 100.168.124.44 y la dirección IP del sitio secundario es 100.168.124.43.
• Existe una zona de Azure DNS tanto para el sitio principal como para el secundario. Supongamos que el punto de conexión para el sitio principal es prod.contoso.com y para el sitio de copia de seguridad es dr.contoso.com. También existe un registro DNS de la aplicación principal, conocido como www.contoso.com.
• El TTL es igual o inferior al del Acuerdo de Nivel de Servicio de RTO establecido en la organización. Por ejemplo, si una empresa establece el RTO de la respuesta ante desastres de aplicaciones en 60 minutos, el TTL debe ser inferior a 60 minutos, preferiblemente el menor posible. Puede configurar Azure DNS para la conmutación por error manual como se indica a continuación:
  • Creación de una zona DNS
  • Creación de registros de zona DNS
  • Actualización del registro CNAME

1. Cree una zona DNS (por ejemplo, www.contoso.com) como se muestra a continuación:

   

   Figura: creación de una zona DNS en Azure

2. Dentro de esta zona debe crear tres registros (por ejemplo: www.contoso.com, prod.contoso.com y dr.contoso.com) como se muestra a continuación.

   

   Figura: creación de registros de zona DNS en Azure

   En este escenario, el sitio www.contoso.com tiene un valor de TTL de 30 minutos, que es muy inferior al RTO indicado y apunta al sitio de producción prod.contoso.com. Esta es la configuración durante las operaciones normales del negocio. El TTL de prod.contoso.com y dr.contoso.com se ha establecido en 300 segundos o 5 minutos. Puede usar un servicio de supervisión de Azure, como Azure Monitor o Azure App Insights, o cualquier solución de supervisión de asociados, como Dynatrace. Incluso puede usar soluciones domésticas que puedan supervisar o detectar errores de nivel de infraestructura virtual o de aplicación.

3. Una vez que se detecta un error, cambie el valor del registro para que apunte a dr.contoso.com como se muestra a continuación:

   

   Figura: actualización del registro CNAME en Azure

   En 30 minutos, durante los cuales la mayoría de los sistemas de resolución actualizarán el archivo de zona almacenado en caché, cualquier consulta a www.contoso.com se redirigirá a dr.contoso.com. También puede ejecutar el siguiente comando de la CLI de Azure para cambiar el valor de CNAME:

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   Este paso se puede ejecutar manualmente o mediante automatización. Se puede realizar manualmente mediante la consola o mediante la CLI de Azure. La API y el SDK de Azure se pueden utilizar para automatizar la actualización de CNAME para que no sea necesaria ninguna intervención manual. La automatización se puede crear mediante Azure Functions, en una aplicación de supervisión de terceros o incluso desde el entorno local.

Pasos siguientes

• Confiabilidad en Azure
• Más información acerca de Azure Traffic Manager.
• Obtenga más información sobre Azure DNS.