Utilizzo delle code cluster WebSphere MQ per input e output

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:

  1. Amministrazione del sistema ridotta

    I cluster necessitano di minori definizioni per stabilire una rete; è possibile impostare e modificare la rete più rapidamente e facilmente.

  2. 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.

Concetti correlati
Panoramica dei flussi di messaggi
Attività correlate
Progettazione di un flusso di messaggi
Utilizzo delle code condivise WebSphere MQ per input e output (z/OS)
Creazione di un flusso di messaggi
Definizione del contenuto del flusso di messaggi
Riferimenti correlati
Nodi integrati
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac00365_