Planeje seu recurso do Ops Manager

Nesta página

Arquitetura

Considerações
chave de criptografia
Banco de dados de aplicativos
Configuração simplificada
Backup.
Configurar o Ops Manager para executar sobre HTTPS
Acesso ao aplicativo do Ops Manager
Implantação do Ops Manager no modo remoto ou local
Gerenciando sistemas externos do MongoDB
Implementando o MongoDB Ops Manager em Multi-Clusters
Armazenamento secreto
Pré-requisitos

MongoDB MongoDB Ops Manager é um aplicativo empresarial que gerencia, faz backup e monitora os sistemas do MongoDB . Com o MongoDB Ops Manager, você pode escalar e atualizar o MongoDB, otimizar queries, executar restaurações point-in-time, receber alertas de desempenho e monitorar seus sistemas. Para gerenciar e manter o MongoDB Ops Manager e seu banco de dados subjacente, você pode usar o MongoDB Enterprise Kubernetes Operator para executar o MongoDB Ops Manager como um recurso distribuído em um container no Kubernetes.

Você pode distribuir recursos MongoDB Ops Manager de uma das seguintes maneiras:

Modo de cluster Kubernetes único. Você pode implantar uma única instância MongoDB Ops Manager para dar suporte à sua implantação de cluster Kubernetes único dos recursos do MongoDB .
Modo de cluster múltiplo do Kubernetes. Você pode implantar várias instâncias do MongoDB Ops Manager e do banco de dados de aplicativos em vários clusters do Kubernetes . Neste modo, o multicluster de recursos do Ops Manager suporta uma implantação do Aplicativo MongoDB Ops Manager e do Banco de Dados de Aplicativo em vários clusters do Kubernetes .

Antes de implementar um recurso do Ops Manager em um ou vários clusters do Kubernetes, revise a arquitetura do Ops Manager no Kubernetes e as considerações, e conclua os pré- requisitos.

Arquitetura

Para obter detalhes da arquitetura de recursos MongoDB Ops Manager , consulte:

Sistemas de cluster Kubernetes únicos de recursos do Ops Manager: Arquitetura do Ops Manager no Kubernetes.
Vários sistemas de cluster Kubernetes de recursos do Ops Manager: Arquitetura do Ops Manager de vários clusters.

Considerações

chave de criptografia

O Operador Kubernetes gera uma chave de criptografia para proteger informações confidenciais no Ops Manager Application Database. O Kubernetes operador do salva esta chave em um segredo no mesmo namespace que o MongoDB Ops Manager recurso . O Operador Kubernetes nomeia o segredo <om-resource-name>-gen-key.

Observação

Para evitar o armazenamento de segredos em sistemas do Kubernetes de cluster único, você pode migrar todos os segredos para uma ferramenta de armazenamento secreta. As implantações em vários clusters do Kubernetes não oferecem suporte ao armazenamento de segredos em ferramentas de armazenamento de segredos, como o HashiCorp Vault.

Se você remover o recurso MongoDB Ops Manager , a chave permanecerá armazenada no segredo no cluster Kubernetes . Se você armazenou o banco de dados do aplicativo em um volume persistente e você criar outro MongoDB Ops Manager recurso do com o mesmo nome, o Kubernetes Operator reutiliza o segredo. Se você criar um recurso MongoDB Ops Manager com um nome diferente, o Kubernetes Operator criará um novo segredo e o aplicativo de banco de dados, e o segredo antigo não será reutilizado.

Banco de dados de aplicativos

topologia

Quando você cria uma instância do MongoDB Ops Manager por meio do Operador Kubernetes em um único cluster Kubernetes , o Ops Manager Application Database é distribuído como um conjunto de réplicas. Não é possível configurar o Banco de Dados de Aplicativo como um banco de dados autônomo ou um cluster fragmentado. Se tiver dúvidas sobre os requisitos de desempenho ou tamanho do Banco de Dados de Aplicativos, entre em contato com o Suporte do MongoDB.
Quando você cria uma instância do Ops Manager por meio do Operador Kubernetes em um modo de vários clusters, o Operador Kubernetes pode configurar o Banco de Dados de Aplicativos do Ops Manager em vários clusters de membros. Para saber mais, consulte Arquitetura do Multi-Cluster Ops Manager.

Monitoramento

O Operador do Kubernetes configura automaticamente o Ops Manager para monitorar o reconhecimento de data center que oferece suporte à aplicação do Ops Manager. O Kubernetes cria um projeto denominado <ops-manager-deployment-name>-db para você monitorar o comando de banco de dados do banco de dados de aplicativo.

O Ops Manager monitora o comando de banco de dados de aplicação, mas o Ops Manager não o managed. Você não pode alterar a configuração do banco de dados do aplicativo no aplicativo Ops Manager.

Importante

A interface do usuário do Ops Manager pode exibir avisos no projeto <ops-manager-deployment-name>-db informando que os agente do banco de dados de aplicativo estão desatualizados. Você pode ignorar esses avisos com segurança.

Autenticação

O Operador Kubernetes força a autenticação SCRAM-SHA-256 no Aplicativo de banco de dados.

O Operador Kubernetes cria o trigger de banco de dados que o Ops Manager usa para se conectar ao reconhecimento de data center de aplicação. Esse trigger de banco de dados tem os seguintes atributos:


Nome de usuário	`mongodb-ops-manager`
Banco de dados de autenticação	`admin`
Funções	`readWriteAnyDatabase` `dbAdminAnyDatabase` `clusterMonitor`

Você não pode modificar o nome e as funções do usuário do banco de dados do MongoDB Ops Manager . Você cria um segredo para definir a senha do usuário do banco de dados. Você edita o segredo para atualizar a senha. Se você não criar um segredo ou excluir um segredo existente, o Operador Kubernetes gerará uma senha e a armazenará.

Para saber mais sobre outras opções de armazenamento secreto, consulte Configurar armazenamento secreto. Os sistemas de vários clusters não suportam o armazenamento de segredos no HashiCorp Vault.

Sistemas offline

O Operador Kubernetes exige que você especifique a versão MongoDB Enterprise para a imagem do Banco de Dados de Aplicativo para permitir quaisquer sistemas de recursos do MongoDB Ops Manager , incluindo sistemas offline.

Configuração simplificada

Depois de implementar o MongoDB Ops Manager, é necessário configurá-lo. O procedimento regular envolve a configuração do MongoDB Ops Manager por meio do assistente de configuração. Se você definir algumas configurações essenciais na especificação do objeto antes de implementá-lo, poderá ignorar o assistente de configuração.

No bloco spec.configuration da especificação do objeto do Ops Manager, você precisa:

Adicione mms.ignoreInitialUiSetup e configure para true.
Adicione as definições mínimas de configuração para permitir que a instância do MongoDB Ops Manager seja iniciada sem erros.

Exemplo

Para desabilitar o assistente de configuração do Ops Manager, defina as seguintes configurações em seu bloco spec.configuration :

1 spec:
2   configuration:
3     mms.ignoreInitialUiSetup: "true"
4     automation.versions.source: "remote"
5     mms.adminEmailAddr: cloud-manager-support@mongodb.com
6     mms.fromEmailAddr: cloud-manager-support@mongodb.com
7     mms.mail.hostname: email-smtp.us-east-1.amazonaws.com
8     mms.mail.port: "465"
9     mms.mail.ssl: "true"
10     mms.mail.transport: smtp
11     mms.minimumTLSVersion: TLSv1.2
12     mms.replyToEmailAddr: cloud-manager-support@mongodb.com

Substitua os valores de exemplo pelos valores que você deseja que seu Ops Manager use.

Backup.

O Kubernetes Operator ativa o Backup por padrão. O Operador Kubernetes implementa um StatefulSet composto por um Pod para hospedar o Serviço de Daemon de Backup e, em seguida, cria uma Declaração de Volume Persistente e volume persistente para o banco de dados principal do Backup Daemon. O Kubernetes Operator usa a do para ativar o Backup Daemon e configurar o head MongoDB Ops Manager API database.

Importante

Para configurar o Backup, você deve criar os recursos MongoDB ou MongoDBMultiCluster para o armazenamento de oplog e para um dos seguintes:

armazenamento de oplog ou armazenamento de oplog S3 . Se você implantar o oplog armazenamento de e o armazenamento de S3 oplog , MongoDB Ops Manager o escolherá um aleatoriamente para usar para backup.
S3 armazenamento de snapshots ou blockstore. Se você implantar um armazenamento de snapshots S3e um armazenamento de blocos, oMongoDB Ops Manager escolherá um para usar para backup aleatoriamente.

O recurso do Ops Manager permanece em um estado Pending até que você configure estes recursos de backup.

Você também pode criptografar tarefas de backup, mas limitações se aplicam a sistemas em que a mesma instância do Kubernetes Operator não está gerenciando os recursos personalizados MongoDBOpsManager e MongoDB .

Oplog Store

Você deve implantar um conjunto de réplica de três membros para armazenar suas fatias de oplog.

O reconhecimento de data center oplog oferece suporte apenas ao mecanismo de autenticação SCRAM . Não é possível habilitar outros mecanismos de autenticação.

Se você habilitar a autenticação SCRAM no reconhecimento de data center oplog, deverá:

Crie um recurso de usuário MongoDB para conectar o Ops Manager ao reconhecimento de data center oplog.
Especifique o name do usuário na definição de recurso do Ops Manager.

S3 oplog Store

Para configurar um armazenamento de oplog no S3 , você deve criar um bucket compatível com o Amazon Web Services S3 ou o S3para armazenar seu reconhecimento de data center oplog.

Você pode configurar o armazenamento de oplog para o recurso MongoDB e o recurso MongoDBMultiCluster , usando a configuração spec.backup.s3OpLogStores.mongodbResourceRef.name na definição de recursos do Ops Manager.

blockstore

Para configurar um blockstore, você deve implementar um conjunto de réplicas para armazenar snapshots.

Armazenamento de snapshots do S3

Para configurar um armazenamento de snapshots S3 , você deve criar um bucket compatível com S3 ou S3 do Amazon Web Services para armazenar os snapshots debackup do banco de dados.

A configuração padrão armazena metadados de snapshot no Banco de Dados do Aplicativo. Você também pode implantar um conjunto de réplicas para armazenar metadados de snapshot e, em seguida, configurá-lo usando as configurações spec.backup.s3Stores.mongodbResourceRef.name na definição de recursos do Ops Manager.

Você pode configurar o armazenamento de snapshots do S3 para o recurso MongoDB e o recurso MongoDBMultiCluster .

Você pode atualizar quaisquer definições de configuração adicionais do S3que Kubernetes o Operator não gerencia por meio do MongoDB Ops Manager aplicativo .

Desabilitar cópia de segurança

Para desabilitar o backup depois de habilitá-lo:

Definir o objeto do Ops spec.backup.enabled Manager Kubernetes configuração como false.
Desative os backups no aplicativo MongoDB Ops Manager .
Excluir o serviço StatefulSet do Backup Daemon :
```
kubectl delete statefulset <metadata.name> -backup-daemon \
 -n <metadata.namespace>
```

Importante

A reivindicação de volume persistente e volume persistente para o banco de dados principal do Backup Daemon não é excluído quando você exclui o Serviço do Backup Daemon StatefulSet. Você pode recuperar dados armazenados antes de excluir esses recursos do Kubernetes.

Para saber mais sobre a recuperação de Volumes persistentes, consulte a documentação do Kubernetes.

Configurar manualmente a criptografia de backup KMIP

Para implementações em que a mesma instância do Kubernetes Operator não está gerenciando os recursos personalizados MongoDBOpsManager e MongoDB , você deve definir manualmente as configurações do cliente de criptografia de backup KMIP no Ops Manager usando o procedimento a seguir. Se o Kubernetes Operator estiver gerenciando os dois recursos, consulte Configurar o KMIP Backup Encryption para o Ops Manager .

Pré-requisitos

Um servidor KMIP em execução.
Uma instância MongoDB Ops Manager em execução, configurada para usar KMIP.
Um segredo TLS que concatena a chave privada e o certificado do cliente KMIP no formato PEM.

Procedimento

Monte o segredo TLS no recurso personalizado MongoDBOpsManager . Por exemplo:

apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: ops-manager-pod-spec
spec:
  < ... omitted ... >
  statefulSet:
    spec:
      template:
        spec:
          volumes:
          - name: kmip-client-test-prefix-mdb-latest-kmip-client
            secretName: test-prefix-mdb-latest-kmip-client
          containers:
            - name: mongodb-ops-manager
              volumeMounts:
              - mountPath: /mongodb-ops-manager/kmip/client/test-prefix-mdb-latest-kmip-client
                name: kmip-client-test-prefix-mdb-latest-kmip-client
                readOnly: true
  ...

Configure as configurações de KMIP para seu projeto no MongoDB Ops Manager seguindo o procedimento em Configurar seu projeto para utilizar KMIP.

Configurar o Ops Manager para executar sobre HTTPS

Você pode configurar sua instância do Ops Manager criada por meio do Kubernetes Operator para ser executada em HTTPS em vez de HTTP.

Para configurar sua instância do Ops Manager para ser executada por HTTPS:

Crie um segredo que contenha o certificado TLS e a chave privada.
Adicione este segredo ao objeto de configuração do Ops Manager.

Para obter instruções detalhadas, consulte Implantar um recurso do Ops Manager.

Importante

Se você tiver implantações existentes, deverá reiniciá-las manualmente após habilitar o HTTPS. Para evitar reiniciar suas implementações, configure HTTPS antes de distribuir seus recursos managed.

Para saber mais, consulte HTTPS ativado após a implementação.

Acesso ao aplicativo do Ops Manager

Por padrão, o Kubernetes Operator não cria um serviço do Kubernetes para rotear o tráfego originado de fora do cluster do Kubernetes para o aplicativo Ops Manager.

Para acessar o aplicativo Ops Manager, você pode:

Configure o Operador Kubernetes para criar um serviço Kubernetes.
Crie um serviço Kubernetes manualmente. MongoDB recomenda usar um serviço LoadBalancer Kubernetes se o seu fornecedor de cloud oferecer suporte a ele.
Se você estiver usando o OpenShift, use rotas.
Use um serviço de terceiros, como o Isstio.

O método mais simples é configurar o Operador Kubernetes para criar um serviço Kubernetes que roteia o tráfego externo para o aplicativo MongoDB Ops Manager . O MongoDB Ops Manager procedimento de sistema instrui você a adicionar as seguintes configurações ao objeto especificação que configura o Kubernetes Operador para criar um serviço:

spec.externalConnectivity
spec.externalConnectivity.type

Além disso, para implantações em vários clusters do Kubernetes, consulte Rede, Balanceamento de carga, Service Mesh.

Implantação do Ops Manager no modo remoto ou local

Você pode usar o Operador Kubernetes para configurar um único cluster MongoDB Ops Manager para operar no modo Local ou Remoto se o seu ambiente impedir a concessão de hosts no cluster do Kubernetes acesso à Internet. Nesses modos, os Daemons de Backup e os recursos gerenciados do MongoDB baixam os arquivos de instalação do MongoDB Ops Manager em vez da Internet:

Configurar um recurso do Ops Manager para usar o modo remoto: o Ops Manager lê os arquivos de instalação de pontos de extremidade HTTP em um servidor web ou armazenamento de arquivos compatível com S3implantado em seu cluster Kubernetes.
Configurar um recurso do Ops Manager para usar o modo local: O Ops Manager lê os arquivos de instalação de um volume persistente que você cria para o Ops Manager StatefulSet.

Gerenciando sistemas externos do MongoDB

Quando você implanta o Ops Manager com o Kubernetes Operator, o Ops Manager pode managed os recursos do MongoDB database implantados:

Para o mesmo cluster do Kubernetes que o gerente de operações.
Fora dos clusters Kubernetes.

Se o Ops Manager managed os recursos do MongoDB database distribuídos em clusters Kubernetes diferentes do Ops Manager ou fora dos clusters Kubernetes, você deverá:

Adicione a configuração mms.centralUrl a spec.configuration na especificação de recursos do Ops Manager.
Defina o valor para a URL pela qual o Ops Manager é exposto fora do cluster do Kubernetes:
```
spec:
  configuration:
    mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/
```
Atualize os ConfigMaps referenciados por todos os recursos do banco de dados MongoDB dentro do cluster Kubernetes que você implantou com o Kubernetes Operator.
Defina data.baseUrl para o mesmo valor da configuração spec.configuration.mms.centralUrl na especificação do recurso Ops Manager.
Importante
Isso inclui os ConfigMaps referenciados pelos recursos do banco de MongoDB database para os armazenamentos de oplog e snapshots.

Implementando o MongoDB Ops Manager em Multi-Clusters

Consulte Arquitetura do Ops Manager de vários clusters.

Armazenamento secreto

Para evitar o armazenamento de segredos no Kubernetes, migre todos os segredos do Kubernetes que o Operador Kubernetes cria para uma ferramenta de armazenamento secreto. Os sistemas de vários clusters não oferecem suporte ao armazenamento de segredos em ferramentas de armazenamento de segredos, como o HashiCorp Vault.

Pré-requisitos

Caso ainda não tenha feito isso, execute o seguinte comando para executar todos os comandos kubectl no namespace que você criou:
```
kubectl config set-context $(kubectl config current-context) \
  -n <metadata.namespace>
```
Observação
Se você estiver implantando um recurso MongoDB Ops Manager em um sistema do MongoDB de vários clusters Kubernetes:
- Defina context como o nome do cluster central, como: kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME".
- Defina --namespace para o mesmo escopo usado para a implantação do MongoDB de vários clusters Kubernetes, como: kubectl config --namespace "mongodb".
Instale o MongoDB Enterprise Kubernetes Operator.
Certifique-se de que o host no qual você deseja implantar o Ops Manager tenha um mínimo de cinco gigabytes de memória.

Criar um segredo Kubernetes para um usuário administrador no mesmo namespace como o recurso Ops Manager. Se estiver implementando o Ops Manager em um sistema MongoDB de vários clusters Kubernetes, use o mesmo namespace que você define para o escopo de implementação do MongoDB de vários clusters Kubernetes.

Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, você pode Criar um Vault Secret .

Para saber mais sobre suas opções de armazenamento secreto, consulte Configurar armazenamento secreto.

Quando você implementa o recurso MongoDB Ops MongoDB Ops Manager , o MongoDB Ops Manager cria um usuário com estas credenciais e concede a ele o role Global Owner . Use essas credenciais para fazer login no MongoDB Ops Manager pela primeira vez. Depois de implantar o MongoDB Ops Manager, altere a senha ou remova esse segredo.

Observação

A senha do usuário administrador deve aderir aos MongoDB Ops Manager requisitos de complexidade de senha do .

kubectl create secret generic <adminusercredentials> \
  --from-literal=Username="<username>" \
  --from-literal=Password="<password>" \
  --from-literal=FirstName="<firstname>" \
  --from-literal=LastName="<lastname>"

(Opcional) Para definir a senha do MongoDB Ops Manager usuário do banco de dados do , crie um segredo no mesmo namespace como o MongoDB Ops Manager recurso .
Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, você pode Criar um Vault Secret .
O Kubernetes Operator cria o usuário do banco de dados que o MongoDB Ops Manager usa para se conectar ao Ops Manager Application Database. Você pode definir a senha para este usuário do banco de dados invocando o seguinte comando para criar um segredo:
```
kubectl create secret generic <om-db-user-secret-name> \
  --from-literal=password="<om-db-user-password>"
```
Observação
Se você optar por criar um segredo para o usuário do banco de dados do Ops Manager, deverá especificar o name do segredo na definição do recurso do Ops Manager. Por padrão, o Kubernetes Operator procura o valor da senha na chave password . Se você armazenou o valor da senha em uma chave diferente, também deverá especificar esse nome key na definição de recurso do Ops Manager.
Se você não criar um segredo, o operador Kubernetes gerará automaticamente uma senha e a armazenará internamente. Para saber mais, consulte Autenticação.

(Opcional). Para configurar o backup para um armazenamento de snapshots S3 , crie um segredo no mesmo namespace que o MongoDB Ops Manager recurso .

Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, você pode Criar um Vault Secret .

Esse segredo armazena suas credenciais do S3 para que o Kubernetes possa conectar o Ops Manager ao seu Amazon Web Services S3 ou bucket compatível com o S3 . O segredo deve conter os seguintes pares de valores-chave:


Chave	Valor
`accessKey`	Identidade exclusiva do usuário AWS que possui o bucket S3 ou compatível com S3 .
`secretKey`	Chave secreta do usuário Amazon Web Services que possui o bucket S3 ou compatível com S3 .

Para criar o segredo, invoque o seguinte comando:

kubectl create secret generic <my-aws-s3-credentials> \
  --from-literal=accessKey="<AKIAIOSFODNN7EXAMPLE>" \
  --from-literal=secretKey="<wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY>"

Para saber mais sobre como gerenciar o armazenamento de snapshots do S3 , consulte os Pré-requisitos.

← Desempenho

Distribuir →

1	spec:
2	configuration:
3	mms.ignoreInitialUiSetup: "true"
4	automation.versions.source: "remote"
5	mms.adminEmailAddr: cloud-manager-support@mongodb.com
6	mms.fromEmailAddr: cloud-manager-support@mongodb.com
7	mms.mail.hostname: email-smtp.us-east-1.amazonaws.com
8	mms.mail.port: "465"
9	mms.mail.ssl: "true"
10	mms.mail.transport: smtp
11	mms.minimumTLSVersion: TLSv1.2
12	mms.replyToEmailAddr: cloud-manager-support@mongodb.com