Bangkok Magazine

SQL Server Always On Availability Groupsを使用した高可用性-BizTalk Server

Posted on
  • 01/14/2020
  • 13 読むべき分
    • M
    • m
    • p
    • n
    • w
    • +8

SQL Server AlwaysOn可用性グループを使用して高可用性を構成します。

ヒント

可用性グループを使用したBizTalk Server2016のセットアップLABでは、Microsoftフィールドエンジニアが作成したステップバイステップガイドを提供しています。 これは実験室環境に基づいており、いくつかの観察が含まれています。 それを見てください。

重要

  • BizTalk Serverでは、SQL Server2016以降の可用性グループで常にサポートされています。 以前のバージョンのSQL Serverを使用している場合は、この記事は適用されません。
  • BizTalk Serverでは同期コミットモードがサポートされていますが、非同期コミットモードはサポートされていません。 障害復旧の場合は、BizTalk Serverのバックアップジョブを構成し、ログ配布を使用することをお勧めします。 詳細については、”BizTalk Serverデータベースのバックアップと復元”を参照してください。

可用性モードは、Always On可用性グループを使用したコミットオプションの詳細を示します。

背景と履歴

BizTalk Serverは、データの永続性のためにSQL Serverに大きく依存しています。 BizTalk Serverの他のコンポーネントとホストは、メッセージの受信、処理、ルーティングなど、異種のビジネスアプリケーションを統合する際に特定の役割を持ちます。 データベースコンピュータはこの作業をキャプチャし、ディスクに保持します。

BizTalkは、SQL Serverフェールオーバークラスタリングとログ配布を使用して、オンプレミスデータベースの高可用性、バックアップと復元、および障害復旧を提供します。 Azure iaas(Azure virtual machines)では、以前のバージョンのSQL Serverではフェールオーバークラスターインスタンスがサポートされていません(MSDTCはサポートされていません)。 その結果、Azure Vmを使用する場合、BizTalkにはHAソリューションがありませんでした。

SQL Server2016以降、sql Server AlwaysOn可用性グループは、オンプレミスおよびAzure Vmの使用のためのMSDTCをサポートしています。 その結果、sql Server2016AlwaysOn機能は、オンプレミスまたはAzure IaaSシナリオのBizTalkデータベースでサポートされます。

SQL Server2016AlwaysOn可用性グループ

AlwaysOn可用性グループを展開するには、Windows Serverフェールオーバークラスタリング(WSFC)クラスターが必要です。 特定の可用性グループの各可用性レプリカは、同じWSFCクラスターの別のノードに存在する必要があります。 WSFCリソースグループは、作成するすべての可用性グループに対して作成されます。 WSFCクラスターは、このリソースグループを監視して、プライマリレプリカの正常性を評価します。

次の図は、1つのプライマリレプリカと4つのセカンダリレプリカを含む可用性グループを示しています。

BizTalk Serverを使用したSQL AlwaysOn可用性グループのプライマリレプリカ

クライアントは、可用性グループリスナーを使用して、特定の可用性グループのプライマリレプリカに接続できます。 可用性グループリスナーは、特定の可用性グループに接続されているリソースのセットを提供し、クライアント接続を適切な可用性レプリカに指示します。

重要

SQL Server2016は、WINDOWS Server2016およびWindows Server2012R2でAlwaysOn可用性グループ(AG)を使用したMSDTCをサポートしています。 Windows Server2012R2では、3090973Windows修正プログラムをインストールする必要があります。Windows Server2016では、RemoteAccessEnabledレジストリキーを有効にする必要があります。

SQL Serverは、2016年より前のバージョンでは、AlwaysOn AGでMSDTCをサポートしていません。

AlwaysOn可用性グループを使用したBizTalkデータベースの高可用性の提供

BizTalk Serverの基本構成では、ルールとBAMデータベースを含む9つ以上のデータベースが作成されます。

スケールアウトメッセージボックスシナリオ(複数のMessageBoxを持つ構成)では、複数のMessageBoxデータベースがあり、各MessageBoxデータベースを可用性グループに追加する必要があり

BizTalk Serverは、BAM分析とアーカイブのためにSQL Server Analysis ServicesとSQL Server Integration Servicesにも依存しています。 SQL Serverでは、Azure IaaSのIntegration ServicesまたはAnalysis Services用の高可用性ソリューションは提供されていません。 したがって、BAMArchiveおよびBAMAnalysis Analysis Servicesデータベースには、別のスタンドアロンSQL Serverインスタンスを使用することをお勧めします。 オンプレミスのインストールでは、SQLフェールオーバークラスタリングインスタンスを使用して高可用性構成を設定できます。

BizTalk Server2016以前の場合、この構成は次の図に示されており、可用性グループのBizTalkデータベースに推奨されています:

BizTalk Server2016およびそれ以前のバージョンで推奨されるSQL Server always onの構成

BizTalk Server2020以降では、SSISカタログを使用してBAM DTSパッケージの高可用性がサポートされています。 SSISDBデータベースをBizTalk Serverデータベースと同じ可用性グループに追加します。 この構成は次の図に示されており、可用性グループのBizTalkデータベースに推奨されています:

BizTalk Server2020以降のバージョンで推奨されるSQL Server always onの構成

BizTalk Server構成では、SQL Serverデータベースに加えて、SQL ServerセキュリティログインとSQLエージェントジョブも作成されます。 AlwaysOn可用性グループは、可用性グループ内のデータベースを管理する機能のみを提供します。 すべての可用性レプリカで、BizTalk ServerのログインおよびSQLエージェントジョブを手動で作成および更新する必要があります。

次のSQL Serverセキュリティログインの一覧は、BizTalk Serverに関連付けられています。 BizTalk Serverアプリケーション用に追加のログインが作成されている場合があります。 その場合は、BizTalkデータベースのレプリカをホストするSQL Serverのすべてのインスタンスでそれらをレプリケートする必要があります。

  1. BizTalkアプリケーションユーザー(各in-procホストに対応する1つ以上)
  2. BizTalk分離ホストユーザー(各分離ホストに対応する1つ以上)
  3. BizTalk Server管理者
  4. BizTalk Server B2B演算子
  5. BizTalk Server演算子
  6. SSO管理者

    7. ユーザー

  7. Bam管理webサービスユーザー
  8. ルールエンジン更新サービスアカウント

追加のホストを作成した場合、または後で追加のホストを作成する場合は、 このプロセス。 これらのSQLログインは、対応するレプリカで手動で作成する必要があります。

次のSQL ServerエージェントジョブがBizTalk Serverに関連付けられています。 各サーバーにインストールされているジョブは、インストールおよび構成されている機能に応じて異なります。 これらのジョブのほとんどは、BizTalk Serverの構成中に作成されます。 いくつかは、ログ配布を構成するときに作成されます。 これらのジョブは、対応するBizTalkデータベースのレプリカをホストするSQL Serverの各インスタンスでレプリケートする必要があります。 これは手動で実行する必要があります。

  • BizTalkMgmtDb jobs:
    • Backup BizTalk Server (BizTalkMgmtDb)
    • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
    • Monitor BizTalk Server (BizTalkMgmtDb)
  • BizTalkMsgBoxDb jobs:
    • MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb
    • MessageBox_Message_Cleanup_BizTalkMsgBoxDb
    • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
    • MessageBox_Parts_Cleanup_BizTalkMsgBoxDb
    • MessageBox_UpdateStats_BizTalkMsgBoxDb
    • Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb
    • PurgeSubscriptionsJob_BizTalkMsgBoxDb
    • TrackedMessages_Copy_BizTalkMsgBoxDb
  • Jobs on additional msgboxes
  • BizTalkDTADb job:
    • DTAパージとアーカイブ(BizTalkDTADb)
  • ジョブ:
      • BAMAlertsApplicationジョブ:
        • 0以上のDelalerthistジョブ

      SQLフェールオーバークラスタリングインスタンスとは異なり、可用性グループでは、すべてのレプリカがアクティブで実行中であり、使用可能です。 フェールオーバーのために各レプリカでSQLエージェントジョブが複製されると、現在プライマリロールとセカンダリロールのどちらにあるかに関係なく、対応す これらのジョブが現在のプライマリレプリカでのみ実行されるようにするには、次のように、すべてのジョブのすべてのステップをIFブロック内:

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

      'dbname'は、ジョブが実行されるように構成されている対応するデータベース名に置き換えます。 次の例は、BizTalkMsgBoxDbのTrackedmessages_Copy_Biztalkmsgboxdbに対するこの変更を示しています:

      BizTalk Serverを使用してAlwaysOn可用性グループのSQLエージェントジョブの名前を変更する

      可用性グループが既に設定されている場合にBizTalkを構成する

      1. OS要件を確認します。
        • すべてのWindows Server2012R2コンピューターに3090973MSDTC修正プログラムをインストー
        • すべてのWindows Server2016コンピューターで、RemoteAccessEnabledレジストリキーを有効にします(KB資料が開きます)。
      2. 必要な可用性グループを作成します。 可用性グループがPer Database Dtc Supportオプションを使用して作成されていることを確認します。
      3. BizTalk Serverを構成してSQL server名を指定する場合は、実際のコンピューター名ではなく、可用性グループのリスナー名を使用します。 これにより、現在のプライマリレプリカにBizTalkデータベース、ログイン、およびSQLエージェントジョブが作成されます。
      4. BizTalk処理(ホストインスタンス、SSOサービス、IIS、ルールエンジン更新サービス、BAMAlertsサービスなど)を停止し、SQLエージェントジョブを停止します。
      5. ここで、それぞれの可用性グループにBizTalkデータベースを追加します。
      6. SQLエージェントジョブステップの本文をIFブロック(前述)内に囲み、ターゲットがプライマリレプリカである場合にのみ実行されるようにします。
      7. スクリプトログインとSQLエージェントジョブを対応するレプリカにレプリケートします。
      8. セカンダリレプリカをホストしている対応するSQLインスタンスで、SQL DBMailプロファイルとBAMアラートのアカウントを複製します。
      9. メッセージボックスデータベースを追加するか、新しいBAMアクティビティ/ビューを後でデプロイする場合は、現在のプライマリレプリカ上の新しいメッ プライマリレプリカで編集し、対応するセカンダリレプリカで手動で作成してください。
      10. BizTalk Server2020以降では、BAM DTSパッケージがSSISカタログに展開されます。 SsisdbデータベースをBizTalkデータベースと同じ可用性グループに追加します。 詳細については、”ALWAYSON for SSISカタログ”を参照してください。

      この構成は、プライマリレプリカをホストするSQLインスタンスを使用して行うこともできます。 この場合、BizTalk構成の後、上記の手順の後にBizTalkコンピューターでUpdateDatabase.vbsおよびUpdateRegistry.vbsスクリプトを実行します。 これについては、次のセクションで詳しく説明します。

      既存のBizTalkデータベースを可用性グループに移動する

      1. OSの要件を確認する:

        • すべてのWindows Server2012R2コンピューターで、3090973MSDTC修正プログラムをインストール(KB資料を開きます)
        • すべてのWindows Server2016コンピューターで、RemoteAccessEnabledレジストリキーを有効にします(KB資料を開)

      2. 必要な可用性グループを作成します。 可用性グループがPer Database Dtc Supportオプションを使用して作成されていることを確認します。

      3. BizTalk処理およびSQLエージェントジョブを停止します。

      4. すべてのBizTalkデータベースの完全バックアップを実行します。

      5. 可用性グループのプライマリロールにあるSQLインスタンスでBizTalkデータベースを復元します。

      6. 現在可用性グループのプライマリロールにある対応するSQLインスタンスのスクリプトログインとSQLエージェントジョブ。

      7. 次の手順を使用して、BizTalkコンピューターでUpdateDatabase.vbsおよびUpdateRegistry.vbsスクリプトを実行します。 入力更新情報xmlに、可用性グループリスナーを新しいサーバー名として入力します。

        1. BizTalk Server上のすべてのBizTalkサービスとエンタープライズSSOサービスを停止します。 SQL ServerでSQLエージェントサービスを停止します。

        2. BizTalk Serverで、SampleUpdateInfoを編集します。次のフォルダー内のxml:

          32ビットコンピューター: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

          64-ビットコンピュータ: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

          1. “SourceServer”を移行元サーバー名(古いデータベースをホストする古いSQL Server)に置き換えます。
          2. “DestinationServer”を、可用性グループリスナー名である宛先サーバーの名前に置き換えます。
          3. BAMAnalysis、BAMデータベース、またはRuleEngineDBがある場合は、適切なセクションのコメントを解除します。

        3. コマンドプロンプトを開き、

          32ビットコンピュータに移動します: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

          64-ビットコンピュータ: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

          コマンドプロンプトで、次のコマンドを実行します:
          cscript UpdateDatabase.vbs SampleUpdateInfo.xml

          更新されたデータベースを実行します。BizTalkグループ内の1つのサーバー上のvbsのみ。

        4. 編集したSampleUpdateInfoをコピーします。このBizTalkグループ内のすべてのBizTalk Serverコンピューター上の次のフォルダーにxmlファイル:

          32ビットコンピューター: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

          64-ビットコンピュータ: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

        5. BizTalk Serverグループ内の各コンピューターで、コマンドプロンプトを開き、

          32ビットコンピューターに移動します: %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

          64-ビットコンピュータ: %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

          コマンドプロンプトで、次のコマンドを実行します:
          cscript UpdateRegistry.vbs SampleUpdateInfo.xml

          更新プログラムを実行します。BizTalkグループ内のすべてのサーバー上のvbs。

      8. 次に、データベースをそれぞれの可用性グループに移動します。

      9. BAMALERTSデータベースのレプリカをホストしているSQLインスタンスで、BAMアラートのSQL DBMailプロファイルとアカウントを複製します。

      10. SQLエージェントジョブ-ステップの本文をIFブロック内で囲み、ターゲットがプライマリである場合にのみ実行されるようにします。

      11. スクリプトログインとSQLエージェントジョブは、対応するレプリカ上でレプリケートします。 UpdateDatabaseスクリプトは、Operations_Operateoninstances_Onmaster_BiztalkmsgboxdbジョブとTrackedmessages_Copy_Biztalkmsgboxdbジョブのサーバー名も更新します。 Sqlエージェントジョブは、UpdateDatabaseスクリプトを実行した後にのみスクリプト化します。

      要件

      • BizTalk Server:
        • BizTalk Server2020Enterprise
        • BizTalk Server2016Enterprise CU5
      • SQL Server:

        • SQL Server2019EnterpriseまたはStandard

        • SQLサーバー2017年の企業か標準

        • SQLサーバー2016年の企業か標準。

          SQL Server Standard Editionの制限については、この資料の既知の制限を参照してください。

      • Windows Server
        • Windows Server2019
        • Windows Server2016
        • Windows Server2012R2

      既定以外のポート(1433)

      で構成された可用性グループリスナーは、BizTalk ServerコンピューターでSQLエイリアスを使用します。

      サポート可用性グループのマルチサブネットフェールオーバー

      BizTalk Serverは、Multisubnetfailover接続オプションをサポートしていないデータベース接続にMicrosoft OLE DBを使用します。 BizTalk ServerではMultiSubnetFailover (=TRUE)接続オプションがサポートされていないため、マルチサブネットフェールオーバー中に回復時間が長くなる可能性があります。

      読み取り専用ルーティング

      読み取り専用ルーティングとは、SQL Serverが読み取り専用ワークロードを許可するように構成されているセカンダリレプリカに、可用性グループリスナーの受信接続をルーティングする機能を指します。

      BizTalkでは、データベースへの接続のいずれにも読み取り専用ルーティングは使用されません。 つまり、可用性グループ内の可用性レプリカの”読み取り可能なセカンダリ”オプションは、BizTalkデータベース接続には影響しません。

      SQL Serverフェールオーバー中のBizTalkホストインスタンスの動作

      SQL Server可用性グループにフェールオーバーが発生した場合、可用性グループのBizTalk Serverデータベースは一時的に

      SQL Serverフェールオーバー中のインプロセスホストインスタンスの動作

      BizTalk Serverデータベースが使用できない場合、Sql Serverへの接続が復元されるまで、BizTalk Serverホストのイン SQL Serverデータベースへの接続が復元されると、ドキュメント処理は正常に再開されます。

      Sql Serverフェールオーバー中の分離されたホストインスタンスの動作

      BizTalk Serverデータベースが使用できない場合、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.

      SQL Serverデータベースへの接続が復元されると、BizTalk Serverアプリケーションログに次のような情報メッセージが書き込まれ、ドキュメント処理が正常に再開されま:

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

      障害復旧のログ配布

      BizTalk Serverは、データベースログ配布を使用してデータベーススタンバイ機能を実装します。 BizTalk Serverのログ配布では、データベースとそのトランザクションログファイルのバックアップと復元が自動化され、運用データベースサーバーに障害が発生した場

      可用性グループのセカンダリデータベースはバックアップではありません。 引き続き、BizTalk Serverログ配布ジョブを使用して、BizTalkデータベースとそのトランザクションログをバックアップします。 BizTalkログ配布の実装方法により、すべてのデータベースの現在のプライマリレプリカに対して常にバックアップが実行されます。 可用性グループのバックアップ基本設定は、BizTalk Serverログ配布ジョブでは適用されません。

      他のBizTalkデータベースをBizTalkデータベースのバックアップジョブに追加する場合は、バックアップの設定時に可用性グループリスナー名をデータベースサーバーとして使

      • BizTalk Serverデータベースの高可用性の提供
      • Microsoft azure仮想マシンのMicrosoft serverソフトウェアサポート
      • SQL Serverデータベースミラーリング、ボリュームシャドウコピーサービス、およびAlwaysOn
      • AlwaysOn可用性グループ(SQL Server)の概要
      • データベースミラーリングまたはAlwaysOn可用性グループ(SQL Server)のクロスデータベーストランザクションのサポート
      • sql ServerがWindows Server2012R2でMsdtcからトランザクション結果を受信したときにreenlistを呼び出すことができません
      • biztalk serverのバックアップと復元 データベース
      • BizTalk Serverデータベースを移動する方法
      • データベースを復元する方法
      • マルチサブネット可用性グループの接続タイムアウト

      既知の制限

      これらの制限は、BizTalk Server、SQL Server AlwaysOn可用性グループ、 これらの制限は、将来的に対処される場合とされない場合があります。

      • ログイン、SQLエージェントジョブ、SQL DBメールプロファイル、およびアカウントは、可用性グループ内では管理されません。 これには、ジョブがプライマリレプリカに対して実行されるように手動で変更する必要があります。

      • SQL Server Analysis ServicesおよびSQL Server Integration Servicesは、可用性グループには参加しません。 SQL Serverからのこのサポートがなければ、Azure仮想マシンではこれらのHAソリューションはありません。 BizTalk ServerのBAM機能は、これらのサービスに依存します。

      • SQL Server2016SP2より前のバージョンでは、可用性グループは同じSQLインスタンス上のデータベース間のMSDTCをサポートしていません。

        SQL Server2016SP2およびBizTalk Server2016CU5以降では、BizTalkデータベースで同じSQL Serverインスタンスを使用できます。

      • BizTalk Serverでは読み取り専用ルーティングを使用できません。

      • BizTalk Serverでは、MultiSubnetFailover接続プロパティは設定されていません。

      • ログ配布を使用するBizTalkバックアップジョブは、可用性グループのバックアップ設定に関係なく、常にプライマリレプリカを対象とします。

      • SQL Server2016Standardは、各SQL AlwaysOn AGで1つのデータベースのみをサポートしています。 BizTalkでは多くのデータベースが使用されるため、通常はSQL Server Enterprise editionをお勧めします。

      • Azure Vmを使用する場合は、MSDTCに専用の固定TCP/IPポートを使用することをお勧めします。 固定TCP/IPポートを使用する場合、古いオペレーティングシステムで一般的に使用されるRPCポートの範囲を制限することはありません。 既知の下位ポートとの競合を回避するには、上位の固定ポート(>20000など)を使用することを検討してください。 DTCシングルポートサポートの構成ServerTcpPortレジストリキーについて説明します。 MSDTCの固定ポートに加えて、メインRPCポート135も使用されます。

      フォールトトレランスを計画する。

    コメントを残す

    メールアドレスが公開されることはありません。