Menu Docs

Página inicial do DocsMongoDB Ops Manager

Configurar um Aplicativo de Ops Manager altamente disponível

Nesta página

O Ops Manager Application oferece alta disponibilidade por meio do uso de vários servidores do aplicativo de Ops Manager atrás de um balancer de carga e do uso de umconjunto de réplicas para hospedar o banco de dados do Ops Manager.

Os componentes do aplicativo de Ops Manager não têm estado entre as solicitações. Qualquer servidor do aplicativo de Ops Manager pode lidar com solicitações, desde que todos os servidores leiam do mesmo aplicativo de banco de dados do Ops Manager. Se um aplicativo de Ops Manager ficar indisponível, outro preencherá as solicitações.

Para tirar proveito disso para alta disponibilidade, configure um balancer de carga de sua escolha para equilibrar o pool de hosts do Aplicativo de Ops Manager. Para fazer isso no Ops Manager, execute as seguintes ações:

O Aplicativo de Ops Manager usa o endereço IP do cliente para auditoria, registro e definição de uma lista de acesso para a API.

Depois que o balancer de carga for configurado e iniciado, você não deverá se conectar ao Aplicativo de Ops Manager a partir de seus URLs de host individual.

Observação

Para proibir o acesso a cada servidor de aplicativos de Ops Manager, configure suas regras de firewall adequadamente.

Exemplo

Se você tiver dois hosts do Ops Manager que atendem aos seguintes endereços URLs:

  • ops1.example.com

  • ops2.example.com

e coloque-os atrás de um balancer de carga na seguinte URL:

  • opsmanager.example.com

Após configurar e iniciar este balancer de carga, você não deve registrar no ops1.example.com. Em vez disso, registre-se em opsmanager.example.com.

Observação

Se você definir esses parâmetros utilizando o arquivo de configuração, altere o mms.remoteIp.header para a URL para o balancer de carga e mms.centralUrl para a URL para o host e porta do Ops Manager.

Se você configurar o Ops Manager para usar vários servidores de aplicativos do Ops Manager atrás de um balancer de carga HTTP ou HTTPS e usar snapshots do sistema de arquivos, FCV 4. As tarefas de snapshot de backup 2 ou posterior são executadas em paralelo em um ou mais servidores. Certifique-se de ter um sistema de arquivos compartilhado montado em cada servidor Ops Manager. O servidor do aplicativo de Ops Manager pode abrir e gravar diferentes offsets dos mesmos arquivos. Certifique-se de que o sistema de arquivos compartilhados permita isso. Caso contrário, você encontrará erros de acesso.

Para que o arquivo de diagnóstico do Ops Manager tenha tempo de ser gerado, defina o parâmetro HTTP idle timeout para o balancer de carga como 180 segundos.

Qualquer dispositivo de balanceamento de carga deve suportar a camada (a Camada de 7 Aplicativo) do modelo OSI .

Distribua um conjunto de réplicas em vez de um standalone para hospedar o aplicativo de banco de dados do Ops Manager. Os conjuntos de réplicas terão failover automático se o primário ficar indisponível.

Se o conjunto de réplicas tiver membros em diversas instalações, certifique-se de que uma única instalação tenha votos suficientes para eleger um primário , se necessário. Escolha a instalação que hospeda os principais sistemas de aplicativos. Coloque a maioria dos membros votantes e todos os membros que podem se tornar primários nesta instalação. Caso contrário, as partições da rede poderiam impedir que o conjunto fosse capaz de formar uma maioria. Para obter detalhes sobre como os conjuntos de réplicas elegem as primárias, veja Eleições do conjunto de réplicas.

Você pode fazer backup do conjunto de réplicas usando snapshots do sistema de arquivos. Os snapshots do sistema de arquivos usam ferramentas no nível do sistema para criar cópias do dispositivo que contém os arquivos de dados do conjunto de réplicas.

Para distribuir o conjunto de réplicas que hospeda o banco de dados do Aplicativo de Ops Manager, consulte Instância de apoio do MongoDB.

gen.key é um arquivo binário de 24 bytes usado para criptografar e descriptografar os bancos de dados de backup e as credenciais de usuário do Ops Manager. Um arquivo gen.key idêntico deve ser armazenado em cada servidor que faz parte de um sistema do Ops Manager altamente disponível.

O arquivo gen.key pode ser gerado automaticamente ou manualmente.

Para que o Ops Manager gere o arquivo:
Inicie um servidor Ops Manager. O Ops Manager criará um arquivo gen.key se não houver nenhum.
Para criar o arquivo manualmente:

Gere um arquivo binário de 24 bytes.

Exemplo

O seguinte cria o arquivo gen.key usando openssl:

openssl rand 24 > /<keyPath>/gen.key

Proteja o arquivo gen.key como qualquer arquivo confidencial. Altere o proprietário para o usuário que está executando o Ops Manager e defina a permissão de leitura e gravação do arquivo somente para o proprietário.

Depois de obter o arquivo gen.key (criado de maneira automática ou manual), antes de iniciar os outros servidores do Ops Manager, copie o arquivo no diretório apropriado no servidor atual e para o diretório apropriado nos outros servidores do Ops Manager:

  • /etc/mongodb-mms/ para instalações de RPM ou Ubuntu

  • ${HOME}/.mongodb-mms/ para instalações de arquivo (.tar)

Importante

  • Qualquer recurso de armazenamento compartilhado que armazena o arquivo gen.key deve ser configurado para alta disponibilidade de forma a não introduzir um ponto único potencial de falha.

  • Qualquer servidor do Ops Manager que não tenha o arquivo gen.key instalado não pode se conectar aos bancos de dados de suporte e se tornar parte de uma instância do HA Ops Manager.

  • Depois de gerar o gen.key para a instância do Ops Manager no primeiro servidor do Ops Manager, faça backup do arquivo gen.key em uma localização segura.

Se você tiver uma instalação do Ops Manager com mais de um host do Ops Manager apontando para o mesmo aplicativo de banco de dados, poderá atualizar o Ops Manager para uma versão mais recente sem incorrer em tempo de inatividade de monitoramento. Após concluir a atualização de um host Ops Manager de um sistema do Ops Manager altamente disponível, esse sistema entra em um estado conhecido como Modo de atualização. Nesse estado, o Ops Manager está disponível durante uma atualização. Os benefícios desse modo são que, durante todo o processo de atualização, o usuário pode fazer a atualização:

  • Alertas e monitoramento operam

  • As instâncias do Ops Manager permanecem ativas

  • O aplicativo do gerente de operações pode ser acessado no modo somente leitura

  • APIs do Ops Manager que gravam ou excluem dados estão desabilitadas

Sua instância do Ops Manager permanece no Modo de atualização até que todos os hosts do Ops Manager tenham sido atualizados e reiniciados. Você não deve atualizar mais de um host do Ops Manager de cada vez.

A distribuição geográfica das instâncias do Banco de Dados de Aplicativo e do Gerenciador de Operações pode afetar o desempenho do Aplicativo do Gerenciador de Operações.

Se você planeja replicar o banco de dados de aplicativos em várias regiões, considere que muitas das operações de volume de trabalho de gravação do Ops Manager usam write concern w:2 , que exige confirmação do nó primário e de um nó secundário do conjunto de réplicas para cada operação de gravação.

Portanto, ter um nó de réplica secundário do banco de dados de aplicativos na mesma região que o nó principal pode levar a um melhor desempenho de leitura e gravação.

Por exemplo, distribuir três nós do conjunto de réplicas do aplicativo de banco de dados em três regiões de forma 1-1-1 pode resultar em um desempenho pior em comparação com a distribuição de três nós de réplicas do aplicativo de banco de dados em duas regiões de forma 2-1, onde uma região hospeda dois nós do conjunto de réplicas do aplicativo de banco de dados e outra região hospeda o terceiro nó do conjunto de réplicas.

A UI do Ops Manager terá melhor desempenho se você se conectar à instância do Aplicativo de Ops Manager distribuída na mesma região que o membro primary do banco de dados do aplicativo do conjunto de réplicas do aplicativo de banco de dados.

Em outras palavras, você pode obter uma melhor experiência do usuário conectando-se à instância do aplicativo de Ops Manager hospedada na mesma região que o nó primário do banco de dados do aplicativo do conjunto de réplicas, em vez de se conectar a uma instância de aplicativo de Ops Manager mais próxima, na qual a própria instância deve se conectar a um nó primário do conjunto de réplicas do banco de dados do aplicativo hospedado em um grupo de réplicas do banco de dados do aplicativo hospedado em uma região diferente e distante com alta latência.

Implemente o conjunto de réplicas que atende ao banco de dados do aplicativo Ops Manager. Para distribuir um conjunto de réplicas, consulte Distribuir um conjunto de réplicas no manual MongoDB.

O procedimento a seguir pressupõe que você tenha gerado o primeiro gen.key usando um dos hosts do aplicativo de Ops Manager. Se, em vez disso, você criar seu próprio gen.key, distribua-o aos hosts do Ops Manager antes de iniciar qualquer um dos aplicativos de Ops Manager.

Importante

O balancer de carga colocado na frente dos servidores de aplicativos de Ops Manager não deve retornar conteúdo armazenado em cache. O balancer de carga deve ter o cache desabilitado.

Para configurar vários aplicativos de Ops Manager com balanceamento de carga:

1

Configure o balancer de carga para realizar uma verificação de integridade em cada ponto de extremidade da API de integridade do Ops Manager:

http://<OpsManagerHost>:<OpsManagerPort>/monitor/health

O Ops Manager responde com um dos dois códigos HTTP:

Código de status HTTP
Status de integridade
200
O host do Ops Manager e o banco de dados de aplicativos parecem saudáveis.
500

O host do Ops Manager ou o aplicativo de banco de dados não parecem íntegros.

Dica

Veja também:

Se esse endpoint retornar HTTP 500 com frequência, consulte a seção Solução de problemas.

O balancer de carga não pode devolver conteúdo em cache.

2
  1. No Ops Manager, clique em Admin, depois na aba General e, em seguida, em Ops Manager Config.

  2. Defina a propriedade URL to Access Ops Manager para apontar para o URL do balancer de carga.

  3. Configure a propriedade Load Balancer Remote IP Header para o nome do campo de cabeçalho HTTP que o balancer de carga usa para identificar o endereço IP do cliente.

    Após o Load Balancer Remote IP Header ser configurado, o Ops Manager habilita os seguintes cabeçalhos HTTP:

    Cabeçalho HTTP
    Encaminhar para o Ops Manager
    Host original que o cliente solicitou no cabeçalho da solicitação HTTP do Host.
    Protocolo usado para fazer a solicitação HTTP.
    Nome de host do servidor proxy.
    Status HTTPS de uma solicitação.
3

Em cada host, edite o arquivo conf-mms.properties para definir a propriedade mongo.mongoUri como a connection string do aplicativo de banco de dados do Ops Manager. Você deve especificar pelo menos 3 hosts na connection string mongo.mongoUri .

mongo.mongoUri=mongodb://<mms0.example.net>:<27017>,<mms1.example.net>:<27017>,<mms2.example.net>:<27017>/?maxPoolSize=100
4

Conclua as etapas a seguir em cada host do agente MongoDB.

  1. Abra o arquivo de configuração do MongoDB Agent.

    vi /path/to/configurationFile.config

    O local do arquivo de configuração Automação depende da sua plataforma:

  2. Edite a propriedade mmsBaseUrl para apontar para o balanceador de carga e salvar as alterações.

    mmsBaseUrl=<LOAD-BALANCER-URL>:<PORT>
  3. Reinicie o MongoDB Agent.

5

Exemplo

Se você instalou o Aplicativo do Ops Manager com um pacote rpm ou deb, emita o seguinte:

service mongodb-mms start
6

O arquivo gen.key está localizado no /etc/mongodb-mms/ para instalações a partir de um gerenciador de pacote e no ${HOME}/.mongodb-mms/ para instalações a partir de um arquivo morto.

Copie o arquivo gen.key do host do aplicativo de Ops Manager em execução para o diretório apropriado nos outros hosts do aplicativo de Ops Manager.

7

Para obter informações sobre como tornar o backup do Ops Manager altamente disponível, consulte Configurar um serviço de backup do Ops Manager altamente disponível.

← Habilitar o monitoramento do aplicativo de banco de dados