Confiabilidad en Azure Spring Apps
Este artículo contiene información detallada sobre la resistencia regional con zonas de disponibilidad y recuperación ante desastres y continuidad empresarial entre regiones para Azure Spring Apps.
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad son grupos físicamente separados de centros de datos dentro de cada región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.
Para más información sobre las zonas de disponibilidad en Azure, consulte ¿Qué son las zonas de disponibilidad?.
Azure Spring Apps admite la redundancia de zona. Cuando se crea una instancia de servicio de Azure Spring Apps con la redundancia de zona habilitada, Azure Spring Apps distribuye automáticamente recursos básicos entre secciones lógicas de la infraestructura subyacente de Azure. El recurso de proceso subyacente distribuye las máquinas virtuales en todas las zonas de disponibilidad para garantizar la capacidad de proceso. El recurso de almacenamiento subyacente replica los datos entre zonas de disponibilidad para mantenerlo disponible aunque existan errores en el centro de datos. Esta distribución proporciona un mayor nivel de disponibilidad para protegerse contra errores de hardware o eventos de mantenimiento planificados.
Requisitos previos
La redundancia de zona no está disponible en el plan Básico.
Azure Spring Apps admite zonas de disponibilidad en las regiones siguientes:
- Este de Australia
- Sur de Brasil
- Centro de Canadá
- Centro de EE. UU.
- Este de Asia
- Este de EE. UU.
- Este de EE. UU. 2
- Centro de Francia
- Centro-oeste de Alemania
- Norte de Europa
- Japón Oriental
- Centro de Corea del Sur
- Norte de Sudáfrica
- Centro-sur de EE. UU.
- Sudeste de Asia
- Sur de Reino Unido 2
- Oeste de Europa
- Oeste de EE. UU. 2
- Oeste de EE. UU. 3
Creación de una instancia de Azure Spring Apps con zonas de disponibilidad habilitadas
Nota:
Solo puede habilitar la redundancia de zona al crear la instancia de servicio de Azure Spring Apps. No se puede cambiar la propiedad de redundancia de zona después de la creación.
Puede habilitar la redundancia de zona en Azure Spring Apps mediante la CLI de Azure o Azure Portal.
Para crear un servicio en Azure Spring Apps con la redundancia de zona habilitada mediante la CLI de Azure, incluya el parámetro --zone-redundant al crear el servicio en Azure Spring Apps, como se muestra en el ejemplo siguiente:
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
Habilitación de su propio recurso con zonas de disponibilidad habilitadas
Puede habilitar su propio recurso en Azure Spring Apps, como su propio almacenamiento persistente. Sin embargo, debe asegurarse de habilitar la redundancia de zona para el recurso. Para más información, consulte Cómo habilitar su propio almacenamiento persistente en Azure Spring Apps.
Experiencia a nivel de zona
Cuando se produce un error en una instancia de aplicación porque se encuentra en un nodo de máquina virtual en una zona con errores, Azure Spring Apps crea una nueva instancia de aplicación para la aplicación con errores en otro nodo de máquina virtual en otra zona de disponibilidad. Los usuarios pueden experimentar una breve interrupción durante este tiempo. No se requiere ninguna acción de usuario y el servicio restaurará la instancia afectada de Azure Spring Apps.
Precios
No hay ningún costo adicional por habilitar la redundancia de zona. Solo tiene que pagar por el plan Estándar o Enterprise, que se necesitan para habilitar la redundancia de zona.
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.
El servicio Azure Spring Apps no proporciona recuperación ante desastres geográfica, pero una planeación cuidadosa puede evitar que experimente tiempo de inactividad.
Para garantizar una alta disponibilidad y protección frente a desastres, implemente las aplicaciones hospedadas en Azure Spring Apps en varias regiones. Azure proporciona una lista de regiones emparejadas para facilitar el planeamiento de implementaciones de aplicaciones.
Tenga en cuenta los tres factores clave siguientes al diseñar la arquitectura:
- Disponibilidad en regiones. Para minimizar el retardo de la red y el tiempo de transmisión, elija una región que admita la redundancia de zona de Azure Spring Apps o un área geográfica próxima a los usuarios.
- Regiones emparejadas de Azure. Para garantizar la coordinación de las actualizaciones de la plataforma y las iniciativas de recuperación prioritarias si es necesario, elija regiones emparejadas dentro del área geográfica elegida.
- Disponibilidad del servicio. Decida si los niveles de acceso de las regiones emparejadas deben ser frecuente/frecuente, frecuente/normal o frecuente/poco frecuente.
Uso de Azure Traffic Manager para enrutar el tráfico
Azure Traffic Manager proporciona equilibrio de carga de tráfico basado en DNS y puede distribuir el tráfico de red entre varias regiones. Use Azure Traffic Manager para dirigir a los clientes a la instancia más próxima del servicio Azure Spring Apps. Para conseguir los máximos niveles de rendimiento y redundancia, dirija todo el tráfico de aplicaciones a través de Azure Traffic Manager antes de enviarlo a la instancia de servicio de Azure Spring Apps. Para más información, consulta ¿Qué es Traffic Manager?
Si tiene aplicaciones de Azure Spring Apps en varias regiones, Azure Traffic Manager puede controlar el flujo de tráfico a las aplicaciones en cada región. Defina un punto de conexión de Azure Traffic Manager para cada servicio mediante la dirección IP del servicio. Debería conectarse a un nombre DNS de Azure Traffic Manager que apunte a la instancia de servicio de Azure Spring Apps. Azure Traffic Manager equilibra el tráfico a través de los puntos de conexión definidos. Si se produce un desastre en un centro de datos, Azure Traffic Manager dirigirá el tráfico de esa región a su par para garantizar la continuidad del servicio.
Siga estos pasos para crear una instancia de Azure Traffic Manager para instancias de Azure Spring Apps:
Cree instancias de Azure Spring Apps en dos regiones diferentes. Por ejemplo, cree instancias de servicio en Este de EE. UU. y Oeste de Europa, como se muestra en la tabla siguiente. Cada instancia funcionará como punto de conexión principal y de conmutación por error para el tráfico.
Nombre del servicio Location Aplicación service-sample-a Este de EE. UU. gateway / auth-service / account-service service-sample-b Oeste de Europa gateway / auth-service / account-service Configure un dominio personalizado para las instancias de servicio. Para más información, vea Tutorial: Asignación de un dominio personalizado existente a Azure Spring Apps. Tras su correcta instalación, ambas instancias de servicio se enlazarán al mismo dominio personalizado, como
bcdr-test.contoso.com.Cree un administrador de tráfico y dos puntos de conexión. Para obtener instrucciones, consulte Inicio rápido: Creación de un perfil de Traffic Manager mediante Azure Portal, que genera el siguiente perfil de Traffic Manager:
- Nombre DNS de Traffic Manager:
http://asa-bcdr.trafficmanager.net - Perfiles de punto de conexión:
Profile Tipo Destino Priority Configuración del encabezado personalizado Perfil de punto de conexión A Punto de conexión externo service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comPerfil de extremo B Punto de conexión externo service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Nombre DNS de Traffic Manager:
Cree un registro CNAME en una zona DNS similar al ejemplo siguiente:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.
El entorno ya se ha configurado. Si usó los valores de ejemplo de los artículos relacionados, debería poder acceder a la aplicación mediante https://bcdr-test.contoso.com.
Uso de Azure Front Door y Azure Application Gateway para enrutar el tráfico
Azure Front Door es un punto de entrada global y escalable que usa la red perimetral global de Microsoft para crear aplicaciones web rápidas, seguras y muy escalables. Azure Front Door proporciona la misma redundancia multigeográfica y enrutamiento a la región más cercana que Azure Traffic Manager. Azure Front Door también proporciona características avanzadas, como la terminación del protocolo TLS, el procesamiento de capas de aplicación y Web Application Firewall (WAF). Para más información, consulte ¿Qué es Azure Front Door?
En el diagrama siguiente se muestra la arquitectura de una instancia de servicio de Azure Spring Apps integrada en una red virtual con redundancia de varias regiones. En el diagrama se muestra la configuración correcta del proxy inverso para Application Gateway y Front Door con un dominio personalizado. Esta arquitectura se basa en el escenario descrito en Exposición de aplicaciones con TLS de un extremo a otro en una red virtual. Este enfoque combina dos instancias de inserción de red virtual de Azure Spring Apps integradas en Application-Gateway en una instancia con redundancia geográfica.
