Diagrama de arquitetura de vários clusters: MongoDB Ops Manager e o banco de dados de aplicativos

O diagrama a seguir mostra o Aplicativo de Ops Manager, o Banco de Dados do Aplicativo, o Backup Daemon e os Volumes persistentes correspondentes distribuídos em vários clusters do Kubernetes.

Neste diagrama:

1. O Member Cluster 0 também é o cluster central porque você instala o Kubernetes operador nele. Ele também é um cluster de nós e pode hospedar qualquer recurso personalizado de vários clusters.

2. O Member Cluster 0 armazena os arquivos kubeconfig, que descrevem a configuração do Kubernetes para clusters de membros, usuários e contextos. Quando você configura o Operador Kubernetes para sistemas de vários clusters usando o plugin-in kubectl mongodb, ele cria o seguinte recurso:

   • O segredo mongodb-enterprise-operator-multi-cluster-kubeconfig, que contém as credenciais para todos os cluster Kubernetes que o operador Kubernetes vai gerenciar. Se você planeja usar o cluster central como um cluster nó, este segredo pode conter as credenciais para o mesmo cluster onde você instala o Kubernetes operador.

   Quando o Operador Kubernetes é executado no modo de vários clusters, ele armazena os recursos necessários, como ConfigMaps e segredos sobre os clusters que ele vai gerenciar. Estes recursos pertencem ao mesmo namespace que o Operador Kubernetes. O Operador do Kubernetes usa esses recursos para implantar o Aplicativo de MongoDB Ops Manager e o Banco de Dados de Aplicativos em vários clusters do Kubernetes .

3. O Operador Kubernetes também cria e mantém alguns ConfigMaps adicionais de estado de implantação de vários clusters para cada aplicativo MongoDB Ops Manager e sistema de banco de dados de aplicativos que gerencia. O Member Cluster 0 armazena esta configuração, que inclui os seguintes ConfigMaps:

   • O <om_resource_name>-cluster-mapping ConfigMap contém o mapeamento de nomes de cluster de membros listados em spec.clusterSpecList para índices de cluster, referenciados nesta documentação como cluster_index, como Cluster 0 ou Cluster 1. O Operador Kubernetes atribui estes índices a cada nome de cluster.

   • O <om_resource_name>-db-cluster-mapping ConfigMap contém o mapeamento dos nomes do cluster de membros listados em spec.applicationDatabase.clusterSpecList para índices de cluster.

   • O <om_resource_name>-db-member-spec ConfigMap contém o número de réplicas do Banco de Dados de Aplicativo configurados para cada agrupamento de membro. Ter essas informações permite que o operador do Kubernetes dimensione ou reconfigure corretamente o conjunto de réplicas como parte da recuperação de desastres, como após a perda de todo o cluster de membros.

4. A configuração do recurso MongoDBOpsManager é um arquivo que você cria e que descreve um sistema do MongoDB Ops Manager de vários clusters. O Operador Kubernetes usa este arquivo para implantar os componentes do MongoDB Ops Manager .

   O exemplo a seguir mostra a configuração que leva o Operador Kubernetes a implantar os componentes do MongoDB Ops Manager descritos neste diagrama. Este exemplo omite algumas configurações que não são relevantes para este diagrama, como a configuração TLS .

   1
   apiVersion: mongodb.com/v1
   2
   kind: MongoDBOpsManager
   3
   metadata:
   4
     name: om
   5
     namespace: om-ns
   6
   spec:
   7
     replicas: 1 # You can set this value and use it as a global or default
   8
                 # setting for all clusters. The spec.clusterSpecList.members
   9
                 # setting overrides this setting.
   10
     topology: MultiCluster
   11
     version: 8.0.0
   12
     adminCredentials: om-admin-secret
   13
     clusterSpecList:
   14
       - clusterName: "Member Cluster 1" # Ops Manager settings for "Member Cluster 1"
   15
         members: 2
   16
         backup: # Backup settings for "Member Cluster 1"
   17
           members: 2 # Overrides spec.backup.members
   18
       - clusterName: "Member Cluster 2" # Ops Manager settings for "Member Cluster 2"
   19
         members: 1
   20
         backup: # Backup settings for "Member Cluster 2"
   21
           members: 2 # Overrides spec.backup.members
   22
     applicationDatabase: # Global {+appdb+} settings
   23
       topology: MultiCluster
   24
       version: 8.0.0
   25
       members: 3 # In multi-cluster mode, the Operator ignores this field.
   26
                  # The Operator sets the number of members for the Application
   27
                  # Database in spec.applicationDatabase.clusterSpecList.members.
   28
       clusterSpecList:
   29
         - clusterName: "Member Cluster 1"
   30
           members: 3
   31
         - clusterName: "Member Cluster 2"
   32
           members: 2
   33
     backup: # Global settings for the Backup Daemon
   34
       enabled: true
   35
       members: 1 # Set this value and use it as a global or default setting.
   36
                  # To override this value, set the value for
   37
                  # spec.clusterSpecList.backup.members.
   38
                  # The Backup Daemon's configuration for each cluster isn't
   39
                  # stored here. Use the Ops Manager's spec.clusterSpecList.backup to
   40
                  # specify the Backup Daemon configuration for each member cluster.

5. O operador Kubernetes se conecta às instâncias do MongoDB Ops Manager fazendo referência a:

   • O padrão FQDN do serviço que ele cria para o recurso do MongoDB Ops Manager, <om_resource_name>-svc.<namespace>.svc.cluster.local, ou

   • A URL que você especifica em spec.opsManagerURL. Em algumas implantações, como quando o cluster onde você instalou o operador Kubernetes não está anexado à malha de serviço, o FQDN de serviço padrão pode estar inacessível. Nesse caso, o operador do Kubernetes relata o status do recurso MongoDBOpsManager como Failed, indicando um erro de conexão. Para levar em conta esses casos, forneça a URL para o Ops Manager no spec.opsManagerURL. Esta URL pode ser um nome de host de uma instância do Ops Manager exposta externamente. Para saber mais, consulte Visão geral de rede.

6. Two member clusters host the Ops Manager Application. In each cluster, the Kubernetes Operator deploys a StatefulSet named <om_resource_name>-<cluster_index>.

   • O StatefulSet implementa duas instâncias do Aplicativo MongoDB Ops Manager no Member Cluster 1 e uma instância no Member Cluster 2.

   • Você define o número de instâncias no spec.clusterSpecList.members. Você pode definir o número de instâncias como zero para que esse cluster não implante nenhuma instância do Aplicativo de MongoDB Ops Manager . Isso é útil se, por exemplo, você quiser usar esse cluster para hospedar apenas instâncias do Backup Daemon .

     Se você remover um cluster de spec.clusterSpecList, isso será equivalente a especificar zero nós em spec.clusterSpecList.members e spec.clusterSpecList[*].backup.members.

   • Para cada StatefulSet em cada cluster, o Operador Kubernetes configura um serviço do tipo ClusterIP, denominado <om_resource_name>-svc, que contém todos os Pods na lista de endpoints do cluster. O FQDN, <om_resource_name>-svc.<namespace>.svc.cluster.local deste serviço é um nome de host padrão que o Operador do Kubernetes usa para acessar o endpoint implementado para o Aplicativo Ops Manager.

   • Se você especificar spec.externalConnectivity, o Operador Kubernetes também criará um serviço externo do tipo Kubernetes LoadBalancer , chamado <om_resource_name>-svc-ext, para cada cluster. Em cada cluster, você pode especificar sua própria configuração para esse serviço externo usando spec.clusterSpecList.externalConnectivity. Por exemplo, você pode alterar o tipo do serviço ou definir anotações.

7. Banco de Dados de Aplicativos. O Operador Kubernetes implementa o Banco de Dados de Aplicativo em dois clusters.

   • The Member Cluster 1 contains three mongod processes for the Application Database, and the Member Cluster 2 contains two mongod processes..

   • You define the Application Database configuration using the spec.applicationDatabase settings. On each member cluster, the Kubernetes Operator creates a StatefulSet named <om_resource_name>-db-<cluster_index> with the number of member clusters defined in spec.applicationDatabase.clusterSpecList.members. In multi-cluster mode, the Kubernetes Operator ignores values that you set for the spec.applicationDatabase.members field. The Kubernetes Operator configures one replica set formed from mongod processes deployed across all member clusters.

   • For each Pod in <statefulset_name>-<pod_index> hosting a MongoDB process named <om_resource_name>-db-<cluster_index>-<pod_index>, the Kubernetes Operator creates a Kubernetes ClusterIP-type service for accessing the individual mongod processes by its FQDN, <om_resource_name>-db-<cluster_index>-<pod_index>-svc. Each mongod process in the replica set must be uniquely addressable.

     Os processos na configuração do conjunto de réplicas devem ter seus nomes de host de processo configurados para o FQDN desse serviço de Pod: <om_resource_name>-db-<cluster_index>-<pod_index>-svc.<namespace>.svc.cluster.local.

   • Cada Pod tem seu volume persistente anexado por meio de uma Declaração de Volume Persistente que o Operador Kubernetes cria.

   • To form a replica set from all mongod processes, each process must connect to each other process for replication purposes. To achieve this, include all member clusters on which you deploy the Application Database into the same service mesh configuration.

     A mesclagem de serviço lida com queries de DNS entre clusters e roteia o tráfego adequadamente. A malha de serviço ajuda a resolver o FQDN <om_resource_name>-db-<cluster_index>-<pod-index>-svc.<namespace>.svc.cluster.local de cada serviço de Pod em todos os clusters e permite a conectividade na porta mongod exposta (27017 por padrão).

     For example, when a mongod process running in the om-db-1-0 Pod in Member Cluster 1 connects to a mongod running in the om-db-2-1 Pod in Member Cluster 2, the first mongod process uses its hostname from the Automation Configuration, om-db-2-1-svc.om-ns.svc.cluster.local:27017, and the service mesh routes this request to Member Cluster 2 to the om-db-2-1-svc service. Without the service mesh, the Kubernetes Member Cluster 1 has no information about the om-db-2-1-svc service deployed in the Member Cluster 2 and the DNS resolution of om-db-2-1-svc.om-ns.svc.cluster.local would fail.

   • Quando o Banco de Dados de Aplicativo e as instâncias do Aplicativo MongoDB Ops Manager estão em um estado Running, o Operador Kubernetes adiciona um contêiner de monitoramento adicional ao Banco de Dados do Aplicativo StatefulSets. Isso resulta em uma reinicialização contínua de todos os Pods do Banco de Dados de Aplicativos em todos os clusters. O Operador Kubernetes atualiza os StatefulSets em todos os clusters sequencialmente, de modo que, durante o processo de reinicialização contínua , em cada cluster, apenas um membro do conjunto de réplicas fique temporariamente indisponível.

   • O agente de monitoramento conecta-se às instâncias do aplicativo MongoDB Ops Manager usando o FQDN do serviço MongoDB Ops Manager, <om_resource_name>-svc.<namespace>.svc.cluster.local, ou o valor em spec.opsManagerURL se você o especificar.

     O Aplicativo MongoDB Ops Manager e o Backup Daemon sempre usam a connection string para o Banco de Dados do Aplicativo que contém todos os membros do conjunto de réplicas. A string de conexão é sempre construída usando os FQDNs de serviço por pod.

8. O Operador Kubernetes implementa o Backup Daemon StatefulSets se você definir o spec.backup.enabled como true.

   • Em cada cluster de membros listado em spec.clusterSpecList, o Operador Kubernetes cria um Backup Daemon StatefulSet, chamado <om_resource_name>-backup-daemon-<cluster_index> com o número de instâncias do Backup Daemon definidos como spec.backup.members.

     Como alternativa, você pode configurar o número de instâncias do Backup Daemon para cada cluster em spec.clusterSpecList[*].backup.members.

   • As instâncias do Backup Daemon se conectam somente ao conjunto de réplicas do banco de dados do aplicativo usando a mesma connection string que as instâncias do aplicativo MongoDB Ops Manager .

Além disso, neste diagrama, é possível observar a malha de serviço e as conexões de rede entre os componentes:

• As linhas pontilhadas ao redor do diagrama mostram a única malha de serviço que inclui a configuração de rede para todos os clusters.

• As linhas pontilhadas ao redor do aplicativo MongoDB Ops Manager nos clusters de membros indicam que essas instâncias não têm estado e o tráfego pode ser distribuído uniformemente para todas as instâncias, por exemplo , usando um balanceador de carga round-robin .

• As linhas pontilhadas ao redor do banco de dados de aplicativos em clusters de membros indicam que essas instâncias se comunicam entre si e formam um único conjunto de réplicas MongoDB.