Menu Docs
Página inicial do Docs
/
MongoDB Cloud 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

A automação do Cloud Manager permite distribuir, configurar e managed MongoDB deployments com a UI do Cloud Manager. A automação do Cloud Manager depende de um MongoDB Agent, que deve ser instalado em todos os servidores do sistema. Os agentes MongoDB pesquisam periodicamente o serviço Cloud Manager para determinar a meta atual e relatam continuamente seu status ao Cloud Manager.

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

O Cloud 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 Cloud Manager.

O MongoDB Agent deve ser capaz de se conectar a cloud.mongodb.com na porta 443 (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 do sistema, quando eles relataram seu status de sistema pela última vez, qual tarefa eles estão tentando completar e o status do sistema. Você pode filtrar os resultados das seguintes maneiras:

    • Digite um nome de host na barra de pesquisa Filter processes.

    • Selecione um ou mais tipos de processo no menu suspenso Process Type.

    • Selecione um ou mais estados de automação no menu suspenso Automation State.

    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 Cloud 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 Cloud Manager API endpoint ou com os processos do MongoDB Server, o Cloud Manager exibirá um banner de aviso no projeto. Você pode resolver isso de duas maneiras, dependendo se espera ou não que os agentes MongoDB estejam se comunicando:

Os agentes do MongoDB precisam se comunicar

Se os MongoDB Agent devem estar se comunicando com o Cloud 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 Cloud Manager podem se comunicar.

MongoDB Agents não precisam se comunicar

Se o módulo de automação do MongoDB Agent deve estar se comunicando com os processos do Cloud Manager API endpoint ou do MongoDB Server, confirme o seguinte para cada implantação automatizada do MongoDB Server:

  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

No MongoDB Cloud Manager, acesse aGo Deployment página do seu projeto.

  1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

  2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

  3. Se a página Deployment ainda não estiver exibida, clique em Deployment na barra lateral.

    A página Sistema é exibida.

2

Acesse a página Processes.

Clique na aba Processes para sua implantação.

A página Processos é exibida.

3

Remova o host.

  1. Encontre o host com problema.

  2. Clique em e depois em Remove Server.

    O Cloud Manager exibe o modal Are you sure you want to remove this server> .

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

    Aviso

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

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

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

    O Cloud Manager exibe as alterações propostas.

    • Se estiver satisfeito, clique em Confirm & Deploy.

      O Cloud Manager remove todos os processos e agente 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. No MongoDB Cloud Manager, Go a página Deployment do seu projeto.

    1. Se ainda não estiver exibido, selecione a organização que contém o projeto desejado no menu Organizations na barra de navegação.

    2. Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.

    3. Se a página Deployment ainda não estiver exibida, clique em Deployment na barra lateral.

      A página Sistema é exibida.

  7. Clique na aba Agents para sua implantação.

    A página Agentes é exibida.

  8. 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.11.0.7349-1 exige que os certificados TLS incluam um valor no campo nome alternativo do assunto. Antes de atualizar para o MongoDB Agent 11.11.0.7355 ou posterior, certifique-se de que todos os certificados TLS usados no MongoDB deployment 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ê usar o Cloud Manager versão 4.2 ou versões 4.4.0 - 4.4.6, você pode encontrar erros ao configurar enableLocalConfigurationServer para 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

Próximo

Monitoramento