Menu Docs
Página inicial do Docs
/
Operador de Kubernetes do MongoDB Enterprise
/
Implementar Ops Manager
/
Arquitetura do Ops Manager
/
Sistemas de vários clusters

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 implantado em vários clusters Kubernetes.

Diagrama mostrando a implantação de alto nível do MongoDB Ops Manager, seu aplicativo de UI, o banco de dados de aplicativos e o Backup Daemon em vários clusters do Kubernetes . O diagrama também mostra conexões de rede entre os componentes.
clique para ampliar

Neste diagrama:

  1. O Member Cluster 0 também é um "cluster de operadores" porque você instala o Operador Kubernetes nele. Ele também é um "cluster de membros" 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 de todos os clusters Kubernetes que o Operador Kubernetes vai gerenciar. Se você planeja usar o cluster do operador como um cluster de membros, esse segredo poderá conter as credenciais do mesmo cluster onde você instalará o Kubernetes Operator.

    Quando o Operador Kubernetes é executado nomodo 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 doTLS do .

    1apiVersion: mongodb.com/v1
    2kind: MongoDBOpsManager
    3metadata:
    4  name: om
    5  namespace: om-ns
    6spec:
    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: 6.0.22
    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: 6.0.5-ent
    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 FQDN padrão 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 no spec.opsManagerURL. Em algumas implantações, como quando o cluster onde você instalou o Operador Kubernetes não está anexado à tela 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 ao MongoDB Ops Manager no spec.opsManagerURL. Essa URL pode ser o nome do host de uma instância MongoDB 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 MongoDB 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 no <statefulset_name>-<pod_index> hospedando um processo MongoDB denominado <om_resource_name>-db-<cluster_index>-<pod_index>, o Operador Kubernetes cria um Kubernetes ClusterIP-tipo de serviço para acessar os processos individuais mongod por seu FQDN, <om_resource_name>-db-<cluster_index>-<pod_index>-svc. Cada processo do mongod no conjunto de réplicas deve ser exclusivamente endereçável.

      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 mesclagem de serviço lida com queries de DNS entre clusters e roteia o tráfego adequadamente. 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 clusters e permite a conectividade na porta mongod exposta (27017 por padrão).

      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 se conecta às MongoDB Ops Manager instâncias do MongoDB Ops Manager aplicativo usando o FQDN do serviço , <om_resource_name>-svc.<namespace>.svc.cluster.local ou o valor em se você spec.opsManagerURL especificá-lo.

      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.

Voltar

Sistemas de vários clusters

Próximo

Redes, Balanceamento de carga, Malha de serviço