分散された DVIPA は複数のスタック上に存在しますが、シスプレックスの外側には、1 つのスタックによってのみ公示されます。このスタックが着信するすべての接続要求を受け取り、処理のために配布リスト内のすべてのスタックに要求をルーティングします。これにより、着信する要求のワークロードが分散されるという利点および、サーバーの障害時にも安全に対処できる予防策を提供できるという利点が得られます。
以前に定義した動的 VIPA に VIPADISTRIBUTE 構成ステートメントを 追加することにより、動的 VIPA (DVIPA) に向けられた接続を 分散することができます。 ステートメントの順序は重要です。 VIPA は、最初 VIPADEFINE ステートメントに 定義されてから、VIPADISTRIBUTE ステートメントに組み込まれます。 適切に VIPABACKUP ステートメントを指定することにより、別の TCP/IP が分散 DVIPA 用のバックアップとして働くことができます。バックアップは障害時にルーティング機能を実行します。 VIPADISTRIBUTE ステートメントに指定されたオプションは、2 番目のスタックに、その DVIPA 用のそれ自体の VIPADISTRIBUTE ステートメントがある場合 (この場合、そのスタック自体 の VIPADISTRIBUTE ステートメントを分散に使用する) を除き、 バックアップ・スタックによって継承されます。 また、VIPADISTRIBUTE ステートメントを VIPABACKUP ステートメント用にのみ指定し、VIPADEFINE ステートメント用には指定しないこともできます。これは、1 次で障害がある間のみワークロードを分散できるようにします。
DVIPA の分散は、バックアップ・スタックがそれをアクティブにした後で変更することができます。ただし、 バックアップ・スタックが DVIPA をアクティブにするより前に VIPADISTRIBUTE ステートメントに よって定義された独自の分散を持っていない場合は、その DVIPA がバックアップ・スタックでアクティブな 間に加えられた分散の変更は一時的なものになります。それらの変更は、DVIPA がバックアップ・スタックでアクティブな間は有効ですが、このスタックがその DVIPA を将来もう一度引き継ぐことがあっても、変更を記憶していません。
以下の例は、適切にコーディングされた分散 DVIPA を示しています。
IPCONFIG SYSPLEXROUTING DYNAMICXCF 193.9.200.4 255.255.255.240 1
IPCONFIG6 DYNAMICXCF 2000::93:9:200:4
VIPADYNAMIC
VIPADEFINE 255.255.255.192 9.67.240.02
VIPADISTRIBUTE DEFINE 9.67.240.02 PORT 20 21 8000 9000 DESTIP
193.9.200.2
193.9.200.4
193.9.200.6
VIPADEFINE V6DVIPA1 2000::9:67:240:2
VIPADISTRIBUTE DEFINE V6DVIPA1 PORT 20 21 8000 9000 DESTIP
2000::93:9:200:2
2000::93:9:200:4
2000::93:9:200:6
ENDVIPADYNAMIC z/OS® V1R6 Communications Server の前は、 動的 VIPA のディストリビューターとして構成された TCP/IP スタック が、IPCONFIG (または IPCONFIG6) DATAGRAMFWD TCP/IP プロファイル・ステートメントを使用して IP 転送を使用可能にするのに必要でした。TCP/IP スタックを転送ノードとして構成しないインストール・システムの場合、これは、動的 VIPA を分配するための要件ではなくなります。ただし、ご使用のシステムのターゲット TCP/IP スタックが XCF 接続のみを持つように構成されている場合は、ターゲットから発信されるパケットはすべてディストリビューターによって転送されるため、従来どおりディストリビューター上でデータグラム転送を構成する必要があります。
配分側スタックがターゲット・スタックに接続を転送するために使用する方法に 影響を与えるために行われる構成変更が幾つかあります。次に示す各項目では、すべての参加スタック とは、配分側スタックおよびすべてのターゲット・スタックを指します。
WLM ワークロード情報は、ターゲット・システムごとに使用可能な汎用 CPU 容量の比較に基づいています。 アプリケーションが System z® Application Assist Processor (zAAP) 容量または System z Integrated Information Processor (zIIP) 容量を使用する場合は、使用可能な zAAP CPU 容量と zIIP CPU 容量も考慮されるように、VIPADISTRIBUTE ステートメントを構成することができます。追加で考慮されるこれらのプロセッサー・タイプの場合、このアプリケーションで使用されるディストリビューターおよびターゲット・システムは、z/OS V1R9 Communications Server より前のバージョンにすることはできません。zAAP および zIIP CPU 容量を考慮する必要がある場合は、このアプリケーションの BASEWLM 配分の代替方式として SERVERWLM 配分を使用できるかどうかを評価してください。 SERVERWLM 配分方式には、アプリケーションの実際の CPU 使用量に基づいて、プロセッサーの比率が WLM によって自動的に判別され、動的に更新されるという利点があります。BASEWLM 配分が必要な場合は、構成するプロセッサーの比率を判別するために、Assist Processor のワークロード使用量を調べてください。これは、SMF レコードの分析、RMF™ などのパフォーマンス・モニター・レポートの使用などの方法で行います。
サーバーが System z Application Assist Processor (zAAP) 容量または System z Integrated Information Processor (zIIP) 容量を使用する場合は、アプリケーションの実際の CPU 使用量に基づいて、WLM によりプロセッサーの比率が自動的に決定され、動的に更新されます。ただし、VIPADISTRIBUTE ステートメントの構成オプションを使用して、WLM サーバー固有の推奨値に影響を与えることができます。VIPADISTRIBUTE ステートメントで PROCXCOST パラメーターを使用することで、WLM 推奨値において、使用可能な zAAP または zIIP 容量があるサーバーを、専用プロセッサーを対象とする作業を標準プロセッサーで代わりに実行する可能性のあるサーバーよりも、優先させることができます。また、VIPADISTRIBUTE ステートメントで ILWEIGHTING パラメーターを使用することで、WLM 推奨値においてどの程度積極的に、より低い重要度レベルに明け渡し可能な容量があるシステム上のサーバーを、より高い重要度レベルに明け渡し可能な容量があるシステム上のサーバーに優先させるかに影響を与えることもできます。WLM でこれらの追加要因が考慮されるようにする場合、すべてのシステムで z/OS V1R11 Communications Server より前のリリースを実行することはできません。
使用される配分方式に関係なく、シスプレックス・ディストリビューター・ルーティング・ポリシーは、接続の配分にさらに影響を与えることができます。シスプレックス・ディストリビューター・ルーティング・ポリシーは、配分側スタック上に構成され、特定のトラフィックのセット用に、ターゲット・スタックのセットを指定します。例えば、指定されたサブネットからの、特定のポート/DVIPA を宛先としたトラフィックすべてを、ターゲット・スタックの 1 つのグループに割り当て、別のサブネットから同じポート/DVIPA に向けられたトラフィックは、ターゲット・スタックの別のグループに割り当てることができます。このようなポリシーのタイプを構成する方法について詳しくは、シスプレックス・ディストリビューター・ポリシーの例を参照してください。
ターゲット・サーバーへの接続の配分は、ターゲット・スタックまたはターゲット・サーバーの反応性による影響を受けることもあります。 シスプレックス・ディストリビューター・スタックは、ターゲット・サーバーが接続セットアップ要求にどの程度目標どおりに応答しているかをモニターし、それぞれのサーバーごとにターゲット・サーバー反応性 (TSR) 値を計算します。
ターゲット・システムのワークロードを基にした WLM ベースの転送、WLM/QoS ベースの転送、サーバー固有のワークロードを基にした WLM ベースの転送、または加重アクティブ転送の場合、新規接続セットアップ要求は、接続セットアップ要求の処理が他と比較して悪かったターゲット・サーバーから、別サーバーへと迂回されます。 ラウンドロビン転送では、ターゲット・サーバーが接続セットアップ要求を正常に受け入れていないと シスプレックス・ディストリビューターが判断した場合は、そのターゲット・サーバーはバイパスされます。ディストリビューターは、TSR が 0 のターゲットに定期的に新規接続要求を送信し、そのターゲットの反応性が改善されたかどうかをチェックします。
デフォルトで、シスプレックス・ディストリビューターは、以下のように 1 分間隔で各ターゲット・サーバーの状況を更新します。
大部分のワークロードには、デフォルトの 1 分間隔で十分です。 しかし、一部の環境では、特に各ターゲット・システムのロードが 100% 容量に近い場合、およびワークロードが大量の短期間接続で構成されている場合は、ディストリビューターがターゲット・サーバーの状況の変化により速く対応するように、これより短い間隔を使用できます。 この間隔を変更するには、GLOBALCONFIG ステートメントで SYSPLEXWLMPOLL パラメーターを使用します。
各配分側スタックおよび各ターゲット・スタックには、IPv4 または IPv6 DYNAMICXCF アドレス、あるいはその両方がなければなりません。このアドレスは、他の配分側スタックによって宛先ポイントとして使用されます。シスプレックス・ディストリビューターを使用する場合、IUTSAMEH リンクを定義してはなりません。DYNAMICXCF ステートメントからは、3 つのリンクが自動的に作成されます。IPCONFIG ステートメントまたは IPCONFIG6 ステートメントに DYNAMICXCF をコーディングする方法については、「z/OS Communications Server: IP 構成解説書」を参照してください。必要となる追加の構成パラメーターの詳細は、「z/OS Communications Server: IP 構成解説書」で、IPCONFIG ステートメントまたは IPCONFIG6 ステートメントにある、DYNAMICXCF パラメーターに関する使用上の注意事項も参照してください。
VIPADISTRIBUTE ステートメントは、新しい接続要求を候補のターゲット・スタックのセットにどのようにルーティングするかを指定します。 VIPADISTRIBUTEd DVIPA には、最大 64 ポートを指定できます。 前の例は、FTP 用のウェルノウン・ポートおよび、 カスタム・アプリケーション用のポートを示しています。
DESTIP キーワードの後には 32 までのターゲット TCP/IP が続き、それぞれの動的 XCF IP アドレスによって識別されます。あるいは、VIPADISTRIBUTE ステートメントに DESTIP ALL を指定することもでき、この場合、アクティブにされた動的 XCF を持つ、現在および将来のすべてのスタックは、候補のターゲット・スタックとして分散に参加します。アプリケーションは、それぞれのリストされた TCP/IP 上の指定されたポートの 1 つを listen するので、ルーティング TCP/IP はそのスタックに接続の転送を開始します。
シスプレックス・ディストリビューターについて詳しくは、「IBM® z/OS V1R13 Communications Server TCP/IP Implementation, Volume 3: High Availability, Scalability, and Performance」(SG24–7998) を参照してください。