BizTalk ホストの高可用性

  • [アーティクル]

BizTalk Serverは、メッセージの受信、メッセージの送信、オーケストレーションの処理など、特定の機能領域を実行するために論理ホストを戦略的に専用化できるため、高可用性に対応するための優れた柔軟性を提供します。

BizTalk ホストとは、BizTalk Server グループ内の論理的なコンテナーです。アダプター ハンドラー、受信場所 (パイプラインを含む)、オーケストレーションなど、BizTalk Server の各種アイテムが、このコンテナー内でホストされます。 通常は、拡張性の観点から似た要件を持つアイテムを特定のホストにグループ化します。 たとえば、受信場所を "受信" ホストに、送信ポートを "送信" ホストに、オーケストレーションを "処理" ホストにグループ化します。

ホスト (論理コンテナー) を作成したら、BizTalk Server グループ内の物理BizTalk Server コンピューターで実行するようにホストのインスタンスを構成できます。 ホスト インスタンスは、指定されたBizTalk Server コンピューター上で Windows サービスとして実行されます。 特定のBizTalk Server コンピューターで同じホストの複数のインスタンスを実行することはできませんが、BizTalk Server グループ内の別のBizTalk Server コンピューターでホストのインスタンスを構成することで、特定のホストの複数のインスタンスを実行できます。 1 台のBizTalk Server コンピューターで異なるホストの複数のインスタンスを実行することもできます。

BizTalk ホストに格納されたアイテムは、次のような役割を果たします。

  • 受信 これらのアイテムは、受信場所でメッセージが取得された後に、メッセージの初期処理を行います。 受信機能 (受信場所やパイプラインなど) をつかさどるホストはセキュリティの処理境界として機能し、メッセージのデコードや復号化は、そのホスト内のパイプラインで行われます。

  • 送信 これらの項目は、送信ポートに送信される前に、メッセージの最終処理を行います。 送信機能 (送信ポートやパイプラインなど) をつかさどるホストはセキュリティの処理境界として機能し、メッセージの署名や暗号化は、そのホスト内のパイプラインで行われます。

  • 処理 これらの項目は、オーケストレーションの指示に基づいてメッセージを処理します。

    1 つの BizTalk ホストにメッセージの受信、送信、処理を行うアイテムを入れることができますが、セキュリティの処理境界を設け、管理と拡張を容易にするためには、機能ごとに異なるホストを作成することをお勧めします。 特に、処理と受信/送信操作には異なるホストを使用し、信頼されたアイテムと信頼されていないアイテムを分離することをお勧めします。

    たとえば、1 つのメッセージを受け取って、オーケストレーションを実行し、10 個のメッセージを送信する場合、送信には受信と比べて 10 倍のトラフィックが発生するため、受信機能と送信機能は 2 つのホストに分ける必要があります。 1 つのメッセージを受信し、オーケストレーションを実行して、1 つのメッセージを送信する場合は、3 つの機能を 1 つの作業単位と捉え、単一のホストとしてグループ化することができます。 また、3 つの機能を別々のホストに分ければ、パフォーマンスと柔軟性を高めることができます。

    BizTalk ホストは、 インプロセス または 分離の 2 種類のいずれかです。 インプロセス ホストはBizTalk Serverランタイム プロセス内で実行されますが、分離ホストはBizTalk Serverランタイム プロセスでは実行されません。 次の表は、2 種類のホストに割り当てることのできる機能をまとめたものです。

ホストの種類 論理コンテナーに割り当てることのできる機能
In-Process -オーケストレーション
- アダプター送信ハンドラー
- HTTP および SOAP 以外のアダプター受信ハンドラー
Isolated HTTP および SOAP の受信ハンドラー

ホストとホスト インスタンスの詳細については、「 BizTalk ホストとホスト インスタンスの管理」を参照してください。

BizTalk ホストの高可用性を提供するには、環境内のホストごとに 2 つ以上のホスト インスタンスが必要です (2 つ以上のBizTalk Server コンピューター上)。 各ホストに複数のホスト インスタンスを割り当てることで、1 つのホスト インスタンスで障害が発生しても、そのホストのインスタンスを実行する別のコンピューターが、問題や障害の発生したホスト インスタンスの機能を引き継ぐため、システム全体としては大きな混乱を招くことなく処理を続行できます。

メッセージの永続性

BizTalk Serverは、BizTalk Serverに関係するすべてのホストが BizTalk MessageBox データベースにメッセージを保持するため、高可用性のためにSQL Serverに大きく依存しています。 たとえば、BizTalk Serverが受信メッセージを受信すると、受信ホストは、他のホストがオーケストレーションの処理と送信のためにメッセージを取得する前に、メッセージ ボックス データベースに保持します。

BizTalk Server ソリューションにオーケストレーションを使用している場合、メッセージは、ビジネス プロセスを実行するホスト (処理ホスト) にルーティングされ、オーケストレーションが実行された後で、メッセージ ボックス データベースに保存されます。 その後、送信ホストが、そのメッセージをメッセージ ボックス データベースから取り出し、適切な送信アダプターを使って外部のアプリケーションに送信します。

ホスト機能とデータベース機能の分離

BizTalk Serverはデータを処理するホストからデータを分離するため、高可用性環境を作成するために実行できる 1 つの手順は、BizTalk Serverで発生するホスト関数 (送受信、処理) と、SQL Serverで発生するデータベース関数を分離することです。 これらの機能を分離することにより、処理、送信、受信の各ホストと、データを保存するデータベースとを別々に拡張することができます。 ランタイムとデータベースレイヤーは関連しています。つまり、BizTalk Serverコンピューターの数を増やす場合は、追加の負荷を処理するためにSQL Server実行しているコンピューターの数を増やす必要があります。 ただし、データベース層と BizTalk 層に直接的な関係はありません。 両者はそれぞれ独立した層であり、別々に拡張することが可能です。

ホストとデータベースでは、高可用性を確保するための作業も異なります。 次のセクションでは、受信、送信、処理の各ホストに高可用性を実現するための作業について説明します。 データベース 層を高可用性にする方法の詳細については、「BizTalk Server データベースの高可用性の提供」を参照してください。

BizTalk Server にかかる処理の負荷が SQL Server よりも大きい環境では、複数の BizTalk Server コンピューターで、同じ SQL Server コンピューターを使用するように構成できます。 つまり、コンピューター間のリソースの不均衡をなくすように構成します。 たとえば、CPU またはメモリの使用率を比較した結果、BizTalk Server コンピューターのリソース使用率が高く (75% 以上)、SQL Server コンピューターのリソース使用率が低い (25% 未満) 場合、別の BizTalk Server コンピューターを追加することにより、SQL Server コンピューターのリソース使用率を引き上げる形で、処理の負荷を分散させることが可能です。

このセクションの内容

参照

BizTalk Server データベースの高可用性を実現する
Enterprise Single Sign-On の高可用性