SQL Server Always On 可用性グループを使用した高可用性 - BizTalk Server

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

ヒント

可用性グループ LAB を使用して BizTalk Server 2016 を設定する方法については、Microsoft フィールド エンジニアが作成した詳細なガイドを参照してください。 これはラボ環境に基づいており、いくつかの観察が含まれています。 試してみて下さい。

重要

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

可用性モードでは、Always On可用性グループを含むコミット オプションの詳細が表示されます。

背景と履歴

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

BizTalk では、SQL Server フェールオーバー クラスタリングとログ配布を使用して、データベースの高可用性、バックアップと復元、ディザスター リカバリーを提供します。 Azure IaaS (Azure 仮想マシン) では、以前は、サポートされている共有ディスクがないため、BizTalk (Windows および SQL) はフェールオーバー クラスター インスタンスをサポートしていません。これは、SQL と MSDTC のクラスタリングに必要です。 その結果、Azure VM を使用するときに BizTalk に HA ソリューションがありませんでした。 Azure 共有ディスクが利用可能になったため、Azure VM で SQL と MSDTC の両方をクラスター化できます。 Azure Shared Disks を使用した SQL フェールオーバー クラスター インスタンスは、最も高可用性のソリューションです。

SQL Server 2016 以降、SQL Server AlwaysOn 可用性グループでは、オンプレミスと Azure VM の使用に MSDTC がサポートされています。 その結果、SQL Server 2016 (またはそれ以降) の AlwaysOn 機能は、オンプレミスまたは Azure IaaS シナリオの BizTalk データベースでサポートされます。 記憶域スペース ダイレクト (S2D) を使用する場合は同期ディスク同期で余分なオーバーヘッドが発生し、フェールオーバー中に余分な時間が発生するため、SQL フェールオーバー クラスター インスタンスと比較して可用性が低下します。

SQL Server 2016 AlwaysOn 可用性グループ

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

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

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

重要

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

SQL Serverでは、2016 より前のバージョンでは AlwaysOn AG を使用した MSDTC はサポートされていません。 SQL Server 2016 SP2 では MSDTC トランザクション処理が改善されているため、SP2 以降をお勧めします。

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

BizTalk Serverの基本構成では、ルールと BAM データベースを含め、少なくとも 9 つのデータベースが作成されます。

2016 SP2 SQL Serverより前のバージョンでは、可用性グループは同じ SQL インスタンス上のデータベース間で MSDTC をサポートしていなかったため、BizTalk データベースは少なくとも 4 つの SQL インスタンスに分散する必要がありました。 この制限により、すべての BizTalk データベースで同じSQL Server インスタンスを使用できるように、SQL Server 2016 SP2 (またはそれ以上) と BizTalk Server 2016 CU5 (またはそれ以上) を使用することをお勧めします。 パフォーマンス上の理由から、複数の SQL インスタンスを使用することを検討することもできます (たとえば、MessageBox を別の SQL インスタンスに配置する)。

スケールアウトされた MessageBox シナリオ (複数の 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 Server 2016 の場合、この構成は次の図に示されており、可用性グループの BizTalk データベースに推奨されます (前述のように、SQL 2016 SP2 および BizTalk 2016 CU5 以降では、4 つの SQL インスタンスは不要になりました)。

BizTalk Server 2020 以降では、SSIS カタログを使用して BAM DTS パッケージの高可用性がサポートされています。 SSISDB データベースを、BizTalk Server データベースと同じ可用性グループに追加します。 この構成は次の図に示されており、可用性グループの BizTalk データベースに推奨されます (前述のように、4 つの SQL インスタンスは不要になりました)。

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

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

1. BizTalk アプリケーション ユーザー (各インプロセス ホストに対応する 1 つ以上)
2. BizTalk 分離ホスト ユーザー (各分離ホストに対応する 1 つ以上)
3. BizTalk Server 管理者
4. BizTalk Server B2B Operators
5. BizTalk Server オペレータ
6. SSO 管理者
7. BAM アラート ユーザー
8. BAM 管理 Web サービス ユーザー
9. ルール エンジンのサービス アカウントの更新

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

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

• BizTalkMgmtDb ジョブ:
  • BizTalk Server のバックアップ (BizTalkMgmtDb)
  • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
  • BizTalk Server の監視 (BizTalkMgmtDb)
• 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
• 追加のメッセージ ボックスでのジョブ
• BizTalkDTADb ジョブ:
  • DTA Purge and Archive (BizTalkDTADb)
• BizTalkRulesEngineDb ジョブ:
  • Rules_Database_Cleanup_BizTalkRuleEngineDb
• BAMAlertsApplication ジョブ:
  • 0 以上の DelAlertHistJob

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

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

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

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

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

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

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

1. OS の要件を確認します。

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

2. 必要な可用性グループを作成します。 [データベース ごとの DTC サポート ] オプションを使用して可用性グループが作成されていることを確認します。

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

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

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

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

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

   1. BizTalk Serverのすべての BizTalk サービスと Enterprise 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 台のサーバーでのみ UpdateDatabase.vbs を実行します。

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

      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 グループ内のすべてのサーバーで、UpdateRegistry.vbs を実行します。

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

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

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

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

要件

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

  • SQL Server 2019 Enterprise または Standard

  • SQL Server 2017 Enterprise または Standard

  • SQL Server 2016 Enterprise または Standard。

    SQL Server Standard エディションの制限については、この記事の「既知の制限事項」を参照してください。

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

既定以外のポートで構成された可用性グループ リスナー (1433)

BizTalk Server マシンで SQL エイリアスを使用します。

マルチサブネット可用性グループ

BizTalk Serverでは、MultiSubnetFailover (=TRUE) 接続オプションはサポートされていません。

このオプションをサポートしていない SQL クライアントをマルチサブネット SQL 可用性グループに接続するときに発生する可能性がある問題の詳細については、SQL ドキュメントを参照してください。 これらの問題の一部については、次のリンクを参照してください。

• マルチサブネット可用性グループでの接続タイムアウト
• フェールオーバー中のクライアント回復待機時間

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

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

BizTalk では、データベースへの接続に対して Read-Only ルーティングは使用されません。 つまり、可用性グループ内の可用性レプリカの "読み取り可能なセカンダリ" オプションは、BizTalk データベース接続に影響を与えません。

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

SQL Server可用性グループでフェールオーバーが発生した場合、可用性グループ上のBizTalk Server データベースは一時的に使用できなくなります。

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

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

SQL Server フェールオーバー時の分離ホスト インスタンスの動作

BizTalk 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 データベースとそのトランザクション ログBizTalk Serverバックアップを続行します。 BizTalk ログ配布の実装方法により、すべてのデータベースの現在のプライマリ レプリカに対してバックアップが常に実行されます。 可用性グループのバックアップ設定は、BizTalk Serverログ配布ジョブでは受け入れられません。

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

リファレンス

• BizTalk Server データベースの高可用性を実現する
• Microsoft Azure 仮想マシンのマイクロソフト サーバー ソフトウェアのサポート
• SQL Server データベース ミラーリング、ボリューム シャドウ コピー サービス、および AlwaysOn の使用
• AlwaysOn 可用性グループの概要 (SQL Server)
• データベース ミラーリングまたは AlwaysOn 可用性グループに対するデータベース間トランザクションのサポート (SQL Server)
• SQL Serverが WINDOWS SERVER 2012 R2 で MSDTC からトランザクションの結果を受信した場合、再登録を呼び出すことはできません
• BizTalk Server データベースのバックアップと復元
• BizTalk Server データベースを移動する方法
• データベースを復元する方法
• マルチサブネット可用性グループでの接続タイムアウト

既知の制限事項

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

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

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

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

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

• BizTalk Serverは、Read-Only ルーティングを使用できません。

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

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

• SQL Server 2016 Standard では、SQL AlwaysOn AG ごとに 1 つのデータベースのみがサポートされます。 BizTalk では多くのデータベースが使用されるため、通常、SQL Server Enterpriseエディションをお勧めします。

• Azure VM を使用する場合は、MSDTC 用の専用の固定 TCP/IP ポートを使用することをお勧めします。 固定 TCP/IP ポートを使用する場合、通常は古いオペレーティング システムで使用される RPC ポート範囲を制限しません。ファイアウォールとロード バランサーの規則を簡素化するのに役立ちます。 既知の下位ポートとの競合を回避するには、より高い固定ポート (20000 など >) の使用を検討してください。 DTC 単一ポート サポートの構成 では、 ServerTcpPort レジストリ キーについて説明します。 MSDTC の固定ポートに加えて、メイン RPC ポート 135 も使用されます。

次のステップ

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