Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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,attiva/passiva o attiva/attiva/passiva (richiede tre computer) per la ridondanza e possono archiviare i dati in un'unità condivisa (ad esempio una matrice di dischi RAID 1+0 SCSI) o una rete SAN (Storage Area Network).
Se il servizio SQL Server non è più disponibile per qualsiasi motivo, il cluster di database trasferisce le risorse dal computer attivo al computer passivo. Durante questo processo di failover, le istanze del servizio BizTalk Server riscontrano errori di connessione al database e riavviano automaticamente per riconnettersi ai database. Il computer di database funzionante (in precedenza il computer passivo) inizia a elaborare le connessioni di database dopo aver assunto le risorse durante il failover.
Il clustering dei database BizTalk Server è descritto in Clustering dei database bizTalk Server2. Questa sezione si concentra sulla scalabilità dei database di BizTalk Server per garantire elevata disponibilità.
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 BizTalk Server e per gestire un utilizzo elevato della CPU nel computer SQL Server del database MessageBox, è possibile configurare BizTalk Server per archiviare i dati in più database MessageBox. Quando si esegue la Configurazione guidata, si crea il primo database MessageBox. Il database MessageBox è il database master di MessageBox. Nella distribuzione di BizTalk Server è presente un singolo database MessageBox master. Il database Master MessageBox contiene le informazioni sulla sottoscrizione master e indirizza i messaggi al database MessageBox appropriato. In genere, si vuole dedicare il database MessageBox master solo per eseguire il routing 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 di BizTalk.
Di seguito è riportato un esempio di flusso di elaborazione del database MessageBox:
Quando il database Master MessageBox riceve un nuovo messaggio di attivazione, ovvero una nuova istanza di un processo aziendale o un messaggio di sottoscrizione, il database Master MessageBox distribuisce il messaggio di attivazione al database MessageBox disponibile successivo. Ad esempio, se si dispone di un database MessageBox master e di 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 un modello round robin. Il database Master MessageBox usa la logica predefinita per bilanciare il carico e non richiede meccanismi di bilanciamento del carico aggiuntivi.
Dopo che il database Master MessageBox indirizza il messaggio di attivazione a un determinato database MessageBox (ad esempio, database MessageBox 1), il processo aziendale passa in memoria ed è in esecuzione.
Se il processo aziendale deve attendere un messaggio e il tempo di attesa è superiore a 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 per il 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.
BizTalk Server archivia tutti gli stati nei database MessageBox e ogni database MessageBox contiene informazioni sullo stato per processi aziendali diversi. Per garantire l'affidabilità, è necessario raggruppare tutti i database MessageBox, inclusi i database MessageBox master e secondario.
Per configurare più database MessageBox, usare la console di amministrazione di BizTalk Server per aggiungere i computer che eseguono SQL Server. Dal punto di vista dell'amministrazione, è necessario aggiungere solo nuovi database MessageBox. BizTalk Server gestisce automaticamente la distribuzione round robin dei messaggi di attivazione e invia messaggi di correlazione ai database MessageBox corretti.
Se si configurano più database MessageBox nell'ambiente, è necessario creare almeno tre database MessageBox per il gruppo 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 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 dal sovraccarico utilizzato dal database Master MessageBox per il routing dei messaggi.
Importante
BizTalk Server archivia tutti gli stati nei database MessageBox e ogni database MessageBox contiene informazioni sullo stato per processi aziendali diversi. Per garantire l'affidabilità, è necessario raggruppare tutti i database MessageBox, inclusi i database MessageBox master e secondario.
Fornire una disponibilità alta per più database MessageBox
Anche se 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 BizTalk Server. Per aggiungere ridondanza, è necessario configurare un cluster server per ogni database MessageBox. BizTalk Server distribuisce i dati tra più database MessageBox, pertanto i database non condividono i dati o forniscono ridondanza in altro modo senza il raggruppamento del server.
Disponibilità elevata per il database di rilevamento BizTalk
A seconda dei requisiti della distribuzione specifica, è possibile migliorare le prestazioni per il rilevamento isolando il database di rilevamento BizTalk in un computer SQL Server separato e creando un host BizTalk separato dedicato al rilevamento dell'host. La figura seguente illustra un host di rilevamento dedicato con due istanze host e database in cluster.
Se la distribuzione ha una velocità effettiva elevata e prevede il rilevamento di un numero elevato di dati per questi messaggi, il sovraccarico di rilevamento potrebbe potenzialmente utilizzare molte risorse 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 di BizTalk Server, ad esempio la ricezione di messaggi e la relativa persistenza nel database MessageBox.
Per migliorare le prestazioni e la sicurezza, è consigliabile dedicare un host per il rilevamento che non contiene altri elementi (ad esempio posizioni di ricezione, orchestrazioni o pipeline) e disabilitare il rilevamento dalla ricezione, dall'elaborazione e dall'invio degli host. Per offrire disponibilità elevata per l'host di rilevamento, creare più di un'istanza host dell'host di rilevamento. 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 ulteriori computer eseguono istanze dell'host di rilevamento, BizTalk Server ridistribuisce automaticamente la gestione di ogni database MessageBox su un'istanza separata dell'host di rilevamento. Se il numero di database MessageBox è maggiore del numero di istanze host di rilevamento, una o più istanze host di rilevamento eseguiranno il servizio di più di un database MessageBox.
Per garantire la disponibilità elevata per il database di rilevamento BizTalk, usare Clustering di Windows per configurare due computer di database che eseguono SQL Server in una configurazione attiva/passiva.
Disponibilità elevata per i database BAM
Il monitoraggio delle attività aziendali (BAM) offre visibilità sui processi aziendali indipendenti dall'implementazione IT o in un'implementazione IT eterogenea. I database di SQL Server BAM (database BAM Star Schema, database di importazione primaria BAM e database di archiviazione BAM) e il database di analisi BAM archivia i dati delle attività aziendali diversi dai dati di monitoraggio operativo. Il diagramma seguente illustra l'infrastruttura di database BAM.
Per assicurarsi che l'infrastruttura BAM sia a disponibilità elevata, eseguire le operazioni seguenti:
Clustera il database primario di importazione BAM e il database di analisi BAM. Il database di importazione primaria BAM è il centro del sistema di monitoraggio delle attività aziendali. È quindi importante rendere il database a disponibilità elevata usando Windows Clustering e seguire le due raccomandazioni successive per impedire che il database venga riempito. Il database di analisi BAM è un database di Analysis Services che archivia i dati usati dagli analisti aziendali per creare aggregazioni di attività e cubi OLAP e pertanto qualsiasi tempo di inattività del database influisce sulla produttività. Anche se non è necessario eseguire il cluster del database di archiviazione BAM, è consigliabile monitorare il registro eventi per individuare gli errori quando i pacchetti di SQL Server Integration Services (SSIS) vengono eseguiti per assicurarsi che i dati siano stati trasferiti correttamente e monitorare le dimensioni del database in modo da poterli sostituire prima che vengano riempiti.
Definire una finestra online. Per ottenere 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à. BAM ottiene questo risultato scambiando regolarmente la tabella completata con un'altra tabella vuota di formato identico. Dopo che BAM esegue questa operazione, le attività aggiuntive completate vengono inserite nella nuova partizione (tabella), mentre BAM mantiene le partizioni precedenti per l'ora definita nella finestra online. È necessario definire una finestra online per assicurarsi che il numero di partizioni nel database di importazione primaria BAM non sia troppo grande. Per altre informazioni sulla pianificazione delle finestre online, vedere Archiviazione dei dati del database di importazione primaria.
Pianificare l'esecuzione periodica dei pacchetti SSIS. La definizione di una finestra online assicura che il database di importazione primaria BAM non si riempia di partizioni di attività precedenti. È 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 di pacchetti di SQL Server Integration Services.
Scegliere attentamente piccoli set di elementi di dati (checkpoint) ed evitare di includere elementi di dati non necessari durante la definizione di un'attività.
Comprendere i compromessi tra le aggregazioni pianificate e in tempo reale quando si progettano le aggregazioni. Le aggregazioni in tempo reale vengono gestite automaticamente dai trigger di SQL Server e hanno una latenza zero. Sono ideali per alcuni scenari cruciali a bassa latenza, ma comportano un costo delle prestazioni ogni volta che gli eventi vengono scritti nel database di importazione primaria BAM. Le aggregazioni programmate si basano sui pacchetti SSIS di cubing programmati per aggiornare i loro dati di aggregazione. La latenza è uguale o maggiore dell'intervallo di pianificazione SSIS, ma in generale hanno un impatto minore sulle prestazioni sul database di importazione primaria BAM.
Se si scelgono le aggregazioni pianificate, assicurarsi di pianificare l'esecuzione dell'SSIS di cubatura con maggiore frequenza rispetto all'SSIS di archiviazione. Il motivo è 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.
Disponibilità elevata per gli 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 una matrice di dischi RAID 1+0 SCSI) o una rete SAN (Storage Area Network).