Partage via

Haute disponibilité avec les groupes de disponibilité Always On SQL Server - BizTalk Server

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

Conseil / Astuce

La configuration de 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 ça.

Important

  • BizTalk Server prend en charge les groupes de disponibilité Always On à partir de SQL Server 2016 et versions ultérieures. Si vous utilisez une version précédente de SQL Server, 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 la tâche de sauvegarde du serveur BizTalk et d'utiliser la copie des journaux de transaction. Pour plus d’informations, consultez sauvegarde et restauration des bases de données BizTalk Server .

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

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 de messages. L’ordinateur de base de données capture ce travail et le conserve sur le disque.

BizTalk utilise le clustering de basculement SQL Server et la copie des journaux de transaction pour fournir haute disponibilité, sauvegarde, restauration et récupération d’urgence pour ses bases de données. Dans Azure IaaS (machines virtuelles Azure), anciennement, BizTalk (Windows et SQL) ne supportait pas les instances de cluster de basculement, car il n’y avait pas de disques partagés pris en charge, requis pour le clustering du SQL et de MSDTC. Par conséquent, BizTalk n’a pas de solution de haute disponibilité lors de l’utilisation de machines virtuelles Azure. Étant donné qu’Azure Shared Disk est désormais disponible, il est possible de clusterr SQL et MSDTC dans les 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, les groupes de disponibilité AlwaysOn SQL Server prennent en charge MSDTC pour les machines virtuelles locales et à l’aide 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 IaaS Azure. Étant donné qu’il existe une surcharge supplémentaire avec la synchronisation de disque synchrone lors de l’utilisation des espaces de stockage direct (S2D) et du temps supplémentaire pendant les basculements, il est moins hautement disponible par rapport à 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 WSFC (Clustering de basculement Windows Server). 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'état de santé 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 listener. Un listener de groupe de disponibilité fournit un ensemble de ressources associées à un groupe de disponibilité donné afin d'orienter les connexions client vers le réplica de disponibilité approprié.

Important

SQL Server 2016 prend en charge MSDTC avec des 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 toutes 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, notamment les règles et les bases de données BAM.

Avant SQL Server 2016 SP2, les groupes de disponibilité ne prenaient pas en charge MSDTC entre les bases de données sur la même instance SQL, de sorte que les bases de données BizTalk devaient ê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 la même instance SQL Server. Vous pouvez toujours envisager d’utiliser plusieurs instances SQL pour des raisons de performances (par exemple, avoir MessageBox sur une autre instance SQL).

Dans un scénario MessageBox avec mise à l'échelle horizontale (une configuration avec plusieurs MessageBox), il existe plusieurs bases de données MessageBox et chaque base de données MessageBox doit être ajoutée aux Groupes de disponibilité.

BizTalk Server dépend également de SQL Server Analysis Services et de SQL Server Integration Services pour l’analyse BAM et l’archivage. 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 instance SQL Server autonome pour les bases de données BAMArchive et BAMAnalysis Analysis Services. Pour les installations locales, l'instance SQL de basculement en cluster peut être utilisée pour mettre en place une configuration à 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 recommandée de SQL Server Always On sur BizTalk Server 2016 et versions antérieures

À compter de BizTalk Server 2020, la haute disponibilité pour les 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 recommandée de SQL Server Always On sur BizTalk Server 2020 et versions ultérieures

Outre les bases de données SQL Server, la configuration de BizTalk Server crée également des logins de sécurité SQL Server, et des tâches SQL Agent. Les groupes de disponibilité AlwaysOn permettent uniquement de gérer les bases de données à l’intérieur d’un groupe de disponibilité. Sur tous les réplicas de disponibilité, les identifiants BizTalk Server et les jobs SQL Agent doivent être créés et mis à jour manuellement.

La liste suivante des connexions de sécurité SQL Server est associée à BizTalk Server. Vous pouvez avoir des connexions supplémentaires créées pour vos applications BizTalk Server. Dans ce 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 de l’hôte isolé BizTalk (un ou plusieurs correspondant à chaque hôte isolé)
  3. Administrateurs BizTalk Server
  4. Opérateurs BizTalk Server B2B
  5. Opérateurs BizTalk Server
  6. Administrateurs d’authentification unique
  7. Utilisateur des alertes BAM
  8. Utilisateur du service web de gestion BAM
  9. Compte de service de mise à jour du moteur de règles

Si vous avez créé des hôtes supplémentaires ou créez des hôtes supplémentaires ultérieurement, il y aura de nouvelles connexions SQL créées dans le cadre de ce processus. Veillez à créer manuellement ces identifiants SQL sur les réplicas correspondants.

Les travaux SQL Server Agent suivants sont associés à BizTalk Server. Les travaux installés sur chaque serveur sont différents en fonction des fonctionnalités installées et configurées. La plupart de ces travaux sont créés pendant la configuration de BizTalk Server. Plusieurs sont créés lors de la configuration de la copie des journaux de transaction. Ces travaux doivent être répliqués sur chaque instance de SQL Server hébergeant la réplique de leur base de données BizTalk correspondante. Cette opération doit être effectuée manuellement.

  • Tâches BizTalkMgmtDb :
    • Sauvegarde BizTalk Server (BizTalkMgmtDb)
    • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
    • Surveiller BizTalk Server (BizTalkMgmtDb)
  • Tâches 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
  • Tâches sur des boîtes de dialogue supplémentaires
  • Travail BizTalkDTADb :
    • Nettoyage et Archivage du DTA (BizTalkDTADb)
  • Tâche 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 des tâches SQL Agent sont dupliquées sur chaque réplica pour le basculement, elles s’exécutent sur le réplica correspondant, qu'il soit dans son 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 ‘dbname’ par le nom de base de données correspondant par rapport auquel le travail est configuré pour s’exécuter. L’exemple suivant montre cette modification pour TrackedMessages_Copy_BizTalkMsgBoxDb sur BizTalkMsgBoxDb :

Modifier 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 les besoins de votre système d’exploitation :
  2. Créez les groupes de disponibilité requis. Vérifiez que les groupes de disponibilité sont créés avec l'option Support DTC par base de données.
  3. Lors de la configuration de BizTalk Server et de la spécification du nom du serveur SQL, utilisez le nom de l’écouteur du groupe de disponibilité au lieu du nom de l’ordinateur réel. Cela crée les bases de données BizTalk, les connexions et les jobs 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, service BAMAlerts, et ainsi de suite) et arrêtez les travaux SQL Agent.
  5. Ajoutez maintenant des bases de données BizTalk aux groupes de disponibilité respectifs.
  6. Placez le contenu des étapes du job SQL Agent dans le bloc IF (mentionné précédemment) pour garantir qu’elles ne s’exécutent que si la cible est la réplique principale.
  7. Script les connexions et les tâches de l'Agent SQL pour les répliquer sur le réplica correspondant.
  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îte de message supplémentaire ou que vous 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 message ou la base de données Alertes BAM sur le réplica principal actuel. Veillez à le modifier sur la réplique principale, puis à les créer manuellement sur les répliques secondaires correspondantes.
  10. À compter de BizTalk Server 2020 et versions ultérieures, les packages DTS BAM 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 scripts UpdateDatabase.vbs et UpdateRegistry.vbs sur les machines BizTalk après les étapes ci-dessus. Ceci est abordé 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 les besoins de votre système d’exploitation :

  2. Créez les groupes de disponibilité requis. Vérifiez que les groupes de disponibilité sont créés avec l’option DTC par base de données.

  3. Arrêtez le traitement BizTalk et les tâches 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 du groupe de disponibilité.

  6. Scripts des connexions et des tâches de l'Agent SQL sur les instances SQL correspondantes actuellement dans le rôle principal dans le groupe de disponibilité.

  7. Exécutez les scripts UpdateDatabase.vbs et UpdateRegistry.vbs sur les machines BizTalk à l'aide des étapes suivantes. Entrez L’Écouteur du Groupe de Disponibilité comme nouveau nom de serveur dans le fichier 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 SERVEUR SQL hébergeant les 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 disposez des bases de données BAMAnalysis, BAM ou RuleEngineDB, décochez les commentaires des sections appropriées.

    3. Ouvrez une invite de commandes, puis 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 dans le 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 du 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 le réplica de la base de données BAMAlerts.

  10. Placez le corps des étapes du 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 jobs SQL Agent afin de les répliquer sur la réplique correspondante. Le script UpdateDatabase met également à jour le nom du serveur dans les travaux Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb et TrackedMessages_Copy_BizTalkMsgBoxDb. Scriptez donc les travaux SQL Agent uniquement après avoir exécuté le script UpdateDatabase.

Spécifications

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

    • SQL Server 2019 Enterprise ou Standard

    • SQL Server 2017 Enterprise ou Standard

    • SQL Server 2016 Enterprise ou Standard.

      Consultez les limitations connues de cet article pour la limitation de SQL Server Standard Edition.

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

Écouteur de groupe de disponibilité configuré avec le port non par défaut (1433)

Utilisez l’alias SQL sur les machines BizTalk Server.

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 multi-sous-réseau. Certains de ces problèmes sont abordés dans les liens suivants :

Routage en lecture seule

Le routage en lecture seule désigne la capacité de SQL Server à rediriger les connexions entrantes d'un écouteur de groupe de disponibilité vers une réplica secondaire configurée pour supporter des charges de travail en lecture seule.

BizTalk n’utilise pas le routage en lecture seule pour les connexions à ses bases de données. Cela signifie que l'option « Secondaire lisible » pour les réplicas de disponibilité dans le groupe de disponibilité n'affecte pas les connexions aux bases de données BizTalk.

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

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 d’hôte en processus pendant le basculement de 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 à 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 d’hôte isolées pendant le basculement de SQL Server

Si les bases de données BizTalk Server ne sont pas disponibles, une instance isolée d’un hôte BizTalk Server s’interrompt et une erreur similaire à celle-ci 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 similaire à ce qui suit 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.

Expédition de journaux pour la récupération en cas de sinistre

BizTalk Server implémente des fonctionnalités de secours de base de données via l’utilisation de la copie des journaux de données. La journalisation des journaux de transaction de BizTalk Server automatise la sauvegarde et la restauration des bases de données et de leurs fichiers journaux de transactions, permettant ainsi à un serveur de secours d'assumer le traitement des bases de données en cas de défaillance du serveur de base de données de production.

Les bases de données secondaires dans le groupe de disponibilité ne sont pas des sauvegardes. Continuez à sauvegarder les bases de données BizTalk et leurs journaux de transactions à l’aide des tâches BizTalk Server Log Shipping. La façon dont BizTalk Log Shipping est implémentée garantit que les sauvegardes sont toujours effectuées sur le réplica principal actuel de chaque base de données. Le paramètre de préférence de sauvegarde sur le groupe de disponibilité n’est pas pris en compte par les travaux BizTalk Server Log Shipping.

Si vous ajoutez des bases de données BizTalk additionnelles à la tâche de sauvegarde des bases de données BizTalk, veillez à utiliser le nom de l’écouteur du groupe de disponibilité comme serveur de bases de données lors de la configuration de la sauvegarde.

References

Limitations connues

Ces limitations concernent BizTalk Server, le groupe de disponibilité AlwaysOn SQL Server et les machines virtuelles Azure. 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 dans les tâches pour garantir leur exécution 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 celles-ci dans les machines virtuelles Azure. Les fonctionnalités BAM de BizTalk Server dépendent de ces services.

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

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

  • 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 Log Shipping ciblent toujours le réplica principal, quelle que soit la préférence de sauvegarde définie pour 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, l’édition SQL Server Enterprise 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 il permet de 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 du port unique DTC décrit la clé de ServerTcpPort Registre. Outre le port fixe pour MSDTC, le port RPC principal 135 est également utilisé.

Étapes suivantes

Planifiez la tolérance de panne.

  • Last updated on