小さなお子様向けの VMware NSX。 パート 5: ロードバランサーの構成

パート1 はじめに
パートXNUMX。 ファイアウォールと NAT ルールの構成
パート XNUMX。 DHCPの設定
パート XNUMX。 ルーティングの設定

前回は、静的ルーティングと動的ルーティングの観点から NSX Edge の機能について説明しましたが、今日はロード バランサーについて説明します。
設定を始める前に、主なバランス調整の種類について簡単に思い出していただきたいと思います。

Теория

今日のすべてのペイロード バランシング ソリューションは、ほとんどの場合、モデルの XNUMX 番目 (トランスポート) レベルと XNUMX 番目 (アプリケーション) レベルでのバランシングの XNUMX つのカテゴリに分類されます。 OSI。 OSI モデルは、バランシング方法を説明する際の最良の参照点ではありません。 たとえば、L4 バランサーが TLS 終端もサポートしている場合、それは L7 バランサーになりますか? しかし、それはそういうものなのです。

• バランサーL4 ほとんどの場合、これはクライアントと利用可能な一連のバックエンドの間に立つ中間プロキシであり、TCP 接続を終了し (つまり、独立して SYN に応答し)、バックエンドを選択して、その方向に新しい TCP セッションを開始し、独立して SYN を送信します。 このタイプは基本的なタイプの XNUMX つであり、他のオプションも可能です。
• バランサーL7 L4 バランサーよりも「高度に」利用可能なバックエンド全体にトラフィックを分散します。 たとえば、HTTP メッセージの内容 (URL、Cookie など) に基づいて、どのバックエンドを選択するかを決定できます。

タイプに関係なく、バランサーは次の機能をサポートできます。

• サービス検出は、利用可能なバックエンドのセット (静的、DNS、Consul、etcd など) を決定するプロセスです。
• 検出されたバックエンドの機能を確認します (HTTP リクエストを使用したバックエンドのアクティブな「ping」、TCP 接続の問題のパッシブな検出、応答内のいくつかの 503 HTTP コードの存在など)。
• バランシング自体 (ラウンドロビン、ランダム選択、ソース IP ハッシュ、URI)。
• TLS の終了と証明書の検証。
• セキュリティ関連のオプション (認証、DoS 攻撃防止、速度制限) など。

NSX Edge は、次の XNUMX つのロード バランサ デプロイメント モードをサポートします。

プロキシモードまたはワンアーム。 このモードでは、NSX Edge はバックエンドの XNUMX つにリクエストを送信するときに、その IP アドレスを送信元アドレスとして使用します。 したがって、バランサは送信元 NAT と宛先 NAT の機能を同時に実行します。 バックエンドは、すべてのトラフィックをバランサーから送信されたものとして認識し、それに直接応答します。 このようなスキームでは、バランサーは内部サーバーと同じネットワーク セグメントに存在する必要があります。

方法は次のとおりです。
1. ユーザーは、Edge 上で構成されている VIP アドレス (バランサー アドレス) にリクエストを送信します。
2. Edge はバックエンドの XNUMX つを選択し、宛先 NAT を実行して、VIP アドレスを選択したバックエンドのアドレスに置き換えます。
3. Edge はソース NAT を実行し、リクエストを送信したユーザーのアドレスを独自のアドレスに置き換えます。
4. パッケージは選択したバックエンドに送信されます。
5. ユーザーの元のアドレスがバランサーのアドレスに変更されているため、バックエンドはユーザーに直接応答せず、エッジに応答します。
6. Edge はサーバーの応答をユーザーに送信します。
図は以下のとおりです。


透過モード、つまりインライン モード。 このシナリオでは、バランサーには内部ネットワークと外部ネットワーク上にインターフェイスがあります。 同時に、外部ネットワークから内部ネットワークに直接アクセスすることはできません。 内蔵ロード バランサーは、内部ネットワーク上の仮想マシンの NAT ゲートウェイとして機能します。

その仕組みは次のとおりです。
1. ユーザーは、Edge 上で構成されている VIP アドレス (バランサー アドレス) にリクエストを送信します。
2. Edge はバックエンドの XNUMX つを選択し、宛先 NAT を実行して、VIP アドレスを選択したバックエンドのアドレスに置き換えます。
3. パッケージは選択したバックエンドに送信されます。
4. バックエンドは、ユーザーの元のアドレス (ソース NAT は実行されません) を含むリクエストを受信し、それに直接応答します。
5. インライン スキームでは通常、ロード バランサーがサーバー ファームのデフォルト ゲートウェイとして機能するため、トラフィックは再びロード バランサーによって受け入れられます。
6. Edge は、VIP を送信元 IP アドレスとして使用して、送信元 NAT を実行してユーザーにトラフィックを送信します。
図は以下のとおりです。

練習

私のテストベンチには Apache を実行する 3 台のサーバーがあり、HTTPS 経由で動作するように構成されています。 Edge は、HTTPS リクエストのラウンド ロビン バランシングを実行し、新しいリクエストをそれぞれ新しいサーバーにプロキシします。
始めましょう

NSX Edge で使用される SSL 証明書の生成
有効な CA 証明書をインポートすることも、自己署名証明書を使用することもできます。 このテストでは自己署名を使用します。

1. vCloud Director インターフェイスで、Edge サービス設定に移動します。
   
2. 「証明書」タブに移動します。 アクションのリストから、新しい CSR の追加を選択します。
   
3. 必須フィールドに入力し、「保持」をクリックします。
   
4. 新しく作成した CSR を選択し、自己署名 CSR オプションを選択します。
   
5. 証明書の有効期間を選択し、「保持」をクリックします。
   
6. 自己署名証明書が使用可能な証明書のリストに表示されます。
   

アプリケーションプロファイルの設定
アプリケーション プロファイルを使用すると、ネットワーク トラフィックをより完全に制御できるようになり、管理がシンプルかつ効果的になります。 これらは、特定の種類のトラフィックの動作を定義するために使用できます。

1. [ロード バランサー] タブに移動し、バランサーを有効にします。 ここでのアクセラレーション有効オプションにより、バランサーは L4 の代わりにより高速な L7 バランシングを使用できるようになります。
   
2. [アプリケーション プロファイル] タブに移動して、アプリケーション プロファイルを設定します。 「+」をクリックします。
   
3. プロファイルの名前を設定し、プロファイルが適用されるトラフィックのタイプを選択します。 いくつかのパラメータについて説明します。
   固執 – セッション データを保存および追跡します。たとえば、プール内のどの特定のサーバーがユーザー リクエストを処理しているかなどです。 これにより、セッションまたは後続のセッションの存続期間中、ユーザー要求が同じプール メンバーにルーティングされることが保証されます。
   SSLパススルーを有効にする – このオプションを選択すると、NSX Edge は SSL の終了を停止します。 代わりに、終了はバランスがとられているサーバー上で直接行われます。
   X-Forwarded-For HTTP ヘッダーを挿入する – ロード バランサーを介して Web サーバーに接続するクライアントの送信元 IP アドレスを決定できます。
   プールサイドSSLを有効にする – 選択したプールが HTTPS サーバーで構成されていることを指定できます。
   
4. HTTPS トラフィックのバランスをとるため、プールサイド SSL を有効にし、[仮想サーバー証明書] -> [サービス証明書] タブで以前に生成した証明書を選択する必要があります。
   
5. プール証明書 -> サービス証明書についても同様です。
   

サーバーのプールを作成し、そのプールへのトラフィックがバランスされるようにします。

1. 「プール」タブに移動します。 「+」をクリックします。
   
2. プールの名前を設定し、アルゴリズム (ラウンド ロビンを使用します) とヘルス チェック バックエンドの監視の種類を選択します。透過オプションは、クライアントの初期ソース IP が内部サーバーに表示されるかどうかを示します。
   • このオプションが無効になっている場合、内部サーバーのトラフィックはバランサーのソース IP から送信されます。
   • このオプションが有効な場合、内部サーバーはクライアントのソース IP を参照します。 この構成では、返されたパケットが NSX Edge を通過するように、NSX Edge がデフォルト ゲートウェイとして機能する必要があります。

   NSX は、次の分散アルゴリズムをサポートしています。

   • IP_ハッシュ – 各パケットの送信元 IP と宛先 IP のハッシュ関数の結果に基づくサーバーの選択。
   • リーストコン – 特定のサーバーですでに利用可能な数に応じて、受信接続のバランスをとります。 新しい接続は、接続数が最も少ないサーバーに送信されます。
   • ラウンドロビン – 新しい接続は、割り当てられた重みに従って、各サーバーに順番に送信されます。
   • URI – URI の左側の部分 (疑問符の前) はハッシュされ、プール内のサーバーの合計の重みで除算されます。 結果は、どのサーバーがリクエストを受信したかを示し、すべてのサーバーが利用可能な限り、リクエストは常に同じサーバーにルーティングされます。
   • HTTPヘッダー – パラメータとして指定できる特定の HTTP ヘッダーに基づいてバランスをとります。 ヘッダーが欠落しているか値がない場合は、ROUND_ROBIN アルゴリズムが適用されます。
   • URL – 各 HTTP GET リクエストは、引数として指定された URL パラメータを検索します。 パラメーターの後に等号と値が続く場合、値はハッシュされ、実行中のサーバーの合計の重みで除算されます。 結果は、どのサーバーがリクエストを受信したかを示します。 このプロセスは、リクエスト内のユーザー ID を追跡し、すべてのサーバーが利用可能な限り、同じユーザー ID が常に同じサーバーに送信されるようにするために使用されます。

   

3. [メンバー] ブロックで [+] をクリックしてサーバーをプールに追加します。
   
   
   ここで次を指定する必要があります。
   • サーバーの名前;
   • サーバのIPアドレス;
   • サーバーがトラフィックを受信するポート。
   • ヘルスチェック用のポート (Monitor healthcheck);
   • 重み – このパラメータを使用すると、特定のプール メンバーが受信するトラフィックの比例量を調整できます。
   • 最大接続数 – サーバーへの最大接続数。
   • 最小接続数 – トラフィックが次のプール メンバーに転送される前にサーバーが処理する必要がある接続の最小数。

   
   
   これは、XNUMX つのサーバーの最終的なプールがどのように見えるかです。
   

仮想サーバーの追加

1. [仮想サーバー] タブに移動します。 「+」をクリックします。
   
2. 「仮想サーバーを有効にする」を使用して仮想サーバーをアクティブ化します。
   名前を付け、以前に作成したアプリケーション プロファイル、プールを選択し、仮想サーバーが外部からリクエストを受信する IP アドレスを指定します。 HTTPS プロトコルとポート 443 を指定します。
   オプションのパラメータは次のとおりです。
   接続制限 – 仮想サーバーが処理できる同時接続の最大数。
   接続速度制限 (CPS) – XNUMX 秒あたりの新しい受信リクエストの最大数。
   

これでバランサーの設定が完了し、その機能を確認できるようになります。 サーバーの構成はシンプルなので、プール内のどのサーバーがリクエストを処理したかを把握できます。 セットアップ中にラウンド ロビン バランシング アルゴリズムを選択し、各サーバーの Weight パラメーターは XNUMX に等しいため、後続の各リクエストはプールの次のサーバーによって処理されます。
ブラウザにバランサーの外部アドレスを入力すると、次のように表示されます。


ページを更新した後、リクエストは次のサーバーによって処理されます。


もう一度、プールから XNUMX 番目のサーバーを確認します。


確認すると、Edge から送信された証明書が最初に生成したものと同じであることがわかります。

Edge Gateway コンソールからバランサーのステータスを確認します。 これを行うには、次のように入力します サービスロードバランサプールを表示.


プール内のサーバーのステータスを確認するための Service Monitor の構成
Service Monitor を使用すると、バックエンド プール内のサーバーのステータスを監視できます。 リクエストに対する応答が期待どおりでない場合は、サーバーをプールから削除して、新しいリクエストを受信しないようにすることができます。
デフォルトでは、次の XNUMX つの検証方法が構成されています。

• TCPモニター、
• HTTPモニター、
• HTTPS モニター。

新しいものを作成しましょう。

1. 「サービス監視」タブに移動し、「+」をクリックします。
   
2. 選ぶ：
   • 新しいメソッドの名前。
   • リクエストが送信される間隔、
   • 応答待ちのタイムアウト、
   • 監視タイプ – GET メソッドを使用した HTTPS リクエスト、予期されるステータス コード – 200(OK) およびリクエスト URL。
3. これで新しい Service Monitor のセットアップが完了し、プールの作成時にそれを使用できるようになりました。
   

アプリケーションルールの設定

アプリケーション ルールは、特定のトリガーに基づいてトラフィックを操作する方法です。 このツールを使用すると、Edge Gateway で利用可能なアプリケーション プロファイルやその他のサービスでは不可能な高度な負荷分散ルールを作成できます。

1. ルールを作成するには、バランサーの [アプリケーション ルール] タブに移動します。
   
2. 名前、ルールを使用するスクリプトを選択し、「保持」をクリックします。
   
3. ルールを作成した後、すでに構成されている仮想サーバーを編集する必要があります。
   
4. [詳細設定] タブで、作成したルールを追加します。
   

上の例では、tlsv1 サポートを有効にしました。

さらにいくつかの例を示します。

トラフィックを別のプールにリダイレクトします。
このスクリプトを使用すると、メイン プールがダウンした場合にトラフィックを別のバランシング プールにリダイレクトできます。 ルールが機能するには、バランサー上に複数のプールが構成されており、メイン プールのすべてのメンバーがダウン状態である必要があります。 プールの ID ではなく、名前を指定する必要があります。

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


トラフィックを外部リソースにリダイレクトします。
ここでは、メイン プールのすべてのメンバーがダウンした場合にトラフィックを外部 Web サイトにリダイレクトします。

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

さらに多くの例 ここで.

バランサーについては以上です。 ご質問がございましたら、いつでもお答えいたします。

出所： habr.com