Scalabilità orizzontale del livello BizTalk Server
Per scalare in orizzontale il livello BizTalk, è necessario aggiungere hardware alla topologia esistente. È consigliabile aggiungere hardware nei seguenti casi:
BizTalk Server diventa un collo di bottiglia. Il collo di bottiglia può essere causato da uno dei seguenti problemi:
CPU: se vengono utilizzate pipeline, mappe o orchestrazioni che fanno un uso intensivo della CPU, i server BizTalk non avranno sufficiente CPU a disposizione.
Memoria e I/O: se i computer esistenti hanno raggiunto il limite massimo di memoria e I/O, l'unico modo per aggiungere risorse consiste nell'aggiungere un altro computer fisico.
La scalabilità verticale è troppo costosa. Si consideri, ad esempio, la topologia BizTalk Server 1 in cui la CPU di BizTalk è al massimo della sua capacità. Se risulta meno costoso aggiungere computer a doppio processore anziché aggiornare il doppio processore a un quadruplo processore, è opportuno scegliere la scalabilità orizzontale.
Con la scalabilità verticale non si risolve il problema del collo di bottiglia. La scalabilità verticale potrebbe essere inefficace nei seguenti casi:
L'IO è al livello massimo per il computer BizTalk, quindi è necessario un altro computer per scalare l'IO.
La memoria è al livello massimo per il sistema operativo. In questo caso, l'unico modo per scalare il sistema consiste nell'aggiungere un computer BizTalk alla topologia.
In alcuni casi, può essere utile avere server dedicati per la ricezione, l'invio e l'elaborazione dei messaggi. In presenza di server dedicati è più semplice isolare i problemi ed effettuare le attività di manutenzione su un computer senza ripercussioni sugli altri. È possibile aggiungere questi computer scalando in orizzontale il livello BizTalk.
Casi in cui non è possibile scalare in orizzontale il livello BizTalk
Il database MessageBox costituisce il collo di bottiglia.
Un adapter diventa il collo di bottiglia. Se, ad esempio, si utilizza l'adapter SQL, dopo aver aumentato il numero di ricevitori BizTalk, bloccare gli aumenti di contese nel database SQL da cui l'adapter SQL BizTalk recupera i dati. Questo riduce la possibilità di scalare in orizzontale l'adapter SQL.
Nella figura seguente è illustrato un esempio di come scalare in orizzontale il livello BizTalk.
Nella figura è illustrata una topologia BizTalk scalata in orizzontale, a partire da un server BizTalk per passare a due server BizTalk. Nella topologia con un server BizTalk, tre istanze host condividono le risorse del computer BizTalk. Nella topologia con due server BizTalk, l'host di trasmissione si trova in un server distinto, che raggiunge una maggiore velocità effettiva.
Considerazioni per la scalabilità orizzontale del livello BizTalk
Prima di aggiungere un computer BizTalk Server è necessario rispondere alle seguenti domande:
Come configurare il sistema per il bilanciamento del carico e la tolleranza di errore quando si scala in orizzontale il livello BizTalk?
La scelta della tecnologia per il bilanciamento del carico e la tolleranza di errore dipende dall'adapter utilizzato. Per gli adapter SOAP e HTTP è consigliabile utilizzare Bilanciamento carico di rete. Per ulteriori informazioni, vedere la documentazione relativa a NLB.
Come si esegue il refactoring delle istanze dell'host?
Non esiste una regola precisa per stabilire come eseguire il refactoring delle istanze dell'host quando si scala in orizzontale il livello BizTalk. Quando eseguire il refactoring delle istanze dell'host dipende dal grado di complessità dello scenario. Di seguito sono riportati alcuni esempi di come eseguire il refactoring delle istanze dell'host.
Scenario 1
Configurazione con un server BizTalk e istanze dell'host di ricezione e trasmissione nello stesso computer.
Si supponga che vi sia un collo di bottiglia a livello di CPU. Si aggiunge al gruppo un computer BizTalk identico. In questo modo vi sono due possibili soluzioni per eseguire il refactoring delle istanze dell'host.
Di seguito sono riportate due soluzioni per il problema:
Soluzione 1: il modo più semplice di fattoriare in questo scenario consiste nel clonare il fattore di istanza host dal primo computer al secondo computer. In questo modo il secondo computer è una copia esatta del primo in termini di funzionalità. Inoltre, il secondo computer può ospitare entrambi gli host di ricezione e trasmissione. Supponendo che non vi siano altri colli di bottiglia, è possibile ottenere un fattore di scala di 2 dal momento che le risorse della CPU sono raddoppiate.
Soluzione 2: un altro modo per tenere conto delle istanze host consiste nell'isolare la ricezione e l'invio di funzioni in computer diversi. In questo caso uno dei server BizTalk è dedicato alla ricezione e l'altro alla trasmissione.
Confronto della soluzione 1 e della soluzione 2
Nella soluzione 1 il numero di istanze dell'host è doppio rispetto alla configurazione con un computer BizTalk Server. Questo significa che aumenterà la contesa dei blocchi nel computer SQL Server. Il fattore di scala sarà determinato dall'aumento della contesa dei blocchi. Se la contesa dei blocchi non rischia di diventare un collo di bottiglia, è possibile considerare un fattore di scala uguale a 2.
Il vantaggio della soluzione 2 è che sono presenti solo due istanze host, pertanto la contesa di blocco nel server SQL deve essere minore rispetto alla soluzione 1. Tuttavia, il fattore di ridimensionamento dipende completamente dalla complessità delle istanze host di ricezione e invio. Si considerino i seguenti casi nella soluzione 2:
Si supponga che entrambe le istanze dell'host di ricezione e di trasmissione facciano un uso uguale della CPU, ciascuna il 50% della CPU della topologia con un server BizTalk. Nella topologia con due server BizTalk si sposta l'istanza dell'host di trasmissione in un computer diverso ed entrambe le istanze dell'host di ricezione e trasmissione ottengono il doppio delle risorse. Ciò dovrebbe fornire un fattore di scala pari a 2, presupponendo che non vi siano altri colli di bottiglia. Questo caso è migliore della soluzione 1, perché vi sono solo due istanze dell'host e pertanto minore contesa dei blocchi.
Si supponga che l'istanza dell'host di trasmissione faccia un uso maggiore della CPU rispetto all'istanza dell'host di ricezione, ovvero utilizzi l'80% di risorse della CPU nella topologia con un server BizTalk. Spostando l'istanza dell'host di trasmissione in un altro computer si ottiene solo il 20% in più di risorse della CPU, quindi il fattore di scala massimo sarà pari a 1,2. Inoltre, il computer con l'istanza dell'host di ricezione utilizzerà solo il 20-30% di risorse della CPU, quindi il vantaggio della scalabilità orizzontale è decisamente minore.
Si prenda in esame la seguente figura, che mostra quattro server BizTalk. Ogni computer è sia ricevitore che mittente, offrendo un totale di quattro istanze host di ogni tipo (ricezione e trasmissione).
Questa topologia potrebbe non essere la migliore possibile. Si dovrebbero verificare anche altre permutazioni del factoring, a seconda della complessità dello scenario. Ad esempio:
Dedicare due computer per la ricezione e due per la trasmissione. In questo modo si ha la migliore scalabilità possibile quando entrambe le istanze dell'host di ricezione e dell'host di trasmissione fanno un uso uguale delle risorse della CPU.
Dedicare tre computer alla ricezione e uno alla trasmissione, se la ricezione utilizza più risorse della trasmissione.
Dedicare un computer alla ricezione e tre alla trasmissione, se la trasmissione utilizza più risorse della ricezione.
In tutti gli scenari è consigliabile ridurre al minimo il numero di istanze di ogni host, in modo da ridurre la contesa nel database MessageBox e al tempo stesso utilizzare al massimo le risorse del computer. La permutazione del factoring dipende dalla complessità dello scenario e dal tipo di collo di bottiglia. Verificare sempre il factoring prima di finalizzare una permutazione.
Vedere anche
Scalabilità verticale del livello BizTalk Server
Scalabilità verticale del livello di SQL Server
Scalabilità orizzontale del livello SQL Server
Host riceventi con scalabilità orizzontale
Host di elaborazione con scalabilità orizzontale
Host di invio con scalabilità orizzontale
Uso del cluster Windows Server per fornire disponibilità elevata per gli host BizTalk Server 2
Database con scalabilità orizzontale
Clustering dei database BizTalk Server