Elegir un paradigma de implementación requiere considerar las necesidades de la aplicación en cuanto a disponibilidad (tanto en general como en caso de una Interrupción del servicio), latencia, cumplimiento de normativas y costo. No existe un único paradigma 'correcto' para la implementación. Esta sección explora las arquitecturas disponibles para ayudarte a satisfacer tus necesidades de implementación.
Al implementar su base de datos, primero debe elegir entre implementarla en una sola región o en varias. El siguiente diagrama muestra estas opciones, que se explican con más detalle a continuación:
Implementaciones de una sola región
A Laimplementación de una sola región es la opción más sencilla. En una implementación de una sola región, los datos se almacenan en una de las regiones de un proveedor (como la de AWS). us-west-2
o del asia-northeast3 de Google). Para aquellas regiones que cuentan con múltiples zonas, Atlas siempre proporciona disponibilidad a nivel de zona. Los nodos de tu clúster están distribuidos en las zonas de disponibilidad dentro de una región única. Por lo tanto, si una sola zona falla, tus datos siguen estando disponibles en las otras zonas.
Nota
Las regiones recomendadas tienen tres zonas de disponibilidad y están marcadas con un ícono de estrella en la interfaz de usuario de Atlas.
Con la simplicidad y el menor costo de una implementación en una sola región conlleva el riesgo de una menor disponibilidad y, potencialmente, una mayor latencia, dependiendo de la distribución de los usuarios de la aplicación.
Implementaciones multiregión
Una implementación multirregional es un paradigma de implementación más complejo que proporciona mayor disponibilidad y baja latencia en un rango geográfico mayor que una implementación monorregional. Existen varios tipos de implementaciones multirregionales:
Multi-región en una geografía: Se implementa en múltiples regiones alojadas por un único proveedor de nube dentro de una única geografía, definida como un área grande como un país o un continente. Esto garantiza la disponibilidad en caso de que alguna región falle.
Por ejemplo, implementa clústeres en el Las regiones de AWS
us-west-1yus-east-1, ambas en los Estados Unidos. Sius-east-1deja de estar disponible,us-west-1seguirá aceptando lecturas y guardados con un rendimiento cercano al normal.Multirregión en múltiples geografías: Implementa en una o más regiones de dos o más geografías. Esto garantiza la disponibilidad si falla una región o si un área geográfica completa no está disponible.
Por ejemplo, implementas clústeres en las regiones AWS
us-east-1yus-east-2, ambas en los Estados Unidos, y un tercer clúster eneu-west-2, que está en Europa.Multi-nube : Despliegue en una o más regiones alojadas por múltiples proveedores de nube. Esto proporciona el mayor nivel de disponibilidad, asegurando que tus datos estén disponibles si alguna región falla o si falla un proveedor de nube completo.
Por ejemplo, se despliegan clústeres en la región AWS
us-west-1y la región de Google Cloudus-east4.
Consideraciones de disponibilidad
La disponibilidad suele considerarse en términos de la resistencia de tus clústeres a las interrupciones, mientras que la recuperación ante desastres se refiere a la rapidez con que tu sistema puede recuperarse de una interrupción del servicio (RTO) y a la cantidad de datos que podrían perderse en una interrupción del servicio (RPO). Porque todas las instancias de Atlas siempre cuentan con datos actualizados, los failovers no requieren la restauración de copias de seguridad.
Atlas tiene la replicación integrada en tus implementaciones, lo que significa:
Las instancias de base de datos se mantienen estrechamente sincronizadas entre sí, generalmente en el rango de milisegundos.
En caso de una Interrupción del servicio, el cambio por falla entre instancias de bases de datos es completamente automático. No requiere intervención humana y sólo lleva unos segundos.
Al usar la configuración por defecto writeConcern de,
majorityno se produce pérdida de datos durante la conmutación por error, ya que todos los datos se escribieron en múltiples ubicaciones, lo que evita la pérdida de datos. Además, el controlador de la base de datos reintentará automáticamente cualquier operación en curso para garantizar su éxito.
Esto significa que el RTO, el RPO y la frecuencia de replicación de datos son efectivamente iguales y sus clústeres Atlas están completamente operativos siempre que la mayoría de los nodos estén en buen estado.
Nota
El RTO y el RPO máximos deben considerarse de forma integral, tanto para todo el clúster como para la implementación de la aplicación. Considere la carga de trabajo total del clúster para garantizar que cumpla con sus requisitos.
Comparación de paradigmas de implementación
Para determinar qué patrón de implementación es el adecuado para usted, desglose sus aplicaciones según su importancia para su negocio principal. Cuanto más importante sea la aplicación (es decir, cuanto mayor sea el impacto de una interrupción en su negocio), más debería considerar una arquitectura que gestione automáticamente cualquier interrupción.
La siguiente tabla proporciona una comparación de paradigmas de implementación para ayudarlo a determinar cuál se adapta mejor a sus necesidades:
Nivel de prioridad | Descripción | RTO | Modelo de implementación | Costo relativo |
|---|---|---|---|---|
Nivel 0 | Aplicaciones de la mayor criticidad. Requiere conmutación por error completamente automática incluso en evento de interrupciones del servicio regionales. | 0 | $$$ | |
Nivel 1 | Aplicaciones de criticidad menor. Puede experimentar algunos periodos de inactividad o periodos de mantenimiento sin un impacto significativo en las ganancias. | > 1 hora y < 8 horas | $$ | |
Nivel 2 | Aplicaciones de menor criticidad. Pueden estar inactivas durante 24 horas sin afectar significativamente los ingresos. | > 8 horas | $+ | |
No producción | Aplicaciones no críticas. Entornos que no son directamente responsables de la ganancia ni están orientados al cliente. Normalmente entornos de desarrollo y prueba. | N/A | $0 en adelante |
Nota
El costo de cada tipo de implementación depende de varios factores, incluido el(los) proveedor(es) que selecciones, el número de regiones que necesites, la cantidad de almacenamiento y la potencia de procesamiento de los servidores. Para obtener la información de precios más reciente, consulta Precios de MongoDB.
Casos de uso
Al elegir su paradigma de implementación, comience por identificar la menor cantidad de regiones posibles para atender a la mayor distribución geográfica de sus usuarios. Luego, considere agregar regiones o proveedores de nube adicionales según sus requisitos de disponibilidad, rendimiento y soberanía de datos.
Considera los siguientes casos de uso para ayudar a decidir qué paradigma de implementación se adapta mejor a la distribución geográfica de los usuarios de tu aplicación:
Usuarios mayormente en una sola geografía
Si la mayoría de los usuarios de tu aplicación se encuentran en una geografía, te recomendamos que la implementes en una o más regiones dentro de la misma geografía. Mientras que una implementación de una sola región puede proteger contra una interrupción del servicio en una sola zona de disponibilidad, una implementación multiregión cubre una área geográfica más grande y garantiza la disponibilidad tanto durante interrupciones del servicio zonales como regionales. Para una disponibilidad aún mayor, puedes implementar en varias regiones. Todas estas opciones admiten baja latencia y simplifican el cumplimiento de los requisitos de soberanía de datos porque todos los datos de los usuarios se acceden y almacenan dentro de la misma geografía.
Para aprender más sobre estos paradigmas de implementación, consulte las siguientes páginas de paradigmas:
Usuarios distribuidos en múltiples geografías
Si los usuarios de tu aplicación están distribuidos en varias geografías, como entre EE. UU. y Europa, te recomendamos implementar en una o más regiones en cada geografía. El despliegue en una región de cada zona geográfica donde se atienden clientes garantiza baja latencia y disponibilidad en caso de una interrupción del servicio geográfica. También puede cumplir con los requisitos de soberanía de datos al realizar el particionamiento de sus datos para que los datos de los usuarios de cada región se alojen dentro de esa región.
Para garantizar una alta disponibilidad en caso de interrupciones regionales sin aumentar la latencia ni violar los requisitos de soberanía de los datos, también puedes implementar en varias regiones de cada zona geográfica. Se puede lograr la mayor disponibilidad para una implementación multiregión al implementar clústeres en múltiples regiones, en diferentes ubicaciones geográficas.
Para aprender más sobre estos paradigmas de implementación, consulte las siguientes páginas de paradigmas:
Usuarios distribuidos en todo el mundo
Si va a implementar una aplicación para un público mundial, le recomendamos implementar una implementación multirregional en varias zonas geográficas antes de considerar una implementación global. En casi todos los casos, una implementación multirregional en varias zonas geográficas puede satisfacer sus requisitos de alta disponibilidad, baja latencia y soberanía de datos. En casos excepcionales, podría necesitar implementaciones Atlas globales, que son los paradigmas de implementación multirregional más complejos y requieren una planificación muy minuciosa.
Para aprender más sobre estos paradigmas de implementación, consulta las siguientes páginas: