Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Muchas regiones de Azure proporcionan zonas de disponibilidad, que son grupos de centros de datos separados dentro de una región. Cada zona de disponibilidad tiene una infraestructura independiente de alimentación, refrigeración y red, de modo que, si una zona experimenta una interrupción, el resto de zonas poseen los servicios regionales, la capacidad y la alta disponibilidad necesarios para respaldarla.
Las zonas de disponibilidad suelen estar separadas por varios kilómetros y, por lo general, se encuentran a 100 kilómetros. Esta distancia significa que están lo suficientemente cerca como para tener conexiones de baja latencia a otras zonas de disponibilidad a través de una red de alto rendimiento. Sin embargo, están lo suficientemente separadas para reducir la probabilidad de que más de uno se vea afectado por interrupciones locales o el tiempo.
Las ubicaciones del centro de datos se seleccionan mediante criterios rigurosos de evaluación de riesgos de vulnerabilidades. Este proceso identifica todos los riesgos significativos específicos del centro de datos y tiene en cuenta los riesgos compartidos entre las zonas de disponibilidad.
Azure no cobra por la transferencia de datos entre zonas de disponibilidad en la misma región, tanto si usa direcciones IP privadas como públicas.
En el diagrama siguiente se muestran varias regiones de Azure de ejemplo. Las regiones 1 y 2 admiten zonas de disponibilidad, mientras que las regiones 3 y 4 no tienen zonas de disponibilidad.
Sugerencia
Para ver qué regiones admiten zonas de disponibilidad, consulte Lista de regiones de Azure.
Centros de datos y zonas de disponibilidad
Una zona de disponibilidad es una agrupación lógica de uno o varios centros de datos físicamente independientes dentro de una región. Cada zona de disponibilidad está integrada de una manera que si algo va mal en uno (como una interrupción de energía o un problema de red), los demás siguen funcionando. Un único centro de datos no ofrece este nivel de protección por sí solo.
Tipos de compatibilidad con zonas de disponibilidad
Los servicios de Azure pueden proporcionar tres tipos de compatibilidad de zona de disponibilidad para sus recursos: con redundancia de zona y zonal. Cada servicio puede admitir uno o varios de estos tipos. Al diseñar la estrategia de confiabilidad, asegúrese de comprender cómo cada servicio de la carga de trabajo admite zonas de disponibilidad haciendo referencia a la guía de confiabilidad de cada servicio.
Cada servicio puede implementar la compatibilidad con zonas de disponibilidad de maneras diferentes. En las siguientes secciones se describen dos tipos de servicios de soporte para zonas de disponibilidad:
Recursos con redundancia de zona: los recursos con redundancia de zona se replican o distribuyen entre varias zonas de disponibilidad por el servicio. Por ejemplo: los servicios de datos con redundancia de zona replican los datos en múltiples zonas para que un error en una zona no afecte a la alta disponibilidad de los datos. Algunos servicios son automáticamente con redundancia de zona en regiones admitidas, mientras que otros servicios requieren que configure el recurso para que tenga redundancia de zona. Para la mayoría de los servicios, Microsoft selecciona las zonas que emplean sus recursos. A veces, puede seleccionar el conjunto de zonas.
Gracias a las implementaciones con redundancia de zona, Microsoft administra la propagación de solicitudes y la replicación de datos entre zonas. Si se produce una interrupción en una zona de disponibilidad, Microsoft administra automáticamente la conmutación por error a otra zona.
Recursos zonales: un recurso zonal se implementa en una sola zona de disponibilidad auto-seleccionada.
Las implementaciones zonales no proporcionan automáticamente resistencia a interrupciones de zona de disponibilidad. Sin embargo, los recursos zonales están aislados de fallos en otras zonas. También pueden ayudarle a lograr requisitos de rendimiento o latencia inusualmente estrictos. Por ejemplo, para una carga de trabajo de chatty creada con máquinas virtuales, puede optar por implementar varias máquinas virtuales en la misma zona para reducir la latencia entre ellas.
Para que los recursos zonales sean resistentes a las interrupciones de zona de disponibilidad, debe diseñar una arquitectura con recursos independientes en varias zonas de disponibilidad dentro de la región. Microsoft no administra el proceso por usted. Si se produce una interrupción en una zona de disponibilidad, usted es responsable de la conmutación por error a otra zona.
Es posible que algunos servicios tengan requisitos adicionales para satisfacer la compatibilidad con las zonas de disponibilidad. Por ejemplo, solo pueden admitir zonas de disponibilidad para determinados niveles o SKU, o en un subconjunto de regiones de Azure. Las guías de confiabilidad contienen detalles de los requisitos que debe cumplir para habilitar zonas de disponibilidad en los servicios.
Cuando se usa la configuración de un recurso para que sea redundante de zona o si se usan varias instancias de un recurso zonal en diferentes zonas de disponibilidad, el recurso se considera resistente a la zona: es decir, es resistente a la interrupción de una sola zona de disponibilidad.
Para más información sobre cómo usar implementaciones zonales y mantener la resistencia de zona, consulte Recursos zonales y resistencia de zona.
Si un recurso no está configurado para usar zonas de disponibilidad, ya sea que la región que utiliza no admite zonas o debido a sus opciones de configuración, se denomina una implementación no zonal o regional. Azure puede colocar recursos no zonales en todas las zonas de la región. No decide qué recursos se asignan a qué zonas. Si alguna zona de disponibilidad de la región experimenta una interrupción, los recursos no zonales podrían estar en la zona afectada y podrían experimentar tiempo de inactividad.
Configuración de recursos para la compatibilidad con zonas de disponibilidad
Cada servicio tiene su propio método para configurar la compatibilidad con zonas de disponibilidad. Para información sobre cómo cada servicio admite zonas de disponibilidad y cómo configurar esa compatibilidad, consulte Guías de confiabilidad de Azure por servicio.
Zonas de disponibilidad físicas y lógicas
Cada centro de datos se asigna a una zona física. Las zonas físicas se asignan a zonas lógicas de la suscripción de Azure y es posible que diferentes suscripciones tengan un orden de asignación diferente. A las suscripciones de Azure se les asigna automáticamente su asignación en el momento en que se ha creado la suscripción. Debido a esto, la asignación de zona para una suscripción podría ser diferente para otras suscripciones.
Por ejemplo, la suscripción A puede tener la zona 1 física asignada a la zona 2 lógica, mientras que la suscripción B tiene la zona 1 física asignada a la zona 3 lógica:
Para comprender la asignación entre las zonas lógicas y físicas de la suscripción, use la API de Azure Resource Manager (ARM) de ubicaciones de lista. Puede usar la CLI de Azure o Azure PowerShell para recuperar la información de la API.
Para comparar la asignación de zona para soluciones resistentes que abarcan varias suscripciones, use la API de ARM dedicada checkZonePeers. Para usar la API checkZonePeers, debe habilitarse la característica "Microsoft.Resources/AvailabilityZonePeering". Para más información sobre cómo habilitar características, consulte Registro de características en la suscripción de Azure.
az rest --method get \
--uri '/subscriptions/{subscriptionId}/locations?api-version=2022-12-01' \
--query 'value[?availabilityZoneMappings != `null`].{displayName: displayName, name: name, availabilityZoneMappings: availabilityZoneMappings}'
Zonas de disponibilidad y actualizaciones de Azure
Para cada región, Microsoft tiene como objetivo implementar actualizaciones en los servicios de Azure en una sola zona de disponibilidad a la vez. Este enfoque reduce el impacto que podrían tener las actualizaciones en una carga de trabajo activa, ya que la carga de trabajo puede seguir ejecutándose en otras zonas mientras la actualización está en proceso. Para aprovechar las actualizaciones de zona secuenciadas, la carga de trabajo ya debe estar configurada para ejecutarse en varias zonas. Para más información sobre cómo Azure implementa las actualizaciones, consulte Avanzar en las prácticas de implementación seguras.
Latencia entre zonas
Dentro de cada región, las zonas de disponibilidad se conectan a través de una red de alto rendimiento. Microsoft se esfuerza por lograr una comunicación entre zonas con latencia de ida y vuelta de menos de 2 milisegundos aproximadamente. La baja latencia permite una comunicación de alto rendimiento dentro de una región y la replicación sincrónica de datos en varias zonas de disponibilidad.
Nota:
La latencia de destino hace referencia a la latencia de los vínculos de red. Según el protocolo de comunicación que use y los saltos de red necesarios para cualquier flujo de red específico, la latencia que observe puede ser diferente.
En la mayoría de las cargas de trabajo, puede distribuir componentes de la solución entre zonas de disponibilidad sin un efecto notable en el rendimiento. Si tiene una carga de trabajo con un alto grado de sensibilidad a la latencia entre zonas, es importante probar la latencia entre las zonas de disponibilidad seleccionadas con los protocolos y la configuración reales. Para reducir el tráfico entre zonas, es posible usar implementaciones zonales, pero de forma óptima, debe usar varias zonas de disponibilidad en el plan de estrategia de confiabilidad. Para más información sobre cómo usar implementaciones zonales y mantener la resistencia de zona, consulte Recursos zonales y resistencia de zona.
Guía de arquitectura de zona de disponibilidad
Para lograr cargas de trabajo confiables:
- Las cargas de trabajo de producción deberán configurarse para usar varias zonas de disponibilidad en caso de que la región en la que se encuentren admita las zonas de disponibilidad.
- En el caso de las cargas de trabajo críticas, debe tener en cuenta una solución que se tanto varias regiones como varias zonas.
Para obtener información más detallada sobre cómo usar regiones y zonas de disponibilidad en una arquitectura de solución, consulte Recomendaciones para usar zonas de disponibilidad y regiones.