O MongoDB Ops Manager é um componente necessário para qualquer implantação do MongoDB Enterprise. O MongoDB Ops Manager automatiza, monitora e executa backups de bancos de dados do MongoDB. O recurso personalizado MongoDBOpsManager define três componentes:
Aplicativo MongoDB Ops Manager — o principal componente do MongoDB Ops Manager e a IU de front-end.
Banco de dados de aplicativo — o banco de dados MongoDB de apoio para o MongoDB Ops Manager.
Backup Daemon — oferece suporte ao aplicativo MongoDB Ops Manager em processos de backup e restauração.
O operador Kubernetes gerencia a especificação do recurso MongoDBOpsManager. Quando a especificação é alterada, o operador Kubernetes valida as alterações e aplica as atualizações apropriadas em cada cluster Kubernetes onde você implanta componentes do Ops Manager.
O diagrama a seguir mostra a arquitetura de uma implantação do MongoDB Ops Manager em um único cluster Kubernetes:
Banco de dados de aplicativos
Para o Banco de Dados de Aplicativos, o Operador Kubernetes implementa um conjunto de réplicas MongoDB definido como um StatefulSet. Cada Pod tem os seguintes contêineres:
mongod — o processo do banco de dados.
MongoDB Agent — gerencia o ciclo de vida
mongod. Você pode substituir a versão do MongoDB Agent usando a variável de ambiente$AGENT_IMAGEouagent.versionno gráfico Helm.Agente de monitoramento — envia dados de monitoramento para o Ops Manager. A versão é selecionada automaticamente para compatibilidade com versões anteriores e não pode ser substituída.
O operador do Kubernetes passa a configuração do banco de dados de aplicativo para os agentes por meio de um segredo (<om_resource_name>-db-config) montado em cada Pod.
O Kubernetes cria um Pod por nó. Cada MongoDB Agent inicia mongod e o adiciona ao conjunto de réplicas. O operador Kubernetes cria PersistentVolumeClaims para cada Pod, e você pode personalizá-los usando spec.applicationDatabase.podSpec.persistence.
O operador do Kubernetes cria um serviço headless para conectividade interna. Em implantações de vários clusters, o operador do Kubernetes também cria um serviço por Pod (<om_resource_name>-db-N-svc) para endereçabilidade individual mongod.
Considerações sobre a topologia do banco de dados do aplicativo
Para eleger um primário, a maioria dos nós do conjunto de réplicas do banco de dados de aplicativo deve estar disponível. Se possível, use um número ímpar de clusters Kubernetes de membros e distribua os nós entre data centers, zonas ou clusters.
Considere estes exemplos de distribuição:
Banco de dados de aplicativo de cinco nós, dois clusters: coloque 3 nós no cluster 1 e 2 no cluster 2. Se o cluster 2 falhar, o cluster 1 terá a maioria. Se o cluster 1 falhar, o cluster 2 não terá.
Banco de dados de aplicativo de cinco nós, três cluster: coloque 2 nós em cada um dos cluster 1 e 2, e 1 no cluster 3. Qualquer falha de cluster único deixa uma maioria.
Banco de dados de aplicativo de sete nó, dois clusters: Coloque 4 no cluster 1 e 3 no cluster 2. Apenas a perda do cluster 2 preserva a maioria.
Para saber mais, consulte Arquiteturas de implantação de conjunto de réplicas e Recuperação de desastres para o MongoDB Ops Manager e Recursos do AppDB.
O recurso de aplicativo do MongoDB 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 :
O operador Kubernetes configura um StatefulSet em cada cluster Kubernetes de nós.
O Kubernetes cria um Pod por réplica do Ops Manager.
Cada Pod contém um processo de Aplicativo de MongoDB Ops Manager .
Para tornar uma implantação de cluster único resiliente a falhas de Pod, aumente spec.replicas. Para tornar uma implantação de vários clusters resiliente a falhas de data center, defina spec.topology como MultiCluster e distribua as instâncias entre os clusters do Kubernetes.
O recurso Backup Daemon
Se spec.backup.enabled for true, o Kubernetes Operator iniciará o Backup Daemon depois que o aplicativo MongoDB Ops Manager atingir um estado de execução. O Kubernetes operador implanta um StatefulSet para o Backup Daemon em cada cluster de nó. O Kubernetes cria tantos pods do Backup Daemon quanto especificado em spec.backup.members.
Se o backup estiver ativado, o operador Kubernetes criará uma PersistentVolumeClaim para o banco de dados principal do Backup Daemon em cada cluster de nó. Você configura o banco de dados principal por meio do spec.backup.headDB.
O operador do Kubernetes invoca APIs do Ops Manager para garantir que a configuração de backup do aplicativo do Ops Manager corresponda à definição de recurso personalizado. Configure armazenamentos de oplog, blockstores ou armazenamentos de snapshots S3 no nível global spec.backup, não por cluster.
Você também pode criptografar tarefas de backup, mas as limitações se aplicam quando a mesma instância do Kubernetes Operator não gerencia os recursos personalizados do MongoDBOpsManager e do MongoDB.
Reconciliação do MongoDB Ops Manager
O diagrama a seguir descreve como o Operador do Kubernetes reconcilia as alterações no MongoDBOpsManager CRD:
A reconciliação prossegue através destas etapas:
Cria ou atualiza o
<om_resource_name>-db-configSegredo contendo a configuração que o MongoDB Agent usa para iniciar o conjunto de réplicas do banco de dados de aplicativo.Cria ou atualiza o
<om_resource_name>-dbStatefulSet para o banco de dados de aplicativo. Este StatefulSet contém pelo menos três Pods. Cada Pod executa um MongoDB Agent que inicia ummongodem seu Pod. O segredo de configuração é montado em cada Pod.Em implantações de vários clusters, o StatefulSet é nomeado
<om_resource_name>-db-<cluster-idx>(por exemplo,om-db-1).Cria ou atualiza o
<om_resource_name>StatefulSet para o aplicativo MongoDB Ops Manager. Cada réplica se conecta ao banco de dados de aplicativo. A maioria das alterações trigger uma atualização contínua. Habilitar o TLS para o banco de dados do aplicativo também aciona uma reinicialização contínua porque a string de conexão muda. As alterações nospec.backupnão trigger uma atualização contínua.Em implantações de vários clusters, o StatefulSet é nomeado
<om_resource_name>-<cluster-idx>(por exemplo,om-1).Cria um usuário administrador através da API do MongoDB Ops Manager e salva as credenciais no
<om_resource_name>-admin-keySecret. Esta etapa ocorre apenas na implantação inicial.Permite o monitoramento executando uma atualização contínua do StatefulSet do banco de dados de aplicativo. Isso também acontece apenas na implantação inicial.
Implanta o Backup Daemon se
spec.backup.enabledfortrue. O StatefulSet é nomeado<om_resource_name>-backup-daemon(ou<om_resource_name>-backup-daemon-<cluster-idx>em implantações de vários clusters).Configura backup via APIs do MongoDB Ops Manager para garantir que a configuração de backup corresponda à definição de recurso personalizado.