Scalabilità orizzontale dei database BizTalk Server
Per garantire la disponibilità elevata per i database BizTalk Server, configurare due computer che eseguono SQL Server in un cluster Windows. Questi computer possono essere eseguiti in una configurazione attiva/attiva/passiva o attiva/attiva/attiva/passiva (richiede tre computer) per la ridondanza e può archiviare i dati in un'unità condivisa (ad esempio un array di dischi RAID 1+0 SCSI) o una rete dell'area di archiviazione (SAN).
Se il servizio SQL Server risulta non disponibile, il cluster di database trasferisce le risorse dal computer attivo a quello passivo. Durante questo processo di failover si verificano errori nelle connessioni al database delle istanze del servizio BizTalk Server e queste istanze vengono riavviate automaticamente per ristabilire la connessione ai database. Il computer del database funzionante (precedentemente definito computer passivo) inizia a elaborare le connessioni al database dopo aver acquisito le risorse durante il failover.
Il clustering dei database BizTalk Server viene illustrato in Clustering dei database BizTalk Server 2. Questa sezione è incentrata sull'aumento del numero di istanze dei database BizTalk Server per garantire la disponibilità elevata.
Disponibilità elevata per il database MessageBox BizTalk
In questa sezione vengono fornite informazioni su come configurare il database MessageBox BizTalk per la disponibilità elevata.
Esecuzione di più database MessageBox
Per migliorare la scalabilità dei database di BizTalk Server e per gestire un utilizzo elevato della CPU nel database MessageBox SQL Server computer, è possibile configurare BizTalk Server per archiviare i dati in più database MessageBox. Il primo database MessageBox viene creato all'esecuzione della Configurazione guidata. è il database MessageBox master. In ogni distribuzione BizTalk Server è presente un solo database MessageBox master. Esso contiene le informazioni della sottoscrizione master e instrada i messaggi ai database MessageBox appropriati. In genere, si vuole dedicare il database MessageBox master per eseguire il routing solo e consentire agli altri database MessageBox di eseguire l'elaborazione. Per fare in modo che un database MessageBox esegui solo il routing, selezionare Disabilita nuova pubblicazione di messaggi dalle proprietà MessageBox nella console di amministrazione BizTalk.
Di seguito è riportato un esempio di flusso di elaborazione del database MessageBox:
Quando riceve un nuovo messaggio di attivazione, ovvero una nuova istanza di un processo di business o un messaggio di sottoscrizione, il database MessageBox master distribuisce il messaggio di attivazione al successivo database MessageBox disponibile. Ad esempio, se si dispone di un database MessageBox master e due database MessageBox, il database MessageBox master instrada il primo messaggio di attivazione al database MessageBox 1, il secondo messaggio di attivazione al database MessageBox 2, il terzo messaggio di attivazione al database MessageBox 1 e così via in una sequenza round-robin. Il database MessageBox master utilizza una logica incorporata per bilanciare il carico e non richiede altri meccanismi di bilanciamento del carico.
Dopo che il database MessageBox ha instradato il messaggio di attivazione a un determinato database MessageBox (ad esempio, il database MessageBox 1), il processo di business passa in memoria e viene eseguito.
Se il processo aziendale deve attendere un messaggio e il tempo di attesa è più lungo di diversi secondi, il processo aziendale viene reso persistente nel database MessageBox 1. Il processo aziendale è in attesa di un messaggio di correlazione.
Quando il messaggio di correlazione arriva al database MessageBox master, il motore di messaggi esegue un'operazione di ricerca nel database per il database MessageBox che contiene lo stato del messaggio di correlazione (in questo esempio MessageBox 1). Il database MessageBox master recapita il messaggio al database MessageBox che contiene il processo aziendale.
Il processo aziendale viene riportato in memoria per continuare l'elaborazione fino al termine o fino a quando non deve attendere un altro messaggio di correlazione.
In BizTalk Server tutti gli stati vengono archiviati nei database MessageBox e ogni database MessageBox contiene informazioni relative alle stato per diversi processi di business. Per garantire l'affidabilità, è necessario includere in un cluster tutti i database MessageBox, inclusi i database MessageBox master e secondari.
Per configurare più database MessageBox, usare la console di amministrazione di BizTalk Server per aggiungere i computer che eseguono SQL Server. Da un punto di vista amministrativo, è necessario aggiungere solo nuovi database MessageBox. In BizTalk Server viene gestita automaticamente la distribuzione round-robin dei messaggi di attivazione e l'invio dei messaggi di correlazione ai database MessageBox appropriati.
Se si configurano più database MessageBox nell'ambiente, è necessario creare almeno tre database MessageBox per il gruppo di BizTalk Server e disabilitare la pubblicazione dei messaggi nel database MessageBox master. Questa raccomandazione viene effettuata perché l'aggiunta di database MessageBox aggiuntivi comporta un sovraccarico da parte del database MessageBox master per il routing dei messaggi tra i database MessageBox. Se si configurano solo due database MessageBox, la maggior parte dei vantaggi ottenuti dal database MessageBox aggiuntivo è compensata dall'overhead utilizzato dal database MessageBox master per il routing dei messaggi.
Importante
In BizTalk Server tutti gli stati vengono archiviati nei database MessageBox e ogni database MessageBox contiene informazioni relative alle stato per diversi processi di business. Per garantire l'affidabilità, è necessario includere in un cluster tutti i database MessageBox, inclusi i database MessageBox master e secondari.
Elevata disponibilità per più database MessageBox
Mentre l'aggiunta di database MessageBox alla distribuzione di BizTalk Server migliora la scalabilità, non offre disponibilità elevata perché ogni database MessageBox è univoco e indipendente ed è potenzialmente un singolo punto di errore per l'ambiente di BizTalk Server. Per aggiungere caratteristiche di ridondanza è necessario configurare un cluster di server per ogni database MessageBox. BizTalk Server distribuisce i dati tra più database MessageBox, pertanto i database non condividono i dati oppure la ridondanza viene garantita senza il cluster server.
Elevata disponibilità del database di rilevamento BizTalk
In base ai requisiti della distribuzione in uso, può essere consigliabile migliorare le prestazioni del rilevamento isolando il database di rilevamento BizTalk in un computer SQL Server diverso e creando un host BizTalk separato dedicato al rilevamento host. La figura seguente mostra un host di rilevamento dedicato con due istanze host e database in cluster.
Se la distribuzione è caratterizzata da un'elevata velocità effettiva e coinvolge il rilevamento di ingenti quantità di dati per i messaggi, l'overhead di rilevamento può assorbire una quantità di risorse eccessiva nel computer che esegue SQL Server. Se si verifica questa situazione e continua una frequenza elevata di messaggi in arrivo, BizTalk Server raggiunge un punto in cui non è possibile elaborare nuovi messaggi perché le risorse necessarie per tenere traccia dei messaggi sono maggiori delle risorse necessarie per eseguire gli altri componenti BizTalk Server , ad esempio la ricezione di messaggi e la persistenza nel database MessageBox.
Per migliorare il livello di prestazioni e sicurezza, è consigliabile dedicare al rilevamento un host che non contenga altri elementi (quali indirizzi di ricezione, orchestrazioni o pipeline) e disattivare il rilevamento negli host riceventi, di elaborazione e di invio. Per garantire un'elevata disponibilità dell'host di rilevamento, creare più di un'istanza di tale host. Vedere Creare un nuovo host.
Per ogni database MessageBox, BizTalk Server usa una sola istanza host di rilevamento per spostare i messaggi dal database MessageBox al database di rilevamento BizTalk (BizTalkDTADb). Se altri computer eseguono istanze dell'host di rilevamento, BizTalk Server distribuisce automaticamente la gestione di ogni database MessageBox a istanze separate dell'host di rilevamento. Se il numero di database MessageBox è maggiore del numero di istanze dell'host di rilevamento, una o più istanze dell'host di rilevamento gestiranno più di un database MessageBox.
Per garantire un'elevata disponibilità del database di rilevamento di BizTalk, utilizzare il Servizio cluster di Windows per configurare due computer di database che eseguono SQL Server in una configurazione attivo/passivo.
Elevata disponibilità dei database BAM
Il monitoraggio delle attività aziendali (BAM) offre visibilità sui processi aziendali indipendenti dall'implementazione IT o in un'implementazione IT eterogenea. Nei database SQL Server BAM (database con schema a stella BAM, database di importazione primaria BAM e database di archiviazione BAM) e nel database di analisi BAM sono memorizzati i dati relativi all'attività di business che si differenziano dai dati di monitoraggio operativi. Il diagramma seguente illustra l'infrastruttura di database BAM.
Per garantire la disponibilità elevata dell'infrastruttura BAM in uso, eseguire le operazioni seguenti:
Includere in un cluster il database di importazione primaria BAM e il database di analisi BAM. Il database di importazione primaria BAM costituisce il centro del sistema Monitoraggio attività di business. È pertanto importante garantire una disponibilità elevata di questo database utilizzando il Servizio cluster di Windows e seguendo le due indicazioni seguenti per impedire che il database si riempia. Il database di analisi BAM è un database di Analysis Services in cui sono memorizzati i dati utilizzati dagli analisti aziendali per generare aggregazioni di attività e cubi OLAP. Eventuali tempi di inattività di questo database limitano pertanto la produttività degli analisti. Anche se non è necessario raggruppare il database di archiviazione BAM, è consigliabile monitorare il registro eventi per individuare gli errori quando vengono eseguiti i pacchetti di SQL Server Integration Services (SSIS) per assicurarsi che i dati siano stati trasferiti correttamente e monitorare le dimensioni del database in modo che sia possibile sostituirli prima di riempirlo.
Definire una finestra online. Per garantire prestazioni migliori ed evitare tempi di inattività, BAM partiziona i dati nel database di importazione primaria BAM in tabelle in base al timestamp al termine dell'attività. Per questo scopo, le tabelle complete vengono sostituite regolarmente da tabelle vuote di formato identico. Dopo questa sostituzione, le nuove attività completate vengono dirette alla nuova partizione (tabella), mentre le partizioni precedenti vengono conservate in BAM per il periodo definito nella finestra online. È necessario definire una finestra online per garantire che il numero di partizioni nel database di importazione primaria BAM non diventi eccessivo. Per altre informazioni sulla pianificazione delle finestre online, vedere Archiviazione dei dati del database di importazione primaria.
Pianificare l'esecuzione periodica dei pacchetti SSIS. Definendo una finestra online è possibile garantire che il database di importazione primaria BAM non venga riempito di partizioni datate. È inoltre necessario pianificare l'esecuzione periodica dei pacchetti SSIS per creare una nuova partizione per i dati dell'attività e spostare i dati dalle partizioni precedenti nel database di importazione primaria BAM nel database di archiviazione BAM. Per altre informazioni sulla pianificazione dei pacchetti SSIS, vedere Pianificazione dei pacchetti di Integration Services SQL Server.
Scegliere attentamente piccoli set di elementi dati (punti di arresto) ed evitare di includere elementi dati superflui durante la definizione di un'attività.
Valutare vantaggi e svantaggi delle aggregazioni pianificate e in tempo reale durante la progettazione delle aggregazioni. Le aggregazioni in tempo reale vengono gestite automaticamente dai trigger SQL Server e hanno latenza zero. Sono ideali per alcuni scenari di bassa latenza cruciali, ma comportano un costo delle prestazioni ogni volta che gli eventi vengono scritti nel database di importazione primaria BAM. Le aggregazioni pianificate si basano sui pacchetti SSIS pianificati per aggiornare i dati di aggregazione. La latenza è uguale o maggiore dell'intervallo di pianificazione SSIS, ma complessivamente hanno un impatto sulle prestazioni inferiore sul database di importazione primaria BAM.
Se si scelgono le aggregazioni pianificate, assicurarsi di pianificare l'esecuzione di SSIS cubing più frequentemente rispetto all'archiviazione SSIS. Ciò è dovuto al fatto che l'archiviazione SSIS non sposta i dati dell'attività elaborati per l'aggregazione pianificata nel database di archiviazione BAM.
Abilitare il servizio bus di eventi BAM in più computer per ottenere la funzionalità di failover.
Elevata disponibilità degli altri database BizTalk Server
Per garantire la disponibilità elevata per gli altri database BizTalk Server, configurare due computer che eseguono SQL Server in un cluster Windows. Questi computer possono essere eseguiti in una configurazione attiva/attiva o attiva/passiva per la ridondanza e possono archiviare i dati in un'unità condivisa (ad esempio un array di dischi RAID 1+0 SCSI) o una rete di archiviazione (SAN).