Ejecución de una aplicación de N niveles en varias regiones de Azure Stack Hub para alta disponibilidad

Esta arquitectura de referencia muestra un conjunto de prácticas probadas para ejecutar una aplicación de N niveles en varias regiones de Azure Stack Hub para lograr la disponibilidad y una sólida infraestructura de recuperación ante desastres. En esta arquitectura, se usa Azure Traffic Manager para lograr una alta disponibilidad. Sin embargo, si Traffic Manager no es una opción preferida en su entorno, puede sustituir un par de equilibradores de carga de alta disponibilidad.

Architecture

Esta arquitectura se basa en la que se muestra en la aplicación de N niveles con SQL Server.

• Regiones primarias y secundarias. Use dos regiones para lograr una mayor disponibilidad. Una región es la región primaria. Use la otra región para la conmutación por error.

• Azure Traffic Manager. Traffic Manager enruta las solicitudes entrantes a una de las regiones. Durante las operaciones normales, enruta las solicitudes a la región primaria. Si esa región deja de estar disponible, Traffic Manager conmuta por error a la región secundaria. Para obtener más información, consulte la sección Configuración de Traffic Manager.

• Grupos de recursos. Cree grupos de recursos independientes para la región primaria y la región secundaria. Este enfoque le ofrece la flexibilidad de administrar cada región como una sola colección de recursos. Por ejemplo, puede volver a implementar una región sin quitar la otra región. Vincule los grupos de recursos para que pueda ejecutar una consulta para enumerar todos los recursos de la aplicación.

• Redes virtuales. Cree una red virtual independiente para cada región. Asegúrese de que los espacios de direcciones no se superpongan.

• Grupo de disponibilidad AlwaysOn de SQL Server. Si usa SQL Server, use grupos de disponibilidad AlwaysOn de SQL para lograr alta disponibilidad. Cree un único grupo de disponibilidad que incluya las instancias de SQL Server en ambas regiones.

• Conexión VPN de red virtual a red virtual. Como el emparejamiento de VNET aún no está disponible en Azure Stack Hub, use la red virtual a la conexión VPN de red virtual para conectar las dos redes virtuales. Consulte red virtual a red virtual en Azure Stack Hub para obtener más información.

Recommendations

Una arquitectura de varias regiones puede proporcionar una mayor disponibilidad que la implementación en una sola región. Si una interrupción regional afecta a la región primaria, puede usar Traffic Manager para conmutar por error a la región secundaria. Esta arquitectura también puede ayudar si se produce un error en un subsistema individual de la aplicación.

Hay varios enfoques generales para lograr una alta disponibilidad entre regiones:

• Activo/pasivo con espera activa. El tráfico va a una región, mientras que la otra espera en espera activa. Espera activa significa que las máquinas virtuales de la región secundaria se asignan y se ejecutan en todo momento.

• Activo/pasivo con espera en frío. El tráfico va a una región, mientras que la otra espera en espera inactiva. Espera inactiva significa que las máquinas virtuales de la región secundaria no se asignan hasta que sea necesario para la conmutación por error. Este enfoque cuesta menos ejecutarse, pero normalmente tardará más tiempo en conectarse durante un error.

• Activo/activo. Ambas regiones están activas y las solicitudes están equilibradas entre ellas. Si una región deja de estar disponible, se quita de la rotación.

Esta arquitectura de referencia se centra en activo/pasivo con espera activa, mediante Traffic Manager para la conmutación por error. Puede implementar un pequeño número de máquinas virtuales para espera activa y, a continuación, escalar horizontalmente según sea necesario.

Configuración de Traffic Manager

Tenga en cuenta los siguientes puntos al configurar Traffic Manager:

• Routing. Traffic Manager admite varios algoritmos de enrutamiento. Para el escenario descrito en este artículo, use el enrutamiento de prioridad (anteriormente denominado enrutamiento de conmutación por error ). Con esta configuración, Traffic Manager envía todas las solicitudes a la región primaria, a menos que la región primaria sea inaccesible. En ese momento, se conmuta automáticamente por error a la región secundaria. Consulte Configuración del método de enrutamiento de conmutación por error.

• Sondeo de estado. Traffic Manager usa un sondeo HTTP (o HTTPS) para supervisar la disponibilidad de cada región. La sonda comprueba que haya una respuesta HTTP 200 para una ruta de URL especificada. Como procedimiento recomendado, cree un punto de conexión que informe del estado general de la aplicación y use este punto de conexión para el sondeo de estado. De lo contrario, el sondeo podría notificar un punto de conexión correcto cuando realmente se producen errores en las partes críticas de la aplicación. Para obtener más información, consulte Patrón de Supervisión de Puntos de Control de Salud.

Cuando Traffic Manager conmuta por error hay un período de tiempo cuando los clientes no pueden llegar a la aplicación. La duración se ve afectada por los siguientes factores:

• El sondeo de estado debe detectar que la región primaria se ha vuelto inaccesible.

• Los servidores DNS deben actualizar los registros DNS almacenados en caché para la dirección IP, que depende del período de vida de DNS (TTL). El TTL predeterminado es de 300 segundos (5 minutos), pero puede configurar este valor al crear el perfil de Traffic Manager.

Para obtener más información, consulte Acerca de la supervisión de Traffic Manager.

Si Traffic Manager conmuta por error, se recomienda realizar una conmutación por recuperación manual en lugar de implementar una conmutación por recuperación automática. De lo contrario, puede crear una situación en la que la aplicación se revierte entre regiones. Compruebe que todos los subsistemas de aplicación están en buen estado antes de conmutar por recuperación.

Tenga en cuenta que Traffic Manager conmuta automáticamente por recuperación de forma predeterminada. Para evitar esto, reduzca manualmente la prioridad de la región primaria después de un evento de conmutación por error. Por ejemplo, supongamos que la región primaria es la prioridad 1 y la secundaria es la prioridad 2. Después de una conmutación por error, establezca la región primaria en la prioridad 3 para evitar la conmutación por recuperación automática. Cuando esté listo para cambiar, vuelva a actualizar la prioridad a 1.

El siguiente comando CLI de Azure actualiza la prioridad:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --priority 3

Otro enfoque consiste en deshabilitar temporalmente el punto de conexión hasta que esté listo para realizar la conmutación por recuperación:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --endpoint-status Disabled

En función de la causa de una conmutación por error, es posible que tenga que volver a implementar los recursos dentro de una región. Antes de conmutar por recuperación, realice una prueba de preparación operativa. La prueba debe comprobar cosas como:

• Las máquinas virtuales están configuradas correctamente. (Todo el software necesario está instalado, IIS se está ejecutando, etc.)

• Los subsistemas de aplicación son correctos.

• Pruebas funcionales. (Por ejemplo, el nivel de base de datos es accesible desde el nivel web).

Configuración de grupos de disponibilidad AlwaysOn de SQL Server

Antes de Windows Server 2016, SQL Server los grupos de disponibilidad AlwaysOn requieren un controlador de dominio y todos los nodos del grupo de disponibilidad deben estar en el mismo dominio de Active Directory (AD).

Para configurar el grupo de disponibilidad:

• Como mínimo, coloque dos controladores de dominio en cada región.

• Asigne a cada controlador de dominio una dirección IP estática.

• Cree UNA VPN para habilitar la comunicación entre dos redes virtuales.

• Para cada red virtual, agregue las direcciones IP de los controladores de dominio (de ambas regiones) a la lista de servidores DNS. Puede usar el siguiente comando de la CLI. Para más información, consulte Cambio de servidores DNS.

  az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
  

• Cree un clúster de clústeres de conmutación por error (WSFC) Windows Server que incluya las instancias de SQL Server en ambas regiones.

• Cree un grupo de disponibilidad AlwaysOn SQL Server que incluya las instancias de SQL Server en las regiones primarias y secundarias. Consulte Extensión del grupo de disponibilidad AlwaysOn al centro de datos remoto Azure (PowerShell) para conocer los pasos.

  • Coloque la réplica principal en la región primaria.

  • Coloque una o varias réplicas secundarias en la región primaria. Configure estos para usar la confirmación sincrónica con conmutación automática por error.

  • Coloque una o varias réplicas secundarias en la región secundaria. Configure estos para usar la confirmación asincrónica , por motivos de rendimiento. (De lo contrario, todas las transacciones de T-SQL tienen que esperar en un recorrido de ida y vuelta a través de la red a la región secundaria).

Consideraciones de disponibilidad

Con una aplicación compleja de n niveles, es posible que no necesite replicar toda la aplicación en la región secundaria. En su lugar, es posible que simplemente replique un subsistema crítico que sea necesario para admitir la continuidad empresarial.

Traffic Manager es un posible punto de error en el sistema. Si se produce un error en el servicio Traffic Manager, los clientes no pueden acceder a la aplicación durante el tiempo de inactividad. Revise el Acuerdo de Nivel de Servicio de Traffic Manager y determine si el uso de Traffic Manager solo cumple los requisitos empresariales de alta disponibilidad. Si no es así, considere la posibilidad de agregar otra solución de administración de tráfico como conmutación por recuperación. Si se produce un error en el servicio Azure Traffic Manager, cambie los registros CNAME en DNS para que apunten al otro servicio de administración del tráfico. (Este paso se debe realizar manualmente y la aplicación no estará disponible hasta que se propaguen los cambios de DNS).

Para el clúster de SQL Server, hay dos escenarios de conmutación por error que se deben tener en cuenta:

• Se produce un error en todas las réplicas de base de datos SQL Server de la región primaria. Por ejemplo, este error puede producirse durante una interrupción regional. En ese caso, debe conmutar por error manualmente el grupo de disponibilidad, aunque Traffic Manager conmute por error automáticamente en el front-end. Siga los pasos descritos en Realizar una conmutación por error manual forzada de un grupo de disponibilidad de SQL Server, que describe cómo realizar una conmutación por error forzada mediante SQL Server Management Studio, Transact-SQL o PowerShell en SQL Server 2016.

  Warning

  Con la conmutación por error forzada, existe un riesgo de pérdida de datos. Una vez que la región primaria vuelva a estar en línea, tome una instantánea de la base de datos y use tablediff para encontrar las diferencias.

• Traffic Manager conmuta por error a la región secundaria, pero la réplica de base de datos principal SQL Server sigue estando disponible. Por ejemplo, es posible que se produzca un error en el nivel de front-end, sin afectar a las máquinas virtuales de SQL Server. En este caso, el tráfico de Internet se enruta a la región secundaria y esa región todavía puede conectarse a la réplica principal. Sin embargo, hay una mayor latencia, ya que las conexiones de SQL Server van entre regiones. En esta situación, realice una conmutación por error manual como se indica a continuación:

  1. Cambie temporalmente una réplica de base de datos SQL Server en la región secundaria a confirmación sincrónica. Este cambio garantiza que no se pierdan datos durante la conmutación por error.

  2. Conmutar por error a esa réplica.

  3. Al conmutar por recuperación a la región primaria, restaure la configuración de confirmación asincrónica.

Consideraciones sobre la capacidad de administración

Al actualizar la implementación, actualice una región a la vez para reducir la posibilidad de que se produzca un error global desde una configuración incorrecta o un error en la aplicación.

Pruebe la resistencia del sistema a errores. Estos son algunos escenarios de error comunes para probar:

• Apague las instancias de máquina virtual.

• Recursos de presión como CPU y memoria.

• Desconectar o retrasar la red.

• Procesos de bloqueo.

• Expiración de certificados.

• Simulación de errores de hardware.

• Apague el servicio DNS en los controladores de dominio.

Mida los tiempos de recuperación y compruebe que cumplen los requisitos empresariales. También se prueban combinaciones de modos de error.

Pasos siguientes

• Para más información sobre los patrones de nube de Azure, consulte Patrones de diseño en la nube.