Recursos zonales y resistencia de zona

En Azure, un recurso zonal es un recurso que está anclado a una sola zona. Dado que un recurso zonal está en una sola zona de disponibilidad, no es resistente a la zona. Si la zona que contiene el recurso tiene un problema, es probable que el recurso experimente tiempo de inactividad.

Algunos servicios de Azure requieren o permiten implementar recursos zonales. Puede optar por implementar un recurso de forma zonal debido a consideraciones de latencia o requisitos de servicio específicos. Puede anclar recursos individuales o conjuntos de recursos relacionados a una sola zona.

En este artículo se describen los escenarios en los que puede optar por implementar recursos zonales en lugar de recursos con redundancia de zona. También resalta las consideraciones y responsabilidades necesarias para asegurarse de que la solución sigue siendo resistente a las interrupciones de zona.

Tipos de implementación de recursos

En Azure, solo algunos tipos de implementación proporcionan resistencia de zona. En la tabla siguiente se comparan tres tipos de implementación de recursos y se describen su resistencia de zona, distribución de zona, opciones de configuración y recomendaciones.

Para obtener más información sobre las zonas de disponibilidad y las implementaciones de recursos, consulte Zonas de disponibilidad.

Cargas de trabajo que combinan recursos con redundancia de zona y zonales

Muchas cargas de trabajo combinan recursos zonales y con redundancia de zona. Por ejemplo, la carga de trabajo podría incluir un conjunto de máquinas virtuales zonales para el nivel de base de datos, un servidor web con redundancia de zona hospedado en Azure App Service y un equilibrador de carga con redundancia de zona para enviar tráfico a las máquinas virtuales de base de datos.

Al combinar recursos zonales y con redundancia de zona en una tarea, tenga en cuenta cómo se comportan cada uno de los recursos y la solución global si una zona de disponibilidad tiene un problema. Normalmente, los servicios con redundancia de zona se recuperan automáticamente de interrupciones de zona con una pérdida de datos mínima o sin pérdida de datos, y Microsoft administra todo el proceso. En el caso de los recursos zonales, tiene la responsabilidad de configurar la conmutación por error automatizada o de realizar actividades de recuperación manual. Para obtener información sobre cómo se comporta cada servicio durante escenarios de zona baja, comprenda sus responsabilidades frente a las responsabilidades de Microsoft y supervise el estado de los servicios durante los eventos de zona abajo, consulte la guía de confiabilidad del servicio.

Cuándo usar una implementación zonal

Use recursos zonales solo cuando haya una necesidad clara. Entre los motivos típicos de una implementación de una sola zona se incluyen los casos en los que un recurso debe ser zonal, un servicio solo está disponible en una zona específica o una carga de trabajo es altamente sensible a la latencia entre zonas.

Recursos que requieren implementaciones zonales

Algunos servicios de Azure solo admiten implementaciones zonales y no proporcionan implementaciones con redundancia de zona.

Las máquinas virtuales son un recurso zonal. Puede usar conjuntos de escalado de máquinas virtuales para crear conjuntos de máquinas virtuales. Los conjuntos de escalado de máquinas virtuales se pueden ampliar por zonas, lo que significa que las máquinas virtuales del conjunto se distribuyen entre varias zonas. Los conjuntos de escalado son una buena manera de lograr la resiliencia de zona para muchas cargas de trabajo que se basan en máquinas virtuales.

Otro ejemplo es Azure NetApp Files, que admite la implementación de volúmenes en una sola zona. El servicio también le ofrece una forma de replicar entre varios volúmenes zonales.

Algunos servicios proporcionan opciones que solo están disponibles en zonas específicas. Por ejemplo, los tipos de máquina virtual específicos que usan unidades de procesamiento de gráficos avanzados (GPU) pueden estar disponibles solo en zonas específicas dentro de una región, lo que significa que no se pueden implementar en varias zonas. Para comprobar qué regiones y zonas admiten los tipos de máquina virtual que necesita, use los siguientes recursos:

• Para comprobar los tipos de máquina virtual disponibles en cada región, consulte Productos disponibles por región.

• Para comprobar los tamaños y tipos de máquina virtual admitidos dentro de cada zona de una región específica, consulte Comprobación de la disponibilidad de la SKU de máquina virtual.

Si el tipo de máquina virtual que necesita solo está disponible en una sola zona dentro de la región que usa, puede considerar una implementación zonal para esa máquina virtual y, a continuación, encontrar otras formas de hacer que la máquina virtual sea resistente a las interrupciones de zona. Pero debe seguir asegurándose de que las otras partes de la solución sean resistentes a la zona.

Para más información, consulte Servicios de Azure que admiten zonas de disponibilidad.

Latencia entre zonas

Si tiene una carga de trabajo que es inusualmente sensible a la latencia, puede usar recursos zonales en lugar de recursos con redundancia de zona, incluso si un servicio admite implementaciones con redundancia de zona.

Una red de baja latencia conecta zonas de disponibilidad, con latencia de ida y vuelta entre zonas normalmente debajo de dos milisegundos. Para la mayoría de las cargas de trabajo, la latencia entre zonas no es un problema. Las ventajas de resistencia de la propagación de recursos entre zonas de disponibilidad son más importantes que el impacto mínimo en el rendimiento del envío de tráfico entre zonas. Pero algunas cargas de trabajo son muy sensibles a la latencia entre zonas. Estas cargas de trabajo pueden incluir los siguientes escenarios:

• Aplicaciones locales heredadas: Algunas cargas de trabajo heredadas pueden contener aplicaciones diseñadas originalmente para un entorno local. Estas cargas de trabajo asumen que los componentes, como las bases de datos y otras aplicaciones y servicios, se colocan en el mismo host o en proximidad física cercana.

• Replicación sincrónica de gran escala: Las aplicaciones y bases de datos con estado realizan ocasionalmente un gran número de escrituras mediante la replicación sincrónica. La replicación sincrónica significa que los datos se escriben en varias réplicas antes de que la operación de escritura se considere completada. La distribución de réplicas entre zonas de disponibilidad mejora la resistencia, pero cuando se usa la replicación sincrónica, la latencia entre zonas puede aumentar la latencia de escritura de la carga de trabajo. Esta mayor latencia no suele ser significativa, pero debido a cómo se diseñan algunas aplicaciones, a veces puede resultar problemática a gran escala.

Si sospecha que la latencia entre zonas afecta a la carga de trabajo, pruebe su impacto en un entorno realista siguiendo estos pasos para la carga de trabajo específica:

1. Defina los requisitos de rendimiento aceptables. El tráfico entre zonas agrega una pequeña cantidad de latencia, pero es insignificante para la mayoría de las cargas de trabajo. Defina cómo debe ser un rendimiento aceptable para su carga de trabajo.

2. Ejecute una prueba de rendimiento dentro de una sola zona de disponibilidad. Establezca un conjunto de métricas de rendimiento de línea base.

   Importante

   Pruebe la carga de trabajo, incluidas las aplicaciones, los protocolos, la configuración y la región de Azure. Use una carga realista. Los puntos de referencia y las pruebas sintéticas no son suficientes porque no muestran cómo se comporta realmente la solución.

3. Habilite la replicación entre zonas. En función de los componentes que use, puede habilitar la redundancia de zona o mover réplicas entre zonas.

4. Vuelva a ejecutar pruebas de rendimiento. Recopile las mismas métricas recopiladas anteriormente.

5. Compare el impacto en el rendimiento con respecto a sus requisitos. Use sus requisitos y los datos de rendimiento para tomar una decisión informada sobre el equilibrio entre latencia y resistencia a las interrupciones de zona.

   Si la prueba demuestra que la latencia es inaceptablemente alta para la carga de trabajo, considere la posibilidad de realizar las siguientes acciones:

   • Intente usar otro conjunto de zonas. Puede haber una ligera variabilidad en la latencia entre diferentes zonas porque pueden tener diferentes distancias físicas entre sí.

     Sugerencia

     Si realiza pruebas entre suscripciones de Azure, revise la asignación de zona lógica a física para asegurarse de probar los conjuntos de zonas físicas que espera.

   • Si hay otra región de Azure que satisfaga sus necesidades generales para la residencia de datos y otros factores, pruebe a usar varias zonas de esa región.

   • Considere si puede rediseñar la aplicación para minimizar la comunicación entre zonas requerida. Por ejemplo, puede consolidar varias operaciones de base de datos pequeñas en una sola operación. Este enfoque puede reducir el impacto de la latencia en la carga de trabajo.

   Si ninguna de estas acciones ayuda, considere la posibilidad de ejecutar la carga de trabajo o componentes específicos dentro de una sola zona de disponibilidad mediante máquinas virtuales zonales y otros servicios de Azure compatibles. A continuación, usted se encarga de que los componentes zonales sean resistentes a las interrupciones de la zona. Revise el resto de este artículo para comprender sus responsabilidades y algunos enfoques que se deben tener en cuenta.

Sus responsabilidades para una implementación zonal

Un recurso zonal está en riesgo de tiempo de inactividad cuando su zona de disponibilidad experimenta una interrupción. Cuando implemente un recurso zonal, usted es responsable de hacer que su carga de trabajo sea resistente a fallos de nivel de zona.

Para que los recursos zonales sean resistentes a la zona, tenga en cuenta las siguientes responsabilidades:

• Implementación y configuración de varios recursos: Implemente recursos zonales independientes manualmente en diferentes zonas o regiones. Determine cómo mantener la configuración coherente en cada recurso. El uso de la infraestructura como código (IaC) es un procedimiento recomendado porque permite la implementación rápida de varios recursos idénticos.

• Enrutamiento y distribución del tráfico: Debe seleccionar un componente del equilibrador de carga, asegurarse de que es resistente a la zona y configurarlo para enviar tráfico entre los recursos de diferentes zonas. Normalmente, se configura la directiva de enrutamiento (como activa-activa o activa-pasiva), comprobaciones de estado automatizadas y procesos de conmutación por error. Para obtener más información, consulte Opciones de equilibrio de carga.

• Replicación o copia de seguridad de datos: En el caso de los recursos con estado, es responsable de proteger los datos que almacenan y asegurarse de que se mantienen de forma segura en varias zonas. Un enfoque común consiste en configurar la replicación en otra instancia de servicio en una zona de disponibilidad diferente. En algunas situaciones, puede confiar en copias de seguridad en su lugar. Pero las copias de seguridad requieren un tiempo de recuperación más largo durante un error de zona, lo que requiere que tenga un objetivo de tiempo de recuperación mayor (RTO). También producen más pérdida de datos, lo que requiere un objetivo de punto de recuperación (RPO) mayor.

• Implementación del proceso de detección y respuesta de errores de zona: Debe determinar cómo supervisar el estado de los recursos zonales, definir las condiciones que los marcan como incorrectos y desencadenar acciones de respuesta como restaurar operaciones en otra zona o región.

• Procesos de recuperación de zona: Una vez que la zona se recupere, usted es responsable de las acciones de recuperación necesarias, como volver a los recursos de la zona principal.

Enfoques comunes para la resiliencia de la implementación zonal

Para tomar decisiones fundamentadas sobre cómo lograr la resistencia de zona para los recursos zonales, tenga en cuenta los siguientes factores:

• Revise toda la carga de trabajo. Comprenda cómo se comporta cada componente durante los eventos de zona descendente, incluidos los recursos con redundancia de zona, zonales y no regionales. Use la guía de confiabilidad de cada servicio para obtener información sobre cómo funciona el servicio durante escenarios de zona baja y cómo supervisar el estado de los servicios para eventos de zona descendente.

• Comprenda la pérdida de datos permitida durante un error de zona. El RPO especifica la cantidad de pérdida de datos que puede aceptar.

  Muchos recursos con redundancia de zona de Azure proporcionan un RPO de cero para errores de zona, lo que significa que no se produce ninguna pérdida de datos. Normalmente logran este RPO mediante la replicación sincrónica de todos los cambios entre zonas.

  Al planificar una implementación zonal, debe asegurarse de que puede satisfacer los requisitos de RPO de su carga de trabajo en caso de fallo de una zona.

• Comprenda el tiempo de inactividad permitido durante un fallo de zona. El RTO especifica cuánto tiempo de inactividad puede aceptar usted.

  Los recursos con redundancia de zona de Azure suelen proporcionar un RTO muy bajo para los errores de zona y normalmente requieren solo unos segundos de tiempo de inactividad.

  Al planificar una implementación zonal, debe asegurarse de que puede satisfacer los requisitos de RTO de su carga de trabajo. Si tiene un RTO bajo, es posible que tenga que confiar en procesos de detección y recuperación automatizados. Un RTO mayor proporciona más flexibilidad para los procesos de respuesta.

• Comprenda el costo. Normalmente, los recursos zonales se facturan individualmente, por lo que la implementación de varios recursos zonales puede aumentar el costo de los recursos.

Diseño de una implementación zonal para la resiliencia

Al diseñar la implementación zonal para lograr resistencia, tenga en cuenta si usa zonas de disponibilidad para lograr alta disponibilidad o recuperación ante desastres. La distinción entre estos conceptos se basa en los requisitos de RTO y RPO.

Si tiene un requisito de RTO bajo y RPO bajo, debe tratar las zonas de disponibilidad como una construcción de alta disponibilidad . Pero si las cifras de RTO y RPO son más elevadas, podría optar por tratar las zonas de disponibilidad como un marco de recuperación ante desastres. Para obtener más información, consulte Continuidad empresarial, alta disponibilidad y recuperación ante desastres. El nivel de carga de trabajo puede ayudarle a determinar los requisitos y las acciones necesarias.

Diseño para lograr alta disponibilidad

Considere la posibilidad de implementar su propia arquitectura de alta disponibilidad en varias zonas. Una arquitectura de alta disponibilidad requiere la replicación de datos automatizada y frecuente entre los componentes que se implementan en varias zonas y la conmutación automática por fallo entre ellos si se produce un error de zona.

Algunas aplicaciones que se implementan en máquinas virtuales zonales proporcionan compatibilidad integrada con alta disponibilidad, por ejemplo, teniendo en cuenta la réplica. Por ejemplo, si usa SQL Server en máquinas virtuales de Azure, los grupos de disponibilidad proporcionan funcionalidades de enrutamiento de tráfico y conmutación por error. Puede seleccionar si desea usar la replicación sincrónica o asincrónica. Para más información, consulte Continuidad empresarial, alta disponibilidad y recuperación ante desastres para SQL Server en máquinas virtuales de Azure.

Diseño para la recuperación ante desastres

La recuperación ante desastres difiere de la alta disponibilidad, ya que un mayor tiempo de inactividad y pérdida de datos son aceptables en un escenario de desastre. RTO y RPO se miden normalmente en horas o más.

Un plan de recuperación ante desastres le ayuda a prepararse para diferentes escenarios y define cómo responder mediante una combinación de procesos automatizados y manuales.

Los siguientes enfoques de recuperación ante desastres pueden ayudar al planear una implementación zonal:

• Recuperación ante desastres de zona a zona de Azure Site Recovery: Este enfoque es útil cuando se necesita la replicación asincrónica de nivel de disco entre máquinas virtuales en distintas zonas. Para más información, consulte Habilitación de la recuperación ante desastres de máquinas virtuales de Azure entre zonas de disponibilidad.

• Recuperación ante desastres de la región a región de Site Recovery: Site Recovery admite la recuperación ante desastres de región a región y se basa en la replicación asincrónica. Este enfoque le permite conmutar por error a una zona de una región diferente de Azure en lugar de a otra zona de la región primaria. Para más información, consulte Replicación de máquinas virtuales de Azure en otra región de Azure.

• Recuperación ante desastres basada en copia de seguridad: Si la solución puede tolerar un RTO elevado y un RPO elevado, considere la posibilidad de usar copias de seguridad como una estrategia de recuperación ante desastres. Si la zona experimenta una interrupción, puede restaurar las copias de seguridad en otra zona o región. También debe considerar si crea previamente los demás recursos de Azure en su solución o si los crea durante el proceso de conmutación por error.

  En una arquitectura zonal, a menudo es responsable de almacenar y replicar esas copias de seguridad.

  Azure Backup es un servicio de copia de seguridad administrado ampliamente usado. Admite copias de seguridad con redundancia de zona y copias de seguridad con replicación geográfica entre regiones de Azure emparejadas. Algunas aplicaciones, como SQL Server en máquinas virtuales de Azure, también incluyen características integradas de copia de seguridad específicas de la aplicación.

Paso siguiente

• Recomendaciones para usar zonas de disponibilidad y regiones en Azure Well-Architected Framework