アプリケーション プロファイルは、仮想サーバに関連付けられることで、ネットワーク トラフィックのロード バランシングを強化し、トラフィック管理タスクを簡素化します。
アプリケーション プロファイルは、それぞれ特定のタイプのネットワーク トラフィックの動作を定義します。関連付けられた仮想サーバは、アプリケーション プロファイルで指定された値に基づいてネットワーク トラフィックを処理します。Fast TCP、Fast UDP、HTTP の各アプリケーション プロファイルがサポートされています。
仮想サーバに関連付けられているアプリケーション プロファイルがない場合は、TCP アプリケーション プロファイルがデフォルトで使用されます。TCP および UDP アプリケーション プロファイルは、アプリケーションが TCP または UDP プロトコルで実行されていて、HTTP URL ロード バランシングなどのアプリケーション レベルのロード バランシングが不要な場合に使用されます。これらのプロファイルは、接続のミラーリングがサポートされる高パフォーマンスのレイヤー 4 ロード バランシングのみが必要な場合にも使用されます。
HTTP アプリケーション プロファイルは、HTTP と HTTPS の両方のアプリケーションで使用されます。これは、特定のサーバ プール メンバーに送信されたすべてのイメージ要求に対してロード バランシングを行う場合、またはプール メンバーから SSL をオフロードするために HTTPS を終了する場合など、ロード バランサがレイヤー 7 ベースでアクションを実行する際に使用されます。TCP アプリケーション プロファイルとは異なり、HTTP アプリケーション プロファイルは、サーバ プール メンバーを選択する前にクライアントの TCP 接続を終了します。
図 1. レイヤー 4 の TCP および UDP アプリケーション プロファイル
図 2. レイヤー 7 の HTTPS アプリケーション プロファイル
前提条件
NSX Manager ユーザー インターフェイスで [マネージャ] モードが選択されていることを確認します。NSX Manager を参照してください。[ポリシー] モード ボタンと [マネージャ] モード ボタンが表示されない場合は、ユーザー インターフェイスの設定 を参照してください。
手順
ブラウザから、NSX Manager (https://<nsx-manager-ip-address>) に管理者権限でログインします。
の順に選択します。
Fast TCP アプリケーション プロファイルを作成します。
ドロップダウン メニューから の順に選択します。
Fast TCP アプリケーション プロファイルの名前と説明を入力します。
アプリケーション プロファイルの詳細を入力します。
FAST TCP のデフォルトのプロファイル設定を受け入れることもできます。
オプション
説明
接続アイドル タイムアウト
TCP 接続が確立された後、サーバがアイドルのまま接続が維持される時間（秒数）を入力します。 アプリケーションが接続を終了する前にロード バランサが接続を終了するのを避けるために、実際のアプリケーション アイドル時間に数秒を加算した値をアイドル時間として設定します。
接続終了タイムアウト
FIN と RST の両方を送信した TCP 接続が、アプリケーションの接続を維持する時間を入力します。 接続にかかる時間を短縮するには、終了タイムアウトを短く設定する必要があります。
HA フローのミラーリング
ボタンの切り替えにより、関連付けられている仮想サーバへのすべてのフローを HA スタンバイ ノードにミラーリングします。
[OK] をクリックします。
Fast UDP アプリケーション プロファイルを作成します。
UDP のデフォルトのプロファイル設定を受け入れることもできます。
ドロップダウン メニューから の順に選択します。
Fast UDP アプリケーション プロファイルの名前と説明を入力します。
アプリケーション プロファイルの詳細を入力します。
オプション
説明
アイドル タイムアウト
UDP 接続が確立された後、サーバがアイドルのまま接続が維持される時間（秒数）を入力します。 UDP は、コネクションレス プロトコルです。ロード バランシング処理では、同じフローと識別される UDP パケット、つまりアイドル タイムアウト期間内に受信された送信元と宛先の IP アドレス、またはポートと IP プロトコルなどが同じ UDP パケットは、すべて同じ接続に属すと見なされ、同じサーバに送信されます。
アイドル タイムアウト期間内にパケットが受信されなかった場合は、フロー署名と選択されたサーバ間で関連付けられた接続は切断されます。
HA フローのミラーリング
ボタンの切り替えにより、関連付けられている仮想サーバへのすべてのフローを HA スタンバイ ノードにミラーリングします。
[OK] をクリックします。
HTTP アプリケーション プロファイルを作成します。
HTTP のデフォルトのプロファイル設定を受け入れることもできます。
HTTP アプリケーション プロファイルは、HTTP と HTTPS の両方のアプリケーションに使用されます。
ドロップダウン メニューから の順に選択します。
HTTP アプリケーション プロファイルの名前と説明を入力します。
アプリケーション プロファイルの詳細を入力します。
オプション
説明
リダイレクト
[なし] - Web サイトが一時的に停止しているとき、ユーザーにはページが見つからないというエラー メッセージが表示されます。
[HTTP リダイレクト] - Web サイトが一時的に停止しているとき、または移動した場合、その仮想サーバ宛の受信された要求は、ここで指定した URL に一時的にリダイレクトできます。静的リダイレクトのみがサポートされています。 たとえば、[HTTP リダイレクト] を http://sitedown.abc.com/sorry.html に設定すると、元の Web サイトが停止しているとき、実際の要求が http://original_app.site.com/home.html であっても http://original_app.site.com/somepage.html であっても、受信された要求は指定された URL にリダイレクトされます。
[HTTP から HTTPS にリダイレクト] - 特定のセキュアなアプリケーションでは SSL による通信が必要ですが、非 SSL 接続を拒否するのではなく、代わりにクライアント要求が SSL を使用するようにリダイレクトできます。[HTTP から HTTPS にリダイレクト] に設定すると、ホストと URI の両方のパスを保持して、クライアント要求が SSL を使用するようにリダイレクトできます。 [HTTP から HTTPS にリダイレクト] に設定する場合、HTTPS 仮想サーバにポート 443 が必要です。また、同じロード バランサに同じ仮想サーバ IP アドレスを構成する必要があります。
たとえば、http://app.com/path/page.html へのクライアント要求は https://app.com/path/page.html にリダイレクトされます。たとえば https://secure.app.com/path/page.html にリダイレクトする際にホスト名または URI を変更する必要がある場合は、ロード バランシング ルールを使用する必要があります。
X-Forwarded-For (XFF)
[挿入] - 受信した要求に XFF HTTP ヘッダーがない場合は、ロード バランサがクライアントの IP アドレスを持つ新しい XFF ヘッダーを挿入します。受信された要求に XFF HTTP ヘッダーが存在する場合は、ロード バランサがクライアントの IP アドレスを持つ新しい XFF ヘッダーを追加します。[置き換え] - 受信した要求に XFF HTTP ヘッダーがすでに存在する場合、ロード バランサはそのヘッダーを置き換えます。 Web サーバは、処理するすべての要求を要求元のクライアント IP アドレスと共に記録します。これらのログは、デバッグと分析のために使用されます。ロード バランサに SNAT が必要な展開トポロジでは、サーバはクライアントの SNAT IP アドレスを使用しますが、そうするとログ作成の目的が達成できなくなります。
この問題を回避するには、元のクライアント IP アドレスを持つ XFF HTTP ヘッダーを挿入するようにロード バランサを構成します。接続の送信元 IP アドレスの代わりに、この IP アドレスを XFF ヘッダーに記録するようにサーバを構成します。
接続アイドル タイムアウト
HTTP アプリケーションがアイドル状態を維持できる時間（秒数）を入力します。この値は、TCP アプリケーション プロファイルで設定する TCP ソケット構成の代わりに使用されます。
要求ヘッダー サイズ
HTTP 要求ヘッダーを格納するために使用されるバッファの最大サイズ（バイト数）を指定します。
NTLM 認証
ボタンの切り替えにより、ロード バランサの TCP 多重化をオフにし、HTTP キープ アライブを有効にします。 NTLM は、HTTP 上で使用可能な認証プロトコルです。NTLM 認証でロード バランシングを行うには、NTLM ベースのアプリケーションをホストしているサーバ プールで TCP 多重化を無効にする必要があります。無効にしないと、特定のクライアントの資格情報で確立されたサーバ側の接続が、別のクライアントの要求を処理するために使用される可能性があります。
NTLM がプロファイルで有効になっており、仮想サーバに関連付けられている場合、サーバ プールで TCP 多重化が有効になっていると、NTLM が優先されます。その仮想サーバに対して、TCP 多重化は実行されません。ただし、同じプールが NTLM でない別の仮想サーバに関連付けられている場合は、TCP 多重化をその仮想サーバへの接続に使用できます。
クライアントが HTTP/1.0 を使用している場合、ロード バランサは HTTP/1.1 プロトコルにアップデートし、HTTP キープ アライブが設定されます。同じクライアント側 TCP 接続で受信されたすべての HTTP 要求は、再認証が不要になるように、1 つの TCP 接続を介して同じサーバに送信されます。
[OK] をクリックします。
