Recomendaciones para usar zonas de disponibilidad y regiones

Se aplica a esta recomendación de lista de comprobación de confiabilidad de Azure Well-Architected Framework:

RE:05	Agregue redundancia en distintos niveles, especialmente para flujos críticos. Aplique redundancia al proceso, los datos, la red y otros niveles de infraestructura de acuerdo con los objetivos de confiabilidad identificados.

Guías relacionadas:Redundancia de diseño | multirregional de alta disponibilidad

En esta guía se describen las recomendaciones para determinar cuándo implementar cargas de trabajo en zonas de disponibilidad o regiones.

Al diseñar una solución para Azure, debe decidir si implementará en varias zonas de disponibilidad de una región o implementará en varias regiones. Esta decisión afecta a la confiabilidad, el costo y el rendimiento de la solución y la capacidad de su equipo para operar la solución. En esta guía se proporciona información sobre los requisitos empresariales clave que influyen en la decisión, los enfoques que puede tener en cuenta, los inconvenientes implicados en cada enfoque y el efecto de cada enfoque en los pilares básicos de Azure Well-Architected Framework.

La decisión sobre las mejores regiones de Azure que se van a usar para la solución es una opción crítica. En la guía Seleccionar regiones de Azure se describe cómo seleccionar y operar en varias regiones geográficas. La elección de cómo se usan regiones y zonas de disponibilidad dentro de la solución también afecta a varios de los pilares de Well-Architected Framework:

• Confiabilidad: la elección del enfoque de implementación puede ayudarle a mitigar varios tipos de riesgos. En general, al distribuir la carga de trabajo en un área más distribuida geográficamente, puede lograr una mayor resistencia.
• Optimización de costos: algunos enfoques arquitectónicos requieren la implementación de más recursos que otros, lo que puede aumentar los costos de los recursos. Otros enfoques implican el envío de datos entre regiones o zonas de disponibilidad separadas geográficamente, lo que podría incurrir en cargos de tráfico de red. También es importante tener en cuenta el costo continuo de administrar los recursos, lo que suele ser mayor cuando tiene requisitos empresariales completos.
• Eficiencia del rendimiento: las zonas de disponibilidad se conectan juntas a través de un vínculo de red de baja latencia y ancho de banda alto, lo que es suficiente para que la mayoría de las cargas de trabajo permitan la replicación sincrónica y la comunicación entre las zonas. Sin embargo, si la carga de trabajo se ha probado y es sensible a la latencia de red entre zonas, es posible que tenga que considerar la posibilidad de buscar físicamente los componentes de la carga de trabajo cerca para minimizar la latencia cuando se comunican.
• Excelencia operativa: una arquitectura compleja requiere más esfuerzo para implementar, configurar y administrar. Además, para una solución de alta disponibilidad, es posible que tenga que planear cómo conmutar por error a un conjunto secundario de recursos. La conmutación por error, la conmutación por recuperación y la redirección transparente del tráfico pueden ser complejas, especialmente cuando se requieren pasos manuales. Se recomienda automatizar los procesos de implementación y administración. Para obtener más información, consulte las guías del pilar de excelencia operativa, incluidas las guías de infraestructura de OE:05 como código, automatización de tareas de OE:09, diseño de automatización de OE:10 y procedimientos de implementación de OE:11.

Sin embargo, diseña la solución, se aplica el pilar seguridad. Normalmente, las decisiones sobre si usa zonas y regiones de disponibilidad y cómo no cambian la posición de seguridad. Azure aplica el mismo rigor de seguridad a todas las regiones y zonas de disponibilidad.

Sugerencia

Para muchas cargas de trabajo de producción, una implementación con redundancia de zona proporciona el mejor equilibrio entre ventajas y desventajas. Puede ampliar este enfoque con la copia de seguridad de datos asincrónica en otra región. Si no está seguro de qué enfoque seleccionar, comience con este tipo de implementación.

Tenga en cuenta otros enfoques de carga de trabajo cuando necesite las ventajas específicas que proporcionan esos enfoques, pero tenga en cuenta los inconvenientes implicados.

Definiciones

Término	Definición
Activo-activo	Arquitectura en la que varias instancias de una solución procesan activamente las solicitudes al mismo tiempo.
Activo-pasivo	Una arquitectura en la que una instancia de una solución se designa como el tráfico principal y procesa, y se implementan una o varias instancias secundarias para atender el tráfico si el principal no está disponible.
Replicación asincrónica	Un enfoque de replicación de datos en el que los datos se escriben y se confirman en una ubicación. Más adelante, los cambios se replican en otra ubicación.
Zona de disponibilidad	Un grupo separado de centros de datos dentro de una región. Cada zona de disponibilidad es independiente de las demás, con su propia infraestructura de alimentación, refrigeración y red. Muchas regiones admiten zonas de disponibilidad.
Centro de datos	Una instalación que contiene servidores, equipos de red y otro hardware para admitir recursos y cargas de trabajo de Azure.
Implementación con redundancia local	Modelo de implementación en el que se implementa un recurso en una sola región sin referencia a una zona de disponibilidad. En una región que admita zonas de disponibilidad, es posible que el recurso se implemente en cualquiera de las zonas de disponibilidad de la región.
Implementación en varias regiones	Un modelo de implementación en el que los recursos se implementan en varias regiones de Azure.
Regiones emparejadas	Una relación entre dos regiones de Azure. Algunas regiones de Azure están conectadas a otra región definida para habilitar tipos específicos de soluciones de varias regiones. Las regiones de Azure más recientes no están emparejadas.
Region	Perímetro geográfico que contiene un conjunto de centros de datos.
Arquitectura de regiones	Configuración específica de la región de Azure, incluido el número de zonas de disponibilidad y si la región está emparejada con otra región.
Replicación sincrónica	Un enfoque de replicación de datos en el que los datos se escriben y confirman en varias ubicaciones. Cada ubicación debe confirmar la finalización de la operación de escritura antes de que se considere completada la operación de escritura general.
Implementación zonal (anclada)	Un modelo de implementación en el que se implementa un recurso en una zona de disponibilidad específica.
Implementación con redundancia de zona	Modelo de implementación en el que se implementa un recurso en varias zonas de disponibilidad. Microsoft administra la sincronización de datos, la distribución del tráfico y la conmutación por error si una zona experimenta una interrupción.

Estrategias de diseño principales

Azure tiene una gran superficie global. Una región de Azure es un perímetro geográfico que contiene un conjunto de centros de datos. Debe tener un conocimiento completo de las regiones de Azure y las zonas de disponibilidad.

Las regiones de Azure tienen una variedad de configuraciones, que también se denominan arquitecturas de región.

Muchas regiones de Azure proporcionan zonas de disponibilidad, que son grupos separados de centros de datos. Dentro de una región, las zonas de disponibilidad están lo suficientemente cerca como para tener conexiones de baja latencia a otras zonas de disponibilidad, pero están lo suficientemente separadas para reducir la probabilidad de que más de una se vea afectada por interrupciones locales o el tiempo. Las zonas de disponibilidad tienen una infraestructura de alimentación, refrigeración y redes independiente. Están diseñados para que, si una zona experimenta una interrupción, los servicios regionales, la capacidad y la alta disponibilidad son compatibles con las zonas restantes.

En el diagrama siguiente se muestran varias regiones de Azure de ejemplo. Las regiones 1 y 2 admiten zonas de disponibilidad.

Si implementa en una región de Azure que contiene zonas de disponibilidad, puede usar varias zonas de disponibilidad juntas. Mediante el uso de varias zonas de disponibilidad, puede conservar copias independientes de la aplicación y los datos dentro de centros de datos físicos independientes en un área metropolitana grande.

Hay dos maneras de usar zonas de disponibilidad en una solución:

• Los recursos zonales se anclan a una zona de disponibilidad específica. Puede combinar varias implementaciones zonales en diferentes zonas para satisfacer los requisitos de alta confiabilidad. Es responsable de administrar la replicación de datos y distribuir solicitudes entre zonas. Si se produce una interrupción en una sola zona de disponibilidad, es responsable de la conmutación por error a otra zona de disponibilidad.
• Los recursos con redundancia de zona se distribuyen entre varias zonas de disponibilidad. Microsoft administra la propagación de solicitudes entre zonas y la replicación de datos entre zonas. Si se produce una interrupción en una sola zona de disponibilidad, Microsoft administra automáticamente la conmutación por error.

Los servicios de Azure admiten uno o ambos enfoques. Los servicios de plataforma como servicio (PaaS) suelen admitir implementaciones con redundancia de zona. Los servicios de infraestructura como servicio (IaaS) suelen admitir implementaciones zonales. Para más información sobre cómo funcionan los servicios de Azure con zonas de disponibilidad, consulte Servicios de Azure con compatibilidad con zonas de disponibilidad.

Cuando Microsoft implementa actualizaciones en los servicios, intentamos usar enfoques que sean los menos perjudiciales para usted. Por ejemplo, pretendemos implementar actualizaciones en una sola zona de disponibilidad a la vez. Este enfoque puede reducir el impacto que pueden 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. Sin embargo, es responsabilidad del equipo de carga de trabajo asegurarse de que su carga de trabajo sigue funcionando durante las actualizaciones de la plataforma. Por ejemplo, cuando se usan conjuntos de escalado de máquinas virtuales con el modo de orquestación flexible o la mayoría de los servicios PaaS de Azure, Azure coloca los recursos de forma inteligente para reducir el impacto de las actualizaciones de la plataforma. Además, puede considerar la posibilidad de sobreaprovisionar ( implementar más instancias de un recurso) para que algunas instancias permanezcan disponibles mientras se actualizan otras instancias. Para obtener más información sobre cómo Azure implementa las actualizaciones, consulte Procedimientos de implementación seguros avanzados.

Muchas regiones también tienen una región emparejada. Las regiones emparejadas admiten determinados tipos de enfoques de implementación de varias regiones. Algunas regiones más recientes tienen varias zonas de disponibilidad y no tienen una región emparejada. Todavía puede implementar soluciones de varias regiones en estas regiones, pero los enfoques que use pueden ser diferentes.

Para más información sobre cómo Azure usa regiones y zonas de disponibilidad, consulte ¿Qué son las regiones de Azure y las zonas de disponibilidad?

Descripción de las responsabilidades compartidas

El principio de responsabilidad compartida describe cómo se dividen las responsabilidades entre el proveedor de nube (Microsoft) y usted. En función del tipo de servicios que use, puede asumir más o menos responsabilidad por el funcionamiento del servicio.

Microsoft proporciona zonas de disponibilidad y regiones para ofrecer flexibilidad en el diseño de la solución para satisfacer sus requisitos. Cuando se usan servicios administrados, Microsoft asume más responsabilidades de administración para los recursos, lo que incluso puede incluir la replicación de datos, la conmutación por error, la conmutación por recuperación y otras tareas relacionadas con el funcionamiento de un sistema distribuido.

Su propio código necesita procedimientos recomendados y patrones de diseño para controlar los errores correctamente. Estas prácticas son aún más importantes durante las operaciones de conmutación por error, como las que se producen cuando se produce una conmutación por error de zona de disponibilidad o región, ya que la conmutación por error entre zonas o regiones normalmente requiere que la aplicación vuelva a intentar las conexiones a los servicios.

Identificación de los requisitos clave de la empresa y de la carga de trabajo

Para tomar una decisión informada sobre cómo usar regiones y zonas de disponibilidad en la solución, debe comprender sus requisitos. Estos requisitos deben basarse en discusiones entre diseñadores de soluciones y partes interesadas de la empresa.

Tolerancia al riesgo

Las diferentes organizaciones tienen diferentes grados de tolerancia al riesgo. Incluso dentro de una organización, la tolerancia al riesgo suele ser diferente para cada carga de trabajo. La mayoría de las cargas de trabajo no necesitan una alta disponibilidad. Sin embargo, algunas cargas de trabajo son tan importantes que incluso vale la pena mitigar los riesgos que es poco probable que se produzcan, como desastres naturales importantes que afectan a una amplia área geográfica.

En esta tabla se enumeran algunos de los riesgos comunes que debe tener en cuenta en un entorno de nube:

Riesgo	Ejemplos	Probabilidad
Interrupción del hardware	Problema con el disco duro o el equipo de red. Reinicios del host.	Alta. Cualquier estrategia de resistencia debe tener en cuenta estos riesgos.
Interrupción del centro de datos	Error de alimentación, refrigeración o red en todo un centro de datos. Desastre natural en una parte de un área metropolitana.	Media
Interrupción de la región	Desastres naturales importantes que afectan a una amplia zona geográfica. Problema de red o servicio que hace que uno o varios servicios de Azure no estén disponibles en toda una región.	Bajo

Sería ideal mitigar todos los riesgos posibles para cada carga de trabajo, pero no es práctico ni rentable hacerlo. Es importante tener una discusión abierta con las partes interesadas de la empresa para que pueda tomar decisiones informadas sobre los riesgos que debe mitigar.

Sugerencia

Independientemente de los objetivos de confiabilidad, todas las cargas de trabajo deben tener alguna mitigación para la recuperación ante desastres. Si la carga de trabajo exige objetivos de alta confiabilidad, las estrategias de mitigación deben ser completas y debe reducir el riesgo de eventos incluso de baja probabilidad. En el caso de otras cargas de trabajo, tome una decisión informada sobre qué riesgos está preparado para aceptar y cuál debe mitigar.

Requisitos de resistencia

Es importante comprender los requisitos de resistencia de la carga de trabajo, incluido el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Estos objetivos le ayudan a decidir qué enfoques se deben descartar. Si no tiene requisitos claros, no puede tomar una decisión informada sobre qué enfoque seguir. Para obtener más información, consulte Requisitos funcionales y no funcionales de destino.

Objetivos de nivel de servicio

Debe comprender el objetivo de nivel de servicio (SLO) de tiempo de actividad esperado de la solución. Por ejemplo, es posible que tenga un requisito empresarial que la solución necesite para satisfacer el tiempo de actividad del 99,9 %.

Azure proporciona acuerdos de nivel de servicio (SLA) para cada servicio. Un Acuerdo de Nivel de Servicio indica el nivel de tiempo de actividad que debe esperar del servicio y las condiciones que debe cumplir para lograr ese Acuerdo de Nivel de Servicio esperado. Sin embargo, recuerde que la forma en que un Acuerdo de Nivel de Servicio de Azure indica la disponibilidad del servicio no siempre coincide con la forma en que considera el estado de la carga de trabajo.

Las decisiones de arquitectura afectan al SLO compuesto de la solución. En general, cuanto mayor sea la redundancia que cree en la solución, más alto será el SLO. Muchos servicios de Azure proporcionan acuerdos de nivel de servicio más altos al implementar servicios en una configuración con redundancia de zona o de varias regiones. Revise los Acuerdos de Nivel de Servicio para cada uno de los servicios de Azure que use para asegurarse de que comprende cómo maximizar la resistencia y el Acuerdo de Nivel de Servicio del servicio.

Residencia de datos

Algunas organizaciones aplican restricciones a las ubicaciones físicas en las que se pueden almacenar y procesar sus datos. A veces, estos requisitos se basan en estándares legales o normativos. En otras situaciones, una organización podría decidir adoptar una directiva de residencia de datos para evitar problemas de los clientes. Si tiene requisitos estrictos de residencia de datos, es posible que tenga que usar una implementación de una sola región o usar un subconjunto de regiones y servicios de Azure.

Nota

Evite realizar suposiciones infundadas sobre los requisitos de residencia de datos. Si necesita cumplir con estándares normativos específicos, compruebe lo que realmente especifiquen esos estándares.

Ubicación del usuario

Al comprender dónde se encuentran los usuarios, puede tomar una decisión informada sobre cómo optimizar la latencia y la confiabilidad de sus necesidades. Azure proporciona muchas opciones para admitir una base de usuarios dispersa geográficamente.

Si los usuarios se concentran en un área, una implementación de una sola región puede simplificar los requisitos operativos y reducir los costos. Sin embargo, debe tener en cuenta si una implementación de una sola región cumple los requisitos de confiabilidad. En el caso de las aplicaciones críticas, debe seguir usando una implementación de varias regiones incluso si los usuarios están colocados.

Si los usuarios están dispersos geográficamente, es posible que tenga sentido implementar la carga de trabajo en varias regiones. Los servicios de Azure proporcionan diferentes funcionalidades para admitir una implementación de varias regiones y puede usar la superficie global de Azure para mejorar la experiencia del usuario y acercar las aplicaciones a la base de usuarios. Puede usar el patrón Stamps de implementación o el patrón Geodes, o replicar los recursos en varias regiones.

Incluso si los usuarios están en diferentes áreas geográficas, tenga en cuenta si necesita una implementación de varias regiones. Tenga en cuenta si puede lograr sus requisitos dentro de una sola región mediante la aceleración global del tráfico, como la aceleración proporcionada por Azure Front Door.

Presupuesto

Si trabaja con un presupuesto restringido, es importante tener en cuenta los costos implicados en la implementación de componentes de carga de trabajo redundantes. Estos costos pueden incluir cargos de recursos adicionales, costos de red y costos operativos de administración de más recursos y un entorno más complejo.

Complejidad

Se recomienda evitar la complejidad innecesaria en la arquitectura de la solución. Cuanto más complejidad introduzca, más difícil será tomar decisiones sobre la arquitectura. Las arquitecturas complejas son más difíciles de operar, más difíciles de proteger y, a menudo, menos rendimiento. Siga el principio de simplicidad.

Facilitación de Azure

Al proporcionar regiones y zonas de disponibilidad, Azure le permite seleccionar un enfoque de implementación que se adapte a sus necesidades. Hay muchos enfoques entre los que puede elegir, cada uno de los cuales proporciona ventajas y incurre en costos.

Para ilustrar los enfoques de implementación que puede usar, considere un escenario de ejemplo. Supongamos que está pensando en implementar una nueva solución que incluya una aplicación que escriba datos en algún tipo de almacenamiento:

Este ejemplo no es específico de ningún servicio concreto de Azure. Está pensado para proporcionar un ejemplo sencillo para ilustrar conceptos fundamentales.

Hay varias maneras de implementar esta solución. Cada enfoque proporciona un conjunto diferente de ventajas y conlleva costos diferentes. En un nivel alto, puede considerar una implementación con redundancia local, zonal (anclada),con redundancia de zona o con varias regiones . En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Redundancia local	Zonal (anclado)	Redundancia de zona	Varias regiones
Confiabilidad	Baja confiabilidad	Depende del enfoque	Alta o muy alta confiabilidad	Alta o muy alta confiabilidad
Optimización de costos	Bajo costo	Depende del enfoque	Costo moderado	Costo elevado
Eficiencia del rendimiento	Rendimiento aceptable (para la mayoría de las cargas de trabajo)	Alto rendimiento	Rendimiento aceptable (para la mayoría de las cargas de trabajo)	Depende del enfoque
Excelencia operativa	Requisitos operativos bajos	Requisitos operativos elevados	Requisitos operativos bajos	Requisitos operativos elevados

En esta tabla se resumen algunos de los enfoques que puede usar y cómo afectan a la arquitectura:

Preocupación arquitectónica	Redundancia local	Zonal (anclado)	Redundancia de zona	Varias regiones
Cumplimiento de la residencia de datos	Alto	Alto	Alto	Depende de la región
Disponibilidad regional	Todas las regiones	Regiones con zonas de disponibilidad	Regiones con zonas de disponibilidad	Depende de la región

En el resto de este artículo se describe cada uno de los enfoques enumerados en la tabla anterior. La lista de enfoques no es exhaustiva. Puede decidir combinar varios enfoques o usar diferentes enfoques en distintas partes de la solución.

Enfoque de implementación 1: implementaciones con redundancia local

Si no especifica varias zonas de disponibilidad o regiones al implementar los recursos, Azure no garantiza si los recursos se implementan en un único centro de datos o se dividen en varios centros de datos de la región. En algunas situaciones, Azure también podría mover el recurso entre zonas de disponibilidad.

La mayoría de los recursos de Azure están altamente disponibles de forma predeterminada, con acuerdos de nivel de servicio altos y redundancia integrada dentro de un centro de datos administrado por la plataforma. Sin embargo, desde una perspectiva de confiabilidad, si alguna parte de la región experimenta una interrupción, existe la posibilidad de que la carga de trabajo se vea afectada. Si es así, es posible que la solución no esté disponible o que se pierdan los datos.

En el caso de cargas de trabajo altamente sensibles a la latencia, este enfoque también podría dar lugar a un menor rendimiento. Es posible que los componentes de carga de trabajo no se coloquen en el mismo centro de datos, por lo que es posible que observe cierta latencia para el tráfico dentro de la región. Azure también puede mover de forma transparente las instancias de servicio entre zonas de disponibilidad, lo que podría afectar ligeramente al rendimiento. Sin embargo, esto no es un problema para la mayoría de las cargas de trabajo.

En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Impacto
Confiabilidad	Baja confiabilidad. Los servicios están sujetos a interrupciones si se produce un error en un centro de datos. Sin embargo, puede compilar una aplicación para que sea resistente a otros tipos de errores.
Optimización de costos	Costo más bajo. Solo tiene que tener una sola instancia de cada recurso y no incurre en costos de ancho de banda entre zonas o entre regiones.
Eficiencia del rendimiento	Para la mayoría de las cargas de trabajo:rendimiento aceptable. Es probable que este enfoque proporcione un rendimiento satisfactorio. Para cargas de trabajo altamente sensibles a la latencia:bajo rendimiento. No se garantiza que los componentes se encuentren en la misma zona de disponibilidad, por lo que es posible que vea un menor rendimiento para componentes altamente sensibles a la latencia.
Excelencia operativa	Alta eficiencia operativa. Solo tiene que implementar y administrar una sola instancia de cada recurso.

En esta tabla se resumen algunos de los problemas desde una perspectiva arquitectónica:

Preocupación arquitectónica	Impacto
Cumplimiento de la residencia de datos	Alta. Al implementar una solución que use este enfoque, los datos se almacenan en la región de Azure que seleccione.
Disponibilidad regional	Alta. Este enfoque se puede usar en cualquier región de Azure.

Implementaciones con redundancia local con copia de seguridad entre regiones

Puede ampliar una implementación con redundancia local realizando copias de seguridad periódicas de la infraestructura y los datos en una región secundaria. Este enfoque agrega una capa adicional de protección para mitigar una interrupción en la región primaria. Este es su aspecto:

Al implementar este enfoque, debe tener en cuenta cuidadosamente el RTO y el RPO:

• Tiempo de recuperación: si se produce una interrupción regional, es posible que tenga que recompilar la solución en otra región de Azure, lo que afecta al tiempo de recuperación. Considere la posibilidad de crear la solución mediante un enfoque de infraestructura como código (IaC) para que pueda volver a implementar rápidamente en otra región si se produce un desastre importante. Asegúrese de que las herramientas y los procesos de implementación sean tan resistentes como las aplicaciones para poder usarlas para volver a implementar la solución, incluso si se produce una interrupción. Planee y ensaye los pasos necesarios para restaurar la solución a un estado de trabajo.
• Punto de recuperación: la frecuencia de copia de seguridad determina la cantidad de pérdida de datos que puede experimentar (el punto de recuperación). Normalmente, puede controlar la frecuencia de las copias de seguridad para que pueda cumplir el RPO.

En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Impacto
Confiabilidad	Confiabilidad moderada. Los servicios están sujetos a interrupciones si se produce un error en un centro de datos. Se realiza una copia de seguridad de los datos de forma asincrónica en una región separada geográficamente, lo que reduce el efecto de una interrupción completa de la región al minimizar la pérdida de datos. En una interrupción completa de la región, puede restaurar manualmente las operaciones en otra región. Sin embargo, los procesos de recuperación pueden ser complejos y pueden tardar tiempo en restaurarse manualmente en la otra región.
Optimización de costos	Bajo costo. Normalmente, agregar una copia de seguridad a otra región solo cuesta ligeramente más que implementar un recurso con redundancia local.
Eficiencia del rendimiento	Para la mayoría de las cargas de trabajo:rendimiento aceptable. Es probable que este enfoque proporcione un rendimiento satisfactorio. Para cargas de trabajo altamente sensibles a la latencia:bajo rendimiento. No se garantiza que los componentes se encuentren en la misma zona de disponibilidad, por lo que es posible que vea un rendimiento inferior para componentes altamente sensibles a la latencia.
Excelencia operativa	Durante cualquier interrupción dentro de una región:baja eficiencia operativa. La conmutación por error es su responsabilidad y puede requerir operaciones manuales y reimplementaciones.

En esta tabla se resumen algunos de los problemas desde una perspectiva arquitectónica:

Preocupación arquitectónica	Impacto
Cumplimiento de la residencia de datos	Depende de la selección de región. Los datos se almacenan principalmente en la región de Azure que especifique. Sin embargo, debe seleccionar otra región para almacenar las copias de seguridad, por lo que es importante seleccionar una región compatible con los requisitos de residencia de datos.
Disponibilidad regional	Alta. Puede usar este enfoque en cualquier región de Azure.

Enfoque de implementación 2: implementaciones zonales (ancladas)

En una implementación zonal , especifique que los recursos se deben implementar en una zona de disponibilidad específica. Este enfoque se denomina a veces una implementación anclada a zona .

Un enfoque zonal reduce la latencia entre los componentes. Sin embargo, por sí mismo, no aumenta la resistencia de la solución. Para aumentar la resistencia, debe implementar varias instancias de los componentes en varias zonas de disponibilidad y decidir cómo enrutar el tráfico entre cada instancia. En este ejemplo se muestra un enfoque de enrutamiento de tráfico activo-pasivo :

En el ejemplo anterior, un equilibrador de carga se implementa en varias zonas de disponibilidad. Es importante tener en cuenta cómo enrutar el tráfico entre instancias de diferentes zonas de disponibilidad, ya que una interrupción de zona también puede afectar a los recursos de red implementados en esa zona. También puede considerar el uso de un equilibrador de carga global, como Azure Front Door o Azure Traffic Manager, que no se implementa en ninguna región.

Cuando se usa un modelo de implementación zonal, se toman muchas responsabilidades:

• Debe implementar recursos en cada zona de disponibilidad y configurar y administrar esos recursos individualmente.
• Debe decidir cómo y cuándo replicar datos entre las zonas de disponibilidad y, después, configurar y administrar la replicación.
• Es responsable de distribuir las solicitudes a los recursos correctos mediante, por ejemplo, un equilibrador de carga. Debe asegurarse de que el equilibrador de carga cumple los requisitos de resistencia. También debe decidir si se debe usar un modelo de distribución de solicitudes activo-pasivo o activo-activo.
• Si una zona de disponibilidad experimenta una interrupción, debe controlar la conmutación por error para enviar tráfico a los recursos de otra zona de disponibilidad.

Una implementación activa-pasiva en varias zonas de disponibilidad a veces se denomina recuperación ante desastres en la región o recuperación ante desastres de metro.

En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Impacto
Confiabilidad	Cuando se implementa en una sola zona de disponibilidad:confiabilidad baja. Una implementación zonal no proporciona resistencia a una interrupción en un centro de datos ni en una zona de disponibilidad. Debe implementar recursos redundantes en varias zonas de disponibilidad para lograr una alta resistencia. Cuando se implementa en varias zonas de disponibilidad:confiabilidad alta. Los servicios se pueden hacer resistentes a una interrupción de un centro de datos o de una zona de disponibilidad.
Optimización de costos	Cuando se implementa en una sola zona de disponibilidad:bajo costo. Una implementación de una sola zona solo requiere una única instancia de cada recurso. Cuando se implementa en varias zonas de disponibilidad:Alto costo. Puede implementar varias instancias de los recursos, cada una de las cuales se factura por separado. También debe pagar por el tráfico entre zonas para la replicación de datos.
Eficiencia del rendimiento	Alto rendimiento. La latencia puede ser muy baja cuando los componentes que atienden una solicitud se encuentran en la misma zona de disponibilidad.
Excelencia operativa	Baja eficiencia operativa. Debe configurar y administrar varias instancias del servicio. Debe replicar datos entre zonas de disponibilidad. Durante una interrupción de la zona de disponibilidad, la conmutación por error es su responsabilidad.

En esta tabla se resumen algunos de los problemas desde una perspectiva arquitectónica:

Preocupación arquitectónica	Impacto
Cumplimiento de la residencia de datos	Alta. Al implementar una solución que usa este enfoque, los datos se almacenan en la región de Azure que seleccione.
Disponibilidad regional	Regiones con zonas de disponibilidad. Este enfoque está disponible en cualquier región que admita zonas de disponibilidad.

Este enfoque se usa normalmente para cargas de trabajo basadas en máquinas virtuales. Para obtener una lista completa de los servicios que admiten implementaciones zonales, consulte Servicio de zona de disponibilidad y compatibilidad regional.

Al planear una implementación zonal, compruebe que los servicios de Azure que usa son compatibles con las zonas de disponibilidad que planea usar. Por ejemplo, para enumerar qué SKU de máquina virtual están disponibles en cada zona de disponibilidad, consulte Comprobación de la disponibilidad de la SKU de máquina virtual.

Sugerencia

Al implementar un recurso en una zona de disponibilidad específica, seleccione el número de zona. La secuencia de números de zona es diferente para cada suscripción de Azure. Si implementa recursos en varias suscripciones de Azure, compruebe los números de zona que debe usar en cada suscripción. Para más información, consulte Zonas de disponibilidad física y lógica.

Enfoque de implementación 3: implementaciones con redundancia de zona

Al usar este enfoque, el nivel de aplicación se distribuye entre varias zonas de disponibilidad. Cuando llegan las solicitudes, un equilibrador de carga integrado en el servicio (que abarca zonas de disponibilidad) dispersa las solicitudes en todas las instancias de cada zona de disponibilidad. Si una zona de disponibilidad experimenta una interrupción, el equilibrador de carga dirige el tráfico a las instancias de las zonas de disponibilidad correctas.

El nivel de almacenamiento también se distribuye entre varias zonas de disponibilidad. Las copias de los datos de la aplicación se distribuyen entre varias zonas de disponibilidad a través de la replicación sincrónica. Cuando la aplicación realiza un cambio en los datos, el servicio de almacenamiento escribe el cambio en varias zonas de disponibilidad y la transacción solo se considera completa cuando se completan todos estos cambios. Este proceso garantiza que cada zona de disponibilidad siempre tenga una copia actualizada de los datos. Si una zona de disponibilidad experimenta una interrupción, se puede usar otra zona de disponibilidad para acceder a los mismos datos.

Un enfoque con redundancia de zona aumenta la resistencia de la solución a problemas como interrupciones del centro de datos. Sin embargo, dado que los datos se replican sincrónicamente, la aplicación tiene que esperar a que los datos se escriban en varias ubicaciones independientes que podrían estar en diferentes partes de un área metropolitana. Para la mayoría de las aplicaciones, la latencia implicada en la comunicación entre zonas es insignificante. Sin embargo, para algunas cargas de trabajo altamente sensibles a la latencia, la replicación sincrónica entre zonas de disponibilidad podría afectar al rendimiento de la aplicación.

En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Impacto
Confiabilidad	Alta confiabilidad. Los servicios son resistentes a una interrupción de un centro de datos o una zona de disponibilidad. Los datos se replican sincrónicamente entre zonas de disponibilidad y sin retraso.
Optimización de costos	Costo moderado. En función de los servicios que use, puede incurrir en algunos costos por niveles de servicio superiores para habilitar la redundancia de zona o algunos costos de red entre zonas.
Eficiencia del rendimiento	Para la mayoría de las cargas de trabajo:rendimiento aceptable. Es probable que este enfoque proporcione un rendimiento satisfactorio. Para cargas de trabajo altamente sensibles a la latencia:bajo rendimiento. Algunos componentes pueden ser sensibles a la latencia debido al tráfico entre zonas o al tiempo de replicación de datos.
Excelencia operativa	Alta eficiencia operativa. Normalmente, solo es necesario administrar una única instancia lógica de cada recurso. Para la mayoría de los servicios, durante una interrupción de la zona de disponibilidad, la conmutación por error es responsabilidad de Microsoft y se produce automáticamente.

En esta tabla se resumen algunos de los problemas desde una perspectiva arquitectónica:

Preocupación arquitectónica	Impacto
Cumplimiento de la residencia de datos	Alta. Al implementar una solución que usa este enfoque, los datos se almacenan en la región de Azure que seleccione.
Disponibilidad regional	Regiones con zonas de disponibilidad. Este enfoque está disponible en cualquier región que admita zonas de disponibilidad.

Este enfoque es posible con muchos servicios de Azure, como Azure Virtual Machine Scale Sets, Azure App Service, Azure Functions, Azure Kubernetes Service, Azure Storage, Azure SQL, Azure Service Bus, y muchos otros. Para obtener una lista completa de los servicios que admiten la redundancia de zona, consulte Servicio de zona de disponibilidad y compatibilidad regional.

Implementaciones con redundancia de zona con copia de seguridad entre regiones

Puede ampliar una implementación con redundancia de zona realizando copias de seguridad periódicas de la infraestructura y los datos en una región secundaria. Este enfoque proporciona las ventajas de un enfoque con redundancia de zona y agrega una capa de protección para mitigar el evento extremadamente improbable de una interrupción de toda la región.

Al implementar este enfoque, debe tener en cuenta cuidadosamente el RTO y el RPO:

• Tiempo de recuperación: si se produce una interrupción regional, es posible que tenga que volver a generar la solución en otra región de Azure, lo que afecta al tiempo de recuperación. Considere la posibilidad de crear la solución mediante un enfoque de IaC para que pueda volver a implementar rápidamente en otra región durante un desastre importante. Asegúrese de que las herramientas y los procesos de implementación son tan resistentes como las aplicaciones para poder usarlas para volver a implementar la solución, incluso si se produce una interrupción. Planee y ensaye los pasos necesarios para restaurar la solución a un estado de trabajo.

• Punto de recuperación: la frecuencia de copia de seguridad determina la cantidad de pérdida de datos que puede experimentar (el punto de recuperación). Normalmente, puede controlar la frecuencia de las copias de seguridad para satisfacer el RPO.

Sugerencia

Este enfoque suele proporcionar un buen equilibrio para todos los problemas arquitectónicos. Si no está seguro de qué enfoque usar, comience con este tipo de implementación.

En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Impacto
Confiabilidad	Confiabilidad muy alta. Los servicios son resistentes a una interrupción de un centro de datos o una zona de disponibilidad. Para la mayoría de los servicios, los datos se replican automáticamente entre zonas y sin retraso. Se realiza una copia de seguridad de los datos de forma asincrónica en una región separada geográficamente. Esta copia de seguridad reduce el efecto de una interrupción de toda la región al minimizar la pérdida de datos. Después de una interrupción completa de la región, puede restaurar manualmente las operaciones en otra región. Sin embargo, los procesos de recuperación pueden ser complejos y pueden tardar tiempo en restaurarse manualmente en la otra región.
Optimización de costos	Costo moderado. Normalmente, agregar una copia de seguridad a otra región cuesta un poco más que la implementación de redundancia de zona.
Eficiencia del rendimiento	Para la mayoría de las cargas de trabajo:rendimiento aceptable. Es probable que este enfoque proporcione un rendimiento satisfactorio. Para cargas de trabajo altamente sensibles a la latencia:bajo rendimiento. Algunos componentes pueden ser sensibles a la latencia debido al tráfico entre zonas o al tiempo de replicación de datos.
Excelencia operativa	Durante una interrupción de la zona de disponibilidad:alta eficiencia operativa. La conmutación por error es responsabilidad de Microsoft y se produce automáticamente. Durante una interrupción regional:baja eficiencia operativa. La conmutación por error es su responsabilidad y puede requerir operaciones manuales y reimplementaciones.

En esta tabla se resumen algunos de los problemas desde una perspectiva arquitectónica:

Preocupación arquitectónica	Impacto
Cumplimiento de la residencia de datos	Depende de la selección de región. Los datos se almacenan principalmente en la región de Azure que especifique, pero debe seleccionar otra región para almacenar las copias de seguridad. Seleccione una región compatible con los requisitos de residencia de datos.
Disponibilidad regional	Regiones con zonas de disponibilidad. Este enfoque está disponible en cualquier región que admita zonas de disponibilidad.

Enfoque de implementación 4: implementaciones en varias regiones

Puede usar varias regiones de Azure juntas para distribuir la solución en un área geográfica amplia. Puede usar este enfoque de varias regiones para mejorar la confiabilidad de la solución o para admitir usuarios distribuidos geográficamente. Al implementar en varias regiones, también se reduce el riesgo de que encuentre una restricción de capacidad de recursos temporales en una sola región. Si la residencia de datos es una preocupación importante para la solución, tenga en cuenta cuidadosamente qué regiones usa para asegurarse de que los datos solo se almacenan en ubicaciones que cumplan sus requisitos.

Regiones activas y pasivas

Las arquitecturas de varias regiones son complejas y hay muchas maneras de diseñar una solución de varias regiones. Para algunas cargas de trabajo, tiene sentido tener varias regiones procesando activamente las solicitudes simultáneamente (implementaciones activas-activas). Para otras cargas de trabajo, es mejor designar una región primaria y usar una o varias regiones secundarias para la conmutación por error (implementaciones activas-pasivas). Esta sección se centra en el segundo escenario, en el que una región está activa y otra es pasiva. Para obtener información sobre las soluciones de varias regiones activas y activas, consulte Patrón de stamps de implementación y Patrón geode.

Replicación de datos

La comunicación entre regiones es mucho más lenta que la comunicación dentro de una región. En general, una distancia geográfica mayor entre dos regiones incurre en una mayor latencia de red debido a la distancia física más larga que los datos necesitan viajar. Consulte Estadísticas de latencia de ida y vuelta de red de Azure para conocer la latencia de red esperada al conectarse entre dos regiones.

La latencia de red entre regiones puede afectar significativamente al diseño de la solución, ya que debe tener en cuenta cuidadosamente cómo afecta la latencia adicional a la replicación de datos y otras transacciones. Para muchas soluciones, una arquitectura entre regiones requiere replicación asincrónica para minimizar el efecto del tráfico entre regiones en el rendimiento.

Replicación de datos asincrónica

Al implementar la replicación asincrónica entre regiones, la aplicación no espera a que todas las regiones confirmen un cambio. Una vez confirmado el cambio en la región primaria, la transacción se considera completada. El cambio se replica en las regiones secundarias más adelante. Este enfoque garantiza que la latencia de conexión entre regiones no afecte directamente al rendimiento de la aplicación. Sin embargo, debido al retraso en la replicación, una interrupción en toda la región podría provocar una pérdida de datos. Esta pérdida de datos puede producirse porque una región puede experimentar una interrupción después de que se complete una escritura en la región primaria, pero antes de que el cambio se pueda replicar en otra región.

En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Impacto
Confiabilidad	Alta confiabilidad. La solución es resistente a una interrupción de un centro de datos, una zona de disponibilidad o una región completa. Los datos se replican, pero es posible que no sean sincrónicos, por lo que es posible que se produzca una pérdida de datos en un escenario de conmutación por error.
Optimización de costos	Alto costo. Debe implementar recursos independientes en cada región y cada recurso incurre en costos de implementación y mantenimiento. La replicación de datos entre regiones también podría suponer costos significativos.
Eficiencia del rendimiento	Alto rendimiento. Las solicitudes de aplicación no requieren tráfico entre regiones, por lo que el tráfico suele ser baja latencia.
Excelencia operativa	Baja eficiencia operativa. Debe implementar y administrar recursos en varias regiones. También es responsable de la conmutación por error entre regiones durante una interrupción regional.

En esta tabla se resumen algunos de los problemas desde una perspectiva arquitectónica:

Preocupación arquitectónica	Impacto
Cumplimiento de la residencia de datos	Depende de la selección de región. Este enfoque requiere que seleccione varias regiones para que la carga de trabajo se ejecute. Elija las regiones compatibles con los requisitos de residencia de datos.
Disponibilidad regional	Muchas regiones de Azure están emparejadas. Algunos servicios de Azure usan regiones emparejadas para replicar datos automáticamente. Si ejecuta la carga de trabajo en una región que no tiene un par, es posible que tenga que usar un enfoque diferente para replicar los datos.

Replicación de datos sincrónica

Si implementa una solución sincrónica de varias regiones, la aplicación debe esperar a que se completen las operaciones de escritura en cada región de Azure antes de que la transacción se considere completada. La latencia en la que se incurre al esperar operaciones de escritura depende de la distancia entre las regiones. Para muchas cargas de trabajo, la latencia entre regiones puede hacer que la replicación sincrónica sea demasiado lenta para ser útil.

En esta tabla se resumen algunos de los aspectos del pilar:

Fundamento	Impacto
Confiabilidad	Muy alta confiabilidad. La solución es resistente a una interrupción de un centro de datos, una zona de disponibilidad o una región completa. Los datos siempre están sincronizados entre regiones, por lo que, incluso si se produce una pérdida de región completa, los datos están disponibles y se completan en otra región.
Optimización de costos	Alto costo. Debe implementar recursos independientes en cada región y cada recurso incurre en costos de implementación y mantenimiento. La replicación de datos entre regiones también podría incurrir en costos significativos.
Eficiencia del rendimiento	Bajo rendimiento. Las solicitudes de aplicación requieren tráfico entre regiones. En función de la distancia entre las regiones, la replicación sincrónica podría agregar una latencia significativa a las solicitudes.
Excelencia operativa	Baja eficiencia operativa. Debe implementar y administrar recursos en varias regiones. También es responsable de la conmutación por error entre regiones durante una interrupción regional.

En esta tabla se resumen algunos de los problemas desde una perspectiva arquitectónica:

Preocupación arquitectónica	Impacto
Cumplimiento de la residencia de datos	Depende de la selección de región. Este enfoque requiere que seleccione varias regiones para que la carga de trabajo se ejecute. Seleccione las regiones compatibles con los requisitos de residencia de datos.
Disponibilidad regional	Muchas regiones de Azure están emparejadas. Algunos servicios de Azure usan regiones emparejadas para replicar datos automáticamente. Si ejecuta la carga de trabajo en una región que no tiene un par, es posible que tenga que usar un enfoque diferente para replicar los datos.

Arquitecturas de regiones

Al diseñar una solución de varias regiones, tenga en cuenta si las regiones de Azure que planea usar están emparejadas.

Puede crear una solución de varias regiones incluso cuando las regiones no estén emparejadas. Sin embargo, los enfoques que se usan para implementar una arquitectura de varias regiones pueden ser diferentes. Por ejemplo, en Azure Storage, puede usar el almacenamiento con redundancia geográfica (GRS) con regiones emparejadas. Si GRS no está disponible, considere la posibilidad de usar características como la replicación de objetos de Azure Storage o diseñar la aplicación para escribir en varias regiones.

Combinación de enfoques de varias zonas y regiones

Debe combinar instrucciones de varias zonas y de varias regiones si los requisitos empresariales exigen dicha solución. Por ejemplo, puede implementar componentes con redundancia de zona en cada región y configurar también la replicación entre las regiones. Para algunas soluciones, este enfoque proporciona un grado de confiabilidad muy alto. Sin embargo, la configuración de este tipo de enfoque puede ser complicada y este enfoque puede ser costoso.

Importante

Las cargas de trabajo críticas deben usar varias zonas de disponibilidad y varias regiones. Para obtener más información sobre las consideraciones que debe proporcionar al diseñar cargas de trabajo críticas, consulte la documentación sobre cargas de trabajo críticas.

Cómo admiten los servicios de Azure los enfoques de implementación

Es importante comprender los detalles específicos de los servicios de Azure que se usan. Por ejemplo, algunos servicios de Azure requieren que configure su configuración de zona de disponibilidad al implementar el recurso por primera vez, mientras que otros admiten cambiar el enfoque de implementación más adelante. De forma similar, es posible que algunas características de servicio no estén disponibles con cada enfoque de implementación.

Para más información sobre las opciones y enfoques de implementación específicos que se deben tener en cuenta para cada servicio de Azure, visite el centro de confiabilidad.

Ejemplos

En esta sección se describen algunos casos de uso comunes y los requisitos clave que normalmente debe tener en cuenta para cada carga de trabajo. Para cada carga de trabajo, se proporcionan uno o varios enfoques de implementación sugeridos, en función de los requisitos y enfoques descritos en este artículo.

Aplicación de línea de negocio para una empresa

Contoso, Ltd., es una gran empresa de fabricación. La empresa está implementando una aplicación de línea de negocio para administrar algunos componentes de sus procesos financieros.

Requisitos empresariales: la información que administra el sistema es difícil de reemplazar, por lo que los datos deben conservarse de forma confiable. Los arquitectos dicen que el sistema debe incurrir en un menor tiempo de inactividad y la menor pérdida de datos posible. Los empleados de Contoso usan el sistema en todo el día laboral, por lo que es importante tener un alto rendimiento para evitar que los miembros del equipo esperen. El costo también es un problema, ya que el equipo financiero tiene que pagar por la solución.

Enfoque sugerido: la implementación con redundancia de zona con copia de seguridad entre regiones proporciona varias capas de resistencia con alto rendimiento.

Aplicación interna

Fourth Coffee es una pequeña empresa. La empresa está desarrollando una nueva aplicación interna que los empleados pueden usar para enviar partes de horas.

Requisitos empresariales: para esta carga de trabajo, la rentabilidad es una preocupación principal. Fourth Coffee evaluó el impacto empresarial del tiempo de inactividad y decidió que la aplicación no necesita priorizar la resistencia ni el rendimiento. La empresa acepta el riesgo de que una interrupción en una región o zona de disponibilidad de Azure pueda hacer que la aplicación no esté disponible temporalmente.

Enfoques sugeridos:

• La implementación con redundancia local con copias de seguridad entre regiones tiene el costo más bajo, pero también tiene riesgos significativos.
• La implementación con redundancia de zona con copia de seguridad entre regiones proporciona una mejor resistencia, pero a un costo ligeramente mayor.

Migración de aplicaciones heredadas

Fabrikam, Inc., está migrando una aplicación heredada desde un centro de datos local a Azure. La implementación usará un enfoque iaaS basado en máquinas virtuales. La aplicación no se diseñó para un entorno de nube y la comunicación entre el nivel de aplicación y la base de datos es muy chatear.

Requisitos empresariales: el rendimiento es una prioridad para esta aplicación. La resistencia también es importante y la aplicación debe seguir funcionando incluso si un centro de datos de Azure experimenta una interrupción.

Enfoque sugerido:

• Fabrikan primero debe probar una implementación con redundancia de zona. Deben comprobar que el rendimiento cumple sus requisitos.
• Si el rendimiento de la solución con redundancia de zona no es aceptable, considere la posibilidad de una implementación zonal (anclada), con implementaciones pasivas en varias zonas de disponibilidad (recuperación ante desastres en regiones).

Aplicación de atención sanitaria

Lamna Healthcare Company está implementando un nuevo sistema de registros de salud electrónicos en Azure.

Requisitos empresariales: debido a la naturaleza de los datos que almacena esta solución, la residencia de datos es fundamentalmente importante. Lamna funciona bajo un marco normativo estricto que exige que los datos permanezcan en una ubicación específica.

Enfoques sugeridos:

• Implementación en varias regiones, si hay varias regiones que se ajustan a los requisitos de residencia de datos de Lamna.
• Si solo hay una sola región que se adapte a sus necesidades, considere una implementación con redundancia de zona o una implementación con redundancia de zona con copia de seguridad entre regiones proporciona una solución de una sola región.

Sistema bancario

Woodgrove Bank ejecuta sus principales operaciones bancarias desde una solución grande que se implementa en Azure.

Requisitos empresariales: se trata de un sistema crítico. Cualquier interrupción puede causar un impacto financiero importante para los clientes. Como resultado, Woodgrove Bank tiene una tolerancia de riesgo muy baja. El sistema necesita el mayor nivel de confiabilidad posible y la arquitectura debe mitigar el riesgo de errores que se pueden mitigar.

Enfoque sugerido: para un sistema crítico, use una implementación de varias regiones de varias zonas. Asegúrese de que las regiones se ajusten a los requisitos de residencia de datos de la empresa.

Software como servicio (SaaS)

Proseware, Inc., crea software que usan empresas de todo el mundo. La base de usuarios de la empresa está ampliamente distribuida geográficamente.

Requisitos empresariales: Proseware debe permitir que cada uno de sus clientes elija una región de implementación cercana al cliente. Habilitar esta opción es importante para la latencia y para los requisitos de residencia de datos de los clientes.

Enfoques sugeridos:

• Una implementación de varias regiones de varias zonas suele ser una buena opción para un proveedor de SaaS, especialmente cuando se usa en el patrón De stamps de implementación.
• Una implementación con redundancia de zona de una sola región junto con una solución de aceleración de tráfico global, como Azure Front Door.

Vínculos relacionados

A continuación se muestran algunas arquitecturas de referencia y escenarios de ejemplo para soluciones de varias zonas y de varias regiones:

• Aplicación web redundante por zonas de alta disponibilidad de línea de base
• Aplicación web de varias regiones de alta disponibilidad
• Aplicación de n niveles para varias regiones
• Aplicación web de varios niveles creada para alta disponibilidad y recuperación ante desastres

Muchos servicios de Azure proporcionan instrucciones sobre cómo usar varias zonas de disponibilidad, incluidos los ejemplos siguientes:

• Azure Site Recovery: Habilitación de la recuperación ante desastres de máquinas virtuales de Azure entre zonas de disponibilidad
• Azure NetApp Files: Descripción de la replicación entre zonas de Azure NetApp Files
• Redundancia de Azure Storage

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad