Espansione del livello SQL Server

Per ogni gruppo BizTalk, si aggiunge un database Master MessageBox. Tutti i database MessageBox successivi aggiunti vengono denominati MessageBox secondari. Master MessageBox gestisce tutte le sottoscrizioni e il routing dei messaggi. Può anche pubblicare messaggi. I database MessageBox secondari pubblicheranno solo i messaggi quando sono configurati in modo specifico 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 operazione se il server fisico MessageBox esistente dispone di risorse di CPU e I/O sufficienti ed è soggetto solo al collo di bottiglia causato dalla contesa sui lock. Creare il database MessageBox secondario su unità I/O separate.

  Vantaggi:

  • La capacità di calcolo aggiuntiva della CPU può essere utilizzata da altre finestre di messaggi.

  • Sono necessarie meno licenze di SQL Server

  • L'hop di rete viene rimosso

• Aggiungere il database MessageBox secondario in un server fisico diverso

  In questo caso, usare un server fisico dedicato con un proprio I/O come database MessageBox aggiuntivo.

  La figura seguente illustra uno scenario in cui il livello SQL viene ridimensionato da un database MessageBox a tre database MessageBoxes.

  

Quando scalare orizzontalmente il database MessageBox

• Il database MessageBox diventa il collo di bottiglia. Questi colli di bottiglia possono essere:

  • CPU In caso di scenari di orchestrazione molto costosi e complessi, il database MessageBox utilizza risorse cpu elevate. Aggiungere un'altra pubblicazione del database MessageBox dovrebbe contribuire ad aumentare la capacità di elaborazione.

  • Contesa di blocco Gli 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 MessageBox di pubblicazione dovrebbe contribuire ad aumentare la velocità effettiva.

• Ampliare la capacità non risolve il collo di bottiglia. Ad esempio, se il database Master MessageBox è associato a conflitti di blocco, il ridimensionamento orizzontale è l'unica opzione.

• L'espansione è troppo costosa. Ad esempio, se l'aggiornamento del server esistente da quad processore a un server a 8 vie è più costoso rispetto all'aggiunta di un altro quad processore, la scalabilità orizzontale è l'opzione migliore.

Quando non è possibile eseguire il scale-out del livello SQL

In teoria, lo strato SQL dovrebbe scalare all'infinito, purché il database Master MessageBox non sia il collo di bottiglia. A tale scopo, prendere in considerazione la possibilità di rendere il database Master MessageBox un database non di pubblicazione in modo che esegui solo il routing. Tuttavia, una volta che il server principale è in collo di bottiglia causato da contesa sui lock, non puoi espandere ulteriormente il livello SQL.

Strategie e considerazioni di scalabilità orizzontale

• Prima scala il database Master MessageBox e poi scala verso l'esterno.

• Scalabilità orizzontale da 1 a 3 database MessageBox SQL anziché da 1 a 2. Si consideri la topologia di SQL Server illustrata nella figura precedente denominata "4 BizTalk Server, 1 topologia di 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 un solo database MessageBox a questa topologia, il messaggio master sarà comunque associato alla CPU e il database MessageBox secondario verrà sottoutilizzato. Quindi, il fattore di ridimensionamento è quasi 1. Se si disabilita la pubblicazione nel database Master MessageBox e si dedica il database Master MessageBox solo a eseguire il routing, il database MessageBox secondario eseguirà la pubblicazione. Ciò non consentirà di aumentare la velocità effettiva complessiva, anche se poiché il database MessageBox secondario è l'unico server di pubblicazione e diventa comunque il collo di bottiglia. Pertanto, l'aggiunta di 2 database MessageBox secondari e la disabilitazione della pubblicazione sul database Master MessageBox sarebbe il modo consigliato per espandere in questo scenario.

• Il database Master MessageBox sarà infine il collo di bottiglia. Quindi, il computer fisico che ospita il database Master MessageBox dovrebbe essere più veloce e più grande.

• Per ridurre al minimo l'invio di dati in rete (e il sovraccarico DTC associato), prendere in considerazione l'inserimento di più database MessageBox nello stesso computer fisico con unità dedicate. Allo stesso tempo, assicurarsi che il computer che ospita questi molteplici database non diventi un collo di bottiglia, poiché le risorse vengono condivise da più database MessageBox.

• Tutti i database MessageBox secondari devono usare hardware paragonabile perché il lavoro viene distribuito uniformemente tra i database MessageBox di pubblicazione.

• Poiché è possibile aumentare il numero di istanze dei database MessageBox secondari purché il database MessageBox master non costituisca un collo di bottiglia, i database MessageBox secondari possono essere eseguiti su computer con meno risorse CPU rispetto a quanto richiesto dal server di database MessageBox master.

Vedere anche

Espansione orizzontale del livello BizTalk Server
Aumento delle prestazioni del livello BizTalk Server
Aumento delle prestazioni del livello SQL Server
Scaled-Out Ricezione degli Host
Scaled-Out Processing Hosts
Scaled-Out Invio Host
Uso del cluster Windows Server per garantire la disponibilità elevata per gli host BizTalk Server2
databaseScaled-Out
Clustering dei database di BizTalk Server