以下のトピックでは、ロードバランスの設定および初期化と障害処理について説明します。

Info*Engine サービスのロードバランスを設定し、コンポーネントの障害発生時に備えて冗長コンポーネントを設定するには、以下のプロセスを使用できます。

ロードバランスと障害処理のためにこれらの手法のいずれか、または両方をサイトで選択できます。

Info*Engine コンポーネントを検索するために、ネーミングサービスでは LDAP エントリで指定されている LDAP サーチベースでサーチが開始されます。指定された名前を持つサーチベースのすべてのコンポーネントエントリが検索されます。サーチベースに同じ名前のコンポーネントが 1 つ以上ある場合、Info*Engine はリクエストを受けるコンポーネントを無作為に選択します。

Info*Engine コンポーネントを 1 つの場所にインストールし、そのコンポーネントに障害が発生した場合、エラーメッセージが生成され、ユーザーまたは呼び出し側アプリケーションに返されます。コンポーネントに複数のインスタンスをインストールおよび設定し、1 つのコンポーネントに障害が発生した場合、ネーミングサービスは同じコンポーネントの別のインスタンスにリクエストを送ります。

Info*Engine タスクプロセッサ、アダプタ、またはゲートウェイを何回もインストールした後、コンポーネントが同一のサービス名を持つように設定することによって、ロードバランスおよび障害の処理を設定できます。この設定には、Info*Engine プロパティ管理ユーティリティを使用します。共通するサービス名を確立した後、タスクおよび JSP の作成者は、アダプタ Webject の INSTANCE パラメータまたは使用するタスクプロセッサを識別する task タグ属性でこの名前を指定する必要があります。

以下のプロセスを使用して、共通のサービス名を持つようにコンポーネントを設定することができます。

次のセクションでは、ロードバランスおよび障害の処理のメソッド設定の例を挙げます。

冗長コンポーネントに複数のホスト属性およびポート属性を持つ LDAP エントリを作成すると、ロードバランスと障害に迅速に対応できます。このメソッドでは、コンポーネントごとにすべてのコンポーネントプロパティが同一であり、TCP ホストおよびポートの接続を通してコンポーネントにアクセスする必要があります。

このメソッドは以下の状況でうまく機能します。

各コンポーネントに一意の LDAP エントリを作成して、補足的なサービス名として共通のサービス名を追加すると、エントリは LDAP ディレクトリ内の同一ブランチに常駐できるようになります。これにより、冗長コンポーネントのプロパティを柔軟に設定できます。各エントリには一意のサービス名があり、デフォルトではサービス名がサービスの識別を一意にするので、すべてのエントリは同一ブランチに常駐できます。LDAP エントリの作成後に追加される共通のサービス名は、ネーミングサービスがサービスをサーチする際に使用される名前で、サービスの識別名の一部にはなりません。

プロパティが異なっていてもユーザーの環境下で同一機能を提供する Info*Engine タスクプロセッサまたはアダプタのインスタンスが複数ある場合、このメソッドは有効に機能します。

たとえば、タスクプロセッサが 3 つあり、それぞれが異なるホストに常駐し、ホストの許容量が異なるので、各プロセッサの LDAP エントリフォームで Max Thread Count フィールドを同じ数に設定しないと仮定します。この場合、タスクプロセッサの 3 つの LDAP エントリを修正できます。

これらのエントリが、Info*Engine サーバーをそれぞれのホストでインストールした際に作成され、ホストの 1 つからネーミングサービスを実行するように環境を設定したと仮定します。1 回に許容されるリクエストの最大数を指定し、タスクプロセッサの間でロードバランスおよび障害の処理を提供するには、Info*Engine プロパティ管理ユーティリティを通してサービスプロパティを編集します。各サーバーのフォームで、Max Thread Count フィールドに許容されるリクエストの数を入力します。たとえば、以下の表のリストは、3 つのタスクプロセッサの一意のサービス名と各プロセッサの最大スレッドカウントを示しています。

これらのエントリのサービス名は、デフォルトの識別名とランタイムサービス名を使用して、一意のサービスを 3 つ生成します。

各フォームで、既存のサービス名の下のフィールドに共通の名前を入力して「追加」をクリックし、共通のタスクプロセッササービス名も追加します。たとえば、サービス名「com.myCompany.myLocation.infoengineServer.taskProcessor」を追加できます。共通の名前を持つタスクプロセッサに対するリクエストを受けると、ネーミングサービスは共通の名前を持つ 3 つのタスクプロセッサの中から 1 つを無作為に選択します。選択したタスクプロセッサが応答しない場合、ほかのプロセッサが選択されます。

LDAP ディレクトリの一意のブランチに同じサービス名の複数の LDAP エントリがある場合に、コンポーネントのプロパティ設定が最も柔軟になります。このメソッドの使用では、エントリが常駐できる (各サービスの識別名で定義されるように) LDAP サーバーで一意のブランチを設定してあることが前提となります。Info*Engine プロパティ管理ユーティリティはブランチを作成しません。プロパティ管理を開いて LDAP エントリを追加する前に、ブランチが存在している必要があります。必要なブランチは、タスク委任管理ユーティリティの Create Repository オプションを使用して作成できます。

このメソッドが有効に機能するのは、LDAP ディレクトリで複雑なブランチシステムを設定した場合と、複数の Info*Engine 環境がある場合です。一定のコンポーネントへのアクセスを一定の環境に制限できても、ほかの環境ではロードバランスが許容されるからです。

たとえば、それぞれ一意のプロパティを持つ 3 つのデータリポジトリがあり、同一の JDBC アダプタが各リポジトリに 1 回ずつ、3 回インストールされていると仮定します。3 つのアダプタ全部でロードバランスを設定するには、アダプタの LDAP エントリで以下の属性を設定します。

また、各エントリが、データベースにアクセスするためにユーザー名を識別する一意の DBUSER 属性を持っていると仮定します。したがって、各 LDAP エントリでは、サービス名の値は同じ (com.myCompany.JDBC) で、ホスト、ポート、データベースユーザー、および識別名サブツリーの値は一意です。この例では、エントリには一意の ptcRuntimeServiceName 属性があるので、各コンポーネントにはプロパティの一意のセットがあります。

ネーミングサービスが「com.myCompany.JDBC」のインスタンスに対するリクエストを受け、ネーミングサービスサーチベースが LDAP エントリ「dc=myCompany,dc=com」に設定されていると、ネーミングサービスは 3 つすべての JDBC アダプタでロードのバランスをとります。ロードのバランスをとるために、Info*Engine は各照会を受けるアダプタを 3 つの中から無作為に選択します。各アダプタは別々のデータベースに接続します。

タスクおよび JSP の作成者は、ここで説明する障害処理のテクニックを各タスクまたは JSP 内で使用できます。これらのテクニックは、コンポーネントが共通するサービス名を持たない場合にも使用できます。

作成者は、task タグで複数のプロセッサ属性を使用して、指定されたタスクを実行する複数のタスクプロセッサを指定できます。リストの最初のプロセッサが使用不可能な場合、Info*Engine はリストにある次のプロセッサへの接続を試行します。この処理は、接続できるまで、またはすべてのプロセッサが試されるまで、続行します。

task タグの使用方法の詳細については、Info*Engine タグを参照してください。

複数の INSTANCE パラメータ値をアダプタ Webject で使用すると、作成者は指定された Webject を実行する複数のアダプタを指定できます。リストの最初のアダプタが使用不可能な場合、Info*Engine はリストにある次のアダプタへの接続を試行します。この処理は、接続が行われるまで、またはすべてのアダプタが試されるまで続行されます。

Info*Engine では、障害処理の構成に役立つ以下のパラメータも提供します。