Las implementaciones multiregión de Atlas son clústeres establecidos en más de una región. Una implementación multirregional puede contar con varias regiones dentro de la misma geografía (un área grande, como un continente o país), o varias regiones en varias geografías. Implementaciones multiregión:
Mejore la protección en caso de una interrupción del servicio regional redirigiendo automáticamente el tráfico a otra región para una disponibilidad continua y una experiencia de usuario fluida.
Mejora el rendimiento y la disponibilidad de algunas aplicaciones al ubicar los datos más cerca de los usuarios.
Al considerar si una implementación multi-región es adecuada para ti, debes evaluar la criticidad de tu aplicación y cómo esto se corresponde con diferentes requisitos de RTO/RPO. La resiliencia existe en un espectro que va desde cero tiempo de inactividad con una implementación en multiregión hasta diferentes cronogramas de copia de seguridad en una implementación en una sola región. La compensación es un mayor costo por más disponibilidad.
Consulta la sección Confiabilidad para obtener más orientación sobre si una implementación multiregión es adecuada para tu carga de trabajo.
Nota
Las implementaciones multiregión están disponibles solo para clústeres dedicados de M10 y más grandes.
Estrategias de Implementación Multiregión
El siguiente diagrama muestra 2 ejemplos de una topología 2+2+1, que se analiza 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 5nodos y 3regiones (2+2+1)
Para lograr una recuperación casi instantánea en caso de una Interrupción del servicio regional, recomendamos una arquitectura que consta de un mínimo de 5 nodos repartidos en 3 regiones. Esta arquitectura garantiza que las operaciones regulares de mantenimiento puedan producirse sin forzar la conmutación por error a una segunda región, al tiempo que asegura la conmutación por error automatizada y la protección frente a la pérdida de datos en caso de incidente de Interrupción del servicio regional completa.
El siguiente diagrama muestra los detalles de esta arquitectura:
Notas y consideraciones
Utiliza nodos privados para conectarse al clúster y emparejamiento de VPC entre las VPC del servidor de su aplicación. El emparejamiento de VPC garantiza que, si se interrumpe una conexión de red o si Atlas en esa región se cae, el nivel de aplicación pueda seguir dirigiéndose al nodo principal, primero mediante el emparejamiento de VPC y luego a través del nodo 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 mayor resiliencia. No hay interrupciones durante las operaciones de Atlas (como una actualización automatizada), y tu aplicación puede soportar una falla regional completa sin interrupciones ni intervención manual.
Arquitectura 5-Nodo, 2-Región (2+3)
Si su empresa está limitada a solo 2 regiones, puede usar una variante de la arquitectura 5-Nodos y 3-Regiones, en la que tiene 5 nodos distribuidos entre dos regiones. La región primaria tiene 2 nodos elegibles y la región secundaria tiene 1 nodo elegible y 2 nodos de solo lectura (sin derecho a voto).
Esto generalmente no se recomienda si se pueden usar regiones 3 porque el operador debe intervenir manualmente para realizar un conmutación por error si la región de mayoría falla. Sin embargo, es una opción para clientes con solo 2 regiones aprobadas.
Notas y consideraciones
Esta arquitectura proporciona una mayor protección contra la pérdida de datos. Si se pierde la región minoritaria, no se requiere ninguna acción del usuario porque 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 pasen a un estado elegible. Sin embargo, es posible que no proporcione una protección completa contra la pérdida de datos si algunos datos aún no se han replicado en un nodo secundario después de un error. En este caso, los datos no estarán disponibles hasta que se recupere la región primaria.
Esta arquitectura viene con algunas advertencias:
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.
Como no hay una mayoría de nodos con derecho a voto, no hay un primario y sólo puede aceptar lecturas (no escrituras).
Para restaurar el clúster funcional, un administrador debe reconfigurar los 2 nodos de solo lectura a nodos elegibles. Sin embargo, la pérdida de datos es posible. Durante la Interrupción del servicio, cualquier nueva escritura en los secundarios se coloca en una colección especial para su recuperación manual. Sin embargo, cualquier escritura en el primario que no se haya replicado a al menos un nodo secundario antes de que el primario caiga se pierde.Para obtener más información, consulta Reconfigurar un set de réplicas Durante una Interrupción del servicio o utiliza el parámetro de la API acceptDataRisksAndForceReplicaSetReconfig.
En los clústeres particionados, si tu proceso de MongoDB no replico las migraciones de fragmentos, la incongruencia de datos podría causar documentos huérfanos.
Variación de menor costo
Para un mayor ahorro de costos, puedes diseñar esta arquitectura sin los nodos 2 de solo lectura. Además de las advertencias enumeradas anteriormente, el tamaño de los datos tiene un impacto significativo en tu decisión, ya que los datos deben sincronizarse con los secundarios cada vez que se añaden nuevos nodos al clúster. Por ejemplo, 1 TB de datos promedian 1 horas de recuperación y tiempo de sincronización. Recomendamos tener 2 nodos de solo lectura en la región minoritaria porque ya están completamente sincronizados, y la recuperación a un clúster totalmente funcional toma solo segundos o minutos.
Arquitectura de 3nodos y 3regiones (1+1+1)
Para cargas de trabajo menos críticas que puedan tolerar interrupciones, puedes aprovechar una arquitectura menos costosa utilizando 1 nodo en cada una de las 3 regiones. Tienes un nodo elegible en cada una de las regiones, lo que significa que si el nodo primario no está disponible, tu clúster pasará a una nueva región para garantizar la disponibilidad continua. Sin embargo, si tu nivel de aplicación en la región principal original sigue atendiendo solicitudes de usuarios, se producirá una mayor latencia ya que las solicitudes se enrutan entre varias regiones. Además, no habrá capacidad de realizar una sincronización inicial optimizada en caso de reconstruir un nodo.
Nota
En general, no recomendamos esta configuración porque el mantenimiento regular y planificado de los nodos de Atlas provocará picos temporales de latencia.
Recomendaciones para implementaciones en multiregión
Para obtener información sobre cómo configurar implementaciones multirregionales y conocer los diferentes tipos de nodos que puede agregar, consulte Configurar la alta disponibilidad y el aislamiento de cargas de trabajo en la documentación de Atlas.
Para automatizar la implementación multirregional usando Terraform, consulta el Módulo de Clúster de MongoDB Atlas.
Si tu aplicación está implementada en uno de los siguientes proveedores de nube, MongoDB recomienda firmemente que implementes tus recursos de Atlas en el mismo proveedor y región. Además, sugerimos que mapees la implementación de los recursos de tu aplicación en las regiones a la implementación de tus 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 mayor seguridad mediante nodos privados que conectan tus recursos en la nube autogestionados con tus recursos de Atlas. Los nodos privados ofrecen el mejor nivel de seguridad de red, asegurando que el tráfico solo pueda iniciarse desde tu cuenta.
Te permite un control más granular sobre el almacenamiento de datos específicos de la región.
Te permite desviar el tráfico a regiones operativas en caso de que se produzca una interrupción del servicio en otro lugar.
Para obtener más información sobre aplicaciones y recomendaciones de implementación de Atlas, consulta:
Considerations
Azure admite enlaces privados entre regiones.
Puedes crear un enlace entre varias regiones sin necesidad de recursos de red adicionales que, de otro modo, serían necesarios.
Por ejemplo, si tu aplicación se implementa en
central-usywest-us-3, y tu clúster de Atlas se implementa enwest-us-3yeast-us-2, puedes crear un nodo privado encentral-usque esté enlazado al enlace privado enwest-us-3.
Para encontrar recomendaciones para tus implementaciones en la nube de Atlas, consulta los siguientes recursos:
Operational Efficiency
Cost Optimization