Suggerimenti per il clustering

Potrebbe essere necessario apportare alcune modifiche ai propri sistemi o applicazioni prima di utilizzare il clustering. Ci sono sia somiglianze che differenze dal comportamento dell'accodamento distribuito.

• È necessario aggiungere definizioni di configurazione manuali ai gestori code all'esterno di un cluster per accedere alle code cluster.
• Se si uniscono due cluster con lo stesso nome, non è possibile separarli di nuovo. Pertanto, è consigliabile assegnare a tutti i cluster un nome univoco.
• Se un messaggio arriva a un gestore code ma non vi è alcuna coda per riceverlo, il messaggio viene inserito nella coda di messaggi non recapitabili. Se non è presente una coda di messaggi non recapitabili, il canale ha esito negativo e riprova. L'utilizzo della coda di messaggi non recapitabili è uguale a quello della coda distribuita.
• L'integrità dei messaggi persistenti viene mantenuta. I messaggi non vengono duplicati o persi come risultato dell'utilizzo dei cluster.
• L'utilizzo di cluster riduce la gestione del sistema. I cluster semplificano la connessione di reti più grandi con molti più gestori code di quanti ne sarebbero in grado di considerare l'utilizzo dell'accodamento distribuito. Esiste il rischio che si consumino risorse di rete eccessive se si tenta di abilitare la comunicazione tra ogni gestore code in un cluster.
• Se si utilizza IBM® MQ Explorer, che presenta i gestori code in una struttura ad albero, la vista per cluster di grandi dimensioni potrebbe essere ingombrante.
• Lo scopo delle liste di distribuzione è quello di utilizzare un unico comando MQPUT per inviare lo stesso messaggio a più destinazioni. Gli elenchi di distribuzione sono supportati su IBM MQ for Multiplatforms. È possibile utilizzare gli elenchi di distribuzione con i cluster dei gestori code. In un cluster, tutti i messaggi vengono espansi all'ora MQPUT . Il vantaggio, in termini di traffico di rete, non è così grande come in un ambiente non cluster. Il vantaggio delle liste di distribuzione è che i numerosi canali e code di trasmissione non devono essere definiti manualmente.
• Se stai per utilizzare i cluster per bilanciare il tuo carico di lavoro, esamina le tue applicazioni. Verificare se i messaggi devono essere elaborati da un particolare gestore code o in una particolare sequenza. Si dice che tali applicazioni abbiano affinità di messaggi. Potrebbe essere necessario modificare le applicazioni prima di poterle utilizzare in cluster complessi.
• È possibile scegliere di utilizzare l'opzione MQOO_BIND_ON_OPEN su un MQOPEN per forzare l'invio di messaggi a una destinazione specifica. Se il gestore code di destinazione non è disponibile, i messaggi non vengono consegnati fino a quando il gestore code non diventa nuovamente disponibile. I messaggi non vengono instradati a un altro gestore code a causa del rischio di duplicazione.
• Se un gestore code deve ospitare un repository del cluster, è necessario conoscerne il nome host o l'indirizzo IP. È necessario specificare queste informazioni nel parametro CONNAME quando si crea la definizione CLUSSDR su altri gestori code che si uniscono al cluster. Se si utilizza DHCP, l'indirizzo IP è soggetto a modifica perché DHCP può assegnare un nuovo indirizzo IP ogni volta che si riavvia un sistema. Pertanto, non è necessario specificare un indirizzo IP nelle definizioni CLUSSDR . Anche se tutte le definizioni CLUSSDR specificano il nome host piuttosto che l'indirizzo IP, le definizioni non sarebbero comunque affidabili. DHCP non aggiorna necessariamente la voce della directory DNS per l'host con il nuovo indirizzo. Se è necessario denominare i gestori code come repository completi sui sistemi che utilizzano DHCP, installare il software che garantisce l'aggiornamento della directory DNS.
• Non utilizzare nomi generici, ad esempio risorse generiche VTAM o nomi generici DDNS (Dynamic Domain Name Server) come nomi di connessione per i propri canali. In tal caso, i canali potrebbero connettersi a un gestore code diverso da quello previsto.
• È possibile richiamare solo un messaggio da una coda cluster locale, ma è possibile inserire un messaggio in qualsiasi coda in un cluster. Se si apre una coda per utilizzare il comando MQGET , il gestore code apre la coda locale.
• Non è necessario modificare alcuna delle applicazioni se si imposta un cluster IBM MQ semplice. L'applicazione può denominare la coda di destinazione sulla chiamata MQOPEN e non ha bisogno di conoscere l'ubicazione del gestore code. Se si configura un cluster per la gestione del carico di lavoro, è necessario esaminare le applicazioni e modificarle come necessario.
• È possibile visualizzare i dati di monitoraggio e di stato correnti per un canale o una coda utilizzando i comandi DISPLAY CHSTATUS e DISPLAY QSTATUS runmqsc . Le informazioni di monitoraggio possono essere utilizzate per misurare le prestazioni e lo stato del sistema. Il monitoraggio è controllato dagli attributi gestore code, coda e canale. Il monitoraggio dei canali mittenti del cluster definiti automaticamente è possibile con l'attributo del gestore code MONACLS .