受信ホストのスケールアウト
受信機能 (受信場所やパイプラインなど) をつかさどるホストはセキュリティの処理境界として機能し、メッセージのデコードや復号化は、そのホスト内のパイプラインで行われます。 受信ホストの高可用性を確保するためには、それぞれが受信ホストのインスタンスを実行する複数の BizTalk Server コンピューターを用意する必要があります。 受信ホストをスケールアウトすることで、メッセージングを集中的に行うBizTalk Serverデプロイの可用性を保証できます。 こうすることで、受信ホストが実行するオーケストレーション処理を最小限に抑えながら、さまざまなタイプのメッセージを高速かつ高い信頼性でルーティングさせることができます。
オーケストレーション処理やメッセージ送信を行うホストから受信ホストを分離することは、環境のセキュリティとスケーラビリティ強化にもつながります。各ホストのセキュリティやスケーラビリティを他のホストと切り離して捉えることができるためです。 たとえば、処理ホストや送信ホストには一切コンピューターを追加することなく、受信ホストにのみ 2 台のコンピューター (ホスト インスタンス) を追加することもできます。
複数ホストによるメッセージの受信
次の図は、受信ホストのインスタンスを実行している 2 台のコンピューターを使用して、受信ホストの高可用性を提供するBizTalk Server展開を示しています。 この図に示されている処理ホストおよび送信ホストの可用性は高くないことに注意してください。
メッセージ
複数の取引先とやりとりする場合や、異なるプロトコルを使用する場合など、環境の規模が大きい場合は、受信機能を複数の受信ホストに分散させることが可能です。 たとえば、アダプターごとにメッセージ受信用のホストを設けたり、メッセージの受信ホストを取引先ごとに用意することもできます。 複数の受信ホストを設ける際、セキュリティの処理境界を作成することで環境の管理性とスケーラビリティは向上しますが、それによって環境の高可用性が実現するというわけではありません。
環境の高可用性を実現するためには、受信ホストごとに複数のホスト インスタンスを作成する必要があります。 たとえば、3 つの受信ホスト (A、B、C) を用意し、それぞれが異なる会社からのメッセージを受信するように構成したとします。 すべての受信ホストに高可用性を確保するためには、受信ホストごとに複数のホスト インスタンスを作成し、それらを複数のコンピューターに展開する必要があります。 セキュリティの処理境界、管理性、スケーラビリティを損なうことなく、複数のホスト インスタンスを 1 台のコンピューターに割り当てることができるという点に注目してください。
次の図は、会社ごとに専用の受信ホストが用意された BizTalk Server 環境に対し、3 台のコンピューターを使って高可用性を実現した例です。
この構成で高可用性を実現するために、各コンピューターは 3 つのホスト インスタンス (3 つの会社ごとに 1 つのインスタンス) を実行します。 各会社に対応するホスト インスタンスには、その会社と通信するための受信場所およびパイプラインが保持されます。 通常動作中は、受信アダプターのスケールアウトに必要な作業 (たとえば、HTTP 用にネットワーク負荷分散を構成するなど) を終えていれば、メッセージの負荷が各ホストの 3 つのホスト インスタンスに分散されます。 1 つのコンピューターの特定のホスト インスタンスで障害が発生した場合、その他の 2 つのコンピューターで実行されているホスト インスタンスが処理を引き継ぐため、サービスの可用性は維持されます。
BizTalk Server 受信アダプターの拡張
受信ホストをスケールアウトして高可用性を確保するという目的において考慮するべき要素はホスト インスタンスだけではありません。環境に実装されているアダプターにも注目する必要があります。 各アダプターには、プロトコルごとの特性があるため、計画と導入もそれぞれのケースによって異なります。 ただし、BizTalk Serverを使用すると、主に追加のコンピューターとホスト インスタンスを使用して、すべてのアダプターに同じ高可用性ソリューションを適用できます。
受信メッセージを複数のホスト コンピューターに分散して高可用性を確保する際、使用するプロトコルによっては、受信アダプターに追加のメカニズムが必要になる場合もあります。 たとえば、HTTP または SOAP アダプター (Web サービス アダプターとも呼ばれます) を使用するソリューションBizTalk Server、受信ワークロードを分散するには、ネットワーク負荷分散 (NLB) などのロード バランサーが必要です。 次の表は、BizTalk Serverで最も一般的なアダプターの高可用性ガイドラインをまとめたものです。
| アダプター | 高可用性を実現するためのガイドライン |
|---|---|
| HTTP | 受信ホストに複数のコンピューターを追加して NLB を構成し、受信メッセージを複数のホスト コンピューターに分散させます。 |
| SOAP | 受信ホストに複数のコンピューターを追加して NLB を構成し、受信メッセージを複数のホスト コンピューターに分散させます。 |
| ファイル | 受信ホストに複数のコンピューターを追加し、各ホスト コンピューター上で、受信場所として同じファイル フォルダーまたは UNC (汎用名前付け規則) パスが参照されるように構成します。 さらに強固な可用性ソリューションを導入する場合は、UNC パスで指定された場所の可用性を確保します (あるいは信頼性を高める)。 |
| FTP | クラスター化された BizTalk ホストで FTP 受信アダプターを実行するように構成します。 詳細については、「 クラスター化されたホスト内でのアダプター ハンドラーの実行に関する考慮事項」を参照してください。 |
| POP3 | クラスター化された BizTalk ホストで POP3 受信アダプターを実行するように構成します。 詳細については、「 クラスター化されたホスト内でのアダプター ハンドラーの実行に関する考慮事項」を参照してください。 |
| MSMQ | Windows クラスター化 BizTalk ホストで実行するように MSMQ 受信アダプターを構成します。 詳細については、「 クラスター化されたホスト内でのアダプター ハンドラーの実行に関する考慮事項」を参照してください。 MSMQ 受信場所がリモート MSMQ サーバー上のキューを使用している場合は、BizTalk ホストをクラスター化する必要はありません。 このシナリオでは、グループ内の複数の BizTalk コンピューターで MSMQ 受信ホストを実行します。 |
| MQSeries | このアダプターの受信ホストに複数のコンピューターを追加して、MQSeries for Windows のキュー マネージャーをクラスター化し、MQSeries Server for Windows をクラスター化します。 |
| Windows Sharepoint Services | 受信ホストに複数のコンピューターを追加して NLB を構成し、受信メッセージを複数のホスト コンピューターに分散させます。 |
| - WCF-NetTcp - WCF-Custom |
受信ホストに複数のコンピューターを追加して NLB を構成し、受信メッセージをこれらのホスト コンピューターに分散させます。 または アダプター受信ハンドラーによって使用されるホストをクラスター化します。 |
| - WCF-NetNamedPipe - WCF-BasicHttp - WCF-WSHttp - WCF-CustomIsolated |
受信ホストに複数のコンピューターを追加して NLB を構成し、受信メッセージをこれらのホスト コンピューターに分散させます。 |
| WCF-NetMsmq | アダプター受信ハンドラーによって使用されるホストをクラスター化します。 |
HTTP アダプター
BizTalk Serverの HTTP 受信アダプターは、各受信ホスト コンピューターでホスト インスタンスとして実行されるインターネット サーバー API (ISAPI) 拡張機能 (BTSHTTPReceive.dll) です。 パートナーが HTTP プロトコルを通じて BizTalk Server にメッセージを送信すると、そのメッセージは通常、インターネット インフォメーション サービス (IIS) のインストールされた BizTalk Server コンピューターの特定の URL で受信されます。 BizTalk Server には、受信場所でこの URL をサブスクライブするホスト インスタンスを作成することになります。 この URL に到着したメッセージは、BizTalk Server によって取り出され、メッセージ ボックス データベースに格納されます。
BizTalk Serverは、同じ受信ホストの複数のホスト インスタンスを作成できるようにすることで、HTTP 受信アダプターの高可用性を実現します。 これらのホスト インスタンスは、共有可能な特定の URL (NLB を使って受信メッセージを複数の受信ホストに分散させている場合はクラスターの IP アドレス) をサブスクライブします。 これらのホストはすべて、クラスターの仮想 IP アドレスに対してサービスを提供するため、いずれかのクラスター メンバーで障害が発生しても、他のホストがこの IP アドレスに対してサービスを提供できます。
SOAP アダプター (Web サービス アダプター)
HTTP 受信アダプターとは異なり、Web サービスの受信アダプターには ISAPI 拡張は使用されません。 受信メッセージは、BizTalk Web サービス公開ウィザードで指定された URL を通じて取得されます。 このウィザードでは、Web サービスがエクスポートされ、受信場所として機能する仮想ディレクトリが作成されます。
Web サービス アダプターに高い可用性を確保するには、受信ホストに複数のコンピューターを追加して NLB を構成し、受信メッセージを複数のホスト コンピューターに分散させます。 クライアントが Web サービス アダプターを通じて BizTalk Server にメッセージを送信すると、NLB は、そのメッセージを負荷の状況に応じて、いずれかの受信ホストに送信します。さらに、そのホスト上で実行されている適切なホスト インスタンスが、メッセージをメッセージ ボックス データベースに保存します。
ファイル アダプタ
ファイル受信アダプターは、メッセージをファイル フォルダーまたは UNC パスから取得します。 ファイル アダプターが B2B のシナリオで使用されることはあまり多くありません。ファイル アダプターを使用するには、特定のパスに対するアクセス許可を双方が必要としますが、企業がファイル システムを外部と共有することは通常考えられないからです。むしろ、社内で使用されることの多いアダプターです。 受信場所に到着したメッセージを BizTalk Server が取得できるようにファイル受信ハンドラーを構成する (パスをサブスクライブする) 必要があります。
BizTalk Serverは、同じ UNC パスをサブスクライブする複数のホスト コンピューター上にホスト インスタンスを作成できるようにすることで、ファイル受信アダプターの高可用性を実現します。 あるホスト コンピューターで実行されているホスト インスタンスにエラーや障害が発生した場合、別のホスト コンピューターで実行されている同じホスト インスタンスが、メッセージを取得し、メッセージ ボックス データベースに保存します。
FTP アダプタ
FTP 受信アダプターを複数のホストで実行するように構成することはできません。FTP 受信アダプターは、FTP プロトコルを使ってファイルを対象システムから取得します。仮に FTP 受信アダプターの複数のインスタンスを実行しようとした場合、同じファイルの複数のコピーが同時に取得されることのないようにファイルをロックする必要があります。しかし、FTP プロトコルにはファイルをロックするという概念がありません。 FTP 受信アダプターは、クラスター化された BizTalk ホストで実行するように構成する必要があります。 詳細については、「 クラスター化されたホスト内でのアダプター ハンドラーの実行に関する考慮事項」を参照してください。
POP3 アダプタ
POP3 受信アダプターは、データの読み取り先 POP3 サーバーが、同一のメールボックスに対する複数コンカレント接続を許可している場合を除き、複数のホストで実行させることができます。 POP3 アダプターが接続されている POP3 サーバーでメールボックスに対する複数のコンカレント接続が可能な場合、POP3 アダプターの受信ハンドラーを構成してクラスター化された BizTalk ホスト インスタンスで実行することで、POP3 アダプターの高可用性を実現する必要があります。 詳細については、「 クラスター化されたホスト内でのアダプター ハンドラーの実行に関する考慮事項」を参照してください。
MSMQ アダプター
高可用性を実現するには、クラスター化された MSMQ リソースと同じクラスター グループ内にある Windows クラスター化 BizTalk ホストで MSMQ 受信アダプターを実行します。 詳細については、「 クラスター化されたホスト内でのアダプター ハンドラーの実行に関する考慮事項」を参照してください。
MSMQ 受信場所がリモート MSMQ サーバー上の MSMQ キュー からのみ 受信している場合は、BizTalk グループ内の複数の BizTalk コンピューターで MSMQ 受信ホストを実行することで高可用性を実現できます。 MSMQ の高可用性を提供するには、リモート MSMQ サーバーが Windows でフェールオーバー クラスタリングを使用していることを確認する必要があります。 トランザクション キューを使用する場合、リモート MSMQ サーバーは MSMQ 4.0 (Windows Server 2008) 以降を実行している必要があります。
MQSeries アダプタ
Microsoft BizTalk Adapter for MQSeries は、BizTalk Server サーバーと IBM MQSeries サーバー間のブリッジとして機能します。 このアダプターに高可用性ソリューションを適用するには、MQSeries アダプターを実行するホスト インスタンスを複数用意し、MQSeries for Windows のキュー マネージャーをクラスター化し、さらに、MQSeries Server for Windows をクラスター化する必要があります。 キュー マネージャーのクラスタリングおよび MQSeries Server のクラスタリングの詳細については、IBM WebSphere MQ のドキュメントを参照してください。 MQSeries アダプターの高可用性を実現する方法の詳細については、Microsoft BizTalk Adapter for MQSeries のヘルプで「High Availability (高可用性)」を参照してください。
Windows SharePoint Services アダプタ
Windows SharePoint Services アダプターは、SharePoint コンピューターにインストールされた Windows SharePoint Services Web サービスを呼び出すことによって、SharePoint からメッセージを取得します。 このアダプターでは、同じメッセージが異なるホスト インスタンスによって処理されてしまうのを防ぐため、チェックアウト メカニズムが使用されています。 そのため、ホスト インスタンスの追加による受信アダプターのスケールアウトが可能となっています。 BizTalk Serverは、SharePoint NLB のインストールを指す同じ HTTP URL をサブスクライブする複数のホスト インスタンスで同じ受信場所を実行できるようにすることで、SharePoint 受信アダプターの高可用性を実現します。
WCF-NetTcp アダプター
NetTcpBinding では IP レイヤー負荷分散手法を使用して負荷分散できます。 しかし、既定では、NetTcpBinding は接続待ち時間を減らすため、TCP 接続をプールします。 この最適化は、負荷分散の基本的なメカニズムに干渉します。 NetTcpBinding を最適化する主要な構成値は、接続プールの設定の一部であるリース タイムアウトです。 接続プールによって、クライアントの接続がファーム内の特定サーバーと関連付けられます。 このような接続の有効期間 (これはリース タイムアウトの設定で制御される要素です) が長くなるにつれて、ファーム内の各サーバーの負荷分散がうまくいかなくなります。 その結果、平均呼び出し時間が増加します。 したがって、負荷分散シナリオで NetTcpBinding を使用する場合、バインディングで使用されるリース タイムアウトの既定値を小さくすることを検討してください。 負荷分散のシナリオでは、30 秒のリース タイムアウトから始めるのが合理的ですが、最適値はアプリケーションによって異なります。 チャネル リース タイムアウトおよびその他のトランスポート クォータの詳細については、「トランスポート クォータ」を参照してください。