ロードバランスと障害のための設定
以下のトピックでは、ロードバランスの設定および初期化と障害処理について説明します。
ロードバランスについて
Info*Engine サービスのロードバランスを設定し、コンポーネントの障害発生時に備えて冗長コンポーネントを設定するには、以下のプロセスを使用できます。
• コンポーネントの複数のインスタンスを設定し、LDAP エントリが共通のサービス名を持つように設定することによって、一部のコンポーネントをシステム全体にわたってロードバランスと障害に備えて設定できます。設定できるコンポーネントは、Info*Engine タスクプロセッサ、アダプタ、またはゲートウェイです。この設定には、Info*Engine プロパティ管理ユーティリティを使用します。
• タスクおよび JSP の作成者は、各タスクまたは JSP 内で障害処理のテクニックを使用できます。これらのテクニックは、コンポーネントが共通するサービス名を持たない場合にも使用できます。作成者は、処理されている特定のタスクまたはアダプタ Webject で複数のコンポーネントを指定できます。作成者は、CONNECTION_ATTEMPTS および CONNECTION_ATTEMPTS_INTERVAL Webject のパラメータを使用して、リクエストの再送頻度およびこれらのリクエストの間隔について制限することもできます。
ロードバランスと障害処理のためにこれらの手法のいずれか、または両方をサイトで選択できます。
 |
ネーミングサービスのインスタンスは重複させないでください。ネーミングサービス LDAP ディレクトリのエントリの複製を作成し共通する名前を付けると、予測できない結果が発生する場合があります。
複数のメソッドサーバーがある Windchill 環境の場合、Windchill アダプタを手動で設定しないでください。Windchill アダプタの自動登録により、アダプタ設定がすべてのフォアグラウンドメソッドサーバーに対応するポート範囲を使用するように更新されることで、必要に応じて複数のメソッドサーバー環境で適切に機能するようにサービス設定が自動更新されます。
|
システム全体のロードバランスおよび障害処理
Info*Engine コンポーネントを検索するために、ネーミングサービスでは LDAP エントリで指定されている LDAP サーチベースでサーチが開始されます。指定された名前を持つサーチベースのすべてのコンポーネントエントリが検索されます。サーチベースに同じ名前のコンポーネントが 1 つ以上ある場合、Info*Engine はリクエストを受けるコンポーネントを無作為に選択します。
Info*Engine コンポーネントを 1 つの場所にインストールし、そのコンポーネントに障害が発生した場合、エラーメッセージが生成され、ユーザーまたは呼び出し側アプリケーションに返されます。コンポーネントに複数のインスタンスをインストールおよび設定し、1 つのコンポーネントに障害が発生した場合、ネーミングサービスは同じコンポーネントの別のインスタンスにリクエストを送ります。
Info*Engine タスクプロセッサ、アダプタ、またはゲートウェイを何回もインストールした後、コンポーネントが同一のサービス名を持つように設定することによって、ロードバランスおよび障害の処理を設定できます。この設定には、Info*Engine プロパティ管理ユーティリティを使用します。共通するサービス名を確立した後、タスクおよび JSP の作成者は、アダプタ Webject の INSTANCE パラメータまたは使用するタスクプロセッサを識別する task タグ属性でこの名前を指定する必要があります。
以下のプロセスを使用して、共通のサービス名を持つようにコンポーネントを設定することができます。
• すべての冗長コンポーネントに LDAP エントリを作成します。このエントリでは、複数のホストおよびポートの属性を指定することを除けば、コンポーネントのすべての情報は同じです。ホストとポートの各ペアはコンポーネントの 1 つに必要なホストとポートに一致します。1 つのホストで複数のインスタンスを実行するには、1 つのポート番号ではなくポート範囲を指定し、下のポート番号と上のポート番号をダッシュで区切ります (例: 1001-1005)。
• 各コンポーネントに一意のサービス名を使用して、各コンポーネントの LDAP エントリを作成します。各 LDAP エントリを編集して、補足的なサービス名として共通のサービス名を追加します。タスクおよび JSP の作成者に、コンポーネントにアクセスする際に、この共通のサービス名を使用するように伝えます。
• ディレクトリ内の一意のブランチに各コンポーネントの LDAP エントリを作成し、同一のサービス名を使用します。ただし、ランタイムサービス名は、各コンポーネント固有の名前にします。
|
|
同一の名前を持つ複数のアダプタコンポーネントを設定し、アダプタの 1 つがプロセス内で動作する場合、ネーミングサービスは常にプロセス内アダプタを選択します。この場合、ロードバランスは行われません。ただし、プロセス内アダプタのクラスへのアクセスにエラーが生じた場合、プロセス外アダプタへの接続が試行されます。
|
次のセクションでは、ロードバランスおよび障害の処理のメソッド設定の例を挙げます。
複数のコンポーネントに対する 1 つの LDAP エントリの使用
冗長コンポーネントに複数のホスト属性およびポート属性を持つ LDAP エントリを作成すると、ロードバランスと障害に迅速に対応できます。このメソッドでは、コンポーネントごとにすべてのコンポーネントプロパティが同一であり、TCP ホストおよびポートの接続を通してコンポーネントにアクセスする必要があります。
このメソッドは以下の状況でうまく機能します。
• 同一のデータレポジトリに接続する冗長プロセス外アダプタがある。
• 複数のタスクプロセッサがあり、ホストとポートを除いて、それぞれが同じプロパティを持つ。
たとえば、同じデータベースにアクセスするようにすべて同じように設定された 3 つの異なるホストに、3 つの JDBC アダプタを設定してあると仮定します。これに該当する場合、アダプタにアクセスするときに使用するホストとポートを除いて、アダプタのプロパティは同じになる可能性があります。3 つのアダプタすべてにわたってロードバランスを設定するには、アダプタの LDAP エントリの 1 つで以下の属性を設定します。
|
サービス名
|
ホスト
|
ポート
|
|---|---|---|
|
com.myCompany.JDBC
|
oradb1.co.com
|
10003
|
|
oradb2.co.com
|
10004
|
|
|
oradb3.co.com
|
10005
|
|
|
複数のメソッドサーバーがある Windchill 環境の場合、複数の Windchill アダプタに対して 1 つの LDAP エントリを使用しないでください。Windchill アダプタの自動登録は、必要に応じてサービス定義を自動的に作成および除去します。アダプタ設定を別々に行うことは、分散トランザクション処理中に適切なセッションアフィニティを保持するのに必要です。
|
LDAP エントリの編集による共通のサービス名の追加
各コンポーネントに一意の LDAP エントリを作成して、補足的なサービス名として共通のサービス名を追加すると、エントリは LDAP ディレクトリ内の同一ブランチに常駐できるようになります。これにより、冗長コンポーネントのプロパティを柔軟に設定できます。各エントリには一意のサービス名があり、デフォルトではサービス名がサービスの識別を一意にするので、すべてのエントリは同一ブランチに常駐できます。LDAP エントリの作成後に追加される共通のサービス名は、ネーミングサービスがサービスをサーチする際に使用される名前で、サービスの識別名の一部にはなりません。
プロパティが異なっていてもユーザーの環境下で同一機能を提供する Info*Engine タスクプロセッサまたはアダプタのインスタンスが複数ある場合、このメソッドは有効に機能します。
たとえば、タスクプロセッサが 3 つあり、それぞれが異なるホストに常駐し、ホストの許容量が異なるので、各プロセッサの LDAP エントリフォームで Max Thread Count フィールドを同じ数に設定しないと仮定します。この場合、タスクプロセッサの 3 つの LDAP エントリを修正できます。
これらのエントリが、Info*Engine サーバーをそれぞれのホストでインストールした際に作成され、ホストの 1 つからネーミングサービスを実行するように環境を設定したと仮定します。1 回に許容されるリクエストの最大数を指定し、タスクプロセッサの間でロードバランスおよび障害の処理を提供するには、Info*Engine プロパティ管理ユーティリティを通してサービスプロパティを編集します。各サーバーのフォームで、Max Thread Count フィールドに許容されるリクエストの数を入力します。たとえば、以下の表のリストは、3 つのタスクプロセッサの一意のサービス名と各プロセッサの最大スレッドカウントを示しています。
|
サービス名
|
ホスト
|
ポート
|
最大スレッド数
|
|---|---|---|---|
|
com.myCompany.myLocation.aHost.server.taskProcessor
|
aHost
|
10003
|
60
|
|
com.myCompany.myLocation.bHost.server.taskProcessor
|
bHost
|
10004
|
200
|
|
com.myCompany.myLocation.cHost.server.taskProcessor
|
cHost
|
10005
|
80
|
これらのエントリのサービス名は、デフォルトの識別名とランタイムサービス名を使用して、一意のサービスを 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 エントリで以下の属性を設定します。
|
サービス名
|
ホスト
|
ポート
|
DN サブツリー値
|
|---|---|---|---|
|
com.myCompany.JDBC
|
oradb1.co.com
|
10003
|
dc=aHost,dc=myCompany,dc=com
|
|
com.myCompany.JDBC
|
oradb2.co.com
|
10004
|
dc=bHost,dc=myCompany,dc=com
|
|
com.myCompany.JDBC
|
oradb3.co.com
|
10005
|
dc=cHost,dc=myCompany,dc=com
|
また、各エントリが、データベースにアクセスするためにユーザー名を識別する一意の DBUSER 属性を持っていると仮定します。したがって、各 LDAP エントリでは、サービス名の値は同じ (com.myCompany.JDBC) で、ホスト、ポート、データベースユーザー、および識別名サブツリーの値は一意です。この例では、エントリには一意の ptcRuntimeServiceName 属性があるので、各コンポーネントにはプロパティの一意のセットがあります。
ネーミングサービスが「com.myCompany.JDBC」のインスタンスに対するリクエストを受け、ネーミングサービスサーチベースが LDAP エントリ「dc=myCompany,dc=com」に設定されていると、ネーミングサービスは 3 つすべての JDBC アダプタでロードのバランスをとります。ロードのバランスをとるために、Info*Engine は各照会を受けるアダプタを 3 つの中から無作為に選択します。各アダプタは別々のデータベースに接続します。
特定のタスクと Webject におけるサービス障害処理
タスクおよび JSP の作成者は、ここで説明する障害処理のテクニックを各タスクまたは JSP 内で使用できます。これらのテクニックは、コンポーネントが共通するサービス名を持たない場合にも使用できます。
タスクのサービス障害
作成者は、task タグで複数のプロセッサ属性を使用して、指定されたタスクを実行する複数のタスクプロセッサを指定できます。リストの最初のプロセッサが使用不可能な場合、Info*Engine はリストにある次のプロセッサへの接続を試行します。この処理は、接続できるまで、またはすべてのプロセッサが試されるまで、続行します。
|
|
task タグのプロセッサ属性でネーミングされたプロセッサをサーチする際に、ネーミングサービスは指定された名前を持つ複数のプロセッサを識別し、使用するプロセッサを無作為に選択します。ネーミングサービスは、共通の名前を持つすべてのプロセッサを試すまで、リスト内のほかのプロセッサに進みません。詳細については、セクション「システム全体のロードバランスおよび障害処理」を参照してください。
|
task タグの使用方法の詳細については、Info*Engine タグを参照してください。
アダプタ Webject のサービス障害
複数の INSTANCE パラメータ値をアダプタ Webject で使用すると、作成者は指定された Webject を実行する複数のアダプタを指定できます。リストの最初のアダプタが使用不可能な場合、Info*Engine はリストにある次のアダプタへの接続を試行します。この処理は、接続が行われるまで、またはすべてのアダプタが試されるまで続行されます。
|
|
Webject INSTANCE パラメータでネーミングされたアダプタをサーチする際に、ネーミングサービスは指定された名前を持つ複数のアダプタを識別し、使用するアダプタを無作為に選択します。ネーミングサービスは、共通の名前を持つすべてのアダプタを試すまで、リスト内のほかのアダプタに進みません。詳細については、セクション「システム全体のロードバランスおよび障害処理」を参照してください。
|
Info*Engine では、障害処理の構成に役立つ以下のパラメータも提供します。
CONNECTION_ATTEMPTS
エラーを返す前にアダプタの接続の確立を試行する最大回数を定義します。複数の INSTANCE パラメータ値を指定する場合、CONNECTION_ATTEMPTS の値は、アダプタインスタンスのリストを繰り返す最大数を定義します。
CONNECTION_ATTEMPT_INTERVAL
接続の試行間の遅延時間を秒単位で定義します。複数の INSTANCE パラメータ値が指定されている場合、CONNECTION_ATTEMPT_INTERVAL の値は、アダプタインスタンスのリスト全体を繰り返す試行間の待機秒数を定義します。
アダプタ Webject でのこれらのパラメータおよび INSTANCE パラメータの使用方法については、使用しているアダプタのアダプタガイドを参照してください。