¿Qué son las zonas de disponibilidad?
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.
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.
Para ver qué regiones admiten zonas de disponibilidad, consulte Regiones de Azure con compatibilidad con zonas de disponibilidad.
Tipos de compatibilidad con zonas de disponibilidad
Los servicios de Azure pueden proporcionar dos tipos de soporte de zona de disponibilidad: con redundancia de zona y zonal. Es posible que cada servicio admita uno o ambos 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.
Servicios con redundancia de zona: los recursos con redundancia de zona se replican o distribuyen entre varias zonas de disponibilidad automáticamente. 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. Para algunos servicios, es posible seleccionar el conjunto de zonas que usa el recurso, mientras que para otros servicios es Microsoft quien selecciona las 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.
Implementaciones zonales: un recurso zonal se implementa en una sola zona de disponibilidad seleccionada automáticamente. Este enfoque no proporciona una ventaja de resistencia, pero le ayuda a lograr requisitos de rendimiento o latencia más estrictos. Por ejemplo: las máquinas virtuales, los discos administrados y las direcciones IP estándar se pueden implementar de forma zonal en la misma zona.
Para mejorar la resistencia de los servicios zonales, se debe diseñar una arquitectura con distintos recursos en varias zonas de disponibilidad dentro de la región, pero 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.
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.
Algunos servicios no usan zonas de disponibilidad hasta que las configure para hacerlo. Si no configura explícitamente un servicio para que admita zonas de disponibilidad, la implementación se denomina no zonal o regional. Los recursos configurados de esta manera se pueden colocar en cualquier zona de disponibilidad de la región y se pueden mover. 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.
Importante
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.
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 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.
Nota:
Como se informó en el blog de actualizaciones de Azure, Azure no cobrará por la transferencia de datos entre zonas de disponibilidad, independientemente de si se usan direcciones IP públicas o privadas en los recursos de Azure. Con este cambio, Azure fomentará y apoyará aún más los esfuerzos de los clientes en la creación de aplicaciones y soluciones más resistentes y eficientes en Azure.
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 lo óptimo es usar varias zonas de disponibilidad en el plan de estrategia de confiabilidad.
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.