BizTalk Server データベースのスケール アウト
BizTalk Server データベースの高可用性を提供するには、Windows クラスターでSQL Server実行されている 2 台のコンピューターを構成します。 これらのコンピューターは、冗長性のためにアクティブ/アクティブ、アクティブ/パッシブ、またはアクティブ/アクティブ/パッシブ (3 台のコンピューターが必要) 構成で実行でき、共有ドライブ (RAID 1+0 SCSI ディスク アレイなど) または記憶域ネットワーク (SAN) にデータを格納できます。
何らかの理由で SQL Server サービスが使用できなくなった場合、データベース クラスターは、アクティブ側コンピューターからパッシブ側コンピューターにリソースを転送します。 このフェールオーバー処理中に BizTalk Server サービスのインスタンスがデータベース接続の障害を検出すると、自動的にデータベースの再接続が実行されます。 正常に動作しているデータベース コンピューター (先ほどまでパッシブ側であったコンピューター) が、フェールオーバーでリソースを引き継いだ後、データベース接続の処理を開始します。
BizTalk Server データベースのクラスタリングについては、「BizTalk Server データベースのクラスタリング2」を参照してください。 このセクションでは、高可用性を提供するためにBizTalk Server データベースをスケールアウトする方法について説明します。
BizTalk MessageBox データベースの高可用性の提供
このセクションでは、高可用性のために BizTalk MessageBox データベースを構成する方法について説明します。
複数のメッセージ ボックス データベースの実行
BizTalk Server データベースのスケーラビリティを向上させ、MessageBox データベースSQL Serverコンピューター上の高い CPU 使用率に対処するために、複数の MessageBox データベース間でデータを格納するようにBizTalk Serverを構成できます。 最初のメッセージ ボックス データベースは、構成ウィザードの実行時に作成されます。 このメッセージ ボックス データベースは、マスターのメッセージ ボックス データベースです。 個々の BizTalk Server 環境には、マスターのメッセージ ボックス データベースが 1 つ含まれています。 マスターのメッセージ ボックス データベースは、マスターのサブスクリプション情報を含み、メッセージを適切なメッセージ ボックス データベースにルーティングします。 通常は、マスター MessageBox データベースを専用にしてルーティングのみを実行し、他の MessageBox データベースで処理を実行できるようにする必要があります。 メッセージ ボックス データベースでルーティングのみを実行するには、BizTalk 管理コンソールの MessageBox プロパティから [新しいメッセージの発行を無効にする ] を選択します。
MessageBox データベース処理フローの例を次に示します。
マスター MessageBox データベースが新しいアクティブ化メッセージ (ビジネス プロセスまたはサブスクリプション メッセージのまったく新しいインスタンス) を受信すると、マスター MessageBox データベースはアクティブ化メッセージを次に使用可能な MessageBox データベースに配布します。 たとえば、1 つのマスター メッセージ ボックス データベースと 2 つのメッセージ ボックス データベースを使用する場合、マスター メッセージ ボックス データベースは、ラウンドロビン方式で、最初のアクティベーション メッセージをメッセージ ボックス データベース 1 に、2 つ目のアクティベーション メッセージをメッセージ ボックス データベース 2 に、3 つ目のアクティベーション メッセージをメッセージ ボックス データベース 1 に送信します。 マスターのメッセージ ボックス データベースでは、負荷分散のロジックを組み込んでいるので、追加の負荷分散メカニズムは必要ありません。
マスターのメッセージ ボックス データベースがアクティベーション メッセージを特定のメッセージ ボックス データベース (メッセージ ボックス データベース 1 など) に送信してから、ビジネス プロセスがメモリに読み込まれ、実行されます。
ビジネス プロセスがメッセージを待機する必要があり、待機時間が数秒を超える場合、ビジネス プロセスは MessageBox データベース 1 に保持されます。 ビジネス プロセスは、関連付けメッセージを待機しています。
関連付けメッセージがマスター メッセージ ボックス データベースに到着すると、メッセージ エンジンは、関連付けメッセージの状態 (この例では MessageBox 1) を含む MessageBox データベースのデータベースで参照操作を実行します。 マスター MessageBox データベースは、ビジネス プロセスを含む MessageBox データベースにメッセージを配信します。
ビジネス プロセスは、完了するまで、または別の関連付けメッセージを待機する必要があるまで処理を続行するためにメモリに戻されます。
BizTalk Server は、メッセージ ボックス データベースのすべての状態を格納します。各メッセージ ボックス データベースには、異なるビジネス プロセスの状態情報が格納されます。 信頼性を確保するため、マスター メッセージ ボックス データベースおよびセカンダリ メッセージ ボックス データベースを含むすべてのメッセージ ボックス データベースをクラスター化する必要があります。
複数の MessageBox データベースを構成するには、BizTalk Server管理コンソールを使用して、SQL Serverを実行しているコンピューターを追加します。 管理的には、新しいメッセージ ボックス データベースを追加する必要があるだけです。 BizTalk Server では、アクティベーション メッセージのラウンドロビン配信を自動的に処理し、関連メッセージを正しいメッセージ ボックス データベースに送信します。
環境内で複数の MessageBox データベースを構成する場合は、BizTalk Server グループに対して少なくとも 3 つの MessageBox データベースを作成する必要があります。マスター MessageBox データベースでメッセージの公開を無効にする必要があります。 この推奨事項は、MessageBox データベースを追加すると、MessageBox データベース間でメッセージをルーティングするためのマスター MessageBox データベースによってオーバーヘッドが発生するためです。 MessageBox データベースを 2 つだけ構成する場合、追加の MessageBox データベースによって得られる利点のほとんどは、メッセージ ルーティングのためにマスター MessageBox データベースによって消費されるオーバーヘッドによって相殺されます。
重要
BizTalk Server は、メッセージ ボックス データベースのすべての状態を格納します。各メッセージ ボックス データベースには、異なるビジネス プロセスの状態情報が格納されます。 信頼性を確保するため、マスター メッセージ ボックス データベースおよびセカンダリ メッセージ ボックス データベースを含むすべてのメッセージ ボックス データベースをクラスター化する必要があります。
複数のメッセージ ボックス データベースの高可用性を実現する
BizTalk Server 展開に MessageBox データベースを追加するとスケーラビリティが向上しますが、各 MessageBox データベースは一意で独立しており、BizTalk Server環境で単一障害点になる可能性があるため、高可用性は提供されません。 冗長性を拡張するには、各メッセージ ボックス データベースについてサーバー クラスターを構成します。 BizTalk Server により、複数のメッセージ ボックス データベース間でデータが分散されるので、データベース間でデータが共有されることなく、サーバーをクラスター化しないで冗長性を提供できます。
BizTalk 追跡データベースの高可用性を実現する
個々の環境での要件によっては、別の SQL Server コンピューターに BizTalk 追跡データベースを分離し、ホスト追跡用の別の BizTalk ホストを作成することで、追跡のパフォーマンスを向上できる場合もあります。 次の図は、2 つのホスト インスタンスとクラスター化されたデータベースを持つ専用の追跡ホストを示しています。
のスケールアウト
スループットが高く、これらのメッセージのデータを大量に追跡する環境であれば、SQL Server を実行しているコンピューター上にあるリソースの多くを追跡のオーバーヘッドで消費してしまう可能性があります。 このような状況が発生し、受信メッセージのレートが高い場合、メッセージの追跡に必要なリソースが他のBizTalk Server コンポーネントの実行に必要なリソース (メッセージの受信や MessageBox データベースへの永続化など) よりも大きいため、BizTalk Serverは新しいメッセージを処理できない時点に達します。
パフォーマンスとセキュリティを向上させるには、他の項目 (受信場所、オーケストレーション、パイプラインなど) を含まない追跡用にホストを専用にし、受信、処理、および送信ホストからの追跡を無効にすることをお勧めします。 追跡ホストの高可用性を実現するには、追跡ホストの複数のインスタンスを作成します。 「新しいホストを作成する」を参照してください。
MessageBox データベースごとに、BizTalk Serverは 1 つの追跡ホスト インスタンスのみを使用して、メッセージ ボックス データベースから BizTalk Tracking データベース (BizTalkDTADb) にメッセージを移動します。 追加のコンピューターで追跡ホストのインスタンスが実行されると、BizTalk Server は、各メッセージ ボックス データベースの処理を追跡ホストの別のインスタンスに自動的にスケールアウトします。 メッセージ ボックス データベースの数が追跡ホストのインスタンスの数よりも多くなった場合は、1 つまたは複数の追跡ホストのインスタンスが、複数のメッセージ ボックス データベースに対するサービスを提供します。
BizTalk 追跡データベースに高可用性を提供するには、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) にデータを格納できます。