MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Uma introdução ao servidor Percona para MongoDB 4.2

Ao escolher uma tecnologia de banco de dados NoSQL, considerações importantes devem ser levadas em consideração, como desempenho, resiliência, confiabilidade e segurança. Esses fatores-chave também devem estar alinhados com o alcance das metas de negócios, pelo menos no que diz respeito ao banco de dados.

Muitas tecnologias entraram em jogo para melhorar esses aspectos, e é aconselhável que uma organização melhore as opções salientes e tente integrá-las aos sistemas de banco de dados.

As novas tecnologias devem garantir o máximo desempenho para melhorar o alcance das metas de negócios a um custo operacional acessível, mas com recursos mais manipuladores, como detecção de erros e sistemas de alerta.

Neste blog, discutiremos a versão Percona do MongoDB e como ela expande o poder do MongoDB de várias maneiras.

O que é o Servidor Percona para MongoDB?

Para que um banco de dados tenha um bom desempenho, deve haver um servidor subjacente estabelecido de maneira ideal para aprimorar as transações de leitura e gravação. O Percona Server for MongoDB é um substituto gratuito de código aberto para o MongoDB Community Edition, mas com funcionalidade adicional de nível empresarial. Ele foi projetado com algumas melhorias importantes na configuração padrão do servidor MongoDB.

Ele oferece alto desempenho, segurança aprimorada e confiabilidade para desempenho ideal com gastos reduzidos em relacionamentos com fornecedores de software proprietário.

Servidor Percona para recursos importantes do MongoDB

MongoDB Community Edition é fundamental para o servidor Percona considerando que já constitui recursos importantes como o esquema flexível, transações distribuídas, familiaridade dos documentos JSON e alta disponibilidade nativa. Além disso, o Percona Server for MongoDB integra os seguintes recursos importantes que permitem satisfazer os aspectos mencionados acima:

  • Backups ativos
  • Criptografia de dados em repouso
  • Registro de auditoria
  • Mecanismo de memória Percona
  • Autenticação LDAP externa com SASL
  • Integração do cofre da HashiCorp
  • Perfil de consulta aprimorado

Hot Backups 

O servidor Percona para MongoDB cria um backup físico de dados em um servidor em execução em segundo plano sem qualquer degradação perceptível da operação. Isso é possível executando o comando createBackup como administrador no banco de dados admin e especificando o diretório de backup. 

> use admin

switched to db admin

> db.runCommand({createBackup: 1, backupDir: "/my/backup/data/path"})

{ "ok" : 1 }

Quando você recebe { "ok" :1 }, o backup foi bem-sucedido. Caso contrário, se, por exemplo, você especificar um caminho de diretório de backup vazio, poderá receber uma resposta de erro, por exemplo:

{ "ok" : 0, "errmsg" : "Destination path must be absolute" }

A restauração do backup requer que primeiro interrompa a instância do mongod, limpe o diretório de dados, copie os arquivos do diretório e reinicie o serviço mongod. Isso pode ser feito executando o comando abaixo 

$ service mongod stop && rm -rf /var/lib/mongodb/* && cp --recursive /my/backup/data/path /var/lib/mongodb/ && service mongod start

Você também pode armazenar o backup em formato de arquivo se estiver usando o servidor Percona para MongoDB 4.2.1-1 

> use admin

> db.runCommand({createBackup: 1, archive: "path/to/archive.tar" })

Você também pode fazer backup diretamente no AWS S3 usando as configurações padrão ou com mais configurações. Para um backup de bucket padrão do S3:

> db.runCommand({createBackup:1,  s3:{bucket:"backup", path:"newBackup"}})

Criptografia de dados em repouso

O MongoDB versão 3.2 introduziu a criptografia de dados em repouso para o mecanismo de armazenamento WiredTiger para garantir que os arquivos de dados possam ser descriptografados e lidos apenas por partes com chave de descriptografia. A criptografia de dados em repouso no Percona Server para MongoDB foi introduzida na versão 3.6 para acompanhar a interface de criptografia de dados em repouso no MongoDB. No entanto, a versão mais recente não inclui suporte para serviços de gerenciamento de chaves Amazon AWS e KIMP.

A criptografia também pode ser aplicada a arquivos de rollback quando os dados em repouso estão ativados. O Percona Server for MongoDB usa a opção encryptionCipherMode com 2 modos de codificação seletivos:

  1. AES256-CBC (modo de cifra padrão)
  2. AES256-GCM

Você pode criptografar dados com o comando abaixo 

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

Usamos a opção --ecryptionKeyFile para especificar o caminho para um arquivo que contém a chave de criptografia. 

$ mongod ... --enableEncryption --encryptionKeyFile <fileName>

Registro de auditoria

Para cada sistema de banco de dados, os administradores têm um mandato para acompanhar as atividades que estão ocorrendo. No Percona Server para MongoDB, quando a auditoria está habilitada, o servidor gera um arquivo de log de auditoria que constitui informações sobre diferentes eventos do usuário, como autorização e autenticação. No entanto, ao iniciar o servidor com a auditoria habilitada, os logs não serão exibidos dinamicamente durante o tempo de execução.

O log de auditoria no MongoDB Community Edition pode ter dois formatos de dados, ou seja, JSON e BSON. No entanto, para o Percona Server for MongoDB, o log de auditoria é limitado apenas ao arquivo JSON. O servidor também registra apenas comandos importantes contrários ao MongoDB que registra tudo. Como o procedimento de filtragem no Percona não é muito claro em termos de sintaxe de filtragem, habilitar o log de auditoria sem filtragem ofereceria mais entradas das quais se pode restringir às próprias especificações.

Mecanismo de Memória Percona

Esta é uma configuração especial do mecanismo de armazenamento WiredTiger que não armazena dados do usuário em disco. Os dados residem totalmente e estão prontamente disponíveis na memória principal, exceto para dados de diagnóstico que são gravados em disco. Isso torna o processamento de dados muito mais rápido, mas considerando que você deve garantir que haja memória suficiente para manter o conjunto de dados e que o servidor não seja desligado. Pode-se selecionar um mecanismo de armazenamento para usar com o comando  --storageEngine. Os dados criados para um mecanismo de armazenamento não podem ser compatíveis com outros mecanismos de armazenamento porque cada mecanismo de armazenamento tem seu próprio modelo de dados. Por exemplo, para selecionar o mecanismo de armazenamento na memória. Você primeiro interrompe qualquer instância mongod em execução e, em seguida, emite os comandos:

$ service mongod stop

$ mongod --storageEngine inMemory --dbpath <newDataDir>

Se você já possui alguns dados com sua edição padrão do MongoDB Community e gostaria de migrar para o Percona Memory Engine, basta usar os utilitários mongodumb e mongorestore emitindo o comando:

$ mongodump --out <dumpDir>

$ service mongod stop

$ rm -rf /var/lib/mongodb/*

$ sed -i '/engine: .*inMemory/s/#//g' /etc/mongod.conf

$ service mongod start

$ mongorestore <dumpDir>

Autenticação LDAP externa com SASL

Sempre que os clientes fazem uma solicitação de leitura ou gravação para a instância do MongoDB mongod, eles precisam se autenticar no banco de dados de usuários do servidor MongoDB primeiro. A autenticação externa permite que o servidor MongoDB verifique as credenciais do cliente (nome de usuário e senha) em relação a um serviço separado. A arquitetura de autenticação externa envolve:

  1. Servidor LDAP que armazena remotamente todas as credenciais do usuário
  2. SASL Daemon que é usado como um proxy local do servidor MongoDB para o serviço LDAP remoto.
  3. Biblioteca SASL:cria os dados de autenticação necessários para o cliente e servidor MongoDB.

Sequência de sessão de autenticação

  • O cliente se conecta a uma instância mongod em execução e cria uma solicitação de autenticação PLAIN usando a biblioteca SASL.
  • A solicitação de autenticação é então enviada ao servidor como um comando especial do Mongo que é recebido pelo servidor mongod com sua carga útil de solicitação.
  • O servidor cria algumas sessões SASL derivadas de credenciais de cliente usando sua própria referência à biblioteca SASL.
  • O servidor mongod passa a carga de autenticação para a biblioteca SASL que a entrega ao daemon saslauthd. O daemon passa para o LDAP e aguarda uma resposta SIM ou NÃO na solicitação de autenticação, verificando se o usuário existe e se a senha enviada está correta.
  • O saslauthd passa essa resposta ao servidor mongod por meio da biblioteca SASL, que então autentica ou rejeita a solicitação de acordo.

 Aqui está uma ilustração para este processo:

Para adicionar um usuário externo a um servidor mongod:

> db.getSiblingDB("$external").createUser( {user : username, roles: [ {role: "read", db: "test"} ]} );

No entanto, os usuários externos não podem ter funções atribuídas no banco de dados do administrador.

Integração do cofre da HashiCorp

O HashCorp Vault é um produto projetado para gerenciar segredos e proteger dados confidenciais armazenando com segurança e controlando rigidamente o acesso a informações confidenciais. Com a versão anterior do Percona, a chave de criptografia de dados em repouso era armazenada localmente no servidor dentro do arquivo de chave. A integração com HashCorp Vault protege a chave de criptografia muito melhor.

Perfil de consulta aprimorado

A criação de perfil tem um impacto negativo no desempenho do banco de dados, especialmente quando há tantas consultas emitidas. O servidor Percona para MongoDB vem na mão limitando o número de consultas coletadas pelo criador de perfil de banco de dados, portanto, diminui seu impacto no desempenho.

Conclusão

Percona Server for MongoDB é um banco de dados de código aberto aprimorado e altamente escalável que pode atuar como um substituto compatível para o MongoDB Community Edition, mas com sintaxe e configuração semelhantes. Ele melhora a segurança extensiva dos dados, especialmente aqueles em repouso, e melhora o desempenho do banco de dados por meio do fornecimento do mecanismo Percona Server, limitando a taxa de criação de perfil, entre outros recursos.

O Percona Server for MongoDB é totalmente suportado pelo ClusterControl como uma opção para implantação.