Scenari di Business Process Choreographer per l'organizzazione in cluster

Descrive le diverse opzioni di configurazione per gli scenari di Business Process Choreographer che utilizzano i cluster.

Di seguito sono riportati i vantaggi principali dell'utilizzo dei cluster di WebSphere® Process Server per le istanze di Business Process Choreographer (BPC):

Opzioni di configurazione

E' possibile configurare Process choreographer in molti modi diversi, per cui le configurazioni dei cluster sono di solito molto complesse. Alcune delle opzioni principali da considerare prima di avviare la creazione dei server delle applicazioni sono tracciate nelle seguenti descrizioni:

Numero di nodi nella cella di WebSphere Process Server
Uno o più. Tutti i novi vengono gestiti da un singolo gestore distribuzioni.
Numero di nodi in ciascun cluster di WebSphere Process Server
Uno o più. L'organizzazione orizzontale in cluster orizzontale WebSphere può aumentare la disponibilità del servizio e la capacità di carico di lavoro complessiva.
Numero di server delle applicazioni presenti in ogni nodo
Uno o più. L'organizzazione verticale in cluster di WebSphere Process Server può aumentare l'utilizzo della risorsa.
Host database
  • Remoto, su un server dedicato
  • Locale su uno dei server delle applicazioni presenti nel cluster
Si consiglia di collocare il database su un server dedicato, preferibilmente con hot standby.
Code della messaggistica applicazione
  • Code locali
  • Code remote
Connessione (messaggistica predefinita)
Quando viene utilizzata la messaggistica predefinita, è possibile configurare i motori del messaggi nello stesso cluster o in un cluster remoto. Per Business Process Choreographer, è necessario utilizzare lo stesso approccio utilizzato per gli altri componenti di WebSphere Process Server. Per ulteriori dettagli sugli scenari possibili, consultare l'argomento Preparazione di un server o di un cluster al supporto delle applicazioni di servizio. La configurazione consigliata è di disporre dei motori di messaggistica in esecuzione su un cluster diverso rispetto al cluster in cui è installato Business Process Choreographer. Pertanto, è simile alla configurazione del gestore code centrale che può essere utilizzato con WebSphere MQ.
Connessione (Gestori code WebSphere MQ)
  • Un gestore code centrale (remoto) che ospita le code per i server delle applicazioni all'interno di un cluster. Questa configurazione è generalmente consigliata.
  • Un gestore cose locale per server delle applicazioni. Questo approccio non consente il failover e la condivisione del carico di lavoro interno al processo.
  • Due gestori code locali per nodo e l'organizzazione in cluster di WebSphere MQ per bilanciare il carico di tra i vari server dell'applicazione.

    Una distribuzione del carico di lavoro tra varie istanze di Business Process Choreographer richiede che i gestori code utilizzati dal contenitore business processo di ciascun server dell'applicazione siano membri dello stesso cluster di WebSphere MQ. Questa configurazione non fornisce failover, quindi, in genere, non è consigliata.

WebSphere MQ non è consigliato come provider JMS se viene utilizzato uno scenario organizzato in cluster.
Sistema del database
E' possibile utilizzare uno qualsiasi dei database supportati tranne Cloudscape.
Server in hot standby
Sono disponibili le seguenti opzioni per i server in hot standby:
  • Nessuna
  • Per il database
  • Per un Gestore code centrale

Tipi di cluster: questo argomento fa riferimento a due diversi tipi di cluster. Un cluster di WebSphere raggruppa i server dell'applicazione per condividere il carico di lavoro ed incrementare la disponibilità del servizio. Un cluster di WebSphere MQ, precedentemente noto come cluster MQSeries® raggruppa i gestori code WebSphere MQ e può essere utilizzato per ottenere un bilanciamento del carico di lavoro interno ai processi.

Alta disponibilità

Per raggiungere un'elevata disponibilità dei servizi di Business Process Choreographer, è bene considerare gli elementi seguenti:

Raggruppamento verticale in cluster per portare al massimo l'utilizzo delle risorse

Per migliorare le prestazioni, si potrebbero creare più istanze di server delle applicazioni sullo stesso nodo in modo che sia possibile per Business Process Choreographer utilizzare le risorse di sistema disponibili.

La condivisione del carico di lavoro

Se si desidera che istanze diverse di Business Process Choreographer condividano gli stessi carichi di lavoro, è necessari che utilizzino una delle seguenti configurazioni del gestore code:
Gestore code centrale
Un gestore code centrale ospita le code necessarie per Business Process Choreographer. Tutte le istanze Business Process Choreographer nel cluster di WebSphere leggono dalle stesse code.
Cluster di WebSphere MQ
Ogni server delle applicazioni dispone di due gestori code. Un gestore code ospita le code locali ed è utilizzato per ottenere i messaggi, l'altro gestore code non ospita alcuna coda ed è utilizzato solo per i messaggi in uscita. Tutti i gestori code delle istanze Business Process Choreographer nel cluster WebSphere diventano membri del cluster WebSphere MQ.

Il risultato di inserire gestori code che non ospitano code è che i messaggi vengono distribuiti attraverso tutti i gestori code in arrivo. Una volta utilizzata la procedura guidata di installazione per installare e configurare il contenitore processi aziendali sul cluster, è necessario modificare manualmente le due produzioni connessioni per server delle applicazioni in modo da puntare ai gestori code locali in arrivo ed in uscita.

Database Business Process Choreographer

Si consiglia di collocare il database su un server dedicato, preferibilmente con hot standby. Il database può trovarsi su un server che si trova all'esterno della cella di WebSphere, tuttavia il gestore distribuzione deve disporne dell'accesso.

Quando si pianifica il database, è bene considerare i punti seguenti:

Provider JMS di messaggistica predefinito di WebSphere

Business Process Choreographer può utilizzare la messaggistica predefinita di WebSphere, che supporta l'organizzazione in cluster, la gestione del carico di lavoro e il failover.

Di seguito sono riportate le topologie supportate:
  • Le risorse di messaggistica si trovano su un cluster diverso rispetto alle applicazioni. Questa è la topologia consigliata, poiché fornisce le capacità di failover con minimi costi di gestione. Questa topologia è simile all'approccio del gestore code centrale nel caso di WebSphere MQ.
  • Le risorse di messaggistica e le applicazioni si trovano sullo stesso cluster. Questa topologia è ideale per elevate prestazioni, sebbene richieda un maggiore impegno di gestione, in particolare quando vengono applicate le modifiche.

Per ulteriori informazioni sulle considerazioni che si applicano quando viene utilizzata la messaggistica predefinita, fare riferimento all'argomento Creazione di un ambiente organizzato in cluster.

WebSphere MQ

Business Process Choreographer (BPC) può utilizzare le code WebSphere MQ per ricevere le richieste ed inviare le risposte. WebSphere MQ non è consigliato come provider JMS se viene utilizzato uno scenario organizzato in cluster. Se si utilizza WebSphere MQ per BPC, è necessario configurare anche la messaggistica predefinita per SCA (Service Component Architecture), utilizzata da BPC per il richiamo del servizio in entrata ed in uscita. Ciascun server dell'applicazione in cui si trova Business Process Choreographer richiede una delle seguenti opzioni:

Gestore code centrale

Utilizzando un gestore code centrale per tutte le code si facilita la gestione. Un gestore code viene utilizzato da tutti i contenitori clonati per le human task ed i processi aziendali. Tuttavia, l'utilizzo di un gestore code ventrale crea un punto di errore singolo che è necessario venga ospitato su un sistema ad elevata disponibilità.

La figura di seguito riportata illustra tutti i server dell'applicazione in un cluster WebSphere che utilizza un gestore code centrale singolo su un altro server. E' possibile che ogni server delle applicazioni mostrato con un contenitore di processi aziendali disponga di un contenitore human task.

Questa figura illustra tutti i server dell'applicazione nel cluster WebSphere che utilizzano un gestore code centrale singolo su un altro server.

Gestore code locale senza organizzazione in cluster di WebSphere MQ

Questo esempio presenta la configurazione standard autonoma di Business Process Choreographer. Ogni contenitore di processi aziendali dispone di un gestore code. Questo approccio non consente una condivisione del carico di lavoro né la disponibilità del servizio di failover.

Organizzazione in cluster di WebSphere MQ

Questa tecnica complessa non è consigliata. Supporta la condizione del carico di lavoro per i servizi di Business Process Choreographer in un cluster di WebSphere. I processi business nel cluster devono essere tutti eseguiti solo su stazioni di lavoro UNIX® o su Windows®, una combinazione di stazioni di lavoro UNIX e Windows non funziona.

Ogni server delle applicazioni richiede due gestori code locali, uno per i messaggi in uscita ed uno per quelli in entrata. Tutti i gestori code diventano membri dello stesso cluster di WebSphere MQ. Sui sistemi Windows, tutti i gestori code devono utilizzare lo stesso protocollo di bind. Sui sistemi UNIX, i gestori code put e get devono utilizzare protocolli diversi. Ad esempio, è possibile modificare le produzioni connessioni delle code in modo che tutti i gestori code in uscita utilizzino il protocollo di collegamento(comunicazioni tra processi) e tutti i gestori code in entrata utilizzino il protocollo client (TCP/IP) predefinito.

Su sistemi Windows e UNIX, l'utilizzo del tipo di trasmissione di bind locale è circa del 5% più veloce rispetto al tipo di trasmissione del client, ma è necessario arrestare l'intero server dell'applicazione per arrestare il gestore code locale WebSphere MQ.

Ciascun contenitore business process nel cluster WebSphere deve essere personalizzato per riflettere i relativi gestori code.

Si consiglia che più di un gestore code nel cluster di WebSphere MQ sia disposto come archivio di cluster.

La figura di seguito riportata illustra il modo in cui i gestori code utilizzati dai server dell'applicazione vengono raggruppati insieme in un cluster WebSphere MQ. Il cluster WebSphere MQ dei gestori code è parallelo al cluster di WebSphere dei server dell'applicazione. Le richieste vengono condivise attraverso le code in entrata presenti nel cluster.

La figura illustra il modo in cui i gestori code utilizzati dai server dell'applicazione vengono raggruppati insieme in un cluster WebSphere MQ parallelo al cluster WebSphere dei server dell'applicazione. Le richieste vengono condivise tra le code in entrata nel cluster.

Come viene creato un cluster WebSphere

Sono disponibili diverse sequenze per creare un cluster per Process choreographer. Si consiglia questa sequenza:

  1. Creare un cluster utilizzando la maschera defaultProcessServer come maschera del server per i membri del cluster.
  2. Aggiungere i membri al cluster.
  3. Abilitare il cluster per le applicazioni del servizio.
  4. Configurare Business Process Choreographer sul cluster.
  5. Se si utilizza WebSphere MQ e la configurazione WebSphere MQ è un cluster WebSphere MQ dei gestori code locali, è necessario modificare le produzioni connessioni. Poiché ciascun gestore code ha un nome diverso, è necessario modificare le produzioni connessioni in ognuno dei server delle applicazioni per riflettere le differenze univoche relative dalla configurazione della procedura guidata di installazione standard di Business Process Choreographer per tutti i cluster.
Related concepts
Business Process Choreographer e Network Deployment

Terms of use |

Last updated: Thu Mar 30 14:34:14 2006

(c) Copyright IBM Corporation 2005, 2006.
This information center is powered by Eclipse technology (http://www.eclipse.org)