Habilitar la resistencia de zona para cargas de trabajo de Azure

Para que las aplicaciones sean más resistentes a los errores de hardware relacionados con la zona, las interrupciones de red y los desastres naturales, es importante diseñar las cargas de trabajo de Azure para la resistencia de zona. Al distribuir recursos entre varias zonas de disponibilidad dentro de una región, se reduce el riesgo de una interrupción de una sola zona que afecta a los servicios críticos.

Aunque es un procedimiento recomendado abordar la resistencia de zona durante la planeación inicial y la implementación de cargas de trabajo, es habitual convertir cargas de trabajo no resistentes existentes a configuraciones resistentes a zonas. En general, el procesamiento de la habilitación de la resistencia de zona para cargas de trabajo existentes es sencillo y Microsoft sigue simplificando el proceso. Sin embargo, cualquier cambio en la carga de trabajo puede introducir una cantidad de riesgo. Una vez que comprenda los riesgos implicados, podrá evaluar y priorizar qué cargas de trabajo y servicios dentro de esas cargas de trabajo son más importantes para su negocio y, después, aplicar resistencia de zona a los recursos más impactantes primero.

En este artículo se describen las consideraciones clave para habilitar la resistencia de zona en las cargas de trabajo de Azure. También le ayuda a planear e implementar una transición correcta a una arquitectura más resistente.

¿Qué es la resistencia de zona?

Los servicios de Azure se pueden hacer resistentes a las interrupciones de zona de disponibilidad de dos maneras principales:

• Servicios con redundancia de zona: Muchos servicios de Azure admiten redundancia de zona. Estos servicios replican automáticamente los datos entre zonas de disponibilidad, distribuyen las solicitudes entrantes y conmutan por error a distintas zonas durante un error de zona. Cada servicio admite estas funcionalidades de una manera que tenga sentido para ese servicio específico. Algunos servicios tienen redundancia de zona de forma predeterminada, mientras que es posible que otros servicios necesiten configurar la redundancia de zona.

• Servicios zonales: Algunos servicios de Azure son zonales, lo que significa que se pueden anclar a una zona de disponibilidad específica. Para lograr resistencia de zona mediante un servicio zonal, implemente instancias independientes del servicio en varias zonas de disponibilidad. También es posible que tenga que administrar la distribución del tráfico, la replicación de datos y la conmutación por error entre las instancias.

Algunos servicios se pueden implementar en una configuración con redundancia de zona o zonal. En la mayoría de los casos, es mejor implementar servicios con redundancia de zona cuando pueda.

Para más información, consulte Tipos de soporte de zonas de disponibilidad.

Procedimiento de habilitación de zona

Siga estos pasos para revisar sistemáticamente las cargas de trabajo de Azure, priorizarlas por resistencia de zona y habilitar la resistencia de zona para cada componente.

Prerrequisitos

Antes de empezar, realice las acciones siguientes:

• Identifique cada carga de trabajo. Una carga de trabajo hace referencia a una colección de recursos de aplicación, datos e infraestructura auxiliar que funcionan conjuntamente para lograr resultados empresariales definidos. Para más información sobre las cargas de trabajo y cómo definirlas, consulte Cargas de trabajo del Marco de buena arquitectura.

• Priorice los flujos de usuario y sistema de cada carga de trabajo. Comprenda las rutas críticas y las dependencias de sus cargas de trabajo para determinar qué componentes deben hacerse resilientes a nivel de zona primero. Para obtener más información sobre cómo usar el análisis de flujo crítico para priorizar los flujos de trabajo, consulte Prioridad de las cargas de trabajo para la resistencia de zona.

• Asigne una clasificación de importancia crítica a cada carga de trabajo y flujo. Esta clasificación le ayuda a comprender el impacto de una posible interrupción en su negocio y guía sus decisiones sobre qué cargas de trabajo priorizar para la resistencia de la zona. Tenga en cuenta también la cantidad de tiempo de inactividad aceptable mientras vuelve a configurar las cargas de trabajo.

  Puede usar una taxonomía para clasificar las cargas de trabajo en función de su importancia. Este enfoque le ayuda a centrar sus esfuerzos en los servicios más importantes.

  Considere la taxonomía de ejemplo siguiente para clasificar las cargas de trabajo.

  Tipo de carga de trabajo	Description	Efecto de la interrupción
  Crítico para la misión	Flujos críticos y cargas de trabajo que deben ser altamente confiables, siempre disponibles, resistentes a errores y operativos	Cualquier interrupción de las funciones esenciales corre inmediatamente riesgos catastróficos de daño empresarial o introduce riesgos para la vida humana.
  Crítico para la empresa	Flujos y cargas de trabajo esenciales que operan funciones empresariales importantes	La interrupción corre algunos riesgos de pérdida financiera o daño de marca.
  Operaciones empresariales	Contribuye a la eficacia de las operaciones empresariales, pero fuera de la línea directa de servicio a los clientes	Puede tolerar algún nivel de interrupción.
  Administrativo	Flujos de producción internos y cargas de trabajo no alineadas con las operaciones empresariales	Puede tolerar interrupciones.

  Para obtener más información sobre cómo clasificar las cargas de trabajo según la clasificación de importancia crítica, consulte Asignación de una clasificación de importancia a cada flujo.

• Compruebe que las regiones donde residen los recursos de Azure admiten zonas de disponibilidad. Consulte la Lista de regiones de Azure. Si una región no admite zonas de disponibilidad, considere la posibilidad de reubicar los recursos en una región que sí lo haga. Para más información, consulte Traslado de recursos de Azure entre grupos de recursos, suscripciones o regiones.

Paso 1: Priorizar los servicios de Azure para la resistencia de zona

Después de determinar qué flujos de carga de trabajo son más críticos para su empresa, puede centrarse en los servicios de Azure de los que dependen esos flujos. Algunos servicios de Azure son más críticos para las aplicaciones que otras. Priorice estos servicios para ayudar a garantizar que las aplicaciones permanezcan disponibles y resistentes si se produce un error de zona.

Use las instrucciones siguientes para priorizar los grupos de servicios de Azure en función de su importancia para las cargas de trabajo. Tenga en cuenta los requisitos empresariales y la arquitectura de aplicaciones específicos al determinar la prioridad de los servicios para la resistencia de zona.

1. Comience con los servicios de red. Las cargas de trabajo tienden a compartir servicios de red, por lo que un aumento de la resistencia de estos servicios puede mejorar la resistencia de varias cargas de trabajo a la vez.

   Muchos servicios de red esenciales tienen redundancia de zona de manera automática, pero debe centrarse en componentes como las puertas de enlace de Azure ExpressRoute, Azure VPN Gateway, Azure Application Gateway, Azure Load Balancer y Azure Firewall.

2. Mejore la resistencia del almacenamiento de datos operativos. Los almacenes de datos operativos contienen datos valiosos que suelen usar varias cargas de trabajo, por lo que mejorar la disponibilidad de esos almacenes de datos puede ayudar a muchas cargas de trabajo.

   Para lograr resistencia de almacenamiento de datos operativos, céntrese en servicios como Azure SQL Database, Azure SQL Managed Instance, Azure Storage, Azure Data Lake Storage, Azure Cosmos DB, Servidor flexible de Azure PostgreSQL, Servidor flexible de Azure MySQL y Azure Cache for Redis.

3. Priorizar los servicios de computación. Estos servicios suelen ser fáciles de replicar y distribuir entre zonas porque no tienen estado.

   Los servicios de proceso incluyen Azure Virtual Machines, Azure Virtual Machine Scale Sets, Azure Kubernetes Service (AKS), Azure App Service, App Service Environment, Azure Functions, Azure Service Fabric y Azure Container Apps.

4. Revise los recursos críticos empresariales restantes que utilizan sus flujos críticos. Es posible que estos recursos no sean tan críticos como los recursos enumerados anteriormente, pero siguen desempeñando un papel en la funcionalidad de la aplicación y debe considerarlos para la resistencia de zona.

5. Revise el resto de los recursos operativos de la empresa. Tome decisiones informadas acerca de si hacerlos resilientes a zonas. Esta revisión incluye servicios que podrían no relacionarse directamente con las cargas de trabajo críticas, pero que siguen contribuyendo al rendimiento y la confiabilidad generales de las aplicaciones.

Paso 2: Evaluación de los enfoques de configuración de zona

Después de priorizar las cargas de trabajo y los servicios de Azure, identifique el enfoque necesario para habilitar la compatibilidad con zonas de disponibilidad para cada servicio y comprenda lo que debe hacer para configurar la resistencia de zona.

Cada guía del servicio de confiabilidad de Azure proporciona una sección que describe cómo habilitar la resistencia de zona para ese servicio. Esta sección le ayuda a comprender el esfuerzo necesario para que cada zona de servicio sea resistente para que pueda planear su estrategia en consecuencia. Para más información sobre un servicio específico, consulte Guías del servicio de confiabilidad de Azure.

Use la tabla de configuración de zona para comprender rápidamente los enfoques de los servicios comunes de Azure.

Paso 3: Probar la latencia

Al hacer que las cargas de trabajo sean resistentes a la zona, considere la posibilidad de tener en cuenta la latencia entre las zonas de disponibilidad. En ocasiones, algunos sistemas heredados no pueden tolerar la pequeña cantidad de latencia adicional que introduce el tráfico entre zonas, especialmente cuando se habilita la replicación sincrónica dentro del nivel de datos. Si sospecha que la latencia entre zonas podría afectar a la carga de trabajo, ejecute pruebas antes y después de habilitar la resistencia de zona. Para obtener más información sobre cómo la latencia entre zonas podría afectar a la aplicación y los enfoques para mitigar los problemas de latencia entre zonas, consulte Recursos zonales y resistencia de zona.

Enfoques de configuración de zona para los servicios de Azure

Cada servicio de Azure admite un tipo específico de compatibilidad con zonas de disponibilidad, que se basa en el uso previsto del servicio y la arquitectura interna. Si tiene un recurso que no está configurado para usar zonas de disponibilidad (o un recurso no zonal ), es posible que quiera volver a configurarlo con compatibilidad con la zona de disponibilidad. La guía de confiabilidad de ese servicio proporciona instrucciones o vínculos a instrucciones de configuración de zona de disponibilidad.

En esta sección se proporciona información general sobre los distintos tipos de enfoques de configuración de zona y qué enfoque admite cada servicio.

En la tabla de configuración de zona se muestra el enfoque de configuración de zona admitido para muchos servicios de Azure y contiene un vínculo a cada guía de confiabilidad de ese servicio. La guía de confiabilidad proporciona información sobre cómo configurar recursos de servicio no zonales para habilitar la compatibilidad con zonas de disponibilidad.

En la tabla siguiente se describe cada enfoque de configuración de zona, incluido el nivel de esfuerzo y el tiempo de inactividad necesarios para habilitar las zonas de disponibilidad.

Comprenda el costo de habilitar la compatibilidad con zonas de disponibilidad para un servicio. Para muchos servicios, la habilitación de zonas de disponibilidad no agrega costos. Pero algunos servicios requieren un nivel específico, un número específico de unidades de capacidad o ambos. Otros servicios cobran tarifas diferentes cuando se usan zonas de disponibilidad. En la tabla de la sección siguiente se muestra el impacto típico en los costos de cada servicio.

Servicios de Azure por enfoque de configuración de zona

En la tabla siguiente se resume la compatibilidad de la zona de disponibilidad para muchos servicios de Azure y se proporciona un enfoque, incluido el impacto en el costo, para habilitar la compatibilidad con zonas de disponibilidad para cada servicio.

Service	Puede ser redundante por zona	Puede ser zonal	Enfoque típico de configuración de zona	Impacto típico en los costos
Azure AI Search			Siempre resistente por zona	N/A
Azure API Management			Modificación	Nivel mínimo necesario
Azure App Configuration			Siempre resistente por zona	N/A
Azure App Service			Habilitación	Nivel mínimo y recuento de instancias necesarios
Azure App Service: App Service Environment			Habilitación	Número mínimo de instancias requerido
Puerta de enlace de aplicaciones de Azure			Siempre resistente por zona	N/A
Azure Backup			Reimplementación	Aumento moderado del costo
Azure Bastion			Reimplementación	Sin impacto en el costo
Azure Batch			Reimplementación	Sin impacto en el costo del mismo número de máquinas virtuales (VM)
Azure Blob Storage			Habilitación	Aumento moderado del costo
Azure Cache for Redis: Enterprise			Reimplementación	Sin impacto en el costo
Azure Cache for Redis: Estándar y Premium			Habilitación	Nivel mínimo necesario
Azure Container Apps			Reimplementación	Número mínimo de réplicas necesario
Azure Container Instances			Reimplementación	Sin impacto en el costo
Azure Container Registry			Siempre resistente por zona	N/A
Azure Cosmos DB para NoSQL			Modificación	Ninguno si usa escrituras de escalado automático o de varias regiones
Azure Data Factory			Siempre resistente por zona	N/A
Azure Data Lake Storage			Habilitación	Aumento moderado del costo
Azure Database for MySQL con la opción Servidor flexible			Reimplementación	Requiere la instancia principal y de alta disponibilidad (HA)
Azure Database for PostgreSQL: servidor flexible			Habilitación	Requiere la instancia principal y la de alta disponibilidad
Azure Databricks			Habilitación	Sin impacto en los costos para el mismo número de máquinas virtuales; aumento moderado del costo para el almacenamiento
Azure Disk Storage (discos administrados)			Habilitación	Aumento moderado del costo
SAN elástico de Azure			Reimplementación	Aumento moderado del costo
Azure Event Hubs: nivel dedicado			Siempre resistente por zona	Unidades de capacidad mínimas (RU) necesarias
Azure Event Hubs: todos los demás niveles			Siempre resistente por zona	N/A
Puerta de enlace de Azure ExpressRoute			Modificación	Depende del nivel
Archivos de Azure			Habilitación	Aumento moderado del costo
Azure Firewall			Modificación	Sin impacto en el costo
Funciones de Azure			Reimplementación	Nivel mínimo y recuento de instancias necesarios
Azure HDInsight			Reimplementación	Sin impacto en el costo para el mismo número de nodos
Azure IoT Hub			Siempre resistente por zona	N/A
Azure Key Vault			Siempre resistente por zona	N/A
Azure Kubernetes Service (AKS)			Reimplementación	Sin impacto en el costo
Equilibrador de carga de Azure			Modificación	Sin impacto en el costo
Azure Logic Apps: nivel de consumo			Siempre resistente por zona	N/A
Azure Logic Apps: nivel estándar			Reimplementación	Nivel mínimo y recuento de instancias necesarios
Azure Managed Grafana			Volver a implementar	Aumento moderado del costo
Azure Monitor: Log Analytics			Siempre resistente por zona
Azure NetApp Files			Reimplementación	Depende de la configuración de replicación
Azure Queue Storage			Habilitación	Aumento moderado del costo
Azure Service Bus			Siempre resistente por zona	N/A
Azure Service Fabric			Reimplementación	Sin impacto en el costo del mismo número de máquinas virtuales
Azure Site Recovery			Reimplementación	Sin impacto en el costo de Site Recovery, aumento moderado del costo para el almacenamiento de réplicas
Azure SQL Database: nivel crítico para la empresa			Habilitación	Sin impacto en el costo
Azure SQL Database: nivel de uso general			Habilitación	Aumento moderado del costo
Azure SQL Database: nivel hiperescala			Reimplementación	Número mínimo de réplicas necesario
Azure SQL Database: nivel Premium			Habilitación	Sin impacto en el costo
Instancia administrada de Azure SQL			Habilitación	Aumento moderado del costo
Azure Table Storage			Habilitación	Aumento moderado del costo
Conjuntos de escalado de máquinas virtuales de Azure			Reimplementación	Sin impacto en el costo del mismo número de máquinas virtuales
Máquinas virtuales de Azure			Reimplementación	Sin impacto en el costo del mismo número de máquinas virtuales
Azure Virtual Network			Siempre resistente por zona	N/A
Dirección IP pública			Siempre resistente por zona	N/A

Recursos relacionados

• Guías de confiabilidad de Azure
• Servicios de Azure compatibles con las zonas de disponibilidad
• Lista de regiones de Azure.