Implementación empresarial de alta disponibilidad mediante App Service Environment

Las zonas de disponibilidad son colecciones de centros de datos separados físicamente dentro de una región determinada. La implementación de recursos entre zonas garantiza que las interrupciones limitadas a una zona no afecten a la disponibilidad de las aplicaciones. Esta arquitectura muestra cómo puede mejorar la resistencia de una implementación de App Service Environment mediante su implementación en una arquitectura con redundancia de zona. Estas zonas no están relacionadas con la proximidad. Se pueden asignar a diferentes ubicaciones físicas con distintas suscripciones. Esta arquitectura presupone la implementación de una sola suscripción.

Cuando se configura App Service Environment para que tenga redundancia de zona, la plataforma distribuye automáticamente las instancias del plan de Azure App Service entre las tres zonas de la región seleccionada. Por lo tanto, el número mínimo de recuento de instancias del plan de App Service es siempre es tres.

Los servicios de Azure que admiten zonas de disponibilidad pueden ser zonales, con redundancia de zona o ambos. Los servicios zonales se pueden implementar en una zona específica. Los servicios con redundancia de zona se pueden implementar automáticamente entre zonas. Para obtener instrucciones detalladas y recomendaciones, consulte Compatibilidad con la zona de disponibilidad. La versión anterior de App Service Environment (v2) solo admite implementaciones zonales, pero la versión actual (v3) admite implementaciones con redundancia de zona.

Hay disponible una implementación de referencia de esta arquitectura en GitHub.

Architecture

Descargue un archivo Visio de esta arquitectura.

Los recursos de las subredes de App Service Environment de esta implementación de referencia son los mismos que los de la arquitectura de implementación estándar de App Service Environment. Esta implementación de referencia usa las funcionalidades con redundancia de zona de App Service Environment v3 y Azure Cache for Redis para proporcionar una mayor disponibilidad. Tenga en cuenta que el ámbito de esta arquitectura de referencia está limitado a una sola región.

Flujo de trabajo

Esta sección describe la naturaleza de la disponibilidad para los servicios que se usan en esta arquitectura:

• App Service Environment v3 se puede configurar para la redundancia de zona. Solo puede configurar la redundancia de zona durante la creación del App Service Environment y solo en regiones que admitan todas las dependencias de App Service Environment v3. Cada plan de App Service en un App Service Environment con redundancia de zona debe tener un mínimo de tres instancias para que se puedan implementar en tres zonas. El cargo mínimo es para nueve instancias. Para obtener más información, consulte la guía de precios. Para encontrar instrucciones detalladas y recomendaciones, consulte Compatibilidad de App Service Environment con Availability Zones.

• Azure Virtual Network abarca todas las zonas de disponibilidad que se encuentran en una sola región. Las subredes de la red virtual también cruzan zonas de disponibilidad. Para más información, lea los Requisitos de red para App Service Environment.

• Application Gateway v2 tiene redundancia de zona. Al igual que la red virtual, abarca varias zonas de disponibilidad por región. Esto significa que, a su vez, una sola puerta de enlace de aplicación es suficiente para un sistema de alta disponibilidad, como se muestra en esta arquitectura de referencia. La arquitectura de referencia usa la SKU de WAF de Application Gateway, que proporciona una mayor protección frente a amenazas y vulnerabilidades comunes en función de una implementación del conjunto de reglas principal (CRS) del Open Web Application Security Project (OWASP). Para más información, consulte Escalado de Application Gateway v2 y WAF v2.

• Azure Firewall tiene compatibilidad integrada con alta disponibilidad. Puede abarcar varias zonas sin ninguna configuración adicional.

  Si lo necesita, también puede configurar una zona de disponibilidad específica al implementar el firewall. Consulte Azure Firewall y Availability Zones para más información. (Esta configuración no se usa en la arquitectura de referencia).

• Microsoft Entra ID es un servicio global de gran disponibilidad y redundancia que abarca zonas de disponibilidad y regiones. Para más información, consulte Avanzar en la disponibilidad de Microsoft Entra.

• Las Acciones de GitHub proporcionan funcionalidades de integración continua e implementación continua (CI/CD) en esta arquitectura. Dado que App Service Environment está en la red virtual, se usa una máquina virtual como jumpbox en la red virtual para implementar las aplicaciones en los planes de App Service. La acción compila las aplicaciones fuera de la red virtual. Para una mayor seguridad y una conectividad RDP/SSH ininterrumpida, considere el uso de Azure Bastion para el jumpbox.

• Azure Cache for Redis es un servicio con redundancia de zona. Una instancia de caché con redundancia de zona se ejecuta en máquinas virtuales implementadas en varias zonas de disponibilidad. Este servicio proporciona mayor resistencia y disponibilidad.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Disponibilidad

Entorno de App Service

Puede implementar App Service Environment entre zonas de disponibilidad para proporcionar resistencia y confiabilidad para las cargas de trabajo críticas para la empresa. Esta configuración también se conoce como redundancia de zona.

Cuando se implementa la redundancia de zona, la plataforma distribuye automáticamente las instancias del plan de App Service entre las tres zonas de la región seleccionada. Por lo tanto, el número mínimo de recuento de instancias del plan de App Service es siempre es tres. Si se especifica una capacidad superior a tres y el número de instancias es divisible entre tres, las instancias se distribuyen de manera uniforme. De lo contrario, las instancias restantes se agregan a la zona restante o se implementan entre las dos zonas restantes.

• Las zonas de disponibilidad se configuran al crear la instancia de App Service Environment.
• Todos los planes de App Service creados en ese App Service Environment requieren un mínimo de tres instancias. Tendrán automáticamente redundancia de zona.
• Solo puede especificar las zonas de disponibilidad al crear una nueva instancia de App Service Environment. Una instancia de App Service Environment existente no se puede convertir para que use zonas de disponibilidad.
• Las zonas de disponibilidad solo se admiten en un subconjunto de regiones.

Para más información, consulte Migración de App Service Environment para compatibilidad con zonas de disponibilidad.

Resistencia

Las aplicaciones que se ejecutan en App Service Environment forman el grupo de back-end para Application Gateway. Cuando una solicitud a la aplicación procede de la red pública de Internet, la puerta de enlace reenvía la solicitud a la aplicación que se ejecuta en App Service Environment. Esta arquitectura de referencia implementa comprobaciones de estado en el front-end web principal, votingApp. Este sondeo de estado comprueba si la API web y Redis Cache están en buen estado. Puede ver el código que implementa este sondeo en Startup.cs:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

El siguiente fragmento de código muestra cómo el script commands_ha.azcli configura los grupos de back-end y el sondeo de estado para la puerta de enlace de aplicación:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Si alguno de los componentes (el front-end web, la API o la memoria caché) produce un error en el sondeo de estado, Application Gateway enruta la solicitud a la otra aplicación del grupo de back-end. Esta configuración garantiza que la solicitud siempre se enrute a la aplicación en una subred de App Service Environment totalmente disponible.

El sondeo de estado también se implementa en la implementación de referencia estándar. Ahí, la puerta de enlace simplemente devuelve un error si dicho sondeo no se ejecuta correctamente. Sin embargo, en la implementación de alta disponibilidad, mejora la resistencia de la aplicación y la calidad de la experiencia del usuario.

Optimización de costos

La optimización de costos trata 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.

Los aspectos relativos a los costos de la arquitectura de alta disponibilidad son muy parecidos a los de la implementación estándar.

Las siguientes diferencias pueden afectar al costo:

• Se aplica un cargo mínimo de nueve instancias del plan de App Service en una instancia de App Service Environment con redundancia de zona. Para obtener más información, vea Precios de App Service Environment.
• Azure Cache for Redis también es un servicio con redundancia de zona. Una caché con redundancia de zona se ejecuta en máquinas virtuales implementadas en varias zonas de disponibilidad para proporcionar alta resistencia y disponibilidad.

El inconveniente de un sistema de alta disponibilidad, resistente y altamente seguro es que implica un mayor costo. Use la calculadora de precios para evaluar sus necesidades con respecto a los precios.

Consideraciones de la implementación

Esta implementación de referencia usa la misma canalización de CI/CD de nivel de producción que la implementación estándar, con solo una máquina virtual jumpbox. Sin embargo, puede decidir usar un jumpbox para cada una de las tres zonas. Esta arquitectura usa solo un jumpbox porque el jumpbox no afecta a la disponibilidad de la aplicación. El jumpbox solo se usa para la implementación y las pruebas.

Implementación de este escenario

Para obtener más información sobre cómo implementar la solución de referencia de esta arquitectura, consulte el archivo Léame de GitHub. Use el script para la implementación de alta disponibilidad.

Colaboradores

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

Creadores de entidad de seguridad:

• Deep Bhattacharya | Arquitecto de soluciones en la nube
• Suhas Rao | Arquitecto de soluciones en la nube

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

Pasos siguientes

Puede modificar esta arquitectura escalando horizontalmente las aplicaciones dentro de la misma región o entre varias regiones, en función de la capacidad de carga máxima esperada. La replicación de aplicaciones en varias regiones puede ayudar a mitigar los riesgos de errores en centros de datos geográficos más amplios, como aquellos ocasionados por terremotos u otros desastres naturales. Para obtener más información sobre el escalado horizontal, lea Escala distribuida geográficamente con App Service Environment. En el caso de una solución de enrutamiento global y de alta disponibilidad, considere la posibilidad de usar Azure Front Door.