最小のVMware NSX。 パート5.ロードバランサーの構成

パート1 入門

パート2 ファイアウォールとNATルールを構成する

パート3。 DHCPセットアップ

パート4 ルーティング設定



前回、静的ルーティングと動的ルーティングの観点からNSX Edgeの機能について話しましたが、今日はバランサーを扱います。



セットアップを進める前に、バランスの主なタイプを簡単に思い出したいと思います。

理論

今日のすべてのペイロードバランシングソリューションは、ほとんどの場合、 OSIモデルの第4（トランスポート）レベルと第7（適用）レベルのバランシングという2つのカテゴリに分類されます。 OSIモデルは、バランス方法を説明する際の最良の基準点ではありません。 たとえば、L4バランサーがTLS終端もサポートしている場合、L7バランサーになりますか？ しかし、それはそうです。

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

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

• サービスディスカバリは、利用可能なバックエンド（静的、DNS、Consul、Etcdなど）のセットを決定するプロセスです。
• 検出されたバックエンドの健全性のチェック（HTTP要求を使用したバックエンドのアクティブな「ping」、TCP接続の問題の受動的検出、連続した回答のいくつかの503 HTTPコードの存在など）。
• それ自体のバランス（ラウンドロビン、ランダム選択、ソースIPハッシュ、URI）。
• TLSの終了と証明書の検証。
• セキュリティ関連のオプション（認証、DoS攻撃の防止、制限速度）など。

NSX Edgeは、2つのバランサー展開モードをサポートしています。



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



方法は次のとおりです。

1. ユーザーは、Edgeで構成されているVIPアドレス（バランサーアドレス）に要求を送信します。
2. Edgeはバックエンドの1つを選択し、宛先NATを実行して、VIPアドレスを選択したバックエンドのアドレスに置き換えます。
3. EdgeはソースNATを実行し、リクエストを送信したユーザーのアドレスを独自のアドレスに置き換えます。
4. パケットは選択したバックエンドに送信されます。
5. ユーザーの元のアドレスがバランサーのアドレスに変更されたため、バックエンドはユーザーに直接応答しませんが、エッジに応答します。
6. Edgeはサーバーの応答をユーザーに送信します。

以下のスキーム。







透過モードまたはインラインモード。 このシナリオでは、バランサーの内部および外部ネットワークにインターフェースがあります。 ただし、外部から内部ネットワークへの直接アクセスはありません。 組み込みのロードバランサーは、内部ネットワーク上の仮想マシンのNATゲートウェイとして機能します。



メカニズムは次のとおりです。

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

以下のスキーム。

練習する

私のテストベンチでは、Apacheを備えた3台のサーバーが構成されており、HTTPSで動作するように構成されています。 Edgeはラウンドロビン方式を使用してHTTPS要求のバランスを取り、新しい要求を新しいサーバーにプロキシします。



始めましょう。

NSX Edgeを使用するSSL証明書の生成

有効なCA証明書をインポートするか、自己署名証明書を使用できます。 このテストでは、自己署名を使用します。

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

アプリケーションプロファイルの構成

アプリケーションプロファイルを使用すると、ネットワークトラフィックをより細かく制御でき、管理が簡単かつ効率的になります。 彼らの助けを借りて、特定の種類のトラフィックの動作を判断できます。

1. [ロードバランサー]タブに移動し、バランサーをオンにします。 ここでのAccelerated enabledオプションは、バランサーがL7の代わりに高速のL4バランシングを使用できるようにします。
   
   
   
   
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_HASH-各パケットの送信元および宛先IPのハッシュ関数の結果に基づくサーバーの選択。
   • LEASTCONN-特定のサーバーで既に利用可能な数に応じて、着信接続のバランスをとります。 新しい接続は、接続の数が最も少ないサーバーに向けられます。
   • ROUND_ROBIN-新しい接続は、指定された重みに従って各サーバーに順番に送信されます。
   • URI - URIの左部分（疑問符の前）はハッシュされ、プール内のサーバーの総重量で除算されます。 結果は、どのサーバーがリクエストを受信するかを示し、すべてのサーバーが利用可能である限り、リクエストが常に同じサーバーにルーティングされるようにします。
   • HTTPHEADER-パラメーターとして指定できる特定のHTTPヘッダーに基づくバランス。 ヘッダーが欠落しているか、意味がない場合、ROUND_ROBINアルゴリズムが使用されます。
   • URL-各HTTP GETリクエストは、引数として指定されたURLパラメーターを検索します。 パラメーターの後に等号と値が続く場合、値はハッシュされ、実行中のサーバーの総重量で除算されます。 結果は、リクエストを受信するサーバーを示します。 このプロセスは、すべてのサーバーが使用可能である限り、要求内のユーザーIDを追跡し、同じユーザーIDが常に同じサーバーに送信されるようにするために使用されます。
   
   
   
3. [メンバー]ブロックで[+]をクリックして、サーバーをプールに追加します。
   
   
   
   
   
   
   
   ここで指定する必要があります：
   
   
   
   
   • サーバー名
   • サーバーのIPアドレス。
   • サーバーがトラフィックを受信するポート。
   • ヘルスチェック用のポート（ヘルスチェックの監視）;
   • 重み-このパラメーターを使用すると、プールの特定のメンバーの受信トラフィックの比例量を調整できます。
   • 最大接続数-サーバーへの接続の最大数。
   • 最小接続数-トラフィックが次のプールメンバーにリダイレクトされる前にサーバーが処理する必要がある最小接続数。
   
   
   
   
   
   
   これは、3台のサーバーの最終的なプールのようです。
   
   
   
   

仮想サーバーを追加

1. [仮想サーバー]タブに移動します。 +をクリックします。
   
   
   
   
2. Enable Virtual Serverを使用して仮想サーバーをアクティブ化します。
   
   
   
   名前を付け、以前に作成したアプリケーションプロファイル、プールを選択し、仮想サーバーが外部からの要求を受け入れるIPアドレスを指定します。 HTTPSプロトコルとポート443を指定します。
   
   ここのオプションのパラメーター：
   
   
   
   接続制限 -仮想サーバーが処理できる同時接続の最大数。
   
   接続レート制限（CPS）-1秒あたりの新しい着信要求の最大数。
   
   
   
   

これでバランサーの設定が完了し、パフォーマンスを確認できます。 サーバーには最も単純な構成があり、プールのどのサーバーがリクエストを処理したかを把握できます。 セットアップ中にラウンドロビンバランシングアルゴリズムを選択しました。各サーバーのWeightパラメーターは1に等しいため、次の各要求はプールの次のサーバーによって処理されます。



ブラウザにバランサーの外部アドレスを入力して、以下を参照してください。







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







そして再び-プールから3番目のサーバーをチェックするには：







チェックすると、Edgeが送信する証明書が最初に生成したものと同じであることがわかります。



Edgeゲートウェイコンソールからバランサーのステータスを確認します。 これを行うには、 show service loadbalancer poolと入力します 。

プール内のサーバーのステータスを確認するためのService Monitorの構成

Service Monitorを使用して、バックエンドプール内のサーバーのステータスを監視できます。 要求への応答が予期したものと一致しない場合、サーバーはプールから撤回して、新しい要求を受け取らないようにすることができます。



デフォルトでは、3つの検証方法が設定されています。

• 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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その他の例はこちら 。



それはバランサーについてのすべてです。 質問があれば、尋ねてください、私は答える準備ができています。