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 é um 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 .

   1apiVersion: mongodb.com/v12kind: MongoDBOpsManager3metadata:4  name: om5  namespace: om-ns6spec:7  replicas: 1 # You can set this value and use it as a global or default8              # setting for all clusters. The spec.clusterSpecList.members9              # setting overrides this setting.10  topology: MultiCluster11  version: 8.0.012  adminCredentials: om-admin-secret13  clusterSpecList:14    - clusterName: "Member Cluster 1" # Ops Manager settings for "Member Cluster 1"15      members: 216      backup: # Backup settings for "Member Cluster 1"17        members: 2 # Overrides spec.backup.members18    - clusterName: "Member Cluster 2" # Ops Manager settings for "Member Cluster 2"19      members: 120      backup: # Backup settings for "Member Cluster 2"21        members: 2 # Overrides spec.backup.members22  applicationDatabase: # Global {+appdb+} settings23    topology: MultiCluster24    version: 8.0.025    members: 3 # In multi-cluster mode, the Operator ignores this field.26               # The Operator sets the number of members for the Application27               # Database in spec.applicationDatabase.clusterSpecList.members.28    clusterSpecList:29      - clusterName: "Member Cluster 1"30        members: 331      - clusterName: "Member Cluster 2"32        members: 233  backup: # Global settings for the Backup Daemon34    enabled: true35    members: 1 # Set this value and use it as a global or default setting.36               # To override this value, set the value for37               # spec.clusterSpecList.backup.members.38               # The Backup Daemon's configuration for each cluster isn't39               # stored here. Use the Ops Manager's spec.clusterSpecList.backup to40               # 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. Dois clusters de membros hospedam o aplicativoMongoDB Ops Manager . Em cada cluster, o Operador Kubernetes implementa um StatefulSet denominado <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.

   • O Member Cluster 1 contém três processos mongod para o Banco de Dados de Aplicativo e o Member Cluster 2 contém dois processos mongod .

   • Você define a configuração do banco de dados do aplicativo usando as configurações do spec.applicationDatabase . Em cada cluster de membros, o Operador Kubernetes cria um StatefulSet denominado <om_resource_name>-db-<cluster_index> com o número de clusters de membros definidos em spec.applicationDatabase.clusterSpecList.members. No modo de vários clusters, o Operador Kubernetes ignora valores definidos para o campo spec.applicationDatabase.members . O Operador Kubernetes configura um conjunto de réplicas formado a partir de processos do mongod distribuídos em todos os clusters de membros.

   • Para cada Pod em <statefulset_name>-<pod_index> que hospeda um processo MongoDB chamado <om_resource_name>-db-<cluster_index>-<pod_index>, o operador Kubernetes cria um serviço do tipo Kubernetes ClusterIPpara acessar os processos individuais mongod pelo seu FQDN, <om_resource_name>-db-<cluster_index>-<pod_index>-svc. Cada mongod processo no conjunto de réplicas deve ser endereçável de forma exclusiva.

     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.

   • Para formar um conjunto de réplicas de todos os processos do mongod , cada processo deve se conectar uns aos outros para fins de replicação. Para isso, inclua todos os clusters de membros nos quais você implementa o banco de dados de aplicativos na mesma configuração de malha de serviço.

     A malha de serviços lida com consultas DNS entre clusters e roteia o tráfego de acordo. A malha de serviços 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 cluster e permite a conectividade na porta exposta mongod (por padrão,27017).

     Por exemplo, quando um processo mongod em execução no om-db-1-0 Pod em Member Cluster 1 se conecta a um mongod em execução no om-db-2-1 Pod em Member Cluster 2, o primeiro processo mongod usa seu nome de host da Automação Configuration, om-db-2-1-svc.om-ns.svc.cluster.local:27017, e a malha de serviço encaminha essa solicitação para Member Cluster 2 para o serviço om-db-2-1-svc . Sem a malha de serviços, o Kubernetes Member Cluster 1 não tem informações sobre o serviço om-db-2-1-svc implantado no Member Cluster 2 e a resolução DNS do om-db-2-1-svc.om-ns.svc.cluster.local falharia.

   • 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.