Scalabilità orizzontale degli host riceventi
Quando un host contiene un elemento ricevente, quale un indirizzo o una pipeline di ricezione, funge da limite di sicurezza e le operazioni di decodifica e decrittografia dei messaggi vengono eseguite in una pipeline all'interno dell'host. Per garantire un’elevata disponibilità degli host riceventi, è necessario disporre di due o più computer BizTalk Server che eseguono istanze di ogni host ricevente. Ridimensionando gli host di ricezione è possibile garantire la disponibilità per le distribuzioni BizTalk Server che sono a elevato utilizzo di messaggistica. Sebbene tali distribuzioni possano gestire solo un'elaborazione minima per le orchestrazioni, sono in grado di instradare numerosi messaggi di vari tipi con elevata velocità e affidabilità.
Per migliorare la protezione e la scalabilità dell'ambiente di lavoro, è possibile separare l'host ricevente dagli host che elaborano le orchestrazioni e inviano messaggi in modo da riuscire a proteggere e adattare ogni host in maniera indipendente dagli altri host. È, ad esempio, possibile aggiungere due computer (istanze host) all'host ricevente senza aggiungere alcun computer agli host di elaborazione o di invio.
Più host per la ricezione dei messaggi
Nella figura seguente viene illustrata una distribuzione BizTalk Server che fornisce disponibilità elevata per l'host ricevente con due computer che eseguono istanze dell'host ricevente. Si noti che in questa figura gli host di elaborazione e invio non sono caratterizzati da un'elevata disponibilità.
Nelle distribuzioni molto estese, nei contesti in cui sono presenti più partner commerciali e negli scenari in cui si utilizzano protocolli diversi, è possibile suddividere la funzionalità di ricezione tra più host riceventi. È, ad esempio, possibile creare un host per la ricezione dei messaggi per ogni singolo adapter o diversi host per la ricezione dei messaggi per i diversi partner. In quest'ultimo caso è possibile creare limiti di protezione e migliorare la gestibilità e scalabilità dell'ambiente di lavoro, anche se queste soluzioni non consentono di garantire un'elevata disponibilità dell'ambiente.
Per ottenere questo risultato è necessario creare due o più istanze host per ogni host ricevente creato. Ad esempio, è possibile creare tre diversi host riceventi (A, B e C) per ricevere messaggi da tre società diverse. Per garantire un'elevata disponibilità a ognuno di questi server è quindi necessario creare istanze di ogni host in due o più computer. È possibile gestire istanze di ogni host in un computer senza perdere il limite di protezione, la gestibilità o la scalabilità.
Nella figura seguente viene mostrato un ambiente BizTalk Server a elevata disponibilità composto da tre computer con host dedicati alla ricezione dei messaggi da diverse società.
Per offrire disponibilità elevata in questa configurazione, ogni computer esegue tre istanze host: un'istanza per ognuna delle tre aziende. Le istanze host di ogni società contengono gli indirizzi e le pipeline di ricezione che consentono di comunicare con le singole società. Durante le normali procedure operative, se sono state eseguite tutte le operazioni necessarie per garantire la scalabilità orizzontale rispetto agli adapter di ricezione (ad esempio, se si configura il bilanciamento del carico di rete per HTTP), il carico di messaggi viene distribuito tra le tre istanze host per ogni host. Se si verifica un errore in un'istanza host di un computer, le istanze host in esecuzione negli altri due computer garantiscono la ridondanza e preservano la disponibilità del servizio.
Adattamento degli adapter di ricezione di BizTalk Server
Oltre alle istanze host, il processo di adattamento e configurazione di un'elevata disponibilità per gli host riceventi dipende inoltre dagli adapter specifici implementati nella distribuzione. Ogni adapter dispone di caratteristiche specifiche relative ai protocolli che differenziano la pianificazione e la distribuzione nei singoli casi. Tuttavia, BizTalk Server consente di applicare la stessa soluzione a disponibilità elevata per tutte le schede, principalmente tramite computer e istanze host aggiuntive.
A seconda del protocollo utilizzato, alcuni adapter di ricezione richiedono un meccanismo aggiuntivo per la distribuzione dei messaggi in ingresso a più computer host per assicurare un'elevata disponibilità. Ad esempio, BizTalk Server soluzioni che usano l'adattatore HTTP o SOAP (altrimenti noto come scheda servizi Web) richiedono un servizio di bilanciamento del carico di carico, ad esempio bilanciamento del carico di rete (NLB) per distribuire il carico di lavoro di ricezione. La tabella seguente riepiloga le linee guida per la disponibilità elevata per le schede più comuni in BizTalk Server.
| Adattatore | Linee guida per un'elevata disponibilità |
|---|---|
| HTTP | Aggiungere più computer all'host ricevente e configurare Bilanciamento carico di rete affinché i messaggi in ingresso vengano distribuiti ai vari computer host. |
| SOAP | Aggiungere più computer all'host ricevente e configurare Bilanciamento carico di rete affinché i messaggi in ingresso vengano distribuiti ai vari computer host. |
| File | Aggiungere più computer all'host ricevente e configurare l'indirizzo di ricezione in ogni computer host affinché faccia riferimento alla stessa cartella di file o allo stesso percorso UNC (Universal Naming Convention). Per ottenere una soluzione completa a elevata disponibilità, è necessario verificare che il percorso di file cui fa riferimento il percorso UNC sia caratterizzato da una disponibilità elevata o sia almeno affidabile. |
| FTP | Configurare l'adapter di ricezione FTP affinché venga eseguito in un host BizTalk incluso in un cluster. Per altre informazioni, vedere Considerazioni sull'esecuzione dei gestori di adapter all'interno di un host cluster. |
| POP3 | Configurare l'adapter di ricezione POP3 affinché venga eseguito in un host BizTalk incluso in un cluster. Per altre informazioni, vedere Considerazioni sull'esecuzione dei gestori di adapter all'interno di un host cluster. |
| MSMQ | Configurare l'adapter di ricezione MSMQ da eseguire in un host BizTalk cluster windows. Per altre informazioni, vedere Considerazioni sull'esecuzione dei gestori di adapter all'interno di un host cluster. Se le posizioni di ricezione MSMQ usano code in un server MSMQ remoto, non è necessario clusterare l'host BizTalk. In questo scenario eseguire l'host di ricezione MSMQ in più computer BizTalk nel gruppo. |
| MQSeries | Aggiungere più computer all'host ricevente per questo adapter, utilizzare gestori di code in cluster in MQSeries per Windows e includere in un cluster il server MQSeries per Windows. |
| Windows SharePoint Services | Aggiungere più computer all'host ricevente e configurare Bilanciamento carico di rete affinché i messaggi in ingresso vengano distribuiti ai vari computer host. |
| - WCF-NetTcp - WCF-Custom |
Aggiungere più computer all'host ricevente e configurare Bilanciamento carico di rete affinché i messaggi in ingresso vengano distribuiti a questi computer host. -oppure- Inserire in cluster l'host utilizzato dal gestore di ricezione dell'adapter. |
| - WCF-NetNamedPipe - WCF-BasicHttp - WCF-WSHttp - WCF-CustomIsolated |
Aggiungere più computer all'host ricevente e configurare Bilanciamento carico di rete affinché i messaggi in ingresso vengano distribuiti a questi computer host. |
| WCF-NetMsmq | Inserire in cluster l'host utilizzato dal gestore di ricezione dell'adapter. |
Adapter HTTP
La scheda di ricezione HTTP in BizTalk Server è un'estensione ISAPI (Internet Server API) (BTSHTTPReceive.dll) eseguita come istanza host in ogni computer host di ricezione. Quando un partner invia un messaggio a BizTalk Server tramite il protocollo HTTP, il messaggio in genere arriva all'URL specifico in un computer BizTalk Server in cui è installato Internet Information Services (IIS). È quindi necessario creare un'istanza host in BizTalk Server con un indirizzo di ricezione che sottoscriva questo URL. Quando arrivano messaggi all'URL, essi vengono recuperati e resi persistenti nel database MessageBox di BizTalk Server.
BizTalk Server offre disponibilità elevata per la scheda di ricezione HTTP consentendo di creare più istanze host dello stesso host. Tali istanze host sottoscrivono un URL specifico, che può essere un indirizzo IP condiviso in cluster se si utilizza Bilanciamento carico di rete per distribuire i messaggi in ingresso a più host riceventi. Tutti questi host contribuiscono a fornire l'indirizzo IP virtuale del cluster, in modo che se si verifica un errore in un membro del cluster, gli altri host possono continuare a fornire l'indirizzo IP.
Adapter SOAP (adapter dei servizi Web)
Diversamente dall'adapter di ricezione HTTP, l'adapter di ricezione per i servizi Web non prevede un'estensione ISAPI. Questo adapter riceve i messaggi in ingresso tramite un URL specificato mediante Pubblicazione guidata servizi Web BizTalk. Questa procedura guidata consente di esportare un servizio Web e di creare una directory virtuale che funga da indirizzo di ricezione.
Per garantire un'elevata disponibilità agli adapter dei servizi Web, aggiungere più computer all'host ricevente e utilizzare Bilanciamento carico di rete per distribuire i messaggi in ingresso. Quando un client invia un messaggio a BizTalk Server tramite l'adapter dei servizi Web, il messaggio viene distribuito da Bilanciamento carico di rete a uno degli host riceventi e l'istanza host appropriata in esecuzione nell'host rende persistente il messaggio nel database MessageBox.
adapter per file
L'adapter di ricezione FILE recupera i messaggi da una cartella di file o da un percorso UNC. Questo adapter viene spesso utilizzato nelle società al posto di scenari Business to Business poiché richiede che entrambe le parti dispongano dell'autorizzazione al percorso e le società in genere non condividono i file system. L'adapter di ricezione per file deve essere configurato per sottoscrivere il percorso in modo che BizTalk Server possa recuperare il messaggio quando esso giunge all'indirizzo di ricezione.
BizTalk Server offre disponibilità elevata per la scheda di ricezione file consentendo di creare istanze host in più computer host che sottoscrivono lo stesso percorso UNC. Se si verifica un errore in un'istanza host in esecuzione in un computer host, la stessa istanza host in esecuzione in un altro computer host può recuperare il messaggio e renderlo persistente nel database MessageBox.
Adapter FTP
L'adapter di ricezione FTP non deve essere configurato per l'esecuzione in più host poiché utilizza il protocollo FTP per recuperare i file dal sistema di destinazione e tale protocollo non supporta il blocco dei file per garantire che più copie dello stesso file non vengano recuperate contemporaneamente quando si eseguono più istanze dell'adapter di ricezione FTP. L'adapter di ricezione FTP deve essere quindi configurato per l'esecuzione in un host BizTalk incluso in un cluster. Per altre informazioni, vedere Considerazioni sull'esecuzione dei gestori di adapter all'interno di un host cluster.
Adapter POP3
L'adapter di ricezione POP3 può essere configurato per l'esecuzione in più host a meno che il server POP3 in cui l'adapter esegue le operazioni di lettura consenta l'esecuzione di più connessioni simultanee alla stessa cassetta postale. In questo caso è possibile ottenere una disponibilità elevata per l'adapter POP3 configurando i gestori di ricezione dell'adapter POP3 affinché vengano eseguiti in un'istanza host di BizTalk inclusa in un cluster. Per altre informazioni, vedere Considerazioni sull'esecuzione dei gestori di adapter all'interno di un host cluster.
Adapter MSMQ
Per ottenere la disponibilità elevata, eseguire l'adapter di ricezione MSMQ in un host BizTalk cluster Windows nello stesso gruppo di cluster della risorsa MSMQ cluster. Per altre informazioni, vedere Considerazioni sull'esecuzione dei gestori di adapter all'interno di un host cluster.
Se il percorso di ricezione MSMQ viene ricevuto solo dalle code MSMQ in un server MSMQ remoto, è possibile ottenere la disponibilità elevata eseguendo l'host di ricezione MSMQ in più computer BizTalk nel gruppo BizTalk. Per garantire la disponibilità elevata per MSMQ, è necessario assicurarsi che il server MSMQ remoto usi il clustering di failover in Windows. Se si usano code transazionali, il server MSMQ remoto deve eseguire MSMQ 4.0 (Windows Server 2008) o versioni successive.
Adapter MQSeries
L'adapter Microsoft BizTalk per MQSeries funge da ponte tra BizTalk Server e server IBM MQSeries. Per garantire una soluzione a elevata disponibilità quando si utilizza questo adapter, è necessario disporre di più istanze dell'host che eseguono l'adapter MQSeries, utilizzare gestori di code in cluster in MQSeries per Windows e includere in un cluster il server MQSeries per Windows. Per ulteriori informazioni sull'inclusione in un cluster del gestore delle code e del server MQSeries, vedere la documentazione di IBM WebSphere MQ. Per ulteriori informazioni su come garantire un'elevata disponibilità per l'adapter MQSeries, vedere la sezione attinente della Guida dell'adapter Microsoft BizTalk per MQSeries.
Adapter Windows SharePoint Services
L'adapter Windows SharePoint Services recupera i messaggi da SharePoint richiamando il servizio Web di Windows SharePoint Services installato da BizTalk nel computer SharePoint. L'adapter utilizza un meccanismo di estrazione per garantire che diversi host non elaborino lo stesso messaggio. Ciò consente alla scheda di ricezione di aumentare il numero di istanze host aggiungendo altre istanze host. BizTalk Server offre disponibilità elevata per la scheda di ricezione di SharePoint consentendo di eseguire le stesse posizioni di ricezione in più istanze host che sottoscrivono lo stesso URL HTTP che punta a un'installazione del bilanciamento del carico di rete di SharePoint.
Adapter WCF-NetTcp
Per bilanciare il carico di NetTcpBinding è possibile utilizzare le tecniche di bilanciamento del carico del livello IP. NetTcpBinding, tuttavia, crea pool di connessioni TCP per impostazione predefinita in modo da ridurre la latenza delle connessioni. Si tratta di un'ottimizzazione che interferisce con il meccanismo di base del bilanciamento del carico. Il valore di configurazione primario per l'ottimizzazione di NetTcpBinding è il timeout lease, che fa parte di Impostazioni pool di connessioni. Il pool di connessioni fa in modo che le connessioni client siano associate a server specifici all'interno della farm. Con l'aumento della durata di tali connessioni (un fattore controllato dall'impostazione del timeout di lease), la distribuzione del carico nei vari server della farm diventa sbilanciata. Di conseguenza, la durata media delle chiamate aumenta. Pertanto, quando si utilizza NetTcpBinding in scenari con bilanciamento del carico, è consigliabile ridurre il timeout lease predefinito utilizzato dal binding. Un timeout di lease di 30 secondi è un punto di partenza ragionevole per scenari con carico bilanciato, sebbene il valore ottimale dipenda dall'applicazione. Per ulteriori informazioni sul timeout lease del canale e altre quote di trasporto, vedere Quote di trasporto.