Manutenzione dei set di repliche MongoDB nel cloud utilizzando Ansible

La replica è stata ampiamente applicata nei sistemi di database per garantire un'elevata disponibilità dei dati attraverso la creazione di ridondanza. Fondamentalmente è una strategia per fare una copia degli stessi dati in diversi server in esecuzione che possono trovarsi su macchine diverse in modo che, in caso di guasto del server principale, ne possa essere attivato un altro per continuare con il servizio.

Un set di repliche è un gruppo di istanze MongoDB che mantengono lo stesso set di dati. Sono la base delle implementazioni di produzione. La replica è vantaggiosa dal fatto che i dati sono sempre disponibili da un server diverso nel caso in cui il sistema del server principale si guasta. Inoltre, migliora il throughput di lettura abilitando un client a inviare richieste di lettura a server diversi e ottenere una risposta da quello più vicino.

Un set di repliche costituisce diversi nodi portanti dati che potrebbero essere ospitati in macchine diverse e un nodo arbitro. Uno di questi nodi portanti dati è etichettato come primario mentre gli altri sono nodi secondari. Il nodo primario riceve tutte le operazioni di scrittura e quindi replica i dati sugli altri nodi dopo che l'operazione di scrittura è stata completata e le modifiche registrate in un oplog.

Un arbitro è un'istanza aggiuntiva che non mantiene un set di dati ma fornisce un quorum in un set di repliche rispondendo al battito cardiaco e alle richieste elettorali da parte di altri membri del set di repliche. Riducono così il costo del mantenimento di un set di repliche piuttosto che di un set completamente funzionante membro del set di repliche con un set di dati.

Failover automatico

Un nodo primario potrebbe non funzionare a causa di alcuni motivi come interruzioni di corrente o disconnessione della rete, quindi non in grado di comunicare con gli altri membri. Se la comunicazione viene interrotta per più del periodo di elezioneTimeoutMillis configurato, una delle secondarie chiede un'elezione per candidarsi come nuova primaria. Se l'elezione è completa e ha esito positivo, il cluster continua con il normale funzionamento. Durante questo periodo non è possibile effettuare operazioni di scrittura. Tuttavia, le query di lettura possono essere configurate per essere eseguite normalmente sui secondari mentre il primario è offline.

Per un processo di replica ottimale, il tempo mediano prima che il cluster elegga un nuovo primario al massimo dovrebbe essere di 12 secondi con le impostazioni di configurazione della replica predefinita. Ciò può essere influenzato da fattori come la latenza di rete che può prolungare il tempo, quindi è necessario tenere in considerazione l'architettura del cluster per assicurarsi che questo tempo non sia impostato troppo alto.

Il valore per selectionTimeoutMillis può essere abbassato dal valore predefinito 10000 (10 secondi), quindi il primario può essere rilevato molto prima durante molto velocemente. Tuttavia, questo potrebbe chiamare frequentemente le elezioni anche per fattori minori come la latenza di rete temporanea anche se il nodo principale è integro. Ciò porterà a problemi come il rollback per le operazioni di scrittura.

Ansible per i set di repliche

Come accennato, un set di repliche può avere membri di diverse macchine host, rendendo così più complessa la manutenzione del cluster. Abbiamo bisogno di un'unica piattaforma da cui questo set di repliche possa essere gestito con facilità. Ansible è uno degli strumenti che offre una panoramica migliore per la configurazione e la gestione di un set di repliche. Se non conosci ansible, fai un breve riassunto di questo articolo per comprendere le nozioni di base come la creazione di un playbook.

Parametri di configurazione

• arbitro_at_index: questo definisce la posizione dell'arbitro nell'elenco dei membri del set di repliche. Un arbitro ricorda non ha dati come gli altri membri e non può essere utilizzato come nodo primario. È disponibile solo per creare un quorum durante le elezioni. Ad esempio se hai un numero pari di iscritti, è bene aggiungere un arbitro tale che se i voti sono uguali, aggiunga un 1 per fare un membro vincente. Il valore da assegnare deve essere un intero.
• concatenamento_permesso: Questo assume un valore booleano e definisce se gli altri membri secondari devono replicare dagli altri membri secondari se il concatenamento _allowed =true. In caso contrario, se il concatenamento _allowed =false, gli altri membri secondari possono replicare solo dal primario. Il valore predefinito è true.
• election_timeout_secs: per impostazione predefinita il valore è 10000 (prende un valore intero). È il tempo in millisecondi per rilevare quando il nodo primario non è raggiungibile o piuttosto non comunica con gli altri membri, quindi attiva un'elezione. Impostalo su un valore mediano di 12 secondi. Se impostato su un valore troppo alto, ci vorrà molto prima di rilevare il fallimento principale e quindi più tempo per fare un'elezione. Poiché ciò influisce sull'operazione di scrittura, potresti finire per perdere molti dati durante quel periodo. D'altra parte, se è impostato troppo basso, ci saranno frequenti inneschi elettorali anche quando il caso non è così grave e le primarie sono ancora raggiungibili. Di conseguenza, avrai così tanti rollback per le operazioni di scrittura che a un certo punto potrebbero portare a una scarsa integrità o incoerenza dei dati.
• heartbeat_timeout_secs: I set di repliche devono comunicare tra loro prima di un'elezione inviando un segnale denominato battito cardiaco. I membri devono quindi rispondere a questa segnalazione entro un periodo specifico che per impostazione predefinita è impostato su 10 secondi. Heartbeat_timeout_secs è il numero di secondi in cui i membri del set di repliche attendono un heartbeat riuscito l'uno dall'altro e se un membro non risponde, viene contrassegnato come inaccessibile. Tuttavia, questo è applicabile solo per la versione del protocollo 0. Il valore per questo è quindi un numero intero.
• login_host: Questo è l'host che ospita il database di accesso. Per impostazione predefinita, MongoDB è localhost.
• login_database: l'impostazione predefinita è l'amministratore ed è dove vengono archiviate le credenziali di accesso.(prende un valore stringa)
• utente_accesso: il nome utente con cui deve essere eseguita l'autenticazione.(prende un valore stringa)
• password_accesso: la password con cui autenticare l'utente. (prende un valore stringa)
• porta_accesso: Questa è la porta MongoDB a cui l'host può accedere. (prende un valore intero)
• membri: definisce un elenco di membri del set di repliche. È una stringa separata da una virgola o da un elenco yaml, ad esempio mongodb0:27017,mongodb2:27018,mongodb3:27019... Se non è presente alcun numero di porta, viene assunto il 27017.
• versione_protocollo: accetta un numero intero che definisce la versione del processo di replica. O 0 o 1
• set_replica: questo è un valore stringa che definisce il nome del set di repliche.
• ssl: valore booleano che definisce se utilizzare o meno la connessione SSL durante la connessione al database.
• ssl_certs_reqs: questo specifica se è richiesto un certificato dall'altro lato della connessione e se sarà necessario convalidarlo se previsto. Le scelte per questo sono CERT_NONE, CERT_OPTIONAL e CERT_REQUIRED. L'impostazione predefinita è CERT_REQUIRED.
• convalida: accetta un valore booleano che definisce se eseguire una convalida di base sul set di repliche fornito config. Il valore predefinito è true.

Creazione di un set di repliche MongoDB utilizzando Ansible

Ecco un semplice esempio di attività per l'impostazione di una replica impostata in ansible. Chiamiamo questo file task.yaml

# Create a replicaset called 'replica0' with the 3 provided members
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_user: admin
    login_password: root
    replica_set: replica0
    arbiter_at_index:2
    election_timeout_secs:12000
    members:
    - mongodb1:27017
    - mongodb2:27018
    - mongodb3:27019
  when: groups.mongod.index(inventory_hostname) == 0

# Create two single-node replicasets on the localhost for testing
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3001
    login_user: admin
    login_password: root
    login_database: admin
    replica_set: replica0
    members: localhost:3000
    validate: yes

- name: Ensure replicaset replica1 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3002
    login_user: admin
    login_password: secret
    login_database: root
    replica_set: replica1
    members: localhost:3001
    validate: yes

Nel nostro playbook possiamo chiamare le attività come

---
- hosts: ansible-test
  remote_user: root
  become: yes
  Tasks:
- include: tasks.yml

Se lo esegui nel tuo playbook, ansible-playbook -i inventory.txt -c ssh mongodbcreateReplcaSet.yaml, ti verrà presentata una risposta se il set di repliche è stato creato o meno. Se la chiave mongodb_replicaset viene restituita con un valore di successo e una descrizione del set di repliche che è stato creato, allora sei a posto.

Conclusione

In MongoDB generalmente è noioso configurare un set di repliche per le istanze mongod che possono essere ospitate da macchine diverse. Tuttavia, Ansible fornisce una piattaforma semplice per fare lo stesso semplicemente definendo alcuni parametri come discusso sopra. La replica è uno dei processi che garantisce il funzionamento continuo dell'applicazione, quindi dovrebbe essere ben configurato impostando un numero multiplo di membri nel mondo di produzione. Un arbitro viene utilizzato per creare un quorum durante il processo elettorale, quindi dovrebbe essere incluso nel file di configurazione definendo la sua posizione.