sql >> Base de Datos >  >> NoSQL >> MongoDB

Una introducción a Percona Server para MongoDB 4.2

Al elegir una tecnología de base de datos NoSQL, se deben tener en cuenta consideraciones importantes, como el rendimiento, la resiliencia, la confiabilidad y la seguridad. Estos factores clave también deben estar alineados con el logro de los objetivos comerciales, al menos en lo que respecta a la base de datos.

Muchas tecnologías han entrado en juego para mejorar estos aspectos, y es recomendable que una organización mejore las opciones más destacadas e intente integrarlas en los sistemas de base de datos.

Las nuevas tecnologías deberían garantizar el máximo rendimiento para mejorar el logro de los objetivos comerciales a un costo operativo asequible pero con funciones más manipuladoras, como la detección de errores y los sistemas de alerta.

En este blog discutiremos la versión Percona de MongoDB y cómo expande el poder de MongoDB en una variedad de formas.

¿Qué es Percona Server para MongoDB?

Para que una base de datos funcione bien, debe haber un servidor subyacente establecido de manera óptima para mejorar las transacciones de lectura y escritura. Percona Server para MongoDB es un reemplazo directo gratuito de código abierto para MongoDB Community Edition, pero con funcionalidad adicional de nivel empresarial. Está diseñado con algunas mejoras importantes en la configuración predeterminada del servidor MongoDB.

Ofrece alto rendimiento, seguridad mejorada y confiabilidad para un rendimiento óptimo con gastos reducidos en relaciones con proveedores de software patentado.

Funciones destacadas del servidor Percona para MongoDB

MongoDB Community Edition es fundamental para el servidor Percona considerando que ya constituye características importantes como el esquema flexible, las transacciones distribuidas, la familiaridad con los documentos JSON y la alta disponibilidad nativa. Además de esto, Percona Server for MongoDB integra las siguientes características destacadas que le permiten satisfacer los aspectos que hemos mencionado anteriormente:

  • Copias de seguridad activas
  • Cifrado de datos en reposo
  • Registro de auditoría
  • Motor de memoria Percona
  • Autenticación LDAP externa con SASL
  • Integración de la bóveda de HashiCorp
  • Perfil de consulta mejorado

Copias de seguridad activas 

El servidor Percona para MongoDB crea una copia de seguridad de datos físicos en un servidor en ejecución en segundo plano sin ninguna degradación operativa notable. Esto se puede lograr ejecutando el comando createBackup como administrador en la base de datos de administración y especificando el directorio de respaldo. 

> use admin

switched to db admin

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

{ "ok" : 1 }

Cuando recibe { "ok" :1 }, la copia de seguridad fue exitosa. De lo contrario, si, por ejemplo, especifica una ruta de directorio de copia de seguridad vacía, puede recibir una respuesta de error, es decir:

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

Restaurar la copia de seguridad requiere primero detener la instancia de mongod, limpiar el directorio de datos, copiar los archivos del directorio y luego reiniciar el servicio de mongod. Esto se puede hacer ejecutando el siguiente comando

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

También puede almacenar la copia de seguridad en formato de archivo si usa el servidor Percona para MongoDB 4.2.1-1 

> use admin

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

También puede realizar una copia de seguridad directamente en AWS S3 utilizando la configuración predeterminada o con más configuraciones. Para una copia de seguridad de depósito S3 predeterminada:

> db.runCommand({createBackup:1,  s3:{depósito:"backup", ruta:"newBackup"}})

Cifrado de datos en reposo

La versión 3.2 de MongoDB introdujo el cifrado de datos en reposo para el motor de almacenamiento WiredTiger para garantizar que las partes puedan descifrar y leer los archivos de datos solo con la clave de descifrado. El cifrado de datos en reposo en Percona Server para MongoDB se introdujo en la versión 3.6 para combinar con el cifrado de datos en la interfaz de reposo en MongoDB. Sin embargo, la última versión no incluye soporte para los servicios de administración de claves Amazon AWS y KIMP.

El cifrado también se puede aplicar a los archivos de reversión cuando los datos en reposo están habilitados. Percona Server para MongoDB usa la opción de cifradoCipherMode con 2 modos de cifrado selectivos:

  1. AES256-CBC (modo de cifrado predeterminado)
  2. AES256-GCM

Puede cifrar datos con el siguiente comando

$ mongod ... --encryptionCipherMode or 

$ mongod ... --encryptionCipherMode AES256-GCM

Usamos la opción --ecryptionKeyFile para especificar la ruta a un archivo que contiene la clave de cifrado.

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

Registro de auditoría

Para cada sistema de base de datos, los administradores tienen el mandato de realizar un seguimiento de las actividades que se llevan a cabo. En Percona Server para MongoDB, cuando la auditoría está habilitada, el servidor genera un archivo de registro de auditoría que constituye información sobre diferentes eventos del usuario, como la autorización y la autenticación. Sin embargo, al iniciar el servidor con la auditoría habilitada, los registros no se mostrarán dinámicamente durante el tiempo de ejecución.

El registro de auditoría en MongoDB Community Edition puede tomar dos formatos de datos, es decir, JSON y BSON. Sin embargo, para Percona Server para MongoDB, el registro de auditoría se limita solo al archivo JSON. El servidor también registra solo comandos importantes contrarios a MongoDB que registra todo. Dado que el procedimiento de filtrado en Percona es tan poco claro en cuanto a la sintaxis de filtrado, habilitar el registro de auditoría sin filtrar ofrecería más entradas desde las que se puede reducir a especificaciones propias.

Motor de memoria Percona

Esta es una configuración especial del motor de almacenamiento WiredTiger que no almacena datos de usuario en el disco. Los datos residen por completo y están fácilmente disponibles en la memoria principal, excepto los datos de diagnóstico que se escriben en el disco. Esto hace que el procesamiento de datos sea mucho más rápido, pero teniendo en cuenta que debe asegurarse de que haya suficiente memoria para almacenar el conjunto de datos y que el servidor no se apague. Se puede seleccionar un motor de almacenamiento para usar con el comando --storageEngine. Los datos creados para un motor de almacenamiento no pueden ser compatibles con otros motores de almacenamiento porque cada motor de almacenamiento tiene su propio modelo de datos. Por ejemplo, para seleccionar el motor de almacenamiento en memoria. Primero detiene cualquier instancia de mongod en ejecución y luego emite los comandos:

$ service mongod stop

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

Si ya tiene algunos datos con su edición MongoDB Community predeterminada y desea migrar a Percona Memory Engine, simplemente use las utilidades mongodumb y mongorestore emitiendo el 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>

Autenticación LDAP externa con SASL

Siempre que los clientes realicen una solicitud de lectura o escritura a la instancia mongod de MongoDB, primero deben autenticarse en la base de datos de usuarios del servidor MongoDB. La autenticación externa permite que el servidor MongoDB verifique las credenciales del cliente (nombre de usuario y contraseña) con un servicio separado. La arquitectura de autenticación externa implica:

  1. Servidor LDAP que almacena de forma remota todas las credenciales de usuario
  2. SaSL Daemon que se utiliza como proxy local del servidor MongoDB para el servicio LDAP remoto.
  3. Biblioteca SASL:crea los datos de autenticación necesarios para el cliente y el servidor MongoDB.

Secuencia de sesión de autenticación

  • El cliente se conecta a una instancia de mongod en ejecución y crea una solicitud de autenticación PLAIN utilizando la biblioteca SASL.
  • La solicitud de autenticación luego se envía al servidor como un comando Mongo especial que luego es recibido por el servidor mongod con su carga de solicitud.
  • El servidor crea algunas sesiones SASL derivadas de las credenciales del cliente utilizando su propia referencia a la biblioteca SASL.
  • El servidor mongod pasa la carga útil de autenticación a la biblioteca SASL, que la entrega al demonio saslauthd. El daemon lo pasa al LDAP y espera una respuesta SÍ o NO a la solicitud de autenticación comprobando si el usuario existe y si la contraseña enviada es correcta.
  • El saslauthd pasa esta respuesta al servidor mongod a través de la biblioteca SASL que luego autentica o rechaza la solicitud en consecuencia.

 Aquí hay una ilustración de este proceso:

Para agregar un usuario externo a un servidor mongod:

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

Sin embargo, los usuarios externos no pueden tener funciones asignadas en la base de datos de administración.

Integración de la bóveda de HashiCorp

HashCorp Vault es un producto diseñado para administrar secretos y proteger datos confidenciales almacenando de forma segura y controlando estrictamente el acceso a información confidencial. Con la versión anterior de Percona, la clave de cifrado de datos en reposo se almacenaba localmente en el servidor dentro del archivo de claves. La integración con HashCorp Vault asegura la clave de cifrado mucho mejor.

Perfil de consulta mejorado

La creación de perfiles tiene un impacto de degradación en el rendimiento de la base de datos, especialmente cuando se emiten tantas consultas. El servidor Percona para MongoDB es útil al limitar la cantidad de consultas recopiladas por el generador de perfiles de la base de datos, por lo que disminuye su impacto en el rendimiento.

Conclusión

Percona Server para MongoDB es una base de datos altamente escalable y de código abierto mejorada que puede actuar como un reemplazo directo compatible para MongoDB Community Edition pero con una sintaxis y una configuración similares. Mejora la seguridad de los datos, especialmente uno en reposo, y mejora el rendimiento de la base de datos a través de la provisión del motor Percona Server, limitando la tasa de creación de perfiles, entre otras características.

Percona Server para MongoDB es totalmente compatible con ClusterControl como opción de implementación.