Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Sistemas autogerenciados
/
Administração

Lista de verificação de operações para implantações autogerenciadas

Nesta página

  • Sistema de arquivos
  • Replicação
  • Fragmentação
  • Registro em diário: WiredTiger Storage engine
  • Hardware
  • Sistemas em hardware de nuvem
  • Configuração do sistema operacional
  • Backups
  • Monitoramento
  • Balanceamento de carga
  • Segurança

A lista de verificação a seguir, juntamente com a lista de verificação de desenvolvimento, fornece recomendações para ajudá-lo a evitar problemas em sua implantação do MongoDB de produção.

Sistema de arquivos

Replicação

  • Verifique se todos os membros do conjunto de réplicas não ocultos estão provisionados de forma idêntica em termos de RAM, CPU, disco, configuração de rede etc.

  • Configure o tamanho do registro para se adequar ao seu caso de uso:

    • A janela de oplog de replicação deve cobrir as janelas normais de manutenção e tempo de inatividade para evitar a necessidade de uma ressincronização completa.

    • A oplog window de replicação deve cobrir o tempo necessário para restaurar um nó do conjunto de réplicas a partir do último backup.

      Observação

      A janela do oplog de replicação não precisa cobrir o tempo necessário para restaurar um membro do conjunto de réplicas por meio da sincronização inicial, pois os registros do oplog são extraídos durante a cópia dos dados. No entanto, o membro que está sendo restaurado deve ter espaço em disco suficiente no banco de dados local para armazenar temporariamente esses registros oplog durante esse estágio de cópia de dados.

  • O conjunto de réplicas deve incluir pelo menos três membros votantes com dados que sejam executados com registro em diário e que você emita escritas com a write concern w: majority para garantir a disponibilidade e a durabilidade.

  • Use nomes de host ao configurar membros do conjunto de réplicas, em vez de endereços IP.

  • Garanta conectividade de rede bidirecional completa entre todas as instâncias de mongod.

  • Certifique-se de que cada host possa se resolver sozinho.

  • Garanta que o conjunto de réplicas contenha um número ímpar de membros votantes.

  • Garanta que as instâncias do mongod tenham 0 ou 1 votos.

  • Para alta disponibilidade, implemente sua réplica configurada em no mínimo três centro de dados.

Fragmentação

  • Coloque seus servidores de configuração em hardware dedicado para obter o desempenho ideal em clusters grandes. Verifique se o hardware tem RAM suficiente para manter os arquivos de dados inteiramente na memória e se tem armazenamento dedicado.

  • Implemente roteadores do mongos de acordo com as diretrizes de Configuração da Produção.

  • Use o NTP para sincronizar os relógios em todos os componentes do seu cluster fragmentado.

  • Garanta a conectividade de rede bidirecional completa entre mongod, mongos e os servidores de configuração.

  • Use CNAMEs para identificar seus servidores de configuração no cluster. Dessa forma, é possível renomear e renumerar seus servidores de configuração sem tempo de inatividade.

Registro em diário: WiredTiger Storage engine

  • Certifique-se de que todas as instâncias usem o registro no diário.

  • Coloque o diário em seu próprio disco de baixa latência para cargas de trabalho de escrita intensiva. Observe que isso afetará os backups do tipo snapshot, pois os arquivos que constituem o estado do banco de dados residirão em volumes separados.

Hardware

  • Use drives RAID10 e SSD para ter o desempenho ideal.

  • SAN e virtualização:

    • Garanta que cada mongod tenha IOPS provisionado para seu dbPath ou tenha seu próprio drive físico ou LUN.

    • Evite recursos dinâmicos de memória, como memory ballooning, ao executar em ambientes virtuais.

    • Evite colocar todos os membros do conjunto de réplicas no mesmo SAN, pois o SAN pode ser um ponto único de falha.

Sistemas em hardware de nuvem

  • Windows Azure: ajuste a manutenção de atividade do TCP (tcp_keepalive_time) para 100-120. O tempo limite de inatividade do TCP no balanceador de carga do Azure é muito lento para o comportamento de pool de conexões do MongoDB. Consulte: Notas de produção do Azure para obter mais informações.

  • Use o MongoDB versão 2.6.4 ou posterior em sistemas com armazenamento de alta latência, como o Windows Azure, pois essas versões incluem melhorias de desempenho para esses sistemas.

Configuração do sistema operacional

Linux

  • Se estiver executando o MongoDB 8.0 ou posterior, ative Transparent Hugepages.

  • Se estiver executando o MongoDB 7.0 ou anterior, desative Transparent Hugepages.

  • Ajuste as configurações de readahead nos dispositivos que armazenam seus arquivos do banco de dados.

    • Para o mecanismo de armazenamento WiredTiger, defina o readahead entre 8 e 32, independentemente do tipo de mídia de armazenamento (disco giratório, SSD, etc.), a menos que o teste mostre um benefício mensurável, repetível e confiável com um valor de readahead maior.

      O suporte comercial do MongoDB pode fornecer conselhos e orientações sobre configurações alternativas de readahead.

  • Se estiver usando tuned no RHEL /CentOS, você deve personalizar seu perfil tuned. Muitos dos perfis tuned fornecidos com o RHEL /CentOS podem impactar negativamente o desempenho com suas configurações padrão. Personalize o perfil tuned escolhido para:

  • Use os agendadores de disco cfq ou deadline para SSDs.

  • Use o agendador de discos cfq para drives virtualizados em VMs guest.

  • Desative o NUMA ou defina vm.zone_reclaim_mode como 0 e execute instâncias mongod com intercalação de nós. Consulte Hardware do MongoDB e NUMA para obter mais informações.

  • Ajuste os valores de ulimit no hardware de acordo com seu caso de uso. Se várias instâncias mongod ou mongos estiverem sendo executadas sob o mesmo usuário, dimensione os valores ulimit adequadamente. Consulte: Configurações do UNIX ulimit para implantações autogerenciadas para obter mais informações.

  • Use noatime como ponto de montagem dbPath.

  • Configure identificadores de arquivo suficientes (fs.file-max), limite de pid do kernel (kernel.pid_max), máximo de threads por processo (kernel.threads-max) e número máximo de áreas de mapa de memória por processo (vm.max_map_count) para sua implantação. Para sistemas grandes, os seguintes valores fornecem um bom ponto de partida:

    • fs.file-max valor de 98000,

    • kernel.pid_max valor de 64000,

    • kernel.threads-max valor de 64000 e

    • vm.max_map_count valor de 131060

  • Certifique-se de que seu sistema tenha espaço de swap configurado. Consulte a documentação do seu sistema operacional para obter detalhes sobre o tamanho apropriado.

  • Certifique-se de que o keepalive TCP padrão do sistema esteja configurado corretamente. Um valor de 120 geralmente oferece melhor desempenho para conjuntos de réplicas e clusters fragmentados. Consulte: O tempo TCP keepalive afeta as implantações do MongoDB? nas Perguntas Frequentes para obter mais informações.

Windows

  • Considere desabilitar as atualizações do "horário do último acesso" do NTFS. Isso é análogo a desabilitar atime em sistemas do tipo Unix.

  • Formate discos NTFS usando o padrão Allocation unit size de 4096 bytes.

Backups

  • Agende testes periódicos do seu processo de backup e restauração para ter estimativas de tempo em mãos e verificar sua funcionalidade.

Monitoramento

  • Use o MongoDB Cloud Manager ou o Ops Manager, uma solução local disponível no MongoDB Enterprise Advanced ou outro sistema de monitoramento para monitorar as principais métricas do banco de dados e configurar alertas para elas. Incluir alertas para as seguintes métricas:

    • atraso de replicação

    • janela de replicação de registro

    • afirmações

    • queues

    • Falhas na Página

  • Monitore as estatísticas de hardware de seus servidores. Em particular, preste atenção ao uso do disco, à CPU e ao espaço disponível em disco.

    Na ausência de monitoramento do espaço em disco ou como precaução:

    • Crie um arquivo dummy de 4 GB no drive storage.dbPath para garantir que haja espaço disponível se o disco ficar cheio.

    • Uma combinação de cron+df pode alertar quando o espaço em disco atinge uma marca de água alta, se nenhuma outra ferramenta de monitoramento estiver disponível.

Balanceamento de carga

  • Configure os balanceadores de carga para ativar as "sessões fixas" ou afinidade do cliente, com um tempo limite suficiente para as conexões existentes.

  • Evite colocar balanceadores de carga entre o cluster MongoDB ou componentes de conjunto de réplicas.

Segurança

Para obter uma lista de medidas de segurança para proteger sua instalação do MongoDB, consulte a Lista de verificação de segurança do MongoDB.

Voltar

Notas de produção

Próximo

Desempenho