Confiabilidad en Azure Cosmos DB for MongoDB vCore

SE APLICA A: núcleo virtual de MongoDB

Este artículo contiene información detallada sobre la resistencia regional con zonas de disponibilidad y recuperación ante desastres entre regiones y continuidad empresarial para Azure Cosmos DB for MongoDB vCore.

Para obtener información arquitectónica general sobre la fiabilidad de Azure, consulte Fiabilidad de Azure.

Compatibilidad de zonas de disponibilidad

Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.

Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.

Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

Para obtener compatibilidad con zonas de disponibilidad, debe habilitar alta disponibilidad (ALTA DISPONIBILIDAD).

La alta disponibilidad evita el tiempo de inactividad de la base de datos manteniendo las réplicas en espera de todas las particiones de un clúster. Si una extensión deja de funcionar, el núcleo virtual de Azure Cosmos DB for MongoDB cambiará las conexiones entrantes de la extensión fallida a su réplica en espera.

Cuando la alta disponibilidad está habilitada en una región que admite zonas de disponibilidad, las particiones de réplica de alta disponibilidad se aprovisionan en una zona de disponibilidad diferente de sus particiones principales. Las réplicas de alta disponibilidad no reciben solicitudes de los clientes a menos que su extensión principal falle.

Si la alta disponibilidad está deshabilitada, cada partición tiene su propio almacenamiento con redundancia local (LRS) con tres réplicas sincrónicas mantenidas por el servicio Azure Storage. Si hay un error de una sola réplica, el servicio Azure Storage detecta el error y vuelve a crear de forma transparente los datos relevantes. Para obtener durabilidad del almacenamiento LRS, consulte Resumen de las opciones de redundancia. Sin embargo, en el caso de un error de región, se corre el riesgo de un tiempo de inactividad extenso y posible pérdida de datos.

Requisitos previos

Su clúster Azure Cosmos DB for MongoDB vCore debe crearse en las siguientes regiones:

• Este de Australia
• Sudeste de Asia
• Centro de Canadá
• Norte de Europa
• Sur de Reino Unido
• Oeste de Europa
• Centro de EE. UU.
• Este de EE. UU.
• Este de EE. UU. 2
• Centro-sur de EE. UU.
• Oeste de EE. UU. 2

Creación de un recurso con zonas de disponibilidad habilitadas

Para habilitar las zonas de disponibilidad, debe habilitar alta disponibilidad (HA) al Crear un clúster o en la secciónEscalado de un clúster existente en Azure Portal.

Recuperación ante desastres entre regiones y continuidad empresarial

La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.

En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.

El núcleo virtual de Azure Cosmos DB for MongoDB no proporciona conmutación automática por error integrada ni recuperación ante desastres. La planificación de la alta disponibilidad es un paso fundamental a medida que se escala la solución.

Recuperación ante desastres en una sola región geográfica

Para maximizar el tiempo de actividad, planee con antelación la continuidad empresarial y prepare todo lo necesario para la recuperación ante desastres con un núcleo virtual de Azure Cosmos DB for MongoDB.

Aunque los servicios de Azure están diseñados para maximizar el tiempo de actividad, es posible que se produzcan interrupciones de servicio no planeadas. Un plan de recuperación ante desastres garantiza que tiene una estrategia para abordar las interrupciones de servicio en regiones.

El núcleo virtual de Azure Cosmos DB for MongoDB crea automáticamente copias de seguridad de los datos a intervalos regulares. Las copias de seguridad automáticas se crean sin afectar al rendimiento o a la disponibilidad de las operaciones de las bases de datos. Todas las copias de seguridad se realizan de forma automática en segundo plano y se almacenan por separado de los datos de origen en un servicio de almacenamiento. Estas copias de seguridad automáticas son útiles en escenarios en los que se eliminan o modifican recursos de manera accidental y, posteriormente, se necesitan las versiones originales.

Las copias de seguridad automáticas se conservan en varios intervalos en función de si el clúster está activo o se ha eliminado recientemente.

	Período de retención
Clústeres activos	35 días
Clústeres eliminados	7 días

Diseño para lograr alta disponibilidad

La alta disponibilidad (HA) debe estar habilitada para clústeres críticos de núcleo virtual de Azure Cosmos DB for MongoDB que ejecutan cargas de trabajo de producción. En un clúster habilitado para alta disponibilidad, cada partición actúa como principal junto con una partición en espera activa aprovisionada en otra zona de disponibilidad. La replicación entre la partición principal y la secundaria es sincrónica de forma predeterminada. Cualquier modificación de la base de datos se conserva en las particiones principal y secundaria (en espera activa) antes de recibir una respuesta de la base de datos.

El servicio mantiene comprobaciones de estado y latidos en cada partición principal y secundaria del clúster. Si una partición principal deja de estar disponible debido a una interrupción regional o de zona, la partición secundaria se promueve automáticamente para convertirse en la nueva principal y se crea una partición secundaria posterior para la nueva principal. Además, si una partición secundaria deja de estar disponible, el servicio crea automáticamente una nueva partición secundaria con una copia completa de datos de la principal.

Si el servicio desencadena una conmutación por error de la partición principal a la secundaria, las conexiones se enrutan sin problemas en segundo plano a la nueva partición principal.

La replicación sincrónica entre las particiones principal y secundaria garantiza ninguna pérdida de datos si hay una conmutación por error.

Pasos siguientes

• Obtenga más información sobre la compatibilidad de características con MongoDB.
• Revise las opciones para migrar de MongoDB a un núcleo virtual de Azure Cosmos DB for MongoDB.
• Para empezar, cree una cuenta.