DB2 データベースを使用するアプリケーションのクライアント・リルートの構成

ユーザーは、クライアント・リルート・フィーチャーを使用して、通信損失を回復するように DB2® ユニバーサル・データベースのクライアント・ アプリケーションを構成できるため、アプリケーションは 中断を最小限に抑えて作業を継続できます。 リルーティングは連続稼働のサポートで中心となりますが、リルーティングが 可能なのは、クライアント接続に対して識別されている代替ロケーションがある場合のみです。

始める前に

このタスクでは、以下を想定しています。
  • アプリケーション・サーバーに定義されて いる DB2 データ ・ソースがあります。データ・ソースの作成について詳しくは、『管理コンソールを使用したデータ・ソースの構成』トピックを参照してください。
  • アプリケーションが接続する DB2 データ ・ソースが、以下のいずれかを実行しています。
    • DB2 for z/OS® バージョン 10.1 以降
    • DB2 Database for Linux, UNIX, and Windows バージョン 9.7 以降
  • DB2 データベースを、冗長セットアップ、または、障害が発生した DB2 サーバーを切り離して スタンバイ・ノードにする機能とともに実装しています。
  • [z/OS]タイプ 4 接続を使用してデータ・ソースに接続します。

このタスクについて

DB2 のクライアント・ リルートでは、データベース・サーバーへの接続に障害が発生した場合に、 代替サーバー・ロケーションを提供できます。パーシスタンス・オプションを指定して クライアント・リルートを使用するよう決定すると、代替サーバーの情報が Java™ 仮想マシン (JVM) 間で保持されます。アプリケーション・サーバーがクラッシュした場合、 そのアプリケーション・サーバーがリストアされデータベースへの接続を試行したときも、 代替サーバーの情報は失われません。

クライアント側での構成 がなくても、クライアント・リルート機能が有効になっているならば、DB2 用 JDBC ドライバーは、 DB2 サーバー への初期接続を確立する際に、そのクライアント・リルート機能をサポートします。 代替サーバーが構成されている DB2 サーバーに JDBC ドライバーが 接続する時点で、1 次サーバーは、代替サーバーについての情報を JDBC ドライバーに送信 します。1 次サーバーへの接続に失敗した場合、JDBC ドライバーは、 代替サーバーへの接続をリルートできます。ただし、クライアント・プロセスがクラッシュ した場合は、代替サーバーの情報は失われるため、クライアントは 1 次サーバーに再度接続する 必要があります。クライアントは、1 次サーバーへの初期接続を確立できなかったならば、 代替サーバーの情報を持たないため、リルートすることはできません。

この問題を解決するには、アプリケーション・サーバー の DB2 データ・ ソースを、「代替サーバー名」および「代替ポート番号」フィールド、または clientRerouteAlternateServerName および clientRerouteAlternatePortNumber データ・ソース・カスタム・プロパティーを使用して構成することで、初期接続の試行時でもクライアント・リルートをサポートできます。 JDBC ドライバーは、1 次 DB2 サーバーに接続できない場合、クライアント・ リルートに必要な情報が既に示されているので、代替サーバーへの 接続をリルートすることができます。

重要: データ・ソース・カスタム・プロパティー enableClientAffinitiesList は、clientRerouteAlternateServerName および clientRerouteAlternatePortNumber プロパティーのセマンティクスを変更します。
これらのプロパティーについて詳しくは、DB2 インフォメーション・センターの『サポートされるすべてのデータベース製品に共通の IBM Data Server Driver for JDBC and SQLJ のプロパティー』トピックを参照してください。クライアント・アフィニティーについて詳しくは、『DB2 データベースを使用するアプリケーションのクライアント・アフィニティーの構成』トピックを参照してください。

また、DB2 データ ソースをタイプ 4 の JDBC ドライバーとして構成した場合、「クライアント・リルート ・サーバーが JNDI 名をリストする (Client reroute server list JNDI name)」フィールド、または clientRerouteServerListJNDIName データ・ソース ・カスタム・プロパティーを使用して、クライアント・リルートの状態のパーシスタンスを 有効にできます。 通常、接続がリルートされ、JDBC ドライバーが代替 DB2 サーバーに接続されている場合は、代替サーバーは、それ自体の代替サーバーに関する情報を JDBC ドライバーに送信します。これにより、JDBC ドライバーは、代替 DB2 サーバー が利用できなくなったときに、接続を再度リルートするために必要な情報を取得します。 この時点で、もともと代替サーバーだったサーバーが、効率よく 1 次サーバーになり、 新しい代替サーバーが確立されます。 クライアント・リルートのパーシスタンスを有効にすると、この新しい状態が 記憶されます。 アプリケーション・サーバーがクラッシュして再始動した場合、JDBC ドライバーは、 クラッシュ時に 1 次サーバーと見なされて いた DB2 サーバー に接続できます。パーシスタンス・フィーチャーがないと、JDBC ドライバーは、 元のサーバーの構成から開始し、もともと 1 次サーバーと見なされていたサーバーへの 接続を試行する必要があります。

以下の DB2 構成可能環境で、自動クライアント・リルート・フィーチャーを 使用できます。
  • データ・パーティショニング・フィーチャー (DPF) を使用した Enterprise Server Edition (ESE)
  • データ・プロパゲーター (DPROPR) スタイルの複製
  • 高可用性クラスターのマルチ プロセッサー (HACMP™)
  • 高可用性災害時リカバリー (HADR)

手順

  1. 管理コンソールで、「リソース」 > 「JDBC」 > 「データ・ ソース」 > 「data_source」の順でクリックします。
  2. 「WebSphere Application Server データ・ソース・プロパティー 」をクリックします。
  3. 「DB2 自動クライアント・リルートのオプション (DB2 automatic client reroute options)」セクションで、クライアント・リルートを使用可能 にするためのフィールドに入力します。 以下のフィールドに入力します。
    代替サーバー名 (Alternate server names)
    DB2 サーバーの 代替サーバー名のリストを指定します。複数の代替サーバー名を指定する場合、 名前をコンマで区切る必要があります。以下に例を示します。
     host1,host2
    代替ポート番号 (Alternate port numbers)
    DB2 サーバーの 代替サーバーのポート (複数可) のリストを指定します。複数の代替サーバーのポートを指定する場合、 ポートをコンマで区切る必要があります。以下に例を示します。
    5000,50001
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 代替ポートとホストの両方に対して、同数のエントリーを指定する必要があります。 同数でないと、警告が表示され、クライアント・リルートは有効になりません。gotcha
  4. オプション: パーシスタンス・オプションを使用したクライアント・リルートを 使用可能にします。
    1. 「クライアント・リルート・サーバーが JNDI 名をリストする (Client reroute server list JNDI name)」フィールドに入力 します。 このフィールドでは、DB2 クライアント・リルートのサーバーのリストを JNDI 名前空間 にバインドする場合に使用される JNDI 名を指定します。 DB2 データベース ・サーバーでは、この名前を使用して、代替サーバーの情報がメモリーにまだない場合に、 代替サーバー名を検索します。
      トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 以下の点に注意してください。
      • このオプションは、タイプ 2 のデータ・ソースではサポートされません。 タイプ 2 の JDBC ドライバーとして構成される DB2 データ ・ソースを使用する場合、JDBC ドライバーがカタログを使用して、クライアント・リルートの 情報を保持します。このプロパティーがタイプ 2 のドライバーを使用して構成される 場合、アプリケーション・サーバーは警告を発行します。
      • データ・ソースが異なる場合は、異なる JNDI 名を使用します。同じ場合は、 データ・ソースを削除して、JNDI エントリーが名前空間から削除されるときに、JNDI エントリーを共有する他のデータ・ソースが影響を受けます。
      gotcha
  5. クライアント・リルート機能の再試行の回数と間隔を構成します。 以下の 2 つのフィールドに入力します。
    「クライアント・リルートの再試行の間隔 (Retry interval for client reroute)」
    自動クライアント・リルートの再試行の間隔の時間 (秒単位) を指定します。
    「クライアント・リルートの最大再試行数 (Maximum retries for client reroute)」
    サーバーへの 1 次接続に失敗した場合の、自動クライアント・リルート機能 によって試行される接続の再試行の最大回数を指定します。このプロパティー は、「クライアント・リルートの再試行の間隔 (Retry interval for client reroute)」が設定されている場合にのみ使用されます。
  6. OK」をクリックして、変更内容を保存します。
  7. アプリケーション・サーバーを再始動します。

次のタスク

JNDI でバインドされているクライアント・リルート情報を後で除去する場合、 データ・ソースを削除することによって除去できます。また、テスト接続サービスで アンバインド・フィーチャーを使用すれば、データ・ソースを削除せずに、アプリケーション・サーバーの JNDI 名前空間から クライアント・リルート機能の JNDI バインディングを削除 できます。
クライアント・リルートの JNDI バインディングを削除するには、 以下のようにします。
  1. 「クライアント・リルートのリストを JNDI からアンバインドする (Unbind client reroute list from JNDI)」を選択します。
  2. 「OK」をクリックします。
  3. 構成を保存します。
  4. データ・ソースの「テスト接続」をクリックします。
  5. 「クライアント・リルートのリストを JNDI からアンバインドする (Unbind client reroute list from JNDI)」を選択解除します。
  6. 「OK」をクリックします。
  7. 構成を保存します。

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_clientreroute
ファイル名:tdat_clientreroute.html