Editar

Aplicación de n niveles para varias regiones

Azure Monitor
Administrador de tráfico de Azure
Azure SQL Database
Azure Virtual Machines

Esta arquitectura de referencia muestra un conjunto de procedimientos de demostrada eficacia para la ejecución de una aplicación de N niveles en varias regiones de Azure, con la finalidad de conseguir disponibilidad y una sólida estructura de recuperación ante desastres.

Architecture

Highly available network architecture for Azure N-tier applications

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

  • Regiones primarias y secundarias Use dos regiones para lograr una mayor disponibilidad. Una es la región primaria. La otra región es 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 dicha región no está disponible, Traffic Manager conmuta por error a la región secundaria. Para más información, consulte la sección Configuración de Traffic Manager.

  • Grupos de recursos. Cree un grupos de recursos independientes para la región primaria, la región secundaria y para Traffic Manager. Este método proporciona flexibilidad para administrar cada región como una única colección de recursos. Por ejemplo, podría volver a implementar una región, sin quitar la otra. Vincule los grupos de recursos, de modo que pueda ejecutar una consulta para obtener una lista de 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, se recomiendan los grupos de disponibilidad AlwaysOn de SQL para obtener alta disponibilidad. Cree un único grupo de disponibilidad que incluya las instancias de SQL Server en ambas regiones.

    Nota

    Tenga en cuenta también Azure SQL Database, que proporciona una base de datos relacional como un servicio en la nube. Con SQL Database, no es necesario configurar un grupo de disponibilidad ni administrar la conmutación por error.

  • Emparejamiento de red virtual. Empareje las dos redes virtuales para permitir la replicación de datos de la región primaria a la región secundaria. Para más información, consulte Emparejamiento de redes virtuales.

Componentes

  • Los conjuntos de disponibilidad garantizan que las máquinas virtuales implementadas en Azure se distribuyan entre varios nodos de hardware aislados en un clúster. Si se produce un error de hardware o software en Azure, solo un subconjunto de las VM se verá afectado y toda la solución seguirá disponible y en funcionamiento.
  • Las zonas de disponibilidad protegen las aplicaciones y los datos de errores del centro de datos. Las zonas de disponibilidad son ubicaciones físicas independientes dentro de una región de Azure. Cada zona de disponibilidad consta de uno o varios centros de datos equipados con alimentación, refrigeración y redes independientes.
  • Azure Traffic Manager es un equilibrador de carga de tráfico basado en DNS que distribuye el tráfico de manera óptima. Proporciona servicios en regiones globales de Azure, con alta disponibilidad y capacidad de respuesta.
  • Azure Load Balancer distribuye el tráfico entrante según reglas y sondeos de estado definidos. Una instancia de Load Balancer proporciona baja latencia y alto rendimiento, y puede escalar hasta millones de flujos para todas las aplicaciones TCP y UDP. Se utiliza un equilibrador de carga público en este escenario para distribuir el tráfico entrante del cliente en el nivel web. Se usa un equilibrador de carga interno en este escenario para distribuir el tráfico desde el nivel empresarial al clúster de SQL Server de back-end.
  • Azure Bastion proporciona conectividad segura de RDP y SSH a todas las VM de la red virtual en la que se aprovisiona. El uso de Azure Bastion protege las máquinas virtuales frente a la exposición de los puertos de RDP/SSH al mundo exterior, al tiempo que ofrece acceso seguro mediante RDP/SSH.

Recomendaciones

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 en la región secundaria. Esta arquitectura también puede ayudar si un determinado subsistema de la aplicación produce un error.

Existen varios enfoques generales para lograr una alta disponibilidad en regiones:

  • Activo/pasivo con espera activa. Un tráfico se dirige a una región, mientras el otro se encuentra en espera activa. El modo de espera activa significa que las VM de la región secundaria están asignadas y siempre se están ejecutando.
  • Activo/pasivo con espera pasiva. El tráfico se dirige a una región, mientras el otro se encuentra en espera pasiva. El modo de espera pasiva significa que las VM de la región secundaria no se asignan hasta que sea necesario para la conmutación por error. Este enfoque tiene un coste menor de ejecución, pero generalmente tarda más en ponerse en línea durante un error.
  • Activo/activo. Ambas regiones están activas y se equilibra la carga de las solicitudes entre ellas. Si una región deja de estar disponible, se elimina de la rotación.

Esta arquitectura de referencia se centra en el enfoque activo/pasivo con espera activa y usa Traffic Manager para la conmutación por error. Puede implementar una cantidad pequeña de VM para la espera activa y, a continuación, escalarlas horizontalmente si es necesario.

Emparejamiento regional

Cada región de Azure se empareja con otra región de la misma zona geográfica. En general, elija regiones del mismo par de regional (por ejemplo, Este de EE. UU. 2 y Centro de EE. UU.). Las ventajas de hacerlo son:

  • Si se produce una interrupción prolongada, se establece como prioridad la recuperación de al menos una región de cada par.
  • Las actualizaciones planeadas del sistema de Azure se implementan en las regiones emparejadas de manera secuencial para reducir el posible tiempo de inactividad.
  • Los pares residen dentro de la misma zona geográfica, de forma que se cumplen los requisitos de residencia de los datos.

Sin embargo, asegúrese de que ambas regiones admitan todos los servicios de Azure que necesita su aplicación (consulte Servicios por región). Para más información sobre los pares regionales, consulte Continuidad empresarial y recuperación ante desastres (BCDR): Regiones emparejadas de Azure.

Configuración de Traffic Manager

Al configurar Traffic Manager, tenga en cuenta lo siguiente:

  • Enrutamiento. Traffic Manager admite varios algoritmos de enrutamiento. Para el escenario descrito en este artículo, use el enrutamiento de prioridad (anteriormente conocido como enrutamiento de conmutación por error). Con esta configuración, Traffic Manager envía todas las solicitudes a la región primaria, a no ser que no sea posible comunicarse con ella. En ese momento, conmuta por error automáticamente a la región secundaria. Consulte Configuración del método de conmutación por error.
  • Sondeo de mantenimiento. Traffic Manager usa un sondeo HTTP (o HTTPS) para supervisar la disponibilidad de cada región. El sondeo comprueba si hay una respuesta HTTP 200 para una ruta de acceso de dirección URL especificada. Como procedimiento recomendado, cree un punto de conexión que indique el estado general de la aplicación y úselo para el sondeo de estado. En caso contrario, el sondeo podría informar de un punto de conexión correcto cuando realmente se producen errores en partes críticas de la aplicación. Para más información, consulte Patrón Health Endpoint Monitoring.

Cuando Traffic Manager conmuta por error, hay un período de tiempo en el que los clientes no pueden acceder a la aplicación. La duración viene determinada 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é con la dirección IP, lo cual depende del período de vida (TTL) de DNS. El TTL predeterminado es de 300 segundos (5 minutos), pero puede configurar este valor al crear el perfil de Traffic Manager.

Para más información, consulte el artículo sobre 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 automática. En caso contrario, puede crear una situación donde la aplicación va y viene incesantemente entre regiones. Compruebe que todos los subsistemas de aplicación tengan un estado correcto antes de la conmutación por recuperación.

Traffic Manager conmuta por recuperación automáticamente de manera predeterminada. Para evitar este problema, reduzca manualmente la prioridad de la región primaria después de un evento de conmutación por error. Por ejemplo, suponga que la región primaria tiene la prioridad 1 y la secundaria 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 de nuevo, actualice la prioridad a 1.

El siguiente comando de la CLI de Azure actualiza la prioridad:

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

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

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

Dependiendo de la causa de una conmutación por error, tendrá que volver a implementar los recursos dentro de una región. Antes de proceder a la conmutación por recuperación, realice una prueba de preparación operativa. La prueba debe comprobar aspectos como:

  • Máquinas virtuales configuradas correctamente. (Todo el software necesario está instalado, IIS está en funcionamiento, etc.).
  • El estado de los subsistemas de aplicación es correcto.
  • Pruebas funcionales. (Por ejemplo, la capa de base de datos es accesible desde la capa web).

Configuración de los grupos de disponibilidad AlwaysOn de SQL Server

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

Para configurar el grupo de disponibilidad:

  • Coloque dos controladores de dominio, como mínimo, en cada región.

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

  • Empareje las dos redes virtuales para habilitar la comunicación entre ellas.

  • 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 de Windows Server (WSFC) que incluya las instancias de SQL Server en ambas regiones.

  • Cree un grupo de disponibilidad AlwaysOn de SQL Server que incluya las instancias de SQL Server en las regiones primaria y secundaria. Consulte Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) (Extensión de un grupo de disponibilidad AlwaysOn para el acceso remoto a un centro de datos de 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 estas réplicas 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. Por motivos de rendimiento, configure estas réplicas para usar la confirmación asincrónica. (De lo contrario, todas las transacciones de T-SQL deberán esperar el recorrido de ida y vuelta a través de la red hasta la región secundaria).

      Nota:

      Las réplicas de confirmación asincrónica no admiten la conmutación automática por error.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Disponibilidad

Con una aplicación de N niveles compleja, no es necesario replicar toda la aplicación en la región secundaria. En su lugar, puede replicar simplemente un subsistema crítico que sea necesario para permitir 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 podrán 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 por sí solo cumple sus 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 el servicio Azure Traffic Manager no funciona, cambie los registros CNAME de DNS para que apunten a otro servicio de administración del tráfico. (Este paso debe realizarse manualmente, y la aplicación dejará de 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:

  • Todas las réplicas de base de datos de SQL Server de la región primaria generarán un error. Esto puede ocurrir, por ejemplo, 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 servidor front-end. Siga los pasos que se indican en Perform a Forced Manual Failover of a SQL Server Availability Group (Realización de una conmutación por error manual forzada de un grupo de disponibilidad de SQL Server), donde se describe cómo realizar una conmutación por error forzada mediante SQL Server Management Studio, Transact-SQL o PowerShell en SQL Server 2016.

    Advertencia

    Con la conmutación por error forzada, se corre el riesgo de pérdida de datos. Una vez que la región primaria vuelve 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 principal de base de datos SQL Server sigue estando disponible. Por ejemplo, si el nivel de front-end produjera un error, las máquinas virtuales de SQL Server no se verían afectadas. En ese caso, el tráfico de Internet se enrutaría a la región secundaria y esa región podría seguir conectándose a la réplica principal. Sin embargo, habrá una mayor latencia, ya que las conexiones de SQL Server atraviesan las regiones. En esta situación, debe realizar una conmutación por error manual como se indica a continuación:

    1. Cambie temporalmente una réplica de base de datos de SQL Server de la región secundaria a confirmación sincrónica. Con este paso se garantiza que no haya pérdida de datos durante la conmutación por error.
    2. Conmute por error a esa réplica.
    3. Cuando conmute por recuperación a la región primaria, restaure el valor de configuración de confirmación asincrónica.

Facilidad de uso

Al actualizar la implementación, actualice una región cada vez para reducir la probabilidad de un error global derivado de una configuración incorrecta o un error en la aplicación.

Pruebe la resistencia del sistema a los errores. Estos son algunos escenarios comunes de error que se pueden probar:

  • Apagado de las instancias de máquina virtual.
  • Recursos de presión, como CPU y memoria.
  • Desconexión o retraso de la red.
  • Bloqueo de procesos.
  • Caducidad de certificados.
  • Simulación de errores de hardware.
  • Apagado del servicio DNS en los controladores de dominio.

Medición de los tiempos de recuperación y comprobación de que cumplen los requisitos empresariales. Pruebe también combinaciones de modos de error.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Puede usar la calculadora de precios de Azure para calcular los costos. Estas son algunas otras consideraciones.

Virtual Machine Scale Sets

Virtual Machine Scale Sets está disponible en todos los tamaños de máquina virtual Windows. Solo se le cobrará por las VM de Azure que implemente y por los recursos de infraestructura subyacente adicionales que haya consumido, como el almacenamiento y las redes. No hay cargos incrementales por el servicio de Virtual Machine Scale Sets.

Para ver las opciones de precios de las máquinas virtuales únicas, consulte Precios de máquinas virtuales Windows.

Servidor SQL

Si elige Azure SQL DB, puede ahorrar costos porque no es necesario configurar un grupo de disponibilidad Always On y equipos de controlador de dominio. Hay varias opciones de implementación, desde una base de datos única hasta una instancia administrada o grupo elástico. Para más información, consulte Precios de Azure SQL.

Para ver las opciones de precios de las máquinas virtuales de SQL Server, consulte Precios de máquinas virtuales SQL.

Equilibradores de carga

Solo se le cobrará por la cantidad de reglas de equilibrio de carga y de salida que se hayan configurado. Las reglas NAT de entrada son gratuitas. Cuando no hay configurada ninguna regla, la instancia de Standard Load Balancer no se cobra por hora.

Precios de Traffic Manager

La facturación de Traffic Manager está basada en el número de consultas de DNS recibidas, con un descuento para los servicios que reciben más de mil millones de consultas mensuales. También se le cobra por cada punto de conexión supervisado.

Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.

Precios de emparejamiento de VNET

Una implementación de alta disponibilidad que use varias regiones de Azure usará el emparejamiento de redes virtuales. Hay distintos cargos por el emparejamiento de VNET en la misma región y para el emparejamiento de VNET global.

Para más información, consulte Precios de Virtual Network.

DevOps

Use una plantilla de Azure Resource Manager única para aprovisionar los recursos de Azure y sus dependencias. Use la misma plantilla para implementar los recursos en las regiones primaria y secundaria. Incluya todos los recursos de la misma red virtual para que estén aislados en la misma carga de trabajo básica. Al incluir todos los recursos, se facilita la asociación de recursos específicos de la carga de trabajo a un equipo de DevOps para que este pueda administrar todos los aspectos de esos recursos de manera independiente. Este aislamiento permite que el equipo y servicios de DevOps realicen la integración continua y la entrega continua (CI/CD).

Además, puede usar distintas plantillas de Azure Resource Manager e intégrelas con Azure DevOps Services para aprovisionar entornos diferentes en minutos; por ejemplo, para replicar escenarios similares a la producción o entornos de prueba de carga solo cuando sea necesario y ahorrar costos.

Considere la posibilidad de usar Azure Monitor para analizar y optimizar el rendimiento de la infraestructura, así como supervisar y diagnosticar problemas de red sin iniciar sesión en las máquinas virtuales. Application Insights es en realidad uno de los componentes de Azure Monitor, que proporciona métricas y registros completos para comprobar el estado de todo el entorno de Azure. Azure Monitor le ayudará a realizar un seguimiento del estado de la infraestructura.

Asegúrese de supervisar no solo los elementos de proceso que admiten el código de aplicación, sino también la plataforma de datos (en particular las bases de datos), ya que un bajo rendimiento de la capa de datos de una aplicación podría tener consecuencias graves.

Para probar el entorno de Azure en el que se ejecutan las aplicaciones, debe realizar un control de versiones e implementarlo a través de los mismos mecanismos que el código de la aplicación. Después, se puede probar y validar mediante los paradigmas de prueba de DevOps.

Para más información, consulte la sección de Excelencia operativa en Marco de buena arquitectura de Microsoft Azure.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

La siguiente arquitectura usa algunas de las mismas tecnologías: