Confiabilidad en Azure Cosmos DB

Azure Cosmos DB para NoSQL es un servicio de base de datos multimodelo distribuido globalmente que admite modelos de datos de documentos con esquemas flexibles. Azure Cosmos DB ofrece características de confiabilidad completas, incluidos varios niveles de coherencia que permiten equilibrar el rendimiento y la disponibilidad, las implementaciones con redundancia de zona de disponibilidad que protegen frente a errores de zona de disponibilidad, replicación en varias regiones con conmutación por error administrada por el servicio o administrada por el cliente, y opciones de copia de seguridad continuas y periódicas para la protección 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 Cosmos DB sea resistente a varias posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad, interrupciones de regiones y mantenimiento del servicio. También se describe cómo usar copias de seguridad para recuperarse de otros tipos de problemas y se resalta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Cosmos DB.

Recomendaciones de implementación de producción

Azure Well-Architected Framework proporciona recomendaciones sobre confiabilidad, seguridad, costo, operaciones y rendimiento. Para comprender cómo estas áreas influyen entre sí y contribuir a una solución de Azure Cosmos DB confiable, consulte Procedimientos recomendados para Azure Cosmos DB.

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 implemente es un Azure Cosmos DB account. Cada cuenta puede tener varias bases de datos con varios contenedores. Los contenedores sirven como unidades lógicas de distribución y escalabilidad. Puede crear contenedores como colecciones, tablas y gráficos, en función de la API que use para interactuar con Azure Cosmos DB. Para obtener más información sobre el modelo de recursos, consulte Databases, contenedores y elementos en Azure Cosmos DB. Cada contenedor usa particionamiento, que admite alto rendimiento y alta escalabilidad.

La configuración del rendimiento refleja la cantidad de recursos del sistema que se pueden utilizar para consultar y trabajar con los datos. Puede aprovisionar manualmente el rendimiento, usar la escalabilidad automática para ajustar dinámicamente la capacidad en función de los requisitos de la carga de trabajo o usar el tipo de cuenta sin servidor para que se cobre por el uso real.

Una sola cuenta puede abarcar varias regiones de Azure, lo que aumenta su resiliencia ante interrupciones regionales. Puede configurar varias regiones para leer y, si usa el nivel Crítico para la empresa, puede usar varias regiones para escribir. Azure Cosmos DB replica automáticamente sus datos geográficamente. El comportamiento de la replicación geográfica se ve afectado por la configuración que se usa, como el nivel de coherencia, que indica cómo desea compensar el equilibrio entre la coherencia de los datos, la disponibilidad, la latencia y el rendimiento. Diferentes niveles de coherencia optimizan para diferentes preocupaciones, admiten diferentes garantías y proporcionan diferentes tipos de replicación entre regiones.

Arquitectura física

Azure Cosmos DB almacena varios replicas de los datos para la redundancia. El servicio mitiga automáticamente las interrupciones de réplica al mantener el cuórum entre réplicas de cada región. Este enfoque garantiza la alta disponibilidad y protege contra la pérdida de datos durante errores de nodo individuales, sin necesidad de cambios o configuración de la aplicación.

Internamente, Azure Cosmos DB administra los datos a través de varias construcciones, incluidas las particiones físicas, conjuntos de partición y conjuntos de réplicas. Para obtener información más detallada sobre cómo funciona Azure Cosmos DB, consulte Distribución global de datos con Azure Cosmos DB: a fondo.

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 obtener más información, consulte Recomendaciones para controlar errores transitorios.

Se recomienda usar los SDK de Azure Cosmos DB. Los SDK implementan automáticamente la compatibilidad con una serie de consideraciones de resistencia, incluido el control de errores transitorios a través de reintentos automáticos, y respetan las respuestas de límite de velocidad enviadas por el servicio. Para obtener más información, consulte Design resilient applications with Azure Cosmos DB SDKs.

Al trabajar con una cuenta de varias regiones, el SDK también admite una estrategia de disponibilidad basada en umbrales, también denominada reaseguro, donde se envían solicitudes de lectura en paralelo a varias regiones y se elige la respuesta más rápida. Este enfoque puede mejorar el rendimiento de la aplicación cuando una región experimenta temporalmente una latencia mayor de lo habitual.

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.

Azure Cosmos DB admite redundancia de zona. Al habilitar la redundancia de zona, Azure distribuye las réplicas de los datos en varias zonas de disponibilidad, lo que proporciona resistencia a problemas y interrupciones del centro de datos. Microsoft selecciona las zonas de disponibilidad que se van a usar.

Diagrama que muestra una cuenta de Azure Cosmos DB con un conjunto de réplicas que contiene tres réplicas, que se distribuyen entre tres zonas de disponibilidad independientes.

Una cuenta de Azure Cosmos DB podría usar varias regiones (ubicaciones) para la distribución global, la escalabilidad y la conmutación por error. La redundancia de zona se configura por separado para cada región de la cuenta.

El uso de redundancia de zona en Azure Cosmos DB no tiene ningún impacto perceptible en el rendimiento o la latencia. No requiere ningún ajuste en el modo de coherencia seleccionado y no requiere ninguna modificación en el código de la aplicación.

Se recomienda usar la redundancia de zona en las regiones en las que se admite, especialmente para las cuentas de una sola región. Dado que las zonas de disponibilidad son físicamente independientes y proporcionan una fuente de alimentación, una red y una refrigeración distintas, los acuerdos de nivel de servicio de disponibilidad para Azure Cosmos DB son más altos para las cuentas con redundancia de zona que las cuentas que no usan zonas de disponibilidad.

Sugerencia

Habilitar la redundancia de zona es una excelente manera de aumentar la resistencia de la base de datos de Azure Cosmos DB sin introducir complejidades de aplicación adicionales ni afectar al rendimiento. En función de la configuración de la cuenta, es posible que ni siquiera incurra en costos adicionales.

Si no habilita la redundancia de zona, la cuenta no es zonal en esa región. Las cuentas no zonales podrían localizar réplicas en una sola zona de disponibilidad, lo que provocaría un posible tiempo de inactividad si esa zona específica experimenta un problema.

Requirements

  • Region support: Puede habilitar la redundancia de zona en las regiones de Azure que admiten zonas de disponibilidad. Para ver si la región admite zonas de disponibilidad, consulte la lista de regiones admitidas.

    La redundancia de zona no es una configuración para toda la cuenta. Azure Cosmos DB cuentas pueden abarcar varias regiones y cada región se puede configurar de forma independiente para usar zonas de disponibilidad. Las regiones que no admiten zonas de disponibilidad no le impiden habilitar la redundancia de zona en otras regiones dentro de la misma cuenta.

  • Cuentas sin servidor: Solo puede configurar cuentas sin servidor con redundancia de zona al crearlas. No se pueden convertir cuentas sin servidor existentes sin zonas de disponibilidad a una configuración de zona de disponibilidad. Para cargas de trabajo críticas, se recomienda usar el rendimiento aprovisionado.

Consideraciones

  • Varias interrupciones de zona simultáneas: Una cuenta de una sola región con redundancia de zona puede mantener la disponibilidad de lectura y escritura cuando una interrupción afecta a una sola zona de disponibilidad. Sin embargo, si la interrupción afecta a varias zonas de disponibilidad o a toda la región, las cuentas de una sola región pierden el acceso de lectura y escritura hasta que se restaure el servicio. Considere la posibilidad de implementar una cuenta de varias regiones si necesita ser resistente a varias zonas con errores al mismo tiempo.

  • Cuentas de varias regiones: Si tiene una cuenta de varias regiones, opcionalmente puede habilitar la redundancia de zona en cualquiera o todas las regiones de cuenta que admiten zonas de disponibilidad. Se recomienda encarecidamente habilitar la redundancia de zona cuando la cuenta esté configurada para usar una sola región o si está configurada para usar una sola región de escritura con varias regiones de lectura.

Cost

Las regiones en las que se habilita la redundancia de zona se cobran a un precio superior. Sin embargo, los precios premium de las zonas de disponibilidad se eximen para las cuentas configuradas con escrituras de varias regiones y para las colecciones configuradas para utilizar el modo de rendimiento con escalado automático. Para obtener más información, consulte Precios de Azure Cosmos DB.

Configurar soporte de zonas de disponibilidad

Para la mayoría de las cuentas, solo se habilita la redundancia de zona cuando se agrega una nueva región a una cuenta de Azure Cosmos DB. Para habilitar la compatibilidad con zonas de disponibilidad en una cuenta existente, agregue una región y habilite la redundancia de zona en ella. Puede seguir un proceso para agregar una región temporal para que pueda configurar la redundancia de zona en la región original. Para obtener pasos detallados, consulte Habilitar redundancia de zona en una cuenta de Azure Cosmos DB.

Para las cuentas sin servidor, debe habilitar la redundancia de zona al crear la cuenta.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar al configurar una cuenta de Azure Cosmos DB para la redundancia de zona y todas las zonas están operativas.

  • Operación entre zonas: Azure Cosmos DB enruta automáticamente las solicitudes a las réplicas entre zonas de disponibilidad, por lo que cualquier réplica puede servir una solicitud.

  • Replicación de datos entre zonas: Cuando un cliente realiza un cambio en los datos, ese cambio se aplica a varias réplicas en distintas zonas para lograr el cuórum. Este enfoque se conoce como replicación sincrónica. La replicación sincrónica garantiza un alto nivel de coherencia de datos, lo que reduce la probabilidad de pérdida de datos durante un error de zona. Las zonas de disponibilidad se encuentran relativamente cerca, lo que significa que hay un efecto mínimo en la latencia o el rendimiento.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar al configurar una cuenta de Azure Cosmos DB para la redundancia de zona y hay una interrupción en una de las zonas.

  • Detección y respuesta: La plataforma Azure Cosmos DB es responsable de detectar un error en una zona de disponibilidad. No es necesario hacer nada para iniciar una conmutación por error de la zona.
  • Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También 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.

  • Active requests: Cuando una zona de disponibilidad deja de estar disponible, Azure Cosmos DB finaliza las solicitudes en curso conectadas a las réplicas de la zona afectada y la aplicación debe reintentar esas solicitudes. Asegúrese de que la aplicación está preparada siguiendo las instrucciones de control de errores transitorios.

  • Pérdida de datos esperada: No hay ninguna pérdida de datos esperada de un error de zona.

  • Tiempo de inactividad esperado: Durante las interrupciones de zona, las conexiones pueden experimentar interrupciones breves que suelen durar unos segundos a medida que se redistribuye el tráfico. Asegúrese de que las aplicaciones están preparadas siguiendo las instrucciones de control de errores transitorios.

  • Redistribution: Azure Cosmos DB redirige automáticamente las solicitudes entrantes a réplicas saludables en otras zonas de disponibilidad. Cuando una zona de disponibilidad tiene una interrupción, la plataforma reasigna automáticamente el rendimiento aprovisionado a otras réplicas.

Recuperación de zona

Cuando se recupera la zona de disponibilidad, Azure Cosmos DB restaura automáticamente las réplicas en la zona de disponibilidad y vuelve a enrutar el tráfico entre réplicas como normal.

Prueba de fallos de zona

La conmutación por error y la recuperación de la zona de disponibilidad para Azure Cosmos DB están totalmente administradas por Microsoft. No es necesario iniciar ni validar los procesos de fallo de las zonas de disponibilidad.

Resistencia a errores en toda la región

Al implementar una cuenta de Azure Cosmos DB en una sola región, una interrupción en toda la región que afecta a todos los nodos de Azure Cosmos DB normalmente no causa pérdida de datos, pero impide que la aplicación acceda a los datos. Azure Cosmos DB restaura el acceso a los datos después de que el servicio se recupere en la región afectada. La pérdida de datos solo se produce si la región experimenta un desastre irrecuperable.

Para prepararse para los casos excepcionales de interrupciones de regiones, puede configurar Azure Cosmos DB para admitir varios niveles de durabilidad y disponibilidad mediante uno de estos enfoques:

En la tabla siguiente se resumen las opciones de recuperación disponibles en función de la configuración de la cuenta y el tipo de interrupción. En las secciones posteriores de este artículo se proporcionan detalles exhaustivos de estas opciones y el comportamiento asociado.

Configuration Tipo de interrupción Impacto en la disponibilidad Impacto de durabilidad Qué hacer
Cuenta de una sola región Interrupción regional Se pierde el acceso de lectura y escritura hasta que se restaura el servicio. No se pierden datos a menos que la región experimente un desastre irrecuperable. Espere a que se restaure el servicio o solicite la restauración de la cuenta de copia de seguridad en otra región.
Región de escritura única, cuenta de varias regiones Interrupción de la región de lectura El SDK redirige a las regiones disponibles según la configuración de regiones preferidas.

En el caso de las cuentas que usan coherencia fuerte con solo dos regiones o obsolescencia limitada que supere la ventana de obsolescencia, la disponibilidad de escritura también se pierde a menos que se desconecte la región afectada.		 No se produce pérdida de datos. Asegúrese de que el rendimiento es suficiente en las regiones restantes. Para una coherencia de obsolescencia fuerte o limitada, considere la posibilidad de desconectar la región afectada.
Región de escritura única, cuenta de varias regiones Interrupción de la región de escritura (con PPAF habilitado) Conmutación automática por error de nivel de partición; no se requiere intervención manual. Si la cuenta usa una coherencia fuerte, no se pierden datos. Si la cuenta no usa una coherencia fuerte, los datos no replicados podrían perderse en el improbable caso de que la región sufra una pérdida de datos permanente. No es necesaria ninguna acción. PPAF administra automáticamente la conmutación por error.
Región de escritura única, cuenta de varias regiones Interrupción de la región de escritura de datos (sin PPAF) La disponibilidad de escritura se pierde hasta que se completa una operación de región sin conexión o una conmutación por error gestionada por el servicio. Las lecturas continúan desde regiones saludables. Si la cuenta usa una coherencia fuerte, no se pierden datos. Si la cuenta no usa una coherencia fuerte, los datos no replicados podrían perderse en el improbable caso de que la región sufra una pérdida de datos permanente. Realice una operación de desconexión de la región. Si la conmutación por error administrada por el servicio está habilitada, Azure Cosmos DB inicia automáticamente la conmutación por error, pero esto puede tardar una hora o más. No cambie la región de escritura durante la interrupción.
Cuenta de región de escritura múltiple Interrupción en cualquier región Enrutamiento automático a regiones correctas a través de la configuración del SDK; no se requiere intervención manual. Los datos actualizados recientemente en la región con errores podrían no estar disponibles en las regiones restantes. En el improbable caso de que la región sufre una pérdida permanente de datos, se podrían perder datos no replicados. Asegúrese de que el rendimiento es suficiente en las regiones restantes. Después de la recuperación, Azure Cosmos DB recupera automáticamente los datos no replicados mediante el método de resolución de conflictos configurado.
Cualquier configuración de cuenta Datos dañados o eliminación accidental Sin impacto en la disponibilidad. Posible pérdida de datos en función de cuándo se detectan daños o eliminaciones. Restauración a un momento dado (copia de seguridad continua) o restauración a partir de una copia de seguridad periódica.

Nota:

Este artículo se centra en los aspectos de confiabilidad de las características de varias regiones de Azure Cosmos DB. Hay otras ventajas para varias regiones de lectura y escritura, como un mayor rendimiento y escalado para aplicaciones distribuidas globalmente. Debe evaluar toda la arquitectura de la solución y tener en cuenta todas las ventajas de usar estas funcionalidades.

SDK y resiliencia

Los SDK de Azure Cosmos DB son una parte importante de la estrategia de resistencia de la aplicación. Cuando tiene una cuenta de varias regiones, la configuración del SDK afecta a cómo se enrutan las solicitudes entre regiones, incluidas las regiones preferidas a las que conectarse y las regiones a las que se debe excluir. Los SDK supervisan la disponibilidad de regiones y particiones, y pueden reconfigurarse dinámicamente para utilizar regiones y particiones saludables, como a través del disyuntor a nivel de partición.

Para obtener más información sobre cómo el SDK admite la alta disponibilidad, consulte la documentación de alta disponibilidad para el SDK que usa:

Posible pérdida de datos durante fallos regionales

Al implementar una cuenta de Azure Cosmos DB en varias regiones, la durabilidad de los datos depende del nivel de coherencia que configure en la cuenta. En la tabla siguiente se detallan todos los niveles de coherencia, el objetivo de punto de recuperación (RPO) de una cuenta de Azure Cosmos DB que se implementa en al menos dos regiones. El RPO representa la posible pérdida de datos durante una interrupción de la región.

Nivel de coherencia RPO para la interrupción de la región
Sesión, prefijo coherente, eventual Menos de 15 minutos
Uso vinculado K y T
Alta 0

K = el número de versiones (es decir, actualizaciones) de un elemento.

T = intervalo de tiempo desde la última actualización.

En el caso de cuentas de varias regiones, el valor mínimo de K y T es de 100 000 operaciones de escritura o de 300 segundos. Este valor define el RPO mínimo para los datos cuando se utiliza la obsolescencia limitada.

Para obtener más información sobre las diferencias entre los niveles de coherencia, consulte Niveles de coherencia en Azure Cosmos DB.

Varias regiones de lectura con una sola región de escritura

Si la solución requiere un tiempo de actividad continuo durante las interrupciones de la región, puede configurar Azure Cosmos DB para replicar los datos en varias regiones, con escrituras controladas por la región primaria. Opcionalmente, puede configurar las aplicaciones para conectarse a regiones de lectura específicas, lo que puede ayudar a mejorar su rendimiento. Si una región tiene una interrupción, la cuenta puede seguir funcionando desde regiones correctas.

Diagrama que muestra una cuenta de Azure Cosmos DB. La región A es una región de lectura y escritura, y la región B es una región de lectura. Una aplicación de la región A realiza lecturas y escrituras en la cuenta de Azure Cosmos DB en la región A. Una aplicación de la región B realiza lecturas en la cuenta de la región B, pero escribe en la región A. Internamente, Azure Cosmos DB replica los cambios entre las regiones.

Conmutación por error entre regiones

Puede configurar el SDK de Azure Cosmos DB con una lista prioritaria de regiones de lectura. El SDK conecta la aplicación a la primera región disponible de la lista. Durante una interrupción de la región de lectura, el SDK detecta la interrupción de la región a través de códigos de respuesta de back-end, la marca como no disponible y enruta las operaciones futuras a la siguiente región disponible en la lista de preferencias. Asegúrese de que la lista de regiones preferidas se ha establecido correctamente y se alinea con los requisitos de negocio y latencia. Para obtener instrucciones detalladas, consulte Solución de problemas de disponibilidad del SDK de Azure Cosmos DB.

La conmutación por error es el proceso de hacer que una de las regiones de su cuenta no esté disponible, ya sea completamente o en parte. El efecto de una conmutación por error depende de si la región es una región de escritura o una región de lectura:

  • Si una región de escritura deja de estar disponible, otra región se convierte en la región de escritura.
  • Si una región de lectura deja de estar disponible, esa región no puede atender solicitudes de lectura y otras regiones se usan en su lugar para las operaciones de lectura.

Azure Cosmos DB proporciona varios tipos de conmutación por error:

  • Conmutación por error automática por partición (PPAF): Internamente, Azure Cosmos DB distribuye los datos entre varias particiones físicas. Si se produce un problema con la infraestructura que admite una partición, es posible que otras particiones no se vean afectadas. PPAF permite a las cuentas con una sola región de escritura conmutar automáticamente por error particiones individuales a una región secundaria mientras mantiene las particiones sanas en la región primaria. PPAF puede ayudar a minimizar el tiempo de inactividad y a permitir una recuperación más rápida durante un error de región parcial. Para obtener más información, consulte Cómo adoptar Per-Partition Automatic Failover (PPAF) para Azure Cosmos DB.

    Nota:

    La conmutación por error automática por partición está en versión de vista previa pública. Esta característica se proporciona sin un Acuerdo de Nivel de Servicio. Para más información, consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.

  • Conmutación por error forzada: Puede desconectar una región de su cuenta. Esto también se conoce como conmutación por falla administrada por el cliente, o una operación de región sin conexión. Este es el enfoque recomendado para restaurar rápidamente la disponibilidad durante una interrupción. Usted es responsable de detectar la interrupción y desencadenar la conmutación por error. También puede usar conmutaciones por error forzadas para simular escenarios de región descendente para pruebas, como durante un simulacro de recuperación ante desastres.

    Si desconecta la región de escritura, la región de lectura con la siguiente prioridad más alta se convierte en la nueva región de escritura. Si deja sin conexión una región de lectura, las aplicaciones pueden conectarse a cualquier otra región de lectura de la cuenta.

    Una conmutación por error forzada de la región de escritura conlleva la posibilidad de pérdida de datos para las escrituras no replicadas.

    Después de una conmutación por error forzada, Microsoft debe restablecer la región en línea. Para regiones saludables, este proceso está automatizado, pero puede tardar varios días. Si la región no vuelve a estar en línea en un día o dos, abra un caso de soporte técnico para solicitar asistencia.

  • Cambiar la región de escritura: Cuando las regiones estén en buen estado, puede cambiar la región de escritura de la cuenta. Este cambio es efectivamente una conmutación por error planeada de la región de escritura de la cuenta.

    Cambiar la región de escritura no produce ninguna pérdida de datos, ya que la replicación de datos se recupera antes de que se promueva la nueva región de escritura. Puede haber una breve interrupción, pero los clientes que usan lógica de reintento y otras técnicas de control de errores transitorios no suelen experimentar un impacto significativo.

    Esta operación requiere que las regiones estén en buen estado, por lo que no se puede usar durante una interrupción de la región.

  • Conmutación por error administrada por el servicio: Cuando la cuenta usa la conmutación por error administrada por el servicio, Microsoft es responsable de decidir cuándo realizar la conmutación por error entre regiones. Para habilitar la conmutación por error administrada por el servicio, especifique prioridades para cada región. Sin embargo, el proceso de declarar una interrupción y desencadenar la conmutación por error gestionada por el servicio puede llevar un tiempo considerable, incluso una hora o más. Para una recuperación más rápida, realice una conmutación por error forzada en lugar de esperar a que se desencadene la conmutación por error administrada por el servicio.

    Si Microsoft inicia una conmutación por error gestionada por el servicio para la región de escritura de la cuenta, se podrían perder las escrituras no replicadas.

    Después de una conmutación por error administrada por el servicio, Microsoft debe restaurar una región en línea. Microsoft trae automáticamente la región en línea, pero este proceso puede tardar varios días.

Requirements

Region support: Puede configurar cualquier región de Azure como región de lectura para la cuenta de Azure Cosmos DB.

Cost

Agregar una región de lectura adicional a una cuenta de Azure Cosmos DB aumenta los costos existentes para cada región. Para obtener más información, consulte Precios de Azure Cosmos DB.

Configuración de varias regiones de lectura

Planeamiento y administración de capacidad

Si la aplicación distribuye las solicitudes entre regiones y una región se queda sin conexión, las regiones restantes experimentan un volumen de solicitudes mayor. Utilice el escalado automático del rendimiento para adaptar dinámicamente la capacidad en función de la demanda. Si usa el rendimiento aprovisionado, planee la capacidad adecuada para controlar la pérdida de una región sin degradación del servicio y considere la posibilidad de sobreaprovisionar. Para más información, consulte Administración de la capacidad con sobreaprovisionamiento.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar al configurar una cuenta de Azure Cosmos DB con varias regiones de lectura y todas las regiones están operativas.

  • Operación entre regiones: La aplicación configura la región que debe recibir operaciones de lectura. Puede configurar la aplicación con una lista prioritaria de regiones o excluir algunas regiones. Para obtener más información sobre cómo funciona la selección de regiones, consulte Diagnose y solucione la disponibilidad de los SDK de Azure Cosmos DB en entornos multirregionales.

    Todas las operaciones de escritura se dirigen a la región de escritura asignada a su cuenta.

  • Replicación de datos entre regiones: Todas las operaciones de escritura se producen en la región primaria de la cuenta. Las operaciones de escritura se replican a las otras regiones de lectura según el nivel de coherencia configurado para la cuenta. Para obtener información sobre el retraso máximo de replicación, consulte Posible pérdida de datos durante las interrupciones de la región.

Comportamiento durante un error de región de lectura

En esta sección se describe qué esperar al configurar una cuenta de Azure Cosmos DB con varias regiones de lectura y se produce una interrupción en una de las regiones de lectura de la cuenta.

Importante

Lo ideal es que las interrupciones de la región de lectura se controlen en el nivel de cliente configurando correctamente la lista de regiones preferidas en la configuración del SDK. Cuando se configura correctamente, el SDK detecta automáticamente la interrupción y vuelve a enrutar las operaciones de lectura a la siguiente región disponible sin necesidad de realizar ninguna conmutación por error del lado del servicio.

  • Detección y respuesta: La responsabilidad de detectar la interrupción y responder depende del tipo de conmutación por error que usa su cuenta.

    • PPAF: PPAF normalmente no se aplica a interrupciones de la región de lectura. Sin embargo, para las cuentas con coherencia fuerte y solo dos regiones, la pérdida de la región de lectura reduce la cuenta a una sola región, que no puede mantener el cuórum dinámico. En este escenario, PPAF puede activarse para conservar la disponibilidad cambiando las particiones afectadas a la región correcta.

    • Conmutación por error forzada: Usted es responsable de realizar una conmutación por error forzada. Para obtener instrucciones detalladas, consulte Realizar una conmutación por error forzada para su cuenta de Azure Cosmos DB.

      Si no realiza una conmutación por error, el comportamiento de la cuenta depende de su nivel de coherencia:

      • Coherencia fuerte: la coherencia fuerte requiere dos o más regiones para mantener el cuórum dinámico. Si hay menos de dos regiones disponibles y no realiza una conmutación por error, la cuenta pierde la disponibilidad de escritura hasta la restauración del servicio.

      • Coherencia de obsolescencia limitada: La coherencia de obsolescencia limitada se basa en el mantenimiento de un umbral de obsolescencia específico entre regiones. Si la longitud de la interrupción de la región supera el umbral, el sistema no puede mantener la coherencia entre escrituras. Si no ejecuta una conmutación por error, la cuenta perderá la capacidad de escritura hasta la restauración del servicio.

    • Conmutación por error administrada por el servicio: Si la conmutación por error administrada por el servicio está habilitada, Microsoft detectará la interrupción e iniciará una conmutación por error de la cuenta. Sin embargo, este proceso puede tardar mucho tiempo, potencialmente una hora o más. Para una recuperación más rápida, realice una conmutación por error forzada en lugar de esperar a que se desencadene la conmutación por error administrada por el servicio.

  • Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo:

  • Solicitudes activas: Es posible que el cliente finalice las solicitudes activas y deba reintentarlas una vez completada la conmutación por error. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

  • Pérdida de datos esperada: Una interrupción en una región de lectura no causa pérdida de datos. Azure Cosmos DB sigue cumpliendo las garantías de coherencia de lectura.

  • Tiempo de inactividad esperado: La cantidad de tiempo de inactividad que experimenta la cuenta depende del tipo de conmutación por error que usa la cuenta.

    • PPAF: Cuando PPAF está habilitado, el sistema detecta y recupera automáticamente el error, normalmente en un plazo de 3 minutos, sin intervención manual.

    • Conmutación por error forzada: El tiempo de inactividad depende de:

      • Cuánto tiempo se tarda en detectar la interrupción e iniciar una conmutación por error.

      • Cuánto tarda la conmutación por error, que generalmente toma unos pocos segundos.

        Advertencia

        No realice ninguna operación de configuración (plano de control) en la región afectada durante escenarios de interrupción, ya que dan como resultado una incoherencia de la cuenta y una recuperación retrasada. Algunos de los ejemplos de operaciones del plano de control que se deben evitar son:

        • Cambiar la región de escritura o modificar la prioridad de failover
        • Actualice la cuenta a la configuración para escritura múltiple
        • Actualización de los niveles de coherencia u otra configuración de la cuenta
        • Actualización de configuraciones de punto de conexión privado o configuración de red
        • Actualización del rendimiento de la cuenta u operaciones de escalado
        • Cualquier otra operación que modifique la configuración de la cuenta o la configuración de región

    • Conmutación por error administrada por el servicio: Microsoft es responsable de iniciar la conmutación por error administrada por el servicio y el tiempo de inactividad que experimenta la cuenta se basa en el tiempo que tarda Microsoft declarar la interrupción e iniciar la conmutación por error. En algunas situaciones, puede tardar una hora o más. Si tu cuenta experimenta interrupciones en la capacidad de escritura y necesitas restaurar rápidamente la disponibilidad de escritura, ejecuta una conmutación por error forzada.

  • Redistribución: Para la conmutación por error forzada o la conmutación por error administrada por el servicio, la región afectada se desconecta y se marca como sin conexión.

    No es necesario realizar ningún cambio en el código de su aplicación para administrar la interrupción de la región de lectura. Los SDK Azure Cosmos DB redirigen las operaciones de lectura a la siguiente región disponible en la lista de regiones preferidas. Si ninguna de las regiones de la lista de regiones preferidas está disponible, las operaciones de lectura se revierten automáticamente a la región de escritura actual de la cuenta tal como está configurada en el servicio.

    Nota:

    Si usa puntos de conexión privados con una cuenta de Azure Cosmos DB, asegúrese de que el DNS privado se enruta correctamente después de la operación de región sin conexión. Para obtener instrucciones detalladas, consulte Consideraciones sobre la conmutación por error para puntos de conexión privados.

Comportamiento durante un fallo de región de escritura

En esta sección se describe qué esperar al configurar una cuenta de Azure Cosmos DB con varias regiones de lectura y se produce una interrupción en la región de escritura de la cuenta.

  • Detección y respuesta: La responsabilidad de detectar la interrupción y responder depende del tipo de conmutación por error que usa su cuenta.

    • PPAF: Microsoft detecta automáticamente la interrupción e inicia una conmutación por error de algunas particiones, si procede. La aplicación no necesita realizar ninguna acción.

    • Conmutación por error forzada: Usted es responsable de realizar una conmutación por error forzada. Para obtener instrucciones detalladas, consulte Realizar una conmutación por error forzada para su cuenta de Azure Cosmos DB.

      Si no realiza una conmutación por error, la cuenta perderá la capacidad de escritura hasta que se restaure el servicio.

      Si hay una interrupción en la región de escritura de la cuenta, evite realizar una operación de cambiar la región de escritura. Los cambios en la región de escritura no se realizan correctamente si hay una interrupción de la región de origen o destino. El motivo es que el procedimiento de cambio de región incluye una comprobación de coherencia que requiere conectividad entre las regiones.

    • Conmutación por error gestionada por el servicio: Microsoft detecta automáticamente la interrupción e inicia una conmutación por error de su cuenta. La aplicación no necesita realizar ninguna acción.

  • Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo:

  • Solicitudes activas: Cualquier solicitud activa podría ser terminada, y el sistema cliente deberá reintentarlas después de que se complete la conmutación por error. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

  • Pérdida de datos esperada: Si configura la cuenta con coherencia fuerte, no se produce ninguna pérdida de datos. De lo contrario, es posible que se pierdan las escrituras no replicadas después de que se complete la conmutación por error. Para obtener información sobre la pérdida máxima de datos esperada durante una interrupción de la región, consulte Posibles pérdidas de datos durante las interrupciones de la región.

  • Tiempo de inactividad esperado: La cantidad de tiempo de inactividad que experimenta la cuenta depende del tipo de conmutación por error que usa la cuenta.

    • PPAF: Cuando PPAF está habilitado, espere una breve interrupción, que normalmente es de aproximadamente 3 minutos.

    • Conmutación por error forzada: El tiempo de inactividad depende de:

      • Cuánto tiempo se tarda en detectar la interrupción e iniciar una conmutación por error.
      • Cuánto tiempo tarda el proceso de conmutación, que normalmente tarda solo unos segundos.

    Advertencia

    No realice ninguna operación de plano de control en la región afectada durante los escenarios de interrupción, ya que provocan inconsistencias en la cuenta y retrasan la recuperación. Algunos de los ejemplos de operaciones del plano de control que se deben evitar son:

    • Cambio de la región de escritura o modificación de la prioridad de conmutación por error
    • Actualice la cuenta a la configuración para escritura múltiple
    • Actualización de los niveles de coherencia u otra configuración de la cuenta
    • Actualización de configuraciones de punto de conexión privado o configuración de red
    • Actualización del rendimiento de la cuenta u operaciones de escalado
    • Cualquier otra operación que modifique la configuración de la cuenta o la configuración de región
    • Conmutación por error administrada por el servicio: Microsoft es responsable de iniciar la conmutación por error administrada por el servicio y el tiempo de inactividad que experimenta la cuenta se basa en el tiempo que tarda Microsoft declarar la interrupción e iniciar la conmutación por error. En algunas situaciones, puede tardar una hora o más. Para restaurar rápidamente la disponibilidad de escritura, realice una conmutación por error forzada.

  • Redistribución: La redistribución del tráfico de escritura depende del tipo de conmutación por error que usa la cuenta.

    • PPAF: Azure Cosmos DB conmuta automáticamente por error la partición no saludable a una región saludable.

    • Conmutación por error forzada: Al realizar una conmutación por error forzada, la región de escritura de la cuenta cambia a la región que especifique.

    Nota:

    Si usa puntos de conexión privados con una cuenta de Azure Cosmos DB, asegúrese de que el DNS privado se enruta correctamente después de la operación de región sin conexión. Para obtener instrucciones detalladas, consulte Consideraciones sobre la conmutación por error para puntos de conexión privados.

    • Conmutación por error gestionada por el servicio: Azure Cosmos DB designa automáticamente una de las regiones secundarias de la cuenta para que sea la nueva región de escritura primaria. La conmutación por error se produce a otra región en el orden de prioridad de región que especifique.

Recuperación de regiones

Microsoft debe restaurar la operatividad de una región. Cuando una región se recupera después de una interrupción, Microsoft pone automáticamente la región en línea. Sin embargo, este proceso puede tardar varios días.

Importante

Después de una conmutación por error forzada, Microsoft restablece automáticamente la conectividad de la región para las regiones saludables. Si la región no vuelve a estar en línea en un día o dos, abra un caso de soporte técnico para solicitar asistencia.

Una vez que la región está en línea, las acciones que realice son diferentes en función de si la interrupción se encontraba en una región de lectura o en una región de escritura.

  • Después de interrupciones de la región de lectura: Cuando la región afectada vuelve a estar en línea, se sincroniza con la región de escritura actual y está disponible de nuevo para atender solicitudes de lectura después de haberse puesto al día por completo. Las siguientes lecturas se redirigen a la región recuperada sin necesidad de realizar cambios en el código de la aplicación. Tanto durante la conmutación por error como durante el restablecimiento de una región con errores anteriores, Azure Cosmos DB sigue respetando las garantías de coherencia de lectura.

  • Después de interrupciones en la región de escritura: Cuando la región afectada vuelve a estar en línea, la región se muestra como "en línea" en el portal de Azure y se vuelve disponible como una región de lectura. En este momento, es seguro cambiar la región de escritura a la región recuperada.

    Importante

    La región recuperada no se promoverá automáticamente de nuevo como la región de escritura una vez que se recupere. Es su responsabilidad volver a cambiar a la región recuperada como región de escritura, una vez que es seguro hacerlo.

    No hay ninguna pérdida de datos o disponibilidad antes, mientras, o después de cambiar la región de escritura. La aplicación sigue teniendo alta disponibilidad.

    Si las escrituras no se replicaron antes de que la región se desconectase, puede leer las escrituras no replicadas de la fuente de conflictos. La aplicación puede leer la fuente de conflictos, resolver los conflictos en función de la lógica específica de la aplicación y volver a escribir los datos actualizados en el contenedor según corresponda.

Prueba de fallos de región

Es posible que su aplicación no maneje correctamente las conmutaciones por error regionales, incluso si la cuenta de Azure Cosmos DB está altamente disponible. Para probar la alta disponibilidad de extremo a extremo de su aplicación como parte de sus pruebas de aplicaciones o simulacros de recuperación ante desastres (DR), deshabilite temporalmente la conmutación por error administrada por el servicio para la cuenta. Invoque la conmutación por error forzada mediante PowerShell, el CLI de Azure o el portal de Azure y, a continuación, supervise la aplicación. Después de completar la prueba, puede revertir a la región primaria una vez que la región vuelva a estar en línea automáticamente y, a continuación, restaurar la conmutación por error gestionada por el servicio para la cuenta. Si la región no vuelve a estar en línea en un día o dos, abra un caso de soporte técnico para solicitar asistencia.

Si su cuenta usa PPAF, puede simular una conmutación por error de partición. Para obtener más información, consulte Probar la configuración de PPAF (simular error).

Varias regiones de escritura

Puede configurar Azure Cosmos DB para que acepte escrituras en varias regiones. Esta configuración puede proporcionar una resistencia muy alta a las interrupciones de la región. También es útil para reducir la latencia de escritura en aplicaciones distribuidas geográficamente.

Diagrama que muestra una cuenta de Azure Cosmos DB. La región A y la región B son regiones de escritura y lectura. Una aplicación de la región A realiza lecturas y escrituras en la cuenta de Azure Cosmos DB en la región A. Una aplicación de la región B realiza lecturas y escrituras en la cuenta de Azure Cosmos DB de la región B. Internamente, Azure Cosmos DB replica de forma asincrónica los cambios entre las regiones.

Cuando se configura una cuenta de Azure Cosmos DB para varias regiones de escritura, no se admite la coherencia fuerte y pueden surgir conflictos de escritura. La región central actúa como un árbitro en conflictos de escritura. Para obtener más información sobre cómo resolver estos conflictos, consulte Tipos de conflictos y directivas de resolución al utilizar varias regiones de escritura.

Es importante tener en cuenta el diseño de la aplicación y cómo funciona con varias regiones de escritura. Revise los procedimientos recomendados para las escrituras en varias regiones.

Requirements

Region support: Puede configurar cualquier región de Azure como región de lectura o escritura para la cuenta de Azure Cosmos DB.

Cost

Agregar una región de escritura adicional a una cuenta de Azure Cosmos DB aumenta los costos existentes para cada región. Para obtener más información, consulte Precios de Azure Cosmos DB.

Configuración de varias regiones de escritura

Puede configurar varias regiones de escritura en su cuenta al crear la cuenta o en cualquier momento después de crearla. Para obtener más información, consulte Configuración de varias regiones de escritura.

Para usar eficazmente varias regiones de escritura, la aplicación también debe configurarse correctamente. Vea Configurar escrituras multirregionales en aplicaciones que usan Azure Cosmos DB.

Planeamiento y administración de capacidad

Si la aplicación distribuye las solicitudes entre regiones y una región se queda sin conexión, las regiones restantes experimentan un volumen de solicitudes mayor. Utilice el escalado automático del rendimiento para adaptar dinámicamente la capacidad en función de la demanda. Si usa el rendimiento aprovisionado, planee la capacidad adecuada para controlar la pérdida de una región sin degradación del servicio y considere la posibilidad de sobreaprovisionar. Para más información, consulte Administración de la capacidad con sobreaprovisionamiento.

Comportamiento cuando todas las regiones están en buen estado

En esta sección se describe qué esperar al configurar una cuenta de Azure Cosmos DB con varias regiones de escritura y todas las regiones están operativas.

Comportamiento durante una falla de región

En esta sección se describe qué esperar al configurar una cuenta de Azure Cosmos DB con varias regiones de escritura y se produce una interrupción en una de las regiones de lectura o escritura de la cuenta.

  • Detección y respuesta: La aplicación detecta la pérdida de la región. Azure Cosmos DB SDKs proporcionan funcionalidades automáticas de selección de regiones que enrutan las operaciones de lectura y escritura a regiones funcionales.

  • Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo:

  • Solicitudes activas: Cualquier solicitud activa podría ser terminada, y el sistema cliente deberá reintentarlas después de que se complete la conmutación por error. Si los clientes controlan correctamente los errores transitorios mediante el reintento después de un breve período de tiempo, normalmente evitan un impacto significativo.

  • Pérdida de datos esperada: Los datos actualizados recientemente podrían dejar de estar disponibles en otras regiones. Para obtener información sobre la pérdida máxima de datos esperada durante una interrupción de la región, consulte Posibles pérdidas de datos durante las interrupciones de la región. En el improbable caso de que la región afectada sufre una pérdida de datos permanente, es posible que pierda datos no replicados.

  • Tiempo de inactividad esperado: No hay tiempo de inactividad esperado en configuraciones de escritura múltiple, siempre que los SDK estén configurados correctamente con ApplicationRegions o PreferredRegions.

    Sugerencia

    Para obtener los mejores resultados, las aplicaciones distribuidas globalmente deben estar delante de un servicio de equilibrio de carga global, como Azure Front Door o Azure Traffic Manager. Estos servicios pueden detectar la degradación regional y enrutar automáticamente el tráfico a instancias de aplicación en una región correcta.

  • Redistribution: Los SDK de Azure Cosmos DB detectan automáticamente que la región es defectuosa y redireccionan las operaciones de lectura y escritura a la siguiente región disponible en la lista de regiones preferidas. No se requieren cambios en el código de la aplicación.

    Sugerencia

    Si la aplicación está gestionada por Azure Front Door o Traffic Manager, esos servicios también detectan la degradación regional y enrutan el tráfico a una región que esté funcionando correctamente.

Recuperación de regiones

Cuando la región afectada vuelve a estar en línea, la región se muestra como "en línea" en el portal de Azure y vuelve a estar disponible.

Los datos de escritura que no se replicaron cuando se produjo un error en la región están disponibles a través de la fuente de conflictos. Las aplicaciones pueden leer la fuente de conflictos, resolver los conflictos de acuerdo con la lógica específica de la aplicación y escribir los datos actualizados de nuevo en el contenedor de Azure Cosmos DB según corresponda.

Prueba de fallos de región

Para probar escenarios de conmutación por error de escritura en varias regiones, puede desconectar una región de escritura mediante una conmutación por error forzada. Este proceso simula una interrupción de la región y puede observar cómo responde la aplicación.

Copias de seguridad y restauración

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

La pérdida de datos puede producirse debido a eliminaciones accidentales u otros problemas en la aplicación que provocan daños en los datos. Cuando se usa una cuenta de una sola región, la pérdida de datos también puede producirse debido a un desastre irrecuperable en la región de Azure Cosmos DB. Para ayudarle a protegerse contra la pérdida de datos, Azure Cosmos DB proporciona un conjunto de funcionalidades de copia de seguridad y restauración. Puede configurar copias de seguridad y retención en función de los requisitos de capacidad de recuperación y los requisitos de costo. Para más información, consulte Copia de seguridad en línea y restauración de datos a petición en Azure Cosmos DB.

Resistencia al mantenimiento del servicio

Azure Cosmos DB administra de forma transparente todos los detalles de los nodos de proceso individuales y realiza automáticamente la aplicación de revisiones y otros tipos de mantenimiento planeado. Los SLA de Azure Cosmos DB para la disponibilidad y la latencia se aplican a través de todas las operaciones de mantenimiento automáticas que realiza el sistema.

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 Acuerdos de Nivel de Servicio para servicios en línea.

Azure Cosmos DB proporciona acuerdos de nivel de servicio para una variedad de configuraciones y características de servicio, incluida la disponibilidad, la latencia, el rendimiento y la coherencia.

Los Acuerdos de Nivel de Servicio de disponibilidad son diferentes en función de si usa cualquiera de las siguientes funcionalidades de producto:

  • Rendimiento aprovisionado
  • Cuenta regional única con soporte para zona de disponibilidad (redundancia de zona)
  • Cuentas que usan varias regiones de lectura
  • Cuentas que usan varias regiones de escritura (nivel Crítico para la empresa)

Contenido relacionado

  • Last updated on