Nozioni di base sulla distribuzione di un set di repliche MongoDB e frammenti utilizzando Puppet

I sistemi di database funzionano al meglio quando sono integrati con alcuni approcci ben definiti che facilitano sia le operazioni di lettura che di scrittura. MongoDB ha fatto il possibile adottando la replica e lo sharding con l'obiettivo di abilitare il ridimensionamento orizzontale e verticale rispetto ai DBM relazionali il cui stesso concetto migliora solo il ridimensionamento verticale.

 Il partizionamento orizzontale garantisce la distribuzione del carico tra i membri del cluster di database in modo che le operazioni di lettura vengano eseguite con poca latenza. Senza lo sharding, la capacità di un singolo server di database con un ampio set di dati e operazioni a velocità effettiva elevata può essere tecnicamente compromessa e può causare il guasto di quel server se non vengono prese in considerazione le misure necessarie. Ad esempio, se la frequenza delle query è molto elevata, la capacità della CPU del server sarà sovraccaricata.

La replica, d'altra parte, è un concetto per cui diversi server di database ospitano gli stessi dati. Garantisce un'elevata disponibilità dei dati oltre a migliorare l'integrità dei dati. Prendi un esempio di un'applicazione di social media ad alte prestazioni, se il sistema di database di servizio principale si guasta come in caso di un'interruzione di corrente, dovremmo avere un altro sistema per servire gli stessi dati. Un buon set di repliche dovrebbe avere più di 3 membri, un arbitro e un'elezione ottimale TimeoutMillis. Nella replica, avremo un nodo master/primario in cui vengono eseguite tutte le operazioni di scrittura e quindi applicate a un Oplog. Dall'Oplog, tutte le modifiche apportate vengono poi applicate agli altri membri, che in questo caso vengono definiti nodi secondari o slave. Nel caso in cui i nodi primari non comunichino dopo un po' di tempo:elezioniTimeoutMillis, gli altri nodi vengono segnalati per andare a un'elezione. Il parametro selectionTimeoutMillis non deve essere impostato su un valore né troppo alto né troppo basso per il motivo che i sistemi rimarranno inattivi per molto tempo, quindi perderanno molti dati o elezioni frequenti che potrebbero risultare anche con latenza di rete temporanea e quindi incoerenza dei dati rispettivamente. Un arbitro viene utilizzato per aggiungere un voto a un membro vincitore per diventare un maestro in caso di pareggio ma non contiene dati come gli altri membri.

Perché utilizzare Puppet per distribuire un set di repliche MongoDB

Più spesso, lo sharding viene utilizzato di pari passo con la replica. Il processo di configurazione e mantenimento di un set di repliche non è facile a causa di:

1. Alte possibilità di errore umano
2. Incapacità di svolgere attività ripetitive automaticamente
3. Dispendioso in termini di tempo soprattutto quando è coinvolto un numero elevato di membri
4. Possibilità di insoddisfazione lavorativa
5. Una complessità schiacciante che potrebbe emergere.

Per superare le battute d'arresto delineate, ci adeguiamo a un sistema automatizzato come Puppet che ha molte risorse per aiutarci a lavorare con facilità.

Nel nostro blog precedente, abbiamo appreso il processo di installazione e configurazione di MongoDB con Puppet. Tuttavia, è importante comprendere le risorse di base di Puppet poiché le utilizzeremo per configurare il nostro set di repliche e frammenti. Nel caso te lo fossi perso, questo è il file manifest per il processo di installazione ed esecuzione del tuo MongoDB sulla macchina che hai creato

​  package {'mongodb':

    ensure => 'installed',

  }

  service {'mongodb':

    ensure => 'running',

    enable => true

  }

Quindi possiamo inserire il contenuto sopra in un file chiamato runMongoDB.pp ed eseguirlo con il comando 

$ sudo apply runMongoDB.pp

Cantando il modulo e le funzioni 'mongodb', possiamo impostare il nostro set di repliche con i parametri corrispondenti per ogni risorsa mongodb.

Connessione MongoDB

Dobbiamo stabilire una connessione mongodb tra un nodo e il server mongodb. L'obiettivo principale di questo è impedire l'applicazione delle modifiche alla configurazione se il server mongodb non può essere raggiunto ma può essere potenzialmente utilizzato per altri scopi come il monitoraggio del database. Usiamo il mongodb_conn_validator

mongodb_conn_validator{‘mongodb_validator’:

ensure => present,

     server: ‘127.0.0.1:27017’,

     timeout: 40,

     tcp_port:27017

    }

name: in questo caso il nome mongodb_validator definisce l'identità della risorsa. Potrebbe anche essere considerata una stringa di connessione

server:potrebbe essere una stringa o un array di stringhe contenenti nomi DNS/indirizzi IP del server su cui dovrebbe essere in esecuzione mongodb.

timeout:questo è il numero massimo di secondi che il validatore deve attendere prima di decidere che puppetdb non è in esecuzione.

tcp_port: questo è un provider per la risorsa che convalida la connessione mongodb tentando la connessione https al server mongodb. La configurazione del certificato SSL del pupazzo dall'ambiente del pupazzo locale viene utilizzata nell'autenticazione.

Creazione del database

mongodb_database{‘databaseName’:

ensure => present,

     tries => 10

}

Questa funzione accetta 3 parametri ovvero:

name: in questo caso il nome databaseName definisce il nome del database che stiamo creando, che sarebbe stato anche dichiarato name => ‘databaseName’.

Tries:definisce la quantità massima di due secondi di tentativi per attendere l'avvio di MongoDB

Creazione di un utente MongoDB

Il modulo mongodb_user consente di creare e gestire utenti per un determinato database nel modulo pupazzo.

mongodb_user {userprod:

  username => ‘prodUser’,

  ensure => present,

  password_hash => mongodb_password(‘prodUser’, ‘passProdser’),

  database => prodUser,

  roles => [‘readWrite’, ‘dbAdmin’],

  tries  => 10

}

Proprietà

username:definisce il nome dell'utente.

password_hash:questo è l'hash della password dell'utente. La funzione mongodb_password() disponibile su MongoDB 3.0 e versioni successive viene utilizzata per creare l'hash.

ruoli:definisce i ruoli che l'utente può eseguire sul database di destinazione.

password:questo è il testo semplice della password dell'utente.

database:definisce il database di destinazione dell'utente.

Creazione di un set di repliche

Utilizziamo il modulo mongodb_replset per creare un set di repliche.

Mongodb_replset{'replicaset1':

   arbiter: 'host0:27017',

   ensure  => present,

   members => ['host0:27017','host1:27017', 'host2:27017', 'host3:27017'] 

   initialize_host: host1:27017

}

name:definisce il nome del set di repliche.

membri:un array di membri che il set di repliche conterrà.

initialize_host:host da utilizzare nell'inizializzazione del set di repliche

arbitro:definisce il membro del set di repliche che verrà utilizzato come arbitro.

Creazione di uno shard MongoDB

mongodb_shard{'shard1':

   ensure  => present,

   members => ['shard1/host1:27017', 'shard1/host2:27017', 'shard1/host3:27017'] 

   keys: 'price'

}

name:definisce il nome dello shard.

membri:questo è l'array di membri che lo shard conterrà.

chiavi:definisce la chiave da utilizzare nello sharding o una matrice di chiavi che possono essere utilizzate per creare una chiave shard composta.