Alta Disponibilidade usando o SQL Server Sempre Em Grupos de Disponibilidade do BizTalk Server

• 01/14/2020
• 13 minutos de leitura
• • M
  • m
  • p
  • n
  • w
  • +8

Configurar a alta disponibilidade usando o SQL Server grupos de disponibilidade AlwaysOn.

Background and history

BizTalk Server reles heavily on SQL Server for data persistence. Outros componentes e hosts no servidor BizTalk têm papéis específicos ao integrar aplicações empresariais díspares, tais como receber, processar ou roteamento de mensagens. O computador do banco de dados captura este trabalho, e persiste-o ao disco.

BizTalk usa Clustering de servidores SQL e Log Shipping para fornecer alta disponibilidade, backup e restauração, e recuperação de desastres para suas bases de dados nas instalações. In Azure IaaS( Azure virtual machines), previous versions of SQL Server do not support Failover Cluster Instances (no MSDTC support). Como resultado, BizTalk não tinha uma solução HA quando usava Azure VMs.

começando com o SQL Server 2016, o SQL Server AlwaysOn Availability Groups suporta MSDTC para on-premises e usando Azure VMs. Como resultado, a funcionalidade AlwaysOn do SQL Server 2016 é suportada para bases de dados BizTalk nas instalações ou em cenários Azure IaaS.

SQL Server 2016 AlwaysOn Availability Groups

implanting AlwaysOn Availability Groups requires a Windows Server Failover Clustering (WSFC) cluster. Cada réplica de disponibilidade de um determinado grupo de disponibilidade deve residir em um nó diferente do mesmo cluster WSFC. Um grupo de recursos WSFC é criado para cada grupo de disponibilidade que você cria. O cluster WSFC monitora este grupo de recursos para avaliar a saúde da réplica primária.

a seguinte ilustração mostra um grupo de disponibilidade que contém uma réplica primária e quatro réplicas secundárias.

os Clientes podem conectar-se à réplica de um determinado grupo de disponibilidade usando um ouvinte de grupo de disponibilidade. Um ouvinte de grupo de disponibilidade fornece um conjunto de recursos que são anexados a um determinado grupo de disponibilidade para direcionar as conexões do cliente para a réplica de disponibilidade apropriada.

SQL Server does not support MSDTC with AlwaysOn AG for any versions prior to 2016.

fornecer alta disponibilidade para bases de dados BizTalk usando AlwaysOn Availability Groups

na configuração básica do servidor BizTalk, um mínimo de 9 bases de dados são criadas incluindo regras e bases de dados BAM.

em um cenário de MessageBox escalado (uma configuração com mais de uma MessageBox), há mais de uma base de dados MessageBox, e cada base de dados MessageBox deve ser adicionada ao grupo de disponibilidade.

BizTalk Server also depends on SQL Server Analysis Services and SQL Server Integration Services for BAM Analysis and Archiving. O SQL Server não oferece uma solução de alta disponibilidade para Serviços de integração ou serviços de análise em Azure IaaS. Por conseguinte, recomenda-se a utilização de outra instância independente do servidor SQL para as bases de dados dos Serviços de análise BAMArchive e BAMAnalysis. Para as instalações nas instalações, a instância de Clustering de falhas SQL pode ser utilizada para configurar uma configuração de alta disponibilidade.

para o servidor BizTalk 2016 e mais antigo, esta configuração é mostrada na seguinte imagem, e recomendada para bases de dados BizTalk em grupos de disponibilidade:

começando com o BizTalk Server 2020 e mais recente, alta disponibilidade para pacotes BAM DTS é suportado usando o catálogo SSIS. Adicione a base de dados SISSDB ao mesmo grupo de disponibilidade que as bases de dados do servidor BizTalk. Esta configuração é mostrada na seguinte imagem, e recomendada para bases de dados BizTalk em grupos de disponibilidade:

além das bases de dados do servidor SQL, a configuração do servidor BizTalk também cria logins de segurança do servidor SQL e empregos do Agente SQL. AlwaysOn os grupos de Disponibilidade apenas oferecem a capacidade de gerenciar bases de dados dentro de um grupo de disponibilidade. Em todas as réplicas de disponibilidade, os logins do servidor BizTalk e os empregos do Agente SQL precisam ser criados e atualizados manualmente.

a seguinte lista de logins de segurança do servidor SQL está associada com o servidor BizTalk. Você pode ter logins adicionais criados para suas aplicações do servidor BizTalk. Se assim for, você precisa replicá-los em cada instância do servidor SQL hospedando uma réplica de bases de dados BizTalk.

1. Usuários de Aplicativo do BizTalk (um ou mais correspondentes a cada um no-proc Host)
2. Usuários do BizTalk Isolado Host (um ou mais correspondentes para cada Host Isolado)
3. Administradores do BizTalk Server
4. BizTalk Server B2B Operadores
5. BizTalk Server Operadores
6. Administradores de SSO
7. Alertas BAM User
8. BAM Web Service de Gerenciamento do Usuário
9. Regra de Atualização do Mecanismo de Conta de Serviço

Se você tiver criado adicional de hosts ou vai criar hosts adicionais mais tarde, haverá novos inícios de sessão SQL criado como parte de processo. Você deve certificar-se de criar estes logins SQL manualmente nas réplicas correspondentes.

as seguintes tarefas de agentes de servidores SQL estão associadas com o servidor BizTalk. As tarefas instaladas em cada servidor são diferentes, dependendo das funcionalidades instaladas e configuradas. A maioria destes empregos são criados durante a configuração do servidor BizTalk. Várias são criadas ao configurar o envio de log. Estas tarefas precisam ser replicadas em cada instância do servidor SQL hospedando réplica de seu banco de dados BizTalk correspondente. Isto deve ser feito manualmente.

• BizTalkMgmtDb jobs:
  • Backup BizTalk Server (BizTalkMgmtDb)
  • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
  • Monitor BizTalk Server (BizTalkMgmtDb)
• BizTalkMsgBoxDb jobs:
  • 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
• Jobs on additional msgboxes
• BizTalkDTADb job:
  • DTA Limpar e Arquivamento (BizTalkDTADb)
• BizTalkRulesEngineDb trabalho:
  • Rules_Database_Cleanup_BizTalkRuleenginedb
• BAMAlertsApplication trabalho:
  • 0 ou mais DelAlertHistJob

ao contrário do SQL Instâncias de Cluster de Failover, em Grupos de Disponibilidade de todas as réplicas estão ativos, execução e disponível. Quando os empregos de agentes SQL são duplicados em cada réplica para failover, eles correm contra a réplica correspondente, independentemente de estar atualmente em papel primário ou Secundário. Para garantir que estas tarefas são executadas apenas na réplica primária atual, cada passo em cada tarefa deve ser fechado dentro de um bloco IF, Como mostrado:

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

substitua 'dbname' pelo nome correspondente da base de dados com o qual a tarefa está configurada para correr. O exemplo seguinte mostra esta alteração para Trackedmessages_copy_ BizTalkMsgBoxDb no BizTalkMsgBoxDb:

Configurar o BizTalk quando a Disponibilidade de Grupos já estão configurados

1. Verificar se o seu sistema operacional requisitos:
   • Em todos os Windows Server 2012 R2 computadores, instalar o 3090973 MSDTC hotfix (abre um artigo da KB).
   • em todos os computadores Windows Server 2016, permitir a chave de Registo RemoteAccessEnabled (abre um artigo KB).
2. criar os grupos de disponibilidade necessários. Certifique-se de que os grupos de disponibilidade são criados com a opção de suporte DTC por banco de dados.
3. ao configurar o servidor BizTalk e especificar o nome do servidor SQL, use o nome do ouvinte do grupo de disponibilidade em vez do nome da máquina real. Isso cria as bases de dados BizTalk, logins e Empregos de agentes SQL na réplica primária atual.
4. parar o processamento BizTalk (instâncias Host, serviço SSO, IIS, serviço de atualização do motor de regras, serviço BAMAlerts, e assim por diante), e parar os empregos de agentes SQL.
5. Agora adicione bases de dados BizTalk aos respectivos grupos de disponibilidade.
6. incluir o corpo de agentes SQL passos de trabalho dentro de IF bloco (mencionado anteriormente) para se certificar de que eles correm apenas se o alvo é a réplica primária.
7. Script Logins and SQL Agent Jobs to replicate them on corresponding replica.
8. replicar o perfil DBMAIL SQL e ter em conta os alertas BAM sobre as instâncias SQL correspondentes que hospedam a réplica secundária.
9. se estiver a adicionar uma base de dados de caixa de mensagens adicional ou a lançar uma nova actividade/Vista BAM mais tarde, serão criados novos postos de trabalho em SQL para novas bases de dados de caixa de mensagens ou bases de dados de alertas BAM na réplica primária actual. Certifique-se de editá-lo em réplica primária, e, em seguida, criá-los manualmente nas réplicas secundárias correspondentes.
10. começando com o BizTalk Server 2020 e mais recente, pacotes BAM DTS são implantados no catálogo SSIS. Adicione o banco de dados SISSDB ao mesmo grupo de disponibilidade que o banco de dados BizTalk. Para mais informações, consulte AlwaysON para o catálogo SSIS.

esta configuração também pode ser feita usando as instâncias SQL hospedando a réplica primária. Neste caso, após a configuração BizTalk, execute os scripts UpdateDatabase.vbs e UpdateRegistry.vbs nas máquinas BizTalk após os passos acima. Isto é discutido em mais detalhes na próxima seção.

Mover bancos de dados do BizTalk para Grupos de Disponibilidade

1. Verifique o seu sistema operacional requisitos:

   • Em todos os Windows Server 2012 R2 computadores, instalar o 3090973 MSDTC hotfix (abre um artigo da KB)
   • Em todos os Windows Server 2016 computadores, permitem a RemoteAccessEnabled chave de registo (abre um artigo do KB)

2. Criar a necessária Disponibilidade de Grupos. Certifique-se de que o grupo de disponibilidade é criado com a opção de suporte DTC por banco de dados.

3. parem o processamento BizTalk e os empregos de agentes SQL.

4. Faça uma cópia completa de segurança de todas as bases de dados BizTalk.

5. restaurar bases de dados BizTalk nas instâncias SQL atualmente no papel principal no grupo de disponibilidade.

6. Logins de Script e empregos de Agente SQL nas instâncias SQL correspondentes atualmente no papel principal no grupo de disponibilidade.

7. execute os scripts UpdateDatabase.vbs e UpdateRegistry.vbs nas máquinas BizTalk usando os seguintes passos. Indique o ouvinte do grupo de disponibilidade como o novo nome do servidor no XML de informação de actualização de entrada.

   1. parar todos os Serviços BizTalk e Enterprise SSO services em BizTalk Server. Parar o serviço de agentes SQL no servidor SQL.

   2. no servidor BizTalk, edite SampleUpdateInfo.xml na seguinte pasta:

      computador de 32 bits: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-computador de bits: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      1. substituir o “SourceServer” pelo nome do servidor de código (antigo servidor SQL que hospedava bases de dados antigas).
      2. substitua “DestinationServer” pelo nome do servidor de destino, que deve ser o nome do ouvinte do grupo de disponibilidade.
      3. se tiver BAMAnalysis, bases de dados BAM ou RuleEngineDB, descomentar as secções apropriadas.

   3. abrir uma linha de comandos e ir para:

      32-bit computer: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-computador de bits: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      na linha de comandos, executar:
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      executar Updatatabase.vbs em apenas um servidor no grupo BizTalk.

   4. copia o SampleUpdateInfo editado.arquivo xml para a pasta seguinte em cada computador do BizTalk Server neste grupo do BizTalk:

      computador de 32 bits: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-bits de computador: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

   5. Em cada computador no grupo do BizTalk Server, abra um prompt de comando e vá para:

      computador de 32 bits: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64-bits de computador: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      No prompt de comando, execute:
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      Executar UpdateRegistry.vbs em todos os servidores do Grupo BizTalk.

8. agora mova as bases de dados para seus respectivos grupos de disponibilidade.

9. replicar o perfil DBMAIL SQL e contabilizar alertas BAM nas instâncias SQL que hospedam a réplica da base de dados BAMAlerts.

10. coloque o corpo do Agente SQL passos de trabalho dentro de um bloco IF para se certificar de que eles correm apenas se o alvo é o principal.

11. Logins de Script e tarefas de Agente SQL para replicá-los na réplica correspondente. O script Updatabase também atualiza o nome do servidor nas tarefas Operations_ Operateoninstances_onmaster_biztalkmsgboxdb e TrackedMessages_Copy_BizTalkMsgBoxdb. Então script the SQL Agent Jobs only after running the Updatabase script.

Requisitos

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

  • o SQL Server 2019 Enterprise ou Standard

  • o SQL Server De 2017, Enterprise ou Standard

  • o SQL Server De 2016, Enterprise ou Standard.

    See Known limitations in this article for SQL Server Standard Edition limitation.

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

Ouvinte de Grupo de Disponibilidade configurado com porta não padrão (1433)

Usar o SQL alias no BizTalk Server máquinas.

Support Availability Group multi-Subnet Failovers

BizTalk Server uses Microsoft OLE DB for database connections, which does not support the MultiSubnetFailover connection option. O servidor BizTalk não suporta a opção de conexão MultiSubnetFailover (=TRUE), e isso pode causar maior tempo de recuperação durante o failover multi-sub-rede.

roteamento apenas para leitura

roteamento apenas para leitura refere-se à capacidade do servidor SQL de encaminhar conexões de entrada para um ouvinte de grupo de disponibilidade para uma réplica secundária que é configurada para permitir cargas de trabalho apenas para leitura.

BizTalk não usa roteamento apenas de leitura para qualquer uma das conexões com suas bases de dados. Isto significa que a opção” readable Secondary ” sobre réplicas de disponibilidade no grupo de disponibilidade não tem qualquer impacto sobre conexões de banco de dados BizTalk.

comportamento das instâncias do servidor BizTalk durante a falha do servidor SQL

se o grupo de disponibilidade do servidor SQL experimentar uma falha, as bases de dados do servidor BizTalk no grupo de disponibilidade estão temporariamente indisponíveis.

comportamento de instâncias hospedeiras em processo durante a falha do servidor SQL

se as bases de dados do servidor BizTalk estão indisponíveis, então uma instância em processo de uma máquina do servidor BizTalk é reciclada até que a conexão ao servidor SQL seja restaurada. Uma vez que a conexão com as bases de dados do servidor SQL é restaurada, o processamento de documentos recomeça normalmente.

Comportamento dos Isolados Instâncias de Host Durante o Failover do SQL Server

Se as bases de dados BizTalk Server não estão disponíveis e, em seguida, um exemplo isolado de um host do BizTalk Server faz uma pausa, e um erro semelhante à seguinte é gerada no log do Aplicativo 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.

uma Vez que a conexão para o SQL Server bancos de dados é restaurado, uma mensagem informativa semelhante à seguinte é escrito no registo de aplicações BizTalk Server, e, em seguida, processamento de documentos, currículos normalmente:

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

Log Shipping for Disaster Recovery

BizTalk Server implements database standby capabilities through the use of database log shipping. BizTalk Server log shipping automates the backup and restore of databases and their transaction log files, allowing a standby server to return database processing in the event that the production database server fails.

bases de dados secundárias no grupo de disponibilidade não são cópias de segurança. Continue a fazer backup dos bancos de dados BizTalk e seus logs de transação usando os trabalhos de registro de servidores BizTalk. A forma como o BizTalk Log Shipping é implementado garante que backups são sempre realizados contra a réplica primária atual de cada banco de dados. A configuração de preferência de backup no grupo de disponibilidade não é honrada pelos trabalhos de envio de Log do servidor BizTalk.

se você está adicionando outras bases de dados BizTalk para o trabalho de Backup de bases de dados BizTalk, certifique-se de usar o nome listener do grupo de disponibilidade como o servidor de banco de dados para eles ao configurar o Backup.

• Fornecer Alta Disponibilidade para Bancos de dados BizTalk Server
• software de servidor do Microsoft suporte para o Microsoft Azure máquinas virtuais
• SQL Server espelhamento de banco de dados, Cópia de Sombra de Volume de serviço e AlwaysOn
• Visão geral de Grupos de Disponibilidade AlwaysOn (SQL Server)
• Cross-Transacções de base de Dados do Suporte Para Espelhamento de Banco de dados ou Grupos de Disponibilidade AlwaysOn (SQL Server)
• Reenlist não pode ser chamado quando o SQL Server recebe o resultado da transação do ms dtc no Windows Server 2012 R2
• Backup e Restauração de BizTalk Server Bases de dados
• Como Mover os Bancos de dados BizTalk Server
• Como Restaurar Seus Bancos de dados
• tempos limite de Conexão Multi-sub-rede de Grupo de Disponibilidade

limitações Conhecidas

Estas limitações são para o BizTalk Server, o SQL Server Grupo de Disponibilidade AlwaysOn, e Azure Máquinas Virtuais. Estas limitações podem ou não ser abordadas no futuro.

• Logins, SQL Agent Jobs, the SQL DB Mail profile, and accounts are not managed within Availability Groups. Isso requer modificação manual em trabalhos para garantir que eles correm contra a réplica primária.

• os Serviços de Análise de servidores SQL e os Serviços de integração de servidores SQL não participam em grupos de disponibilidade. Sem este suporte do servidor SQL, não há solução HA para estes em máquinas virtuais Azure. As capacidades BAM do servidor BizTalk são dependentes desses serviços.

• antes do SQL Server 2016 SP2, grupos de disponibilidade não suportam MSDTC entre bases de dados na mesma instância SQL.

  começando com SQL Server 2016 SP2 e BizTalk Server 2016 CU5, as bases de dados BizTalk podem usar a mesma instância de servidor SQL.

• o servidor BizTalk não pode usar roteamento apenas para leitura.

• o servidor BizTalk não define a propriedade de conexão MultiSubnetFailover.

• os trabalhos de Backup da BizTalk usando Log Shipping sempre terão como alvo a réplica primária, independentemente da preferência de backup definida no grupo de disponibilidade.

• SQL Server 2016 Standard suporta apenas um banco de dados em cada SQL AlwaysOn AG. Uma vez que BizTalk usa muitos bancos de dados, SQL Server Enterprise edition é tipicamente recomendado.

• se usar o Azure VMs, recomenda-se a utilização de uma porta TCP/IP fixa dedicada para o MSDTC. Ao usar uma porta TCP/IP fixa, não está a limitar a sua gama de portas RPC normalmente utilizada com sistemas operativos mais antigos; e ajuda a simplificar as suas regras de firewall e de balanceamento de carga. Para evitar conflitos com portos inferiores conhecidos, considere o uso de um porto fixo superior (como >20000). A configuração do suporte de porta única DTC descreve a chave de Registo ServerTcpPort. Além da porta fixa para MSDTC, a principal porta RPC 135 também é usada.

plano para tolerância a falhas.