Menu Docs
Página inicial do Docs
/
MongoDB Ops Manager
/

Perguntas frequentes: automação

Nesta página

  • Quais versões do MongoDB o Ops Manager managed?
  • Quais são os caminhos de atualização para as versões 1.8.x e 2.0.x do Ops Manager?
  • Como o Ops Manager managed os sistemas do MongoDB?
  • Como o Ops Manager realiza manutenção em nós de cluster?
  • De quantas automações eu preciso?
  • Alguns dados do MongoDB são transferidos pela automação?
  • O Ops Manager lidará com falhas durante uma atualização?
  • Que tipos de sistema posso criar no Ops Manager?

Isso aborda perguntas comuns sobre o Ops Manager e seus recursos de automação.

O Ops Manager pode automatizar as operações de gerenciamento para seus processos monitorados do MongoDB, permitindo que você reconfigure, pare e reinicie o MongoDB por meio da interface do Ops Manager.

A automação do Ops Manager pode ser executada apenas em arquiteturas de 64 bits.

Para funções específicas do MongoDB Ops Manager e versões MongoDB suportadas, consulte Matriz de compatibilidade doMongoDB .

Para caminhos de atualização, consulte Upgrade do Ops Manager.

Depois de implantar a automação no ambiente da implantação do MongoDB , cada agente se comunica periodicamente com o MongoDB Ops Manager e executa qualquer trabalho necessário.

Os agentes reavaliam constantemente seu ambiente para adaptar seu trabalho conforme necessário. Como parte dessa atividade de rotina, o agente estabelece conexões frequentes de curta duração com os membros do cluster. Se um agente encontrar um problema, como problemas de conectividade de rede ou falha do Ops Manager, os agentes ajustarão seu trabalho para compensar e chegar com segurança ao estado objetivo.

Os agentes criam planos para passar do estado atual para um estado de meta. Os planos são executados em etapas, onde cada etapa é autônoma e independente das outras etapas.

Exemplo

Para uma instalação, o plano envolve baixar o MongoDB, iniciar o processo com as opções apropriadas de linha de comando, inicializar o conjunto de réplicas e aguardar uma maioria saudável. A configuração atinge o estado da meta quando o conjunto de réplicas está ativo e tem uma maioria saudável.

MongoDB Ops Manager executa umareinicialização contínua quando você executa manutenção em nós em um cluster. O agente atualiza os nós em um cluster um a um, sempre mantendo um nó primário, até que todos os nós sejam atualizados para manter a disponibilidade do cluster durante um período de manutenção.

Para cada nó secundário no cluster, Automação:

  1. Reinicia o processo mongod em execução no nó no modo standalone .

  2. Executa a tarefa de manutenção.

  3. Reinicia o processo mongod em execução no nó no modo replSet .

Após a atualização dos nós secundários, Automação:

  1. Desce o primário usando o comando rs.stepDown() .

  2. Atlas Triggers uma eleição para um novo nó primário.

  3. Executa a tarefa de manutenção no nó primário anterior.

  4. Reinicia o processo mongod em execução no antigo nó primário no modo replSet para ingressar no cluster como um nó secundário.

No MongoDB Ops Manager, a automação executa reinicializações contínuas nos nós do cluster para tarefas de manutenção, incluindo o seguinte:

  • Girando chaves KMIP .

  • Rotacionar arquivos-chave.

  • Alterando os argumentos de configuração do mongod .

  • Atualizando ou fazendo downgrade do modo TLS, auth ou clusterAuth .

  • Alterando a versão do MongoDB.

  • Alterando o tamanho do oplog.

  • Removendo um processo de um conjunto de réplicas.

  • Cancelando uma restauração a partir de um backup.

  • Habilitando o Profiler

Dica

Veja também:

Para usar a automação, você deve ter um agente em execução em cada host onde uma instância gerenciada do MongoDB é executada.

Os agentes não transmitem nenhum registro de dados de um MongoDB deployment. Os agentes comunicam apenas informações de configuração da implantação e registros do MongoDB.

De um modo geral, sim. O design dos componentes de gerenciamento e automação do Ops Manager não leva em conta todas as possíveis falhas; no entanto, a arquitetura do sistema pode contornar muitos tipos de falhas.

Usando o Ops Manager, você pode configurar todos os tipos de sistema do MongoDB: clusters sharded, conjuntos de réplicas e standalones.

Os fragmentos em um cluster fragmentado devem ser conjuntos de réplicas. Ou seja, um fragmento não pode ser um mongod autônomo. Se você precisar executar um fragmento como um único mongod (que não oferece redundância ou failover), execute o fragmento como um conjunto de réplicas de um único nó.

Observação

Você não pode atualizar uma implantação do MongoDB fragmentado para a versão 3.4 se a implantação usar instâncias espelhadas mongod como servidores de configuração. Para permitir que a implantação fragmentada seja atualizada, consulte Converter servidores de configuração em um conjunto de réplicas. A conversão requer que a implantação fragmentada execute a versão do MongoDB 3.2.4 ou posterior. As implantações que executam versões anteriores devem ser atualizadas para a versão 3.2.4 antes de uma atualização para a versão 3.4.

Voltar

Perguntas frequentes: administração