Partager via

Haute disponibilité à l’aide de groupes de disponibilité SQL Server Always On - BizTalk Server

  • Article

Configurez la haute disponibilité à l’aide de SQL Server groupes de disponibilité AlwaysOn.

Conseil

La configuration BizTalk Server 2016 à l’aide de groupes de disponibilité LAB fournit un guide pas à pas écrit par un ingénieur de terrain Microsoft. Il est basé sur un environnement de laboratoire et comprend quelques observations. Regarde.

Important

  • BizTalk Server prennent en charge les groupes de disponibilité Always On à partir du SQL Server 2016 et des versions ultérieures. Si vous utilisez une version SQL Server précédente, cet article ne s’applique pas à vous.
  • BizTalk Server prend en charge le mode de validation synchrone ; le mode de validation asynchrone n’est pas pris en charge. Pour la récupération d’urgence, il est recommandé de configurer le travail de sauvegarde BizTalk Server et d’utiliser la copie des journaux. Pour plus d’informations, consultez Sauvegarde et restauration de bases de données BizTalk Server.

Les modes de disponibilité détaillent les options de validation avec Always On groupes de disponibilité.

Arrière-plan et historique

BizTalk Server s’appuie fortement sur SQL Server pour la persistance des données. D’autres composants et hôtes dans BizTalk Server ont des rôles spécifiques lors de l’intégration d’applications métier disparates, telles que la réception, le traitement ou le routage des messages. L’ordinateur de base de données capture ce travail et le conserve sur le disque.

BizTalk utilise SQL Server clustering de basculement et la copie des journaux pour assurer la haute disponibilité, la sauvegarde et la restauration, ainsi que la récupération d’urgence de ses bases de données. Dans Azure IaaS (machines virtuelles Azure), BizTalk (Windows et SQL) ne prenait pas en charge les instances de cluster de basculement, car aucun disque partagé n’était pris en charge, ce qui est requis pour clustering de SQL et MSDTC. Par conséquent, BizTalk n’avait pas de solution haute disponibilité lors de l’utilisation de machines virtuelles Azure. Étant donné qu’Azure Shared Disk est désormais disponible, il est possible de mettre en cluster SQL et MSDTC dans des machines virtuelles Azure. L’instance de cluster de basculement SQL utilisant des disques partagés Azure est la solution la plus hautement disponible.

À compter de SQL Server 2016, SQL Server groupes de disponibilité AlwaysOn prend en charge MSDTC pour les machines virtuelles locales et l’utilisation de machines virtuelles Azure. Par conséquent, la fonctionnalité AlwaysOn SQL Server 2016 (ou version ultérieure) est prise en charge pour les bases de données BizTalk locales ou dans les scénarios Azure IaaS. Étant donné qu’il y a une surcharge supplémentaire avec la synchronisation de disque synchrone lors de l’utilisation de espaces de stockage direct (S2D) et du temps supplémentaire pendant les basculements, elle est moins hautement disponible que l’instance de cluster de basculement SQL.

Groupes de disponibilité AlwaysOn SQL Server 2016

Le déploiement de groupes de disponibilité AlwaysOn nécessite un cluster de basculement Windows Server (WSFC). Chaque réplica de disponibilité d'un groupe de disponibilité donné doit résider sur un nœud différent du même cluster WSFC. Un groupe de ressources WSFC est créé pour chaque groupe de disponibilité que vous créez. Le cluster WSFC surveille ce groupe de ressources pour évaluer l'intégrité du réplica principal.

L'illustration suivante montre un groupe de disponibilité qui contient un réplica principal et quatre réplicas secondaires.

Réplica principal dans le groupe de disponibilité SQL AlwaysOn avec BizTalk Server

Les clients peuvent se connecter au réplica principal d’un groupe de disponibilité donné à l’aide d’un écouteur de groupe de disponibilité. Un écouteur de groupe de disponibilité fournit un ensemble de ressources attachées à un groupe de disponibilité donné pour diriger les connexions client vers le réplica de disponibilité approprié.

Important

SQL Server 2016 prend en charge MSDTC avec les groupes de disponibilité AlwaysOn sur Windows Server 2016 et Windows Server 2012 R2. Windows Server 2012 R2 nécessite l’installation du correctif logiciel Windows 3090973. Windows Server 2016 nécessite que la clé de Registre RemoteAccessEnabled soit activée.

SQL Server ne prend pas en charge MSDTC avec AlwaysOn AG pour les versions antérieures à 2016. SQL Server 2016 SP2 a amélioré la gestion des transactions MSDTC afin que SP2 ou version ultérieure soit recommandé.

Fournir une haute disponibilité pour les bases de données BizTalk à l’aide de groupes de disponibilité AlwaysOn

Dans la configuration de base de BizTalk Server, un minimum de 9 bases de données sont créées, y compris les bases de données Règles et BAM.

Avant SQL Server 2016 SP2, les groupes de disponibilité ne prenaient pas en charge MSDTC entre les bases de données sur le même instance SQL. Les bases de données BizTalk devaient donc être distribuées sur un minimum de 4 instances SQL. En raison de cette limitation, il est recommandé d’utiliser SQL Server 2016 SP2 (ou version ultérieure) et BizTalk Server 2016 CU5 (ou version ultérieure) afin que toutes les bases de données BizTalk puissent utiliser le même SQL Server instance. Vous pouvez toujours envisager d’utiliser plusieurs instance SQL pour des raisons de performances (par exemple, avoir messageBox sur un autre instance SQL).

Dans un scénario MessageBox avec montée en puissance parallèle (configuration avec plusieurs MessageBox), il existe plusieurs bases de données MessageBox et chaque base de données MessageBox doit être ajoutée au groupe de disponibilité.

BizTalk Server dépend également de SQL Server Analysis Services et SQL Server Integration Services pour l’analyse et l’archivage BAM. SQL Server ne fournit pas de solution de haute disponibilité pour Integration Services ou Analysis Services dans Azure IaaS. Par conséquent, il est recommandé d’utiliser une autre SQL Server instance autonome pour les bases de données BAMArchive et BAMAnalysis Analysis Services. Pour les installations locales, l’instance de clustering de basculement SQL peut être utilisée pour configurer une configuration de haute disponibilité.

Pour BizTalk Server 2016, cette configuration est illustrée dans l’image suivante et recommandée pour les bases de données BizTalk dans les groupes de disponibilité (comme mentionné ci-dessus, à compter de SQL 2016 SP2 et BizTalk 2016 CU5, 4 instances SQL ne sont plus nécessaires) :

Configuration SQL Server toujours activée sur BizTalk Server 2016 et les versions antérieures

À compter de BizTalk Server 2020, la disponibilité élevée des packages DTS BAM est prise en charge à l’aide du catalogue SSIS. Ajoutez la base de données SSISDB au même groupe de disponibilité que les bases de données BizTalk Server. Cette configuration est illustrée dans l’image suivante et recommandée pour les bases de données BizTalk dans les groupes de disponibilité (comme mentionné ci-dessus, 4 instances SQL ne sont plus nécessaires) :

Configuration SQL Server toujours activée sur BizTalk Server 2020 et versions ultérieures

En plus des bases de données SQL Server, la configuration BizTalk Server crée également des SQL Server connexions de sécurité et des travaux SQL Agent. Les groupes de disponibilité AlwaysOn permettent uniquement de gérer des bases de données à l’intérieur d’un groupe de disponibilité. Sur tous les réplicas de disponibilité, les connexions BizTalk Server et les travaux sql Agent doivent être créés et mis à jour manuellement.

La liste suivante des connexions de sécurité SQL Server sont associées à BizTalk Server. Des connexions supplémentaires peuvent être créées pour vos applications BizTalk Server. Si c’est le cas, vous devez les répliquer sur chaque instance de SQL Server hébergeant un réplica de bases de données BizTalk.

  1. Utilisateurs d’application BizTalk (un ou plusieurs correspondant à chaque hôte in-proc)
  2. Utilisateurs hôtes isolés BizTalk (un ou plusieurs correspondant à chaque hôte isolé)
  3. Administrateurs BizTalk Server
  4. Opérateurs B2B BizTalk Server
  5. Opérateurs BizTalk Server
  6. Administrateurs SSO
  7. Utilisateur des alertes BAM
  8. Utilisateur de service Web de gestion de l'analyse BAM
  9. Compte de service de mise à jour du moteur de règles

Si vous avez créé des hôtes supplémentaires ou que vous en créerez d’autres ultérieurement, de nouvelles connexions SQL seront créées dans le cadre de ce processus. Vous devez vous assurer de créer ces connexions SQL manuellement sur les réplicas correspondants.

Les travaux d'Agent SQL Server suivants sont associés à BizTalk Server. Les travaux installés sur chaque serveur sont différents selon les fonctionnalités installées et configurées. La plupart de ces travaux sont créés pendant BizTalk Server configuration. Plusieurs d'entre eux sont créés lors de la configuration de l'envoi de journaux. Ces travaux doivent être répliqués sur chaque instance de SQL Server hébergement réplica de leur base de données BizTalk correspondante. Cette opération doit être effectuée manuellement.

  • Travaux BizTalkMgmtDb :
    • Backup BizTalk Server (BizTalkMgmtDb)
    • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
    • Monitor BizTalk Server (BizTalkMgmtDb)
  • Travaux 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
  • Travaux sur des msgbox supplémentaires
  • Travail BizTalkDTADb :
    • DTA Purge and Archive (BizTalkDTADb)
  • Travail BizTalkRulesEngineDb :
    • Rules_Database_Cleanup_BizTalkRuleEngineDb
  • Travail BAMAlertsApplication :
    • 0 ou plus DelAlertHistJob

Contrairement aux instances de clustering de basculement SQL, dans les groupes de disponibilité, tous les réplicas sont actifs, en cours d’exécution et disponibles. Lorsque les travaux SQL Agent sont dupliqués sur chaque réplica pour le basculement, ils s’exécutent sur les réplica correspondants, qu’ils soient actuellement dans le rôle principal ou secondaire. Pour vous assurer que ces travaux sont exécutés uniquement sur le réplica principal actuel, chaque étape de chaque travail doit être placée dans un bloc IF, comme indiqué :

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

Remplacez par ‘dbname’ le nom de base de données correspondant sur lequel le travail est configuré pour s’exécuter. L’exemple suivant montre cette modification pour TrackedMessages_Copy_BizTalkMsgBoxDb sur BizTalkMsgBoxDb :

Modifiez le nom du travail SQL Agent dans le groupe de disponibilité AlwaysOn avec BizTalk Server

Configurer BizTalk lorsque les groupes de disponibilité sont déjà configurés

  1. Vérifiez la configuration requise de votre système d’exploitation :
  2. Créez les groupes de disponibilité requis. Assurez-vous que les groupes de disponibilité sont créés avec l’option Prise en charge DTC par base de données .
  3. Lorsque vous configurez BizTalk Server et spécifiez le nom du serveur SQL, utilisez le nom de l’écouteur du groupe de disponibilité au lieu du nom réel de l’ordinateur. Cela crée les bases de données BizTalk, les connexions et les travaux SQL Agent sur le réplica principal actuel.
  4. Arrêtez le traitement BizTalk (instances d’hôte, service D’authentification unique, IIS, Service de mise à jour du moteur de règles, BAMAlerts Service, etc.) et arrêtez les travaux de l’Agent SQL.
  5. Ajoutez maintenant des bases de données BizTalk aux groupes de disponibilité respectifs.
  6. Placez le corps des étapes de travail sql Agent dans IF le bloc (mentionné précédemment) pour vous assurer qu’elles s’exécutent uniquement si la cible est le réplica principal.
  7. Script des connexions et des travaux de l’Agent SQL pour les répliquer sur les réplica correspondants.
  8. Répliquez le profil et le compte SQL DBMail pour les alertes BAM sur les instances SQL correspondantes hébergeant le réplica secondaire.
  9. Si vous ajoutez une base de données de boîtes de messages supplémentaire ou déployez ultérieurement une nouvelle activité/vue BAM, de nouveaux travaux SQL sont créés pour les nouvelles bases de données de boîtes de messages ou la base de données alertes BAM sur le réplica principal actuel. Veillez à le modifier sur les réplica primaires, puis créez-les manuellement sur les réplicas secondaires correspondants.
  10. À compter de BizTalk Server 2020 et versions ultérieures, les packages BAM DTS sont déployés dans le catalogue SSIS. Ajoutez la base de données SSISDB au même groupe de disponibilité que les bases de données BizTalk. Pour plus d’informations, consultez AlwaysON pour le catalogue SSIS.

Cette configuration peut également être effectuée à l’aide des instances SQL hébergeant le réplica principal. Dans ce cas, après la configuration BizTalk, exécutez les UpdateDatabase.vbs scripts et UpdateRegistry.vbs sur les machines BizTalk après les étapes ci-dessus. Cette question est abordée plus en détail dans la section suivante.

Déplacer des bases de données BizTalk existantes vers des groupes de disponibilité

  1. Vérifiez la configuration requise de votre système d’exploitation :

  2. Créez les groupes de disponibilité requis. Assurez-vous que le groupe de disponibilité est créé avec l’option Prise en charge DTC par base de données .

  3. Arrêtez le traitement BizTalk et les travaux SQL Agent.

  4. Effectuez une sauvegarde complète de toutes les bases de données BizTalk.

  5. Restaurez les bases de données BizTalk sur les instances SQL actuellement dans le rôle principal dans le groupe de disponibilité.

  6. Scripts connexions et travaux SQL Agent sur les instances SQL correspondantes actuellement dans le rôle principal dans le groupe de disponibilité.

  7. Exécutez les UpdateDatabase.vbs scripts et UpdateRegistry.vbs sur les machines BizTalk en procédant comme suit. Entrez l’écouteur de groupe de disponibilité comme nouveau nom de serveur dans le xml des informations de mise à jour d’entrée.

    1. Arrêtez tous les services BizTalk et les services d’authentification unique d’entreprise sur BizTalk Server. Arrêtez le service SQL Agent sur SQL Server.

    2. Sur BizTalk Server, modifiez SampleUpdateInfo.xml dans le dossier suivant :

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

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

      1. Remplacez « SourceServer » par le nom du serveur source (ancien SQL Server hébergeant d’anciennes bases de données).
      2. Remplacez « DestinationServer » par le nom du serveur de destination, qui doit être le nom de l’écouteur du groupe de disponibilité.
      3. Si vous avez BAMAnalysis, les bases de données BAM ou RuleEngineDB, supprimez les marques de commentaire des sections appropriées.

    3. Ouvrez une invite de commandes et accédez à :

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

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

      À l'invite de commandes, exécutez :
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      Exécutez UpdateDatabase.vbs sur un seul serveur du groupe BizTalk.

    4. Copiez le fichier SampleUpdateInfo.xml modifié dans le dossier suivant sur chaque ordinateur BizTalk Server de ce groupe BizTalk :

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

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

    5. Sur chaque ordinateur du groupe BizTalk Server, ouvrez une invite de commandes et accédez à :

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

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

      À l'invite de commandes, exécutez :
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      Exécutez UpdateRegistry.vbs sur chaque serveur dans le groupe BizTalk.

  8. Déplacez maintenant les bases de données vers leurs groupes de disponibilité respectifs.

  9. Répliquez le profil et le compte SQL DBMail pour les alertes BAM sur les instances SQL hébergeant les réplica de la base de données BAMAlerts.

  10. Placez le corps des étapes de travail sql Agent dans un bloc IF pour vous assurer qu’elles s’exécutent uniquement si la cible est la principale.

  11. Script des connexions et des travaux de l’Agent SQL pour les répliquer sur le réplica correspondant. Le script UpdateDatabase met également à jour le nom du serveur dans les travaux Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb et TrackedMessages_Copy_BizTalkMsgBoxDb. Par conséquent, scriptez les travaux de l’Agent SQL uniquement après avoir exécuté le script UpdateDatabase.

Configuration requise

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

    • SQL Server 2019 Enterprise ou Standard

    • SQL Server 2017 Enterprise ou Standard

    • SQL Server 2016 Entreprise ou Standard.

      Consultez Limitations connues dans cet article pour connaître la limitation de l’édition SQL Server Standard.

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

Écouteur de groupe de disponibilité configuré avec un port autre que par défaut (1433)

Utilisez l’alias SQL sur BizTalk Server machines.

Groupes de disponibilité multi-sous-réseaux

BizTalk Server ne prend pas en charge l’option de connexion MultiSubnetFailover (=TRUE).

Reportez-vous à la documentation SQL pour plus d’informations sur les problèmes qui peuvent se produire lors de la connexion d’un client SQL qui ne prend pas en charge cette option à un groupe de disponibilité SQL à plusieurs sous-réseaux. Certains de ces problèmes sont abordés dans les liens suivants :

Routage en lecture seule

Le routage en lecture seule fait référence à la possibilité pour SQL Server d’acheminer les connexions entrantes d’un écouteur de groupe de disponibilité vers un réplica secondaire configuré pour autoriser les charges de travail en lecture seule.

BizTalk n’utilise pas Read-Only routage pour les connexions à ses bases de données. Cela signifie que l’option « Secondaire lisible » sur les réplicas de disponibilité dans le groupe de disponibilité n’a aucun impact sur les connexions aux bases de données BizTalk.

Comportement des instances d’hôte BizTalk pendant SQL Server basculement

Si le groupe de disponibilité SQL Server subit un basculement, les bases de données BizTalk Server sur le groupe de disponibilité sont temporairement indisponibles.

Comportement des instances de l'hôte In-process au cours d'un basculement SQL Server

Si les bases de données BizTalk Server ne sont pas disponibles, une instance in-process d’un hôte BizTalk Server est recyclée jusqu’à ce que la connexion au SQL Server soit restaurée. Une fois la connexion aux bases de données SQL Server restaurée, le traitement des documents reprend normalement.

Comportement des instances de l'hôte isolé au cours d'un basculement de SQL Server

Si les bases de données BizTalk Server ne sont pas disponibles, un instance isolé d’un hôte BizTalk Server s’interrompt et une erreur similaire à ce qui suit est générée dans le journal des applications 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.

Une fois la connexion aux bases de données SQL Server restaurée, un message d’information semblable au suivant est écrit dans le journal des applications BizTalk Server, puis le traitement des documents reprend normalement :

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

Copie des journaux de transaction pour la récupération d’urgence

BizTalk Server implémente des fonctionnalités de secours de base de données à l’aide de la copie des journaux de base de données. BizTalk Server copie des journaux de transaction automatise la sauvegarde et la restauration des bases de données et de leurs fichiers journaux des transactions, ce qui permet à un serveur de secours de reprendre le traitement de la base de données en cas de défaillance du serveur de base de données de production.

Les bases de données secondaires du groupe de disponibilité ne sont pas des sauvegardes. Continuez à sauvegarder les bases de données BizTalk et leurs journaux de transactions à l’aide de BizTalk Server travaux de copie des journaux de transaction. La façon dont la copie des journaux de transaction BizTalk est implémentée garantit que les sauvegardes sont toujours effectuées sur la réplica principale actuelle de chaque base de données. Le paramètre de préférence de sauvegarde sur le groupe de disponibilité n’est pas respecté par les BizTalk Server travaux de copie des journaux de transaction.

Si vous ajoutez d’autres bases de données BizTalk au travail de sauvegarde de bases de données BizTalk, veillez à utiliser le nom de l’écouteur de groupe de disponibilité comme serveur de base de données pour ces bases de données lors de la configuration de la sauvegarde.

Références

Limitations connues

Ces limitations concernent BizTalk Server, SQL Server groupe de disponibilité AlwaysOn et Azure Machines Virtuelles. Ces limitations peuvent ou non être traitées à l’avenir.

  • Les connexions, les travaux SQL Agent, le profil de messagerie SQL DB et les comptes ne sont pas gérés dans les groupes de disponibilité. Cela nécessite une modification manuelle des travaux pour s’assurer qu’ils s’exécutent sur le réplica principal.

  • SQL Server Analysis Services et SQL Server Integration Services ne participent pas aux groupes de disponibilité. Sans cette prise en charge de SQL Server, il n’existe aucune solution de haute disponibilité pour ces solutions dans Azure Machines Virtuelles. les fonctionnalités BAM de BizTalk Server dépendent de ces services.

  • Avant SQL Server 2016 SP2, les groupes de disponibilité ne prenaient pas en charge MSDTC entre les bases de données sur le même instance SQL.

    À compter de SQL Server 2016 SP2 et BizTalk Server 2016 CU5, les bases de données BizTalk peuvent utiliser les mêmes SQL Server instance.

  • BizTalk Server ne peut pas utiliser le routage Read-Only.

  • BizTalk Server ne définit pas la propriété de MultiSubnetFailover connexion.

  • Les travaux de sauvegarde BizTalk utilisant la copie des journaux de transaction ciblent toujours le réplica principal, quelle que soit la préférence de sauvegarde définie sur le groupe de disponibilité.

  • SQL Server 2016 Standard ne prend en charge qu’une seule base de données dans chaque groupe de disponibilité SQL AlwaysOn. Étant donné que BizTalk utilise de nombreuses bases de données, SQL Server Entreprise édition est généralement recommandée.

  • Si vous utilisez des machines virtuelles Azure, il est recommandé d’utiliser un port TCP/IP fixe dédié pour MSDTC. Lorsque vous utilisez un port TCP/IP fixe, vous ne limitez pas votre plage de ports RPC généralement utilisée avec des systèmes d’exploitation plus anciens . et cela vous aide à simplifier vos règles de pare-feu et d’équilibreur de charge. Pour éviter les conflits avec les ports inférieurs connus, envisagez d’utiliser un port fixe supérieur (par exemple >, 20000). La configuration de la prise en charge d’un port unique DTC décrit la clé de ServerTcpPort Registre. En plus du port fixe pour MSDTC, le port RPC main 135 est également utilisé.

Étapes suivantes

Planifiez la tolérance de panne.