Estrategias de arquitectura para diseñar redundancia

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

En esta guía se describen las recomendaciones para agregar redundancia a lo largo de flujos críticos en diferentes capas de carga de trabajo, lo que optimiza la resistencia. Cumpla los requisitos de los objetivos de confiabilidad definidos aplicando los niveles adecuados de redundancia a los niveles de proceso, datos, redes y otras capas de infraestructura. Aplique esta redundancia para proporcionar a la carga de trabajo una base sólida y confiable en la que basarse. Al compilar la carga de trabajo sin redundancia de infraestructura, existe un alto riesgo de tiempo de inactividad prolongado debido a posibles errores.

Definiciones

En el contexto de confiabilidad, use redundancia para contener problemas que afecten a un único recurso y asegúrese de que esos problemas no afecten a la confiabilidad de todo el sistema. Use la información que identificó sobre los flujos críticos y los objetivos de confiabilidad para tomar decisiones informadas necesarias para la redundancia de cada flujo.

Por ejemplo, puede tener varios nodos de servidor web que se ejecutan a la vez. Si el flujo que admiten es crítico, es posible que todos los nodos necesiten réplicas que puedan aceptar el tráfico inmediatamente si un problema afecta a todo el grupo, como una interrupción completa del centro de datos. Como alternativa, dado que los problemas a gran escala son poco frecuentes y es costoso implementar un conjunto completo de réplicas, puede implementar un número limitado de réplicas para que el flujo funcione en un estado degradado hasta que resuelva el problema.

Al diseñar la redundancia en el contexto de la eficacia del rendimiento, distribuya la carga entre varios nodos redundantes para asegurarse de que cada nodo funciona de forma óptima. En el contexto de confiabilidad, cree una capacidad de reserva para absorber errores o mal funcionamientos que afecten a uno o varios nodos. Asegúrese de que la capacidad de reserva puede absorber errores durante todo el tiempo necesario para recuperar los nodos afectados. Teniendo en cuenta esta distinción, ambas estrategias deben trabajar conjuntamente. Si distribuye el tráfico entre dos nodos para el rendimiento y ambos se ejecutan en 60% uso y se produce un error en un nodo, el nodo restante corre el riesgo de sobrecargarse porque no puede funcionar en 120%. Extienda la carga con otro nodo para asegurarse de que se mantienen los objetivos de rendimiento y confiabilidad.

Desventajas:

• Más redundancia de carga de trabajo equivale a más costos. Considere cuidadosamente la posibilidad de agregar redundancia y revisar periódicamente la arquitectura para asegurarse de que administra los costos, especialmente cuando se usa el sobreaprovisionamiento. Cuando se usa el sobreaprovisionamiento como estrategia de resistencia, equilibre con una estrategia de escalado bien definida para minimizar las ineficacias de costos.

• Puede haber inconvenientes en el rendimiento cuando se crea en un alto grado de redundancia. Por ejemplo, los recursos que se distribuyen entre zonas de disponibilidad o ubicaciones pueden afectar al rendimiento porque tiene que enviar tráfico a través de conexiones de alta latencia entre recursos redundantes, como servidores web o instancias de base de datos.

• Los distintos flujos dentro de la misma carga de trabajo pueden tener requisitos de confiabilidad diferentes. Los diseños de redundancia específicos del flujo pueden introducir complejidad en el diseño general.

• Un diseño de redundancia de baja latencia significa que acepta el riesgo de perder esos componentes en caso de que se produzca un evento a gran escala, como un desastre geográfico, que desconecte todas las instancias. Un entorno de recuperación ante desastres geográficamente distante (DR) ayuda a mitigar este riesgo, pero aumenta los costos.

Preferir servicios sin servidor y totalmente administrados para reducir la carga operativa

Aproveche las soluciones sin servidor, software como servicio (SaaS) y plataforma como servicio (PaaS) para agregar fácilmente redundancia a la carga de trabajo sin necesidad de administrar la replicación de datos o las operaciones de conmutación por error. Estos servicios implementan redundancia de forma transparente, lo que elimina la carga operativa de diseñar y mantener sus propios mecanismos de redundancia. Al evaluar las opciones de servicio, priorice los servicios administrados que controlan la redundancia automáticamente sobre los enfoques basados en la infraestructura que requieren la configuración de redundancia manual.

Los servicios administrados de Azure proporcionan redundancia a través de diferentes modelos. Cada modelo proporciona distintos niveles de abstracción y simplicidad operativa.

Servicios globales con redundancia integrada: Los servicios como Microsoft Entra ID, Azure DNS y Azure Key Vault funcionan como servicios globales con redundancia automática en varias regiones. Estos servicios proporcionan resistencia inherente sin necesidad de ninguna configuración de redundancia de usted. Controlan automáticamente los escenarios de conmutación por error y recuperación de forma transparente.

Modelos de capacidad abstracta: Las ofertas como Azure Cosmos DB, Azure Databricks y los puntos de conexión administrados de Azure OpenAI abstraen la complejidad de la infraestructura subyacente detrás de unidades de capacidad, DTU u otras métricas lógicas. Estos servicios distribuyen automáticamente la carga de trabajo en varias instancias, zonas y regiones al presentar un modelo de administración y facturación simplificados. Especifique los requisitos de capacidad en lugar de administrar instancias redundantes individuales.

Al diseñar la solución, evalúe si existe una opción de servicio administrado para cada componente antes de implementar la redundancia basada en la infraestructura. Los servicios administrados reducen la sobrecarga operativa y, a menudo, proporcionan implementaciones de redundancia más sólidas que las soluciones personalizadas, aunque podrían implicar inconvenientes en el control y costos potencialmente mayores para cada unidad de capacidad.

Compilación de redundancia en la carga de trabajo con varias instancias de componentes

Implemente varias instancias de los componentes y servicios de infraestructura para lograr la resistencia que necesita la carga de trabajo. Esta estrategia de redundancia fundamental garantiza que, si se produce un error en una instancia, otras instancias pueden seguir controlando la carga de trabajo. Puede lograr varias instancias a través de diferentes enfoques. Algunos escenarios requieren que configure manualmente la redundancia mediante la implementación de varios recursos individualmente, como varios circuitos De Azure ExpressRoute o la configuración de Azure Traffic Manager en varias regiones. Otros servicios están diseñados para admitir varias instancias directamente, como establecer conjuntos de escalado de máquinas virtuales de Azure en cinco instancias o configurar Azure App Service para ejecutar 10 instancias. Cuando sea posible, prefiera los servicios que proporcionan compatibilidad integrada con varias instancias y funcionalidades de escalado automático, ya que simplifican la administración de redundancia y pueden responder a las necesidades de confiabilidad y rendimiento.

Al implementar componentes de infraestructura redundantes, determine cuántas instancias de cada componente satisfacen los objetivos de confiabilidad. Tenga en cuenta si necesita varias instancias de todos los componentes o solo componentes críticos específicos y determine la distribución geográfica de esas instancias para satisfacer los requisitos de resistencia. Al implementar la infraestructura redundante, tenga en cuenta las siguientes recomendaciones.

Recursos de proceso:

• Prefiere los servicios que tienen compatibilidad con redundancia integrada. Estos servicios le permiten especificar el número de instancias que necesita y pueden controlar la distribución y administración de esas instancias.

• Mantenga la capa de proceso limpia de cualquier estado porque los nodos individuales que atienden las solicitudes se pueden eliminar, producir errores o reemplazarse en cualquier momento.

• Diseñe y pruebe la estrategia de escalado para que coincida con el enfoque de redundancia.

Recursos de datos:

• Replique los datos entre regiones geográficas para proporcionar resistencia a interrupciones regionales y errores catastróficos.

• Comprenda las funcionalidades de replicación y redundancia integradas de los servicios de plataforma con estado que usa.

• Determine si es necesaria la replicación de datos sincrónica o asincrónica para la funcionalidad de la carga de trabajo. Para obtener más información, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

• Distribuya los datos geográficamente, como admite el servicio, para minimizar el efecto de los errores localizados geográficamente.

• Automatice la conmutación por error después de un error de instancia de base de datos. Puede configurar la conmutación por error automatizada en varios servicios de datos PaaS de Azure. La conmutación por error automatizada no es necesaria para los almacenes de datos que admiten escrituras en varias regiones, como Azure Cosmos DB. Para obtener más información, consulte Recomendaciones para diseñar una estrategia de recuperación ante desastres.

• Use el mejor almacén de datos para los datos. Adopte la persistencia poliglot o las soluciones que usan una combinación de tecnologías de almacén de datos. Los datos incluyen más que solo datos persistentes de la aplicación. También incluye registros de aplicaciones, eventos, mensajes y memorias caché.

• Considere los requisitos de coherencia de los datos y use la coherencia final cuando los requisitos lo permitan. Cuando se distribuyen los datos, use la coordinación adecuada para aplicar garantías de coherencia sólidas. La coordinación puede reducir el rendimiento y hacer que los sistemas se acoplan estrechamente, lo que puede hacer que sean más débiles. Por ejemplo, si una operación actualiza dos bases de datos, en lugar de colocarla en un único ámbito de transacción, es mejor si el sistema puede dar cabida a la coherencia final.

• Creación de particiones de datos para disponibilidad. La creación de particiones de base de datos mejora la escalabilidad y también puede mejorar la disponibilidad. Si una partición deja de funcionar, las demás particiones siguen siendo accesibles. Un error en una partición solo interrumpe un subconjunto de las transacciones totales.

• Si el particionamiento no es una opción, puede usar el patrón Segregación de responsabilidades de consulta de comandos (CQRS) para separar los modelos de datos de solo lectura y escritura. Agregue más instancias de base de datos de solo lectura redundantes para proporcionar más resistencia.

Recursos de red:

• Decida una topología de red confiable y escalable. Use un modelo en estrella tipo hub-and-spoke o un modelo de Azure Virtual WAN para ayudarle a organizar la infraestructura en la nube en patrones lógicos que facilitan la compilación y el escalado del diseño de redundancia.

• Seleccione el servicio de red adecuado para equilibrar y redirigir las solicitudes dentro o entre regiones. Use los servicios de equilibrio de carga globales o con redundancia de zona cuando sea posible para cumplir los objetivos de confiabilidad.

• Asegúrese de que ha asignado suficiente espacio de direcciones IP en las redes virtuales y subredes para tener en cuenta el uso planeado, incluidos los requisitos de escalabilidad horizontal.

• Asegúrese de que la aplicación se puede escalar dentro de los límites de puerto de la plataforma de hospedaje de aplicaciones elegida. Si una aplicación inicia varias conexiones de Protocolo de control de transmisión de salida (TCP) o Protocolo de datagramas de usuario (UDP), puede agotar todos los puertos disponibles y provocar un rendimiento deficiente de la aplicación.

• Elija SKU y configure los servicios de red que pueden cumplir los requisitos de ancho de banda y disponibilidad. El rendimiento de una puerta de enlace de VPN varía en función de su SKU. La compatibilidad con la redundancia de zona solo está disponible para algunas SKU del equilibrador de carga.

• Asegúrese de que el diseño para controlar el sistema de nombres de dominio (DNS) se ha creado con un enfoque en la resistencia y admite la infraestructura redundante.

Uso del patrón de stamps de implementación para simplificar el enfoque de redundancia

Además de la redundancia de los componentes y servicios de infraestructura individuales, amplíe la estrategia de redundancia al nivel de carga de trabajo mediante la implementación de varias instancias de toda la carga de trabajo o grupos lógicos de recursos. Siga el patrón de diseño de stamps de implementación para crear unidades repetibles y independientes que incluyan todos los recursos necesarios para entregar la carga de trabajo a un subconjunto específico de usuarios o requisitos.

Las marcas de implementación representan un cambio de nivel de componente a redundancia de nivel de carga de trabajo. Cada stamp actúa como una unidad completa de escala que contiene todos los recursos necesarios(proceso, almacenamiento, redes y dependencias) que pueden funcionar de forma independiente. Este enfoque proporciona ventajas clave, incluidos los dominios de error aislados que contienen radio de explosión, escalado horizontal a través de implementación adicional de marca en lugar de escalado de componentes individuales, segmentación flexible por geografía o requisitos, y operaciones simplificadas a través de unidades repetibles idénticas.

Tanto si implementa stamps en un modelo activo-activo (donde todos los stamps sirven activamente el tráfico simultáneamente) o el modelo activo-pasivo (donde un stamp atiende el tráfico mientras otros permanecen en espera), diseñe cada stamp para que sea una implementación completa y autoadministrada que pueda controlar su carga de trabajo designada de forma independiente.

Lograr un tiempo de inactividad cero a través de redundancia activa-activa

Las implementaciones activas maximizan la disponibilidad del servicio mediante la ejecución simultánea de varias instancias de una carga de trabajo, cada una de ellas controla activamente el tráfico. Esta configuración garantiza la conmutación por error inmediata, elimina el tiempo de inactividad y optimiza el uso de recursos manteniendo todas las instancias productivas. Si se produce un error en una instancia, el tráfico se vuelve a enrutar automáticamente a instancias correctas sin interrumpir el servicio.

Por ejemplo, una plataforma de comercio electrónico durante la temporada punta puede mantener operaciones sin problemas incluso si una implementación encuentra problemas. Las configuraciones activas y activas son ideales para cargas de trabajo críticas que requieren disponibilidad ininterrumpida, pero tienen mayores costos de infraestructura y complejidad. Las estrategias operativas avanzadas son necesarias para administrar varios entornos activos, garantizar la coherencia de los datos y coordinar las actualizaciones en todas las instancias.

En las secciones siguientes se describen las opciones de configuración de las implementaciones activas-activas.

• Activo-activo a la capacidad: Marcas de implementación reflejadas en dos o más ubicaciones, cada una configurada para controlar las cargas de trabajo de producción de la ubicación o las ubicaciones que sirven y escalables para controlar las cargas de otras ubicaciones si se produce una interrupción regional.

  • Gestión de redes: Use la latencia o el enrutamiento global ponderado para distribuir el tráfico entre ubicaciones.

  • Replicación y coherencia de datos: Use un almacén de datos distribuido globalmente como Azure Cosmos DB para funcionalidades de lectura y escritura en varias regiones. En el caso de las bases de datos relacionales, use réplicas legibles con cadenas de conexión de solo lectura.

  • Ventaja de este diseño: Menores costos operativos que un diseño sobreaprovisionado.

  • Desventaja de este diseño: Posible degradación de la experiencia del usuario al escalar verticalmente para satisfacer las demandas de una carga completa si otra ubicación experimenta una interrupción.

• Sobreaprovisionado activo-activo: Marcas de implementación reflejadas en dos o más ubicaciones, cada una de ellas sobreaprovisionada para controlar las cargas de trabajo de producción para la ubicación o las ubicaciones que sirven y para controlar las cargas de otras ubicaciones si se produce una interrupción regional.

  • Gestión de redes: Use la latencia o el enrutamiento global ponderado para distribuir el tráfico entre ubicaciones.

  • Replicación y coherencia de datos: Use un almacén de datos distribuido globalmente como Azure Cosmos DB para funcionalidades de lectura y escritura en varias regiones. En el caso de las bases de datos relacionales, use réplicas legibles con cadenas de conexión de solo lectura.

  • Ventaja de este diseño: El diseño más resistente posible.

  • Desventaja de este diseño: Mayores costos operativos que un diseño escalable.

• Ventajas comunes de ambos diseños: Alta resistencia y bajo riesgo de interrupción completa de la carga de trabajo.

• Desventajas comunes de ambos diseños: Mayores costos operativos y carga de administración debido a diversos factores, incluida la necesidad de administrar la sincronización del estado y los datos de la aplicación.

Uso de un diseño de arquitectura activo-pasivo como enfoque de recuperación ante desastres rentable

Las configuraciones de implementación activa-pasiva proporcionan una manera rentable de garantizar la recuperación ante desastres mediante la ejecución de una instancia principal que controla todo el tráfico mientras mantiene inactivas las instancias secundarias, pero listas. Estas instancias en espera solo se activan cuando se produce un error en la instancia principal o se somete a mantenimiento. Este enfoque minimiza el uso de recursos al tiempo que proporciona funcionalidades de conmutación por error confiables.

Por ejemplo, una plataforma de negociación financiera puede usar esta configuración para mantener la continuidad del servicio. El sistema principal administra todas las transacciones, mientras que el sistema secundario permanece sincronizado en segundo plano. Si el sistema principal deja de funcionar, el sistema secundario toma rápidamente el control y restaura las operaciones con una interrupción mínima. Este enfoque equilibra la confiabilidad y el costo, lo que hace que sea ideal para las cargas de trabajo que pueden tolerar tiempos de recuperación breves sin la complejidad o el gasto de las implementaciones activas-activas.

Tenga en cuenta las siguientes opciones de configuración para las implementaciones activas-pasivas.

• Reserva caliente: Una ubicación principal y una o varias ubicaciones secundarias. La ubicación secundaria se implementa con el tamaño mínimo posible de proceso y datos y se ejecuta sin carga. Esta ubicación se conoce como una ubicación de reserva cálida . Después de la conmutación por error, los recursos de proceso y de datos se escalan para controlar la carga desde la ubicación principal.

  • Gestión de redes: Use el enrutamiento global de prioridad .

  • Replicación y coherencia de datos: Replique la base de datos en la ubicación pasiva y use las funcionalidades de conmutación automática por error de las soluciones paaS, como Azure Cosmos DB y Azure SQL Database.

  • Ventaja de este diseño: Menor tiempo de recuperación entre los diseños activos-pasivos.

  • Desventaja de este diseño: Mayor costo operativo entre los diseños activos-pasivos.

• Repuesto en frío: Una ubicación principal y una o varias ubicaciones secundarias. La ubicación secundaria se escala para controlar la carga completa, pero se detienen todos los recursos de proceso. Esta ubicación se conoce como ubicación de reserva fría . Debe iniciar los recursos antes de la conmutación por error.

  • Gestión de redes: Use el enrutamiento global de prioridad .

  • Replicación y coherencia de datos: Replique la base de datos en la ubicación pasiva y use las funcionalidades de conmutación automática por error de las soluciones de PaaS, como Azure Cosmos DB y SQL Database.

  • Ventaja de este diseño: Menores costos operativos que el diseño de reserva caliente.

  • Desventaja de este diseño: Tiempo de recuperación más largo que el diseño de reserva caliente.

Distribución de cargas de trabajo en la infraestructura independiente de proximate

La implementación de cargas de trabajo en centros de datos o sectores de centros de datos independientes cercanos proporciona redundancia sin poner en peligro el rendimiento. Mediante el uso de instalaciones geográficamente cercanas pero físicamente independientes, esta configuración garantiza el aislamiento de errores con un impacto mínimo de latencia. Proporciona la resistencia de la infraestructura distribuida al tiempo que mantiene la capacidad de respuesta de una implementación de un solo sitio. En Azure, las zonas de disponibilidad proporcionan esta funcionalidad. Las zonas de disponibilidad son centros de datos o sectores de centros de datos físicamente independientes que están diseñados para permitirle implementar fácilmente cargas de trabajo de baja latencia y tolerantes a errores.

En el caso de las aplicaciones sensibles a la latencia, como los juegos en tiempo real, este enfoque permite una conmutación por error sin interrupciones y una experiencia de usuario ininterrumpida. Los servidores de juegos distribuidos entre centros de datos locales pueden volver a enrutar el tráfico al instante durante las interrupciones, con equilibrio de carga transparente y replicación de datos casi en tiempo real que conserva la continuidad del juego. Sin embargo, esta estrategia conlleva algún riesgo porque los eventos regionales a gran escala pueden seguir afectando a todos los sitios simultáneamente.

Reforzar la tolerancia a errores con implementaciones geográficamente distantes

La implementación en centros de datos distribuidos geográficamente proporciona la protección más fuerte frente a desastres a gran escala al distribuir cargas de trabajo entre regiones de cientos o miles de kilómetros de distancia. Este enfoque garantiza la continuidad empresarial durante eventos como desastres naturales, errores de infraestructura o interrupciones geopolíticas que pueden afectar a todas las áreas metropolitanas. En Azure, puede implementar cargas de trabajo en regiones, que se distribuyen en todo el mundo. Al usar este enfoque de diseño, elija regiones cercanas a los usuarios, pero que estén geográficamente distantes, como Oeste de EE. UU. y Este de EE. UU.

Por ejemplo, una plataforma financiera global puede mantener un servicio ininterrumpido mediante el enrutamiento del tráfico a regiones no afectadas si una área experimenta una interrupción importante. Este enfoque maximiza la resistencia y admite el cumplimiento normativo en las jurisdicciones, pero presenta una mayor latencia, requisitos complejos de coherencia de datos y mayor sobrecarga operativa. Debe ponderar estos factores cuidadosamente contra las ventajas de la redundancia global.

Facilitación de Azure

La plataforma Azure le ayuda a optimizar la resistencia de la carga de trabajo y a agregar redundancia mediante las siguientes acciones:

• Le ayuda a seleccionar las mejores regiones de Azure para la arquitectura de varias regiones con la guía Seleccionar regiones de Azure.

• Proporciona redundancia integrada con muchas soluciones PaaS y SaaS, algunas de las cuales son configurables.

• Proporciona servicios administrados globales como Microsoft Entra ID, Azure DNS y Key Vault que implementan redundancia de forma transparente sin necesidad de configuración.

• Permite diseñar e implementar redundancia dentro de la región mediante zonas de disponibilidad y redundancia entre regiones.

• Proporciona soluciones de proceso con redundancia de zona, como Virtual Machine Scale Sets, que pueden distribuir automáticamente el proceso uniformemente entre zonas de disponibilidad al implementar máquinas virtuales (VM).

• Proporciona servicios de equilibrio de carga compatibles con réplicas, como Azure Application Gateway, Azure Front Door y Azure Load Balancer.

• Proporciona soluciones de replicación geográfica implementadas fácilmente, como la replicación geográfica activa para SQL Database. Implemente la distribución global y la replicación transparente mediante Azure Cosmos DB. Azure Cosmos DB proporciona dos opciones para controlar las escrituras en conflicto. Elija la mejor opción para la carga de trabajo.

• Proporciona funcionalidades de restauración a un momento dado (PITR) para muchos servicios de datos PaaS.

• Mitiga el agotamiento de puertos a través de Azure NAT Gateway o Azure Firewall.

Facilitación de Azure específica de DNS

• Para escenarios de resolución de nombres internos, use zonas privadas de Azure DNS, que tienen redundancia de zona integrada y redundancia geográfica. Para más información, consulte Resistencia de la zona privada de Azure DNS.

• Para escenarios de resolución de nombres externos, use zonas públicas de Azure DNS, que tienen redundancia de zona integrada y redundancia geográfica.

• Los servicios dns de Azure públicos y privados son servicios globales que son resistentes a interrupciones regionales porque los datos de zona están disponibles globalmente.

• Para escenarios de resolución de nombres híbridos entre entornos locales y en la nube, use la resolución privada de Azure DNS. Este servicio admite redundancia de zona si la carga de trabajo se encuentra en una región que admite zonas de disponibilidad. Una interrupción de toda la zona no requiere ninguna acción durante la recuperación de zona. El servicio se recupera automáticamente y se reequilibrada para aprovechar las ventajas de la zona correcta. Para más información, consulte Resistencia en la resolución privada de Azure DNS.

• Para eliminar un único punto de error y lograr una resolución de nombres híbridas más resistente entre regiones, implemente dos o más solucionadores privados de Azure DNS en distintas regiones. La conmutación por error de DNS, en un escenario de reenvío condicional, se logra mediante la asignación de una resolución como servidor DNS principal. Asigne el otro solucionador en otra región como servidor DNS secundario. Para más información, consulte Configuración de la conmutación por error de DNS mediante solucionadores privados.

Aplicación de la protección de eliminación para conservar la redundancia

La redundancia solo ayuda si los componentes que lo proporcionan permanecen en su lugar. La eliminación accidental de un almacén de datos, una zona DNS o una capa de enrutamiento de tráfico afecta la resiliencia y obliga a realizar acciones de recuperación completas. Reduzca el radio de explosión de errores humanos aplicando bloqueos de recursos de Azure CanNotDelete.

Dilema: La aplicación de bloqueos ralentiza las acciones legítimas de recuperación y puede crear fricción operativa. Los bloqueos impiden la eliminación de recursos, no los cambios ni los datos dentro del recurso. Trate los bloqueos como una red de seguridad delgada que complementa, nunca reemplaza, copia de seguridad, replicación y gobernanza de acceso.

Example

Para obtener un ejemplo de una implementación con redundancia de varias regiones, consulte Aplicación web con redundancia de zona de alta disponibilidad de línea base.

En el diagrama siguiente se muestra otro ejemplo.

Vínculos relacionados

Para más información sobre la redundancia, consulte los siguientes recursos:

• Guía de regiones de Azure
• Redundancia de Azure Storage
• Almacenamiento con redundancia de zona
• Replicación geográfica activa de SQL Database
• Configuración de la replicación entre dos instancias administradas

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.