Recomendaciones para el uso de zonas de disponibilidad y regiones
Se aplica a esta recomendación de lista de comprobación de confiabilidad del marco de trabajo bien diseñado de Azure:
| RE:05 | Agregue redundancia en distintos niveles, especialmente para los 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 se 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, las desventajas implicadas en cada enfoque y el efecto de cada enfoque en los pilares básicos del marco de azure Well-Architected.
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 usa regiones y zonas de disponibilidad dentro de la solución también afecta a varios de los pilares del marco bien diseñado:
- 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 implementar más recursos que otros, lo que puede aumentar los costos de los recursos. Otros enfoques implican el envío de datos a través de 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 la mayoría de las cargas de trabajo para permitir 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 tener en cuenta la ubicación física de 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 la 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 y cómo se usan zonas de disponibilidad y regiones no cambian la posición de seguridad. Azure aplica el mismo rigor de seguridad a cada región y zona de disponibilidad.
Sugerencia
Para muchas cargas de trabajo de producción, una implementación con redundancia de zona proporciona el mejor equilibrio entre las ventajas y desventajas. Puede ampliar este enfoque con la copia de seguridad de datos asincrónica en otra región. Si no tiene claro 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 tráfico principal y procesa, y se implementan una o varias instancias secundarias para atender el tráfico si la 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 | 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 más recientes de Azure 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 se 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) | 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 una descripción completa 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 regiones.
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 con otras zonas de disponibilidad, pero están lo suficientemente separadas como 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 suministro eléctrico, de refrigeración y de red independientes. Están diseñadas para los casos en los que cuando una zona experimente alguna interrupción, las zonas restantes sigan ofreciendo servicios regionales, capacidad y alta disponibilidad.
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 mantener 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 distintas zonas para satisfacer los requisitos de alta confiabilidad. Usted es el responsable de administrar la replicación de datos y distribuir solicitudes entre zonas. Si se produce alguna interrupción en una sola zona de disponibilidad, usted es el responsable de la conmutación por error a otra zona de disponibilidad.
- Los recursos con redundancia de zona se propagan 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 alguna 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) por lo general admiten 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 son 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 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. Sin embargo, en última instancia, 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 inteligentemente los recursos 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 más información sobre cómo Azure implementa las actualizaciones, consulte Avanzar en las prácticas de implementación seguras.
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. Dependiendo 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. Al usar servicios administrados, Microsoft asume más responsabilidades de administración para los recursos, lo que puede incluso 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 las zonas de disponibilidad y las regiones de la solución, debe comprender sus requisitos. Estos requisitos deben basarse en discusiones entre diseñadores de soluciones y partes interesadas empresariales.
Tolerancia al riesgo
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 merece la pena mitigar los riesgos que es poco probable que se produzcan, como los 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. |
Alto. Cualquier estrategia de resistencia debe tener en cuenta estos riesgos. |
| Interrupción del centro de datos | Errores 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 | Desastre natural importante que afecta 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 incluso eventos de baja probabilidad. Para 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 esperado de tiempo de actividad (SLO) de la solución. Por ejemplo, puede tener 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 necesita 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 manera en que considere el estado de la carga de trabajo.
Las decisiones arquitectónicas afectan al SLO compuesto de la solución. En general, cuanto mayor sea la redundancia que cree en la solución, mayor 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 de 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 esos estándares especifiquen realmente.
Ubicación de 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, considere si necesita una implementación de varias regiones. Considere 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 opera 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 adicionales de recursos, 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 de los pilares:
| Fundamento | Redundante localmente | Zonal (anclado) | Con 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 | Redundante localmente | Zonal (anclado) | Con 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 |
El resto de este artículo 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 entre 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 muy sensibles a la latencia, este enfoque también podría dar lugar a un rendimiento menor. 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 de los pilares:
| 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 incurrirá en ningún costo de ancho de banda 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 muy 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 algunas de las preocupaciones desde una perspectiva arquitectónica:
| Preocupación arquitectónica | Impacto |
|---|---|
| Cumplimiento de la residencia de datos | Alto. Al implementar una solución que use este enfoque, los datos se almacenan en la región de Azure que seleccione. |
| Disponibilidad regional | Alto. 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 compilar 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 son tan resistentes como las aplicaciones para poder usarlas para volver a implementar la solución incluso si hay 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 de los pilares:
| Fundamento | Impacto |
|---|---|
| Confiabilidad | Confiabilidad moderada. Los servicios están sujetos a interrupciones si se produce un error en un centro de datos. Los datos se realizan 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 cuesta un poco 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 muy 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 | Durante cualquier interrupción dentro de una región: baja eficiencia operativa. La conmutación por error es su responsabilidad y podría requerir operaciones manuales y reimplementaciones. |
En esta tabla se resumen algunas de las preocupaciones 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 | Alto. 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 deben implementarse 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, se implementa un equilibrador de carga 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 una 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, a continuación, 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.
A veces, una implementación activa-pasiva en varias zonas de disponibilidad se denomina recuperación ante desastres en la región o la recuperación ante desastres de metro.
En esta tabla se resumen algunos de los aspectos de los pilares:
| 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 o 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: alta confiabilidad. Los servicios se pueden hacer resistentes a una interrupción de un centro de datos o de 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 sola 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. |
| 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 zona de disponibilidad, la conmutación por error es su responsabilidad. |
En esta tabla se resumen algunas de las preocupaciones desde una perspectiva arquitectónica:
| Preocupación arquitectónica | Impacto |
|---|---|
| Cumplimiento de la residencia de datos | Alto. Al implementar una solución que use 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 soporte técnico regional.
Cuando planee 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ísicas y lógicas.
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 muy 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 de los pilares:
| 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 de niveles de servicio más altos para habilitar la 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 muy 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 debe administrar una sola instancia lógica de cada recurso. Para la mayoría de los servicios, durante una interrupción de zona de disponibilidad, la conmutación por error es responsabilidad de Microsoft y se produce automáticamente. |
En esta tabla se resumen algunas de las preocupaciones desde una perspectiva arquitectónica:
| Preocupación arquitectónica | Impacto |
|---|---|
| Cumplimiento de la residencia de datos | Alto. Al implementar una solución que use 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, incluidos Azure Virtual Machine Scale Sets, App de Azure 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 soporte técnico 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 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 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 cumplir 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 de los pilares:
| 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 entre zonas automáticamente y sin retraso. Los datos se copian de seguridad de forma asincrónica en una región separada geográficamente. Esta copia de seguridad reduce el efecto de una interrupción de la región completa 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 muy 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 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 podría requerir operaciones manuales y reimplementaciones. |
En esta tabla se resumen algunas de las preocupaciones 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 que sea 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 temporal 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 se almacenan solo 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 solicitudes simultáneamente (implementaciones activas y 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 mayor distancia geográfica entre dos regiones incurre en más latencia de red debido a la distancia física más larga que los datos necesitan para 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 dar lugar a una pérdida de datos. Esta pérdida de datos puede producirse porque una región podría experimentar una interrupción después de completar una escritura en la región primaria, pero antes de que el cambio se pudiera replicar en otra región.
En esta tabla se resumen algunos de los aspectos de los pilares:
| 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 puede 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 algunas de las preocupaciones 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 se ejecute la carga de trabajo. Elija 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 que se incurre en la espera de 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 de los pilares:
| Fundamento | Impacto |
|---|---|
| Confiabilidad | Confiabilidad muy alta. 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 completos 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 puede suponer 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 algunas de las preocupaciones 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 se ejecute la carga de trabajo. 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 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 varias regiones
Debe combinar instrucciones de varias zonas y varias regiones si los requisitos empresariales exigen dicha solución. Por ejemplo, puede implementar componentes con redundancia de zona en cada región y también configurar la replicación entre las regiones. Para algunas soluciones, este enfoque proporciona un grado muy alto de confiabilidad. 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 usa. 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 el cambio del enfoque de implementación más adelante. Del mismo modo, 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 tiempo de inactividad tan pequeño como sea posible. Los empleados de Contoso usan el sistema durante todo el día laboral, por lo que es importante evitar que los miembros del equipo sigan esperando. 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. Cuarto café evaluó el impacto empresarial del tiempo de inactividad y decidió que la aplicación no necesita priorizar la resistencia o 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 deje de estar disponible temporalmente.
Enfoques sugeridos:
- La implementación con redundancia local con copias de seguridad entre regiones tiene el menor costo, 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 de un centro de datos local a Azure. La implementación usará un enfoque de 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 chatsa.
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 debe probar primero 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 implementar 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 sanitarios 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 de varias zonas, 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 operaciones bancarias principales desde una solución grande que se implementa en Azure.
Requisitos empresariales: se trata de un sistema crítico. Las interrupciones pueden 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 cualquier error que se pueda 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 usado por 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 varias regiones:
- Aplicación web altamente disponible con redundancia de zona 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.