Administración de MongoDB Raúl Bojo Romero II Jornadas Técnicas UEx – CIEMAT: Introducción a NoSQL con MongoDB 9 – 11 de Febrero, 2016 Jesús Santisteban Fernández

¿QUIENES SOMOS? { “speakers” : [ { “name” : “Jesús Santisteban Fernández”, “organization” : “CETA-Ciemat”, “unit” : “USE”, “tags” : [“dba”, “services”, “sysop”, “netadmin”], “email” : “jesus.santisteban@externos.ciemat.es” }, { “name” : “Raúl Bojo Romero”, “organization” : “CETA-Ciemat”, “unit” : “USE”, “tags” : [“dba”, “services”, “developer”], “email” : “raul.bojo@externos.ciemat.es” }, ] }

ÍNDICE Introducción. Configuración Avanzada. Replicación (Replica Set). Fragmentación (Sharding). Seguridad. Métodos de Backup.

INTRODUCCIÓN ¿Qué es MongoDB? Base de datos (Open-Source) NoSQL. Orientada a documentos. Diseñada para facilitar el desarrollo y el escalado.

CONFIGURACIÓN AVANZADA ¿Cómo podemos instalar MongoDB? MongoDB esta disponibles para Linux, OS X y Windows. Si nos centramos en la distribución Ubuntu-Server 14.04 LTS: Importar la clave pública usada por el sistema de paquetería (dpkg/apt): apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927 Incluir el repositorio de MongoDB dentro de /etc/apt/sources.list.d: echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse" | tee /etc/apt/sources.list.d/mongodb-org-3.2.list Actualizar la base de datos de paquetes: apt-get update Instalar la última versión estable de MongoDB: apt-get install -y mongodb-org

CONFIGURACIÓN AVANZADA ¿Qué debemos hacer para configurar MongoDB? MongoDB permite realizar la configuración el servicio mongod de dos formas distintas: Linea de Comandos: Indicando las opciones de configuración al iniciar el servicio: mongod --dbpath /data/db --port 27017 --logpath file.log --logappend --fork Opciones Descripción --config Indica el path del fichero de configuración a utilizar. --dbpath Indica el path donde se almacenan los ficheros de la base de datos. --port Indica el puerto por el cual va a escuchar la instancia. --logpath Indica el path donde se almacena el fichero de log de la instancia. --logappend Si es true, no sobrescribe el fichero de log si existe, añade entradas. --fork Habilita el modo daemon (el proceso se ejecuta en backgroud). --journal Habilita el journal (habilitado por defecto). --bind_ip Fuerza al servidor la IP por la cual recibirá las peticiones.

CONFIGURACIÓN AVANZADA Fichero de configuración: Editando las opciones de configuración del fichero: /etc/mongod.conf Debemos tener en cuenta que usa formato YAML (no soporta tabulación). Dicho fichero de configuración es utilizado por el script de inicio del servicio /etc/init.d/mongod.

CONFIGURACIÓN AVANZADA ¿Con qué comandos contamos para la Administración MongoDB? Comando Función db.help() Muestra los comandos disponibles y su descripción db.copyDatabase(fromdb, todb, fromhost) Copia una base de datos incluso desde un host remoto. db.currentOp() Muestra las operaciones ejecutándose actualmente en la DB. db.dropDatabase() Elimina una base de datos. db.hostInfo() Muestra la información del servidor donde se aloja MongoDB. db.killOp(opid) Mata el proceso de la operación indicada. db.repairDatabase() Repara la base de datos en la que estamos ubicados. db.serverStatus() Devuelve un documento con el estado del servicio. db.shutdownServer(timeoutSecs) Detiene el proceso que tiene levantado el servicio. db.stats() Devuelve las estadísticas de la base de datos actual. db.version() Muestra la versión de MongoDB ejecutándose.

REPLICACIÓN (REPLICA SET) ¿Qué es la replicación? Sincronización de datos a través de múltiples servidores. ¿Qué aporta la replicación a nuestras BBDD? Redundancia / durabilidad. Alta disponibilidad Tipos de replicación: Replicación binaria Basada en “estado”  MongoDB!!

REPLICACIÓN (REPLICA SET) Ventajas en MongoDB Asynchronous replication (statement based) Automatic failover Independencia de versiones Diferentes Storage Engines en miembros No hay downtime en actualizaciones ¿Cómo se gestiona en MongoDB? Miembros del Replica Set: Primary, Secondaries, Arbiter Máximo 50 miembros (v3.0+) Procesos mongod & parámetros de configuración Replica Set Oplog (async replication) Elections: Primary down (+10s) (automatic failover) New!! (v3.2) : “protocolVersion: 1” para acelerar la detección de múltiples primarios Máximo 7 miembros con derecho a voto

REPLICACIÓN (REPLICA SET) Replicación en MongoDB Conexión de clientes Primary + 2 Secondaries RF: 3, Majority: 2 Primary + 1 Secondary + 1 Arbiter RF: 2, Majority: 2 writeConcern ReadConcern (v3.2) readPreference

REPLICACIÓN (REPLICA SET) Automatic failover Primary election Conexión de clientes writeConcern readConcern readPreference Replicación en MongoDB

Miembros de un Replica Set PRIMARY Es único en el Replica Set Solo él recibe las escrituras y por defecto las lecturas Solo él garantiza la consistencia Mantiene el oplog a replicar En elecciones no existe primario, no se puede escribir Si no “ve” una mayoría de miembros se convierte en secundario En su proceso mongod se define el nombre del replica-set Puede invitar a nuevos miembros Establece la seguridad REPLICACIÓN (REPLICA SET)

REPLICACIÓN (REPLICA SET) Miembros de un Replica Set SECONDARIES Mantienen una copia exacta de los datos del PRIMARY replicando su oplog asíncronamente. Pueden aceptar lecturas contemplando tolerancia a obsolescencia de datos Opciones del Driver cliente readConcern: “local” (primary), “majority” (eventual consistency) Query Read Preference: primary, primaryPreferred, secondary, secondaryPreferred, nearest (menor latencia) Tipos de miembros secundarios Sin derecho a voto  { votes: 0 } Prioridad 0  { priority: 0 } Oculto  { hidden: true, priority: 0 } Retardado  { slaveDelay: nsecs }

REPLICACIÓN (REPLICA SET) Miembros de un Replica Set ARBITER No mantiene copia de datos Requiere pocos recursos. Preferiblemente en máquina independiente (cloud - AWS) Tienen 1 voto en las elecciones Permiten mantener número impar de miembros No pueden convertirse en primarios en una elección Secundario especial  { arbiterOnly: true } No debe ejecutarse en máquinas que ya incluyen primario o secundarios Tan solo intercambian votos, heartbeats y datos de configuración Antes de ser añadido necesita un --dbpath para iniciar mongod Minimizar con --nojournal y --smallfiles

REPLICACIÓN (REPLICA SET) Estrategias de Definición de un Replica Set Determinar un número impar de miembros Considerar “fault tolerance”: FT = members - majority Utilizar “hidden” o “delayed” members para funciones dedicadas  Backup, reporting, analytics. Balancear la carga en entornos con excesivas lecturas Anticipar el aumento de capacidad a la demanda Utilizar journaling para protección ante fallos  Sin journaling activo MongoDB no podrá recuperar datos ante desastres inexperados El mínimo recomendado son 3 miembros Distribuye geográficamente los miembros de una réplica

REPLICACIÓN (REPLICA SET) Elections And Failover Si el primario falla, las réplicas secundarias determinan conjuntamente quién debe ser elegido como nuevo primario usando una implementación extendida del “Raft consensus algorithm” http://raft.github.io/ - http://thesecretlivesofdata.com/raft/ follower leader candidate election timeout heartbeat timeout

REPLICACIÓN (REPLICA SET) Un evento de elección se produce cuando Fallo en el Primary → (v3.2) protocolVersion: 1, electionTimeoutMillis stepDown(sec) reconfig(conf) pérdida de quorum Elección de nuevo primario en MongoDB 1)El más actualizado 2)El de mayor prioridad 3)Menos de 10s detrás del primario, si excede queda inaccesible Rollback de primario Un rollback revierte las escrituras en un primario cuando retorna al replica-set después de un fallo. El rollback solo es necesario si el primario ha aceptado operaciones de escritura y no se han replicado correctamente en los secundarios antes de que quedara inaccesible

REPLICACIÓN (REPLICA SET) Colecciones en miembros de Replica Set local.system.replset Almacena el documento de configuración del replica-set rs.initiate(), rs.conf(), rs.reconfig(), rs.status() local.oplog.rs Es la colección cíclica que almacena el oplog El tamaño por defecto es del 5% del espacio libre en disco Se puede cambiar mediante oplogSizeMB Si un miembro “cae” durante demasiado tiempo debe ser inicializado (re-sync) Cada operación en el oplog es idempotente Operaciones de actualización múltiple se desglosan en secundarios Oplog status helper rs.printReplicationInfo() Consultar lag desde el primario con rs.printSlaveReplicationInfo()

REPLICACIÓN (REPLICA SET) Replica Set – Lecturas y escrituras Write Concern Por defecto las operaciones de escritura solo se confirman desde el primario. Se puede cambiar en operaciones desde clientes db.products.insert( { item: "envelopes", qty : 100, type: "Clasp" }, { writeConcern: { w: 2, wtimeout: 5000 } } ) O en la configuración del replica set cfg = rs.conf() cfg.settings = {} cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 } rs.reconfig(cfg)

REPLICACIÓN (REPLICA SET) Replica Set – Lecturas y escrituras Read Preference Por defecto en un replica set las operaciones de lectura se realizan sobre el primario. Con readConcern “local” las lecturas del primario reflejan las últimas actualizaciones si no ha habido recuperación. Con readConcern “majority” las lecturas son del primario o secundarios con lo que se tiene consistencia eventual (solo v3.2 con WiredTiger). El driver de MongoDB soporta 5 modo en preferencia de lecturas: Primary PrimaryPreferred Secondary SecondaryPreferred Nearest La síntaxis depende del driver que se utilize (PHP, python, etc.) En el shell de mongo disponemos del método readPref en el cursor

REPLICACIÓN (REPLICA SET) Método Descripción rs.initiate() Inicializa un replica set rs.add(“host:port”) Añade un nuevo miembro al replica set con las siguientes opciones: { priority: n, votes: 1,  se recomienda no modificar!! slaveDelay: n, artbiterOnly: true, hidden: true, tags: […] } rs.addArb(“host:port”) Añade un miembro “árbitro” al Replica Set rs.remove(“host:port”) Elimina un miembro del Replica Set rs.status() Muestra un documento con información de estado del Replica Set rs.conf() Muestra el documento con la configuración del Replica Set rs.reconfig(newConfig) Re-configura un Replica Set aplicando el nuevo objeto de configuración rs.isMaster() Indica qué miembro es el “primary” rs.stepDown(n) Convierte el primario en secundario forzando una elección rs.freeze(n) Previene que el miembro actual pueda ser elegido como primario rs.printReplicationInfo() Imprime informe de estado desde el punto de vista del primario rs.printSlaveReplicationInfo() Imprime informe de estado desde la perspectiva de un secundario rs.slaveOk() Habilita lecturas de secundarios. Deprecado. Ahora readPref() rs.syncFrom(“host:port”) Fuerza a obtener el oplog de otro miembro del Replica Set

REPLICACIÓN (REPLICA SET) Desplegando un Replica Set… 1. Consideraciones Previas Nuestro Replica Set estará formado por: 3 miembros: majority = 2, fault tolerance = 1 1 Primary, 1 Secondaries, 1 Arbiter Configuación de resolución de nombres local (evitar localhost) # echo “10.10.1.7 rsm1.local rsm2.local rsma.local” >> /etc/hosts Creamos los directorios para cada proceso mongo # mkdir –p /data/{rsm1,rsm2,rsma}

REPLICACIÓN (REPLICA SET) Desplegando un Replica Set… 2. Iniciamos los miembros del Replica Set # primary/secondaries $ mongod --port 27001 --replSet rsJUC --dbpath /data/rsm1 --logpath /data/rsm1.log -- logappend --oplogSize 50 --smallfiles --fork $ mongod --port 27002 --replSet rsJUC --dbpath /data/rsm2 --logpath /data/rsm2.log -- logappend --oplogSize 50 --smallfiles --fork # arbiter, sin journaling $ mongod --port 27005 --replSet rsJUC --dbpath /data/rsma --logpath /data/rsma.log -- logappend --oplogSize 50 --nojournal --smallfiles --fork 3. Accedemos al Shell de mongo e iniciamos el Replica Set con 1 miembro $ mongo rs01.local:27001 > var rsconf = { _id:"rsJUC", members: [ { _id:0, host: “rsm1.local:27001" } ] } > rs.initiate(rsconf) > rs.conf()

REPLICACIÓN (REPLICA SET) Desplegando un Replica Set… 2. Añadimos otros miembros # añadimos el secundary > rs.add(“rsm2.local:27002”) # añadimos el arbiter > rs.addArb(“rsma.local:27003”) 3. Comprobamos la configuración y estado del Replica Set > rs.conf() { "_id" : "rsJUC", "version" : 3, "protocolVersion" : NumberLong(1), "members" : [ … ] } ....................... > rs.status() { "set" : "rsJUC", "date" : ISODate("2016-02-04T09:44:08.438Z"), "myState" : 1, "term" : NumberLong(1), … }

REPLICACIÓN (REPLICA SET) PRÁCTICA Desplegar un Replica Set que cumpla los siguientes requisitos: Debe estar formado por: 5 miembros (majority=3, fault tolerance=2) 1 miembro árbitro Objetivos: Configurar e iniciar el Replica Set Forzar “down” y re-elección de Primario Cambiar la prioridad de un secundario Ocultar un secundario y reconfigurar Configurar secundario con sincronización retardada (20s)

FRAGMENTACIÓN ( SHARDING) ¿Qué es el Sharding? Sharding es un método para almacenar datos a través de múltiples máquinas. ¿Por qué necesitamos Sharding? Almacenar grandes conjuntos de datos . Resolver operaciones que necesitan alto rendimiento. Escalado Vertical: + CPU + RAM Limitaciones Hardware + Storage Escalado Horizontal (Sharding): Divide el conjunto de datos y los distribuye a través de varios servidores, en lo se que denominan shards .

¿ Que conseguimos con el Sharding? Reducir el número de operaciones que cada shard maneja. Cada shard procesa menos operaciones a medida que el cluster crece. Reducir la cantidad de datos que el servidor tiene que almacenar. Cada shard almacena menos datos a medida que el cluster crece Aumento de la capacidad y del rendimiento HORIZONTALMENTE FRAGMENTACIÓN ( SHARDING)

¿Cómo fragmenta MongoDB los datos? MongoDB distribuye los datos a nivel de colección. Las particiones de los datos de las colecciones viene determinada por la Shard Key. Shard Keys Campo muy importante, es vital seleccionar una Shard Key óptima. Debe ser el campo más común es las “queries” para una colección. Debe ser un Single Field Index o un Compound Index. Son inalterables y no se pueden cambiar después de realizar una inserción. Debe tener buena “cardinalidad” / “granularidad” (tener los suficientes valores para repartir la colección a través de los shards). FRAGMENTACIÓN ( SHARDING)

¿Cómo fragmenta MongoDB los datos? Indexes MongoDB soporta la indexación de cualquier campo del documento. Por defecto, todas las colecciones están indexadas por el campo “_id” Usuarios o Aplicaciones tienen la posibilidad de añadir nuevos índices. Los índices utilizados para el Sharding pueden ser: Single Field Indexes: FRAGMENTACIÓN ( SHARDING)

¿Cómo fragmenta MongoDB los datos? Compound Indexes: Formados por múltiples campos ( Límite 31 campos). Chunks No son datos físicos. Es una agrupación lógica de los rangos en los que dividimos los documentos de una colección, determinada por la Shard Key. FRAGMENTACIÓN ( SHARDING)

¿Cómo fragmenta MongoDB los datos? MongoDB divide en trozos (chunks) el conjunto de documentos de una colección en función de la Shard key , y distribuye cada trozo (chunk) en cada shard. Para realizar dicha división MongoDB tiene dos posibles métodos: Hash Based Sharding Range Based Sharding FRAGMENTACIÓN ( SHARDING)

Divide el conjunto de documentos de una colección en rangos, determinado por los valores de la Shard Key. Cada rango (chunk), contiene un rango no superpuesto de valores de la Shard Key. Cuando un chunk crece por el encima del chunksize, MongoDB intenta dividir (split) el chunk, en chunks mas pequeños. FRAGMENTACIÓN ( SHARDING) Range Based Sharding

Realiza un HASH del valor de la Shard Key, utilizando estos hashes para crear los chunks. Asegura una distribución aleatoria de una colección en el cluster. Dos documentos con el mismo valor de Shard Key, rara vez forman parte del mismo chunk. FRAGMENTACIÓN ( SHARDING) Hash Based Sharding

¿Cuál es más eficiente? Range Based Sharding Más eficiente para rango de consultas, dado que los datos suelen estar en el mismo chunk, y por lo tanto en el mismo shard. Las escrituras continuadas un mismo shard pueden provocar la sobrecarga del sistema. Distribución desigual de datos ( con Share Keys que aumentan su valor linealmente). Hash Based Sharding Distribución uniforme de los datos, dando lugar a escrituras más eficientes. Poco eficiente para rango de consultas, dado que los datos suelen estar repartidos por diferentes chunks, y por lo tanto en distintos shards. FRAGMENTACIÓN ( SHARDING)

¿Permite MongoDB balancear la distribución de los datos? Añadir nuevos datos o nuevos servidores (shards), puede dar lugar a una distribución no balanceada de los datos. MongoDB asegura en balanceo de los datos en el clúster con 2 procesos (background): Splitting Se realiza cuando un chunk sobrepasa el chunksize especificado (defecto 64MB), dividiendo el chunk a la mitad. Divide los metadatos, sin afectar a los datos ni a los shards. Habilitado por defecto (--noAutoSplit ) FRAGMENTACIÓN ( SHARDING)

Balancing Version +2.2 Dif total chunks < 20 2 20 ≤ total chunks < 80 4 total chunks ≥ 80 8 FRAGMENTACIÓN ( SHARDING) Se realiza en los servidores mongos. Esta habilitada por defecto, aunque se puede deshabilitar, tanto globalmente, como a nivel de colección. Se realiza cuando la diferencia entre el número de chunks de dos shards sobrepasa un límite:

¿ Como realiza MongoDB la implementación del Sharding ?. Sharded Cluster esta formado por: Shards: Almacenan los datos. Puede ser un Single Mongod o Replica Set(Producción). Query Routers: Encargada de dirigir las peticiones de los clientes a los shards, devolviendo el resultado a los clientes posteriormente. Config Servers: Almacenan los metadatos del cluster, así como la localización de los datos en cada shard. Version 3.2  Replica Set (Wired Tigger) FRAGMENTACIÓN ( SHARDING)

Primary Shard Cada base de datos tiene un “Primary Shard” que contiene todas las colecciones que no has sido fragmentadas. Es Posible cambiar el “Primary Shard” de una base de datos (movePrimary). El proceso de migración puede necesitar un tiempo elevando y no es recomendable acceder a las colecciones hasta que el proceso haya finalizado. FRAGMENTACIÓN ( SHARDING) ¿ Como realiza MongoDB la implementación del Sharding ?.

FRAGMENTACIÓN ( SHARDING) ¿ Con qué comandos contamos para la administración del Sharded Cluster? Comando Función sh.addShard() Añade un host (Primary of ReplSet) al Sharded Cluster sh.enableSharding() Habilita el Sharding para una base de datos sh.shardCollection() Añade un colección al Sharded Cluster sh.status() Devuelve un resumen del estado del Sharded Cluster sh.moveChunk() Migra un chunk a otro Shard sh.splitFind() Divide un chunk a la mitad basándose en una Query sh.splitAlt() Divide un chunk en 2 basándose en una ShardKey sh.stopBalancer() Detiene el balanceador globalmente (mongos) sh.startBalancer() Inicia el balanceador globalmente (mongos) sh.BalancerState() Devuelve si el balanceador está habilitado sh.isBalancerRunning() Devuelve “true” si el balanceador está migrando chunks sh.disableBalancing() Deshabilita el balanceo en un colección sh.enableBalancing() Habilita el balanceo en un colección

FRAGMENTACIÓN ( SHARDING) Desplegando un Sharded Cluster… 1. Consideraciones Previas Nuestro Sharded Cluster va a estar formado por: 3 Shards (ReplSet) 1 Config Servers (ReplSet) 2 Mongos Vamos a configurar la resolución de nombres local (evitar localhost): echo “10.10.1.6 juc01 juc01.local" >> /etc/hosts Creamos directorios donde se almacenaran los datos de cada servicio: mkdir -p /data/shard0/rs0 /data/shard0/rs1 /data/shard0/rs2 mkdir -p /data/shard1/rs0 /data/shard1/rs1 /data/shard1/rs2 mkdir -p /data/shard2/rs0 /data/shard2/rs1 /data/shard2/rs2 mkdir -p /data/cfg/rs0 /data/cfg/rs1 /data/cfg/rs2

FRAGMENTACIÓN ( SHARDING) Desplegando un Sharded Cluster… 2. Iniciamos todos los Config Servers y Configuramos el Replica Set: #Config Server (ReplSet) mongod --configsvr --replSet cfg --dbpath /data/cfg/rs0 --port 26050 --fork --logpath cfg0.log --logappend --oplogSize 50 mongod --configsvr --replSet cfg --dbpath /data/cfg/rs1 --port 26051 --fork --logpath cfg1.log --logappend --oplogSize 50 mongod --configsvr --replSet cfg --dbpath /data/cfg/rs2 --port 26052 --fork --logpath cfg2.log --logappend --oplogSize 50 # Configuramos el Replica Set mongo --port 26050 cfg = { _id: "cfg", configsvr: true, members: [ { _id: 0, host: "juc01:26050" }, { _id: 1, host: "juc01:26051" }, { _id: 2, host: "juc01:26052" } ] } rs.initiate(cfg)

FRAGMENTACIÓN ( SHARDING) Desplegando un Sharded Cluster… 3. Iniciamos 3 Replica Set de cada Shard: #Shard 0 mongod --shardsvr --replSet shard0 --dbpath /data/shard0/rs0 --port 27000 --fork --logpath s0- r0.log --logappend --smallfiles --oplogSize 50 mongod --shardsvr --replSet shard0 --dbpath /data/shard0/rs1 --port 27001 --fork --logpath s0- r1.log --logappend --smallfiles --oplogSize 50 mongod --shardsvr --replSet shard0 --dbpath /data/shard0/rs2 --port 27002 --fork --logpath s0- r2.log --logappend --smallfiles --oplogSize 50 #Shard 1 mongod --shardsvr --replSet shard1 --dbpath /data/shard1/rs0 --port 27100 --fork --logpath s1- r0.log --logappend --smallfiles --oplogSize 50 mongod --shardsvr --replSet shard1 --dbpath /data/shard1/rs1 --port 27101 --fork --logpath s1- r1.log --logappend --smallfiles --oplogSize 50 mongod --shardsvr --replSet shard1 --dbpath /data/shard1/rs2 --port 27102 --fork --logpath s1- r2.log --logappend --smallfiles --oplogSize 50

FRAGMENTACIÓN ( SHARDING) Desplegando un Sharded Cluster… #Shard 2 mongod --shardsvr --replSet shard2 --dbpath /data/shard2/rs0 --port 27200 --fork --logpath s2- r0.log --logappend --smallfiles --oplogSize 50 mongod --shardsvr --replSet shard2 --dbpath /data/shard2/rs1 --port 27201 --fork --logpath s2- r1.log --logappend --smallfiles --oplogSize 50 mongod --shardsvr --replSet shard2 --dbpath /data/shard2/rs2 --port 27202 --fork --logpath s2- r2.log --logappend --smallfiles --oplogSize 50 4. Configuramos el Replica Set para cada Shard #Shard 0 mongo --port 27000 cfg = { _id: "shard0", members: [ { _id: 0, host: "juc01:27000" }, { _id: 1, host: "juc01:27001" }, { _id: 2, host: "juc01:27002" } ] } rs.initiate(cfg)

FRAGMENTACIÓN ( SHARDING) Desplegando un Sharded Cluster… #Shard 1 mongo --port 27100 cfg = { _id: "shard1", members: [ { _id: 0, host: "juc01:27100" }, { _id: 1, host: "juc01:27101" }, { _id: 2, host: "juc01:27102" } ] } rs.initiate(cfg) #Shard 2 mongo --port 27200 cfg = { _id: "shard2", members: [ { _id: 0, host: "juc01:27200" }, { _id: 1, host: "juc01:27201" }, { _id: 2, host: "juc01:27202" } ] } rs.initiate(cfg)

FRAGMENTACIÓN ( SHARDING) Desplegando un Sharded Cluster… 5. Iniciamos los procesos Mongos: mongos --configdb cfg/juc01:26050,juc01:26051,juc01:26052 --fork --logpath mongos0.log -- logappend mongos --configdb cfg/juc01:26050,juc01:26051,juc01:26052 --fork --logpath mongos1.log -- logappend --port 27018 6. Añadimos los Shard al Cluster mongo sh.status() sh.addShard("shard0/juc01:27000") sh.addShard("shard1/juc01:27100") sh.addShard("shard2/juc01:27200") sh.status() use config show collections db.shards.find()

FRAGMENTACIÓN ( SHARDING) Desplegando un Sharded Cluster… 7. Creamos un Base de Datos y Habilitamos el Sharding use juc db.example.insert({x: 0, description: "Documento Testing"}) db.example.find() sh.status() sh.enableSharding("juc") 8. Añadimos la colección al Sharded Cluster sh.shardCollection("juc.example", {x:1}) db.example.createIndex({x:1}) sh.status() for (var i=0; i < 20000; i++) { db.example.insert({x: i, description: "Documento Testing"}) } sh.status() db.example.stats()

FRAGMENTACIÓN ( SHARDING) PRACTICA Desplegar un Cluster Shard que cumpla los siguientes requisitos: Debe estar formado por: 2 Shards (shard0 – shard1) 1 Config Servers (configrepl) 1 Mongos Incluir una base de datos llamada “practica”, que contendrá una colección llamada “inventario” con el siguiente documento inicial: { item: 0, details: { model: "Nexus 5“, manufacturer: “LG" } } Fragmentar la colección inventario, utilizando como Shared Key el campo “item”. Añadir otros 500.000 documentos a la colección (el campo item debe ser único).

SEGURIDAD SEGURIDAD EN MongoDB Opciones 1) Entorno asegurado o “trusted environment” Bloqueo a nivel de red. Acceso restringido por clientes. Independiente a MongoDB 2) Autenticación MongoDB Ejecutar mongod y mongos con opciones --auth  Control de acceso de clientes --keyFile  Seguridad intra-cluster --bind_ip  Fuerza en el servidor la IP por la cual recibirá las peticiones.

SEGURIDAD SEGURIDAD EN MongoDB Autenticación - ¿Quién eres tu en MongoDB? Usuario de aplicación, administrador, backups, monitoring. Autorización - ¿Qué puedes hacer en MongoDB? Operaciones CRUD, configurar la BD, configurar sharding, gestión de usuarios. Habilitar autenticación de Usuarios Iniciar mongod con –auth Especificar directiva “security.authorization = enabled” en el fichero de config. Credenciales de usuario/password, SCRAM-SHA-1 por defecto en v3.0+ Certificados “x.509“ LDAP, Kerberos (Enterprise!!) Habilitar autenticación Interna (Replica Set, Sharding) Mediante “keyFile” o certificados “x.509”

SEGURIDAD SEGURIDAD EN MongoDB Roles pre-definidos read, readWrite, dbAdmin, clusterAdmin, root, etc Roles customizados Definir roles de usuario en base a privilegios o roles pre-definidos Almacenamiento de usuarios En sharding se mantienen en el config server, no en los mongos Se almacenan en la colección system.users en BD admin Recomendaciones No exponer los servidores de BD a internet Buen diseño y configuración de AC Habilitar SSL. Utilizar ficheros SSL CA entre cliente y servidor Auditar la actividad del sistema (Enterprise!!) Encriptar los datos

SEGURIDAD SEGURIDAD EN MongoDB Roles de Usuario read readWrite Roles de Administrador dbAdmin dbOwner userAdmin (!permite asignar roles) Roles de Administrador clusterAdmin clusterManager clusterMonitor hostManager Backup Roles backup Restore Roles para todas BDs readAnyDatabase readWriteAnyDatabase userAdminAnyDatabase dbAdminAnyDatabase Roles superusuario root Rol interno __system

SEGURIDAD ¿ Con qué comandos contamos para la administración de Usuarios? Comando Función db.auth() Autentica un usuario en una base de datos db.createUser() Crea un nuevo usuario db.updateUser() Actualiza los datos de un usuario db.changeUserPassword() Cambia la clave de un usuario existente db.removeUser() Deprecado. Elimina un usuario de la base de datos db.dropAllUsers() Elimina todos los usuarios de una base de datos db.dropUser() Elimina solo un usuario especificado db.grantRolesToUser() Asigna un rol y sus privilegios a un usuario db.revokeRolesFromUser() Elimina un rol a un usuario db.getUser() Devuelve información sobre el usuario db.getUsers() Devuelve la información de todos los usuario de una bd

SEGURIDAD Comandos para la administración de Roles Comando Función db.createRole() Crea un rol y especifica sus privilegios db.updateRole() Actualiza un rol personalizado db.dropRole() Elimina un rol personalizado db.dropAllRoles() Elimina todos los roles personalizados asociados a una bd db.grantPrivilegesToRole() Asigna privilegios a un rol personalizado db.revokePrivilegesFromRole() Elimina un privilegio de un rol personalizado db.grantRolesToRole() Asigna roles del que hereda un rol personalizado db.revokeRolesFromRole() Elimina roles heredados en un rol db.revokeRolesFromUser() Inicia el balanceador globalmente (mongos) db.getRole() Devuelve información sobre el rol db.getRoles() Devuelve información de todos los roles de una bd

SEGURIDAD Activando seguridad en MongoDB… 1. Ejecutar mongod con opción –auth # --auth para habilitar seguridad $ mongod –auth --dbpath /data/rsm1 2. Acceder a mongo shell, permite sin credenciales para inicializar auth $ mongo rsm1.local:27001 3. Crear el usuario administrador y asociar roles > use admin > var admusr = { user : “admin”, pwd : “changeme”, roles : [ role: “userAdminAnyDatabase”, db: “admin” ] } > db.createUser( admusr ) > db.auth(“admin”,”changeme”) 4. Acceder con autenticación # con la password en blanco nos la solicitará $ mongo rsm1.local:27001 –u “admin” –p

SEGURIDAD PRÁCTICA Habilitar seguridad mediante Control de Acceso en MongoDB: Consideraciones: Configurar una instancia mongod con autenticación activada Configurar un Replica Set básico de 3 miembros con autenticación Objetivos: Crear nuevo usuario para acceso autenticado Comprobar control de autorización mediante asignación de Roles Crear Rol personalizado para acceso autorizado a colección Configurar un keyfile para autenticación a base de datos

MÉTODOS DE BACKUP Cuando desplegamos MongoDB en producción, debemos tener una estrategia para realizar backups y restaurar los datos en caso de desastre, o perdida de datos. MongoDB propone las siguientes alternativas para dicho propósito: Estrategias de Backup basadas en Sistemas de Ficheros. Utilizando las utilidades de Mongodb. Uso de herramientas Enterprise: MongoDB Cloud Manager Backup Ops Manager Backup Software

MÉTODOS DE BACKUP Estrategias de Backup basadas en Sistemas de Ficheros: Realizando snapshots si el sistema de fichero lo permite (LVM, EBS) Tener habilitado el journal y que resida en el mismo volumen lógico que los datos. En un Sharded Cluster, debemos deshabilitar el balanceador y realizar un snapshot de cada shard y config aprox. mismo tiempo. Si el sistema de ficheros no soporta snapshots, puedes copiar los datos directamente utilizando utilidades como cp, scp, rsync. No son compatibles “point in time recovery” para el Replica Set. Difícil gestión con Sharded Cluster grandes.

MÉTODOS DE BACKUP Utilizando las utilidades de Mongodb: mongodump Herramienta que lee los datos de una base de datos MongoDB y los vuelca en un fichero BSON (Alta fiabilidad). Excluye el contenido de la base de datos local. Solo captura los documentos de la base de datos, no incluye los índices. En sistemas con Replica Set se recomienda ejecutarlo con la opción --oplog, para registrar en el oplog, las operaciones que realiza mongodump. mongodump --db test --collection collection mongodump --host mongodb1.example.net --port 37017 --username user --password pass --out /opt/backup/mongodump-2016-02-04

MÉTODOS DE BACKUP mongorestore Herramienta que puebla la base de datos con los datos del fichero BSON. Reconstruye los índices después de importar los datos. En sistemas con Replica Set se recomienda ejecutarlo con la opción --oplogRelay. mongorestore --host mongodb1.example.net --port 37017 --username user --password pass /opt/backup/mongodump-2016-02-04 mongodump y mongorestore son simples y eficientes para despliegues pequeños de MongoDB, pero pueden dar problemas con grandes entornos con Replica Set o Sharding.

REFERENCIAS Y ENLACES DE INTERÉS https://www.mongodb.com https://docs.mongodb.org/manual https://university.mongodb.com http://www.mongodbspain.com

MongoDB Tools Mongobird - https://github.com/citsoft/mongobird Potente y atractiva herramienta de monitorización que proporciona un panel de control con estadísticas, gráficas, etc Mongoowl - http://mongoowl.citsoft.net/ Herramienta de monitorización en tiempo real y visualización gráfica basada en DHTML Robomongo - http://robomongo.org/ Herramienta open source de gestión de MongoDB orientada a Shell Mongo Management Studio - Community Edition http://www.litixsoft.de/english/mms Consola de gestión para MongoDB con un interface claro y ligero. Puedes ejecutar los comandos típicos de MongoDB sin necesidad de utilizar MongoDB shell Edda – http://goo.gl/bck5fp Script python que trata ficheros log de MongoDB como entrada y genera un timeline gráfico de eventos en un Replica Set REFERENCIAS Y ENLACES DE INTERÉS

FIN