シスプレックス・ディストリビューターは、通常、それぞれの接続要求を候補のサーバー・インスタンスの 1 つに到達したときに分散し、これは、接続要求が到達した時点での使用可能な容量と有効なポリシーに基づいて行われます。 特に、それぞれの接続は、着信する接続要求を受信するサーバー・インスタンスに関して、他のすべての既存接続や将来の接続から独立したものと見なされます。
しかし、一部のアプリケーションでは、クライアントと、複数の接続をスパンする必要がある特定のサーバー・インスタンスとの間にアフィニティーが確立されます。 例えば、TN3270E Telnet サーバー・プリンター・セッションは、Telnet クライアントからの接続要求に基づいており、そのプリンター・セッション接続要求は、LU2 セッションにサービスを行っているのと同じ TN3270E Telnet サーバーへ経路指定される必要があります。同様に、ショッピング・カートなどの Web ベースのアプリケーションでは、すべての接続が、特定のクライアントから、ショッピング・カートのコンテンツをセッション状態として格納しているサーバー・インスタンスへ来ていなければならない場合があります。
VIPADISTRIBUTE ステートメント上の TIMEDAFFINITY パラメーターは、シスプレックス・ディストリビューターに対し、特定の分散 DVIPA への接続はクライアントの起点を考慮する必要があることを示します。 IP アドレスによって識別されたのと同じクライアントからの接続は、複数のサーバー・インスタンスが単一のターゲット・スタックによってホストされている場合でも、同じサーバー・インスタンスへ経路指定される必要があります。
VIPADISTRIBUTE ステートメント上で TIMEDAFFINITY パラメーターにゼロ以外の値を指定した場合、特定のクライアントからの最初の接続は、原則としてターゲット・スタックと listen しているアプリケーションへ経路指定されます。 その時点で、シスプレックス・ディストリビューターのルーティング・スタックとターゲット・スタックは、どちらもアフィニティーを確立し、それ以後の同じクライアントからの接続要求を管理します。 このアフィニティーは、接続カウント (初期には 1) を保守します。 同じ分散 DVIPA およびポートについての後続の接続要求は、同じクライアント IP アドレスから着信するので、これらは同じサーバー・インスタンスに経路指定され、 アフィニティー接続カウントは増分されます。 アフィニティー・ベースの接続 (最初の接続も含む) がクローズされると、接続カウントは減分されます。
最後の既存接続がクローズされ、カウントがゼロになった時点で、TIMEDAFFINITY パラメーターによって指定された継続時間 (秒単位) のタイマーが開始されます。 このタイマーは、同じクライアントから同じ分散 DVIPA およびポートへの別の接続要求が受信された時点で停止し、接続要求は指定されたサーバー・インスタンスへ経路指定されます。 タイマーが満了する前に、そのクライアントから、指定された分散 DVIPA およびポートへの接続要求を受信しなかった場合、アフィニティーはシスプレックス・ディストリビューターのルーティング・スタックおよびターゲット・スタックから削除されます。 そのクライアントから次回に出される、その分散 DVIPA およびポートへの接続要求は、通常のシスプレックス・ディストリビューターの相対容量およびポリシーに関する考慮事項に従って経路指定されます。
既存のアフィニティーにマップされる接続要求は、使用される配分方式に関係なく、常にそのターゲットに経路指定されます。これは、加重アクティブ接続配分にも適用されます。確立されたアフィニティーは受け入れられますが、アフィニティーのない接続要求の配分の決定には、アフィニティー関係の結果として確立されたアクティブ接続が含まれます。
TIMEDAFFINITY 値を 0 として指定する VIPADISTRIBUTE ステートメントを含むプロファイルで VARY TCPIP,,OBEYFILE コマンドを使用すると、新しいアフィニティーの確立が妨げられます。 しかし、既存のアフィニティーは、このアフィニティーを使用するすべての接続が終了し、このアフィニティーのタイマーが切れるまで残ります。 新しいステートメントによって既存のアフィニティーのタイマー値が変更されることはありません。その代わりに、アフィニティーが確立されたときにアクティブであった構成済みの TIMEDAFFINITY 値を引き続き使用します。 既存のアフィニティーを削除するには、VIPADISTRIBUTE DELETE ステートメントの後に続けて、TIMEDAFFINITY 値 0 の VIPADISTRIBUTE DEFINE ステートメントを含むプロファイルを指定して、VARY TCPIP,,OBEYFILE コマンドを発行してください。
置かれた環境によっては、 新しいクライアントの TCP 接続要求を満たすのに必要なキー・リソースが使用できない場合は、 特定のターゲット・アプリケーション・サーバー・インスタンスとのクライアントのアフィニティーが、 指定された時間間隔の前に終了する場合があることに注意してください。これには、次のシナリオがあります。
このシナリオに対する例外が生じるのは、複数のアプリケーションが同一のシステムおよび TCP/IP スタック上にあって、同一ポートで listen も行っている (つまり、その一組のアプリケーションが shareport グループを成している) 構成の場合です。この場合は、その shareport グループ内のアプリケーション・インスタンスの 1 つが終了するか、DVIPA シスプレックス・ディストリビューター・ワークロード・バランシングのために静止するか、または指定されたポートでもう listen を行わなくなった場合、ルーティング・スタックは既存のすべてのアフィニティーを維持し続けます。ただしそれは、このターゲット・システムおよび TCP/IP スタックに対してのみであり、shareport グループ内の少なくとも 1 つのアプリケーション・インスタンスがアクティブになっていて、静止しておらず、指定されたポートを listen している場合のみです。アクティブでなくなったサーバーへのアフィニティーを以前持っていたクライアントから、 新しい TCP 接続が受け取られると、 要求は同じターゲット・システムと TCP/IP スタックに経路指定されます。 shareport グループ内の他の使用可能なサーバーの 1 つが選択され、要求を処理し、新規アフィニティーが確立されます。
シスプレックス・ディストリビューターのクライアントの概念は、 接続要求上のソース IP アドレスにのみ結びつけられています。この概念は新しいことではなく、ポリシー・エージェントや IPSec など、他の機能にも当てはまります。 しかし、そのために、本当に異なるクライアント・インスタンスからの多数の異なる接続が、すべて同じソース IP アドレスで現れる状況では、問題が起きる場合があります。 例としては、以下の状況があります。
これに似た事例では、シスプレックス・ディストリビューターが、同じソース IP アドレスを使用するさまざまな実クライアントからの接続要求を区別する手段を持たないために、分散が最適状態より大幅に少なくなる場合があります。 すべてのソース IP アドレスが同じである (例えば、ファイアウォール内にプロキシー・インスタンスが 1 つだけ存在する) という最悪の場合、ロード・バランシングは、アフィニティーが存在する限り、まったく存在しなくなります。
基本的に、時限アフィニティーが作成されたのは、以前は不可能であった状況下で接続ワークロードの分散を許容するためです。不可能であった理由は、クライアント/サーバー・アプリケーション・モデルでは、一定の期間、特定のクライアントが特定のサーバー・インスタンスへ進む必要があるからです。 そのようなアプリケーションの場合、現時点ではワークロード・バランシングが行われません。 合理的な数のソース IP アドレスがワークロード・バランシングを許容しないようなネットワーク構成の場合、作業をソース側で分割する技法を実装する (各クライアントを固有のサーバー・アドレスへ進むように構成するか、WebSphere® HTTP サーバー・プラグインのように、プロキシーを複数のサーバー間にワークロードを分散するように構成する) 必要があります。予想されるさまざまなソース IP アドレスの数と接続要求の到着率が、合理的なバランシングを提供してシスプレックス・ワークロードの変更に対する反応を提供するのに十分なほど大きい場合、これは合理的なソリューションを提供する一方、クライアントとサーバーの間のアフィニティーをアプリケーションの必要に応じて尊重します。 それぞれの分散 DVIPA とポートのペアに基づいてアフィニティーを構成する主な理由は、アフィニティー要件がアプリケーション (ポート番号) ごとに異なり、一部のアプリケーションではアフィニティーをまったく必要としないことにあります。 使用しているネットワーク内の特定のアプリケーションにシスプレックス・ディストリビューターでの時限アフィニティーが適切であるかどうかを判別する際には、特定のネットワーク構成、特にさまざまな IP アドレスからの接続の到着率を考慮に入れる必要があります。
アフィニティー情報は、シスプレックス・ディストリビューターのルーティング・スタック、バックアップ・スタック、およびターゲット・スタック上で処理する必要があります。 ターゲット・スタックが z/OS V1R5 よりも前のバージョンの場合は、そのスタックの shareport グループの一部であるサーバー・アプリケーション・インスタンスは正しく機能せず、そのターゲット・スタックに対するアフィニティーは、1 次ルーティング・スタックの障害時にも、バックアップ・ルーティング・スタックに通知されません。バックアップ・ルーティング・スタックが z/OS V1R5 以降でないと、そのスタックが障害を起こしたルーティング・スタックを引き継ぐ場合でも、アフィニティー情報が残存するターゲット・スタックから送られてきません。 したがって、アフィニティーを備えた分散 DVIPA の分散に参加するすべての TCP/IP スタックを、少なくとも z/OS V1R5 にすることを強くお勧めします。
DETAIL 修飾子を指定して Netstat VCRT/-V レポート・オプションを使用すると、次のように、接続ごとのアフィニティー関連情報を表示することができます。
MVS TCP/IP NETSTAT CS V1R8 TCPIP Name: TCPCS 15:10:28
Dynamic VIPA Connection Routing Table:
Dest: 203.1.10.18..21 (1)
Source: 193.10.1.118..0
DestXCF: 193.1.1.108
CfgTimAff: 0200 TimAffCnt: 0000000003 TimAffLft: 0000
Dest: 203.1.10.18..21 (2)
Source: 193.10.1.118..1026
DestXCF: 193.1.1.108
PolicyRule: FTPD1
PolicyAction: paPRD-SD-7-INTR-SPECIAL
Dest: 203.1.10.18..21 (2)
Source: 193.10.1.118..1027
DestXCF: 193.1.1.108
PolicyRule: FTPD1
PolicyAction: paPRD-SD-7-INTR-SPECIAL
Dest: 203.1.10.18..21 (2)
Source: 193.10.1.118..1028
DestXCF: 193.1.1.108
PolicyRule: FTPD1
PolicyAction: paPRD-SD-7-INTR-SPECIAL
Dest: 203.1.10.18..21 (3)
Source: 193.10.1.119..0
DestXCF: 193.1.2.108
CfgTimAff: 0200 TimAffCnt: 0000000001 TimAffLft: 0000
Dest: 203.1.10.18..21 (4)
Source: 193.10.1.119..1030
DestXCF: 193.1.2.108
PolicyRule: FTPD1
PolicyAction: paPRD-SD-7-INTR-SPECIAL
Dest: 203.1.10.18..21 (5)
Source: 193.10.1.120..0
DestXCF: 193.1.1.108
CfgTimAff: 0200 TimAffCnt: 0000000000 TimAffLft: 0099
Dest: 204.2.10.11..21 (6)
Source: 193.10.1.199..1031
DestXCF: 193.1.6.108
PolicyRule: FTPD1
PolicyAction: paPRD-SD-7-INTR-SPECIAL
Dest: 205.2.10.11..21 (6)
Source: 193.10.1.199..1032
DestXCF: 193.1.6.108
PolicyRule: *NONE*
PolicyAction: *NONE*上記の例には、以下の注が適用されます。