Server Load Balancer:CLBリスナーに関するFAQ

CLBはポート転送をサポートしていますか?

はい、CLBはポート転送をサポートします。

詳細については、「HTTPからHTTPSへのリクエストのリダイレクト」をご参照ください。

パブリックネットワークインターフェイスコントローラー (NIC) を無効にすると、CLBサービスが影響を受けますか。

ECS (Elastic Compute Service) インスタンスにパブリックIPアドレスが割り当てられている場合、パブリックNICを無効にするとサービスが中断されます。

デフォルトでは、ECSインスタンスにパブリックIPアドレスが割り当てられている場合、ECSインスタンスはパブリックIPアドレスを使用してインターネットと通信します。 この場合、ネットワークトラフィックはECSインスタンスのパブリックNICを介して転送されます。 パブリックNICを無効にした場合、ECSインスタンスはインターネットに応答を送信できません。 ECSインスタンスのNICを無効にしないことを推奨します。 必要に応じて、デフォルトルートの宛先をプライベートIPアドレスに変更します。 それ以外の場合、サービスは影響を受けます。 さらに、インターネット経由のApsaraDB RDSインスタンスへのアクセスなど、インターネットアクセスが必要かどうかを確認します。

いくつかのシナリオで接続が最大帯域幅に達しないのはなぜですか?

• 説明: インターネット課金方式が帯域幅課金であるインターネット対応のCLBインスタンスを購入し、クライアントでストレステストを実行するか、クライアントを使用して大きなパケットを転送すると、接続が最大帯域幅に達することができない場合があります。

• 原因:

  CLBは、バックエンドサーバーのグループ間でリクエストを均等に分散することにより、負荷分散サービスを提供します。 したがって、帯域幅は各接続に均等に割り当てられます。

  単一接続でのダウンロードのピーク帯域幅=CLBインスタンスの合計帯域幅 /(N - 1) Nはサーバグループの数を表し、4である。 たとえば、CLBコンソールで最大帯域幅を10 Mbit/sに設定した場合、複数のクライアントを同時に使用すると、合計帯域幅は10 Mbit/sに達する可能性があります。 各クライアントの最大帯域幅は、10/(4 − 1) = 3.33 Mbit/sの式に基づいて計算される。

• 推奨ソリューション:

  • CLBインスタンスのインターネット計測方法を、データ転送による課金に変更します。

  • Network Load Balancer (NLB) またはApplication Load Balancer (ALB) インスタンス、elastic IPアドレス (EIP) 、およびEIP帯域幅プランを使用します。 このソリューションは、ALBまたはNLBインスタンスのスケーラビリティを高め、接続が最大帯域幅に達することを保証します。

いくつかのシナリオでCLBが最大QPSに達しないのはなぜですか?

• 説明: 少数の永続接続が使用されるシナリオでは、サーバーグループ内のすべてのバックエンドサーバーに永続接続が割り当てられるわけではありません。 その結果、CLBインスタンスは最大QPSに達することができません。

• 原因:

  CLBは、バックエンドサーバーのグループ間でリクエストを均等に分散することにより、負荷分散サービスを提供します。 設定する最大QPSは、各バックエンドサーバーに均等に割り当てられます。

  各バックエンドサーバーの最大QPSは、次の式を使用して計算されます。各バックエンドサーバーの最大QPS=合計QPS/(N - 1) 。 Nは、サーバーグループ内のバックエンドサーバーの数です。 たとえば、CLBコンソールでSmall I (slb.s1.small) 仕様のCLBインスタンスを購入した場合、最大QPSは1,000です。 複数のクライアントを同時に使用すると、合計QPSは1,000に達する可能性があります。 バックエンドサーバーの数が8の場合、各バックエンドサーバーの最大QPSは、1000/(8 - 1) = 142の式に基づいて計算されます。

• 推奨ソリューション:

  • ストレステストのために、1つのクライアントで短期間の接続を使用します。

  • ビジネス要件に基づいて接続の再利用を減らします。

  • CLBインスタンスの仕様をアップグレードします。 詳細については、次をご参照ください： 従量課金 (従量課金) インスタンスのアップグレードまたはダウングレード

  • より高いスケーラビリティをサポートするALBインスタンスを使用します。

各タイプのリスナーの接続タイムアウト期間はどのくらいですか?

• TCPリスナー: 10〜900秒。

• HTTPリスナー:

  • アイドル接続タイムアウト時間: 1〜60秒。

  • 接続リクエストのタイムアウト時間: 1〜180秒。

• HTTPSリスナー:

  • アイドル接続タイムアウト時間: 1〜60秒。

  • 接続リクエストのタイムアウト時間: 1〜180秒。

一部のシナリオでは、新しい接続の数が上限に達しないのはなぜですか?

• 問題: 従量課金方式を使用するCLBインスタンスを購入した後、クライアント側のストレステストや単一ソースアクセスなどのシナリオでは、新しい接続が最大帯域幅に達することができません。

• 原因:

  負荷分散システムは、クラスターデプロイを使用して高可用性とスケーラビリティを確保します。 外部ネットワークからの接続は、クラスター内の複数のシステムサーバーに分散されます。 その結果、1秒あたりの接続のクォータがサーバー間で均等に分散されます。

  1秒あたりの最大接続数=CLBインスタンスの1秒あたりの接続総数 /(N - 1) 。 Nはサーバの数を表す。

  たとえば、Small I (slb.s1.small) インスタンスを購入した場合、CLBインスタンスでサポートされている1秒あたりの最大接続数は3,000です。 複数のクライアントがCLBインスタンスにアクセスすると、1秒あたりの合計接続数はCLBインスタンスで3,000に達する可能性があります。 3,000/(4 − 1) = 1,000。 したがって、各サーバーは1秒あたり最大1,000の接続をサポートします。

• 推奨ソリューション:

  • CLBインスタンスの計測方法の変更: CLBインスタンスの計測方法を、仕様を指定する必要がなく、より高いパフォーマンスをサポートする従量課金制から従量課金制に変更します。

  • NLBを使用する: NLBは、高い同時実行性や1秒あたりの多数の新しい接続が必要なシナリオに最適です。 NLBは、CLBよりも高いパフォーマンスとスケーラビリティをサポートします。 CLBはサーバーによる制限をサポートし、CLBは1秒あたりの限られた数の接続のみをサポートします。 ただし、NLBは多数の同時接続に耐えることができます。

CLBのサービスアドレスへの接続がタイムアウトするのはなぜですか。

考えられる原因：

• セキュリティ上の理由から、CLBのサービスIPアドレスがブロックされています。

  トラフィックのブラックホール、トラフィックのスクラブ、またはWAFにより、CLBのIPアドレスがブロックされる可能性があります。 WAFは、接続確立後にリセット (RST) パケットをクライアントとバックエンドサーバーに送信することで保護します。

• クライアントポートの枯渇

  クライアントポートの枯渇は、特にストレステストで接続エラーを引き起こす可能性があります。 デフォルトでは、CLBはTCP接続のタイムスタンプを削除します。 その結果、tw_reuse設定は有効にならず、time_wait状態の接続は再利用できません。 これらの蓄積された接続はすべてのポートを排気します。

  解決策: 短期間の接続ではなく永続的な接続を確立するようにクライアントを設定します。 so_lingerソケットオプションを設定して、FINパケットの代わりにRSTパケットを送信して接続を閉じます。

• バックエンドサーバーの受け入れキューがいっぱいです。

  バックエンドサーバーの受け入れキューがいっぱいになると、バックエンドサーバーはsyn_ackパケットを返すことができなくなります。 その結果、クライアントからの要求がタイムアウトします。

  解決策: net.core.somaxconnを128に設定します。 ビジネス要件に基づいて適切な値を指定し、sysctl -w net.core.somaxconn=<Desired value> を実行してパラメーターの値を変更し、バックエンドサーバーでアプリケーションを再起動します。

• レイヤ4 CLBはバックエンドサーバーからアクセスされます。

  バックエンドサーバーからレイヤー4 CLBにアクセスすると、接続が失敗します。 たとえば、バックエンドサーバーに到達したリクエストは、別のバックエンドサーバー上のアプリケーションにリダイレクトされます。

• RSTパケットは正しく応答されません。

  CLBでTCP接続が確立されてから900秒以内にデータが送信されない場合、CLBはRSTパケットをクライアントとバックエンドサーバーに送信して接続を閉じます。 バックエンドサーバー上のアプリケーションがRSTパケットに正しく応答しない場合、アプリケーションは接続が閉じられた後にデータパケットを送信する可能性があります。 その結果、CLB接続タイムアウトが発生する。

  説明

  デフォルトのタイムアウト時間は900秒です。 業務要件に基づいてタイムアウト期間を変更できます。

一部のシナリオでセッションの永続性が失敗するのはなぜですか?

• リスナーのセッション維持が有効かどうかを確認します。

• HTTPおよびHTTPSリスナーは、4xxステータスコードを持つレスポンスにCookieを挿入してセッションを保持できません。

  解決策: HTTPまたはHTTPSリスナーの代わりにTCPリスナーを使用します。 TCPリスナーは、クライアントIPアドレスに基づいてセッションを持続します。 バックエンドサーバーは、Cookieを挿入または検証して、セッションが永続化されることを確認できます。

• HTTP 302リダイレクトは、セッションを永続化するためのSERVERID文字列を変更します。

  CLBがHTTPステータスコード302を運ぶ応答にクッキーを挿入すると、SERVERID文字列が変更されます。 その結果、セッションを持続させることができない。

  原因を确认するには、ブラウザまたはパケットキャプチャソフトウェアを使用してリクエストとレスポンスを确认してください。 次に、302ステータスコードがパケットに含まれているかどうか、およびcookieのSERVERID文字列が変更されているかどうかを確認します。

  解決策: HTTPまたはHTTPSリスナーの代わりにTCPリスナーを使用します。 TCPリスナーは、クライアントIPアドレスに基づいてセッションを持続します。 バックエンドサーバーは、Cookieを挿入または検証して、セッションが永続化されることを確認できます。

• タイムアウト時間は小さい値に設定される。 タイムアウト期間をより大きな値に設定できます。

クッキーを表示するには?

ブラウザを開き、F12を押して、SERVERIDまたはユーザー定義のcookieが応答に挿入されているかどうかを確認します。 cur l www.example.com -c /tmp/cookie123コマンドを実行してcookieを保存し、cur l www.example.com -b /tmp/cookie123コマンドを実行してcookieを表示することもできます。

Linux curlコマンドを使用してセッションの永続性をテストする方法?

1. テストページを作成します。

   各バックエンドサーバーにテストページを作成します。 テストページでバックエンドサーバーのプライベートIPアドレスを確認できます。 次の図は、出力パラメーターの例を示しています。 プライベートIPアドレスは、リクエストが配信されるバックエンドサーバーを示します。 プライベートIPアドレスは、CLBがセッションを保持できるかどうかをテストするために使用されます。

   

2. Linuxでcurlコマンドを実行します。

   この例では、Linuxを実行するCLBインスタンスのIPアドレスは10.170.XX.XXで、作成されたページのURLはhttp:// 10.170.XX.XX/check.jspです。

   1. Linuxを実行しているサーバーにログオンします。

   2. 次のコマンドを実行して、バックエンドサーバーによって挿入されたcookieを照会します。

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      説明

      デフォルトでは、CLBはCookieを挿入してセッションを保持します。 ただし、カールはクッキーを送信または保存しません。 したがって、テストを実行する前にcookieを保存する必要があります。 そうでない場合、curlテスト結果は、セッション持続性が無効であることを示す。

   3. cookieを保存した後、次のコマンドを実行します。

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      説明

      a<=30は、実行するテストの数を示します。 この値は、ビジネス要件に基づいて設定できます。 grep '10.170.XX. XX' のIPアドレスをECSインスタンスのプライベートIPアドレスに設定します。

   4. 上記のテストで返されたIPアドレスを確認します。 同じIPアドレスが返された場合は、CLBがセッションを永続化できることを示します。

クライアントが応答を受信する前にクライアントがCLBとの接続を閉じた場合、CLBはバックエンドサーバー側の接続を閉じますか。

この場合、CLBはバックエンドサーバー側の接続を閉じません。

リクエストがCLBに送信される前に、リクエストがすでにTCPオプションアドレス (TOA) ヘッダーを持っている場合、CLBはヘッダーにクライアントIPアドレスを保持できますか?

いいえ、CLBはTOAヘッダーにクライアントIPアドレスを保持できません。 デフォルトでは、TOAモジュールがインストールされている場合、CLBは自動的にTOAヘッダーを追加してクライアントIPアドレスを保持します。 CLBが既にTOAヘッダーを運ぶ要求を受信した場合、CLBはヘッダーにクライアントIPアドレスを保存できません。

CLBのWAF保護を有効にするにはどうすればよいですか?