A `MongoDBOpsManager` definição de recurso personalizada

Nesta página

Banco de dados de aplicativos

Aplicativo de Ops Manager
Backup Daemon

O Operador Kubernetes gerencia os sistemas do Ops Manager usando o MongoDBOpsManager recurso personalizado em cada cluster do Kubernetes onde você distribui o recurso. O Operador Kubernetes observa a especificação do recurso em busca de alterações. Quando a especificação é alterada, o Operador do Kubernetes valida as alterações e faz as atualizações apropriadas no recurso em cada um dos clusters do Kubernetes em que você distribui componentes do Ops Manager.

MongoDBOpsManager recurso personalizadoA especificação define os seguintes MongoDB Ops Manager componentes do :

Banco de dados de aplicativos
O aplicativo MongoDB Ops Manager
O Daemon de Backup

O diagrama a seguir descreve os componentes relacionados para uma implantação MongoDB Ops Manager :

Em sistemas de cluster único, você distribui estes componentes no mesmo cluster Kubernetes onde instala o Operador Kubernetes. Esse cluster é conhecido como "cluster do operador".
Em sistemas de vários clusters, você:
- Implante cada componente em clusters Kubernetes diferentes, conhecidos como "clusters de membros". Você também pode implantar uma implantação simplificada de vários clusters com um único cluster Kubernetes de membro. Para saber mais, consulte Modo de cluster único e multicluster.
- Instale o Operador Kubernetes em um cluster do Kubernetes, conhecido como "cluster de operadores" de onde o Operador Kubernetes gerencia todos os outros clusters de membros. O cluster do operador também pode ser considerado um cluster de membros, pois também pode hospedar os componentes do MongoDB Ops Manager . Consulte Diagrama de arquitetura de vários clusters.

Diagrama mostrando a arquitetura de alto nível do MongoDB Enterprise Kubernetes Operator (cluster Kubernetes único)

Banco de dados de aplicativos

Para o banco de dados de aplicativos, o Operador Kubernetes implementa um conjunto de réplicas do MongoDB como um StatefulSet.

Cada Pod para o Banco de Dados do Aplicativo tem os seguintes contêineres:

mongod.
MongoDB Agent. Para substituir a versão do MongoDB Agent, use a variável de ambiente $AGENT_IMAGE ou agent.version no gráfico Helm que você usa para instalar o Kubernetes Operator.
Agente de monitoramento. Você não pode substituir a versão do agente de monitoramento. A versão que o Kubernetes Operator usa garante a compatibilidade com as versões do MongoDB Ops Manager .
Para visualizar a versão do agente de monitoramento:
- Inspecione o /usr/local/om_version_mapping.json dentro do Pod para o Operador Kubernetes ou a imagem para o Operador Kubernetes.
- Verifique a imagem do container do agente de monitoramento no Pod onde você implementa o banco de dados de aplicativos.

Em sistemas de vários clusters (quando você define spec.applicationDatabase.topology como MultiCluster), o Operador Kubernetes cria o StatefulSet em cada cluster Kubernetes especificado para o Banco de Dados de Aplicativos em spec.applicationDatabase.clusterSpecList.

As ações a seguir ocorrem em cada cluster Kubernetes de membros que hospeda nós de conjunto de réplicas do MongoDB para o banco de dados de aplicativos:

O Kubernetes cria um Pod no StatefulSet para cada nó que compreende seu conjunto de réplicas do Banco de Dados de Aplicativo. Cada Pod no StatefulSet executa um mongod e o MongoDB Agent.
Para permitir que cada MongoDB Agent inicie mongod em seu Pod no StatefulSet, você deve especificar uma versão específica do MongoDB Server para o banco de dados de aplicativos usando a configuração spec.applicationDatabase.version . A versão especificada nesta configuração deve corresponder à tag no registro de contêiner.
Cada MongoDB Agent inicia mongods em seu Pod do Banco de Dados de Aplicativos. O MongoDB Agent adiciona processos mongod ao conjunto de réplicas do banco de dados do aplicativo.
Você configura o número de réplicas e outras opções de configuração para o conjunto de réplicas do Banco de Dados do Aplicativo definido na coleção spec.applicationDatabase no recurso personalizado MongoDBOpsManager . O Kubernetes operador do passa essa configuração para o MongoDB Agent usando um segredo que o Kubernetes operador monta em cada Pod no banco de dados do aplicativo StatefulSet.
Em sistemas do Banco de Dados de Aplicativos de vários clusters (onde spec.applicationDatabase.topology está definido como MultiCluster), você especifica o número de nós em cada cluster de membros separadamente para cada cluster de membros no spec.applicationDatabase.clusterSpecList. Em sistemas de vários clusters, a configuração replicas em spec.applicationDatabase é ignorada.
Cada vez que você atualiza a collection spec.applicationDatabase , o Operador Kubernetes aplica as alterações na configuração do MongoDB Agent e na especificação StatefulSet, se aplicável. Se a especificação do StatefulSet for alterada, o Kubernetes atualizará os Pods de forma contínua e reiniciará cada Pod.
Para fornecer conectividade a cada Pod do Banco de Dados de Aplicativo a partir de cada cluster Kubernetes que hospeda o Banco de Dados de Aplicativo, o Operador Kubernetes cria um serviço headless . Em sistemas de vários clusters do Banco de Dados de Aplicativos, o Operador Kubernetes também cria um serviço por Pod denominado <om_resource_name>-db-N-svc (isso corresponde a metadata.name) e usa seuFQDN , como <om_resource_name>-db-0.<namespace>.svc.cluster.local, como nome de host para conectando-se a um mongod específico.
Dependendo da StorageClass ou o ambiente no qual você implementa o Operador Kubernetes, o Kubernetes pode criar os Volumes Persistentes usando o provisionamento dinâmico de volume.
Você pode personalizar as Declarações de volume persistente para os pods do banco de dados de aplicativos usando spec.applicationDatabase.podSpec.persistence.single ou spec.applicationDatabase.podSpec.persistence.multiple.

Topologia do Banco de Dados do Aplicativo

Para eleger uma primária, a maioria dos nós do conjunto de réplicas do aplicativo de banco de dados deve estar disponível. Se a maioria dos nós do conjunto de réplicas falhar, o conjunto de réplicas não poderá formar uma maioria votante para eleger um nó primário. Para saber mais, consulte Arquiteturas de sistema de conjunto de réplicas.

Se possível, use um número ímpar de clusters Kubernetes de membros e distribua os nós do banco de dados de aplicativos entre data centers, zonas ou clusters Kubernetes. Para saber mais, consulte Conjuntos de réplicas distribuídos em dois ou mais data centers.

Considere os seguintes exemplos da topologia do banco de dados do aplicativo:

Para um banco de dados de aplicativo de cinco membros, algumas possíveis distribuições de membros incluem:

Dois clusters: três membros para Cluster 1 e dois membros para Cluster 2.
- Se Cluster 2 falhar, Cluster 1 hospedará um número suficiente de membros do conjunto de réplicas do aplicativo de banco de dados para eleger um nó primário.
- Se Cluster 1 falhar, Cluster 2 não terá membros suficientes do banco de dados de aplicativos para eleger um nó primário.
Três clusters: dois membros para Cluster 1, dois membros para Cluster 2 e um membro para Cluster 3.
- Se qualquer cluster falhar, haverá membros suficientes nos clusters restantes para eleger um nó primário.
- Se dois clusters falharem, não haverá membros suficientes em nenhum cluster restante para eleger um nó primário.

Para um Banco de Dados de Aplicativo de sete membros, considere a seguinte distribuição de membros:

Dois clusters: quatro membros para Cluster 1 e três membros para Cluster 2.
- Se Cluster 2 falhar, há membros suficientes em Cluster 1 para eleger um nó primário.
- Se Cluster 1 falhar, não há membros suficientes em Cluster 2 para eleger um nó primário.

Embora Cluster 2 atenda ao mínimo de três membros para o Banco de Dados de Aplicativo, a maioria dos sete membros do Banco de Dados de Aplicativo deve estar disponível para eleger um nó primário.

Para saber mais, consulte Recuperação de desastres para o MongoDB Ops Manager e Recursos do AppDB.

Aplicativo de Ops Manager

Depois que o banco de dados de aplicativos atinge um estado de execução , o operador do Kubernetes começa a implantar o aplicativo do MongoDB Ops Manager :

Ele configura um StatefulSet em cada cluster Kubernetes de membros.
Para cada conjunto de réplicas MongoDB Ops Manager que você deseja implantar, o Kubernetes cria um Pod no StatefulSet.
Cada Pod contém um processo de Aplicativo de MongoDB Ops Manager .

Para tornar seu sistema do MongoDB Ops Manager de cluster único resiliente a falhas de Pod único, aumente o número de réplicas que hospedam o aplicativo MongoDB Ops Manager , usando spec.replicas.

Para tornar a implantação do MongoDB Ops MongoDB Ops Manager de vários clusters resiliente a falhas de todo o data center ou zona, implante o aplicativo MongoDB Ops Manager em vários clusters do Kubernetes definindo spec.topology e spec.applicationDatabase.topology como MultiCluster. Consulte também Recuperação de desastres para o MongoDB Ops Manager e Recursos do AppDB.

Backup Daemon

Se spec.backup.enabled for true, então em cada cluster Kubernetes membro, o Operador Kubernetes inicia o Daemon de Backup depois que o Aplicativo MongoDB Ops Manager atinge um estágio de Execução . Para o Backup Daemon, o Operador Kubernetes implementa um StatefulSet para cada cluster Kubernetes de membros. Em cada cluster de membros, o Kubernetes cria tantos Backup Daemon Pods no StatefulSet quanto especificado no spec.backup.members. Em implantações de cluster único, essas ações ocorrem no cluster do operador que você usa para instalar o Kubernetes Operator e implantar os componentes do MongoDB Ops Manager .

Se você habilitar o backup, configure o armazenamento de oplog, um blockstore ou um armazenamento de snapshot S3no spec.backup nível global e não para cada cluster de membros do Kubernetes.

Você também pode criptografar tarefas de backup, mas as limitações se aplicam a sistemas em que a mesma instância do Kubernetes Operator não está gerenciando os recursos personalizados do MongoDBOpsManager e do MongoDB .

Se você ativar o backup, o Kubernetes Operator criará uma declaração de volume persistente para o banco de banco de dados principal do Backup Daemon em cada cluster Kubernetes de membros. Você pode configurar o banco de dados principal usando a configuração spec.backup.headDB .

O Operador Kubernetes invoca as APIs MongoDB Ops Manager para garantir que a configuração de backup do aplicativo MongoDB Ops Manager corresponda à que você definir nas definições de recursos personalizados para cada cluster Kubernetes de membros.

Voltar

Arquitetura do Ops Manager

Reconciliação