システムの概要

図 1 は、4 つのシステム、シスプレックス外部のネーム・サーバー、シスプレックス内のネーム・サーバー、およびネットワーク内の複数のクライアントを含む z/OS® シスプレックスを示しています。 z/OS Load Balancing Advisor と ADNR は、シスプレックス内のシステムの 1 つで実行されます。z/OS Load Balancing Agent のインスタンスが、3 つのシスプレックス・システム上でアクティブになっています。3 インスタンスのサーバー・アプリケーションが、シスプレックス内でアクティブになっています。

図 1. システムの概要
z/OS Load Balancing Advisor、ADNR、および z/OS Load Balancing Agents がネットワーク内でどのように機能するかを示す図。

ADNR は、DNS 名の割り当て先シスプレックス・リソースに関する情報を使用して構成されます。これらのリソースは、グループ単位で構成されます。 例えば、あるシスプレックス (ここには、複数インスタンスの CICS® リスナー・アプリケーションが入っている) に対するネーム・サーバーで ADNR に DNS 名を管理させる場合を考えてみます。その場合、このシスプレックス内の指定ポートに対して CICS リスナー・インスタンスとなる可能性のある全インスタンスを、ADNR 構成ファイル内の同一グループで定義します。

ADNR は、シスプレックス・リソースについての構成済み情報を z/OS Load Balancing Advisor アプリケーションに登録します。この z/OS Load Balancing Advisor アプリケーションは、この情報を z/OS Load Balancing Agent (複数の場合あり) に伝達し、この Agent は、ADNR によって登録されるリソースが使用可能であるかどうかの情報をこの Advisor に報告して戻します。次に、z/OS Load Balancing Advisor は、登録されたどのリソースがアクティブであり、どのリソースがアクティブでないかを ADNR に報告します。(これ以降の文章で「Advisor」は z/OS Load Balancing Advisor を、「Agent」は z/OS Load Balancing Agent を表します。) その後、この Advisor は、それらのリソースの使用可能性に変更があるかどうかを ADNR に報告します。

この Advisor が使用可能であると報告するリソースのグループごとに、ADNR は、そのグループ内のリソースのグループ全体を表す DNS 名をネーム・サーバーに追加し、その名前を、そのグループ内の使用可能なリソースの IP アドレスにマップします。CICS リスナーの例で言いますと、各アクティブ CICS リスナー・アプリケーションの IP アドレスは、CICS リスナー・アプリケーションのグループ全体を表す名前にマップされます。非アクティブな各 CICS アプリケーションの IP アドレスは、その DNS 名にマップされません。次に、クライアントは、ADNR がネーム・サーバーに追加した名前を使用してアプリケーションに接続します。クライアントのリゾルバーに戻されるアドレス (単数または複数) は、アクティブなアプリケーション・インスタンスのみを反映します。したがって、クライアントは 1 つの DNS 名を使用して、アプリケーションの任意のアクティブ・インスタンスに接続できます。 アプリケーション・インスタンスが使用不可になると、それらの使用不可のアプリケーション・インスタンスのアドレスは、ネーム・サーバー内のその DNS 名から分離されます。 そのグループ内のすべてのアプリケーション・インスタンスが使用不可になると、そのグループのアプリケーションを表す DNS 名は、ネーム・サーバーから削除されます。

また、ネーム・サーバーで個々のサーバー・インスタンスの名前を更新するように ADNR を構成することもできます。それらの名前は、サーバー・インスタンスが使用可能になるとサーバー・インスタンスへの到達に使用できる IP アドレスにマップされます。 したがって、あるクライアントが特定サーバー・インスタンスに接続する必要がある場合、その名前を接続に使用できます。 個々の各サーバー・インスタンスが使用不可になると、その使用不可のサーバー・インスタンスを表す DNS 名は、ネーム・サーバーから削除されます。

ADNR が管理するネーム・サーバーは、RFC 2136、「Dynamic Updates in the Domain Name System (DNS UPDATE)」をサポートする必要があります。RFC のアクセスについては、関連プロトコル仕様を参照してください。

管理目的から考えると、管理対象のリソースと同じシスプレックス内で ADNR を実行するのが便利です。 ADNR はシスプレックス内で実行します。こうするとそれは移動可能になり、最適な使用可能性を提供できます。 この Advisor が稼働するシステムと同じシステムで ADNR を実行すると、ADNR と Advisor 間のネットワーク・トラフィックを減らすことができます。 さらに、ネットワーク障害により ADNR と Advisor 間の通信が中断される可能性は、この構成では排除されます。