Scalabilità orizzontale del livello SQL Server
Per ogni gruppo BizTalk, viene aggiunto un database MessageBox master. Tutti i database MessageBox aggiunti in seguito vengono chiamati MessageBox secondari. Il MessageBox master gestisce tutte le sottoscrizioni e il routing dei messaggi. Può inoltre pubblicare messaggi. I database MessageBox secondari pubblicheranno messaggi solo se configurati specificamente per farlo.
Come aggiungere un database MessageBox secondario
Esistono due modi per aggiungere database MessageBox secondari:
Aggiungere il database MessageBox secondario nello stesso server fisico.
Eseguire questa azione se il server fisico MessageBox esistente dispone di risorse CPU e I/O sufficienti e solo se i suoi colli di bottiglia sono dovuti alla contesa dei blocchi. Creare il database MessageBox secondario in unità separate di I/O.
Vantaggi:
Lo spazio di CPU supplementare può essere utilizzato da un altro MessageBox
È necessario un numero ridotto di licenze di SQL Server
Viene eliminato l'hop di rete
Aggiungere il database MessageBox secondario in un diverso server fisico
In questo caso, utilizzare un server fisico dedicato con un proprio I/O come database MessageBox supplementare.
Nella figura seguente viene illustrato uno scenario in cui il livello SQL viene configurato per la scalabilità orizzontale da un database MessageBox a tre database MessageBox.
Quando eseguire la scalabilità orizzontale del database MessageBox
Il database MessageBox diviene il collo di bottiglia. Di seguito sono riportati i possibili colli di bottiglia:
CPU In caso di scenari di orchestrazione molto costosi e complessi, il database MessageBox utilizza risorse cpu elevate. L'aggiunta di un altro database di pubblicazione MessageBox dovrebbe contribuire ad aumentare la velocità effettiva.
Conflitti di blocco Scenari complessi con più istanze host o orchestrazioni tendono a creare conflitti di blocco nel database MessageBox. Anche in questo caso, l'aggiunta di un altro database di pubblicazione MessageBox dovrebbe contribuire ad aumentare la velocità effettiva.
La scalabilità verticale non risolve i colli di bottiglia. Se, ad esempio, il database MessageBox master è implicato in una contesa dei blocchi, l'unica opzione è rappresentata dalla scalabilità orizzontale.
La scalabilità verticale è troppo costosa. Se, ad esempio, l'aggiornamento del server a quattro processori esistente a un server a 8 vie è più costoso dell'aggiunta di un altro server a quattro processori, l'opzione migliore è la scalabilità orizzontale.
Casi in cui non è possibile scalare in orizzontale il livello SQL
In teoria, il livello SQL dovrebbe poter essere scalabile all'infinito, a condizione che il database MessageBox master non sia il collo di bottiglia. Per ottenere questo risultato, trasformare il database MessageBox master in un database non di pubblicazione affinché esegua solo il routing. Ma quando il collo di bottiglia del master è dovuto a una contesa dei blocchi, non è più possibile eseguire la scalabilità orizzontale del livello SQL.
Strategie di scalabilità orizzontale e considerazioni
Eseguire prima la scalabilità verticale del database MessageBox master e poi quella orizzontale.
Aumento del numero di istanze da 1 a 3 database MessageBox SQL anziché da 1 a 2. Si consideri la topologia di SQL Server illustrata nella figura precedente intitolata "4 BizTalk Server, 1 topologia SQL Server" e si supponga che il server SQL sia associato alla CPU, in altre parole, l'elaborazione della CPU è un collo di bottiglia. Se si aggiunge solo un database MessageBox a questa topologia, il Messagebox master sarà ancora associato alla CPU e il database MessageBox secondario sarà sottoutilizzato. Quindi, il fattore di ridimensionamento è quasi 1. Se si disabilita la pubblicazione nel database Master MessageBox e si dedica solo il database Master MessageBox al routing, il database MessageBox secondario eseguirà la pubblicazione. Tuttavia ciò non contribuirà ad aumentare la velocità complessiva poiché il database MessageBox secondario è l'unico server di pubblicazione e continua a essere il collo di bottiglia. La procedura di scalabilità orizzontale consigliata in questo scenario consiste pertanto nell'aggiungere 2 database MessageBox secondari e nel disattivare la pubblicazione nel database MessageBox master.
Il database MessageBox master potrebbe diventare il collo di bottiglia. Il computer fisico che ospita il database MessageBox master dovrebbe essere pertanto più veloce e più potente.
Per ridurre al minimo l'invio di dati sulla rete e l'overhead del DTC associato, è consigliabile inserire più database MessageBox nello stesso computer fisico con unità dedicate. Allo stesso tempo, assicurarsi che il computer in cui sono contenuti questi database multipli non diventi il collo di bottiglia in quanto le risorse vengono condivise da più database MessageBox.
È preferibile che tutti i database MessageBox secondari utilizzino hardware con caratteristiche simili perché il lavoro viene distribuito uniformemente tra i database di pubblicazione MessageBox.
Poiché, se non vi è alcun collo di bottiglia nel database MessageBox master, è possibile eseguire la scalabilità orizzontale dei database MessageBox secondari, questi possono essere installati in computer con risorse di CPU inferiori rispetto al server del database MessageBox master.
Vedere anche
Scalabilità orizzontale del livello BizTalk Server
Scalabilità verticale del livello BizTalk Server
Scalabilità verticale del livello di 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 garantire la disponibilità elevata per gli host BizTalk Server 2
Database con scalabilità orizzontale
Clustering dei database BizTalk Server