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 multiregión 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.

Configure el rendimiento, que representa la cantidad de recursos del sistema que puede utilizar para consultar y trabajar con sus 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 las réplicas manteniendo el quórum entre las 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.

Use 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 multirregional, el SDK también admite una estrategia de disponibilidad basada en un umbral, también denominada hedging, en la que se envían solicitudes de lectura en paralelo a varias regiones y se acepta 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.

Una cuenta de Azure Cosmos DB puede utilizar 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.

Use 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 distintas fuentes de alimentación, redes y refrigeración, 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.

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. En el caso de las cargas de trabajo críticas, use 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 desplegar una cuenta multirregional si necesita ser resiliente al fallo simultáneo de varias zonas.

• 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, se renuncia a los precios premium de las zonas de disponibilidad para las cuentas configuradas con escrituras de varias regiones y para las colecciones configuradas para usar el modo de rendimiento de escalabilidad automática. 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 las zonas de disponibilidad de 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:

• Varias regiones de lectura con una sola región de escritura. Opcionalmente, puede habilitar la conmutación por error administrada por servicio o la conmutación automática por partición (PPAF).
• Regiones de escritura múltiples.

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.

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:

• SDK de Azure Cosmos DB .NET v3
• SDK v4 de Azure Cosmos DB Java
• SDK de Azure Cosmos DB para Python

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 pérdida potencial de datos durante una interrupción del servicio en una región.

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 sufre una interrupción del servicio, la cuenta puede seguir funcionando desde las regiones que están en buen estado.

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 de región de escritura única realizar automáticamente la conmutación por error de particiones individuales a una región secundaria, al tiempo que se mantienen las particiones en buen estado en la región principal. 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.

• Conmutación por error forzada: Puede desconectar una de las regiones de su cuenta. Esto también se conoce como conmutación por error administrada por el cliente o operación de región fuera de línea. Este es el enfoque recomendado para restaurar rápidamente la disponibilidad durante una interrupción. Usted es responsable de detectar la interrupción del servicio y de activar la conmutación por error. También puede utilizar las conmutaciones por error forzadas para simular escenarios de caída de una región con fines de prueba, 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 su región de escritura conlleva la posibilidad de pérdida de datos en el caso de las escrituras no replicadas.

  Tras una conmutación por error forzada, Microsoft debe volver a poner 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 equivale, en la práctica, a una conmutación por error planificada de la región de escritura de su 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 del servicio y activar la conmutación por error administrada por el servicio puede llevar bastante tiempo, posiblemente 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 activa una conmutación por error administrada por el servicio para la región de escritura de la cuenta, cualquier escritura no replicada podría perderse.

  Tras una conmutación por error administrada por el servicio, Microsoft debe volver a poner la 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

• Agregue regiones de lectura a una cuenta: Puede configurar varias regiones en su cuenta al crear la cuenta o en cualquier momento después de crearla. Para obtener más información, consulte Agregar o quitar regiones de la cuenta de base de datos.

• Habilitación de la conmutación por error: Algunos tipos de conmutación por error deben configurarse de antemano:

  • Conmutación automática por error por partición: Para obtener más información, consulte Cómo incorporar y adoptar la conmutación automática por error por partición (PPAF) para Azure Cosmos DB.

  • Conmutación por error administrada por el servicio: En primer lugar, habilite la conmutación por error administrada por el servicio. A continuación, establezca las prioridades de conmutación por error para cada región de su cuenta.

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.

• 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, en el caso de las cuentas con consistencia fuerte y solo dos regiones, la pérdida de la región de lectura reduce la cuenta a una única región, lo que impide mantener el quó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 conocer los pasos detallados, 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 su cuenta dependerá de su nivel de consistencia:

    • 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 perderá la disponibilidad de escritura hasta que se restablezca el 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 duración de la interrupción de la región supera el umbral, el sistema no podrá mantener la consistencia entre las escrituras. Si no se realiza una conmutación por error, la cuenta perderá la disponibilidad de escritura hasta que se restablezca el 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:

  • Puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas.

  • 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 los problemas.

• Solicitudes activas: Es posible que cualquier solicitud activa se interrumpa y que el cliente tenga que volver a intentarla una vez finalizada 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:

    • El tiempo que tardes en detectar la interrupción e iniciar la conmutación por error.

    • El tiempo que tarda la conmutación por error, que suele ser de unos 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 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. Si tu cuenta sufre una interrupción en las operaciones de escritura y necesitas restablecer rápidamente la disponibilidad de escritura, realiza 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 conocer los pasos detallados, consulte Realizar una conmutación por error forzada para su cuenta de Azure Cosmos DB.

    Si no se realiza una conmutación por error, la cuenta perderá la disponibilidad de escritura hasta que se restablezca 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 completan con éxito si se produce una interrupción en la región de origen o de 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:

  • Puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas.

  • 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 los problemas.

• Solicitudes activas: Es posible que cualquier solicitud activa se interrumpa y que el cliente tenga que volver a intentarla una vez finalizada 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:

    • El tiempo que tardes en detectar la interrupción e iniciar la conmutación por error.
    • El tiempo que tarda la conmutación por error, que suele ser de 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:

  • Cambiar la región de escritura o modificar 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 utilice su cuenta.

  • PPAF: Azure Cosmos DB realiza automáticamente la conmutación por error de la partición defectuosa a una región en buen estado.

  • 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 administrada por el servicio: Azure Cosmos DB promueve automáticamente una de las regiones secundarias de la cuenta para que sea la nueva región de escritura principal. 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.

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 alguna escritura no se replicó antes de que la región quedara fuera de línea, puede leer las escrituras no replicadas desde el canal 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 administre correctamente las conmutaciones por error de región, incluso si su cuenta de Azure Cosmos DB tiene alta disponibilidad. 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. Una vez completada la prueba, puede volver a la región principal cuando esta vuelva a estar en línea automáticamente y, a continuación, restablecer la conmutación por error administrada 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.

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 del hub actúa como árbitro en los 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 multiregión.

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. Consulte Configuración de escrituras multiregión 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.

• Operación entre regiones: Cuando una cuenta está configurada con varias regiones de escritura, la aplicación configura la región que se debe usar para las operaciones de lectura y escritura. 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. Para obtener información sobre cómo configurar la aplicación, consulte Configuración de escrituras multiregión en aplicaciones que usan Azure Cosmos DB.

• Replicación de datos entre regiones: Los datos se replican entre regiones de forma asincrónica. El retraso de replicación depende del nivel de coherencia de la cuenta. No se puede usar una coherencia fuerte para las escrituras de varias regiones. Para obtener más información, consulte Posibles pérdidas de datos durante interrupciones de región.

  Cuando una cuenta está configurada para varias regiones de escritura, las aplicaciones de diferentes regiones pueden realizar cambios que entren en conflicto entre sí. Azure Cosmos DB proporciona funcionalidades de resolución de conflictos. Para obtener más información, consulte Tipos de conflictos y directivas de resolución al usar varias regiones de escritura. Para obtener información sobre cómo configurar su propia directiva de resolución de conflictos, consulte Administrar directivas de resolución de conflictos en Azure Cosmos DB.

  Nota:

  Actualizar el mismo identificador de documento con frecuencia o volver a crear el mismo identificador de documento con frecuencia después de que expire su TTL o se elimine, afecta negativamente al rendimiento de la replicación debido a un mayor número de conflictos generados en el sistema.

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:

  • Puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas.

  • 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 los problemas.

• Solicitudes activas: Es posible que cualquier solicitud activa se interrumpa y que el cliente tenga que volver a intentarla una vez finalizada 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.

Cualquier dato de escritura que no se haya replicado cuando se produjo el error de la región queda disponible a través del canal 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 multiregión, 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

• confiabilidad Azure
• Información general de Azure Cosmos DB
• Niveles de coherencia en Azure Cosmos DB
• Distribución de datos global con Azure Cosmos DB
• Diagnose y solucione los problemas de disponibilidad de los SDK de Azure Cosmos DB en entornos multirregionales