Arquitectura multi-clúster

Modo de Clúster Único y Múltiple

Puede controlar la moda en la que implementa los recursos de MongoDB con el operador de Kubernetes con las siguientes configuraciones:

• spec.topology — controla el modo de la aplicación de Ops Manager.

• spec.applicationDatabase.topology — controla el modo de la base de datos de la aplicación.

Si estableces spec.topology y spec.applicationDatabase.topology en MultiCluster, se habilita el modo de clúster múltiple para el recurso de MongoDB Ops Manager y su base de datos de la aplicación, como se muestra en el siguiente ejemplo:

spec:
  topology: MultiCluster
  applicationDatabase:
    topology: MultiCluster

En el modo de clúster múltiple, puede comenzar con un clúster de un solo nodo y escalar según sea necesario. Específicamente:

• Inicio de clúster de un solo nodo: una implementación puede comenzar con un clúster de un solo nodo.

• Set de réplicas de la base de datos de la aplicación mínimo: un set de réplicas de la base de datos de la aplicación de 3nodos mínimo puede ejecutarse en un clúster de un solo nodo y, a continuación, expandirse a través de los clúster más tarde.

• Instancia de aplicación única: una sola instancia de aplicación de Ops Manager puede ejecutarse en un clúster, con clústeres adicionales agregados más tarde.

En el modo de clúster único (el predeterminado), omita la configuración de topología o establézcala en SingleCluster.

Limitaciones de la implementación en múltiples clústeres

Las siguientes limitaciones se aplican a las implementaciones de varios clústeres:

• Use versiones de Ops Manager posteriores a 5.0.7.

• Utilice únicamente secretos para el almacenamiento de secretos. HashiCorp Vault no es compatible.

• Para implementaciones en las que el operador de Kubernetes no gestiona los recursos MongoDBOpsManager y MongoDB, debes configurar manualmente la configuración de cifrado de copia de seguridad de KMIP en MongoDB Ops Manager.

• No agregue un ServiceMonitor a los recursos MongoDBMultiCluster. La integración de Prometheus no es compatible.

• No puede migrar recursos existentes de MongoDB de clúster único a recursos de clúster múltiple.

Diferencias entre implementaciones de clúster único y multiclúster

Diagramas de implementación de recursos de base de datos MongoDB de clúster múltiple

Puede crear implementaciones de MongoDB de clúster múltiple con o sin una malla de servicios.

En ambos casos, el operador de Kubernetes:

• Monitorea la especificación MongoDBMultiCluster en el clúster del operador.

• Utiliza el kubeconfig montado para comunicarse con los clústeres de nodos.

• Crea ConfigMaps, Secrets, Services y StatefulSets en cada clúster de nodos.

• Implementa nodos de set de réplicas de MongoDB en los clústeres adecuados.

• Observa los eventos del clúster del operador y del clúster de nodos.

• Reconcilia los recursos para confirmar el estado deseado.

Una implementación multi-Kubernetes clúster MongoDB que utiliza los Controladores MongoDB para el operador Kubernetes consiste en un clúster operador y uno o más nodos clúster en Kubernetes:

• El clúster de operadores tiene el siguiente rol:

  • Aloja los controladores MongoDB para el operador Kubernetes

  • Actúa como el plano de control para la implementación multi-Kubernetes de MongoDB

  • Aloja la especificación de recursos MongoDBMultiCluster para el set de réplicas de MongoDB.

  • Hospeda a Ops Manager, si implementas Ops Manager con Kubernetes operador

  • También puede alojar nodos del set de réplicas de MongoDB

  Importante

  El clúster central también se conoce como el clúster del operador. Es posible que en futuras versiones, las referencias al clúster central sean renombradas para referirse al clúster del operador.

• Los nodos clústeres alojan los conjuntos de réplicas de MongoDB.

Con una malla de servicio

La malla de servicios gestiona la detección de nodos de MongoDB en todos los clústeres y gestiona la comunicación entre nodos. El siguiente diagrama ilustra una implementación de varios clústeres con una malla de servicios:

haga clic para ampliar

Sin Service Mesh

Los dominios externos y las zonas DNS gestionan la comunicación entre clústeres. Consulte Habilitar la conectividad externa a través de dominios externos y zonas DNS. El siguiente diagrama ilustra una implementación multiclúster sin un Service Mesh:

haga clic para ampliar

Diagrama de implementación de recursos de MongoDB Ops Manager de clúster múltiple

El siguiente diagrama muestra la aplicación MongoDB Ops Manager, la base de datos de la aplicación y el daemon de copias de seguridad implementados en varios clústeres de Kubernetes:

Elementos clave de una implementación de MongoDB Ops Manager con múltiples clústeres:

1. El clúster del operador (por ejemplo, el clúster de nodo 0) almacena el secreto kubeconfig (mongodb-enterprise-operator-multi-cluster-kubeconfig) y los ConfigMaps de asignación de clústeres utilizados para gestionar todos los clústeres de nodo.

2. Los ConfigMaps de asignación de clústeres rastrean la relación entre los nombres de los clústeres y los índices:

   • <om_resource_name>-cluster-mapping — asigna spec.clusterSpecList entradas a índices de clúster.

   • <om_resource_name>-db-cluster-mapping — asigna spec.applicationDatabase.clusterSpecList entradas a índices de clúster.

   • <om_resource_name>-db-member-spec — registra el recuento de réplicas por clúster para la recuperación ante desastres.

3. Los StatefulSets de aplicación se denominan <om_resource_name>-<cluster_index> en cada clúster. El operador crea un servicio ClusterIP (<om_resource_name>-svc) que contiene todos los Pods locales, además de un servicio LoadBalancer opcional (<om_resource_name>-svc-ext) para el acceso externo.

4. Los StatefulSets de la base de datos de la aplicación se denominan <om_resource_name>-db-<cluster_index>. Los servicios por pod (<om_resource_name>-db-<cluster_index>-<pod_index>-svc) permiten la direccionabilidad individual de mongod en toda la malla de servicios.

5. Los daemon de copias de seguridad StatefulSets se denominan <om_resource_name>-backup-daemon-<cluster_index>, creados si spec.backup.enabled es true.

Redes de varios clústeres

Equilibrio de carga para implementaciones de MongoDB Ops Manager con múltiples clústeres

Para implementaciones de Ops Manager de varios clústeres, cada clúster puede exponer sus pods de aplicación de Ops Manager de forma individual utilizando un servicio de tipo LoadBalancer. Cree este servicio utilizando spec.externalConnectivity y apunte un dominio externo a su dirección IP externa. Para obtener más información sobre la configuración del equilibrio de carga en implementaciones de varios clústeres, consulte Requisitos de malla de servicio para implementaciones de Ops Manager de varios clústeres.

Dado que el Operador de Kubernetes no admite el equilibrio de carga entre clústeres de forma nativa, debe configurar el equilibrio de carga externamente. Existen los siguientes enfoques para habilitar el equilibrio de carga entre clústeres para las implementaciones de Ops Manager:

• Balanceador de carga externo: Configure un balanceador de carga de red externo (proxy de paso) para todos los clústeres que alojan la aplicación MongoDB Ops Manager. El balanceador de carga reenvía el tráfico al servicio LoadBalancer de cada clúster de forma rotatoria. El siguiente diagrama ilustra este enfoque:

haga clic para ampliar

• Malla de servicio con proxy: utilice el equilibrio de carga entre clúster de la malla de servicio. Implemente un proxy (como Nginx o HAProxy) en un clúster, expóngalo externamente y configure el paso de TCP a <om_resource_name>-svc.<namespace>.svc.cluster.local. El siguiente diagrama ilustra este enfoque:

haga clic para ampliar

Consideraciones de rendimiento de clúster múltiple para implementaciones de MongoDB Ops Manager

La distribución geográfica de la base de datos de la aplicación y las instancias de Ops Manager puede afectar el rendimiento de la aplicación de Ops Manager y los procesos de copia de seguridad y restauración. Consulte Rendimiento en implementaciones multiregión.

Para maximizar los beneficios de la resiliencia y la disponibilidad de varios clústeres, implemente todos los componentes en la misma área geográfica siempre que sea posible.

Las fuentes de posible degradación del rendimiento incluyen:

• Mayor latencia de red entre la aplicación de Ops Manager y el nodo de base de datos de la aplicación principal.

• Mayor latencia entre los nodos de la base de datos MongoDB y la aplicación Ops Manager que realiza tareas de copia de seguridad.

Si planea implementaciones geográficamente distantes, póngase en contacto con el soporte de MongoDB para obtener ayuda.

Capacidades de recursos de base de datos de MongoDB de varios clúster

Las siguientes capacidades de varios clústeres utilizan los mismos procedimientos que las implementaciones de un solo clúster:

• Conectarse con registros DNS SRV: Utilice la cadena de conexión de la lista de nodos iniciales de DNS connectionString.standardSrv del secreto que crea el operador de Kubernetes. Consulte Conectarse a un recurso de base de datos MongoDB desde el interior de Kubernetes y seleccione la pestaña Using the Kubernetes Secret.

• Gestionar la seguridad para usuarios de base de datos: utilice los mismos procedimientos de autenticación LDAP, SCRAM, X.509 y OIDC que las implementaciones de clúster único, con las siguientes excepciones:

  • Los procedimientos de clústeres múltiples solo se aplican a los sets de réplicas (no se admiten clústeres particionados).

  • En mongodbResourceRef, especifique el nombre del set de réplicas de varios clústeres.

• Respaldos consultables (clúster único |onprem| únicamente): si Ops Manager se implementa en un solo clúster, puede configurar respaldos consultables. Los respaldos consultables no son compatibles con las implementaciones de Ops Manager de varios clúster.