Cluster Websphere MQ

Question

Sono abbastanza nuovo su websphere MQ, quindi scusatemi se non sto usando i termini giusti. Stiamo facendo un progetto in cui abbiamo bisogno di configurare un cluster MQ per l'alta disponibilità.

L'applicazione client mantiene un pool di connessione con il gestore code per gli abbonati e gli editori. Supponiamo di avere due gestori code in un cluster che ospita le code con gli stessi nomi. Ciascuna coda ha il proprio insieme di sottoscrittori e editori che vengono memorizzati nella cache dall'applicazione client. Supponiamo che uno dei gestori di code si spenga, i sottoscrittori e gli editori delle code su quel gestore code moriranno rendendo gli oggetti sull'applicazione client defunti.

In questo caso possono essere presi in considerazione i seguenti scenari?

1] Quando primi crash queueManager, i messaggi sulle sue code sono trasferiti ad altre QueueManager nel cluster

2] Quando QueueManager si ripropone, non v'è alcun meccanismo per ripristinare gli editori e gli abbonati. Attualmente abbiamo scritto un thread di ripristino automatico nell'applicazione client che tenta di ricollegare i publisher e gli abbonati non riusciti. Ma in caso di configurazione del cluster, temiamo che gli editori e gli abbonati si ricollegheranno all'altro qmanager in esecuzione. E quando viene ripristinato il queuemanager arrestato, non ci saranno editori e sottoscrittori.

Qualcuno può spiegare come gestire questi due scenari?

Answer 1

Per aggiungere alla risposta di Shashi, per ottenere il massimo dal clustering WMQ è necessario disporre di un hop di rete tra mittenti e destinatari di messaggi. Il clustering WMQ riguarda il modo in cui QMgrs parla tra loro. Non ha nulla a che fare con il modo in cui le app client comunicano con QMgrs e non replicano i messaggi. In un cluster quando un messaggio deve passare da un QMgr a un altro, il cluster individua dove indirizzarlo. Se esistono più istanze cluster di una singola coda di destinazione, il messaggio può essere indirizzato a una di esse. Se non vi è alcun hop di rete tra mittenti e destinatari, i messaggi non devono lasciare il QMGR locale e pertanto il comportamento del cluster WMQ non viene mai richiamato, anche se i MQQ coinvolti possono partecipare al cluster.

In un'architettura di cluster WMQ convenzionale, tutti i ricevitori ascoltano su più istanze della stessa coda, con lo stesso nome, distribuiti su più QMgr. I mittenti hanno uno o più QMgrs in cui possono connettersi e inviare richieste (fire-and-forget), probabilmente in attesa di risposte (richiesta-risposta). Poiché i destinatari dei messaggi forniscono alcuni servizi, chiamo i loro QMgrs "QMgrs del provider di servizi". I messaggi di posta elettronica in cui i mittenti dei messaggi vengono trasmessi sono MMS di tipo "Consumatore di servizi" perché queste app sono consumatori di servizi.

La diapositiva di seguito è tratta da una presentazione che utilizzo sugli incarichi di consulenza di WMQ Architecture.

Nota che i consumatori dei servizi - le cose che inviano messaggi di richiesta - failover. Le cose che ascoltano le code degli endpoint di servizio e forniscono servizi NON falliscono. Ciò è dovuto alla necessità di assicurarsi che ogni coda di endpoint del servizio attivo sia sempre servita. In genere, ciascuna istanza dell'app contiene un handle di input su due o più istanze di coda. In questo modo un QMgr può andare giù e tutte le istanze delle app rimangono attive. Se un'istanza dell'app si interrompe, alcune altre istanze di app continuano a funzionare con le sue code. Questa affinità dei provider di servizi per QMgr specifici abilita anche la transazionale XA se necessario.

Il modo migliore che ho trovato per spiegare WMQ HA è una diapositiva dalla conferenza IMPACT:

Un WebSphere MQ gruppo assicura che un servizio rimane a disposizione, anche se un'istanza di un cluster la coda potrebbe non essere disponibile. I nuovi messaggi nel cluster verranno indirizzati alle istanze della coda rimanenti. Un cluster hardware o multi-istanza QMgr (MIQM) consente l'accesso ai messaggi esistenti. Quando un lato della coppia attivo/passivo scende, c'è una breve interruzione su quel QMgr solo mentre si verifica il failover, quindi il nodo secondario prende il sopravvento e rende nuovamente disponibili i messaggi sulle code. Una rete che combina cluster WMQ e cluster hardware/MIQM offre il più alto livello di disponibilità.

Ricordare che in nessuna di queste configurazioni i messaggi vengono replicati attraverso i nodi. Un messaggio WMQ ha sempre una singola posizione fisica. Per ulteriori informazioni su questo aspetto, vedere Thoughts on Disaster Recovery.

Answer 2

WMQ Il clustering è un argomento avanzato. È necessario innanzitutto eseguire una buona quantità di letture di WMQ e capire cosa si intende per clustering nel mondo WMQ prima di tentare qualsiasi cosa.

WMQ Cluster differisce in molti modi dai cluster tradizionali. A differenza dei cluster tradizionali, ad esempio in un cluster attivo/passivo, i dati verranno condivisi tra istanze attive e passive di un'applicazione. In qualsiasi momento, l'istanza attiva dell'applicazione elaborerà i dati. Quando l'istanza attiva si interrompe, l'istanza passiva subentra e inizia l'elaborazione. Questo non è il caso dei cluster WMQ in cui i gestori code in un cluster sono univoci e quindi le code/gli argomenti ospitati da quei gestori code non sono condivisi. È possibile avere le stesse code/argomenti in entrambi i gestori code, ma poiché i gestori code sono diversi, i messaggi, gli argomenti, gli abbonamenti non verranno condivisi.

Rispondere alle vostre domande.
1) No. I messaggi, se persistenti, rimarranno nel gestore code arrestato. Non saranno trasferiti ad altri gestori code. Poiché il gestore code stesso non è disponibile, non è possibile eseguire nulla finché non viene richiamato il gestore code.
2) No. Il gestore code non può farlo. È compito dell'applicazione verificare la disponibilità del gestore code e riconnettersi. WMQ fornisce funzionalità di riconnessione automatica del client, in cui le librerie client WMQ si riconnettono automaticamente al gestore code quando rilevano errori di connessione interrotti. Questa funzione è disponibile da WMQ v7.xe versioni successive con client C e Java. Il client C# supporta la funzionalità di v7.1.

Per i requisiti di elevata disponibilità, è possibile utilizzare la funzione di gestione code di istanze multiple di WMQ. Questa funzione abilita istanze attive/passive dello stesso gestore code in esecuzione su due macchine diverse. L'istanza attiva del gestore code gestirà le connessioni client mentre l'istanza passiva si troverà in modalità sospensione. Entrambe le istanze condivideranno dati e registri. Quando l'istanza attiva si interrompe, l'istanza passiva diventa attiva. Avrai accesso a tutti i messaggi persistenti presenti nelle code prima che il gestore code attivo si arrestasse.

Leggere l'InfoCenter di WMQ per ulteriori informazioni sul gestore code di istanze multiple.