Quando si progetta la rete
WebSphere MQ
sottostante al dominio broker
WebSphere Message Broker, considerare
la possibilità di utilizzare i cluster.
L'utilizzo di cluster del gestore code apporta i seguenti
vantaggi:
- Amministrazione del sistema ridotta
I cluster necessitano di minori definizioni per stabilire una
rete; è possibile impostare e modificare la rete più rapidamente e facilmente.
- Maggiore disponibilità e bilanciamento del carico di lavoro
Si possono ottenere dei vantaggi definendo
istanze della stessa coda in più di un gestore code, distribuendo quindi il carico di lavoro nel cluster.
Se si utilizzano i cluster con WebSphere Message Broker,
considerare quanto segue:
- Per le code SYSTEM.BROKER:
- Le code SYSTEM.BROKER vengono definite quando si creano i componenti WebSphere Message Broker
e non vengono definite come code cluster. Non modificare questo attributo.
- Per la connettività del broker, di Gestione configurazione e del Server nomi utente:
- Se si definiscono i gestori code che supportano i broker, Gestione configurazione
e il Server nomi utente in un cluster, si possono godere i vantaggi dell'amministrazione
semplificata fornita dai cluster WebSphere MQ.
Questo potrebbe rivelarsi particolarmente importante per i broker in un collettivo, che
devono avere tutti le interconnessioni WebSphere MQ.
- Per le code di input del flusso di messaggi:
- Se si definisce una coda di input come coda cluster, considerare le implicazioni
relative all'ordine dei messaggi o dei segmenti di un messaggio segmentato. Le implicazioni sono le stesse
di qualsiasi coda cluster WebSphere MQ. In particolare, l'applicazione deve assicurare che,
se sta inviando messaggi segmentati, tutti i segmenti saranno elaborati dalla stessa coda di destinazione e quindi dalla
stessa istanza del flusso di messaggi nello stesso broker.
- Per le code di output del flusso di messaggi:
-
- WebSphere Message Broker specifica sempre MQOO_BIND_AS_Q_DEF
quando apre una coda per l'output. Se si prevede che messaggi segmentati vengano
inseriti in una coda di output o si desidera che una serie di messaggi venga gestita dalla stessa
elaborazione, è necessario specificare DEFBIND(OPEN) quando si definisce quella coda. Questo assicura che tutti
i segmenti di un singolo messaggio o tutti i messaggi nella sequenza, siano inseriti
nella stessa coda di destinazione e siano elaborati dalla stessa istanza dell'applicazione
di destinazione.
- Se si creano i propri nodi di output, specificare MQOO_BIND_AS_Q_DEF quando si apre
la coda di output e DEFBIND(OPEN) quando si definisce la coda, se è necessario garantire
l'ordine dei messaggi o per assicurare una singola destinazione per i messaggi
segmentati.
- Per pubblicazione/sottoscrizione:
-
- Se la coda di destinazione per una pubblicazione è una coda cluster, è necessario distribuire il flusso di
messaggi di pubblicazione/sottoscrizione a tutti i broker presenti sui gestori code nel
cluster. Tuttavia, il cluster non fornisce alcuna funzione di
failover alla topologia e alla funzionalità del dominio broker. Se un
broker su cui è pubblicato un messaggio o su cui si registra un sottoscrittore, non è disponibile,
la distribuzione della pubblicazione o della registrazione non viene presa in carico da un altro
broker.
- Quando un client registra una sottoscrizione con un broker in esecuzione su un gestore
code membro di un cluster, il broker inoltra una registrazione proxy ai neighbor
all'interno del dominio broker; i dettagli della registrazione non
vengono resi noti ad altri membri del cluster.
- Un client potrebbe scegliere di diventare un sottoscrittore organizzato in cluster, in modo che
la propria coda sottoscrittore faccia parte di una serie di code organizzate in cluster che riceve qualsiasi
pubblicazione specificata. In questo caso, quando si registra una sottoscrizione, utilizzare il nome di un gestore code
"immaginario" associato al cluster;
questo non è il gestore code a cui verrà inviata la pubblicazione, ma un alias ad uso del
broker. Come attività amministrativa, viene effettuata la definizione di un alias
gestore code vuoto per questo gestore code sul broker che soddisfi questa sottoscrizione
per tutti i sottoscrittori organizzati in cluster. Quando il broker
pubblica in una coda sottoscrittore che denomina questo gestore code, la risoluzione del nome del
gestore code ha come effetto l'invio della pubblicazione a qualsiasi gestore code che ospiti la
coda cluster del sottoscrittore e solo un sottoscrittore organizzato in cluster riceve la
pubblicazione.
Ad esempio, se una coda organizzata in cluster fosse
SUBS_QUEUE e il gestore code "immaginario" del sottoscrittore fosse CLUSTER_QM,
la definizione del broker dovrebbe essere:
DEFINE QREMOTE(CLUSTER_QM)
RQMNAME(' ') RNAME(' ')
Questo invia le pubblicazioni broker per
SUBS_QUEUE su CLUSTER_QM a un'istanza della coda cluster denominata SUBS_QUEUE
ovunque nel cluster.
Per comprendere meglio i cluster e le implicazioni dell'utilizzo
delle code cluster, consultare il manuale WebSphere MQ Queue
Manager Clusters.