高可用性の計画
BizTalk Serverの高可用性は、BizTalk Serverデプロイでの可用性を中断する可能性がある機能コンポーネントの回復に重点を置いています。
BizTalk Serverで高可用性を実証するには、障害を引き起こし、回復における製品の有効性を測定する必要があります。 高可用性BizTalk Server展開により、外部のアプリケーションやシステムに対してエラーや障害が透過的になり、中断を最小限に抑えてすべてのサービスが正常に機能し続けることができます。
高可用性を提供するBizTalk Serverデプロイを設計するには、アプリケーション統合またはビジネス プロセス統合シナリオに関連する各機能コンポーネントの冗長性を実装する必要があります。 BizTalk Server、データを処理するホストからデータを概念的に分離することで、これらのシナリオの実装を簡略化します。 ホストは、オーケストレーション、送信ハンドラー、受信ハンドラーなど、BizTalk 項目の論理コンテナーです。 ホスト インスタンスを作成し、ホストに割り当てます。 ホスト インスタンスとは、特定のサーバー上のホストを物理的に表現したものです。 これは、BTSNTSvc.exe と呼ばれるBizTalk Server サービス プロセスか、IIS プロセスなどの別のプロセスです。 そのため、BizTalk Serverの高可用性を提供するには、次のように、複数のホスト インスタンスを実行し、BizTalk Server データベースをクラスタリングする必要があります。
BizTalk ホストのアーキテクチャ。 BizTalk Serverを使用すると、ホストを分離し、複数のホスト インスタンスを実行して、メッセージの受信、オーケストレーションの処理、メッセージの送信などの主要な機能の高可用性を実現できます。 BizTalk Serverはホスト インスタンスを介して複数のコンピューターにワークロードを自動的に分散するため、これらのホストには追加のクラスタリングや負荷分散メカニズムは必要ありません。 ただし、HTTP アダプターと SOAP アダプターの受信ハンドラーを実行するホストには、高可用性を提供するためにネットワーク負荷分散 (NLB) などの負荷分散メカニズムが必要であり、FTP、MSMQ、POP3、SQL、SAP の受信ハンドラーを実行するホストには、高可用性を提供するためのクラスタリング メカニズムが必要です。
Note
2 フェーズ コミット シナリオに対応するには、常に SAP 受信アダプターをクラスター化する必要があります。
BizTalk Server データベースのアーキテクチャ。 BizTalk Server データベースの高可用性構成は、通常、アクティブ/パッシブ サーバー クラスター構成で構成された 2 つ以上のSQL Server データベース コンピューターで構成されます。 これらのコンピューターは、共通のディスク リソース (RAID 1+0 SCSI ディスク アレイや記憶域ネットワークなど) を共有し、Windows フェールオーバー クラスタリングを使用してバックアップの冗長性とフォールト トレランスを提供します。
高可用性に不可欠なもう 1 つの BizTalk 機能コンポーネントは、マスター シークレット サーバーです。 BizTalk Serverは、このサービスに依存して暗号化キーを取得します。
このセクションでは、これらの各カテゴリの高可用性に対処する方法について説明します。 BizTalk Server高可用性ソリューションは Windows とSQL Server上に構築されているため、BizTalk Server用にホストを構成する前に、これらの製品を高可用性で展開してください。 こうした基盤となる製品の高可用性を実現する方法については、次のリンクを参照してください。
高可用性ソリューション (SQL Server)](/sql/sql-server/failover-clusters/high-availability-solutions-sql-server)
コンポーネント障害の影響を理解する
次の表に、BizTalk Server環境のコンポーネントと依存関係と、コンポーネントまたは依存関係が失敗した場合のBizTalk Server環境への影響を示します。 コンポーネントと依存関係のどちらをクラスター化するかを決定するときは、潜在的な障害のスコープを考慮する必要があります。
| コンポーネントまたは依存関係 | 障害の範囲 |
|---|---|
| SQL Server | システム全体。 SQL Serverが失敗した場合、BizTalk Serverはドキュメントを処理できません。 |
| [マスター シークレット サーバー] | システム全体。 マスター シークレット サーバーが失敗した場合、BizTalk Serverはドキュメントを処理できません。 メモ： マスター シークレット サーバーが失敗した場合、BizTalk グループ内の各 BizTalk サーバーは、その BizTalk サーバー上の Enterprise SSO サービスが再起動されるまで、マスター シークレットのキャッシュされたメモリ内コピーを引き続き使用します。 BizTalk サーバーで Enterprise SSO サービスが再起動された場合、マスター シークレットのキャッシュされたコピーはメモリから解放され、BizTalk サーバーはマスター シークレット サーバーに接続してマスター シークレットの別のコピーを取得できる必要があります。 マスター シークレット サーバーが失敗し、BizTalk サーバーでドキュメントの処理を続行する場合は、グループ内の BizTalk サーバーで Enterprise SSO サービスを再起動しないでください。 |
| MSDTC | サーバー。 MSDTC が失敗した場合、トランザクションのサポートを必要とするサーバー上のコンポーネントは失敗します。 メモ：SQL Serverとマスター シークレット サーバーはトランザクションサポートのために MSDTC に依存しているため、SQL サーバーまたはマスター シークレット サーバー上の MSDTC が失敗した場合、エラーのスコープはシステム全体になります。 BizTalk Serverでは、実行時の操作中にSQL Serverおよびマスター シークレット サーバーと通信する場合、トランザクションのサポートが必要です。 |
| BizTalk ホスト インスタンス | サーバー。 BizTalk ホスト インスタンスに格納されているコンポーネントは、ホスト インスタンスが失敗した場合、ドキュメント処理に参加できません。 |
| Microsoft メッセージ キュー (MSMQ) | サーバー。 MSMQ が失敗した場合、MSMQ アダプターなどの MSMQ サービスに依存するドキュメント処理は、サーバー上で停止されます。 |
| ファイル システム | サーバー。 ファイル システムが失敗した場合、ファイル システムに依存するドキュメント処理 (ファイル アダプターなど) はサーバーで停止されます。 |
高可用性BizTalk Server システムをより適切に管理するには、BizTalk スタック (Windows Server、DC (DNS、DHCP)、BizTalk Server、SQL Server、IIS サーバー、ファイル サーバー、MSMQ サーバー、外部アプリケーションについて十分に理解している必要があります。 このセクションでは、BizTalk Serverと依存SQL Serverコンピューターの高可用性に焦点を当てます。
BizTalk Server High-Availabilityの例
Microsoft BizTalk Server でホストのスケールアウト層を通じて高可用性を提供するサンプル シナリオについては、「サンプル BizTalk Server高可用性シナリオ」を参照してください。
参照
BizTalk ホストの高可用性
データベースの高可用性
マスター シークレット サーバーの高可用性
チェックリスト:ディザスター リカバリーによる可用性の向上