BizTalk Server データベースの高可用性を実現するには、Windows クラスターで SQL Server を実行している 2 台のコンピューターを構成します。 これらのコンピューターは、冗長性を確保するために、アクティブ/アクティブ/パッシブ、アクティブ/パッシブ、アクティブ/アクティブ/パッシブ (3 台のコンピューターが必要) 構成で実行でき、共有ドライブ (RAID 1+0 SCSI ディスク アレイなど) または記憶域ネットワーク (SAN) にデータを格納できます。
何らかの理由で SQL Server サービスが使用できなくなった場合、データベース クラスターはアクティブなコンピューターからパッシブ コンピューターにリソースを転送します。 このフェールオーバー プロセス中に、BizTalk Server サービス インスタンスでデータベース接続エラーが発生し、自動的に再起動してデータベースに再接続します。 機能しているデータベース コンピューター (以前はパッシブ コンピューター) は、フェールオーバー中にリソースを想定した後、データベース接続の処理を開始します。
BizTalk Server データベースのクラスタリングについては、「 BizTalk Server Databases2 のクラスタリング」を参照してください。 このセクションでは、高可用性を提供するために BizTalk Server データベースをスケールアウトすることに重点を置いています。
BizTalk MessageBox データベースの高可用性の提供
このセクションでは、高可用性のために BizTalk MessageBox データベースを構成する方法について説明します。
複数のメッセージ ボックス データベースの実行
BizTalk Server データベースのスケーラビリティを強化し、メッセージ ボックス データベースの SQL Server コンピューターでの高い CPU 使用率に対処するために、複数の MessageBox データベースにデータを格納するように BizTalk Server を構成できます。 構成ウィザードを実行するときに、最初の MessageBox データベースを作成します。 このメッセージ ボックス データベースは、マスター メッセージ ボックス データベースです。 BizTalk Server 展開には、単一のマスター メッセージ ボックス データベースがあります。 マスター メッセージ ボックス データベースには、マスター サブスクリプション情報が含まれており、メッセージを適切な MessageBox データベースにルーティングします。 通常は、マスター MessageBox データベースをルーティングのみを実行し、他の MessageBox データベースに処理を実行させる必要があります。 メッセージ ボックス データベースでルーティングのみを実行するには、BizTalk 管理コンソールの MessageBox プロパティから [ 新しいメッセージの発行を無効にする ] を選択します。
MessageBox データベース処理フローの例を次に示します。
マスター メッセージ ボックス データベースが新しいアクティブ化メッセージ (ビジネス プロセスまたはサブスクリプション メッセージのまったく新しいインスタンス) を受信すると、master MessageBox データベースはアクティブ化メッセージを次に使用可能な MessageBox データベースに配布します。 たとえば、1 つのマスター メッセージ ボックス データベースと 2 つの MessageBox データベースがある場合、マスター メッセージ ボックス データベースは、最初のアクティブ化メッセージを MessageBox データベース 1 に、2 番目のアクティブ化メッセージを MessageBox データベース 2 に、3 番目のアクティブ化メッセージを MessageBox データベース 1 にルーティングします。ラウンドロビン パターンでルーティングされます。 マスター メッセージ ボックス データベースでは、組み込みのロジックを使用して負荷分散が行われ、追加の負荷分散メカニズムは必要ありません。
マスター メッセージ ボックス データベースがアクティブ化メッセージを特定の MessageBox データベース (たとえば、MessageBox データベース 1) にルーティングした後、ビジネス プロセスはメモリに入り、実行されます。
ビジネス プロセスがメッセージを待機する必要があり、待機時間が数秒より長い場合、ビジネス プロセスは MessageBox データベース 1 に保持されます。 ビジネス プロセスは、関連付けメッセージを待機しています。
関連付けメッセージがマスター メッセージ ボックス データベースに到着すると、メッセージ エンジンは、関連付けメッセージの状態 (この例では MessageBox 1) を含む MessageBox データベースのデータベースで参照操作を実行します。 マスター メッセージ ボックス データベースは、ビジネス プロセスを含むメッセージ ボックス データベースにメッセージを配信します。
ビジネス プロセスは、完了するまで、または別の関連付けメッセージを待機する必要があるまで、処理を続行するためにメモリに戻されます。
BizTalk Server では、すべての状態がメッセージ ボックス データベースに格納され、各メッセージ ボックス データベースにはさまざまなビジネス プロセスの状態情報が含まれています。 信頼性を確保するには、マスター データベースとセカンダリ メッセージ ボックス データベースを含むすべての MessageBox データベースをクラスター化する必要があります。
複数のメッセージ ボックス データベースを構成するには、BizTalk Server 管理コンソールを使用して、SQL Server を実行しているコンピューターを追加します。 管理の観点からは、新しい MessageBox データベースを追加するだけで済みます。 BizTalk Server は、アクティブ化メッセージのラウンド ロビン分散を自動的に処理し、正しい MessageBox データベースに関連付けメッセージを送信します。
環境内で複数の MessageBox データベースを構成する場合は、BizTalk Server グループ用に少なくとも 3 つの MessageBox データベースを作成する必要があります。マスター メッセージ ボックス データベースでメッセージの発行を無効にする必要があります。 この推奨事項は、メッセージ ボックス データベースを追加すると、メッセージ ボックス データベース間でメッセージをルーティングするためのマスター メッセージ ボックス データベースによってオーバーヘッドが発生するためです。 2 つの MessageBox データベースのみを構成する場合、追加の MessageBox データベースによって得られる利点のほとんどは、メッセージ ルーティングのためにマスター MessageBox データベースによって消費されるオーバーヘッドによってオフセットされます。
Von Bedeutung
BizTalk Server では、すべての状態がメッセージ ボックス データベースに格納され、各メッセージ ボックス データベースにはさまざまなビジネス プロセスの状態情報が含まれています。 信頼性を確保するには、マスター データベースとセカンダリ メッセージ ボックス データベースを含むすべての MessageBox データベースをクラスター化する必要があります。
複数のメッセージ ボックス データベースの高可用性を提供する
BizTalk Server 展開に MessageBox データベースを追加するとスケーラビリティは向上しますが、各 MessageBox データベースは一意で独立しており、BizTalk Server 環境の単一障害点である可能性があるため、高可用性は提供されません。 冗長性を追加するには、メッセージ ボックス データベースごとにサーバー クラスターを構成する必要があります。 BizTalk Server は複数のメッセージ ボックス データベースにデータを分散するため、データベースはデータを共有したり、サーバー クラスタリングなしで冗長性を提供したりしません。
BizTalk 追跡データベースの高可用性の提供
特定の展開の要件に応じて、BizTalk 追跡データベースを別の SQL Server コンピューターに分離し、ホスト追跡専用の別の BizTalk ホストを作成することで、追跡のパフォーマンスを向上させることができます。 次の図は、2 つのホスト インスタンスとクラスター化されたデータベースを持つ専用の追跡ホストを示しています。
のスケールアウト
デプロイのスループットが高く、これらのメッセージの多くのデータを追跡する必要がある場合、追跡オーバーヘッドによって、SQL Server を実行しているコンピューター上で大量のリソースが消費される可能性があります。 このような状況が発生し、受信メッセージのレートが高い場合、BizTalk Server は、メッセージを追跡するために必要なリソースが、他の BizTalk Server コンポーネントの実行に必要なリソース (メッセージの受信やメッセージ ボックス データベースへの保存など) よりも大きいため、新しいメッセージを処理できない時点に達します。
パフォーマンスとセキュリティを向上させるために、他の項目 (受信場所、オーケストレーション、パイプラインなど) を含まない追跡用にホストを専用にし、受信、処理、および送信ホストからの追跡を無効にすることをお勧めします。 追跡ホストの高可用性を提供するには、追跡ホストの複数のホスト インスタンスを作成します。 「新しいホストの作成」を参照してください。
メッセージ ボックス データベースごとに、BizTalk Server は、メッセージ ボックス データベースから BizTalk Tracking データベース (BizTalkDTADb) にメッセージを移動するために、追跡ホスト インスタンスを 1 つだけ使用します。 追加のコンピューターで追跡ホストのインスタンスが実行される場合、BizTalk Server は各 MessageBox データベースの処理を追跡ホストの個別のインスタンスに自動的にスケールアウトします。 MessageBox データベースの数が追跡ホスト インスタンスの数より多い場合、1 つ以上の追跡ホスト インスタンスが複数の MessageBox データベースにサービスを提供します。
BizTalk Tracking データベースの高可用性を実現するには、Windows クラスタリングを使用して、アクティブ/パッシブ構成で SQL Server を実行している 2 つのデータベース コンピューターを構成します。
BAM データベースの高可用性の提供
ビジネス アクティビティ監視 (BAM) を使用すると、IT 実装に関係なく、または異種の IT 実装全体でビジネス プロセスを可視化できます。 BAM SQL Server データベース (BAM スター スキーマ データベース、BAM プライマリ インポート データベース、BAM アーカイブ データベース) と BAM 分析データベースには、運用監視データとは異なるビジネス アクティビティ データが格納されます。 次の図は、BAM データベース インフラストラクチャを示しています。
BAM インフラストラクチャが高可用性であることを確認するには、次の手順を実行します。
BAM プライマリ インポート データベースと BAM 分析データベースをクラスター化します。 BAM プライマリ インポート データベースは、ビジネス アクティビティ監視システムの中心です。 そのため、Windows クラスタリングを使用してこのデータベースを高可用性にし、次の 2 つの推奨事項に従ってこのデータベースがいっぱいにならないようにすることが重要です。 BAM 分析データベースは、ビジネス アナリストがアクティビティ集計と OLAP キューブの構築に使用するデータを格納する Analysis Services データベースです。そのため、このデータベースのダウンタイムは生産性に影響します。 BAM アーカイブ データベースをクラスター化する必要はありませんが、SQL Server Integration Services (SSIS) パッケージの実行時にエラーが発生していないかイベント ログを監視して、データが正常に転送されたことを確認し、データベースのサイズを監視して、いっぱいになる前に置き換えることをお勧めします。
オンライン ウィンドウを定義します。 パフォーマンスを向上させ、ダウンタイムを回避するために、BAM は、アクティビティが完了したときのタイムスタンプに基づいて、BAM プライマリ インポート データベース内のデータをテーブルにパーティション分割します。 BAM は、完了したテーブルを同じ形式の別の空のテーブルと定期的にスワップすることでこれを実現します。 BAM がこれを行った後、追加の完了したアクティビティは新しいパーティション (テーブル) に移動し、BAM はオンライン ウィンドウで定義された時間の古いパーティションを保持します。 BAM プライマリ インポート データベース内のパーティションの数が大きくなりすぎないように、オンライン ウィンドウを定義する必要があります。 オンライン ウィンドウのスケジュール設定の詳細については、「 プライマリ インポート データベース データのアーカイブ」を参照してください。
SSIS パッケージを定期的に実行するようにスケジュールします。 オンライン ウィンドウを定義すると、BAM プライマリ インポート データベースに古いアクティビティ パーティションがいっぱいにならないことを確認できます。 また、アクティビティ データの新しいパーティションを作成し、BAM プライマリ インポート データベースの古いパーティションから BAM アーカイブ データベースにデータを移動するために、SSIS パッケージを定期的に実行するようにスケジュールする必要があります。 SSIS パッケージのスケジュール設定の詳細については、「 SQL Server Integration Services パッケージのスケジュール設定」を参照してください。
少数のデータ項目 (チェックポイント) を慎重に選択し、アクティビティを定義するときに不要なデータ項目を含めないようにします。
集計を設計するときに、スケジュールされた集計とリアルタイム集計の間のトレードオフについて理解します。 リアルタイム集計は SQL Server トリガーによって自動的に維持され、待機時間はゼロになります。 これらは、ミッション クリティカルな低待機時間のシナリオに最適ですが、イベントが BAM プライマリ インポート データベースに書き込まれるたびにパフォーマンス コストが発生します。 スケジュールされた集計は、スケジュールされたキューディング SSIS パッケージに依存して集計データを更新します。 待機時間は SSIS スケジュール間隔以上ですが、全体的に BAM プライマリ インポート データベースへのパフォーマンスへの影響は小さくなります。
スケジュールされた集計を選択する場合は、アーカイブ SSIS よりも頻繁に実行されるように、キューディング SSIS をスケジュールしてください。 これは、スケジュールされた集計に対して処理されたアクティビティ データが、アーカイブ SSIS によって BAM アーカイブ データベースに移動されないためです。
複数のコンピューターで BAM Event Bus サービスを有効にして、フェールオーバー機能を取得します。
他の BizTalk Server データベースの高可用性の提供
他の BizTalk Server データベースに高可用性を提供するには、Windows クラスターで SQL Server を実行している 2 台のコンピューターを構成します。 これらのコンピューターは、冗長性を確保するためにアクティブ/アクティブ/アクティブ/パッシブ構成で実行でき、共有ドライブ (RAID 1+0 SCSI ディスク アレイなど) または記憶域ネットワーク (SAN) にデータを格納できます。