Come configurare RabbitMQ usando l'architettura Active/Passive High Availability

Question

Sto provando a configurare un cluster di server RabbitMQ, per ottenere code altamente disponibili utilizzando un'architettura server attiva/passiva. Sto seguendo questa guida:

1. http://www.rabbitmq.com/clustering.html
2. http://www.rabbitmq.com/ha.html
3. http://karlgrz.com/rabbitmq-highly-available-queues-and-clustering-using-amazon-ec2/

mia esigenza per l'alta disponibilità è semplice, ho due nodi (CentOS 6.4) con RabbitMQ (v3.2) e Erlang R15B03. Il Nodo1 deve essere "attivo", rispondere a tutte le richieste e il Nodo2 deve essere il nodo "passivo" che ha tutte le code e i messaggi replicati (dal Nodo1).

Per fare questo, ho configurato il seguente:

• Node1 con RabbitMQ lavorando bene in modalità non-cluster
• Nodo2 con RabbitMQ lavorando bene in modalità non-cluster

Il successivamente ho creato un cluster tra entrambi i nodi: unendo Nodo2 a Nodo1 (guida 1). Successivamente ho configurato un criterio per eseguire il mirroring delle code (guida 2), replicando tutte le code e i messaggi tra tutti i nodi del cluster. Funziona, posso collegarmi a qualsiasi nodo e pubblicare o consumare messaggi, mentre entrambi i nodi sono disponibili.

Il problema si verifica quando ho una coda "queueA" che è stata creata sul Nodo1 (master su codaA), e quando Nodo1 viene arrestato, non riesco a connettermi alla codaA nel Nodo2 per produrre o consumare messaggi, Node2 genera un errore che dice che Node1 non è accessibile (penso che la codaA non sia replicata al Nodo2 e che il Nodo2 non possa essere promosso come master della codaA).

L'errore è:

{ "L'operazione di AMQP è stata interrotta: AMQP primo motivo, iniziata da Peer, il codice = 404, text = \" NOT_FOUND - casa nodo 'di coniglio @ node1' di durevole coda 'queueA' in vhost 'app01' è giù o inaccessibile \ "classid = 50, methodId = 10, la causa ="}

La sequenza dei passaggi utilizzati è:

Node1:

1. rabbitmq-server -detached 
2. rabbitmqctl start_app 

Node2:

3. Copy .erlang.cookie from Node1 to Node2 
4. rabbitmq-server -detached 

al cluster (Node2):

5. rabbitmqctl stop_app 
6. rabbitmqctl join_cluster rabbit@node1 
7. rabbitmqctl start_app 

Configura coda politica mirroring:

8. rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' 

Nota: Il modello utilizzato per i nomi delle code è "" (tutte le code).

Quando eseguo "rabbitmqctl list_policies" e "rabbitmqctl cluster_status" è tutto ok.

Perché il Nodo2 non può rispondere se il Nodo1 non è disponibile? C'è qualcosa di sbagliato in questa configurazione?

Answer 1

Nella console di gestione Web, la coda è elencata come Node1 +1?

Sembra che potrebbe esserci qualche problema con la configurazione. Ho un set di vagrant boxes preconfigurato per funzionare in un cluster, potrebbe valere la pena provarlo e identificare problemi nella configurazione?

Answer 2

letto attentamente il vostro riferimento

http://www.rabbitmq.com/ha.html

Si potrebbe utilizzare un cluster di nodi RabbitMQ per costruire il vostro broker RabbitMQ . Ciò sarà resiliente alla perdita dei singoli nodi nei termini della disponibilità complessiva del servizio, ma si applicano alcuni importanti avvertimenti : mentre gli scambi e le associazioni sopravvivono alla perdita di nodi individuali, le code e i loro messaggi no. Questo perché una coda e il suo contenuto risiedono esattamente su un nodo, quindi la perdita di un nodo renderà le sue code non disponibili.

Answer 3

Assicurarsi che la coda non sia duratura o esclusiva.

Dalla documentazione (https://www.rabbitmq.com/ha.html):

code esclusivi verranno eliminati quando la connessione che li ha dichiarato chiuso. Per questo motivo, non è utile per una coda esclusiva da speculare (o durevole per quella materia) poiché quando il nodo lo ospita, la connessione verrà chiusa e la coda verrà rimossa in ogni caso.

Per questo motivo, le code esclusive non vengono mai sottoposte a mirroring (anche se corrispondono a una politica che indica che dovrebbero essere). Non sono nemmeno mai durevoli (anche se dichiarati come tali) .

Dal tuo messaggio di errore:

{ "L'operazione di AMQP è stata interrotta: AMQP primo motivo, iniziata da Peer, il codice = 404, text = \" NOT_FOUND - nodo di casa 'di coniglio @ node1' di coda durevole 'queueA' in vhost 'app01' è giù o inaccessibile \ "classid = 50, methodId = 10, causa ="}

sembra si è creato una coda lunga durata.

Answer 4

Non è stato specificato l'host virtuale (app01) nella chiamata set_policy, pertanto la politica si applicherà solo all'host virtuale predefinito (/). Questa riga di comando dovrebbe funzionare:

rabbitmqctl set_policy -p app01 ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}' 

Answer 5

Solo coda specchio che sono sincronizzati con il master sono promossi ad essere padrone, dopo fallisce. Questo è un comportamento predefinito, ma può essere cambiato in promuovi-on-shutdown sempre.