Línea base de migración de zona de disponibilidad de Azure

En este artículo se muestra cómo evaluar la preparación de la zona de disponibilidad de la aplicación con el fin de migrar desde una zona de no disponibilidad a la compatibilidad con zonas de disponibilidad. Le llevaremos por los pasos que necesitará para determinar cómo puede aprovechar la compatibilidad con la zona de disponibilidad en consonancia con los requisitos regionales y de la aplicación. Para obtener información más detallada sobre las zonas de disponibilidad y las regiones que las admiten, consulte ¿Qué son las regiones de Azure y las zonas de disponibilidad?

Al crear cargas de trabajo confiables, puede elegir al menos una de las siguientes configuraciones de zona de disponibilidad:

  • Zonales. Una configuración zonal proporciona una zona de disponibilidad específica y seleccionada automáticamente.

  • Redundancia de zona. Una configuración con redundancia de zona proporciona recursos que se replican o distribuyen entre zonas automáticamente.

Además de las dos opciones de zona de disponibilidad, con redundancia de zona y zona, Azure ofrece servicios globales, lo que significa que están disponibles globalmente independientemente de la región. Dado que estos servicios siempre están disponibles entre regiones, son resistentes a interrupciones regionales y zonales.

Para ver qué servicios de Azure admiten zonas de disponibilidad, consulte Servicio de zona de disponibilidad y compatibilidad regional.

Nota

Cuando no selecciona una configuración de zona para el recurso, ya sea zonal o con redundancia de zona, el recurso y sus subcomponentes no serán resistentes a la zona y pueden dejar de funcionar durante una interrupción zonal en esa región.

Consideraciones para migrar a la compatibilidad con zonas de disponibilidad

Hay varias maneras posibles de crear una aplicación confiable de Azure con zonas de disponibilidad que cumplan los objetivos de SLA y confiabilidad. Siga los pasos siguientes para elegir el enfoque adecuado para sus necesidades en función de las consideraciones técnicas y normativas, las funcionalidades de servicio, la residencia de datos, los requisitos de cumplimiento y la latencia.

Paso 1: Comprobación de si la región de Azure admite zonas de disponibilidad

En este primer paso, deberá validar que la región de Azure seleccionada admite zonas de disponibilidad, así como los servicios de Azure necesarios para la aplicación.

Si su región admite zonas de disponibilidad, se recomienda encarecidamente configurar la carga de trabajo para zonas de disponibilidad. Si la región no admite zonas de disponibilidad, deberá usar la guía de Azure Resource Mover para migrar a una región que ofrezca compatibilidad con la zona de disponibilidad.

Nota

Para algunos servicios, las zonas de disponibilidad solo se pueden configurar durante la implementación. Si desea incluir zonas de disponibilidad para los servicios existentes, es posible que tenga que volver a implementar. Consulte la documentación específica del servicio en Introducción a la migración de zonas de disponibilidad para productos y servicios de Microsoft Azure.

Paso 2: Comprobación de la disponibilidad de productos y SKU en la región de Azure

En este paso, validará que los servicios y SKU de Azure necesarios están disponibles en las zonas de disponibilidad de la región de Azure seleccionada.

Para comprobar la compatibilidad regional de los servicios, consulte Productos disponibles por región.

Para enumerar las SKU de máquina virtual disponibles por región y zona de Azure, consulte Comprobación de la disponibilidad de la SKU de máquina virtual.

Si la región no admite los servicios y las SKU que requiere la aplicación, deberá volver al paso 1: Comprobar la disponibilidad del producto en la región de Azure para buscar una nueva región que admita los servicios y las SKU que requiere la aplicación. Se recomienda encarecidamente configurar la carga de trabajo con redundancia de zona.

En el caso de la alta disponibilidad zonal de azure IaaS Virtual Machines, use Virtual Machine Scale Sets (VMSS) Flex para distribuir las máquinas virtuales entre varias zonas de disponibilidad.

Paso 3: Considerar los requisitos de la aplicación

En este paso final, determinará, en función de los requisitos de la aplicación, qué tipo de compatibilidad con zona de disponibilidad es más adecuado para la aplicación.

A continuación se muestran tres preguntas importantes que le ayudarán a elegir la implementación correcta de la zona de disponibilidad:

¿La aplicación incluye componentes sensibles a la latencia?

Las zonas de disponibilidad de Azure dentro de la misma región de Azure están conectadas por una red de alto rendimiento con una latencia de ida y vuelta de menos de 2 ms.

El enfoque recomendado para lograr una alta disponibilidad, si la baja latencia no es un requisito estricto, es configurar la carga de trabajo con una implementación con redundancia de zona.

Para los componentes críticos de la aplicación que requieren proximidad física y baja latencia, como juegos, simulación de ingeniería y comercio de alta frecuencia (HFT), se recomienda configurar una implementación zonal. Virtual Machine Scale Sets Flex proporciona un proceso alineado con la zona junto con los discos de almacenamiento conectados.

¿El código de la aplicación tiene la preparación para controlar un modelo distribuido?

En el caso de un modelo de microservicios distribuidos y en función de la aplicación, existe la posibilidad de intercambiar datos en curso entre microservicios entre zonas. Este intercambio continuo de datos a través de las API podría afectar al rendimiento. Para mejorar el rendimiento y mantener una arquitectura confiable, puede elegir la implementación zonal.

Con una implementación zonal, debe:

  1. Identifique los recursos o servicios confidenciales de latencia en la arquitectura.

  2. Confirme que los recursos o servicios confidenciales de latencia admiten la implementación zonal.

  3. Localice conjuntamente los servicios o recursos confidenciales de latencia en la misma zona. Otros servicios de la arquitectura pueden seguir siendo redundantes de zona.

  4. Replique los servicios zonales sensibles a la latencia en varias zonas de disponibilidad para garantizar la resistencia de la zona.

  5. Equilibrio de carga entre varias implementaciones zonales con equilibradores de carga estándar o global.

Si el servicio de Azure admite zonas de disponibilidad, se recomienda encarecidamente usar la redundancia de zona mediante la propagación de nodos entre las zonas para obtener un Acuerdo de Nivel de Servicio de tiempo de actividad superior y la protección contra interrupciones zonales.

Para una aplicación de 3 niveles, es importante comprender la aplicación, la empresa y los niveles de datos; así como su estado (con estado o sin estado) para diseñar en consonancia con los procedimientos recomendados e instrucciones según el tipo de carga de trabajo.

Para cargas de trabajo especializadas en Azure como se muestra a continuación, consulte las instrucciones de arquitectura de zona de aterrizaje y los procedimientos recomendados correspondientes.

¿Desea lograr la continuidad empresarial y la recuperación ante desastres en la misma región de Azure debido a los requisitos de cumplimiento, residencia de datos o gobernanza?

Para lograr la continuidad empresarial y la recuperación ante desastres dentro de la misma región y cuando no hay ningún par regional, se recomienda encarecidamente configurar la carga de trabajo con redundancia de zona. Un enfoque de una sola región también se aplica a determinados sectores que tienen requisitos estrictos de residencia y gobernanza de datos dentro de la misma región de Azure. Para obtener información sobre cómo replicar, conmutar por error y conmutar por recuperación máquinas virtuales de Azure desde una zona de disponibilidad a otra dentro de la misma región de Azure, consulte Habilitación de la recuperación ante desastres de máquinas virtuales de Azure entre zonas de disponibilidad.

Si necesita varias regiones o si la región de Azure no admite zonas de disponibilidad, se recomienda usar pares regionales. Los pares regionales están situados a una distancia lejos a unos 100 kilómetros de distancia, y le proporcionan protección de radio de explosión frente a errores de nivel regional, como incendios, inundaciones, terremotos y otras calamidades naturales o imprevistas. Para obtener más información, consulte Replicación entre regiones en Azure: continuidad empresarial y recuperación ante desastres.

Nota

Puede haber escenarios en los que una combinación de servicios zonales, con redundancia de zona y globales funciona mejor para satisfacer los requisitos empresariales y técnicos.

Otros aspectos que se deben tener en cuenta

  • Para obtener información sobre cómo probar las aplicaciones para obtener disponibilidad y resistencia, consulte Pruebas de aplicaciones para disponibilidad y resistencia.

  • Cada centro de datos de una región se asigna a una zona física. Las zonas físicas se asignan a las zonas lógicas de la suscripción de Azure. A las suscripciones de Azure se les asigna automáticamente esta asignación en el momento de crear una suscripción. Puede usar la API REST de ARM dedicada, listLocations y establecer la versión de API en 2022-12-01 para enumerar la asignación de zona lógica a la zona física de la suscripción. Esta información es importante para los componentes críticos de la aplicación que requieren colocalización con recursos de Azure clasificados como servicios estratégicos que pueden no estar disponibles en todas las zonas físicas.

  • Los cargos de ancho de banda entre zonas se aplican cuando el tráfico se mueve entre zonas. Para más información sobre los precios de ancho de banda, consulte Precios de ancho de banda.

Pasos siguientes