O Ops Manager é um componente necessário para qualquer sistema do Enterprise MongoDB . O Ops Manager automatiza, monitora e executa backups de bancos de dados MongoDB . O recurso personalizado do MongoDBOpsManager define três componentes:
Aplicativo Ops Manager — o componente principal do Ops Manager e a interface do usuário front-end.
Banco de dados de aplicativos — o banco de dados MongoDB de apoio para o Ops Manager.
Backup Daemon - oferece suporte ao aplicativo 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 do Kubernetes valida as alterações e aplica as atualizações apropriadas em cada cluster do Kubernetes onde você distribui componentes do Ops Manager.
O diagrama a seguir mostra a arquitetura de uma implantação do 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 containers:
mongod — o processo do banco de dados .
MongoDB Agent — gerencia o
mongodciclo de vida do. Você pode substituir a versão do MongoDB Agent usando a$AGENT_IMAGEvariável de ambiente ouagent.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 do aplicativo para os agentes por meio de um segredo (<om_resource_name>-db-config) montado em cada Pod.
O Kubernetes cria um Pod por membro. 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 utilizando spec.applicationDatabase.podSpec.persistence.
O Operador Kubernetes cria um Serviço headless para conectividade interna. Em sistemas de vários clusters, o Operador Kubernetes também cria um serviço por Pod (<om_resource_name>-db-N-svc) para endereçamento individual mongod.
Considerações sobre topologia 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 possível, use um número ímpar de clusters Kubernetes de membros e distribua nós entre data centers, zonas ou clusters.
Considere estes exemplos de distribuição:
Banco de Dados de Aplicativos de cinco membros, dois clusters: Coloque 3 os membros no Cluster 1 e 2 no Cluster.2 Se 2 o Cluster falhar, o Cluster 1 terá a maioria. Se 1 o Cluster falhar, o Cluster 2 não falhará.
Banco de Dados de Aplicativos com cinco membros, três clusters: Coloque 2 membros cada em Clusters 1 e,2 e 1 no 3 Cluster. Qualquer falha de cluster único deixa uma maioria.
Banco de dados de aplicativos de sete membros, dois clusters: coloque 4 no cluster 1 e 3 no 2 cluster. Somente a perda do Cluster 2 preserva a maioria.
Para saber mais, consulte Arquiteturas de sistema de conjunto de réplicas e recuperação de desastres para o Ops Manager e recursos do AppDB.
O recurso de aplicativo 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 membros.
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 um sistema de cluster único resiliente a falhas de Pod, aumente spec.replicas. Para tornar um sistema de vários clusters resiliente a falhas no centro de dados, defina spec.topology como MultiCluster e distribua instâncias entre clusters Kubernetes.
O recurso Backup Daemon
Se o spec.backup.enabled for true, o Operador do Kubernetes iniciará o Backup Daemon após o Aplicativo de Ops Manager atingir um estado de Execução. O Operador Kubernetes implementa um StatefulSet para o Backup Daemon em cada cluster de membros. O Kubernetes cria tantos Backup Daemon Pods quanto especificado em spec.backup.members.
Se o backup estiver ativado, o Kubernetes Operator criará um PersistentVolumeClaim para o banco de dados principal do Backup Daemon em cada cluster de membros. 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 de Ops Manager corresponda à definição de recurso personalizado. Configure armazenamentos de oplog, blockstores ou armazenamentos de snapshots S3 no nível spec.backup global, não por cluster.
Você também pode criptografar tarefas de backup, mas limitações se aplicam quando a mesma instância do Kubernetes Operator não gerencia os MongoDBOpsManager MongoDB recursos personalizados e.
Reconciliação do Ops Manager
O diagrama a seguir descreve como o operador Kubernetes reconcilia as alterações no CRD MongoDBOpsManager:
A reconciliação passa por estas 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 do aplicativo.Cria ou atualiza o
<om_resource_name>-dbStatefulSet para o banco de dados do 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 sistemas de vários clusters, o StatefulSet é denominado
<om_resource_name>-db-<cluster-idx>(por exemplo,om-db-1).Cria ou atualiza o
<om_resource_name>StatefulSet para o aplicação Ops Manager. Cada réplica se conecta ao Banco de Dados do Aplicativo. A maioria das alterações desencadeia uma atualização contínua. Habilitar o TLS para o Banco de Dados de Aplicativos também aciona uma reinicialização contínua porque a string de conexão muda. Alterações emspec.backupnão desencadeiam uma atualização contínua.Em sistemas de vários clusters, o StatefulSet é denominado
<om_resource_name>-<cluster-idx>(por exemplo,om-1).Cria um usuário administrador por meio da API do Ops Manager e salva as credenciais no
<om_resource_name>-admin-keysegredo . Esta etapa acontece apenas na implementação inicial.Permite o monitoramento executando uma atualização contínua do banco de dados do aplicativo StatefulSet. Isso também acontece somente na implantação inicial.
Implementa o Backup Daemon se
spec.backup.enabledtruefor. O StatefulSet é denominado<om_resource_name>-backup-daemon(ou<om_resource_name>-backup-daemon-<cluster-idx>em sistemas de vários clusters).Configura o backup por meio de APIs do Ops Manager para garantir que a configuração de backup corresponda à definição de recurso personalizado.