Disponibilidad (confiabilidad) y recuperación ante desastres (DR) en el núcleo virtual de Azure Cosmos DB for MongoDB: entre bambalinas
SE APLICA A: 
núcleo virtual de MongoDB
En este artículo se describen los elementos internos de alta disponibilidad (HA) y recuperación ante desastres entre regiones (DR) para un núcleo virtual de Azure Cosmos DB for MongoDB, que describen el diseño y las funcionalidades de estas características. Proporciona información sobre la planificación eficaz de la estrategia en la región y entre regiones para garantizar la confiabilidad y la continuidad empresarial.
Anatomía del clúster de núcleo virtual de Azure Cosmos DB for MongoDB
Un clúster de núcleo virtual de Azure Cosmos DB for MongoDB consiste en una o varias particiones físicas (nodos). Cada partición física incluye un nodo de ejecución dedicado y un almacenamiento SSD prémium remoto. Los recursos de proceso y almacenamiento de una partición física son exclusivos de una base de datos única y no se comparten entre clústeres o bases de datos.
En clústeres con varias particiones, cada partición tiene una configuración de proceso y almacenamiento idénticas. Independientemente del número de particiones, todos los recursos del clúster se hospedan en la misma región de Azure.
El núcleo virtual de Azure Cosmos DB for MongoDB usa almacenamiento con redundancia local (LRS), lo que garantiza que todos los datos se repliquen de forma sincrónica tres veces dentro de la ubicación física del clúster. Azure Storage administra estas réplicas de forma transparente, comprueba la integridad de los datos mediante comprobaciones de redundancia cíclica (CRC) y repara los daños detectados mediante datos redundantes. Además, las sumas de comprobación se aplican al tráfico de red para evitar datos dañados durante el almacenamiento y la recuperación.
Figura 1. Componentes del clúster de núcleo virtual de Azure Cosmos DB for MongoDB.
Tanto si la aplicación se conecta a una sola partición como a un clúster de varias particiones, usa una sola cadena de conexión y un punto de conexión. Esta abstracción simplifica las operaciones de base de datos distribuidas, lo que facilita la conexión a una configuración de varias particiones, así como a una base de datos de MongoDB independiente.
Alta disponibilidad en la región
En el caso de las cargas de trabajo de producción, se recomienda encarecidamente habilitar alta disponibilidad en la región para cumplir los estándares de confiabilidad modernos. Aunque la alta disponibilidad se puede deshabilitar para el desarrollo o los clústeres experimentales para reducir los costes, es fundamental para mantener la disponibilidad de la base de datos en producción.
La alta disponibilidad se puede alternar durante el aprovisionamiento del clúster o en cualquier momento después de crear el clúster. Está disponible en todas las regiones de Azure que admiten el núcleo virtual de Azure Cosmos DB for MongoDB, independientemente de las funcionalidades regionales específicas.
Cuando la alta disponibilidad está habilitada, cada partición física principal del clúster se empareja con una partición en espera. La partición en espera refleja la configuración de proceso y almacenamiento de su equivalente principal. Esto da como resultado seis réplicas de datos por partición, tres en la partición principal y tres en espera. En regiones con zonas de disponibilidad (AZ), las particiones principales y en espera se implementan en zonas independientes.
Los datos se replican sincrónicamente entre cada partición principal y en espera. Las escrituras solo se reconocen después de confirmarse correctamente en ambas particiones, lo que garantiza una fuerte coherencia en el clúster de alta disponibilidad. En otras palabras, una partición física en espera es una réplica completa siempre actualizada de su partición física principal que proporciona una fuerte coherencia dentro del clúster de alta disponibilidad.
Figura 2. Clúster de núcleo virtual de Azure Cosmos DB for MongoDB con y sin alta disponibilidad en la región habilitada.
En caso de error de partición principal, el servicio realiza automáticamente una conmutación por error a su partición en espera. Durante la conmutación por error, todas las solicitudes de lectura y escritura se redirigen a la partición en espera, que se convierte en la nueva principal. Las operaciones de escritura en curso durante la conmutación por error se reintentan dentro del servicio para garantizar la continuidad. A continuación, se crea una partición de reemplazo para volver a establecer la replicación sincrónica, que se convierte en la nueva en espera.
Replicación entre regiones: recuperación ante desastres regional (DR)
Aunque son raras, las interrupciones regionales pueden interrumpir el acceso a la base de datos. La replicación entre regiones proporciona una estrategia sólida de recuperación ante desastres (DR), lo que garantiza el acceso a los datos incluso durante interrupciones a gran escala.
Con la replicación entre regiones, puede crear un clúster de réplicas en otra región de Azure. Cada partición del clúster de réplica replica de forma asincrónica los datos de su equivalente del clúster principal. Este modelo de replicación garantiza una coherencia final al tiempo que minimiza el impacto en el rendimiento en el clúster principal.
La replicación asincrónica evita la necesidad de que las réplicas entreguen y confirmen inmediatamente cada operación de escritura antes de que se devuelva una confirmación de "escritura completa" a la aplicación. Sin embargo, esto significa que es posible que algunas escrituras completadas en el clúster principal aún no se repliquen en el clúster de réplica, lo que da lugar a retrasos de replicación. La extensión del retraso de replicación depende de la intensidad de las operaciones de escritura en el clúster principal y de la carga general en los clústeres principal y de réplica.
En esta configuración:
- El clúster principal de la región A controla todas las lecturas y escrituras.
- El clúster de réplicas de la región B admite el acceso de solo lectura, lo que permite operaciones de lectura de alto rendimiento más cercanas a aplicaciones o usuarios de esa región.
Las aplicaciones pueden realizar consultas OLTP en el clúster principal de la región A y operaciones de lectura intensas, como consultas OLAP o de informes, se pueden apuntar al clúster de réplicas de la región B.
Las aplicaciones pueden usar un cadena de conexión global de lectura y escritura dinámica, que siempre apunta al clúster abierto para escrituras. Durante una interrupción regional, el clúster de réplicas de la región B se puede promover para aceptar escrituras. La cadena de conexión global se actualiza automáticamente para que apunte al clúster promocionado, lo que garantiza operaciones de escritura ininterrumpidas.
Figura 3. Recuperación ante desastres regional (DR) con un clúster de núcleo virtual de Azure Cosmos DB for MongoDB con la replicación entre regiones habilitada. El clúster de la región B se promueve para convertirse en el nuevo clúster de lectura y escritura. El clúster de la región A se convierte en un clúster de réplica.
Resumen de la disponibilidad en la región y las funcionalidades de recuperación ante desastres entre regiones
En la tabla siguiente se resumen las consideraciones principales para habilitar y administrar la alta disponibilidad en la región y la estrategia de recuperación ante desastres entre regiones.
| Escenario | Característica de núcleo virtual de Azure Cosmos DB for MongoDB | No se produce pérdida de datos | Protección frente a interrupciones en toda la región | Conmutación por error automática | Sin cambio de cadena de conexión |
|---|---|---|---|---|---|
| Error de partición física | Alta disponibilidad en la región | ✔️ | ❌ | ✔️ | ✔️ |
| Interrupción regional | Clúster de replicación entre regiones | ❌ | ✔️ | ❌ | ✔️† |
† Cuando se usa la cadena de conexión global de lectura y escritura.
Contenido relacionado
- Más información sobre la alta disponibilidad en la región en el núcleo virtual de Azure Cosmos DB for MongoDB
- Obtenga información sobre la replicación entre regiones y la recuperación ante desastres entre regiones
- Obtenga más información sobre la confiabilidad en núcleo virtual de Azure Cosmos DB for MongoDB