Arquitectura multi-clúster

Modo de Clúster Único y Múltiple

Puedes controlar el modo en el que implementas los recursos de MongoDB con el operador de Kubernetes mediante la siguiente configuración:

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

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

Si establece tanto spec.topology como spec.applicationDatabase.topology en MultiCluster, esto habilita el modo multiclúster para el recurso Ops Manager y su base de datos de aplicaciones, como se muestra en el siguiente ejemplo:

spec:
  topology: MultiCluster
  applicationDatabase:
    topology: MultiCluster

En el modo multiclúster, puede comenzar con un clúster de un solo miembro y escalarlo según sea necesario. Específicamente:

• Inicio de clúster de un solo miembro: Un despliegue puede comenzar con un clúster de un solo miembro.

• Conjunto mínimo de 3réplicas de la base de datos de la aplicación: Un conjunto mínimo de réplicas de la base de datos de la aplicación de miembros puede ejecutarse en un clúster de un solo miembro y luego expandirse a través de clústeres posteriormente.

• Instancia única de la aplicación: Una única instancia de la aplicación Ops Manager puede ejecutarse en un clúster, y posteriormente se pueden añadir clústeres adicionales.

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 clústeres múltiples

Las siguientes limitaciones se aplican a las implementaciones en clústeres múltiples:

• Use versiones de Ops Manager posteriores a 5.0.7.

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

• Para implementaciones en las que el operador de Kubernetes no gestiona los MongoDBOpsManager MongoDB recursos y, debe configurar manualmente los ajustes de cifrado de copia de seguridad de KMIP en Ops Manager.

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

• No es posible migrar recursos de MongoDB existentes de un solo clúster a recursos de varios clústeres.

Diferencias entre implementaciones de clúster único y de clúster múltiple

Diagramas de despliegue de recursos de bases de datos MongoDB en clústeres múltiples

Puedes crear implementaciones de MongoDB en varios clústeres con o sin malla de servicios.

En ambos casos, el operador de Kubernetes:

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

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

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

• Implementa los miembros del conjunto de réplicas de MongoDB en los clústeres correspondientes.

• Monitorea los eventos del clúster del operador y del clúster miembro.

• Concilia 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 servicios

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

haga clic para ampliar

Sin una malla de servicios

Los dominios externos y las zonas DNS gestionan la comunicación entre clústeres.Consulte Habilitar la conectividad externa mediante dominios externos y zonas DNS. El siguiente diagrama ilustra una implementación de varios clústeres sin malla de servicios:

haga clic para ampliar

Diagrama de despliegue de recursos de Multi-Cluster Ops Manager

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

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

1. Elclúster del 0 kubeconfig operador (por ejemplo, el clúster miembro) almacena el secretomongodb-enterprise-operator-multi-cluster-kubeconfig () y los ConfigMaps de asignación de clústeres utilizados para administrar todos los clústeres miembros.

2. LosConfigMaps 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 entradas spec.clusterSpecList a índices de clúster.

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

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

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

4. Los StatefulSets de labase de datos <om_resource_name>-db-<cluster_index> de la aplicación se denominan. Los servicios por Pod<om_resource_name>-db-<cluster_index>-<pod_index>-svc () permiten el mongod direccionamiento individual a través de la malla de servicios.

5. LosStatefulSets del demonio de respaldo se <om_resource_name>-backup-daemon-<cluster_index> denominan, se crean spec.backup.enabled si true es.

Redes multiclúster

Balanceo de carga para implementaciones de Ops Manager en clústeres múltiples

Para implementaciones de Ops Manager en varios clústeres, cada clúster puede exponer sus pods de aplicación de Ops Manager individualmente mediante un LoadBalancerservicio de tipo. Cree este servicio con spec.externalConnectivity y apunte un dominio externo a su dirección IP externa. Para obtener más información sobre la configuración del balanceo de carga en implementaciones de varios clústeres, consulte Requisitos de Service Mesh para implementaciones de Ops Manager en varios clústeres.

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

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

haga clic para ampliar

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

haga clic para ampliar

Consideraciones de rendimiento en clústeres múltiples para implementaciones de Ops Manager

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

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

Entre las posibles causas de degradación del rendimiento se incluyen:

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

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

Si tiene previsto realizar implementaciones en ubicaciones geográficamente distantes, póngase en contacto con el soporte técnico de MongoDB para obtener ayuda.

Capacidades de recursos de la base de datos MongoDB multiclúster

Las siguientes funcionalidades de clúster múltiple utilizan los mismos procedimientos que las implementaciones de clúster único:

• Conéctese con registros DNS SRV: utilice la connectionString.standardSrv cadena de conexión de la lista de semillas DNS del secreto que crea el operador de Kubernetes. Consulte Conectarse a un recurso de base de datos MongoDB desde dentro de Kubernetes y seleccione la Using the Kubernetes Secret pestaña.

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

  • Los procedimientos multiclúster se aplican únicamente a conjuntos de réplicas (no se admiten clústeres fragmentados).

  • En mongodbResourceRef, especifique el nombre del conjunto de réplicas de clúster múltiple.

• Copias de seguridad consultables (solo en clúster único |local|): Si Ops Manager se implementa en un clúster único, puede configurar copias de seguridad consultables. Las copias de seguridad consultables no son compatibles con implementaciones de Ops Manager en varios clústeres.