スケールアウト データベース

BizTalk Server データベースの高可用性を提供するには、Windows クラスターでSQL Server実行されている 2 台のコンピューターを構成します。 これらのコンピューターは、アクティブ/アクティブ構成またはアクティブ/パッシブ構成で稼働することにより、冗長性を確保できます。また、共有ドライブ (RAID 1+0 SCSI ディスク アレイなど) やストレージ エリア ネットワーク (SAN) にデータを保存できます。

何らかの理由で SQL Server サービスが使用できなくなった場合、データベース クラスターは、アクティブ側コンピューターからパッシブ側コンピューターにリソースを転送します。 このフェールオーバー処理中に BizTalk Server サービスのインスタンスがデータベース接続の障害を検出すると、自動的にデータベースの再接続が実行されます。 正常に動作しているデータベース コンピューター (先ほどまでパッシブ側であったコンピューター) が、フェールオーバーでリソースを引き継いだ後、データベース接続の処理を開始します。

複数のメッセージ ボックス データベースの実行

BizTalk Server データベースのスケーラビリティを向上させるために、複数の MessageBox データベース間でデータを格納するようにBizTalk Serverを構成できます。 最初のメッセージ ボックス データベースは、構成ウィザードの実行時に作成されます。 このメッセージ ボックス データベースは、マスターのメッセージ ボックス データベースです。 個々の BizTalk Server 環境には、マスターのメッセージ ボックス データベースが 1 つ含まれています。 マスターのメッセージ ボックス データベースは、マスターのサブスクリプション情報を含み、メッセージを適切なメッセージ ボックス データベースにルーティングします。 通常は、マスター MessageBox にルーティングのみを行い ([ 新しいメッセージの発行を無効にする] を選択) 専用にして、他の MessageBox データベースに処理を実行させます。

マスター MessageBox データベースが新しいアクティブ化メッセージ (ビジネス プロセスまたはサブスクリプション メッセージのまったく新しいインスタンス) を受信すると、マスター MessageBox データベースはアクティブ化メッセージを次に使用可能な MessageBox データベースに配布します。 たとえば、1 つのマスター メッセージ ボックス データベースと 2 つのメッセージ ボックス データベースを使用する場合、マスター メッセージ ボックス データベースは、ラウンドロビン方式で、最初のアクティベーション メッセージをメッセージ ボックス データベース 1 に、2 つ目のアクティベーション メッセージをメッセージ ボックス データベース 2 に、3 つ目のアクティベーション メッセージをメッセージ ボックス データベース 1 に送信します。 マスターのメッセージ ボックス データベースでは、負荷分散のロジックを組み込んでいるので、追加の負荷分散メカニズムは必要ありません。

マスターのメッセージ ボックス データベースがアクティベーション メッセージを特定のメッセージ ボックス データベース (メッセージ ボックス データベース 1 など) に送信してから、ビジネス プロセスがメモリに読み込まれ、実行されます。 ビジネス プロセスがメッセージを待機する必要があり、待機時間が数秒を超える場合、ビジネス プロセスは MessageBox データベース 1 に保持されます。 ビジネス プロセスは、関連付けメッセージを待機しています。 マスターのメッセージ ボックス データベースで関連メッセージを受信すると、関連メッセージ (この例では、メッセージ ボックス 1) の状態を格納しているメッセージ ボックス データベースに対し、データベースの参照操作が行われます。 マスターのメッセージ ボックス データベースは、ビジネス プロセスを格納しているメッセージ ボックス データベースにメッセージを送信します。 処理が終了するまでまたは別の関連メッセージが来るまで、ビジネス プロセスがメモリに戻され、処理が続行されます。

BizTalk Server は、メッセージ ボックス データベースのすべての状態を格納します。各メッセージ ボックス データベースには、異なるビジネス プロセスの状態情報が格納されます。 信頼性を確保するため、マスター メッセージ ボックス データベースおよびセカンダリ メッセージ ボックス データベースを含むすべてのメッセージ ボックス データベースをクラスター化する必要があります。

複数のメッセージ ボックス データベースを構成するには、BizTalk 管理コンソールを使用して SQL Server を実行しているコンピューターを追加します。 管理的には、新しいメッセージ ボックス データベースを追加する必要があるだけです。 BizTalk Server では、アクティベーション メッセージのラウンドロビン配信を自動的に処理し、関連メッセージを正しいメッセージ ボックス データベースに送信します。

ユーザー環境で複数のメッセージ ボックス データベースを構成する場合、BizTalk Server グループに少なくとも 3 つのメッセージ ボックス データベースを作成する必要があります。また、マスターのメッセージ ボックス データベース上のメッセージの公開を無効にする必要があります。 この理由は、メッセージ ボックス データベースを追加すると、メッセージ ボックス データベース間でメッセージをルーティングするため、マスター メッセージ ボックス データベースによるオーバーヘッドが発生するためです。 2 つのメッセージ ボックス データベースしか構成していない場合、追加のメッセージ ボックス データベースによって取得されるほとんどの利点は、メッセージのルーティングにおけるマスター メッセージ ボックス データベースのオーバーヘッドで相殺されます。

複数のメッセージ ボックス データベースの高可用性を実現する

BizTalk Server 展開に MessageBox データベースを追加するとスケーラビリティが向上しますが、各 MessageBox データベースは一意で独立しており、BizTalk Server環境で単一障害点になる可能性があるため、高可用性は提供されません。 冗長性を拡張するには、各メッセージ ボックス データベースについてサーバー クラスターを構成します。 BizTalk Server により、複数のメッセージ ボックス データベース間でデータが分散されるので、データベース間でデータが共有されることなく、サーバーをクラスター化しないで冗長性を提供できます。

BizTalk 追跡データベースの高可用性を実現する

個々の環境での要件によっては、別の SQL Server コンピューターに BizTalk 追跡データベースを分離し、ホスト追跡用の別の BizTalk ホストを作成することで、追跡のパフォーマンスを向上できる場合もあります。 スループットが高く、これらのメッセージのデータを大量に追跡する環境であれば、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 プライマリ インポート データベースは、ビジネス アクティビティ監視システムの中心です。 このため、Windows クラスタリングを使用してこのデータベースの高可用性を実現し、次の 2 つの推奨方法に従ってこのデータベースがいっぱいになるのを防ぐことが重要です。 BAM 分析データベースは、ビジネス アナリストがアクティビティの集計や OLAP キューブの構築に使用するデータを格納する Analysis Services データベースです。このため、このデータベースのダウンタイムは、生産性に影響します。 BAM アーカイブ データベースをクラスター化する必要はありませんが、データ変換サービス (DTS) パッケージを実行する際には、イベント ログでエラーを監視することをお勧めします。DTS パッケージでは、データが正常に転送されたことを確認し、データベースがいっぱいになればデータベースを変更できるようにサイズを監視することができます。

• オンライン ウィンドウを定義します。 パフォーマンスを向上させ、ダウンタイムを回避するため、BAM は、アクティビティが完了したときのタイムスタンプに基づいて、BAM プライマリ インポート データベースのデータをテーブルに分割します。 BAM は、完了したテーブルと同一フォーマットの空のテーブルを定期的に交換して、この機能を実現します。 BAM がこの処理を行った後、BAM は、オンライン ウィンドウに定義されている期間、古いパーティションを保存します。また、追加の完了したアクティビティは、新しいパーティション (テーブル) に格納されます。 BAM プライマリ インポート データベースのパーティション数が大きくなりすぎないように、オンライン ウィンドウを定義する必要があります。 オンライン ウィンドウのスケジュール設定の詳細については、BizTalk Server ヘルプの「プライマリ インポート データベース データのアーカイブ」を参照してください。

• 定期的に実行する DTS パッケージのスケジュールを設定します。 オンライン ウィンドウを定義することにより、古いアクティビティのパーティションで BAM プライマリ インポート データベースがいっぱいになる状態を回避できます。 アクティビティ データに対する新しいパーティションを作成し、BAM プライマリ インポート データベースの古いパーティションから BAM アーカイブ データベースにデータを移動するため、定期的に実行する DTS パッケージのスケジュールの設定も行う必要があります。 DTS パッケージのスケジュール設定の詳細については、BizTalk Server ヘルプの「DTS パッケージのスケジュール」を参照してください。

• 慎重に選択してデータ項目 (チェックポイント) のセットを小さくします。アクティビティを定義するときに不要なデータ項目が含まれないようにします。

• 集計を計画したときのスケジュール済みの集計とリアルタイムの集計とのトレードオフを考慮します。 リアルタイムの集計は、SQL Server トリガーによって自動的に保存されます (待機時間ゼロ)。 一部のミッションクリティカルな待機時間の短いシナリオには理想的ですが、イベントが BAM プライマリ インポート データベースに書き込まれている場合に常にパフォーマンス コストが発生します。 スケジュール済みの集計は、スケジュール済みのキューブ DTS パッケージに応じて、集計データを更新します。 待機時間は DTS のスケジュール間隔以上になりますが、総体的には、BAM プライマリ インポート データベースへのパフォーマンスの影響は小さくなります。

• スケジュール済みの集計を選択する場合は、キューブ DTS がアーカイブ DTS よりも頻繁に実行されるようにスケジュール設定を行います。 これは、スケジュール済み集計用に処理されたアクティビティ データは、アーカイブ DTS によって BAM アーカイブ データベースに移動されないからです。

• 複数のコンピューターで BAM イベント バス サービスを有効にし、フェールオーバー機能を取得します。

他の BizTalk Server データベースの高可用性を実現する

他のBizTalk Server データベースに高可用性を提供するには、Windows クラスターでSQL Server実行されている 2 台のコンピューターを構成します。 これらのコンピューターは、アクティブ/アクティブ構成またはアクティブ/パッシブ構成で稼働することにより、冗長性を確保できます。また、共有ドライブ (RAID 1+0 SCSI ディスク アレイなど) やストレージ エリア ネットワーク (SAN) にデータを保存できます。

参照

BizTalk ホストの高可用性
BizTalk Server データベースの高可用性を実現する
BizTalk Server の高可用性を実現するサンプル シナリオ