Disponibilità elevata con gruppi di disponibilità SQL Server Always On - BizTalk Server

Configurare la disponibilità elevata usando SQL Server gruppi di disponibilità AlwaysOn.

Suggerimento

La configurazione BizTalk Server 2016 tramite lab dei gruppi di disponibilità offre una guida dettagliata scritta da un tecnico del campo Microsoft. Si basa su un ambiente lab e include alcune osservazioni. Guardalo fuori.

Importante

• BizTalk Server supporta Always On gruppi di disponibilità a partire da SQL Server 2016 e versioni successive. Se si usa una versione precedente di SQL Server, questo articolo non si applica all'utente.
• BizTalk Server supporta la modalità commit sincrona; la modalità commit asincrona non è supportata. Per il ripristino di emergenza, è consigliabile configurare il processo di backup BizTalk Server e usare il log shipping. Per informazioni dettagliate specifiche, vedere Backup e ripristino di database BizTalk Server.

Le modalità di disponibilità dettaglia le opzioni di commit con Always On gruppi di disponibilità.

Background e cronologia

BizTalk Server si basa su SQL Server per la persistenza dei dati. Altri componenti e host in BizTalk Server hanno ruoli specifici durante l'integrazione di applicazioni aziendali diverse, ad esempio la ricezione, l'elaborazione o il routing dei messaggi. Il computer di database acquisisce questo lavoro e lo mantiene su disco.

BizTalk usa SQL Server Clustering di failover e Log Shipping per offrire disponibilità elevata, backup e ripristino di emergenza per i database. In Azure IaaS (macchine virtuali di Azure), in precedenza BizTalk (Windows e SQL) non supportava istanze del cluster di failover perché non erano presenti dischi condivisi supportati, necessari per il clustering di SQL e MSDTC. Di conseguenza, BizTalk non ha una soluzione a disponibilità elevata quando si usano macchine virtuali di Azure. Poiché Il disco condiviso di Azure è ora disponibile, è possibile clusterare sia SQL che MSDTC nelle macchine virtuali di Azure. Istanza del cluster di failover SQL con Dischi condivisi di Azure è la soluzione più disponibile.

A partire da SQL Server 2016, SQL Server Gruppi di disponibilità AlwaysOn supporta MSDTC per le macchine virtuali di Azure e l'uso di macchine virtuali di Azure. Di conseguenza, la funzionalità AlwaysOn SQL Server 2016 (o versione successiva) è supportata per i database BizTalk locali o negli scenari di Azure IaaS. Poiché è presente un sovraccarico aggiuntivo con sincronizzazione del disco sincrona quando si usa Spazi di archiviazione diretta (S2D) e tempo aggiuntivo durante i failover, è meno disponibile rispetto all'istanza del cluster di failover SQL.

SQL Server gruppi di disponibilità AlwaysOn 2016

La distribuzione di gruppi di disponibilità AlwaysOn richiede un cluster WSFC (Windows Server Failover Clustering). Ogni replica di disponibilità di un determinato gruppo di disponibilità deve risiedere su un nodo diverso dello stesso cluster WSFC. Il gruppo di risorse WSFC viene creato per ogni gruppo di disponibilità che viene creato. Con il cluster WSFC è possibile eseguire il monitoraggio del gruppo di risorse per valutare lo stato di integrità della replica primaria.

Di seguito viene illustrato un gruppo di disponibilità contenente una replica primaria e quattro repliche secondarie.

I client possono connettersi alla replica primaria di un determinato gruppo di disponibilità usando un listener del gruppo di disponibilità. Un listener del gruppo di disponibilità fornisce un set di risorse associate a un determinato gruppo di disponibilità per indirizzare le connessioni client alla replica di disponibilità appropriata.

Importante

SQL Server 2016 supporta MSDTC con gruppi di disponibilità AlwaysOn in Windows Server 2016 e Windows Server 2012 R2. Windows Server 2012 R2 richiede l'installazione dell'hotfix di Windows 3090973. Windows Server 2016 richiede che la chiave del Registro di sistema RemoteAccessEnabled sia abilitata.

SQL Server non supporta MSDTC con AlwaysOn AG per le versioni precedenti al 2016. SQL Server 2016 SP2 migliorata la gestione delle transazioni MSDTC in modo che SP2 o versione successiva sia consigliata.

Fornire disponibilità elevata per i database BizTalk con gruppi di disponibilità AlwaysOn

Nella configurazione di base di BizTalk Server vengono creati almeno 9 database, inclusi regole e database BAM.

Prima di SQL Server 2016 SP2, i gruppi di disponibilità non supportavano MSDTC tra database nella stessa istanza SQL in modo che i database BizTalk devono essere distribuiti in un minimo di 4 istanze SQL. A causa di questa limitazione, è consigliabile usare SQL Server 2016 SP2 (o versioni successive) e BizTalk Server 2016 CU5 (o versioni successive) in modo che tutti i database BizTalk possano usare la stessa istanza SQL Server. È comunque possibile considerare l'uso di più di un'istanza SQL per motivi di prestazioni, ad esempio la presenza di MessageBox in un'istanza SQL diversa.

In uno scenario MessageBox con scalabilità orizzontale (una configurazione con più di un messageBox), è presente più di un database MessageBox e ogni database MessageBox deve essere aggiunto al gruppo di disponibilità.

BizTalk Server dipende anche da SQL Server Analysis Services e SQL Server Integration Services per L'analisi BAM e l'archiviazione. SQL Server non offre una soluzione a disponibilità elevata per Integration Services o Analysis Services in Azure IaaS. È pertanto consigliabile usare un'altra istanza autonoma di SQL Server per i database BAMArchive e BAMAnalysis Analysis Services. Per le installazioni locali, l'istanza del clustering di failover SQL può essere usata per configurare una configurazione a disponibilità elevata.

Per BizTalk Server 2016, questa configurazione viene visualizzata nell'immagine seguente e consigliata per i database BizTalk nei gruppi di disponibilità (come indicato in precedenza, a partire da SQL 2016 SP2 e BizTalk 2016 CU5, 4 istanze SQL non sono più necessarie):

A partire da BizTalk Server 2020, la disponibilità elevata per i pacchetti BAM DTS è supportata tramite il catalogo SSIS. Aggiungere il database SSISDB allo stesso gruppo di disponibilità dei database di BizTalk Server. Questa configurazione viene visualizzata nell'immagine seguente e consigliata per i database BizTalk nei gruppi di disponibilità (come indicato in precedenza, 4 istanze SQL non sono più necessarie):

Oltre ai database SQL Server, la configurazione BizTalk Server crea anche SQL Server account di accesso alla sicurezza e processi di SQL Agent. I gruppi di disponibilità AlwaysOn offrono solo la possibilità di gestire i database all'interno di un gruppo di disponibilità. In tutte le repliche di disponibilità, è necessario creare e aggiornare manualmente gli account di accesso BizTalk Server e i processi di SQL Agent.

L'elenco seguente di account di accesso alla sicurezza SQL Server è associato a BizTalk Server. È possibile che siano stati creati altri account di accesso per le applicazioni BizTalk Server. In tal caso, è necessario replicarli in ogni istanza di SQL Server che ospita una replica di database BizTalk.

1. Utenti dell'applicazione BizTalk (uno o più corrispondenti a ogni host in-proc)
2. Utenti host isolati bizTalk (uno o più corrispondenti a ogni host isolato)
3. Amministratori BizTalk Server
4. Operatori B2B BizTalk Server
5. Operatori BizTalk Server
6. Amministratori SSO
7. Utente avvisi BAM
8. Utente del servizio Web di gestione BAM
9. Account del servizio aggiornamento motore regole

Se sono stati creati host aggiuntivi o verranno creati altri host in un secondo momento, verranno creati nuovi account di accesso SQL come parte di questo processo. È necessario assicurarsi di creare manualmente questi account di accesso SQL nelle repliche corrispondenti.

I seguenti processi di SQL Server Agent sono associati a BizTalk Server. I processi installati in ogni server dipendono dalle funzionalità installate e configurate. La maggior parte di questi processi viene creata durante la configurazione di BizTalk Server. Molti di essi vengono creati durante la configurazione per il log shipping. Questi processi devono essere replicati in ogni istanza di SQL Server replica di hosting del database BizTalk corrispondente. Questa operazione deve essere eseguita manualmente.

• Processi BizTalkMgmtDb:
  • Backup di BizTalk Server (BizTalkMgmtDb)
  • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
  • Monitoraggio BizTalk Server (BizTalkMgmtDb)
• Processi BizTalkMsgBoxDb:
  • MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb
  • MessageBox_Message_Cleanup_BizTalkMsgBoxDb
  • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
  • MessageBox_Parts_Cleanup_BizTalkMsgBoxDb
  • MessageBox_UpdateStats_BizTalkMsgBoxDb
  • Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb
  • PurgeSubscriptionsJob_BizTalkMsgBoxDb
  • TrackedMessages_Copy_BizTalkMsgBoxDb
• Processi in msgbox aggiuntivi
• Processo BizTalkDTADb:
  • DTA Purge and Archive (BizTalkDTADb)
• Processo BizTalkRulesEngineDb:
  • Rules_Database_Cleanup_BizTalkRuleEngineDb
• Processo BAMAlertsApplication:
  • 0 o più DelAlertHistJob

A differenza delle istanze di clustering di failover SQL, nei gruppi di disponibilità tutte le repliche sono attive, in esecuzione e disponibili. Quando i processi di SQL Agent vengono duplicati in ogni replica per il failover, vengono eseguiti sulla replica corrispondente, indipendentemente dal fatto che sia attualmente nel ruolo primario o secondario. Per assicurarsi che questi processi vengano eseguiti solo nella replica primaria corrente, ogni passaggio in ogni processo deve essere racchiuso all'interno di un blocco IF, come illustrato di seguito:

IF (sys.fn_hadr_is_primary_replica(‘dbname’) = 1)  
BEGIN  
…  
END

Sostituire ‘dbname’ con il nome del database corrispondente in base al quale il processo è configurato per l'esecuzione. L'esempio seguente illustra questa modifica per TrackedMessages_Copy_BizTalkMsgBoxDb in BizTalkMsgBoxDb:

Configurare BizTalk quando i gruppi di disponibilità sono già configurati

1. Controllare i requisiti del sistema operativo:
   • In tutti i computer Windows Server 2012 R2 installare l'hotfix MSDTC 3090973 (apre un articolo della Knowledge Base).
   • In tutti i computer Windows Server 2016 abilitare la chiave del Registro di sistema RemoteAccessEnabled (apre un articolo della Knowledge Base).
2. Creare i gruppi di disponibilità necessari. Assicurarsi che i gruppi di disponibilità vengano creati con l'opzione Supporto DTC per database .
3. Quando si configura BizTalk Server e si specifica il nome del server SQL, usare il nome del listener del gruppo di disponibilità anziché il nome effettivo del computer. In questo modo vengono creati i database BizTalk, gli account di accesso e i processi di SQL Agent nella replica primaria corrente.
4. Arrestare l'elaborazione BizTalk (istanze host, servizio SSO, IIS, servizio di aggiornamento del motore regole, servizio BAMAlerts e così via) e arrestare i processi di SQL Agent.
5. Aggiungere ora i database BizTalk ai rispettivi gruppi di disponibilità.
6. Racchiudere il corpo dei passaggi del processo di SQL Agent all'interno IF del blocco (menzionato in precedenza) per assicurarsi che vengano eseguiti solo se la destinazione è la replica primaria.
7. Script di accesso e processi di SQL Agent per replicarli nella replica corrispondente.
8. Replicare il profilo DBMail SQL e l'account per gli avvisi BAM nelle istanze SQL corrispondenti che ospitano la replica secondaria.
9. Se si aggiunge un database aggiuntivo della finestra di messaggio o si distribuisce una nuova attività/vista BAM in un secondo momento, vengono creati nuovi processi SQL per i nuovi database della finestra di messaggio o il database degli avvisi BAM nella replica primaria corrente. Assicurarsi di modificarlo nella replica primaria e quindi crearli manualmente nelle repliche secondarie corrispondenti.
10. A partire da BizTalk Server 2020 e versioni successive, i pacchetti BAM DTS vengono distribuiti nel catalogo SSIS. Aggiungere il database SSISDB allo stesso gruppo di disponibilità dei database BizTalk. Per altre informazioni, vedere AlwaysON per il catalogo SSIS.

Questa configurazione può essere eseguita anche usando le istanze DI SQL che ospitano la replica primaria. In questo caso, dopo la configurazione bizTalk, eseguire gli UpdateDatabase.vbs script e UpdateRegistry.vbs nei computer BizTalk dopo i passaggi precedenti. Questo argomento viene descritto in modo più dettagliato nella sezione successiva.

Spostare i database BizTalk esistenti in gruppi di disponibilità

1. Controllare i requisiti del sistema operativo:

   • In tutti i computer Windows Server 2012 R2 installare l'hotfix MSDTC 3090973 (apre un articolo della Knowledge Base)
   • In tutti i computer Windows Server 2016 abilitare la chiave del Registro di sistema RemoteAccessEnabled (apre un articolo della Knowledge Base)

2. Creare i gruppi di disponibilità necessari. Assicurarsi che il gruppo di disponibilità sia stato creato con l'opzione Supporto DTC per database .

3. Arrestare l'elaborazione BizTalk e i processi di SQL Agent.

4. Eseguire il backup completo di tutti i database BizTalk.

5. Ripristinare i database BizTalk nelle istanze SQL attualmente presenti nel ruolo primario nel gruppo di disponibilità.

6. Script di account di accesso e processi di SQL Agent nelle istanze SQL corrispondenti attualmente nel ruolo primario nel gruppo di disponibilità.

7. Eseguire gli UpdateDatabase.vbs script e UpdateRegistry.vbs nei computer BizTalk seguendo questa procedura. Immettere il listener del gruppo di disponibilità come nuovo nome del server nel file xml delle informazioni di aggiornamento di input.

   1. Arrestare tutti i servizi BizTalk e i servizi Enterprise SSO in BizTalk Server. Arrestare il servizio SQL Agent in SQL Server.

   2. In BizTalk Server modificare SampleUpdateInfo.xml nella cartella seguente:

      Computer a 32 bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Computer a 64 bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      1. Sostituire "SourceServer" con il nome del server di origine (precedente SQL Server che ospita i database precedenti).
      2. Sostituire "DestinationServer" con il nome del server di destinazione, che deve essere il nome del listener del gruppo di disponibilità.
      3. Se si dispone di BAMAnalysis, database BAM o RuleEngineDB, rimuovere il commento dalle sezioni appropriate.

   3. Aprire un prompt dei comandi e passare a:

      Computer a 32 bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Computer a 64 bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      Al prompt dei comandi eseguire:
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      Eseguire UpdateDatabase.vbs in un solo server del gruppo BizTalk.

   4. Copiare il file SampleUpdateInfo.xml modificato nella cartella seguente in ogni computer BizTalk Server in questo gruppo BizTalk:

      Computer a 32 bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Computer a 64 bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

   5. In ogni computer del gruppo BizTalk Server aprire un prompt dei comandi e passare a:

      Computer a 32 bit: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      Computer a 64 bit: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      Al prompt dei comandi eseguire:
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      Eseguire UpdateRegistry.vbs in ogni server del gruppo BizTalk.

8. Spostare ora i database nei rispettivi gruppi di disponibilità.

9. Replicare il profilo DBMail SQL e l'account per gli avvisi BAM nelle istanze SQL che ospitano la replica del database BAMAlerts.

10. Racchiudere il corpo dei passaggi del processo di SQL Agent all'interno di un blocco IF per assicurarsi che vengano eseguiti solo se la destinazione è primaria.

11. Script di account di accesso e processi di SQL Agent per replicarli nella replica corrispondente. Lo script UpdateDatabase aggiorna anche il nome del server nei processi Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb e TrackedMessages_Copy_BizTalkMsgBoxDb. Creare quindi script per i processi di SQL Agent solo dopo l'esecuzione dello script UpdateDatabase.

Requisiti

• BizTalk Server:
  • BizTalk Server 2020 Enterprise
  • BizTalk Server 2016 Enterprise CU5
• SQL Server:

  • SQL Server 2019 Enterprise o Standard

  • SQL Server 2017 Enterprise o Standard

  • SQL Server 2016 Enterprise o Standard.

    Vedere Limitazioni note in questo articolo per la limitazione di SQL Server Standard Edition.

• Windows Server
  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2

Listener del gruppo di disponibilità configurato con porta non predefinita (1433)

Usare l'alias SQL nei computer BizTalk Server.

Gruppi di disponibilità su più subnet

BizTalk Server non supporta l'opzione di connessione MultiSubnetFailover (=TRUE).

Per altre informazioni sui problemi che possono verificarsi durante la connessione di un client SQL che non supporta questa opzione a un gruppo di disponibilità SQL su più subnet, vedere la documentazione di SQL. Alcuni di questi problemi sono descritti nei collegamenti seguenti:

• Timeout di connessione in un gruppo di disponibilità su più subnet
• Latenza di recupero del client durante i failover

Routing di sola lettura

Il routing di sola lettura fa riferimento alla possibilità di SQL Server di instradare le connessioni in ingresso per un listener del gruppo di disponibilità a una replica secondaria configurata per consentire carichi di lavoro di sola lettura.

BizTalk non usa Read-Only Routing per le connessioni ai relativi database. Ciò significa che l'opzione "Secondario leggibile" nelle repliche di disponibilità nel gruppo di disponibilità non ha alcun impatto sui connessioni alle banche dati BizTalk.

Comportamento delle istanze dell'host BizTalk durante il failover di SQL Server

Se il gruppo di disponibilità SQL Server riscontra un failover, i database BizTalk Server nel gruppo di disponibilità non sono temporaneamente disponibili.

Comportamento delle istanze host di tipo In-Process in caso di failover di SQL Server

Se i database BizTalk Server non sono disponibili, viene riciclata un'istanza in-process di un host BizTalk Server finché non viene ripristinata la connessione al SQL Server. Una volta ripristinata la connessione ai database SQL Server, l'elaborazione dei documenti riprende normalmente.

Comportamento delle istanze host di tipo Isolato in caso di failover di SQL Server

Se i database di BizTalk Server non sono disponibili, un'istanza isolata di un host BizTalk Server viene sospesa e viene generato un errore simile al seguente nel registro applicazioni di BizTalk Server:

All receive locations are being temporarily disabled because either the MessageBox or Configuration database is not available. When these databases become available, the receive locations will be automatically enabled.

Dopo aver ripristinato la connessione ai database SQL Server, viene scritto un messaggio informativo simile al seguente nel log dell'applicazione di BizTalk Server e quindi l'elaborazione dei documenti riprende normalmente:

All receive locations are being enabled because both the MessageBox and Configuration databases are back online.

Log Shipping per il ripristino di emergenza

BizTalk Server implementa funzionalità di standby del database tramite l'uso del log shipping del database. BizTalk Server log shipping automatizza il backup e il ripristino dei database e dei relativi file di log delle transazioni, consentendo a un server standby di riprendere l'elaborazione del database nel caso in cui il server di database di produzione non riesca.

I database secondari nel gruppo di disponibilità non sono backup. Continuare a eseguire il backup dei database BizTalk e dei log delle transazioni usando i processi di log shipping BizTalk Server. La modalità di implementazione di BizTalk Log Shipping garantisce che i backup vengano sempre eseguiti sulla replica primaria corrente di ogni database. L'impostazione delle preferenze di backup nel gruppo di disponibilità non viene rispettata dai processi di log shipping di BizTalk Server.

Se si aggiungono altri database BizTalk al processo di backup dei database BizTalk, assicurarsi di usare il nome listener del gruppo di disponibilità come server di database per loro durante la configurazione del backup.

Riferimenti

• Elevata disponibilità dei database BizTalk Server
• Microsoft server software support for Microsoft Azure virtual machines (Supporto software di server Microsoft per macchine virtuali di Microsoft Azure)
• Mirroring del database SQL Server, servizio Copia Shadow del volume e AlwaysOn
• Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
• Supporto delle transazioni tra database per il mirroring del database o i gruppi di disponibilità AlwaysOn (SQL Server)
• Impossibile chiamare reenlist quando SQL Server riceve il risultato delle transazioni da MSDTC in Windows Server 2012 R2
• Eseguire il backup e il ripristino di database di BizTalk Server
• Come spostare i database BizTalk Server
• Come ripristinare i database
• Timeout di connessione in un gruppo di disponibilità su più subnet

Limitazioni note

Queste limitazioni sono per BizTalk Server, SQL Server Gruppo di disponibilità AlwaysOn e Azure Macchine virtuali. Queste limitazioni potrebbero o non essere risolte in futuro.

• Gli account di accesso, i processi di SQL Agent, il profilo di posta elettronica sql e gli account non vengono gestiti all'interno dei gruppi di disponibilità. Ciò richiede la modifica manuale nei processi per assicurarsi che vengano eseguiti nella replica primaria.

• SQL Server Analysis Services e SQL Server Integration Services non partecipano ai gruppi di disponibilità. Senza questo supporto da SQL Server, non è disponibile alcuna soluzione di disponibilità elevata per questi elementi in Azure Macchine virtuali. le funzionalità BAM di BizTalk Server dipendono da questi servizi.

• Prima di SQL Server 2016 SP2, i gruppi di disponibilità non supportano MSDTC tra database nella stessa istanza DI SQL.

  A partire da SQL Server 2016 SP2 e BizTalk Server 2016 CU5, i database BizTalk possono usare la stessa istanza SQL Server.

• BizTalk Server non è possibile usare Read-Only Routing.

• BizTalk Server non imposta la MultiSubnetFailover proprietà di connessione.

• I processi di backup BizTalk che usano Log Shipping saranno sempre destinati alla replica primaria indipendentemente dalla preferenza di backup impostata nel gruppo di disponibilità.

• SQL Server 2016 Standard supporta solo un singolo database in ogni gruppo di disponibilità Sql AlwaysOn. Poiché BizTalk usa molti database, è in genere consigliabile SQL Server Enterprise edizione.

• Se si usano macchine virtuali di Azure, è consigliabile usare una porta TCP/IP dedicata per MSDTC. Quando si usa una porta TCP/IP fissa, non si limita l'intervallo di porte RPC in genere usato con sistemi operativi meno recenti; e consente di semplificare le regole del firewall e del servizio di bilanciamento del carico. Per evitare conflitti con porte inferiori note, prendere in considerazione l'uso di una porta fissa superiore (ad esempio >20000). La configurazione del supporto per la porta singola DTC descrive la chiave del ServerTcpPort Registro di sistema. Oltre alla porta fissa per MSDTC, viene usata anche la porta RPC principale 135.

Passaggi successivi

Pianificare la tolleranza di errore.