Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Guida passo passo per l'implementazione di un Cluster RabbitMQ Attivo-Passivo

Scopri come configurare un robusto cluster RabbitMQ Attivo-Passivo per l'alta disponibilità. Questa guida copre la configurazione dei prerequisiti, l'essenziale sincronizzazione del cookie Erlang, l'unione dei nodi del cluster e l'applicazione delle politiche di mirroring (`ha-mode:all`) per garantire la coerenza dei dati e un failover del servizio senza interruzioni quando il nodo attivo si arresta.

40 visualizzazioni

Guida passo-passo per l'implementazione di un cluster RabbitMQ Active-Passive

L'implementazione dell'alta disponibilità (HA) per servizi di messaggistica mission-critical richiede una solida ridondanza. Una configurazione di cluster RabbitMQ Active-Passive è un approccio classico per raggiungere questo obiettivo, garantendo che se il nodo attivo fallisce, un nodo passivo designato possa subentrare rapidamente, minimizzando i tempi di inattività. Questa guida fornisce un processo completo, passo dopo passo, per configurare tale implementazione, coprendo i prerequisiti, la configurazione dei nodi e l'assicurazione di capacità di failover senza interruzioni.

Questo modello di implementazione si basa sul clustering RabbitMQ standard combinato con un meccanismo esterno (come Pacemaker o script semplici) per gestire il rilevamento dell'indirizzo IP in caso di guasto. Per questa guida, ci concentreremo sull'aspetto del clustering RabbitMQ che costituisce la base della configurazione HA.

Prerequisiti per un Cluster Active-Passive

Prima di iniziare la configurazione, assicurarsi che i seguenti prerequisiti siano soddisfatti su tutti i nodi del cluster previsti (Nodo A - Attivo, Nodo B - Passivo):

  1. Versioni Software Identiche: Tutti i nodi devono eseguire la versione esatta di RabbitMQ Server e Erlang/OTP.
  2. Accessibilità di Rete: Tutti i nodi devono essere in grado di comunicare tra loro attraverso le porte necessarie (default 5672 per AMQP, 25672 per il clustering).
  3. Risoluzione Host: Configurare il file /etc/hosts (o il DNS) su tutti i nodi in modo che ciascun nodo possa risolvere in modo affidabile il nome host di tutti gli altri nodi.
  4. Consistenza del Cookie: Il 'magic cookie' di Erlang deve essere identico su tutti i nodi. Questo è fondamentale affinché i nodi si fidino l'uno dell'altro per il clustering.

Il cookie di Erlang determina se i nodi possono comunicare in modo sicuro. Deve essere copiato dal primo nodo inizializzato a tutti gli altri.

Sul Nodo A (Il primo nodo):

Individuare il file cookie (solitamente /var/lib/rabbitmq/.erlang.cookie o ~/.erlang.cookie a seconda del metodo di installazione) e copiarne il contenuto.

Sul Nodo B (e nodi successivi):

  1. Interrompere il servizio RabbitMQ:
    bash sudo systemctl stop rabbitmq-server
  2. Sostituire il file cookie esistente con il contenuto copiato dal Nodo A, assicurando i permessi corretti (solitamente 400).
    bash # Esempio utilizzando echo (sostituire il contenuto come necessario) echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie
  3. Avviare il servizio sul Nodo B:
    bash sudo systemctl start rabbitmq-server

Passaggio 1: Configurazione dei Nomi Host e della Rete

Assicurarsi che i file host su entrambi i Nodi A e B mappino correttamente i loro nomi host.

Esempio di /etc/hosts (su entrambi i server):

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

Passaggio 2: Inizializzazione del Primo Nodo del Cluster (Attivo)

Il Nodo A sarà il nodo primario iniziale, dove viene stabilito per primo il cluster.

  1. Avviare il servizio sul Nodo A (se non è già in esecuzione):
    bash sudo systemctl start rabbitmq-server
  2. Verificare lo Stato: Assicurarsi che il nodo funzioni correttamente.
    bash rabbitmqctl status

Passaggio 3: Aggiunta del Secondo Nodo (Passivo) al Cluster

Ora, istruiamo il Nodo B ad unirsi al cluster guidato dal Nodo A.

  1. Interrompere il Servizio sul Nodo B (se in esecuzione):
    bash sudo systemctl stop rabbitmq-server

  2. Comando di Unione: Eseguire il comando di unione sul Nodo B, specificando il nome host del Nodo A come peer.
    bash rabbitmqctl join_cluster rabbit@rabbitmq-node-a
    Suggerimento: Utilizzare il nome host definito in /etc/hosts.

  3. Avviare il Servizio sul Nodo B:
    bash sudo systemctl start rabbitmq-server

Passaggio 4: Verifica della Formazione del Cluster

Accedere al Nodo A e verificare che entrambi i nodi si riconoscano.

rabbitmqctl cluster_status

Estratto dell'Output Previsto:

Si dovrebbero vedere sia rabbitmq-node-a che rabbitmq-node-b elencati sotto running_nodes.

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

Passaggio 5: Configurazione dell'Alta Disponibilità (Accodamento di Code in Cluster)

Il clustering RabbitMQ standard consente ai nodi di condividere metadati (utenti, exchange), ma i messaggi residenti nelle code tipicamente non vengono replicati automaticamente a meno che non vengano applicate specifiche policy HA. Per un vero failover Active-Passive, devono essere utilizzate le code specchiate (mirrored queues).

Definizione della Policy

Una policy viene applicata alle code che corrispondono a specifici modelli per definire quante copie della coda dovrebbero esistere nel cluster e dove dovrebbero essere promosse.

Utilizzare il comando rabbitmqctl set_policy su uno dei nodi per forzare lo mirroring su tutto il cluster ("^").

```bash

Imposta una policy denominata 'ha-all' che specchia le code corrispondenti a qualsiasi nome ('^')

a tutti i nodi del cluster (3 nodi totali) e imposta il comportamento 'promote'.

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"'