Confiabilidad en Azure DocumentDB

Azure DocumentDB es un servicio de base de datos NoSQL totalmente administrado para el desarrollo de aplicaciones moderno con compatibilidad con MongoDB. Azure DocumentDB admite una configuración de alta disponibilidad (HA) con réplicas de reserva activa replicadas de forma sincrónica y redundancia de zona. También proporciona una réplica de lectura opcional en otra región de Azure y copias de seguridad automáticas con retención a un momento dado para protegerse frente a la pérdida accidental de datos.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure DocumentDB sea resistente a varias posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad, interrupciones de región y mantenimiento del servicio. También describe el comportamiento de copia de seguridad y proporciona información clave sobre la alta disponibilidad y la replicación entre regiones.

Recomendaciones de implementación de producción para la confiabilidad

Para obtener una lista de recomendaciones para mejorar la confiabilidad del clúster, consulte Procedimientos recomendados para alta disponibilidad (HA) y replicación entre regiones en Azure DocumentDB.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

El recurso principal que implementa es un clúster de Azure DocumentDB. Para cada clúster, elija un nivel de proceso y configure el almacenamiento. El nivel seleccionado determina las funcionalidades disponibles para las características de confiabilidad, como la alta disponibilidad (HA), y también afecta a la forma en que planea la capacidad para escenarios de resistencia.

Las aplicaciones se conectan a un clúster mediante cadenas de conexión y puntos de conexión. Azure DocumentDB proporciona puntos de conexión para operaciones de lectura y escritura y, cuando se configuran, puntos de conexión para clústeres de réplica de lectura. Estos puntos de conexión permiten a la aplicación seguir usando patrones de conexión estables mientras el servicio administra el comportamiento de conmutación por error en segundo plano.

Dentro de cada clúster, los datos se organizan como bases de datos, colecciones y documentos. Este modelo de datos compatible con MongoDB es la base para las decisiones de diseño de nivel de carga de trabajo, como la estrategia de particionamiento, los patrones de lectura y escritura, y el ámbito de copia de seguridad y restauración.

Arquitectura física

Azure DocumentDB ejecuta el clúster en particiones, que representan nodos (máquinas virtuales) que ejecutan el servicio. Puede desplegar una partición o escalar horizontalmente a varias particiones. La implementación de múltiples fragmentos mejora la capacidad de escalabilidad, pero por sí sola no proporciona alta disponibilidad (HA).

Cuando habilita HA, Azure DocumentDB aprovisiona un conjunto correspondiente de particiones en espera. Cada fragmento principal tiene un fragmento de reserva. El servicio replica los datos de forma sincrónica entre cada par primario-en espera y promueve el fragmento en espera si el fragmento primario falla. Para obtener más información sobre la alta disponibilidad, consulte Alta disponibilidad en Azure DocumentDB.

Azure DocumentDB usa Azure Storage para la durabilidad de las particiones. Si HA está desactivada, cada shard utiliza almacenamiento con redundancia local (LRS). LRS mantiene tres copias de los datos, pero no es resistente a la pérdida de una zona de disponibilidad. Para más información sobre la durabilidad de LRS, consulte Resumen de las opciones de redundancia.

Para obtener más información, consulte Disponibilidad y recuperación ante desastres (DR) en Azure DocumentDB: En segundo plano.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para más información, vea Recomendaciones para gestionar errores temporales.

Azure DocumentDB es compatible con el protocolo MongoDB, por lo que las aplicaciones normalmente se conectan mediante controladores de MongoDB. Usted es responsable de configurar los ajustes de reintento del controlador de su aplicación para gestionar fallos transitorios, especialmente las interrupciones de conexión y las interrupciones breves de escritura durante la conmutación por error. Siga estas directrices.

  • Use controladores de MongoDB que admiten el control automático de reintentos para errores de conectividad transitorios.

  • Configure los reintentos con retroceso exponencial y limite el número de intentos de reintento.

  • Cuando sea posible, diseñe las operaciones de escritura para que sean idempotentes, de modo que volver a intentarlas sea seguro. Para obtener orientación general sobre la idempotencia, consulte el patrón de consumidor idempotente.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Para usar la compatibilidad con zonas de disponibilidad en Azure DocumentDB, habilite la alta disponibilidad (HA). Al habilitar la alta disponibilidad en una región que admite zonas de disponibilidad, el clúster pasa a ser con redundancia de zona porque Azure DocumentDB coloca los fragmentos en espera en una zona de disponibilidad distinta de la de sus fragmentos principales. Las particiones en espera no reciben solicitudes de cliente a menos que se produzca un error en la partición principal.

Si deshabilita la alta disponibilidad, Azure DocumentDB no coloca particiones en espera en otra zona de disponibilidad, por lo que un error de zona de disponibilidad puede hacer que el clúster no esté disponible.

Diagrama de un clúster de Azure DocumentDB con redundancia de zona, con fragmentos primarios y en espera en zonas de disponibilidad distintas.

Requisitos

  • Compatibilidad con regiones: Para usar zonas de disponibilidad con Azure DocumentDB, elija una región que admita tanto Azure DocumentDB como zonas de disponibilidad. Compruebe los productos disponibles por región y compárelo con las regiones que admiten zonas de disponibilidad.

  • Alta disponibilidad: Debe habilitar la alta disponibilidad en el clúster. HA requiere que el clúster use el nivel de cómputo M30 (o superior).

Consideraciones

Aunque algunas API de Azure DocumentDB incluyen referencias a modos de implementación en la misma zona, Azure DocumentDB no admite implementaciones de HA en la misma zona. El servicio admite implementaciones de alta disponibilidad con redundancia de zona.

Distribución de instancias a través de zonas

Microsoft selecciona dos zonas de disponibilidad para el clúster. En las implementaciones de alta disponibilidad con redundancia de zona, Azure DocumentDB coloca todas las particiones principales en una zona y todas las particiones en espera en la otra zona.

Costo

Cuando la alta disponibilidad está habilitada, Azure DocumentDB aprovisiona una partición en espera para cada partición principal, lo que aumenta el costo de proceso y almacenamiento del clúster. En las regiones que admiten zonas de disponibilidad, la alta disponibilidad también hace que el clúster sea redundante entre zonas. En algunos modos de implementación, Azure DocumentDB habilita la alta disponibilidad de forma predeterminada. Para las cargas de trabajo de producción, mantenga activada la alta disponibilidad. En el caso de las cargas de trabajo de desarrollo y prueba, puede deshabilitar la alta disponibilidad para reducir el costo. Para obtener más información sobre los precios, consulte precios de Azure DocumentDB.

Configurar soporte de zonas de disponibilidad

  • Cree un nuevo clúster de Azure DocumentDB con redundancia entre zonas: Al crear un clúster en una región que admita zonas de disponibilidad, habilite la alta disponibilidad (HA) para que el clúster tenga redundancia entre zonas. Para ver los pasos detallados, consulte Inicio rápido: Creación de un clúster de DocumentDB de Azure mediante el portal de Azure.

  • Habilite la redundancia de zona en un clúster existente de Azure DocumentDB: Puede habilitar la alta disponibilidad en un clúster existente. No hay tiempo de inactividad de la base de datos cuando la alta disponibilidad está habilitada o deshabilitada en un clúster de Azure DocumentDB. Para obtener pasos detallados, consulte Escalado de un clúster de DocumentDB de Azure.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar al configurar un clúster de DocumentDB de Azure para alta disponibilidad en una región que admita zonas de disponibilidad y todas las zonas están operativas.

  • Operación entre zonas: Las particiones principales sirven a todas las solicitudes de cliente. Las particiones en espera en una zona de disponibilidad diferente no reciben solicitudes de cliente a menos que se produzca un error en la principal.

  • Replicación de datos entre zonas: La replicación entre particiones principales y en espera es sincrónica. Las escrituras se conservan en particiones principales y en espera antes de que el servicio devuelva una respuesta.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar al configurar un clúster de Azure DocumentDB para alta disponibilidad en una región que admita zonas de disponibilidad y hay una interrupción en una de las zonas.

  • Detección y respuesta: Microsoft supervisa el estado de las particiones y se encarga de las operaciones de detección y conmutación por error por usted. Si una partición principal deja de estar disponible debido a una interrupción de zona, Azure DocumentDB promueve automáticamente la partición en espera y, a continuación, vuelve a generar redundancia mediante la creación de una nueva partición en espera.

  • Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

  • Solicitudes activas: Las solicitudes en curso que no se confirmaron antes de la conmutación por error pueden fallar y el cliente debe reintentarlas. Si la aplicación controla errores transitorios, estos reintentos normalmente se completan automáticamente.

  • Pérdida de datos esperada: Azure DocumentDB replica los datos de forma sincrónica entre las particiones principal y en espera, por lo que no se espera ninguna pérdida de datos.

  • Tiempo de inactividad esperado: No se espera ningún tiempo de inactividad para las operaciones de lectura. En el caso de las operaciones de escritura, se puede producir una breve interrupción mientras se completa la conmutación por error. Si su aplicación reintenta correctamente las operaciones tras producirse fallos transitorios, esto suele manifestarse como una breve ralentización.

  • Redistribución: El cadena de conexión no cambia, por lo que los clientes siguen usando el mismo punto de conexión. El servicio redirige automáticamente el tráfico a particiones en espera promocionadas y vuelve a generar nuevas particiones en espera.

Recuperación de zona

Cuando se recupera la zona de disponibilidad, Azure DocumentDB restaura automáticamente las operaciones normales en todas las zonas usadas por el clúster.

Prueba de fallos de zona

La plataforma Azure DocumentDB administra el enrutamiento del tráfico, la conmutación por error y la recuperación de zona para clústeres con redundancia de zona. No es necesario que inicie ni valide los procesos de fallo de las zonas de disponibilidad.

Resistencia a errores en toda la región

Cada clúster de DocumentDB de Azure se implementa en una sola región de Azure. Para garantizar la resiliencia ante fallos de una región, configure la replicación entre regiones añadiendo un clúster de réplica en otra región.

Replicación entre regiones

Azure DocumentDB admite la replicación entre regiones a través de un clúster de réplicas. El clúster de réplica aparece como un clúster independiente en el grupo de recursos. Puede usar este clúster réplica para la recuperación ante desastres y escalar las lecturas. Azure DocumentDB replica automáticamente y de forma asincrónica los cambios de datos del clúster principal en el clúster de réplica.

Diagrama de replicación asincrónica desde un clúster principal de Azure DocumentDB a un clúster de réplica de lectura en otra región.

Si se produce un error en la región primaria, se puede promover el clúster de réplica para convertirse en el clúster de lectura y escritura. La cadena de conexión global de lectura y escritura se actualiza automáticamente para apuntar al clúster ascendido.

Diagrama de una réplica promocionada de Azure DocumentDB que gestiona el tráfico después de que falle la región primaria.

En esta sección se resumen las consideraciones de confiabilidad para la replicación entre regiones. Para obtener más información, consulte Administración de la replicación entre regiones y en la misma región en el clúster de Azure DocumentDB y Prácticas recomendadas para la replicación entre regiones y en la misma región en Azure DocumentDB.

Conmutación por error entre regiones

Azure DocumentDB admite tres modos de promoción:

  • Promoción forzada: Promueve inmediatamente el clúster de réplicas para aceptar operaciones de escritura y redirige el tráfico de escritura entrante a la cadena de conexión global de lectura y escritura. Este modo minimiza el tiempo de inactividad, pero puede provocar la pérdida de datos porque pierde las escrituras no replicadas.

  • Conmutación por error administrada por el servicio: Puede configurar el clúster para que use la conmutación por error administrada por el servicio. Microsoft supervisa el clúster principal e inicia automáticamente una promoción forzada si el clúster principal no está en buen estado.

  • Promoción ordenada: Evita la pérdida de datos, pero requiere cierto tiempo de inactividad mientras se replican las operaciones de escritura no replicadas. La promoción ordenada requiere que ambos clústeres estén en buen estado, por lo que no se puede realizar durante una interrupción del servicio en la región.

Para obtener más información, consulte Modos de conmutación por error entre regiones en Azure DocumentDB.

Requisitos

  • Compatibilidad con regiones: Puede usar la replicación entre regiones en todas las regiones de Azure que admiten Azure DocumentDB.

  • Nivel de proceso: La replicación entre regiones requiere el nivel de proceso M30 o superior.

Consideraciones

  • Acceso a la red: Los clústeres de réplica no heredan la configuración de red del clúster principal. Configure las reglas del firewall o los puntos de conexión privados por separado en el clúster de réplica, y pruebe la conectividad antes de una conmutación por error. Para más información, consulte Escrituras continuas, operaciones de lectura en réplicas de clúster y cadenas de conexión.

  • Compatibilidad de funciones: Los clústeres de réplica no admiten la recuperación a un momento dado (PITR) ni la alta disponibilidad dentro de la región.

    Si la alta disponibilidad está habilitada en el clúster principal, es responsable de volver a habilitar la alta disponibilidad en el clúster promocionado.

    Para obtener más información, consulte límites y cuotas del servicio Azure DocumentDB.

Costo

La replicación entre regiones agrega costos para los recursos de proceso y almacenamiento del clúster de réplica. También se aplican cargos por transferencia de datos entre regiones. Para obtener detalles sobre los precios, consulte Precios de Azure DocumentDB y Precios del ancho de banda.

Configuración de la compatibilidad con varias regiones

  • Cree un clúster de réplica: Para habilitar la replicación entre regiones, cree un clúster de réplica desde el clúster principal. Puede crear un clúster de réplica al crear el clúster principal o después. Para conocer los pasos, consulte Administración de la replicación entre regiones y la misma región en el clúster de DocumentDB de Azure.

  • Configure la conmutación automática por error: Si desea que Azure promueva automáticamente la réplica en caso de interrupciones en la región primaria, habilite la conmutación por error administrada por el servicio. Para obtener más información, consulte Habilitación de la conmutación por error administrada por el servicio.

    Note

    Microsoft suele activar la conmutación por error gestionada por el servicio solo en casos extremos, como la caída de toda una región o un gran número de clientes afectados. Puede haber un retraso antes de que se desencadene la conmutación por error. Si necesita restablecer la disponibilidad rápidamente, le recomendamos que administre el proceso de conmutación por error mediante una promoción forzada iniciada por el cliente.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar al configurar un clúster de DocumentDB de Azure para la replicación entre regiones y todas las regiones están operativas.

  • Operación entre regiones: El clúster principal atiende todo el tráfico de lectura y escritura. El clúster de réplicas gestiona tráfico de solo lectura, que puede utilizar para ampliar horizontalmente las cargas de trabajo de lectura o para mantener el tráfico de lectura dentro de una región específica. La cadena de conexión global de lectura y escritura siempre apunta al clúster actual con capacidad de escritura, por lo que los clientes no necesitan hacer un seguimiento de qué región es la primaria.

  • Replicación de datos entre regiones: La replicación entre el clúster principal y el clúster de réplica es asincrónica. Las escrituras se confirman en el clúster primario y se notifican al cliente antes de replicarse en el clúster réplica. Este enfoque impide que la latencia de red entre regiones afecte al rendimiento de escritura. Dado que la replicación es asincrónica, se espera algún retraso de replicación entre los clústeres de réplica y principal, y se pueden perder las escrituras no replicadas durante una conmutación por error forzada.

Comportamiento durante una falla de región

En esta sección se describe qué esperar al configurar un clúster de DocumentDB de Azure para la replicación entre regiones y hay una interrupción en la región del clúster principal.

  • Detección y respuesta: La responsabilidad de detectar la interrupción y responder depende del tipo de conmutación por error que usa el clúster.

    • Si la conmutación por error administrada por el servicio está habilitada, Azure DocumentDB detecta la interrupción y realiza automáticamente una promoción forzada del clúster de réplicas.
    • Si la conmutación por error administrada por el servicio no está habilitada, eres responsable de detectar la interrupción del servicio y activar una promoción forzada.

    Para obtener más información, consulte Modos de conmutación por error entre regiones en Azure DocumentDB.

  • Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

  • Solicitudes activas: Las solicitudes activas dirigidas a la región primaria fallida podrían fallar. Una vez completada la conmutación por error, las aplicaciones deberían volver a conectarse e intentar el acceso de nuevo al clúster promocionado.

  • Pérdida de datos esperada: Las conmutaciones por error durante fallos regionales no se planifican, por lo que las escrituras no replicadas pueden perderse, ya que la replicación es asíncrona.

  • Tiempo de inactividad esperado: El tiempo de inactividad general depende del tiempo de detección, el modo de conmutación por error y el comportamiento de reconexión del cliente.

    En el caso de la promoción forzada iniciada por el cliente, el tiempo de inactividad total incluye el tiempo necesario para detectar la interrupción e iniciar los procesos de respuesta, así como el tiempo de finalización de la promoción.

    Una vez iniciada una promoción, normalmente se completa en unos minutos.

  • Redistribución: La cadena de conexión global de lectura y escritura apunta automáticamente al clúster promovido después de la promoción. Las aplicaciones que usan cadenas de conexión específicas del clúster pueden requerir actualizaciones de configuración para dirigir el tráfico al clúster en buen estado.

Recuperación de regiones

Azure DocumentDB no vuelve automáticamente a la región original después de que esta se recupere. Para devolver las operaciones de escritura a la región original, realice otra promoción después de restablecer su topología preferida. Utiliza una promoción gradual para evitar la pérdida de datos durante la conmutación de vuelta. Una promoción gradual requiere un breve periodo de inactividad y puedes llevarla a cabo en el momento que elijas, por ejemplo, durante una ventana de mantenimiento. Para obtener más información, consulta Activar una promoción gradual.

Prueba de fallos de región

Pruebe periódicamente el proceso de recuperación ante desastres mediante la promoción del clúster de réplicas en un entorno controlado.

  • Utiliza la promoción forzada para simular el comportamiento ante una interrupción del servicio. Esta prueba puede dar lugar a una pérdida de datos, por lo que considere la posibilidad de ejecutar esta prueba en un entorno de no producción. Para obtener más información, consulte Desencadenar una promoción forzada.

  • Utiliza la promoción gradual para simulacros de conmutación planificados cuando desees evitar la pérdida de datos. Para obtener más información, consulta Activar una promoción gradual.

Copias de seguridad y restauración

La replicación y la compatibilidad con zonas de disponibilidad ayudan a mantener un clúster disponible durante los errores de infraestructura. Azure DocumentDB realiza automáticamente copias de seguridad continuas, que abordan un riesgo diferente al habilitar la recuperación a un momento dado (PITR) después de eliminar o modificar datos accidentalmente. Azure DocumentDB realiza copias de seguridad sin afectar al rendimiento ni a la disponibilidad de las operaciones de base de datos. Para obtener más información sobre cómo la replicación y la copia de seguridad abordan distintos riesgos, consulte Redundancia, replicación y copia de seguridad.

Azure DocumentDB almacena copias de seguridad por separado de los datos de origen. En regiones que admiten zonas de disponibilidad, el servicio almacena instantáneas de copia de seguridad en tres zonas de disponibilidad. Azure DocumentDB administra estas copias de seguridad y no puede exportarlas. El servicio conserva las copias de seguridad durante 35 días para clústeres activos, 7 días para clústeres activos de nivel ampliable (M10, M20, M25) y 7 días para los clústeres eliminados.

Puede restaurar una copia de seguridad en un nuevo clúster. Después de hacerlo, debe realizar un conjunto de tareas posteriores a la restauración.

Para obtener más información, consulte Restauración de un clúster en Azure DocumentDB.

Resistencia al mantenimiento del servicio

Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. No se prevé ningún tiempo de inactividad durante las operaciones de mantenimiento, a menos que se te haya informado a través de el mantenimiento planificado de Azure Service Health.

Los eventos de mantenimiento planeado todavía pueden provocar errores transitorios breves para las operaciones de cliente. La aplicación debe controlar estos eventos mediante la guía de reintento de Resistencia a errores transitorios.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte los SLAs de los servicios en línea.

Para Azure DocumentDB, los Acuerdos de Nivel de Servicio de disponibilidad solo se aplican cuando el clúster tiene habilitada la alta disponibilidad (HA). Los acuerdos de nivel de servicio de disponibilidad diferentes se aplican a las siguientes configuraciones:

  • Clústeres habilitados para alta disponibilidad que abarcan varias regiones de Azure mediante la replicación entre regiones.

  • Clústeres con HA en una sola región.

Contenido relacionado

  • Se actualizó por última vez el