接続形態

このセクションでは、Business Integration Connect とその前提条件ソフトウェアをインストールする前に考慮する必要のある、いくつかの接続形態 (配置構成) について説明します。選択する接続形態は、『環境の計画』で説明した要因にもとづいて選択する必要があります。このセクションで説明する接続形態は、統合接続形態、分割接続形態、および分散接続形態です。

統合接続形態

この接続形態は最も単純なものです。この接続形態は、Business Integration Connect コンポーネントの 3 つ (Receiver、Community Console、Document Manager) のすべてが稼働する単一サーバーで構成されます。このサーバー上に WebSphere MQ および RDBMS を置くこともできます。ただし、これらの製品は、別個の専用サーバーに置く必要があります。

分割接続形態

分割接続形態は、Receiver と Community Console の各コンポーネントを含むフロントエンド・サーバー、および Document Manager コンポーネントを含むバックエンド・サーバーで構成されます。この接続形態は、小規模実稼働環境用の基本レベルの接続形態であり、これを使用すると、ソフトウェア投資の効果を最大化できます。WebSphere MQ および RDBMS は、これらのサーバーを含め、どこにでも置くことができることに注意してください。専用サーバーへの実装が最善の方法です。

分割接続形態 (フロントエンド・サーバーおよびバックエンド・サーバー) では、3 つの Business Integration Connect コンポーネントのすべてのインスタンスは、同一のファイル共用システムによって通信を行う必要があります。大きなボリュームや高可用性を考慮する必要がない場合は、ストレージをバックエンドにホスティングすると安価なソリューションになります。パフォーマンスやセキュリティーを考慮すると、フロントエンドよりもバックエンドの方が好ましい選択です。このソリューションを使用する場合、フロントエンド・サーバーは、NFS 接続または同等のファイル共用ソリューションを使用して、バックエンド・サーバーとファイルを共用できます。

注:
分割接続形態配置のすべてのマシンのシステム時刻は、できるだけ頻繁に同期してください。メッセージを受信するときに Receiver ホスト・マシンで発生するイベントは、受信側マシンからのタイム・スタンプを付けてログに記録されます。同じメッセージの処理に関係するその他のイベントが Document Manager マシンでも発生する可能性があり、これらのイベントは、Document Manager マシンからのタイム・スタンプを付けてログに記録されます。完全な時刻同期は不可能なので、コンソールのログ・レコードを表示する場合に順序付けに明らかな矛盾があっても、このことを認識しておけば理解に苦しまずにすみます。

分散接続形態

大規模インストール・システムに高い拡張性と冗長性をもった環境が必要な場合は、分散接続形態を構築します。この接続形態は、それぞれの Business Integration Connect コンポーネント (Receiver、Community Console、Document Manager) の、1 つ以上の専用サーバーで構成されます。例えば、冗長性のための 2 つの Receiver サーバー、多数の Community Console ユーザーをサポートする 4 つの Community Console サーバー、および文書処理用の 6 つの Document Manager を必要とする環境を構成できます。より高度な文書処理 (Document Manager)、より多くのユーザー (Community Consoles)、より多くの接続 (Receivers) を処理しなければならないコンポーネントでは、必要に応じてサーバーを追加することによってこの接続形態を拡張できます。

分散接続形態では、共用ストレージとして外部 NAS 装置を使用すると、いいソリューションになります。これによって、環境は、他のすべてのサーバーから独立した、ハイパフォーマンスの、冗長性のあるストレージ・デバイスをもつことができます。すべてのサーバーは、外部装置に対して、NFS 接続または同等のファイル共用ソリューションを確立できます。RDBMS および WebSphere MQ は専用サーバーに置く必要があります。また、それらのデータ・ストレージは NAS 装置に置く必要はありません。

最良実例の設計

接続形態を決定したら、次に、冗長性および災害時回復機能を提供する接続形態をどのように実装するかについて考慮する必要があります。ポッドにもとづいて設計することをお勧めします。この設計には、1 次実動ポッドがあります。このポッドには、実動ロードを処理するのに必要な、すべての Business Integration Connect コンポーネントが含まれます。また、2 次実動ポッドがあり、これも実動ロードを処理できます。さらに、これら 2 つを切り替えるロード・バランサーがあります。2 次実動ポッドは冗長性を提供します。図 1は、この 2 つのポッドを実装する方法を示しています。

図 1. ポッドにもとづいた接続形態


実動ロードを処理できる別のポッドを災害時回復サイトに置くことができます。 3 つすべてのポッドのフロントエンド・コンポーネントは、同一でなければなりません。ただし、災害時回復ポッド用のバックエンド・コンポーネントは、実動コンポーネントから分離する必要があります。したがって、別個のデータベース・サーバー、WebSphere MQ サーバー、およびファイル共用システムが必要です。実動コンポーネントと災害時回復バックエンド・コンポーネント間には、ある形式のデータ同期処理を実装する必要があります。Business Integration Connect は、常に、アクティブな実稼働環境を 1 つしかサポートしません。また、統合接続形態などの最小インプリメンテーションの、テスト・ポッドを追加することもできます。

Copyright IBM Corp. 1997, 2004