Menu Docs
Página inicial do Docs
/
MongoDB Ops Manager
/
Solução de problemas

Automação

Nesta página

  • A automação é executada somente em arquiteturas de 64 bits
  • Uso de hardware próprio
  • Networking
  • Configuração da automação
  • Dimensionamento
  • Tempo limite de conexão frequente
  • Implantações
  • Permissões do MongoDB Agent
  • Remover hosts problemáticos do MongoDB
  • Certifique-se de que os certificados TLS contenham um nome alternativo de assunto
  • Armazenamento de arquivos de configuração na memória para clusters existentes

O Ops Manager Automation permite distribuir, configurar e gerenciar MongoDB deployments com a UI do Ops Manager. O Ops Manager Automation depende de um MongoDB Agent, que deve ser instalado em todos os servidores do sistema. Ele pesquisa periodicamente o serviço do Ops Manager para determinar a meta atual e relatam continuamente seu status ao Ops Manager.

A automação é executada somente em arquiteturas de 64 bits

O Ops Manager fornece apenas downloads de 64 bits do MongoDB Agent.

Uso de hardware próprio

  • Se você distribuir a automação manualmente, certifique-se de ter um MongoDB Agent em cada servidor.

  • Se você distribuir o agente manualmente, deverá criar o dbPath do MongoDB e o diretório para os binários do MongoDB e garantir que o usuário que estiver executando o agente seja o proprietário desses diretórios.

    Se você instalar usando o pacote rpm, o agente será executado como usuário mongod; se estiver usando o pacote deb, o agente será executado como usuário mongodb. Se você instalar usando o arquivo tar.gz, poderá executar o agente como qualquer usuário.

Networking

Conectividade com portas MongoDB

Todos os hosts devem permitir a comunicação entre as portas do MongoDB. O padrão é 27017, mas você pode configurar intervalos de portas alternativos na interface do Ops Manager.

O Agente MongoDB deve ser capaz de se conectar ao Ops Manager na porta 8080 (HTTP) ou porta 8443 (HTTPS). Para obter mais informações sobre o acesso a portas e endereços IP, consulte Visão geral de segurança.

Problema de conectividade entre os clusters

Ao realizar uma atualização contínua, o MongoDB Agent tenta evitar o tempo de inatividade. Ele precisa coletar o estado de outros membros do cluster. Um problema de conectividade (entre mongodse mongoses), como resolução de nome de host ou firewall configurado incorretamente, pode impedir que o MongoDB Agent determine o estado dos processos remotos e conclua a alteração.

Para garantir que todos os nós do cluster possam se comunicar uns com os outros:

  1. Para um cluster não fragmentado:

    1. Conecte-se a cada mongod.

    2. A partir desse host mongod , conecte-se a todos os outros nós do conjunto de réplicas.

  2. Para um cluster fragmentado:

    1. Conecte-se a cada mongod.

    2. A partir desse host mongod , conecte-se a todos os outros nós do shard.

    3. Conecte-se a cada mongos.

    4. A partir disso, o host mongos :

      1. Conecte-se aos outros hosts mongos .

      2. Faça login em todos os outros membros de cada fragmento.

Conexões de automação frequentes

O MongoDB Agent coleta o estado de cada membro do cluster a cada 10 segundos para garantir que o ambiente esteja no estado esperado. Como parte dessa avaliação, o MongoDB Agent cria uma conexão, verifica determinados arquivos para determinar o estado e, em seguida, fecha a conexão. Essas conexões frequentes de curta duração fazem parte da atividade de rotina do MongoDB Agent e não devem afetar o desempenho.

Configuração da automação

Depois de concluir a configuração da automação, certifique-se de que o plano do sistema satisfaça as necessidades do seu sistema. Verifique os nomes de host e as portas antes de confirmar o sistema.

Dimensionamento

  • Certifique-se de provisionar hosts com espaço suficiente para executar o MongoDB e oferecer suporte aos requisitos do seu conjunto de dados.

  • Verifique se você forneceu um número suficiente de hosts para executar seu sistema. Cada mongod deve ser executado em seu próprio host.

Tempo limite de conexão frequente

O MongoDB Agent muitas vezes pode atingir o tempo limite das conexões por um ou mais dos seguintes motivos:

  • Tempo limite de conexão

  • Alta latência de rede

  • Alta carga do servidor

  • Chaves SSL grandes

  • Velocidade insuficiente da CPU

Por padrão, as conexões são encerradas após 40 segundos. O MongoDB recomenda aumentar gradualmente o valor da definição de configuração dialTimeoutSeconds do MongoDB Agent para evitar tempos limite de conexão prematuros e frequentes. No entanto, aumentar esse valor também aumenta o tempo necessário para implantar futuras alterações de configuração. Experimente com pequenos aumentos incrementais até determinar o valor ideal para seu sistema.

Para saber mais, consulte dialTimeoutSeconds nas configurações de conexão do MongoDB Agent.

Implantações

Um banner que exibe We have detected a potential problem while deploying... aparece quando certas condições se aplicam. Estes são alguns exemplos.

Alteração do sistema incapaz de concluir/não prosseguir

Se você adicionou ou reiniciou um sistema e o sistema permanece no estado In Progress por vários minutos, o banner será exibido.

Nessa situação, você tem quatro opções:

  1. Clique em View Diagnostics.

    O modal View Diagnostics exibe quaisquer erros que possam ter acontecido durante o sistema.

  2. Clique em View Status.

    O modal Automation Status exibe os processos da implantação, quando eles relataram seu status de implantação pela última vez, qual tarefa eles estão tentando completar e o status da implantação.

    Para saber mais sobre o status de qualquer um dos processos individuais, clique no ícone de reticências e selecione View Details ou View Agent Logs.

    • View Details mostra qual é o plano de sistema do processo e em qual estágio desse plano o MongoDB Agent está atualmente.

    • View Agent Logs abre uma nova janela do navegador com a tela Deployment > Agents > Agent Logs exibida e o conteúdo do registro do MongoDB Agent exibido por padrão. Clique no menu View para selecionar um registro de agente diferente.

  3. Clique em View Agent Logs.

    Uma nova janela do navegador é aberta com a tela Deployment > Agents > Agent Logs exibida e o conteúdo do registro do MongoDB Agent exibido por padrão. Clique no menu View para selecionar um registro de agente diferente.

  4. Clique em Allow Override & Edit Configuration.

    Se você diagnosticar um erro e precisar corrigir a configuração do sistema, siga o procedimento para editar o sistema.

Se você encerrar o sistema e ainda não conseguir encontrar uma solução, remova o sistema do Ops Manager.

Os MongoDB Agents estão inativos ou não estão se comunicando

Se o módulo de automação do MongoDB Agent não puder se comunicar com o aplicativo de Ops Manager API endpoint ou com os processos do servidor MongoDB, o Ops Manager exibirá um banner de aviso no projeto. Você pode resolver isso de duas maneiras, dependendo se espera ou não que os MongoDB Agents estejam se comunicando:

Os agentes do MongoDB precisam se comunicar

Se os MongoDB Agents devem estar se comunicando com o host do Ops Manager ou instâncias MongoDB, confirme o seguinte para cada MongoDB Agent:

  1. O agente está instalado e funcionando em cada host.

  2. O agente e o endpoint da API do aplicativo Ops Manager podem se comunicar.

MongoDB Agents não precisam se comunicar

Se o módulo de automação dos MongoDB Agents devem estar se comunicando com os processos do aplicativo de Ops Manager API endpoint ou servidor MongoDB, confirme o seguinte para cada sistema automatizado do servidor MongoDB:

  1. Clique no link Allow Editing & Override Current Configuration no banner de aviso.

  2. Remova todos os processos (mongod e mongos) em execução nos hosts que atendem aos MongoDB Agents desnecessários.

Permissões do MongoDB Agent

Um problema de permissões pode impedir que a automação conclua uma alteração. Se View Status ou View Diagnostics relatar um erro relacionado a permissões (como open /data/db/mongod.lock: permission denied), verifique se o usuário do MongoDB Agent possui e tem permissões de leitura e gravação para os arquivos dbpath e logpath.

Remover hosts problemáticos do MongoDB

Você pode usar o console ou a API para remover hosts obsoletos, quebrados ou problemáticos da automação. Isso pode incluir a circunstância em que o MongoDB Agent não pode ser alcançado.

Para remover um host problemático usando o console:

  1. Navegue até seu projeto.

  2. Clique em Servers.

  3. Encontre o host com problema.

  4. Clique em e depois em Remove Server.

    O gerente de operações exibe o modal Are you sure you want to remove this server>.

  5. Insira o nome do host fornecido no campo Enter the host name e clique em Remove se quiser remover este servidor.

    Aviso

    O Ops Manager remove todos os dados de monitoramento deste host quando você clica em Remove. O Ops Manager não fornece confirmação ou cancelamento para esta ação.

    Se você não deseja remover o servidor, clique em Cancel.

  6. Clique em Review & Deploy para revisar as suas alterações.

    O Ops Manager exibe as alterações propostas.

    • Se estiver satisfeito, clique em Confirm & Deploy.

      O Ops Manager remove todos os processos e agentes no momento.

    • Para fazer mais alterações de configuração, clique em Cancel.

Para remover um host com problema usando a API:

  1. Obtenha a configuração de automação atual.

  2. Edite o arquivo JSON de configuração de automação.

  3. Remover o nó obsoleto dos processos e conjuntos de réplicas.

  4. Atualize o arquivo de configuração de automação.

  5. Aguarde alguns minutos.

  6. Verifique a visualização Agents .

  7. Confirme se o host não aparece mais na lista de agentes.

Certifique-se de que os certificados TLS contenham um nome alternativo de assunto

Aviso

O MongoDB Agent da versão 11.12.0.7384 exige que os certificados TLS incluam um valor no campo Nome alternativo do assunto. Antes de atualizar para a versão 11.12.0.7384, certifique-se de que todos os certificados TLS usados em seu sistema do MongoDB contenham um SAN. [1]

[1] MongoDB escreveu para o MongoDB Agent a linguagem Go. Go 1.17 removeu a capacidade de usar X.509 Campo CommonName como nome de host quando não existe SAN . Quando os clientes validam os certificados TLS , o cliente verifica o nome ou os nomes de host aos quais os certificados se aplicam a partir dos valores nos campos SAN ou Nome Distinto do Assunto (DN) do certificado. Ao criar certificados TLS , algumas pessoas utilizariam o campo Nome Comum do Assunto (CN) para armazenar o nome do host. Os CNs têm limitações que os tornam uma escolha ruim para armazenar nomes de host. Esses limites incluem um comprimento máximo 64caracteres e nenhum suporte para restrições de nome. RFC 2818 descontinuado o uso de CN para armazenar nomes de host em maio 2000 de . Essa RFC exigia que os clientes recorressem ao CN se o certificado não tivesse valores no campo SAN . RFC 6125 removeu o requisito em 2011.Go 1.15 desabilita a adesão à RFC 2818 e usa a RFC 6125 prática de tornar o CN opcional. Na prática, essa alteração exige que você adicione valores SAN ou habilite o uso do CNs.Go 1.17 remove a solução alternativa para usar o CN se não houver SAN.Com a versão atual do MongoDB Agent, você deve usar SAN.Para saber mais, consulte a postagem do blog de Fraser Tweedale sobre este tópico

Armazenamento de arquivos de configuração na memória para clusters existentes

Se você usa o Ops Manager versão 4.2 ou versões 4.4.0 - 4.4.6, pode encontrar erros ao definir enableLocalConfigurationServer como true e reiniciar seu MongoDB Agent.

Esse problema afeta apenas clusters existentes em que enableLocalConfigurationServer está definido como true depois que o cluster é criado. Definir esse valor antes de criar o cluster não aciona esse problema.

Para alterar esta configuração com segurança para clusters existentes:

  1. No final de seu arquivo de configuração do MongoDB Agent, adicione:

    enableLocalConfigurationServer=true

  2. Desligue cada processo gerenciado pelo MongoDB Agent.

  3. Reinicie o MongoDB Agent executando o seguinte comando:

    service mongodb-mms-automation-agent restart

  4. Reinicie os processos MongoDB que você desligou.

  5. Verifique se o arquivo automation-mongod.conf tem a diretiva de expansão __rest .

Para obter mais informações sobre o armazenamento de arquivos de configuração na memória, consulte Configurar como o MongoDB Agent gerencia arquivos de configuração e senhas.

Voltar

Autenticação