I passaggi per rendere un servizio esistente HornetQ JNDI come HA?


177

TL; DR

Quali sono i passaggi per configurare un servizio HA-JNDI con un'impostazione HornetQ? Credo che la documentazione sia un po 'sparsa. Ho letto i documenti qui, ma non sembra illustrare in dettaglio.

Versione più lunga:

Quindi abbiamo una configurazione HornetQ JMS insieme a JNDI. Abbiamo detto 5 server, che eseguono l'istanza master HornetQ JMS con il servizio JNDI su ciascuno. Su ciascuno di questi 5 server, abbiamo anche uno slave in esecuzione per altri master HornetQ.

Illustrare:

Server A - HornetQa_master, JNDI, HornetQb_slave
Server B - HornetQb_master, JNDI, HornetQc_slave
Server C - HornetQc_master, JNDI, HornetQd_slave
Server D - HornetQd_master, JNDI, HornetQe_slave
Server E - HornetQe_master, JNDI, HornetQa_slave

Ognuno di questi server HornetQ funge da middleware per le nostre diverse esigenze di back-end, quindi 5 server, 5 istanze master HornetQ, 5 istanze slave HornetQ e 5 server JNDI. Il problema, tuttavia, con questa configurazione è che se un host del server (non solo il processo, l'host stesso), dice A si interrompe, idealmente il servizio dovrebbe ricadere su HornetQ in esecuzione sul server E che ospita lo slave HornetQ di A. Tuttavia, per riprendere come master HornetQ, HornetQa_slave deve parlare con il processo JNDI in esecuzione sul server A (presumo di replicare i messaggi). Poiché l'host A è inattivo, l'HornetQa_slave in esecuzione su E non ha modo di parlare con JNDI su A, e quindi non può riprendere come processo principale.

Se il servizio JNDI fosse stato altamente disponibile, il processo HornetQ slave potrebbe riprendere come master come previsto. Qualcuno potrebbe gentilmente indicare i documenti o illustrare in semplici passaggi come possiamo convertire la nostra configurazione esistente in un HA-JNDI? Per quello che vale, ho letto più fonti , ma non sembra illustrare in modo molto dettagliato come iniziare a configurare un HA-JNDI. Per favore fatemi sapere se avete bisogno di maggiori informazioni sulla nostra configurazione attuale.


8
Dove sono in esecuzione i tuoi clienti? Sono in esecuzione sulle stesse istanze AS o da un'altra istanza / JVM o entrambi?
jjhavokk,

3
@jjhavokk avrebbero corso su un'altra JVM
gravetii il

4
Potresti abilitare HornetQ in modalità High Availability (replica attiva - passiva)? Abbinalo al rilevamento dinamico del server e dovresti avere un fallback affidabile. Vedi docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/html/… e docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/html/…
diginoise

4
Quale versione di jboss stai eseguendo?
eis,

5
Vedo che questo è davvero vecchio, ma mi chiedo se hai trovato la risposta. Ormai probabilmente sai che l'HA richiede <forward-when-no-consumers> true </forward-when-no-consumers> per propagare i messaggi, ma che il failback da master non funziona. Ho avuto la stessa configurazione in weblogic e websphere in cui funziona il failback, ma non con jboss. C'è qualcosa da impostare per consentire al master di sincronizzare e aggiornare i messaggi persi in modo che funzioni un failback corretto?
user1442498

Risposte:


1

Con l'architettura descritta mi sembra difficile, perché in effetti è necessario riconfigurare lo slave come master e quindi si avrà una certa interruzione.

HornetQ HA viene fornito tramite una coppia di backup dal vivo e il bilanciamento del carico viene fornito tramite un cluster.

Se si desidera disporre sia di HA sia di bilanciamento del carico, saranno necessarie 2 coppie di backup live raggruppate insieme.

Fonte: https://developer.jboss.org/thread/254232

È possibile fare riferimento al master non tramite il nome host ma utilizzando un indirizzo IP virtuale , in modo che nel caso in cui il master sia inattivo, è possibile riconfigurare uno degli slave come master e avviare l'ip virtuale in modo da non dover riconfigurare il resto degli schiavi. (Per mantenere HA anche quando il master è inattivo, si desidera avere 2 slave, in modo da poter riavviare uno di essi come master e ancora uno sarà in esecuzione).

Un altro modo per ottenere lo stesso risultato è con un nome host DNS specifico per il master che è possibile riconfigurare per puntare a un IP diverso se un host è inattivo. Poiché il DNS è memorizzato nella cache, è meglio che queste voci si trovino nel file "hosts".

Se 3 host per dominio HA sono troppi hardware, è possibile farlo più facilmente con i server virtuali senza la necessità di acquistare altro hardware.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.