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

Requisitos do sistema do Ops Manager

Nesta página

  • Requisitos de hardware
  • Requisitos de rede
  • Requisitos de software

Esta seção descreve os requisitos de hardware, software e rede para os hosts que executam os componentes do Ops Manager.

Importante

Antes de implementar hosts, use a Lista de verificação de instalação para planejar sua configuração.

Para obter os requisitos para as instâncias do MongoDB em execução como o Banco de Dados do Aplicativo do Ops Manager e o Banco de Dados de Backup, consulte Instalar o Banco de Dados do Aplicativo e o Banco de Dados de Backup do Ops Manager.

Observação

Ao usar o termo hardware nesta página, ele deve ser entendido como as especificações por host usando uma das seguintes arquiteturas:

  • hardware físico,

  • componentes de hardware alocados a um host virtual,

  • componentes de hardware alocados para um contêiner virtual, ou

  • componentes de hardware alocados para um nó de trabalho do Kubernetes.

Cada host deve atender aos requisitos totais de RAM e capacidade de disco para todos os componentes do Ops Manager que ele atende:

  • Aplicativo Ops Manager

  • Bancos de dados de aplicativos do Ops Manager

  • Principais bancos de dados para o(s) Daemon(s) de backup ativo(s)

  • Backup de bancos de dados de blockstore

Exemplo

Você deseja servir o aplicativo MongoDB Ops Manager e um Backup Daemon em um host. Essa configuração do MongoDB Ops Manager gerenciará e monitorará 300 hosts MongoDB , fará backup de 200 hosts e executará o FCV 4.2 ou posterior. A capacidade total de disco de todos os bancos de dados em backup é 4 TB. Os requisitos totais seriam:

  • O aplicativoOps Manager precisa de 15 GB de RAM.

  • O Backup Daemon também precisa de pelo menos 100 GB de capacidade de disco disponível.

Este exemplo de host exigiria um mínimo de 15 GB de RAM e 100 GB de capacidade de disco.

Aviso

Potencial para falha de produção

Sua instância do Ops Manager pode falhar em produção se você não configurar o seguinte:

Todo host que atende ao aplicativo Ops Manager deve atender aos seguintes requisitos de hardware:

Número de hosts monitorados
Núcleos de CPU
Memória física [1]
Disco
Até 400 hosts monitorados
4 +
15 GB
10 GB para o aplicativo Ops Manager no /opt mais armazenamento para registros [2]
Até 2.000 hosts monitorados
8 +
15 GB
10 GB para o aplicativo Ops Manager no /opt mais armazenamento para registros [2]
Mais de 2.000 anfitriões
Contactar o gestor de conta MongoDB
Contactar o gestor de conta MongoDB
Contactar o gestor de conta MongoDB
[1] Memória Física, neste contexto, significa memória residente exibida como RES no comando ps resulta em plataformas Linux. Isso também se aplica a máquinas virtuais e contêineres, mesmo que sua memória física seja uma construção virtual.
[2](1, 2) A capacidade de armazenamento necessária para registros depende de como você Configurar Rotação de Log. Por padrão, os registros giram a cada gigabyte e a cada 24 horas, o que ocorrer primeiro. As estimativas conservadoras exigem a alocação de 30 GB de disco para cada mês de registros que você deseja manter. Revise as configurações de alocação de disco e rotação de registro para obter a configuração de disco ideal.

O Ops Manager Application Database é executado como um conjunto de réplicas de três membros que é executado em hosts dedicados.

Todo host que atende o banco de dados de aplicativo do Ops Manager deve atender os seguintes requisitos de hardware (físico ou virtual):

Número de hosts monitorados
RAM
Capacidade de disco
Núcleos de CPU
Até 400
8 GB de RAM mais a RAM necessária para o aplicativo mongod
200 GB
4 × 2 GHz+
Até 2.000
15 GB de RAM mais a RAM necessária para o aplicativo mongod
500 GB
4 × 2 GHz+
Mais de 2.000
Contacte o seu gestor de conta MongoDB
Contacte o seu gestor de conta MongoDB
Contacte o seu gestor de conta MongoDB

Para obter o melhor desempenho, use:

As estimativas de capacidade de disco são aproximadas. A capacidade de disco necessária pode aumentar ou diminuir devido ao número de bancos de dados monitorados.

Importante

Antes de começar a usar o Backup, entre em contato com o gerente de conta do MongoDB para ajudar a estimar os requisitos de armazenamento do host do Daemon de backup.

Cada host no qual você ativa o Daemon de Backup deve atender aos seguintes requisitos, além daqueles para o Ops Manager.

Cada host que atende a um Daemon de backup ativo tem os seguintes requisitos de hardware:

O backup Daemon deve ter pelo menos 100 GB de capacidade de disco disponível.

Número de hosts
Núcleos de CPU
RAM
Até 200
4+ × 2 GHz+
15 GB de RAM adicional

O Backup Daemon cria bancos de dados principais que replicam dados para cada conjunto de réplicas atribuído ao Daemon. Normalmente, cada host no qual você ativa o Backup Daemon precisa armazenar 2.0 a 2.5 vezes a soma do tamanho no disco de todos os conjuntos de réplicas de backup.

Especificamente, cada host deve ter:

  • A capacidade de disco e a capacidade de gravação para manter cada banco de dados principal, mais

  • A capacidade do disco para armazenar uma cópia adicional dos dados para cada head database para suportar restaurações point-in-time.

Entre em contato com seu gerente de contas do MongoDB para determinar a capacidade do disco e os requisitos de taxa de transferência.

Se você usar o Ops Manager Backup, deverá provisionar hosts para o banco de dados de backup.

Os requisitos de host para o banco de dados de backup variam, dependendo do uso de um banco de dados blockstore ou do armazenamento do sistema de arquivos para armazenar os snapshots. O banco de dados de backup sempre contém dados de registro.

Se você armazenar snapshots no Banco de Dados de Backup, seus hosts normalmente devem ter capacidade suficiente para armazenar de 2 a 3 vezes o tamanho total dos dados de produção de backup. Os snapshots são compactados e eliminados da duplicação no nível do bloco no blockstore.

Seus requisitos específicos dependem da compressibilidade dos dados e da taxa de alteração. Entre em contato com o gerente de conta do MongoDB para ajudar a estimar o caso de uso e os requisitos de armazenamento dependentes da carga de trabalho para seus hosts de banco de dados de backup.

Se você armazenar snapshots no Banco de Dados de Backup, cada membro portador de dados deverá atender aos seguintes requisitos:

Núcleos de CPU
Capacidade de disco
RAM
4 × 2 GHz+

A capacidade mínima de disco necessária para o blockstore do Ops Manager usa a seguinte fórmula:

(2 a 3 vezes o tamanho total do dbPath) * 2 (para permitir trabalhos de limpeza)

Entre em contato com o suporte do MongoDB para determinar a capacidade mínima de disco com precisão.

8 GB de RAM por TB de disco de blockstore para fornecer uma bom snapshot e velocidade de restauração. O Ops Manager define 1 TB de blockstore como 1024 4 bytes.

Entre em contato com seu gerente de contas do MongoDB para determinar a capacidade do disco e os requisitos de taxa de transferência.

Se você não armazenar snapshots no Banco de Dados de Backup, cada membro portador de dados deverá atender os seguintes requisitos:

Núcleos de CPU
Capacidade de disco
4 × 2 GHz+
O tamanho dos oplogs compactados para a janela point-in-time configurada. O padrão é 24 horas.

Se você configurou o Ops Manager para fazer download de binários diretamente da Internet, o Ops Manager precisará acessar os seguintes sites da Internet por HTTPS usando solicitações IPv4 e IPv6 para a Internet:

Local
Propósito
downloads.mongodb.com
opsmanager.mongodb.com
Para fazer o download do manifesto da versãodo MongoDB.
fastdl.mongodb.org
Para fazer o download das compilações da MongoDB Community.

As conexões entre o host do aplicativo Ops Manager e seus conjuntos de réplicas do banco de dados do aplicativo, Oplog e blockstore devem ter a menor latência de rede possível. Com sistemas excedendo 200 hosts MongoDB, a latência entre os componentes do aplicativo Ops Manager deve ser inferior a 1 ms. Entre em contato com o suporte do MongoDB se achar que seu ambiente de rede não pode atender esse requisito.

Muitos componentes do Ops Manager se conectam a um processo mongod em execução. Esses incluem:

  • o banco de dados do aplicativo,

  • qualquer banco de dados de backup, e

  • qualquer banco de dados MongoDB que o MongoDB Agent gerencia

Os sistemas que hospedam esses componentes enviam tráfego de dados uns para os outros para verificar uma conexão ativa. A configuração de manutenção do TCP determina com que frequência executar esta verificação. A maioria dos sistemas usa o valor padrão de 7200 segundos (duas horas).

A conexão de rede pode cair dentro desse período. Sem uma conexão existente, o Ops Manager deve criar uma nova conexão com esse processo mongod . Isso pode atrasar a comunicação ou resultar em tempos limite de rede ou erros de soquete. Para evitar esse problema, reduza o valor de manutenção para aumentar as verificações de verificação. Todos os componentes do Ops Manager devem usar o mesmo valor de manutenção.

Para saber como definir isso para o valor recomendado, consulte O tempo de manutenção de atividade do TCP afeta implantações do MongoDB?​, no Manual do MongoDB Server.

Cada host de MongoDB Agent e MongoDB deve se autoidentificar como seu FQDN para garantir conectividade confiável.

Use o comando a seguir para encontrar o host FQDN:

> hostname -f

Seu resultado deve ficar assim:

mongodb.example.com

O host do Windows deve estar conectado à internet e anexado a um domínio do Active Directory.

Use o comando a seguir para encontrar o host FQDN:

PS C:\> systeminfo | findstr /B /C:"Host" /C:"Domain"

Seu resultado deve ficar assim:

Host Name: mongodb
Domain: example.com

Combine Host Name e Domain com um . para obter o FQDN. Com o exemplo anterior, o FQDN é mongoodb.example.com.

O aplicativo MongoDB Ops Manager deve ser capaz de se conectar a usuários e agentes MongoDB por HTTP ou HTTPS. MongoDB Agents devem ser capazes de se conectar aos MongoDB client MongoDB databases.

Embora o Ops Manager exija apenas portas de rede HTTP (ou HTTPS) e MongoDB abertas para se conectar com usuários e bancos de dados, quais portas são abertas em um firewall dependem de quais recursos estão habilitados: criptografia, autenticação e monitoramento.

Esta página define quais sistemas precisam se conectar a quais portas em outros sistemas.

O Ops Manager se conecta a vários serviços. Esta página explica as portas que devem ser abertas para implantar os vários componentes usados com uma sistema do Ops Manager.

As portas específicas que devem ser abertas em qualquer firewall intermediário dependem de quais recursos estão habilitados, como criptografia, autenticação e monitoramento.

Diagrama mostrando as conexões entre os componentes do Ops Manager.
clique para ampliar

Dica

Todas as portas listadas nas seguintes seções são a porta especificada na documentação para instalações do MongoDB ou as portas conhecidas para o serviço específico atribuído pela IANA. Se o número da porta puder ser alterado, ele será observado após a tabela em cada seção.

Para executar o Ops Manager sem uma conexão com a Internet, consulte Configurar sistema para ter acesso limitado à Internet para garantir que você tenha todos os binários necessários para executar o Ops Manager sem uma conexão com a Internet.

O Ops Manager exige os seguintes requisitos mínimos de porta de rede:

  • Tanto os users do Ops Manager quanto os agentes do MongoDB devem ser capazes de se conectar ao aplicativo Ops Manager por HTTP ou HTTPS.

  • O Ops Manager deve ser capaz de se conectar ao mongod que executa os bancos de dados MongoDB do aplicativo Ops Manager.

  • Para cada projeto do Ops Manager, os MongoDB Agents devem ser capazes de se conectar a todos os processos MongoDB do cliente (mongod ou mongos).

  • O aplicativo Ops Manager também deve ser capaz de enviar e-mails aos usuários do Ops Manager.

Para usar o Ops Manager, abra as seguintes portas para os hosts especificados.

Serviço, serviço
Porta padrão
Transporte
Direção
Propósito
Utiliza TLS?

HTTP

8080

TCP

Entrada
Fornece uma conexão web ao Ops Manager de usuários e MongoDB Agents.
Não

HTTPS

8443

TCP

Entrada
Fornece uma conexão segura com o Ops Manager a partir de usuários e MongoDB Agents.
Sim
HTTP ou HTTPS
8090

TCP

Entrada

Fornece um endpoint de verificação de integridade para monitorar o Ops Manager por meio de um serviço de monitoramento como Zabbix ou Nagios. Ele só está disponível por meio de localhost e está desativado por padrão.

Para habilitá-lo, consulte Habilitar o Health Check Endpoint. Quando ativado, você pode acessar o endpoint em:

http://127.0.0.1:8090/health

Importante

Esta porta só é acessível a partir de localhost (ou 127.0.0.1). O número da porta pode ser alterado de 8090 para outro valor.

O endpoint da API oferece a capacidade de verificar as conexões do serviço HTTP com o banco de dados do aplicativo Ops Manager e o armazenamento de snapshots de backup.

Uma resposta bem-sucedida retorna o seguinte:

{
"mms_db": "OK",
"backup_db": "OK"
}
Opcional
MongoDB
27017

TCP

saída
Conecta-se ao aplicativo MongoDB, backup e bancos de dados de clientes.
Opcional

SMTP

587

TCP

saída
Envia e-mails do Ops Manager para um host SMTP ou para o AWS SES.
Opcional

Observação

A maioria da administração do Ops Manager pode ser realizada por meio da interface do usuário. Alguns procedimentos exigem acesso ao sistema operacional. Para permitir que seus administradores acessem seu Ops Manager, bem como os hosts do MongoDB, abra as seguintes portas para esses hosts.

Serviço, serviço
Porta padrão
Transporte
Direção
Propósito
Utiliza TLS?
ssh
22

TCP

Entrada
Administração do sistema Linux.
Sim
RDP
3389

TCP

Entrada
Administração do sistema Windows.
Não

O Ops Manager pode fazer backup de bancos de dados MongoDB em um ou mais sistemas de armazenamento:

Para fazer backup de hosts MongoDB, abra as seguintes portas para os hosts de backup preferidos (armazenamento de blocos, armazenamento de snapshots de armazenamento compatível com S3 e/ou armazenamento de snapshots do sistema de arquivos):

Serviço, serviço
Porta padrão
Transporte
Direção
Propósito
Utiliza TLS?
MongoDB
27017

TCP

saída
Faça backup de snapshots de todo o banco de dados para blockstore ou snapshots de metadados para o banco de dados de metadados de blockstore de armazenamento compatível com o S3.
Opcional

HTTPS

443

TCP

saída
Faça backup dos dados do snapshot do banco de dados em um bucket de armazenamento compatível com S3.
Sim

NFS

2049

TCP

saída
Faça backup de capturas de imagens do banco de dados no sistema de arquivos baseado em UNIX/Linux-based.
Não

CIFS

3020

TCP

saída
Faça backup de snapshots do banco de dados no sistema de arquivos baseado no Windows.
Não
Servidor proxy
25999

TCP

saída
Consulte o host de backup de captura instantânea.
Não

Os snapshots também podem ser restaurados usando o link exibido no aplicativo Ops Manager. As mesmas portas necessárias para usar o Ops Manager precisariam estar abertas para que o usuário baixasse o snapshot.

Para encontrar o link de download, clique em Continuous Backup, na guia Restore History e, em seguida, clique no link download ao lado do snapshot.

Observação

MongoDB 3.4.2 O Enterprise e o posterior oferecem a capacidade de executar queries de snapshots de backup. O Ops Manager provisiona esses snapshots consultáveis como instâncias do MongoDB somente leitura, conforme descrito em Query a Backup. Para executar query de uma captura de imagem da cópia de segurança, abra as seguintes portas:

Serviço, serviço
Porta padrão
Transporte
Direção
Propósito
Utiliza TLS?
MongoDB
27700 - 27719

TCP

Entrada
Habilite a comunicação entre o host do aplicativo e um snapshot de backup para query
Opcional

Abra as seguintes portas entre o Ops Manager e o SNMP Manager para enviar e receber notificações de captura SNMP de suas MongoDB deployments para o Ops Manager.

Importante

Ops Manager 6.0.0 descontinua alerta SNMP. Ops Manager 7.0.0 não incluirá alerta SNMP. Para saber mais sobre outras opções de alerta, consulte Integrações de serviços de terceiros.

Serviço, serviço
Porta padrão
Transporte
Direção
Propósito
Utiliza TLS?

SNMP

162

UDP

saída
Enviar capturas para o gerenciador SNMP.
Não

SNMP

11611

UDP

Entrada
Receber solicitações do SNMP Manager.
Não

MongoDB Ops Manager O usa SNMPv baseado em comunidade2 (SNMPv2c).

Importante

Ops Manager 6.0.0 descontinua alerta SNMP. Ops Manager 7.0.0 não incluirá alerta SNMP. Para saber mais sobre outras opções de alerta, consulte Integrações de serviços de terceiros.

Você pode configurar o aplicativo Ops Manager com dois tipos diferentes de capturas SNMP :

Tipo de armadilha
Conteúdos
Frequência
Alvo
Batida de coração
Avaliação de integridade interna do aplicativo MongoDB Ops Manager
Conjunto do usuário
um ou mais endpoints
Alerta
Conjunto do usuário
um ou mais endpoints

Para configurar o Aplicativo MongoDB Ops Manager para enviar SNMPv2c Heartbeat ou Alert Traps:

  1. Baixe o arquivo MIB.

  2. Para configurar SNMPv2c Traps:

    1. Para SNMPv2c Heartbeat Traps:

    2. Para armadilhas de alerta SNMPv2c:

Os usuários do MongoDB Enterprise podem autenticar usuários do Ops Manager usando o LDAP. Para autenticar usando o LDAP, abra as seguintes portas no Ops Manager e no seu host LDAP.

Serviço, serviço
Porta padrão
Transporte
Direção
Propósito
Utiliza TLS?

LDAP

389

UDP

Ambos
Autenticar e/ou autorizar usuários do Ops Manager em relação ao host do LDAP.
Não

LDAPS

636

UDP

Ambos
Autenticar e/ou autorizar usuários do Ops Manager em relação ao host do LDAP.
Sim

Para configurar as cadeias de URI LDAP do Ops Manager, incluindo a configuração de uma porta não padrão, consulte Autenticação do usuário.

Os usuários do MongoDB Enterprise podem usar Kerberos ou LDAP para autenticar usuários do MongoDB. Para autenticar usando LDAP ou Kerberos, abra as seguintes portas entre os bancos de dados de clientes MongoDB, Ops Manager e o(s) host(s) Kerberos ou LDAP.

Serviço, serviço
Porta padrão
Transporte
Direção
Propósito
Utiliza TLS?
Kerberos
88
TCP / UDP
saída
Solicite autenticação para usuários MongoDB em relação ao host Kerberos.
Não
Kerberos
88

UDP

Entrada
Receber autenticação para usuários MongoDB em relação ao host Kerberos.
Não

LDAP

389

UDP

Ambos
Autenticar e/ou autorizar usuários MongoDB em relação ao host LDAP.
Não

LDAPS

636

UDP

Ambos
Autenticar e/ou autorizar usuários MongoDB em relação ao host LDAP.
Sim

Para configurar o Kerberos para autenticação no banco de dados do aplicativo Ops Manager, consulte Configurar o Ops Manager para autenticação combancos de dados de aplicativos.

As implementações do MongoDB Enterprise usando o mecanismo de armazenamento WiredTiger oferecem suporte a uma opção de criptografia nativa. Você pode usar um serviço KMIP para gerenciar a chave de criptografia mestre. Para suportar o mecanismo de armazenamento criptografado via KMIP, abra as seguintes portas entre os hosts do Backup Daemon, os hosts MongoDB e os hosts KMIP.

Serviço, serviço
Portas padrão
Transporte
Direção
Propósito
Utiliza TLS?

KMIP

5696

TCP

saída
Envie mensagens entre bancos de dados MongoDB e host KMIP.
Sim

Observação

Se você alterar a porta do host KMIP, consulte Instantâneos de backup criptografados para configurar o Ops Manager para usar essa nova porta.I

Se o Ops Manager não estiver configurado para o modo local, ele precisará acessar os seguintes sites da Internet por HTTPS:

Local
Propósito
downloads.mongodb.com
opsmanager.mongodb.com
Para fazer o download do manifesto da versãodo MongoDB.
fastdl.mongodb.org
Para fazer o download das compilações da MongoDB Community.

Cada instância do MongoDB Agent e do Gerenciador de Operações deve ser capaz de resolver o nome do host para cada host que hospeda uma instância do MongoDB ou do MongoDB Agent.

Em cada host, defina seus nomes de host para nomes de domínio totalmente qualificados (FQDN) sempre que possível. Consulte a documentação do seu sistema operacional sobre como localizar e definir o nome do host como FQDN.

A configuração do FQDN em cada host ajuda a saber qual host você está usando quando estiver conectado a esse host. Para permitir que outros hosts saibam quais são os nomes de host dos outros hosts, você precisa fornecer uma maneira de esses hosts resolverem os nomes de host.

Existem duas maneiras de configurar a resolução do nome de host.

Para tornar os nomes de host dos hosts resolvíveis, execute um host com um serviço de nome de domínio (DNS). DNS mapeia endereços IP para nomes de host com um determinado domínio (como example.com). Esse host de DNS deve ter uma entrada para cada host na sistema: MongoDB Ops Manager, MongoDB Agent e MongoDB. Recomenda-se a inclusão de entradas para LDAP, Kerberos, SNMP e hosts de e-mail, além de balanceadores de carga.

Importante

Ops Manager 6.0.0 descontinua alerta SNMP. Ops Manager 7.0.0 não incluirá alerta SNMP. Para saber mais sobre outras opções de alerta, consulte Integrações de serviços de terceiros.

Se uma configuração de DNS não for possível, adicione entradas para cada host no arquivo hosts de cada sistema.

Sistema operacional
hosts Localização
Linux
/etc/hosts
Mac OS X
/private/etc/hosts
Windows
%SystemRoot%\System32\drivers\etc\hosts

Isso normalmente resulta em:

C:\Windows\System32\drivers\etc\hosts

O arquivo hosts é um texto sem formatação legível e deve ser editado com permissões do root ou Administrator. O formato de entrada é escrito como:

127.0.0.1 localhost
10.15.0.5 opsmgr.example.dev
10.15.10.15 rs1.example.dev
10.15.10.16 rs2.example.dev
10.15.10.17 rs3.example.dev

Os hosts que executam componentes do Ops Manager devem atender aos seguintes requisitos de software:

Importante

O Ops Manager 5.0 e posterior exige o Bash 4.2 ou posterior.

Os hosts que executam o Ops Manager devem ser executados em uma versão de 64 bits de um dos seguintes sistemas operacionais:

Sistema operacional
MongoDB Ops Manager 5.0
Gerente de operações 6.0
Amazon linux
2
2
Debian
9 , 10 , 11
10 , 11
RHEL / CentOS 1
7 , 8
7 , 8 , 9
SUSE linux enterprise server
12 , 15
12 , 15
Ubuntu
18.04, 20.04
18.04, 20.04

1 RHEL é diferente do Servidor RHEL . O Ops Manager suporta apenas RHEL.

Observação

Embora o MongoDB Agent possa ser instalado em arquiteturas s390x e PowerPC (ppc64le), o aplicativo Ops Manager não pode ser instalado nessas plataformas. Você deve instalar o aplicativo Ops Manager em uma das plataformas listadas na tabela anterior.

Os hosts que executam MongoDB Agents devem ser executados em uma versão de 64 bits de uma das seguintes arquiteturas de hardware e sistemas operacionais. A tabela a seguir lista as versões do MongoDB Server que você pode implantar com o MongoDB Agent nas plataformas associadas:

Arquitetura
Distribuição/sistema operacional
6.0
5.0
4.4
4.2
4.0
3.6
x86_64
RHEL/CentOS/Oracle Linux 7 1
RHEL/Rocky/Alma linux/Oracle linux 8 1
RHEL/Rocky/Alma linux/Oracle linux 9 1
Amazon Linux 2
SUSE12
SUSE15
Debian 8
Debian 9
Debian 10
Debian 11
Ubuntu 16.x
Ubuntu 18.x
Ubuntu 20.x
Ubuntu 22.x 2
Windows
BRAÇO
RHEL/ Centos 8
RHEL/CentOS 9
Amazon Linux 2
PowerPC/ ppc64le
RHEL/ Centos 7
RHEL/ Centos 8
zSeries/ 390x
RHEL 7
RHEL 8

1 O MongoDB é compatível apenas com o Oracle Linux que executa RHCK . O MongoDB não é compatível com o Oracle Linux que executa o UEK.

2 MongoDB connector O para BI não Ubuntu 22.04 é compatível com o .

O suporte para a execução do MongoDB Agent no Windows 2008 ou Windows Server 2008R2 termina no início do Ops Manager 5.0.

O MongoDB Agent ainda suporta o gerenciamento de sistemas MongoDB executadas no Windows 2016, 2019 e 2020.

Observação

A partir do servidor MongoDB Ops Manager MongoDB 4.0.11, As arquiteturas do Windows exigem os pacotes redistribuíveis do Visual C++ para Visual Studio 2013.

O Ops Manager requer a opção de exec padrão definida em /etc/fstab na máquina host subjacente para executar os binários necessários armazenados no volume que faz backup do diretório /var .

O pacote Ops Manager gera automaticamente o seguinte ulimits:

  • Abrir arquivos

  • Máximo de processos de usuário

  • Memória virtual

RHEL e CentOS 6 limitam o número máximo de processos de usuário para 1024. Isso substitui a configuração do limite geral do processo do usuário (ulimit -u).

Para o userid que executa o Ops Manager (mongodb-mms por padrão), adicione entradas soft e hard nproc (número de processos) ao arquivo de configuração do processo do usuário /etc/security/limits.d/99-mongodb-nproc.conf . Use valores maiores que o RHEL 1024 limite de processo do usuário.

mongodb-mms soft nproc 200000
mongodb-mms hard nproc 500000

Se /etc/security/limits.d/99-mongodb-nproc.conf não existir, crie-o. Use o conteúdo do arquivo /etc/security/limits.d/90-nproc.conf como modelo.

Para a seguinte série de versões do Ops Manager, você pode executar seus bancos de dados de backup em qualquer uma das seguintes versões do MongoDB:

Lançamento do Gerenciador de Operações
MongoDB 4.2
MongoDB 4.4
MongoDB 5.0
MongoDB 6.0
MongoDB Ops Manager 5.0
Obsoleto(a)
Suportado
Suportado
Gerente de operações 6.0
Obsoleto(a)
Suportado
Suportado

Observação

Uma versão obsoleta continua funcionando com a versão correspondente do Ops Manager, no entanto, deixaremos de oferecer suporte para essa versão no próximo lançamento. O suporte do MongoDB recomenda migrar para uma versão compatível para evitar possíveis problemas de incompatibilidade.

Para saber mais, consulte a Política de suporte legado do MongoDB e Programações do ciclo de vida do software MongoDB para o Ops Manager.

O suporte à versão abrange a série completa de lançamentos, do primeiro ao último lançamento.

Para saber mais sobre a versão MongoDB, consulte Versões do MongoDB no Manual MongoDB.

Importante

Somente o MongoDB Ops Manager bancos de dados de backup devem atender a esse requisito. As implementações do MongoDB que o Ops Manager gerencia não. Para obter as versões mínimas necessárias para sistemas gerenciadas do MongoDB, consulte a array de compatibilidade do MongoDB.

Consulte as páginas a seguir no manual do MongoDB para obter os requisitos ulimit dos hosts que executam o MongoDB (hosts do Daemon de Backup e do Ops Manager Backing Databases):

Instale e verifique um servidor de e-mail. O Ops Manager precisa de um servidor de e-mail para enviar alertas e recuperar contas de usuário. Você pode usar um servidor SMTP ou um servidor AWS SES. Para configurar seu servidor de e-mail, consulte Email Delivery Method Configuration.

Muitas distribuições orientadas ao host do Linux incluem um servidor SMTP local por padrão. Estes incluem, mas não estão limitados a:

O Windows Server inclui um relé SMTP com o Internet Information Server.

Você também pode configurar o Ops Manager para enviar e-mails por provedores terceirizados. Estes incluem, mas não estão limitados a:

Se o seu ambiente incluir SNMP, você poderá configurar um receptor de armadilha SNMP com armadilhas de pulsação periódicas para monitorar a integridade interna do Ops Manager. O Ops Manager usa SNMP v2c. Para saber mais, consulte Configurar suporte do SNMP Heartbeat.

Importante

Ops Manager 6.0.0 descontinua alerta SNMP. Ops Manager 7.0.0 não incluirá alerta SNMP. Para saber mais sobre outras opções de alerta, consulte Integrações de serviços de terceiros.

Ao instalar o Ops Manager versão 4.0.13 ou posterior em hosts Linux, instale o pacote fontconfig para habilitar a exportação de dados da guia Status para formato PDF ou PNG.

Para usar o Ops Manager, você deve usar um dos seguintes navegadores compatíveis com o Javascript habilitado:

Navegador da Web suportado
Versão(s) suportada(s)
estábulo mais recente
estábulo mais recente
estábulo mais recente
estábulo mais recente

O Ops Manager exibe um aviso em navegadores não compatíveis.

Voltar

Lista de verificação de instalação