自動クライアント・リルートについての説明およびセットアップ

自動クライアント・リルート・フィーチャーの主な目的は、 IBM® Data Server Client アプリケーションが通信の損失からリカバリーできるようにして、アプリケーションが最小限の中断で作業を続行できるようにすることです。名前が示すように、再ルーティングは連続稼働のサポートで中心となりますが、再ルーティングが可能なのは、クライアント接続に対して識別されている代替ロケーションがある場合のみです。

サーバーが Db2®の場合、自動クライアント・リルート・フィーチャーは、以下の構成可能な環境内で使用できます。

Db2 Enterprise Server Edition ( パーティション・データベース環境)
Db2 Enterprise Server Edition ( IBM Db2 pureScale® Feature
InfoSphere® Replication Server
IBM PowerHA® SystemMirror® for AIX®
高可用性災害時リカバリー (HADR)
自動クライアント・リルートは、HADR および Db2 pureScale Feature と連携して機能し、アクセスされているデータベースのフェイルオーバー後にクライアント・アプリケーションが最小限の中断で作業を続行できるようにします。

データベース・サーバーが System i ® または System z ®上にある場合、以下の構成でシームレス自動クライアント・リルート・フィーチャーが必要になります。

IBM データ・サーバー・クライアントは、代替サーバーを持つ Db2 Connect サーバーを介して z/OS® または i5/OS システムに接続します。自動クライアント・リルートは、 IBM Data Server Client と 2 つの Db2 Connect サーバーの間で使用されます。
Db2 for z/OS Parallel Sysplex ® データ共有環境にアクセスする Db2 Connect クライアントまたはサーバー製品。自動クライアント・リルートは、 Db2 Connect と z/OS Parallel Sysplex システムとの間で使用されます。自動クライアント・リルート・フィーチャーは、 Db2 Connectライセンス・クライアントと Parallel Sysplex との間のシームレスなフェイルオーバーをサポートします。シームレスなフェイルオーバーについて詳しくは、関連リンクを参照してください。

接続 ( Db2 C) サーバーとその代替サーバーの場合、ローカル・データベースを同期する必要がないため、オリジナルと代替の両方の接続 ( Db2 C) サーバーに、同一のデータベース別名を使用してアクセスできるようにカタログされたターゲット・ホストまたはシステム i データベースがあることを確認するだけで十分です。

Db2 データベース・システムが通信障害からリカバリーできるようにするためには、通信障害が発生する前に、代替サーバーの場所を指定しておく必要があります。 UPDATE ALTERNATE SERVER FOR DATABASE コマンドは、特定のデータベース上の代替サーバー・ロケーションを定義するために使用します。

サーバー・インスタンスの特定のデータベースで代替サーバー・ロケーションを指定すると、接続プロセスの一部として、代替サーバー・ロケーション情報が IBM データ・サーバー・クライアントに返されます。 Db2 Connect クライアントまたはサーバー製品と、ホストまたは System i データベース・サーバーとの間で自動クライアント・リルートを使用する場合、リモート・サーバーはそれ自体に 1 つ以上の代替アドレスを提供する必要があります。 Db2 for z/OSの場合、データベースがシスプレックス・データ共用環境であれば、複数のアドレスが認識されます。したがって、代替サーバーを Db2 Connectにカタログする必要はありません。何らかの理由でクライアントとサーバー間の通信が失われた場合、 IBM Data Server Client は、代替サーバー情報を使用して接続を再確立しようとします。 IBM データ・サーバー・クライアントは、元のサーバーである可能性があるデータベース・サーバーと、そのサーバーのデータベース・ディレクトリー・ファイルにリストされている代替サーバー、または z/OS 並列シスプレックス・システムによって戻されるサーバー・リストにある代替サーバーとの再接続を試みます。接続を再確立しようとするこうした試行は、最初は非常に短い時間間隔で行われ、徐々に試行の間隔が長くなります。

接続が成功すると、通信障害の後にデータベース接続が再確立されたことを示す SQL30108N が戻されます。ホスト名または IP アドレスと、サービス名またはポート番号が戻されます。 IBM データ・サーバー・クライアントは、元のサーバーまたは代替サーバーのいずれに対してもクライアント通信を再確立できない場合にのみ、元の通信障害のエラーをアプリケーションに返します。

V10.1 フィックスパック 2 以降のフィックスパックでは、ワークロード・バランス (WLB) フィーチャーを有効にして Db2 for z/OS データ共有グループに接続する際に、非シームレス ACR フィーチャーの動作が変更されました。

CLI ドライバーは、接続が失敗してもすぐには新しいトランスポートを探しません。 CLI ドライバーは、アプリケーションが SET ステートメント (特殊レジスター) または SQL ステートメントを再サブミットすると、トランスポートを割り振ります。ただし、非シームレス ACR フィーチャーが有効になっていて、WLB フィーチャーが無効になっている場合、 CLI ドライバーは直ちに新しいトランスポートを検索し、次に使用可能なメンバーに再接続します。
SQL30108N は、 CLI ドライバーが 1 次グループのメンバーへの再接続に失敗し、代替グループに切り替える必要がある場合に、アプリケーションに 2 回戻ります。代替グループが db2dsdriver.cfg ファイルに alternategroup パラメーターで指定されていて、enableAlternateGroupSeamlessAcr が FALSE に設定されていると、このエラーが 2 回戻されます。最初の SQL30108N エラー (理由コード 2) は、現行グループのメンバーへの既存の接続が失敗したときに戻されます。 2 番目の SQL30108N エラー (理由コード 4) は、既存の 1 次グループ内のすべてのメンバーに対する接続試行がすべて失敗したときに戻されます。その後、代替グループへの再接続が認可されている場合、アプリケーションは 2 回目の SET ステートメントまたは SQL ステートメントを再実行依頼できます。 CLI ドライバーは、ACR 接続エラー (SQL30108N) が戻されたときに、同じ接続ハンドルで障害が発生したメンバーを追跡して、障害が発生したメンバーにステートメントが再実行依頼されないようにします。
注: SQL30108N は、以下のシナリオでは 2 回返されません。
- Db2 Connect サーバーがゲートウェイとして使用される場合。
- ACR フィーチャーが明示的に有効にされ、WLB フィーチャーが無効な場合。

Db2 for z/OS データ共用グループに接続する場合、 IBM サポートから指示されない限り、シームレス ACR フィーチャーおよび WLB フィーチャーを使用不可にしないでください。

Db2 Connect サーバー環境での代替サーバー接続に関する以下の考慮事項に注意してください。

リモート・クライアントとローカル・クライアントの両方のために DB2 Connect サーバーを使用してホストまたは System i データベースへのアクセスを提供する場合、システム・データベースのディレクトリー項目にある代替サーバーの接続情報に関して混乱が生じる可能性があります。この混乱を最小限に抑えるために、同じホストまたは System i データベースを表すように、システム・データベースのディレクトリーで 2 つの項目をカタログすることを検討してください。リモート・クライアント用に 1 つの項目、ローカル・クライアント用にもう 1 つの項目をカタログします。
ターゲット Db2 for z/OS サーバーから返される並列シスプレックス情報は、 Db2 Connect サーバーのキャッシュにのみ保持されます。ディスクに書き込まれる代替サーバーは 1 つのみです。複数の代替サーバーまたは複数のアクティブ・サーバーが存在する場合、その情報はメモリーでのみ維持され、プロセスが終了すると失われます。

ワークロード・バランシングと自動クライアント・リルートでは、クライアントが/etc/hostsファイルのクラスターの各メンバーのエントリを持たなければなりません。以下に例を示します。

10.10.10.1 hostname01.linux hostname01
10.10.10.2 hostname02.linux hostname02

代替サーバーが指定されている場合、一般的に、通信エラーが検出されたときに自動クライアント・リルートが使用可能になります。高可用性災害時リカバリー (HADR) 環境では、SQL1776N が HADR スタンバイ・サーバーから戻された場合にも、使用可能になります。

HADR および Db2 pureScale に関する考慮事項

Db2 pureScale インスタンス内の 1 つのメンバーへの接続を確立すると、返されるサーバー・リストには、そのインスタンスのすべてのメンバーに関する情報だけでなく、代替サーバー上の Db2 pureScale インスタンスのホスト名とポートに関する情報も含まれます。クライアントは、 Db2 pureScale インスタンス内の 1 つのメンバーに接続できない場合 (または HADR が構成されている場合は 1 次データベース上のメンバーに接続できない場合)、別のメンバーに接続しようとします。どのメンバーにも接続できない場合は、指定された代替サーバー・アドレス (HADR 環境ではスタンバイ・データベース) で Db2 pureScale インスタンスを試行します。可用性の向上のため、代替サーバー・アドレスとして接続ディストリビューターまたはマルチホーム DNS エントリーを使用できますが、その際には必ず、代替サーバーの複数のメンバーが含まれるようにディストリビューターまたはマルチホーム DNS エントリーを構成する必要があります。

代替サーバーごとに 1 つだけメンバーをリストすることもできますが、リストされたメンバーがオフラインの場合にはクライアントがクラスターにアクセスできなくなるので、代替グループ方式を使用してクラスター内の複数のメンバーを定義することを強くお勧めします。これを行う方法については、関連リンクを参照してください。

その他のリルート・オプションを以下に示します。

クライアント・アフィニティー: 1 次メンバーとスタンバイ・メンバーをリストして、クライアントがどちらも試行できるようにします。クライアント・アフィニティーおよび ACR を一緒に使用することはできません。クライアント・アフィニティーが有効になっている場合、ACR で指定される代替サーバーは無視されます。クライアント・アフィニティーが有効になっている場合、代替グループは定義できません。詳しくは、 Db2のクライアント・アフィニティーのトピックを参照してください。
仮想 IP: 常に現行の 1 次サーバーを指し示す仮想 IP アドレスを定義します。