Cómo configurar un Sharded Cluster en MongoDB

Definición

Un sharded cluster es un conjunto de Replica Sets (shards) cuya función es la de repartirse uniformemente la carga de trabajo, de tal manera que nos permite escalar horizontalmente nuestras aplicaciones para así poder trabajar con grandes cantidades de datos. MongoDB uses sharding to support deployments with very large data sets

Ventajas de un sharded cluster

Las principales funcionalidades que nos aporta un sharded cluster son las siguientes:

  • Escalabilidad: desde un servidor aislado a arquitecturas distribuidas de grandes clusters (Permite particionar, de manera transparente para el usuario, nuestra base de datos en tantas como shards tengamos. Esto aumenta el rendimiento del procesado de los datos al ser cada una de ellas más pequeña que la original)
  • Auto balanceado de carga a través de los distintos shards. El balanceador decide cuándo migrar los datos, y a qué Shard, para que estén uniformemente distribuidos entre todos los servidores del cluster. Cada shard aloja los datos correspondientes a un rango de la clave escogida para particionar nuestra colección.

Configuración de nuestro Sharded Cluster

Esta es la configuración que va a tener nuestro cluster:

  • Tres config servers (lo mínimo para producción): su función es la de decirle a los mongos a qué Replica Set, o shard, tienen que enrutar las peticiones de los clientes. Irán en la máquina: juan-mongodbspain
  • Dos replica sets (a y b) de tres nodos cada uno (suficiente para mostrar cómo se configura el cluster). Cada Replica Set en una máquina distinta, el primero en: juan-mongodbspain y el segundo en: juan-mongodbspain2.
  • Dos mongos (solicitan la información requerida por los clientes al shard que la contiene. Irán en la máquina: juan-mongodbspain

Creación de directorios

Antes de levantar los servicios debemos haber creado los directorios donde guardaremos nuestros datos. Utilizaremos los siguientes:

  • cfg0, cfg1 y cfg2 para cada config server
  • a0, a1 y a2 para cada uno de los tres nodos de la primera Replica Set
  • b0, b1 y b2 para cada uno de los tres nodos de la segunda Replica Set

Orden

Seguiremos este orden para levantar las instancias que componen nuestro sharded cluster:

  1. Config servers
  2. mongod’s
  3. mongo’s

Config servers

Levantamos los config servers:

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongod—configsvr—port26050—logpath/var/lib/mongodb/shardedcluster/log.cfg0—logappend—dbpath/var/lib/mongodb/shardedcluster/cfg0—fork

about tofork childprocess,waiting until server isready forconnections.

forked process:5453

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongod—configsvr—port26051—logpath/var/lib/mongodb/shardedcluster/log.cfg1—logappend—dbpath/var/lib/mongodb/shardedcluster/cfg1—fork

about tofork childprocess,waiting until server isready forconnections.

forked process:5469

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongod—configsvr—port26052—logpath/var/lib/mongodb/shardedcluster/log.cfg2—logappend—dbpath/var/lib/mongodb/shardedcluster/cfg2—fork

about tofork childprocess,waiting until server isready forconnections.

forked process:5498

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$

Mediante la opción ‘configsvr’ indicamos que el servicio va a ser un config server.

Como podemos observar, estamos utilizando la máquina “juan-mongodbspain” para alojar los tres config servers, por esa razón utilizamos puertos distintos. En caso de tenerlos en máquinas distintas no es necesario que especifiquemos ningún puerto.

mongod’s

En un artículo anterior explicamos cómo configurar una Replica Set, podéis leerlo aquí:

Vamos a levantar los servicios correspondientes a los seis nodos. Los tres primeros formarán el primer Replica Set (shard) e irán en una máquina. Los tres últimos formarán el segundo shard e irán en otra máquina.

En el comando que vamos a utilizar hemos de indicar que el mongod va a formar parte de un shard en un cluster particionado. Esto lo conseguimos a través de la opción –shardsvr. El puerto por defecto para estas instancias es el 27018.

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongod—shardsvr—replSeta—dbpath/var/lib/mongodb/shardedcluster/a0—logpath/var/lib/mongodb/shardedcluster/log.a0—port27000—fork—logappend—smallfiles—oplogSize50

about tofork childprocess,waiting until server isready forconnections.

forked process:5515

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongod—shardsvr—replSeta—dbpath/var/lib/mongodb/shardedcluster/a1—logpath/var/lib/mongodb/shardedcluster/log.a1—port27001—fork—logappend—smallfiles—oplogSize50

about tofork childprocess,waiting until server isready forconnections.

forked process:5562

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongod—shardsvr—replSeta—dbpath/var/lib/mongodb/shardedcluster/a2—logpath/var/lib/mongodb/shardedcluster/log.a2—port27002—fork—logappend—smallfiles—oplogSize50

about tofork childprocess,waiting until server isready forconnections.

forked process:5609

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$

Ahora vamos con el segundo Shard, que irá alojado en la otra máquina:

juan@juan-mongodbspain2:/var/lib/mongodb/shardedcluster$mongod—shardsvr—replSetb—dbpath/var/lib/mongodb/shardedcluster/b0—logpath/var/lib/mongodb/shardedcluster/log.b0—port27000—fork—logappend—smallfiles—oplogSize50

about tofork childprocess,waiting until server isready forconnections.

forked process:5658

childprocess started successfully,parentexiting

juan@juan-mongodbspain2:/var/lib/mongodb/shardedcluster$mongod—shardsvr—replSetb—dbpath/var/lib/mongodb/shardedcluster/b1—logpath/var/lib/mongodb/shardedcluster/log.b1—port27001—fork—logappend—smallfiles—oplogSize50

about tofork childprocess,waiting until server isready forconnections.

forked process:5706

childprocess started successfully,parentexiting

juan@juan-mongodbspain2:/var/lib/mongodb/shardedcluster$mongod—shardsvr—replSetb—dbpath/var/lib/mongodb/shardedcluster/b2—logpath/var/lib/mongodb/shardedcluster/log.b2—port27002—fork—logappend—smallfiles—oplogSize50

about tofork childprocess,waiting until server isready forconnections.

forked process:5754

childprocess started successfully,parentexiting

juan@juan-mongodbspain2:/var/lib/mongodb/shardedcluster$

mongo’s

Salvo para tareas de administración nunca nos conectaremos a un mongod ni a un config server. Las apps lo harán a los mongos, que son los encargados de enrutar las peticiones a los shards correspondientes. Es por esta razón por la que estamos especificando puertos distintos al estándar en todas las instancias. Por lo tanto, la única puerta de entrada a la base de datos ha de ser un mongos.

Así se levantan los mongos:

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongos—configdb juan-mongodbspain:26050,juan-mongodbspain:26051,juan-mongodbspain:26052—fork—logappend—logpath/var/lib/mongodb/shardedcluster/log.mongos0

about tofork childprocess,waiting until server isready forconnections.

forked process:5832

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongos—configdb juan-mongodbspain:26050,juan-mongodbspain:26051,juan-mongodbspain:26052—fork—logappend—logpath/var/lib/mongodb/shardedcluster/log.mongos1—port26061

about tofork childprocess,waiting until server isready forconnections.

forked process:5894

childprocess started successfully,parentexiting

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$

Como vemos, al no haber especificado puerto alguno en el primero de ellos será ese mongos el que utilice el puerto por defecto (27017).

Comprobación de nuestros servicios

Vamos ahora a comprobar que tenemos todas las instancias corriendo:

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$ps-ef|grep mongo

root54532634011:08?00:00:10mongod—configsvr—port26050—logpath/var/lib/mongodb/shardedcluster/log.cfg0—logappend—dbpath/var/lib/mongodb/shardedcluster/cfg0—fork

root54692634011:08?00:00:10mongod—configsvr—port26051—logpath/var/lib/mongodb/shardedcluster/log.cfg1—logappend—dbpath/var/lib/mongodb/shardedcluster/cfg1—fork

root54982634011:09?00:00:10mongod—configsvr—port26052—logpath/var/lib/mongodb/shardedcluster/log.cfg2—logappend—dbpath/var/lib/mongodb/shardedcluster/cfg2—fork

root55152634011:10?00:00:10mongod—shardsvr—replSeta—dbpath/var/lib/mongodb/shardedcluster/a0—logpath/var/lib/mongodb/shardedcluster/log.a0—port27000—fork—logappend—smallfiles—oplogSize50

root55622634011:10?00:00:10mongod—shardsvr—replSeta—dbpath/var/lib/mongodb/shardedcluster/a1—logpath/var/lib/mongodb/shardedcluster/log.a1—port27001—fork—logappend—smallfiles—oplogSize50

root56092634011:11?00:00:09mongod—shardsvr—replSeta—dbpath/var/lib/mongodb/shardedcluster/a2—logpath/var/lib/mongodb/shardedcluster/log.a2—port27002—fork—logappend—smallfiles—oplogSize50

root58322634011:34?00:00:00mongos—configdb juan-mongodbspain:26050,juan-mongodbspain:26051,juan-mongodbspain:26052—fork—logappend—logpath/var/lib/mongodb/shardedcluster/log.mongos0

root58942634011:34?00:00:00mongos—configdb juan-mongodbspain:26050,juan-mongodbspain:26051,juan-mongodbspain:26052—fork—logappend—logpath/var/lib/mongodb/shardedcluster/log.mongos1—port26061

juan59545196011:35pts/600:00:00grep—color=auto mongo

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$

Y en la otra máquina tenemos los mongod’s correspondientes al segundo shard:

juan@juan-mongodbspain2:/var/lib/mongodb/shardedcluster$ps-ef|grep mongo

root56582634011:12?00:00:09mongod—shardsvr—replSetb—dbpath/var/lib/mongodb/shardedcluster/b0—logpath/var/lib/mongodb/shardedcluster/log.b0—port27000—fork—logappend—smallfiles—oplogSize50

root57062634011:12?00:00:09mongod—shardsvr—replSetb—dbpath/var/lib/mongodb/shardedcluster/b1—logpath/var/lib/mongodb/shardedcluster/log.b1—port27001—fork—logappend—smallfiles—oplogSize50

root57542634011:12?00:00:09mongod—shardsvr—replSetb—dbpath/var/lib/mongodb/shardedcluster/b2—logpath/var/lib/mongodb/shardedcluster/log.b2—port27002—fork—logappend—smallfiles—oplogSize50

juan@juan-mongodbspain2:/var/lib/mongodb/shardedcluster$

Configuración de las Replica Set

Ahora tenemos que configurar las dos Replica Set (explicado en el artículo anterior). Sólo muestro cómo se hace para una de ellas porque es idéntico en ambas:

juan@juan-mongodbspain:/var/lib/mongodb/replicaset$mongo—port27000

MongoDB shell version:2.6.6

connecting to:127.0.0.1:27000/test

Hello Juan.Haveagood day!

>rs.initiate()

“info2":”no configuration explicitly specified — making one”,

“me”:”juan-mongodbspain:27000",

“info”:”Config now saved locally. Should come online in about a minute.”,

“ok”:1

a:PRIMARY>rs.add(“juan-mongodbspain:27001")

{“ok”:1}

a:PRIMARY>rs.add(“juan-mongodbspain:27002")

{“ok”:1}

a:PRIMARY>

Configuración del cluster

Sólo nos falta añadir al cluster nuestros dos shards. Esto lo haremos desde el primer mongos. Antes de hacerlo podemos comprobar que nuestro cluster no contiene ningún shard:

juan@juan-mongodbspain:/var/lib/mongodb/shardedcluster$mongo

MongoDB shell version:2.6.6

connecting to:test

Hello Juan.Haveagood day!

mongos>sh.status()

—-Sharding Status—-

sharding version:{

“_id”:1,

“version”:4,

“minCompatibleVersion”:4,

“currentVersion”:5,

“clusterId”:ObjectId(“548eb941260fb6e98e17d275")

shards:

databases:

{“_id”:”admin”,”partitioned”:false,”primary”:”config”}

mongos>

Añadimos nuestros dos shards al cluster:

mongos>sh.addShard(“a/juan-mongodbspain:27000")

{“shardAdded”:”a”,”ok”:1}

mongos>sh.addShard(“b/juan-mongodbspain2:27000")

{“shardAdded”:”a”,”ok”:1}

mongos>

Comprobamos la configuración del cluster una vez añadidos los dos shards:

mongos>sh.status()

—-Sharding Status—-

sharding version:{

“_id”:1,

“version”:4,

“minCompatibleVersion”:4,

“currentVersion”:5,

“clusterId”:ObjectId(“548eb941260fb6e98e17d275")

shards:

{“_id”:”a”,”host”:”a/juan-mongodbspain:27000,juan-mongodbspain:27001,juan-mongodbspain:27002"}

{“_id”:”b”,”host”:”b/juan-mongodbspain2:27000,juan-mongodbspain2:27001,juan-mongodbspain2:27002"}

databases:

{“_id”:”admin”,”partitioned”:false,”primary”:”config”}

mongos>

Balanceador

De esta forma podemos comprobar que está activo el balanceador:

mongos>sh.getBalancerState()

true

mongos>

Ya hemos terminado de configurar nuestro sharded cluster. Dejamos para otro artículo explicar cómo particionar una colección.

En el próximo artículo hablaremos sobre cómo actualizar un nodo stand-alone, una Replica Set y un Sharded Cluster.


Originally published at www.mongodbspain.com on January 26, 2015.

Show your support

Clapping shows how much you appreciated juan roy’s story.