Alta disponibilidad mediante grupos de disponibilidad de SQL Server Always On: BizTalk Server

  • Artículo

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

Sugerencia

La configuración de BizTalk Server 2016 mediante el LABORATORIO de grupos de disponibilidad proporciona una guía paso a paso escrita por un ingeniero de campo de Microsoft. Se basa en un entorno de laboratorio e incluye algunas observaciones. Mira esto.

Importante

  • BizTalk Server admite grupos de disponibilidad de Always On a partir de SQL Server 2016 y versiones posteriores. Si usa una versión anterior de SQL Server, este artículo no se aplica a usted.
  • BizTalk Server admite el modo de confirmación sincrónica; no se admite el modo de confirmación asincrónica. Para la recuperación ante desastres, se recomienda configurar el trabajo de copia de seguridad BizTalk Server y usar el trasvase de registros. Consulte Copia de seguridad y restauración de bases de datos de BizTalk Server para obtener detalles específicos.

Los modos de disponibilidad detallan las opciones de confirmación con Always On grupos de disponibilidad.

Antecedentes e historial

BizTalk Server se basa en gran medida en SQL Server para la persistencia de datos. Otros componentes y hosts de 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 conserva en el disco.

BizTalk usa SQL Server clústeres de conmutación por error y trasvase de registros para proporcionar alta disponibilidad, copia de seguridad y restauración, y recuperación ante desastres para sus bases de datos. En IaaS de Azure (máquinas virtuales de Azure), anteriormente, BizTalk (Windows y SQL) no admitía instancias de clúster de conmutación por error, ya que no había discos compartidos admitidos, lo que es necesario para la agrupación en clústeres de SQL y MSDTC. Como resultado, BizTalk no tenía una solución de alta disponibilidad al usar máquinas virtuales de Azure. Dado que el disco compartido de Azure ya está disponible, es posible agrupar SQL y MSDTC en máquinas virtuales de Azure. La instancia de clúster de conmutación por error de SQL mediante discos compartidos de Azure es la solución más altamente disponible.

A partir de SQL Server 2016, SQL Server grupos de disponibilidad AlwaysOn admite MSDTC para el entorno local y el uso de máquinas virtuales de Azure. Como resultado, la característica AlwaysOn de SQL Server 2016 (o posterior) es compatible con bases de datos de BizTalk locales o en escenarios de IaaS de Azure. Dado que hay una sobrecarga adicional con la sincronización de discos sincrónicos al usar Espacios de almacenamiento directo (S2D) y tiempo adicional durante las conmutaciones por error, es menos altamente disponible en comparación con la instancia de clúster de conmutación por error de SQL.

grupos de disponibilidad AlwaysOn de SQL Server 2016

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

En la ilustración siguiente se muestra un grupo de disponibilidad que contiene solo una réplica principal y cuatro réplicas secundarias.

Réplica principal en el grupo de disponibilidad AlwaysOn de SQL con BizTalk Server

Los clientes pueden conectarse a la réplica principal de un grupo de disponibilidad determinado mediante un agente de escucha de grupo de disponibilidad. Un agente de escucha de grupo de disponibilidad proporciona un conjunto de recursos conectados a un grupo de disponibilidad determinado para dirigir las conexiones de cliente a la réplica de disponibilidad adecuada.

Importante

SQL Server 2016 admite MSDTC con grupos de disponibilidad AlwaysOn (AG) en Windows Server 2016 y Windows Server 2012 R2. Windows Server 2012 R2 requiere que se instale la revisión de Windows 3090973. Windows Server 2016 requiere que se habilite la clave del Registro RemoteAccessEnabled.

SQL Server no admite MSDTC con AlwaysOn AG para ninguna versión anterior a 2016. SQL Server 2016 SP2 mejoró el control de transacciones de MSDTC, por lo que se recomienda SP2 o posterior.

Proporcionar alta disponibilidad para bases de datos de BizTalk mediante grupos de disponibilidad AlwaysOn

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

Antes de SQL Server 2016 SP2, los grupos de disponibilidad no admitían MSDTC entre bases de datos en la misma instancia de SQL, por lo que las bases de datos de BizTalk tenían que distribuirse en un mínimo de 4 instancias de SQL. Debido a esta limitación, se recomienda usar SQL Server 2016 SP2 (o superior) y BizTalk Server 2016 CU5 (o superior) para que todas las bases de datos de BizTalk puedan usar la misma instancia de SQL Server. Todavía puede considerar la posibilidad de usar más de una instancia de SQL por motivos de rendimiento (por ejemplo, tener el cuadro de mensajes en una instancia de SQL diferente).

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

BizTalk Server también depende de SQL Server Analysis Services y SQL Server Integration Services para el análisis y el archivado de BAM. SQL Server no proporciona una solución de alta disponibilidad para Integration Services o Analysis Services en IaaS de Azure. Por lo tanto, se recomienda usar otra instancia de SQL Server independiente para las bases de datos bamArchive y BAMAnalysis Analysis Services. En el caso de las instalaciones locales, se puede usar la instancia de clústeres de conmutación por error de SQL para configurar una configuración de alta disponibilidad.

Para BizTalk Server 2016, esta configuración se muestra en la imagen siguiente y se recomienda para las bases de datos de BizTalk en grupos de disponibilidad (como se mencionó anteriormente, a partir de SQL 2016 SP2 y BizTalk 2016 CU5, ya no se requieren 4 instancias de SQL):

Configuración recomendada SQL Server siempre activada en BizTalk Server 2016 y versiones anteriores

A partir de BizTalk Server 2020, se admite la alta disponibilidad para paquetes DTS de BAM mediante el catálogo de 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 imagen siguiente y se recomienda para las bases de datos de BizTalk en grupos de disponibilidad (como se mencionó anteriormente, ya no se requieren 4 instancias de SQL):

Se recomienda SQL Server configuración siempre activada en BizTalk Server 2020 y versiones más recientes

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 SQL Server y trabajos del 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 de BizTalk Server 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 a BizTalk Server. Es posible que tenga inicios de sesión adicionales creados para las aplicaciones de BizTalk Server. Si es así, debe replicarlos en cada instancia de SQL Server hospedar una réplica de bases de datos de BizTalk.

  1. Usuarios de aplicaciones de BizTalk (uno o varios correspondientes a cada host en proceso)
  2. Usuarios de host aislados de BizTalk (uno o varios correspondientes a cada host aislado)
  3. Administradores de servidor BizTalk Server
  4. Operadores B2B de BizTalk Server
  5. Operadores de servidor BizTalk Server
  6. Administradores de SSO
  7. Usuario de alertas de BAM
  8. Usuario de 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, habrá nuevos inicios de sesión de SQL creados como parte de este proceso. Debe asegurarse de crear estos inicios de sesión de SQL manualmente en las réplicas correspondientes.

Los siguientes trabajos del Agente SQL Server están asociados a BizTalk Server. Los trabajos instalados en cada servidor son diferentes según las características instaladas y configuradas. La mayoría de estos trabajos se crean durante BizTalk Server configuración. Algunos se crean al configurar el envío de registro. Estos trabajos deben replicarse en cada instancia de SQL Server réplica de hospedaje de su base de datos de BizTalk correspondiente. Esto se debe realizar manualmente.

  • Trabajos de BizTalkMgmtDb:
    • Copia de seguridad de BizTalk Server (BizTalkMgmtDb)
    • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
    • Supervisar el servidor BizTalk Server (BizTalkMgmtDb)
  • Trabajos de 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
  • Trabajos en msgboxes adicionales
  • Trabajo de BizTalkDTADb:
    • DTA Purge and Archive (BizTalkDTADb)
  • Trabajo de BizTalkRulesEngineDb:
    • Rules_Database_Cleanup_BizTalkRuleEngineDb
  • Trabajo BAMAlertsApplication:
    • 0 o más DelAlertHistJob

A diferencia de las instancias de clústeres 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 del 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 en el rol secundario. Para asegurarse de que estos trabajos solo se ejecutan en la réplica principal actual, todos los pasos de cada trabajo se deben incluir 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 en el que se configura el trabajo para ejecutarse. En el ejemplo siguiente se muestra este cambio para TrackedMessages_Copy_BizTalkMsgBoxDb en BizTalkMsgBoxDb:

Cambie el nombre del trabajo del Agente SQL en el grupo de disponibilidad AlwaysOn con BizTalk Server

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

  1. Compruebe los requisitos del sistema operativo:
  2. Cree los grupos de disponibilidad necesarios. Asegúrese de que los grupos de disponibilidad se crean con la opción Compatibilidad con DTC por base de datos .
  3. Al configurar BizTalk Server y especificar el nombre del servidor SQL, use el nombre del agente de escucha del grupo de disponibilidad en lugar del nombre real del equipo. Esto crea las bases de datos de BizTalk, los inicios de sesión y los trabajos del 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 de BizTalk a los grupos de disponibilidad correspondientes.
  6. Incluya el cuerpo de los pasos de trabajo del Agente SQL dentro IF del bloque (mencionado anteriormente) para asegurarse de que se ejecutan solo si el destino es la réplica principal.
  7. Generar scripts de inicios de sesión y trabajos del Agente SQL para replicarlos en la réplica correspondiente.
  8. Replique el perfil de SQL DBMail y la cuenta para las alertas de BAM en las instancias de SQL correspondientes que hospedan la réplica secundaria.
  9. Si va a agregar una base de datos de cuadro de mensaje adicional o implementar una nueva actividad o vista de BAM más adelante, se crean nuevos trabajos de SQL para las nuevas bases de datos de cuadros de mensaje o la base 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éelos manualmente en las réplicas secundarias correspondientes.
  10. A partir de BizTalk Server 2020 y versiones posteriores, los paquetes DTS de BAM se implementan en el catálogo de SSIS. Agregue la base de datos SSISDB al mismo grupo de disponibilidad que las bases de datos de BizTalk. Para obtener más información, consulte AlwaysON para el catálogo de SSIS.

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

Mover bases de datos de BizTalk existentes a grupos de disponibilidad

  1. Compruebe los requisitos del sistema operativo:

  2. Cree los grupos de disponibilidad necesarios. Asegúrese de que el grupo de disponibilidad se crea con la opción De compatibilidad con DTC por base de datos .

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

  4. Realice una copia de seguridad completa de todas las bases de datos de BizTalk.

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

  6. Generar scripts de inicios de sesión y trabajos del Agente SQL en las instancias sql correspondientes actualmente en el rol principal del grupo de disponibilidad.

  7. Ejecute los UpdateDatabase.vbs scripts y UpdateRegistry.vbs en las máquinas de BizTalk mediante los pasos siguientes. Escriba el agente de escucha del 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 de BizTalk y los servicios de inicio de sesión único de empresa en BizTalk Server. Detenga el servicio 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

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

      1. Reemplace "SourceServer" por el nombre del servidor de origen (antiguo SQL Server hospedar bases de datos antiguas).
      2. Reemplace "DestinationServer" por el nombre del servidor de destino, que debe ser el nombre del agente de escucha del grupo de disponibilidad.
      3. Si tiene las bases de datos BAMAnalysis, BAM o RuleEngineDB, quite la marca de comentario de las secciones adecuadas.

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

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

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

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

      Ejecute UpdateDatabase.vbs solo en un servidor del grupo de BizTalk.

    4. Copie el archivo de SampleUpdateInfo.xml editado en la siguiente carpeta en cada equipo BizTalk Server de este grupo de BizTalk:

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

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

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

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

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

      En el símbolo del sistema, ejecute lo siguiente:
      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. Replique el perfil de SQL DBMail y la cuenta para las alertas de BAM en las instancias de SQL que hospedan la réplica de la base de datos BAMAlerts.

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

  11. Generar scripts de inicios de sesión y trabajos del Agente SQL para replicarlos en la réplica correspondiente. El script UpdateDatabase también actualiza el nombre del servidor en los trabajos de Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb y TrackedMessages_Copy_BizTalkMsgBoxDb. Por lo tanto, cree un script para los trabajos del Agente SQL solo después de ejecutar el script UpdateDatabase.

Requisitos

  • 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.

      Consulte Limitaciones conocidas de este artículo para obtener SQL Server Standard limitación de edición.

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

Agente de escucha del grupo de disponibilidad configurado con un puerto no predeterminado (1433)

Use el alias SQL en máquinas BizTalk Server.

Grupos de disponibilidad de varias subredes

BizTalk Server no admite la opción de conexión MultiSubnetFailover (=TRUE).

Consulte la documentación de SQL para obtener más información sobre los problemas que pueden producirse al conectar un cliente SQL que no admite esta opción a un grupo de disponibilidad de SQL de varias subredes. Algunos de estos problemas se describen en los vínculos siguientes:

Enrutamiento de solo lectura

El enrutamiento de solo lectura hace referencia a la capacidad de SQL Server enrutar las conexiones entrantes de un agente de escucha de grupo de disponibilidad a una réplica secundaria configurada para permitir cargas de trabajo de solo lectura.

BizTalk no usa Read-Only Enrutamiento para ninguna de las conexiones a sus bases de datos. Esto significa que la opción "Secundaria legible" en réplicas de disponibilidad del grupo de disponibilidad no tiene ningún impacto en bizTalk conexione de base de datos.

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

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

Comportamiento de las instancias de host de tipo En curso 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 restaura la conexión con el SQL Server. Una vez restaurada la conexión a las bases de datos de SQL Server, el procesamiento de documentos se reanuda normalmente.

Comportamiento de las 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, se pausa una instancia aislada de un host de BizTalk Server y se genera un error similar al siguiente en el registro de aplicación 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 restaurada la conexión a las bases de datos de SQL Server, se escribe un mensaje informativo similar al siguiente en el registro de aplicación de 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.

Trasvase de registros para la recuperación ante desastres

BizTalk Server implementa funcionalidades de espera de base de datos mediante el uso del trasvase de registros de base de datos. BizTalk Server trasvase de registros automatiza la copia de seguridad y 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 se produzca un error en el servidor de bases de datos de producción.

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

Si va a agregar otras bases de datos de BizTalk al trabajo de copia de seguridad de bases de datos de BizTalk, asegúrese de usar el nombre del agente de escucha del grupo de disponibilidad como servidor de bases de datos para ellas al configurar la copia de seguridad.

Referencias

Restricciones conocidas

Estas limitaciones son para BizTalk Server, SQL Server grupo de disponibilidad AlwaysOn y Azure Virtual Machines. Estas limitaciones pueden o no abordarse en el futuro.

  • Los inicios de sesión, los trabajos del Agente SQL, el perfil de Correo electrónico de BASE de datos de SQL y las cuentas no se administran dentro de los grupos de disponibilidad. Esto requiere una modificación manual en Trabajos para asegurarse de que se ejecutan en la réplica principal.

  • SQL Server Analysis Services y SQL Server Integration Services no participan en grupos de disponibilidad. Sin esta compatibilidad con SQL Server, no hay ninguna solución de alta disponibilidad para estas en Azure Virtual Machines. las funcionalidades 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 de SQL.

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

  • BizTalk Server no puede usar Read-Only Enrutamiento.

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

  • Los trabajos de copia de seguridad de BizTalk que usan el trasvase de registros siempre tendrán como destino la réplica principal, independientemente de las preferencias de copia de seguridad establecidas en el grupo de disponibilidad.

  • SQL Server 2016 Standard solo admite una base de datos única en cada grupo de disponibilidad AlwaysOn de SQL. Dado que BizTalk usa muchas bases de datos, normalmente se recomienda SQL Server Enterprise edición.

  • Si usa máquinas virtuales de Azure, se recomienda usar un puerto TCP/IP fijo dedicado para MSDTC. Cuando se usa un puerto TCP/IP fijo, no se limita el intervalo de puertos RPC que se usa normalmente con sistemas operativos anteriores; y ayuda a simplificar las reglas del firewall y del equilibrador de carga. Para evitar conflictos con puertos inferiores conocidos, considere la posibilidad de usar un puerto fijo superior (como >20000). La configuración de la compatibilidad con puertos únicos de DTC describe la clave del ServerTcpPort Registro. Además del puerto fijo para MSDTC, también se usa el puerto RPC principal 135.

Pasos siguientes

Planee la tolerancia a errores.