Alta disponibilidad con Grupos de disponibilidad Always On de SQL Server-BizTalk Server

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

Configure la alta disponibilidad mediante grupos de disponibilidad de SQL Server AlwaysOn.

Antecedentes e historial

BizTalk Server depende en gran medida de SQL Server para la persistencia de datos. Otros componentes y hosts en BizTalk Server tienen roles específicos al integrar aplicaciones empresariales dispares, como recibir, procesar o enrutar mensajes. El equipo de base de datos captura este trabajo y lo mantiene en el disco.

BizTalk utiliza clústeres de conmutación por error de SQL Server y envío de registros para proporcionar alta disponibilidad, copias de seguridad y restauración, y recuperación ante desastres para sus bases de datos locales. En Azure IaaS (máquinas virtuales de Azure), las versiones anteriores de SQL Server no admiten instancias de clúster de conmutación por error (no admiten MSDTC). Como resultado, BizTalk no tenía una solución de HA al usar máquinas virtuales de Azure.

A partir de SQL Server 2016, los grupos de disponibilidad de SQL Server AlwaysOn admiten MSDTC para máquinas virtuales locales y de Azure. Como resultado, la función AlwaysOn de SQL Server 2016 es compatible con bases de datos BizTalk locales o en escenarios de Azure IaaS.

Grupos de disponibilidad de AlwaysOn de SQL Server 2016

La implementación de grupos de disponibilidad de AlwaysOn requiere un clúster de Clúster de conmutación por error de Windows Server (WSFC). Cada réplica de disponibilidad de un grupo de disponibilidad determinado debe residir en un nodo diferente del mismo clúster WSFC. Se crea un grupo de recursos WSFC para cada grupo de disponibilidad que cree. El clúster de WSFC supervisa este grupo de recursos para evaluar el estado de la réplica principal.

La siguiente ilustración muestra un grupo de disponibilidad que contiene una réplica primaria y cuatro réplicas secundarias.

Los clientes pueden conectarse a la réplica principal de un grupo de disponibilidad determinado mediante un receptor de grupos de disponibilidad. Un receptor de grupos de disponibilidad proporciona un conjunto de recursos que se adjuntan a un grupo de disponibilidad determinado para dirigir las conexiones de cliente a la réplica de disponibilidad adecuada.

SQL Server no admite MSDTC con AlwaysOn AG para ninguna versión anterior a 2016.

Proporcionar alta disponibilidad para bases de datos BizTalk utilizando Grupos de disponibilidad AlwaysOn

En la configuración básica de BizTalk Server, se crean un mínimo de 9 bases de datos, incluidas Reglas y bases de datos BAM.

En un escenario de MessageBox escalado (una configuración con más de una MessageBox), hay más de una base de datos de MessageBox, y cada base de datos de MessageBox debe agregarse al grupo de disponibilidad.

BizTalk Server también depende de los Servicios de Análisis de SQL Server y de los Servicios de Integración de SQL Server para el Análisis y Archivo de BAM. SQL Server no proporciona una solución de alta disponibilidad para Servicios de Integración o Servicios de análisis en Azure IaaS. Por lo tanto, se recomienda utilizar otra instancia independiente de SQL Server para las bases de datos de BAMArchive y BAMAnalysis Analysis Services. Para instalaciones locales, la instancia de clúster de conmutación por error de SQL se puede usar para configurar una configuración de alta disponibilidad.

Para BizTalk Server 2016 y versiones anteriores, esta configuración se muestra en la siguiente imagen y se recomienda para bases de datos BizTalk en Grupos de disponibilidad:

A partir de BizTalk Server 2020 y versiones posteriores, se admite una alta disponibilidad de paquetes DTS BAM utilizando el Catálogo SSIS. Agregue la base de datos SSISDB al mismo grupo de disponibilidad que las bases de datos de BizTalk Server. Esta configuración se muestra en la siguiente imagen y se recomienda para bases de datos BizTalk en Grupos de disponibilidad:

Además de las bases de datos de SQL Server, la configuración de BizTalk Server también crea inicios de sesión de seguridad de SQL Server y trabajos de agente SQL. Los grupos de disponibilidad AlwaysOn solo proporcionan la capacidad de administrar bases de datos dentro de un Grupo de disponibilidad. En todas las réplicas de disponibilidad, los inicios de sesión del servidor BizTalk y los trabajos del agente SQL deben crearse y actualizarse manualmente.

La siguiente lista de inicios de sesión de seguridad de SQL Server están asociados con BizTalk Server. Es posible que tenga inicios de sesión adicionales creados para sus aplicaciones de servidor BizTalk. Si es así, debe replicarlos en cada instancia de SQL Server que aloje una réplica de bases de datos BizTalk.

1. Usuarios de la aplicación BizTalk (uno o más correspondientes a cada Host in-proc)
2. Usuarios de Host aislado BizTalk (uno o más correspondientes a cada Host Aislado)
3. Administradores de BizTalk Server
4. Operadores B2B de BizTalk Server
5. Operadores de BizTalk Server
6. Administradores de SSO
7. Alertas de BAM Al usuario
8. Usuario del Servicio Web de Administración de BAM
9. Cuenta de Servicio de actualización del Motor de reglas

Si ha creado hosts adicionales o creará hosts adicionales más adelante, se crearán nuevos inicios de sesión SQL como parte de este proceso. Debe asegurarse de crear estos inicios de sesión SQL manualmente en las réplicas correspondientes.

Los siguientes trabajos de agente de SQL Server están asociados con BizTalk Server. Los trabajos instalados en cada servidor son diferentes en función de las características instaladas y configuradas. La mayoría de estos trabajos se crean durante la configuración del servidor BizTalk. Se crean varios al configurar el envío de registros. Estos trabajos deben replicarse en cada instancia de réplica de alojamiento de SQL Server de su base de datos BizTalk correspondiente. Esto debe realizarse 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:
  • Purga y archivo de DTA (BizTalkDTADb)
• BizTalkRulesEngineDb trabajo:
  • Rules_Database_Cleanup_BizTalkRuleEngineDb
• Trabajo de aplicación de Bamalerts:
  • 0 o más Trabajo de Delalerthist

A diferencia de las instancias de clúster de conmutación por error de SQL, en los grupos de disponibilidad todas las réplicas están activas, en ejecución y disponibles. Cuando los trabajos de agente SQL se duplican en cada réplica para la conmutación por error, se ejecutan en la réplica correspondiente, independientemente de si se encuentra actualmente en el rol principal o secundario. Para asegurarse de que estos trabajos se ejecutan solo en la réplica principal actual, cada paso de cada trabajo debe estar encerrado dentro de un bloque IF, como se muestra:

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

Reemplace 'dbname' por el nombre de base de datos correspondiente con el que está configurado para ejecutarse el trabajo. El siguiente ejemplo muestra este cambio para TrackedMessages_Copy_BizTalkMsgBoxDb en BizTalkMsgBoxDb:

Configure BizTalk cuando los grupos de disponibilidad ya están configurados

1. Compruebe los requisitos de su sistema operativo:
   • En todos los equipos Windows Server 2012 R2, instale la revisión 3090973 MSDTC (abre un artículo de KB).
   • En todos los equipos con Windows Server 2016, habilite la clave de registro habilitada para acceso remoto (abre un artículo de KB).
2. Cree los Grupos de disponibilidad necesarios. Asegúrese de que los Grupos de disponibilidad se creen con la opción de Compatibilidad con DTC por base de datos.
3. Al configurar BizTalk Server y especificar el nombre de SQL server, utilice el nombre de escucha del Grupo de disponibilidad en lugar del nombre real de la máquina. Esto crea las bases de datos BizTalk, inicios de sesión y trabajos de agente SQL en la réplica principal actual.
4. Detenga el procesamiento de BizTalk (Instancias de Host, Servicio SSO, IIS, Servicio de actualización del Motor de reglas, Servicio BAMAlerts, etc.) y detenga los trabajos del agente SQL.
5. Ahora agregue bases de datos BizTalk a los grupos de disponibilidad respectivos.
6. Incluya el cuerpo de los pasos del trabajo del agente SQL dentro del bloque IF (mencionado anteriormente) para asegurarse de que solo se ejecuten si el destino es la réplica principal.
7. Scripts de inicio de sesión y trabajos de agente SQL para replicarlos en la réplica correspondiente.
8. Replique el perfil y la cuenta de SQL DBMail para alertas BAM en las instancias SQL correspondientes que alojan la réplica secundaria.
9. Si agrega una base de datos de cuadros de mensajes adicional o implementa una nueva actividad/vista de BAM más adelante, se crean nuevos trabajos SQL para nuevas bases de datos de cuadros de mensajes o bases de datos de alertas de BAM en la réplica principal actual. Asegúrese de editarlo en la réplica principal y, a continuación, créelas manualmente en las réplicas secundarias correspondientes.
10. A partir de BizTalk Server 2020 y versiones posteriores, los paquetes DTS BAM se implementan en el catálogo SSIS. Agregue la base de datos SSISDB al mismo grupo de disponibilidad que las bases de datos BizTalk. Para obtener más información, consulte AlwaysOn para el catálogo de SSIS.

Esta configuración también se puede realizar utilizando las instancias SQL que alojan la réplica principal. En este caso, después de la configuración de BizTalk, ejecute los scripts UpdateDatabase.vbs y UpdateRegistry.vbs en las máquinas BizTalk después de los pasos anteriores. Esto se discute con más detalle en la siguiente sección.

Mover bases de datos BizTalk existentes a Grupos de disponibilidad

1. Compruebe los requisitos de su sistema operativo:

   • En todos los equipos Windows Server 2012 R2, instale la revisión MSDTC 3090973 (abre un artículo KB)
   • En todos los equipos Windows Server 2016, habilite la clave de registro habilitada para acceso remoto (abre un artículo KB)

2. Cree los Grupos de disponibilidad necesarios. Asegúrese de que el Grupo de Disponibilidad se cree con la opción de compatibilidad con DTC por base de datos.

3. Detenga el procesamiento de BizTalk y los trabajos de Agente SQL.

4. Realice copias de seguridad completas de todas las bases de datos BizTalk.

5. Restaure las bases de datos BizTalk en las instancias SQL que se encuentran actualmente en el rol principal del Grupo de disponibilidad.

6. Inicios de sesión de script y trabajos de agente SQL en las instancias SQL correspondientes que se encuentran actualmente en el rol principal del Grupo de disponibilidad.

7. Ejecute los scripts UpdateDatabase.vbs y UpdateRegistry.vbs en las máquinas BizTalk siguiendo los siguientes pasos. Introduzca el Oyente de grupo de disponibilidad como el nuevo nombre del servidor en el xml de información de actualización de entrada.

   1. Detenga todos los servicios BizTalk y los servicios SSO empresariales en BizTalk Server. Detener el servicio del agente SQL en SQL Server.

   2. En BizTalk Server, edite SampleUpdateInfo.xml en la siguiente carpeta:

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

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

      1. Reemplace «SourceServer» por el nombre del servidor de origen (antiguo servidor SQL que aloja bases de datos antiguas).
      2. Reemplace «DestinationServer» por el nombre del servidor de destino, que debe ser el nombre del oyente del grupo de disponibilidad.
      3. Si tiene las bases de datos BAM, BAM o RuleEngineDB, descomente las secciones apropiadas.

   3. Abra un símbolo del sistema y vaya a:

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

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

      En el símbolo del sistema, ejecute:
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      Ejecute Updatabase.vbs en un solo servidor del grupo BizTalk.

   4. Copie la muestra editada Updateinfo.archivo xml a la siguiente carpeta en cada equipo BizTalk Server de este grupo BizTalk:

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

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

   5. En cada equipo del grupo de servidores BizTalk, abra un símbolo del sistema y vaya a:

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

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

      En el símbolo del sistema, ejecute:
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      Ejecute UpdateRegistry.vbs en cada servidor del grupo BizTalk.

8. Ahora mueva las bases de datos a sus respectivos Grupos de disponibilidad.

9. Replicar el Perfil y la cuenta de SQL DBMail para Alertas BAM en las instancias SQL que alojan la réplica de la base de datos BAMAlerts.

10. Incluya el cuerpo de los pasos del trabajo del agente SQL dentro de un bloque IF para asegurarse de que solo se ejecuten si el destino es el principal.

11. Scripts de inicio de sesión y trabajos de agente SQL para replicarlos en la réplica correspondiente. El script UpdateDatabase también actualiza el nombre del servidor en los trabajos Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb y TrackedMessages_Copy_BizTalkMsgBoxDb. Por lo tanto, escriba los trabajos del agente SQL solo después de ejecutar el script UpdateDatabase.

Requisitos

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

  • SQL Server 2019 Enterprise o Standard

  • SQL Server 2017 Enterprise o Standard

  • SQL Server 2016 Enterprise o Standard.

    Consulte las limitaciones conocidas en este artículo para consultar la limitación de la edición estándar de SQL Server.

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

Escucha de grupos de disponibilidad configurada con un puerto no predeterminado (1433)

Use alias SQL en máquinas BizTalk Server.

Admite conmutadores por error de varias Subred del Grupo de disponibilidad

BizTalk Server utiliza Microsoft OLE DB para conexiones de base de datos, lo que no admite la opción de conexión de conmutación por error de múltiples subred. BizTalk Server no admite la opción de conexión MultiSubnetFailover (=TRUE), y esto puede causar un mayor tiempo de recuperación durante la conmutación por error de varias subredes.

Enrutamiento de solo lectura

El enrutamiento de solo lectura se refiere a la capacidad de SQL Server de enrutar conexiones entrantes para un receptor de grupo de disponibilidad a una réplica secundaria configurada para permitir cargas de trabajo de solo lectura.

BizTalk no utiliza Enrutamiento de solo lectura para ninguna de las conexiones a sus bases de datos. Esto significa que la opción «Secundaria Legible» en Réplicas de disponibilidad en el grupo de disponibilidad no tiene ningún impacto en las conexiones de base de datos BizTalk.

Comportamiento de las instancias de Host BizTalk durante la conmutación por error de SQL Server

Si el grupo de disponibilidad de SQL Server experimenta una conmutación por error, las bases de datos de BizTalk Server en el grupo de disponibilidad no están disponibles temporalmente.

Comportamiento de las instancias de Host en proceso durante la conmutación por error de SQL Server

Si las bases de datos de BizTalk Server no están disponibles, se recicla una instancia en proceso de un host de BizTalk Server hasta que se restablezca la conexión con SQL Server. Una vez que se restablece la conexión a las bases de datos de SQL Server, el procesamiento de documentos se reanuda normalmente.

Comportamiento de Instancias de Host aisladas Durante la conmutación por error de SQL Server

Si las bases de datos de BizTalk Server no están disponibles, una instancia aislada de un host de BizTalk Server se detiene y se genera un error similar al siguiente en el registro de aplicaciones de 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.

Una vez que se restablece la conexión a las bases de datos de SQL Server, se escribe un mensaje informativo similar al siguiente en el registro de la aplicación BizTalk Server y, a continuación, el procesamiento de documentos se reanuda normalmente:

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

Envío de registros para Recuperación ante desastres

BizTalk Server implementa las capacidades de espera de la base de datos mediante el uso del envío de registros de bases de datos. El envío de registros de BizTalk Server automatiza la copia de seguridad y la restauración de las bases de datos y sus archivos de registro de transacciones, lo que permite que un servidor en espera reanude el procesamiento de la base de datos en caso de que el servidor de base de datos de producción falle.

Las bases de datos secundarias del grupo disponibilidad no son copias de seguridad. Continúe haciendo copias de seguridad de las bases de datos BizTalk y sus registros de transacciones mediante trabajos de envío de registros de servidor BizTalk. La forma en que se implementa el envío de registros de BizTalk garantiza que las copias de seguridad siempre se realicen contra la réplica principal actual de cada base de datos. Los trabajos de envío de registros de BizTalk Server no respetan la configuración de preferencias de copia de seguridad del grupo de disponibilidad.

Si está agregando otras bases de datos BizTalk al trabajo de copia de seguridad de bases de datos BizTalk, asegúrese de usar el nombre del Oyente del grupo de disponibilidad como servidor de base de datos para ellas al configurar la copia de seguridad.

• Proporcionar alta disponibilidad para bases de datos de BizTalk Server
• Soporte de software de Microsoft server para máquinas virtuales Microsoft Azure
• Duplicación de bases de datos de SQL Server, Servicio de Instantáneas de volumen y AlwaysOn
• Descripción general de los Grupos de disponibilidad de AlwaysOn (SQL Server)
• Soporte para Transacciones entre bases de datos Para Duplicación de bases de datos o Disponibilidad de AlwaysOn Grupos (SQL Server)
• No se puede llamar a la lista de reproducción cuando SQL Server recibe el resultado de la transacción de MSDTC en Windows Server 2012 R2
• Copia de seguridad y restauración de BizTalk Server Bases de datos
• Cómo mover las bases de datos de BizTalk Server
• Cómo Restaurar sus bases de datos
• Tiempos de espera de conexión en el Grupo de disponibilidad de varias subred

Limitaciones conocidas

Estas limitaciones son para BizTalk Server, SQL Server AlwaysOn Availability Group y Máquinas virtuales Azure. Estas limitaciones pueden o no abordarse en el futuro.

• Los inicios de sesión, los trabajos de agente SQL, el perfil de correo de la base de datos SQL y las cuentas no se administran dentro de los grupos de disponibilidad. Esto requiere una modificación manual en los trabajos para asegurarse de que se ejecutan contra la réplica principal.

• Los servicios de análisis de SQL Server y los servicios de integración de SQL Server no participan en los grupos de disponibilidad. Sin este soporte de SQL Server, no hay una solución de HA para estas máquinas virtuales de Azure. Las capacidades de BAM de BizTalk Server dependen de estos servicios.

• Antes de SQL Server 2016 SP2, los grupos de disponibilidad no admiten MSDTC entre bases de datos en la misma instancia SQL.

  A partir de SQL Server 2016 SP2 y BizTalk Server 2016 CU5, las bases de datos BizTalk pueden usar la misma instancia de SQL Server.

• BizTalk Server no puede usar Enrutamiento de solo lectura.

• BizTalk Server no establece la propiedad de conexión MultiSubnetFailover.

• Los trabajos de copia de seguridad BizTalk que utilizan Envío de registros siempre se dirigirán a la réplica principal, independientemente de la preferencia de copia de seguridad establecida en el Grupo de disponibilidad.

• El estándar SQL Server 2016 admite solo una base de datos en cada SQL AlwaysOn AG. Dado que BizTalk utiliza muchas bases de datos, normalmente se recomienda SQL Server Enterprise edition.

• Si utiliza máquinas virtuales de Azure, se recomienda utilizar un puerto TCP/IP fijo dedicado para MSDTC. Al usar un puerto TCP / IP fijo, no está limitando el rango de puertos RPC que normalmente se usa con sistemas operativos más antiguos, y ayuda a simplificar las reglas de firewall y balanceador de carga. Para evitar conflictos con puertos inferiores conocidos, considere usar un puerto fijo superior (como > 20000). La configuración de la compatibilidad con puerto único DTC describe la clave de registro ServerTcpPort. Además del puerto fijo para MSDTC, también se utiliza el puerto principal RPC 135.

Planifique la tolerancia a fallos.