Desplegueu un conjunt de rèpliques amb alta disponibilitat a MongoDB 3.4 mitjançant el fitxer de claus per al control daccés a Ubuntu 16.04

Des de la seva concepció el 2009, MongoDB ha liderat la indústria NoSQL. Un dels conceptes bàsics de MongoDB és el conjunt de rèpliques, així que abans de treballar-hi, revisem el concepte.

Sobre el conjunt de rèpliques

El model de comunicació més senzill utilitzat en la replicació de bases de dades és l'arquitectura Master-Slave. Com el seu nom indica, aquest model té 2 rols distribuïts en un mestre únic i molts esclaus, el paper del mestre és processar les operacions de lectura i escriptura realitzades pels clients i els esclaus es tracten com una rèplica del mestre.

L'avantatge més important d'aquest model és que el rendiment del mestre no es veu compromès per les operacions de còpia de seguretat, les operacions de còpia de seguretat es fan de manera asíncrona i això pot convertir-se en un problema greu quan falla un node mestre. Els nodes esclaus són només de lectura i s'han de promocionar manualment al node mestre, de manera que en aquest temps hi ha la possibilitat de perdre dades.

Una opció per resoldre el problema de disponibilitat és tenir més d'un mestre en l'arquitectura, però això pot comportar un altre problema en la coherència de les dades entre aquestes instàncies i la complexitat afegida de la configuració.

Ara donat el context, podem presentar la tecnologia Replica Set de MongoDB. El conjunt de rèpliques és el nom de l'arquitectura Mestre-Esclau que té una migració automàtica per error, de manera que en el moment en què un primarynode mestre (que ara s'anomena ) no funciona correctament election, s'activarà i s'escollirà un nou node primari entre els esclaus restants ( denominat ara secondaries).

Node primari

El node principal és l'únic que realitza operacions d'escriptura, per defecte les operacions de lectura també les gestiona el principal, però aquest comportament es pot canviar més endavant.

Les operacions s'enregistren al oplog(registre d'operacions) i, a continuació, els nodes secundaris actualitzen el seu contingut de manera asíncrona en funció del contingut deloplog

Nota: oplogés una col·lecció limitada, això vol dir que la col·lecció té un límit, ja local.oplog.rsque podeu comprovar el contingut d'aquesta col·lecció dins d'un shell mongo en qualsevol membre del conjunt.

Node secundari

A més de ser els que fan una còpia de seguretat adequada de la base de dades, un node secundari té aquestes funcions:

• Pot acceptar operacions de lectura si cal.
• Pot desencadenar una elecció si falla un node primari.
• Pot votar a les eleccions.
• Pot convertir-se en la nova primària si cal.

Gràcies a aquestes característiques podem tenir diferents tipus de nodes secundaris:

• Prioritat 0 : aquests nodes no poden convertir-se en un primaryi no poden desencadenar una elecció, tot i així poden votar a les eleccions, tenir una rèplica completa i acceptar operacions de lectura. Aquests poden ser útils en el desplegament de diversos centres de dades.
• Ocults : són Priority 0membres, però a més no poden processar operacions de lectura. Poden votar si cal. Les tasques preferides per a aquests membres són els informes i les còpies de seguretat.
• Endarrerit : aquests nodes s'encarreguen de les "dades històriques" en ser retardats amb alguna unitat en el temps. Un membre retardat ha de ser un priority 0node, i es recomana que hiddentambé ho sigui.

Requisits previs

• La disponibilitat per executar un mínim de 3 instàncies d'Ubuntu 16.04 x64 amb la mateixa mida del servidor.

Dissenyeu el conjunt de rèpliques

Abans de desplegar una infraestructura és important dissenyar-la, i hi ha punts a tenir en compte en aquest disseny.

Elecció del nombre de membres

Tingueu en compte que el nombre mínim d'elements per crear un conjunt de rèplica és de 3. Podeu barrejar els tres tipus de nodes amb un mínim d'un node primari i un secundari.

En aquesta guia estem desplegant 3 membres, un principal i dos secundaris estàndard.

Nota: Es recomana tenir un nombre màxim de 7 membres amb dret a vot amb una barreja d'àrbitres i membres secundaris.

Trieu un nom

El nom és només com a referència, però l'estàs utilitzant a la configuració del conjunt. Tingueu en compte que podeu tenir més d'un conjunt de rèpliques al vostre entorn de producció, així que no oblideu el nom del vostre conjunt.

Aquest tutorial anima l'usuari a seleccionar el nom del conjunt.

Distribució dels membres en diferents centres de dades

Aquest tutorial suggereix desplegar-lo al mateix centre de dades per evitar problemes de comunicació.

Nota: en cas de desplegament en diferents centres de dades, es recomana embolicar els vostres nodes amb una VPN

Instruccions de desplegament

Pas 1: implementeu els nodes mínims per a la vostra infraestructura

Llançar 3 nodes d'Ubuntu 16.04 x64; a la mateixa regió des del vostre portal de clients, si és possible. No us oblideu d'anomenar-los segons el tipus de projecte amb el qual esteu tractant i assegureu-vos de tenir la mateixa mida del servidor en tots aquests nodes.

Després d'haver desplegat els vostres 3 nodes, haureu d'assegurar-vos que tots els nodes poden parlar amb la resta. Heu de fer un ssh en dos nodes i arribar als altres amb ping -c 4 EXAMPLE_IP. Canvieu EXAMPLE_IPa les IP reals dels vostres nodes.

Aquí podeu veure un exemple de comunicació reeixida entre dos nodes.

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

Pas 2: instal·leu MongoDB a cada node de la vostra infraestructura

En general, podeu utilitzar el paquet MongoDB d'Ubuntu, però és millor utilitzar el repo oficial de la comunitat perquè sempre està actualitzat. Aquest repo conté aquests paquets:

• mongodb-org , el paquet de grup que envolta els quatre components.
• mongodb-org-server , conté el mongoddimoni (procés principal que gestiona les sol·licituds de dades).
• mongodb-org-mongos , conté el mongosdimoni (servei d'encaminament per a desplegaments compartits).
• mongodb-org-shell , aquesta és la mongo shellinterfície de JavaScript.
• mongodb-org-tools , algunes eines per a activitats d'administració.

Continueu amb la instal·lació dels paquets.

Importeu la clau pública al sistema de gestió de paquets.

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

Creeu el fitxer de llista per a 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

Actualitzeu la base de dades de paquets.

sudo apt-get update

Instal·leu el metapaquet MongoDB.

sudo apt-get install -y mongodb-org

Inicieu el servei MongoDB.

sudo service mongod start

Ara podeu obrir l' mongo shellen qualsevol sessió de bash. Per fer-ho, heu d'utilitzar l' mongoordre. Seràs rebut per alguna cosa semblant a això.

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 us oblideu de tancar el servei amb sudo service mongod stop, perquè més endavant tornarem a començar mongodamb alguns paràmetres. Repetiu aquest procés als 3 nodes del conjunt.

Pas 3: configureu el fitxer de claus d'accés

L'ús d'un fitxer de claus força dos conceptes a l'administració del conjunt de rèpliques. El primer és Internal Authentication. Per defecte, podeu iniciar una mongo shellsessió sense utilitzar un usuari i aquesta sessió tindrà el control total de la base de dades, però quan feu servir un fitxer de claus per a l'autenticació, la vostra mongo shellsessió arriba a un estat anomenat localhost exception. Aquest estat només us permet crear l'usuari administrador i el conjunt de rèpliques. El segon concepte és Role-Based Access Control, o en altres paraules autorització. Això s'aplica per governar els nivells administratius del conjunt de rèpliques.

Creeu el vostre fitxer de claus

El fitxer de claus és la contrasenya a utilitzar al conjunt, aquesta contrasenya ha de ser la mateixa en tots els membres del conjunt. Per augmentar la seguretat, és important utilitzar una clau aleatòria amb l'eina que escolliu.

El contingut ha de tenir entre 6 i 1064 caràcters. També heu d'establir el read onlypermís per al fitxer de claus.

chmod 400 PATH_OF_YOUR_KEYFILE

Col·loqueu el fitxer de claus a cada membre del conjunt

Ara copieu el vostre fitxer de claus a tots els membres establerts, utilitzeu una carpeta coherent per a referència futura i no l'emmagatzemeu en un suport extraïble.

També utilitzeu una carpeta per al fitxer a què hi mongodpugui accedir.

Aplicar utilitzant el fitxer de claus del conjunt de rèpliques

En aquest pas hem d'iniciar el mongod daemon conjunt de cada membre . Hi ha dues maneres d'iniciar el mongodprocés: mitjançant un fitxer de configuració o mitjançant la línia d'ordres. Tots dos són mètodes bastant fàcils, però només per simplicitat, aquest tutorial utilitza la versió de línia d'ordres.

Configuració de la línia d'ordres

Utilitzeu el nom que heu escollit anteriorment en aquesta ordre.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

Per defecte mongodno s'executa com a dimoni. Haureu d'utilitzar el --forkparàmetre o utilitzar el upstartper executar-lo completament com a dimoni. En aquest tutorial no recomanem l'execució mongodcom a dimoni perquè pugueu veure els registres directament al vostre terminal.

Nota: escriviu amb cura el nom del conjunt de rèpliques perquè un cop creat no podeu canviar-lo.

Pas 4: connecteu-vos a la interfície localhost des d'un dels membres del conjunt

Nota: si executeu mongodcom un procés que no és un dimoni, haureu d'obrir una altra connexió ssh per continuar treballant.

Heu d'utilitzar l' mongoordre per obrir el fitxer mongo shell. Això es pot fer en qualsevol membre del conjunt.

En aquest moment estem en un estat anomenat localhost exception. Quan s'utilitza un fitxer de claus per configurar el mongodprocés, esteu obligat a crear un administrador de base de dades abans de poder aplicar operacions de lectura i escriptura, però ho entrarem més endavant.

Pas 5: inici del conjunt de rèpliques

Aquesta és una part delicada, estem utilitzant l'ordre rs.initiate()dins mongo shelldel pas 4. abans d'utilitzar aquesta comanda, revisem-la.

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 _idcamp és una cadena i ha de coincidir amb el --replSetque es va passar abans a mongod. A més, cada valor de hostha de ser la ip o el nom de domini de cada membre del conjunt de rèpliques. No oblideu afegir el port que la instància mongo està utilitzant a cada membre.

Ara és el moment d'executar l'ordre amb les vostres dades, això activarà un election, i després s'escollirà automàticament un principal.

Aquí hauríeu de tenir en compte que el vostre cursor de shell ha canviat a YOUR_SET_NAME:PRIMARY>o YOUR_SET_NAME:SECONDARY. Això vol dir que crear un conjunt va ser un èxit.

Per continuar treballant, heu de trobar el primary, si no hi esteu, és clar. Utilitzeu l' rs.status()ordre per mostrar la informació del conjunt de rèpliques i localitzar el fitxer primary. Esteu buscant la propietat "stateStr" : "PRIMARY".

Pas 6: Creació de l'administrador

Després d'haver localitzat el primary, introduïu mongo shelli executeu la següent comanda amb les vostres dades.

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

La admin = db.getSiblingDB("admin")part ens permet escriure admindes d'una base de dades diferent. Això crea un àlies anomenat admin, de manera que podem executar ordres utilitzant-lo.

Si l'operació és un èxit, rebràs una notificació que l'usuari ha estat afegit.

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

En aquest moment, només tenim un administrador per a tots els servidors, però tenir un conjunt de rèplica ens obliga a tenir un usuari amb el clusterAdminrol. Crearem un altre usuari amb només aquesta funció per separar les preocupacions.

Pas 7: autenticació com a administrador

Hem arribat al límit del localhost exception, per això hem de canviar l'autenticació a l'usuari creat un pas abans.

Podeu canviar els usuaris dins del mongo shellamb el següent.

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

Si encara no us heu connectat, mongo shellutilitzeu aquesta ordre.

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

Se us notificarà el canvi d'usuari i podreu passar al següent pas.

Pas 8: Creació del mestre de clúster

El clusterAdminrol ofereix a l'usuari el control total del conjunt de rèpliques. Crear-lo és tan fàcil com crear l'usuari administrador.

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

Tingueu en compte que aquesta vegada el rol es canvia aclusterAdmin .

Pas 9: inserció de dades al conjunt de rèplica

En aquest moment tenim 2 usuaris administradors: un que té control total sobre el servidor i un altre que té accés a les tasques administratives a nivell de conjunt de rèplica. No obstant això, ens falta un usuari que tingui accés per "utilitzar" una base de dades, així que crearem aquest usuari ara.

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

Fixeu-vos que aquesta vegada estem canviant la dbpart, allà estem posant la base de dades accessible per l'usuari, en aquest cas estem utilitzant una base de dades anomenada cars.

La base de dades encara no està creada. Per fer-ho, hauràs d'escriure algunes ordres per crear-lo implícitament. Canvia a la carsbase de dades.

use cars

Rebràs una notificació: switched to db cars.

La base de dades encara no s'ha creat, per fer-ho cal escriure-hi alguna cosa. Estem utilitzant el següent exemple.

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

Aquesta vegada se us notificarà amb WriteResult({ "nInserted" : 1 }).

Si voleu, podeu recuperar tots els objectes de la base de dades, amb el find()mètode:

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

Tingueu en compte que _idserà diferent a la vostra sortida, però les altres dades haurien de ser les mateixes. Amb el temps suficient, aquestes dades es replicaran als altres membres.

Conclusió

Crear un conjunt de rèpliques pot ser un repte al principi perquè hi ha molta informació per entendre, però un cop tingueu la idea que hi ha darrere, podeu desplegar-lo amb molt de temps, així que no us rendeu si no podeu comprendre-ho per primera vegada. Tingueu en compte que el conjunt de rèpliques és important en l'administració de MongoDB perquè obre la possibilitat d'afegir funcions avançades com l'equilibri de càrrega.