Guida Passo-Passo per Distribuire un Cluster RabbitMQ Attivo-Passivo

L'alta disponibilità di RabbitMQ richiede più di due server che possono vedersi. Hai bisogno di clustering per metadati condivisi, code replicate per la disponibilità dei messaggi e un percorso di failover chiaro per i client.

Questa guida mostra il lato RabbitMQ di una distribuzione in stile attivo-passivo. Il failover del client di solito proviene da un bilanciatore di carico, un cambio DNS, un service discovery o un IP virtuale gestito al di fuori di RabbitMQ.

Prerequisiti per un Cluster Attivo-Passivo

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

Versioni Software Compatibili: Mantieni allineate le versioni di RabbitMQ Server e Erlang/OTP tra i nodi. In pratica, esegui la stessa versione di RabbitMQ su ogni nodo a meno che tu non stia seguendo il percorso di aggiornamento progressivo documentato da RabbitMQ.
Accessibilità di Rete: I nodi devono comunicare sulle porte AMQP utilizzate dai client, sulla porta di distribuzione utilizzata per il clustering e su qualsiasi porta di gestione o TLS che abiliti.
Risoluzione Host: Configura il file /etc/hosts (o DNS) su tutti i nodi in modo che ogni nodo possa risolvere in modo affidabile il nome host di tutti gli altri nodi.
Consistenza del Cookie: Il 'cookie magico' Erlang deve essere identico su tutti i nodi. Questo è cruciale affinché i nodi si fidino l'uno dell'altro per il clustering.

Stabilire la Consistenza del Cookie

Il cookie 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):

Individua il file del cookie (di solito /var/lib/rabbitmq/.erlang.cookie o ~/.erlang.cookie a seconda del metodo di installazione) e copia il suo contenuto.

Sul Nodo B (e nodi successivi):

Ferma il servizio RabbitMQ:
```
sudo systemctl stop rabbitmq-server
```

Sostituisci il file del cookie esistente con il contenuto copiato dal Nodo A, assicurando i permessi corretti (di solito 400).

# Esempio usando echo (sostituisci il contenuto secondo necessità)
echo "YOUR_LONG_COOKIE_STRING" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

Avvia il servizio sul Nodo B:
```
sudo systemctl start rabbitmq-server
```

Passo 1: Configurazione dei Nomi Host e della Rete

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

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

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

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

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

Avvia il servizio sul Nodo A (se non è già in esecuzione):
```
sudo systemctl start rabbitmq-server
```
Verifica lo Stato: Assicurati che il nodo sia in esecuzione correttamente.
```
rabbitmqctl status
```

Passo 3: Unione del Secondo Nodo (Passivo) al Cluster

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

Ferma l'applicazione RabbitMQ sul Nodo B mantenendo disponibile il nodo Erlang:
```
sudo rabbitmqctl stop_app
```
Reimposta lo stato locale del Nodo B se è già stato inizializzato come nodo autonomo:
```
sudo rabbitmqctl reset
```
Comando di Unione: Esegui il comando di unione sul Nodo B, specificando il nome host del Nodo A come peer.
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
Consiglio: Usa il nome host definito in /etc/hosts.
Avvia l'applicazione RabbitMQ sul Nodo B:
```
sudo rabbitmqctl start_app
```

Passo 4: Verifica della Formazione del Cluster

Accedi al Nodo A e verifica che entrambi i nodi si riconoscano a vicenda.

rabbitmqctl cluster_status

Estratto di Output Previsto:

Dovresti 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]},
 ...
]

Passo 5: Configurazione dell'Alta Disponibilità per le Code

Il clustering standard di RabbitMQ condivide metadati come utenti, exchange, binding e policy. I contenuti delle code necessitano di un tipo di coda replicata se vuoi che i messaggi sopravvivano al guasto del nodo.

Per distribuzioni RabbitMQ moderne, usa code di quorum per code durevoli replicate. Le code mirrorate classiche utilizzavano politiche ha-mode nelle versioni precedenti di RabbitMQ, ma questo approccio è deprecato e rimosso dalle versioni principali più recenti.

Dichiarare una Coda di Quorum

Puoi dichiarare code di quorum dalla tua applicazione o con rabbitmqadmin. Questo esempio crea una coda di quorum durevole:

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

Per laboratori a due nodi, una coda di quorum può funzionare, ma non può tollerare la perdita di un nodo e mantenere ancora una maggioranza. Per la produzione, usa almeno tre nodi RabbitMQ per le code di quorum in modo che un nodo possa fallire mentre la coda ha ancora una maggioranza.

Passo 6: Test del Failover

Prima di dichiarare il cluster pronto, testa il percorso che i tuoi client utilizzeranno:

Pubblica alcuni messaggi di test persistenti su una coda di quorum.
Ferma l'applicazione RabbitMQ del nodo attivo con sudo rabbitmqctl stop_app.
Conferma che i client si riconnettano tramite il tuo bilanciatore di carico, target DNS o configurazione di service discovery.
Consuma i messaggi di test dal nodo sopravvissuto.
Avvia di nuovo l'applicazione fermata con sudo rabbitmqctl start_app e controlla rabbitmqctl cluster_status.

Conclusione Finale

Il clustering RabbitMQ ti fornisce metadati del broker condivisi, ma la disponibilità delle code dipende dal tipo di coda e dal design del failover del client. Usa code di quorum per code durevoli replicate, mantieni almeno tre nodi per una vera tolleranza ai guasti e testa il failover con lo stesso percorso di connessione utilizzato dalle tue applicazioni.