Implemente un conjunto de réplicas con alta disponibilidad en MongoDB 3.4 usando Keyfile para control de acceso en Ubuntu 16.04

• Acerca del conjunto de réplicas
• Prerrequisitos
• Diseñar el conjunto de réplica
• Instrucciones de implementación
• Conclusión

Desde su concepción en 2009, MongoDB ha liderado la industria NoSQL. Uno de los conceptos centrales de MongoDB es el conjunto de réplicas, por lo que antes de trabajar con él, primero revisemos el concepto.

Acerca del conjunto de réplicas

El modelo más simple de comunicación utilizado en la replicación de bases de datos es la arquitectura Maestro-Esclavo. Como su nombre lo indica, este modelo tiene 2 roles que se extienden en un maestro único y muchos esclavos, el rol del maestro es procesar las operaciones de lectura y escritura realizadas por los clientes y los esclavos son tratados como una réplica del maestro.

La ventaja más importante de este modelo es que el rendimiento del maestro no se ve comprometido por las operaciones de respaldo, las operaciones de respaldo se realizan de forma asíncrona y esto puede convertirse en un problema grave cuando falla un nodo maestro. Los nodos esclavos son de solo lectura y deben promoverse manualmente al nodo maestro, por lo que en este momento existe la posibilidad de perder datos.

Una opción para resolver el problema de disponibilidad es tener más de un maestro en la arquitectura, pero esto puede conducir a otro problema en la consistencia de los datos entre esas instancias y la complejidad adicional de la configuración.

Ahora dado el contexto, podemos presentar la tecnología Replica Set de MongoDB. Conjunto de réplica es el nombre de la arquitectura Maestro-Esclavo que tiene conmutación por error automática, por lo que en el momento en que un primarynodo maestro (que ahora se llama ) no funciona correctamente, electionse disparará y se elegirá un nuevo nodo primario entre los esclavos restantes ( referido ahora como secondaries).

Nodo primario

El nodo primario es el único que realiza operaciones de escritura, de forma predeterminada las operaciones de lectura también son manejadas por el primario, pero este comportamiento se puede cambiar más adelante.

Las operaciones se registran en el oplog(registro de operaciones), luego los nodos secundarios actualizan su contenido de forma asíncrona en función del contenido deloplog

Nota: oploges una colección con límite, esto significa que la colección tiene un límite, con el local.oplog.rsque puede verificar el contenido de esta colección dentro de un shell mongo en cualquier miembro del conjunto.

Nodo secundario

Además de ser los que hacen una copia de seguridad adecuada de la base de datos, un nodo secundario tiene estos roles:

• Puede aceptar operaciones de lectura si es necesario.
• Puede desencadenar una elección si falla un nodo primario.
• Puede votar en elecciones.
• Puede convertirse en la nueva primaria si es necesario.

Gracias a estas características podemos tener diferentes tipos de nodos secundarios:

• Prioridad 0 : estos nodos no pueden convertirse en primaryy no pueden desencadenar una elección, aún así pueden votar en las elecciones, tener una réplica completa y pueden aceptar operaciones de lectura. Estos pueden ser útiles en la implementación de centros de datos múltiples.
• Oculto : Estos son Priority 0miembros, pero además no pueden procesar operaciones de lectura. Pueden votar si es necesario. Las tareas preferidas para estos miembros son los informes y las copias de seguridad.
• Retrasado : estos nodos están a cargo de los "datos históricos" al retrasarse con alguna unidad en el tiempo. Un miembro retrasado debe ser un priority 0nodo, y se recomienda que también sea hiddenmiembro.

Prerrequisitos

• La disponibilidad para ejecutar un mínimo de 3 instancias de Ubuntu 16.04 x64 con el mismo tamaño de servidor.

Diseñar el conjunto de réplica

Antes de desplegar una infraestructura es importante diseñarla, y hay puntos a considerar en este diseño.

Elegir el número de miembros

Tenga en cuenta que el número mínimo de elementos para crear un conjunto de réplica es 3. Puede mezclar los tres tipos de nodos con un mínimo de un nodo primario y uno secundario.

En esta guía, estamos implementando 3 miembros, uno primario y dos secundarios estándar.

Nota: Se recomienda tener un número máximo de 7 miembros con derecho a voto con una combinación de árbitros y miembros secundarios.

Escoge un nombre

El nombre es solo para referencia, pero lo está utilizando en la configuración del conjunto. Tenga en cuenta que puede tener más de un conjunto de réplicas en su entorno de producción, así que no descuide el nombre de su conjunto.

Este tutorial anima al usuario a seleccionar el nombre del conjunto.

Distribución de los miembros en diferentes centros de datos.

Este tutorial sugiere implementar en el mismo centro de datos para evitar problemas de comunicación.

Nota: En caso de implementar en diferentes centros de datos, se recomienda envolver sus nodos con una VPN

Instrucciones de implementación

Paso 1: Implemente los nodos mínimos para su infraestructura

Inicie 3 nodos de Ubuntu 16.04 x64; en la misma región desde su portal de clientes, si es posible. No olvide nombrarlos de acuerdo con el tipo de proyecto con el que está tratando y asegúrese de tener el mismo tamaño de servidor en todos estos nodos.

Después de desplegar sus 3 nodos, deberá asegurarse de que cada nodo pueda hablar con el resto. Necesita ssh en dos nodos y llegar a los demás usando ping -c 4 EXAMPLE_IP. Cambie EXAMPLE_IPa las IP reales de sus nodos.

Aquí puede ver un ejemplo de comunicación exitosa entre dos nodos.

root@foo_node:~# ping -c 4 EXAMPLE_IP
PING EXAMPLE_IP (EXAMPLE_IP) 56(84) bytes of data.
64 bytes from EXAMPLE_IP: icmp_seq=1 ttl=59 time=0.594 ms
64 bytes from EXAMPLE_IP: icmp_seq=2 ttl=59 time=0.640 ms
64 bytes from EXAMPLE_IP: icmp_seq=3 ttl=59 time=0.477 ms
64 bytes from EXAMPLE_IP: icmp_seq=4 ttl=59 time=0.551 ms

--- EXAMPLE_IP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3021ms
rtt min/avg/max/mdev = 0.477/0.565/0.640/0.064 ms

Paso 2: instale MongoDB en cada nodo de su infraestructura

En general, puede usar el paquete MongoDB de Ubuntu, pero es mejor usar el repositorio oficial de la comunidad porque siempre está actualizado. Este repositorio contiene estos paquetes:

• mongodb-org , el paquete grupal que envuelve los cuatro componentes.
• mongodb-org-server , este contiene el mongoddemonio (proceso primario que maneja las solicitudes de datos).
• mongodb-org-mongos , contiene el mongosdemonio (servicio de enrutamiento para implementaciones compartidas).
• mongodb-org-shell , esta es la mongo shellinterfaz de JavaScript.
• mongodb-org-tools , algunas herramientas para actividades de administración.

Proceda a instalar los paquetes.

Importe la clave pública al sistema de gestión de paquetes.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

Cree el archivo de lista para MongoDB '/etc/apt/sources.list.d/mongodb-org-3.4.list'.

echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

Actualice la base de datos del paquete.

sudo apt-get update

Instale el metapaquete MongoDB.

sudo apt-get install -y mongodb-org

Inicie el servicio MongoDB.

sudo service mongod start

Ahora puede abrir el mongo shellen cualquier sesión bash. Para hacer esto, debes usar el mongocomando. Serás recibido por algo similar a esto.

MongoDB shell version v3.4.7
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.7
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
Server has startup warnings:
*Some extra logs are cut by the way*
>

No olvides cerrar el servicio con sudo service mongod stop, porque más tarde comenzaremos mongodnuevamente con algunos parámetros. Repita este proceso en los 3 nodos del conjunto.

Paso 3: configurar el archivo de claves de acceso

El uso de un archivo clave fuerza dos conceptos en la administración del conjunto de réplicas. La primera de ellas es Internal Authentication. De manera predeterminada, puede iniciar una mongo shellsesión sin usar un usuario y esta sesión tendrá el control total de la base de datos, pero cuando usa un archivo de claves para la autenticación, su mongo shellsesión alcanza un estado llamado localhost exception. Este estado solo le permite crear el usuario administrador y el conjunto de réplicas. El segundo concepto es Role-Based Access Control, o en otras palabras, autorización. Esto se aplica para gobernar los niveles administrativos del conjunto de réplicas.

Crea tu archivo clave

El archivo de claves es la contraseña para usar en el conjunto, esta contraseña debe ser la misma en todos los miembros del conjunto. Para aumentar la seguridad, es importante utilizar una clave aleatoria con la herramienta que elija.

El contenido debe tener entre 6 y 1064 caracteres de longitud. También debe establecer el read onlypermiso para el archivo de claves.

chmod 400 PATH_OF_YOUR_KEYFILE

Coloque el archivo de claves en cada miembro del conjunto

Ahora copie su archivo clave a cada miembro del conjunto, utilice una carpeta consistente para referencia futura y no lo guarde en un medio extraíble.

Utilice también una carpeta para el archivo al que mongodpueda acceder.

Aplicar mediante el archivo de claves en el conjunto de réplicas

En este paso, necesitamos comenzar mongod daemon en cada miembro del conjunto . Hay dos formas de iniciar el mongodproceso: usando un archivo de configuración o usando la línea de comando. Ambos son métodos bastante fáciles, pero solo por simplicidad, este tutorial utiliza la versión de línea de comandos.

Configuración de línea de comando

Use el nombre que eligió anteriormente en este comando.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

Por defecto mongodno se ejecuta como un demonio. Necesitará usar el --forkparámetro o usarlo upstartpara ejecutarlo completamente como demonio. En este tutorial no recomendamos que se ejecute mongodcomo demonio para que pueda ver los registros directamente en su terminal.

Nota: Escriba con cuidado el nombre del conjunto de réplicas porque una vez creado no puede cambiarlo.

Paso 4: conéctese a la interfaz localhost desde uno de los miembros del conjunto

Nota: Si se ejecuta mongodcomo un proceso que no es daemon, tendrá que abrir otra conexión ssh para continuar trabajando.

Debe usar el mongocomando para abrir el mongo shell. Esto se puede hacer en cualquier miembro del conjunto.

En este momento estamos en un estado llamado localhost exception. Cuando se utiliza un archivo de claves para configurar el mongodproceso, está obligado a crear un administrador de base de datos antes de poder aplicar operaciones de lectura y escritura, pero lo veremos más adelante.

Paso 5: iniciar el conjunto de réplicas

Esta es una parte delicada, estamos usando el comando rs.initiate()dentro mongo shelldel Paso 4. antes de usar este comando, revisémoslo.

rs.initiate(
  {
    _id : <replicaSetName>,
    members: [
      { _id : 0, host : "example1.net:27017" },
      { _id : 1, host : "example2.net:27017" },
      { _id : 2, host : "example3.net:27017" }
    ]
  }
)

El primer _idcampo es una cadena y debe coincidir con el --replSetque se pasó antes a mongod. Además, cada valor de hostdebe ser la ip o el nombre de dominio de cada miembro del conjunto de réplicas. No olvide agregar el puerto que la instancia de mongo está usando en cada miembro.

Ahora es el momento de ejecutar el comando con sus datos, esto activará un election, luego se elegirá un primario automáticamente.

Aquí debe tener en cuenta que su cursor de shell ha cambiado a YOUR_SET_NAME:PRIMARY>o YOUR_SET_NAME:SECONDARY. Esto significa que crear un set fue un éxito.

Para continuar trabajando necesita encontrar el primary, si no está en él, por supuesto. Use el rs.status()comando para mostrar la información del conjunto de réplicas y localice el primary. Estás buscando la propiedad "stateStr" : "PRIMARY".

Paso 6: creación del administrador

Después de haber localizado el primary, ingrese el mongo shelly ejecute el siguiente comando usando sus datos.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOU_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

La admin = db.getSiblingDB("admin")parte nos permite escribir admindesde una base de datos diferente. Esto crea un alias llamado admin, por lo que podemos ejecutar comandos usándolo en su lugar.

Si la operación es exitosa, recibirá una notificación de que el usuario ha sido agregado.

Successfully added user: {
    "user" : "YOUR_USER",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        }
    ]
}

En este punto, solo tenemos un administrador para todos los servidores, pero tener un conjunto de réplicas nos obliga a tener un usuario con el clusterAdminrol. Crearemos otro usuario con solo ese rol para separar las preocupaciones.

Paso 7: Autenticando como administrador

Hemos alcanzado el límite de localhost exception, por lo que tenemos que cambiar la autenticación para el usuario creado un paso antes.

Puede cambiar los usuarios dentro de la mongo shellcon lo siguiente.

db.getSiblingDB("admin").auth("YOUR_ADMIN", "YOUR_PASSWORD" )

Si aún no se ha conectado, mongo shelluse este comando en su lugar.

mongo -u "YOUR_ADMIN" -p "YOUR_PASSWORD" --authenticationDatabase "admin"

Se le notificará el cambio de un usuario, y puede ir al siguiente paso.

Paso 8: creación del clúster maestro

El clusterAdminrol le da al usuario el control total del conjunto de réplicas. Crearlo es tan fácil como crear el usuario administrador.

db.getSiblingDB("admin").createUser(
  {
    "user" : "YOUR_USER",
    "pwd" : "YOUR_PASSWORD",
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

Tenga en cuenta que esta vez el rol se cambia aclusterAdmin .

Paso 9: Insertar datos en el conjunto de réplicas

En este momento tenemos 2 usuarios administradores: uno que tiene control total sobre el servidor y otro que tiene acceso a tareas administrativas en el nivel establecido de réplica. Sin embargo, nos falta un usuario que tenga acceso para "usar" una base de datos, por lo que crearemos ese usuario ahora.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOUR_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "cars" } ]
  }
)

Tenga en cuenta que esta vez estamos cambiando la dbparte, allí estamos poniendo la base de datos accesible para el usuario, en este caso estamos usando una base de datos llamada cars.

La base de datos aún no se ha creado. Para hacerlo, tendrá que escribir algunos comandos para crearlo implícitamente. Cambie a la carsbase de datos.

use cars

Usted recibirá una notificación: switched to db cars.

La base de datos aún no se ha creado, para hacerlo debe escribir algo en ella. Estamos usando el siguiente ejemplo.

db.models.insert({ make: "Dodge", model: "Viper", year: 2010 })

Esta vez se le notificará con WriteResult({ "nInserted" : 1 }).

Si lo desea, puede recuperar todos los objetos en la base de datos, con el find()método:

db.models.find()
{ "_id" : ObjectId("59acd8b55334882863541ff4"), "make" : "Dodge", "model" : "Viper", "year" : 2010 }

Tenga en cuenta que _idserá diferente en su salida, pero los otros datos deberían ser los mismos. Con suficiente tiempo, estos datos se replicarán a los otros miembros.

Conclusión

Crear un conjunto de réplicas puede ser un desafío al principio porque hay mucha información que comprender, pero una vez que tenga la idea, puede implementarla en un instante, así que no se dé por vencido si no puede captarla la primera vez. Tenga en cuenta que el conjunto de réplicas es importante en la administración de MongoDB porque abre la posibilidad de agregar funciones avanzadas como Load Balancing.