Las implementaciones multirregionales de Atlas son clústeres configurados en más de una región. Una implementación multirregional puede tener varias regiones dentro de la misma geografía (un área extensa, como un continente o un país), o Múltiples regiones en múltiples geografías. Implementaciones multirregionales:
Mejore la protección en caso de una interrupción regional redirigiendo automáticamente el tráfico a otra región para lograr una disponibilidad continua y una experiencia de usuario fluida.
Mejore el rendimiento y la disponibilidad de algunas aplicaciones al ubicar los datos más cerca de los usuarios.
Al considerar si una implementación multirregional es adecuada para usted, debe evaluar la criticidad de su aplicación y cómo se corresponde con los diferentes requisitos de RTO/RPO. La resiliencia varía entre cero tiempo de inactividad con una implementación multirregional y diferentes programaciones de respaldo con una implementación de una sola región. La contrapartida es un mayor costo a cambio de mayor disponibilidad.
Consulte la sección Confiabilidad para obtener más orientación sobre si una implementación multirregional es adecuada para su carga de trabajo.
Nota
Las implementaciones multirregionales están disponibles solo para M10 clústeres dedicados y más grandes.
Estrategias de implementación multirregional
El siguiente diagrama muestra 2 ejemplos de una topología 2+2+1, que se describe en detalle a continuación. Muestra un solo clúster con 5 nodos en 3 regiones diferentes: 2 nodos en US1, 2 en US2 y 1 en US3.
Arquitectura de nodo 5, región 3(2+2+1)
Para lograr una recuperación casi instantánea en caso de una interrupción regional, recomendamos una arquitectura con un mínimo de 5 nodos distribuidos en 3 regiones. Esta arquitectura garantiza que las operaciones de mantenimiento regulares se puedan realizar sin forzar la conmutación por error a una segunda región, a la vez que garantiza la conmutación por error automatizada y la protección contra la pérdida de datos en caso de una interrupción regional completa.
El siguiente diagrama muestra detalles de esta arquitectura:
Notas y consideraciones
Usar Puntos finales privados para conectarse al clúster y emparejamiento de VPC entre las VPC de su servidor de aplicaciones. El emparejamiento de VPC garantiza que, si se interrumpe una conexión de red o Atlas en esa región deja de funcionar, la capa de aplicación aún puede enrutar al nodo principal, primero a través del emparejamiento de VPC y luego a través del punto final privado.
Esta arquitectura tiene el costo más alto debido al tráfico de red entre regiones y a tener 5 o más nodos que contienen datos.
Esta arquitectura proporciona la máxima resiliencia. No hay interrupciones durante las operaciones de Atlas (como una actualización automática) y su aplicación puede soportar un fallo regional completo sin necesidad de interrupciones ni intervención manual.
Esta arquitectura tiene el costo más alto debido al tráfico de red entre regiones y a tener 5 o más nodos que contienen datos.
Arquitectura de nodo 5, región 2(2+3)
Si su empresa está limitada a solo 2 regiones, puede usar una variante de la arquitectura de 5nodos y 3regiones, en la que tiene 5 nodos distribuidos entre dos regiones. La región principal tiene 2 nodos elegibles, y la secundaria tiene 1 nodos elegibles y 2 nodos de solo lectura (sin derecho a voto).
Generalmente, esto no se recomienda si se pueden usar 3 regiones, ya que el operador debe intervenir manualmente para conmutar por error si falla la región mayoritaria. Sin embargo, es una opción para clientes con solo 2 regiones aprobadas.
Notas y consideraciones
Esta arquitectura ofrece mayor protección contra la pérdida de datos. Si se pierde la región minoritaria, no se requiere ninguna acción del usuario, ya que la región mayoritaria sigue siendo un clúster completamente funcional. Si se pierde la región mayoritaria, el sistema seguirá disponible en modo de solo lectura hasta que la mayoría de los nodos estén habilitados. Sin embargo, es posible que no ofrezca una protección completa contra la pérdida de datos si algunos datos aún no se han replicado a un nodo secundario tras un fallo. En este caso, esos datos no estarán disponibles hasta que se recupere la región principal.
Esta arquitectura tiene algunas salvedades:
Si se pierde la región mayoritaria, la región minoritaria no es un clúster completamente funcional; no tiene un primario y solo puede aceptar lecturas, pero no escrituras.
Debido a que no hay una mayoría de nodos con derecho a voto, no tiene un nodo principal y solo puede aceptar lecturas (no escrituras).
Para restaurar el clúster funcional, un administrador debe reconfigurar los 2 nodos de solo lectura como nodos elegibles. Sin embargo, es posible que se pierdan datos. Durante la interrupción, cualquier escritura nueva en los nodos secundarios se almacena en una colección especial para su recuperación manual. Sin embargo, cualquier escritura en el nodo principal que no se haya replicado en al menos un nodo secundario antes de la interrupción del principal se perderá. Para obtener más información, consulte "Reconfigurar un conjunto de réplicas durante una interrupción regional" o utilice el parámetro de API acceptDataRisksAndForceReplicaSetReconfig.
En clústeres fragmentados, si su proceso MongoDB no replicó las migraciones de fragmentos, la inconsistencia de datos podría provocar documentos huérfanos.
Variación de menor costo
Para ahorrar aún más, puede diseñar esta arquitectura sin los 2 nodos de solo lectura. Además de las advertencias mencionadas anteriormente, el tamaño de los datos influye significativamente en su decisión, ya que estos deben sincronizarse con los nodos secundarios cada vez que se añaden nuevos nodos al clúster. Por ejemplo, 1 TB de datos supone un tiempo promedio de recuperación y sincronización de 1 horas. Recomendamos tener 2 nodos de solo lectura en la región minoritaria, ya que ya están completamente sincronizados y la recuperación a un clúster completamente funcional tarda solo unos segundos o minutos.
Arquitectura de nodo 3, región 3(1+1+1)
Para cargas de trabajo menos críticas que toleran interrupciones, puede optar por una arquitectura más económica utilizando un nodo 1 en cada una de las 3 regiones. Tiene un nodo seleccionable en cada región, lo que significa que, si el nodo principal no está disponible, el clúster conmutará por error a una nueva región para garantizar la disponibilidad continua. Sin embargo, si la capa de aplicación en la región principal original sigue atendiendo las solicitudes de los usuarios, la latencia aumentará, ya que las solicitudes se enrutan entre varias regiones. Además, no será posible realizar una sincronización inicial optimizada al reconstruir un nodo.
Nota
Generalmente no recomendamos esta configuración porque el mantenimiento regular y planificado de los nodos Atlas provocará picos de latencia temporales.
Recomendaciones para implementaciones multirregionales
Para aprender a configurar implementaciones multirregionales y conocer los diferentes tipos de nodos que puede agregar, consulte Configurar alta disponibilidad y aislamiento de carga de trabajo en la documentación de Atlas.
Si su aplicación está implementada en uno de los siguientes proveedores de nube, MongoDB recomienda encarecidamente que implemente sus recursos de Atlas en ese mismo proveedor y región. Además, le sugerimos que asigne la implementación de los recursos de su aplicación entre regiones a la implementación de sus recursos de Atlas, como se muestra a continuación.
Desplegar los recursos de la aplicación junto a los recursos de Atlas:
Reduce la latencia de las operaciones de base de datos ejecutadas por su aplicación.
Permite una mayor seguridad con endpoints privados que conectan sus recursos de nube autogestionados con sus recursos de Atlas. Los endpoints privados ofrecen el máximo nivel de seguridad de red, garantizando que el tráfico solo se inicie desde su cuenta.
Le permite un control más granular sobre el almacenamiento de datos específicos de la región.
Le permite redirigir el tráfico a regiones saludables en caso de que ocurra una interrupción en otro lugar.
Para obtener más información sobre las recomendaciones de implementación de aplicaciones y Atlas, consulte:
Considerations
Azure admite vínculos privados entre regiones.
Puede crear un vínculo entre varias regiones sin necesidad de recursos de red adicionales que de otro modo serían necesarios.
Por ejemplo, si su aplicación está implementada en
central-usywest-us-3, y su clúster Atlas está implementado enwest-us-3yeast-us-2, puede crear un punto final privado encentral-usque se vincule al enlace privado enwest-us-3.
Para encontrar recomendaciones para sus implementaciones de nube Atlas, consulte los siguientes recursos:
Recomendaciones para organizaciones, proyectos y clústeres de Atlas
Operational Efficiency
Seguridad
Confiabilidad
Rendimiento
Cost Optimization