Database con scalabilità orizzontale
Per garantire la disponibilità elevata per i database BizTalk Server, configurare due computer che eseguono SQL Server in un cluster Windows. È possibile eseguire questi computer in una configurazione attivo/attivo o attivo/passivo per garantire la ridondanza e archiviare i dati in un'unità condivisa (ad esempio un array di dischi RAID 1+0 SCSI) o in una rete 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.
Esecuzione di più database MessageBox
Per migliorare la scalabilità dei database BizTalk Server, è 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 master MessageBox a eseguire il routing solo ( selezionare Disabilita nuova pubblicazione di messaggi) e consentire agli altri database MessageBox di eseguire l'elaborazione.
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 database MessageBox master riceve tale messaggio di correlazione, il messaggio esegue un'operazione di ricerca nel database per individuare il database MessageBox contenente lo stato del messaggio di correlazione (in questo esempio, MessageBox 1). Il database MessageBox master invia quindi il messaggio al database MessageBox contenente il processo di business. Il processo di business viene quindi riportato in memoria per proseguire l'elaborazione fino al completamento o fino al punto in cui dovrà 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, è necessario utilizzare la Console di amministrazione BizTalk 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 3 database MessageBox per il gruppo BizTalk Server e disattivare la pubblicazione di messaggi sul database MessageBox master. Questa indicazione è necessaria poiché l'aggiunta di altri database MessageBox determina un overhead del database MessageBox master per il routing dei messaggi tra i vari database MessageBox. Se si configurano solo 2 database MessageBox, gran parte del vantaggio determinato dal database MessageBox aggiuntivo viene annullato dall'overhead utilizzato dal database MessageBox master per il routing dei messaggi.
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. 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.
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
Monitoraggio attività di business (BAM) consente di ottenere una visibilità dei processi di business indipendente dall'implementazione IT o in implementazioni IT eterogenee. 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. 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. Sebbene non sia necessario includere in un cluster il database di archiviazione BAM, è consigliabile monitorare il registro eventi per individuare errori durante l'esecuzione dei pacchetti Data Transformation Services (DTS) per garantire il corretto trasferimento dei dati e monitorare le dimensioni del database in modo da poterlo sostituire prima che si riempia.
Definire una finestra online. Per assicurare prestazioni più elevate ed evitare tempi di inattività, in Monitoraggio attività di business i dati del database di importazione primaria BAM vengono suddivisi in tabelle basate sul timestamp relativo al completamento 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" nella Guida di BizTalk Server.
Pianificare l'esecuzione periodica dei pacchetti DTS. 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 DTS per creare una nuova partizione per i dati di attività e spostare i dati dalle partizioni precedenti del database di importazione primaria BAM nel database di archiviazione BAM. Per altre informazioni sulla pianificazione dei pacchetti DTS, vedere "Pianificazione dei pacchetti DTS" nella Guida di BizTalk 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. Costituiscono la soluzione ideale in alcuni scenari cruciali a bassa latenza, ma comportano una riduzione delle prestazioni ogni volta che gli eventi vengono scritti nel database di importazione primaria BAM. Le aggregazioni pianificate si basano sui pacchetti DTS pianificati di aggiornamento cubo per aggiornare i dati di aggregazione. La latenza di questa soluzione è uguale o maggiore dell'intervallo di pianificazione DTS, ma nel complesso determina un impatto minore sulle prestazioni del database di importazione primaria BAM.
Se si scelgono le aggregazioni pianificate, accertarsi di pianificare l'esecuzione del DTS di aggiornamento con una frequenza maggiore rispetto al DTS di archiviazione. Ciò è necessario in quanto il DTS di archiviazione non sposta i dati di attività elaborati per l'aggregazione pianificata nel database di archiviazione BAM.
Attivare il servizio bus di eventi BAM in più computer per ottenere 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. È possibile eseguire questi computer in una configurazione attivo/attivo o attivo/passivo per garantire la ridondanza e archiviare i dati in un'unità condivisa (ad esempio un array di dischi RAID 1+0 SCSI) o in una rete di archiviazione (SAN).
Vedere anche
Elevata disponibilità degli host BizTalk
Elevata disponibilità dei database BizTalk Server
Scenari di esempio di BizTalk Server a disponibilità elevata