ロード・バランサーに Advisor のロケーション (IP アドレスおよびポート) を構成します。使用可能性を最大にするために、このアドレスは DVIPA として定義してください。
シスプレックスのサブプレックス環境では、このステップには追加のアクションが必要です。このステップの変更については、サブプレックス環境における外部ロード・バランサーの構成を参照してください。
TLS/SSL を使用している場合、ロード・バランサーは z/OS® Load Balancing Advisor 環境内のクライアント・アプリケーションです。Advisor の構成に使用されているのと同じ TLS/SSL プロトコルおよび暗号スイート (データを暗号化する場合) を使用して、ロード・バランサーを構成する必要があります。クライアント証明書はロード・バランサー上に構成し、またそのレベルの認証が必要な場合は、z/OS SAF 準拠のセキュリティー製品にも定義する必要があります。手順については、ロード・バランサーの資料を参照してください。
ロード・バランサーが Advisor と通信する機能をカスタマイズできる場合があります。SASP プロトコルは 2 つの機能を定義しており、ロード・バランサーの実装でこの機能を構成可能な場合と不可能な場合があります。その 1 つは、ロード・バランサーが Advisor をポーリングして更新データの有無を確認するか、それとも更新データがロード・バランサーにプッシュされるかを決定します。 もう 1 つは、データが更新されたメンバーのみをロード・バランサーに送るか、それとも、データが変更されたかどうかに関係なくすべてのメンバーをロード・バランサーに送るかを決定します。 これらの特性をカスタマイズできるかどうか、およびカスタマイズできる場合のカスタマイズ方法については、ご使用のロード・バランサーの資料を参照してください。ロード・バランサーが、Advisor からロード・バランサーへの更新情報のプッシュを要求でき、またそのように構成されている場合は、Advisor は少なくとも各更新間隔ごとにロード・バランサーを更新します。ロード・バランサーが、Advisor に更新情報の確認のためのポーリングを行うよう要求でき、またそのように構成されている場合は、Advisor は、各更新間隔ごとにポーリングするようロード・バランサーに促します。しかし、ロード・バランサーはこのガイドラインを無視することを選択する可能性があります。この環境で予想される動作については、ロード・バランサーの資料を参照してください。
使用可能性を確保するためには、同じように構成された予備のロード・バランサーを保有することを検討してください。 その場合は、このロード・バランサーの固有のロード・バランサー識別子 (LB UID) を知っていることが必要です。これは、UID または UUID とも呼ばれるもので、ロード・バランサーを一意的に識別します。重複する LB UID 許可されません。ロード・バランサーから既存の接続と同じ LB UID を使用して Advisor に接続しようとすると、既存の接続は強制的に切断され、新規の接続に置き換えられます。 予備として構成されたロード・バランサーを、バックアップ対象のロード・バランサーと同時に接続してホット・スタンバイとして使用したい場合は、それらのロード・バランサーはそれぞれ固有の LB UID を持っている必要があります。あるいは、それらのロード・バランサーを同じ LB UID で構成した場合は、オリジナルのロード・バランサーが失敗するまでは、Advisor から切断された状態にしておく必要があります。
一部のロード・バランサーは、各パケットをその宛先に転送時にディスパッチ・モードまたは直接指定モードを使用できる場合があります。外部ロード・バランサーは、通常、クラスター IP アドレスを使用して、ロード・バランシング対象のアプリケーションのセットを表します。 クライアント・アプリケーションは、その要求としてこのクラスター IP アドレスを宛先 IP アドレスとして使用します。ロード・バランサーがディスパッチ・モードを使用する場合は、着信 IP パケットの宛先 IP アドレスは変更されません。代わりに、ロード・バランサーは、ターゲット z/OS システム上のネットワーク・アダプターの MAC アドレスを使用して、パケットをそのシステムへ転送します。受信側の z/OS システムは、パケットの宛先 IP アドレスを検査して、それが HOME リスト内の IP アドレスの 1 つに一致すれば、そのパケットを受け入れます。 したがって、ディスパッチ・モードでは、すべてのターゲット z/OS システムの HOME リストに、ロード・バランサーのクラスター IP アドレスが定義されている必要があります。 ただし、これらのアドレスは、動的ルーティング・プロトコルによって外部に公示されないようにすることが重要です。これを達成する 1 つの方法は、これらの IP アドレスをループバック・アドレスとして z/OS 上で定義することです。
直接指定モードでは、ロード・バランサーは、ネットワーク・アドレス変換 (NAT) のようなテクノロジーを使用して、宛先 IP アドレス (つまりクラスター IP アドレス) をターゲット z/OS システムが所有する 1 つの IP アドレスに変換します。これらの接続用の IP パケットをクライアントに送り返す場合は、ロード・バランサーは、ソース IP アドレス (つまりターゲット z/OS システムの IP アドレス) を変換して、 アプリケーションがその要求上で以前に使用したクラスター IP アドレスに戻します。
ディスパッチ・モードでは、NAT を行う必要はなくなりますが、これには特別な考慮事項が幾つかあります。例えば、図 1 では、SYSA および SYSB は両方とも同じサーバー (FTPD) を持っており、このサーバーは INADDR_ANY を使用して同じポート番号にバインドされます。 パケットはクラスター IP アドレスを持つことになるので (SYSA および SYSB はどちらも同じクラスター内にあります)、ロード・バランサーは、MAC アドレスを使用して、SYSA または SYSB のどちらにパケットを送信することを決定し、TCP/IP はそのパケットをサーバーにルーティングします。
直接指定モードでは、パケット自体の中で宛先 IP アドレス (サーバー NAT) が変更されるか、または、宛先 IP アドレスおよびソース IP アドレス (サーバー NAT およびクライアント NAT) の両方がパケット内で変更されます。 このパケットは同一ロード・バランサーを介して戻される必要があり、このロード・バランサーは変更を認識し、逆のマッピングを行うことになります。このため、パケットはオリジナルの転送先からオリジナル・ソースへと流れることができます。
個々のターゲット・アプリケーション・インスタンスを表すメンバー、またはシスプレックス内の 1 つのシステムを総称的に表すシステム・メンバー、あるいはその両方を使用して、各ロード・バランサーを構成してください。 同一タイプのワークロードを共用できるメンバーは、同一グループの下で定義されます。例えば、TN3270E Telnet サーバーはあるグループ下に定義され、HTTP サーバーは別グループ下に定義されます。 アプリケーション・メンバーを定義するには、IP アドレス、ゼロ以外のポート、およびゼロ以外のプロトコルを指定します。システム・メンバーを定義するには、IP アドレスを指定し、ポートとプロトコルにゼロを指定します。 ゼロのポートのみまたはゼロのプロトコルのみ (つまり両方ではなく一方だけがゼロ) を持つメンバーは、有効なメンバーとは見なされず、Advisor からのデータを受信しません。 メンバーの IP アドレスは、そのシスプレックス内で有効かつ到達可能なアドレス (ある特定のシスプレックス・システムに対して固有のアドレス) を表していなければなりません。 これには、ループバック・アドレスやその他の公示されないアドレスは含まれません。