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áriomongod
; se estiver usando o pacotedeb
, o agente será executado como usuáriomongodb
. Se você instalar usando o arquivotar.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 MongoDB Agent deve ser capaz de se conectar ao MongoDB Ops Manager na porta 8080
(HTTP) ou na 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 mongod
se mongos
es), 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:
Para um cluster não fragmentado:
Para um cluster fragmentado:
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:
Clique em View Diagnostics.
O modal View Diagnostics exibe quaisquer erros que possam ter acontecido durante o sistema.
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.
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.
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:
O agente está instalado e funcionando em cada host.
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:
Clique no link Allow Editing & Override Current Configuration no banner de aviso.
Remova todos os processos (
mongod
emongos
) 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:
Navegue até seu projeto.
Clique em Servers.
Encontre o host com problema.
Clique em e depois em Remove Server.
O gerente de operações exibe o modal Are you sure you want to remove this server>.
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.
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:
Edite o arquivo JSON de configuração de automação.
Remover o nó obsoleto dos processos e conjuntos de réplicas.
Aguarde alguns minutos.
Verifique a visualização Agents .
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:
No final de seu arquivo de configuração do MongoDB Agent, adicione:
enableLocalConfigurationServer=true Desligue cada processo gerenciado pelo MongoDB Agent.
Reinicie o MongoDB Agent executando o seguinte comando:
service mongodb-mms-automation-agent restart Reinicie os processos MongoDB que você desligou.
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.