Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
SE APLICA A:
NoSQL
MongoDB
Casandra
Gremlin
Tabla de
Azure Cosmos DB funciona de forma diferente a muchos otros servicios de Azure cuando se trata de configuraciones de alta disponibilidad. En lugar de confiar en una instancia secundaria implementada por el cliente para lograr resistencia, las cuentas de Azure Cosmos DB se configuran con una configuración de varias regiones que replican activamente los datos entre regiones seleccionadas. Durante una interrupción regional, la conmutación por error (región sin conexión) se puede iniciar en otra región para mantener la disponibilidad.
Cuando una cuenta de Azure Cosmos DB conmuta por error, el nombre del servicio permanece sin cambios. Si el punto de conexión público se usa para la conectividad, los sistemas todavía pueden acceder al servicio a través de la misma resolución DNS, independientemente de su estado de conmutación por error. Las funciones de resolución DNS operan sin problemas incluso si solo una región o un subconjunto de servicios se ve afectado por una interrupción. Esta resistencia integrada reduce el número de tareas de continuidad empresarial y recuperación ante desastres (BCDR) necesarias para Azure Cosmos DB.
Para los clientes que usan puntos de conexión privados, se requiere una configuración adicional para garantizar la compatibilidad con la conmutación por error. En este documento se proporciona una arquitectura de ejemplo de una cuenta de Azure Cosmos DB de varias regiones mediante puntos de conexión privados para redes seguras y se detallan los pasos necesarios para diferentes escenarios de BCDR.
Arquitectura de ejemplo
Esta arquitectura utiliza regiones primarias y secundarias para admitir escenarios de conmutación por error activos/activos y activos/pasivos. Cada región incluye una red en la que se implementan la cuenta de Azure Cosmos DB y otras soluciones de carga de trabajo. La cuenta de Azure Cosmos DB de varias regiones tiene puntos de conexión privados en ambas regiones para garantizar una conectividad sin problemas. Esta configuración permite a las aplicaciones conectarse al punto de conexión privado más cercano, optimizando el rendimiento al tiempo que mantiene la resistencia durante un evento de conmutación por error.
Los dos puntos de conexión privados no pueden usar la misma zona DNS privada para el mismo punto de conexión. Como resultado, cada región tiene su propia zona DNS privada. Cada zona regional está conectada a la red del concentrador para esa región específica. Este diseño aprovecha el escenario del reenviador DNS para proporcionar resolución. Como resultado, independientemente de la región de la máquina virtual (VM) que acceda al punto de conexión privado, hay un punto de conexión local disponible para conectarse a Azure Cosmos DB. En el caso de las conexiones que se originan en un centro de datos, se establecería una conexión VPN a la red del centro de conectividad en la región correspondiente.
Para la resolución DNS, cada centro de datos configuraría el reenvío condicional a uno de los dos conjuntos de servidores de resolución DNS, lo que garantiza que se resuelve en la ubicación de red más cercana para una conectividad óptima.
Conceptos de arquitectura
Azure Cosmos DB admite varios puntos de conexión privados por cuenta, lo que le permite crear puntos de conexión distribuidos regionalmente en diferentes redes virtuales. Por ejemplo, podría tener un punto de conexión privado de Azure Cosmos DB en cada región, cada uno de los cuales atiende el tráfico de forma independiente desde su red virtual respectiva.
En las topologías tradicionales en estrella tipo hub-and-spoke, esta configuración es menos común debido a las limitaciones de la zona DNS privada; cada zona solo puede contener un registro por nombre DNS. Una vez que vincule un punto de conexión privado a una zona DNS privada, los puntos de conexión adicionales de otras regiones deben usar zonas DNS privadas independientes para evitar conflictos de DNS.
Además, los puntos de conexión privados de Azure Cosmos DB no están enlazados a regiones. Puede implementar un punto de conexión privado en una región para acceder a una cuenta de Azure Cosmos DB hospedada en otra región, lo que permite configuraciones de red flexibles.
Para garantizar una resolución adecuada, cada región debe tener su propia zona DNS privada específica de la región asignada al punto de conexión local. Esta configuración permite que los recursos de cada región enruten el tráfico correctamente. Aunque la implementación de puntos de conexión privados en la misma región que la cuenta de Azure Cosmos DB suele ser preferible para la optimización de costos y latencia, admitir puntos de conexión privados de varias regiones puede ser fundamental para escenarios de alta disponibilidad y conmutación por error regional, lo que garantiza el acceso privado continuo incluso si una región deja de estar disponible.
Escenarios de conmutación por error
Esta topología admite los siguientes escenarios, cada uno con sus propias consideraciones de conmutación por error de DNS.
| Scenario | Description | Consideraciones sobre DNS |
|---|---|---|
| Escenario 1: conmutación por error de Azure Cosmos DB | Una interrupción del servicio en la región primaria requiere que Azure Cosmos DB conmute por error a una región secundaria. | No se requieren cambios |
| Escenario 2: Conmutación por error de otros servicios | Un fallo del servicio afecta a otros servicios de la región primaria, pero Azure Cosmos DB no necesita realizar una conmutación por error. | Si la interrupción afecta a los servidores DNS hospedados en la región primaria, los reenviadores condicionales de un entorno local deben actualizarse a la región secundaria. |
| Escenario 3: interrupción de toda la región | Una interrupción grave del servicio afecta a varios servicios, lo que necesita que tanto Azure Cosmos DB como otros servicios realicen un failover. | Los reenviadores condicionales del DNS local deben actualizarse a la región secundaria. |
| Escenario 4: configuración de escritura múltiple | Azure Cosmos DB y otros servicios funcionan en una configuración activa o activa en varias regiones. | No se requieren cambios |
Escenario 1: Conmutación por error de Azure Cosmos DB
En este escenario, un problema con la cuenta de Azure Cosmos DB requiere que conmute por error a una región secundaria. Dado que Azure Cosmos DB está diseñado para alta disponibilidad, las interrupciones regionales son poco frecuentes, pero todavía deben planearse.
Cuando se activa la conmutación por error forzada (región sin conexión) de Azure Cosmos DB, se realiza la conmutación a la región secundaria, mientras que el enrutamiento de red permanece sin cambios. No se necesitan modificaciones en DNS, cada región sigue usando su punto de conexión privado local para comunicarse con Azure Cosmos DB. Después de la conmutación por error (región sin conexión): el servicio funcionará como se muestra:
Una vez que la región primaria esté nuevamente correcta, se realiza el proceso de reversión en la cuenta de Azure Cosmos DB, restaurando la región de escritura original sin necesidad de realizar cambios en la configuración de la red.
Escenario 2: Conmutación por error de otros servicios
En este escenario, el problema no se encuentra con la cuenta de Azure Cosmos DB, sino con los servicios que se conectan a él, como los servicios de aplicación, las máquinas virtuales o los contenedores. Estos servicios deben conmutarse por error a una región secundaria siguiendo sus respectivos planes de recuperación ante desastres.
Por ejemplo, las máquinas virtuales pueden usar Azure Site Recovery para replicar cargas de trabajo de antemano, mientras que los servicios de aplicaciones se pueden volver a implementar en la región secundaria mediante canalizaciones de CI/CD o características de escalado nativas de la plataforma.
Una vez que los servicios están activos en la región secundaria, pueden empezar a conectarse inmediatamente a Azure Cosmos DB a través del punto de conexión privado regional local. Azure Cosmos DB no requiere ningún cambio para admitir esto: los puntos de conexión ya están aprovisionados para permitir el acceso sin problemas desde varias regiones.
Si hay una red local conectada a través de VPN, la conectividad continuará siempre que la resolución DNS a través del hub continúe siendo operativa. Sin embargo, si la infraestructura DNS del centro se ve afectada (por ejemplo, debido a una interrupción del servicio DNS o una máquina virtual), es posible que los reenviadores DNS locales deban volver a configurarse para que apunten a los solucionadores DNS de la región secundaria hasta que se restaure la región primaria.
Después de la conmutación por error, los servicios de la región secundaria funcionarán como se muestra:
Una vez restaurada la región primaria, los servicios se pueden revertir y se pueden revertir los cambios temporales de DNS en los sistemas locales.
Escenario 3: Interrupción de toda la región
En este escenario, hay una interrupción regional suficientemente grave que hacen que la cuenta de Azure Cosmos DB y los servicios de aplicación dependientes deban ser transferidos a una región secundaria.
Esta conmutación por error sigue un modelo combinado similar a los dos escenarios anteriores: la cuenta de Azure Cosmos DB conmuta por error a su región de escritura secundaria y los servicios de Azure (como aplicaciones web, máquinas virtuales o contenedores) se vuelven a implementar o activar en la región secundaria. La región primaria es eficazmente no funcional, pero la arquitectura garantiza que los servicios sigan ejecutándose desde la región secundaria con una interrupción mínima.
Al igual que con los casos anteriores, si la red de concentrador principal no puede controlar la resolución DNS, por ejemplo debido a una interrupción de la infraestructura DNS, los reenviadores DNS condicionales locales deben actualizarse temporalmente para usar solucionadores en la región secundaria para mantener la conectividad del punto de conexión privado.
Después de la conmutación por error, la arquitectura funciona como se muestra:
Una vez restaurada la región primaria, las cargas de trabajo pueden revertirse y la configuración de DNS se puede revertir a su configuración original.
Escenario 4: Configuración de varias escrituras
En este escenario, Azure Cosmos DB está configurado para escrituras en varias regiones, lo que le permite aceptar escrituras en varias regiones simultáneamente. Una interrupción se produce en una región, lo que afecta a los servicios de aplicaciones locales, pero Azure Cosmos DB sigue estando disponible globalmente debido a su naturaleza distribuida.
Dado que las cuentas de escritura múltiple tienen sus propios puntos de conexión de lectura y escritura regionales, no se necesita la conmutación por error de Azure Cosmos DB. La aplicación simplemente conmuta por error a otra región activa donde los servicios siguen en ejecución y puede continuar leyendo y escribiendo en Azure Cosmos DB mediante el punto de conexión privado regional. Comportamientos clave en este escenario:
- No se requiere la conmutación por error de Azure Cosmos DB; las demás regiones siguen controlando las escrituras sin problemas.
- Los servicios de aplicación (por ejemplo, App Services, AKS o las máquinas virtuales) se rehidratan o escalan verticalmente en una región alternativa.
- Los puntos de conexión privados regionales ya están aprovisionados, lo que permite la conectividad inmediata sin cambios de DNS.
- Los clientes locales siguen funcionando siempre y cuando sus reenviadores DNS puedan resolverse en un punto de conexión privado válido. Si los servicios DNS de la región con errores se ven afectados, deben apuntar temporalmente a los solucionadores DNS de la región activa.
Cuando se restaura la región primaria, los servicios de aplicación pueden volver a su estado original si se desea. No se requieren cambios en Azure Cosmos DB. La plataforma continúa replicando datos en todas las regiones de escritura tal como están configuradas.
