SLB は HTTP リダイレクトをサポートしていますか。

はい。

SLB は HTTP から HTTPS へのリダイレクトをサポートしています。

NIC を無効にした場合、SLB サービスは影響を受けますか。

ECS インスタンスがパブリック IP を設定している場合、インターネット NIC を無効にすると、負荷分散サービスに影響が及びます。

バックエンド ECS がパブリック IP で設定されている場合、トラフィックはインターネット NIC を通過します。 インターネット NIC が無効になっていると、返すデータパケットを送信できません。 インターネット NIC は無効にしないことを推奨します。 しかしながら、必要な場合は、サービスへの影響を避けるためにデフォルトルートをイントラネットへ変更することができます。 ただし、インターネット経由での RDS へのアクセスなど、ビジネスがインターネットに依存しているかどうかを検討する必要があります。

接続がピーク帯域幅の値に到達できない原因を教えてください。

SLB は負荷分散サービスを提供するためにクラスターにデプロイされるため、すべてのリクエストは SLB システムサーバー上に均等に分散されます。 同様に、指定された帯域幅もこれらのサーバーに均等に分散されます。

単一接続ダウンロードのトラフィック上限の計算方法は次のとおりです。単一接続ダウンロードピーク= Server Load Balancer の設定済み合計帯域幅/(N-1) 。 N はトラフィック転送グループの数を表し、現在の値は 4 です。 たとえば、コンソールで帯域幅の上限を10 MB に設定した場合、各クライアントのダウンロードの最大トラフィックは 10/(4-1) 、つまり 3.33 MB です。

Server Load Balancer の実装原則を考慮して、外部サービスへの悪影響や制限を排除するために、ビジネス条件と実装モードに基づいて単一のリスナーに対して妥当な帯域幅ピーク値を設定することを推奨します。

各リスナーのタイムアウト値を教えてください。

  • TCP リスナー：900 秒
  • UDP リスニング：90秒
  • HTTP リスナー：60 秒
  • HTTPS リスナー：60 秒

SLB 接続がタイムアウトになる原因を教えてください。

サーバー側の問題では、次のような状況で接続タイムアウトが発生する可能性があります。

  • SLB インスタンスの IP の保護

    ブラックホーリングやスクラビング、WAF 保護など

  • クライアントポートの不足

    クライアントポートが不足していると、特にストレステストで接続エラーが発生する可能性があります。 SLB は TCP 接続のタイムスタンプ属性を消去します。 したがって、tw_reuse パラメーターは機能せず、time_wait 状態の接続ヒープによってクライアントポートが不足します。

    解決策：クライアントに対して TCP キープアライブを有効にせず、接続を終了する際は FIN パケットの代わりに RST パケットを使用します。

  • バックエンドサーバーの受け入れキューの飽和

    バックエンドサーバーの受け入れキューがいっぱいの場合、バックエンドサーバーは SYN_ACK パケットを送信することができません。 そのため、接続がタイムアウトします。

    解決策：net.core.somaxconn のデフォルト値は 128 です。 sysctl -w net.core.somaxconn=1024 コマンドを実行し、この値を変えて、バックエンドサーバーのアプリケーションを再起動します。

  • バックエンドサーバからレイヤー 4 ロードバランシングサービスへのアクセス

    レイヤー 4 ロードバランシングサービスの場合、バックエンドサーバからサービスにアクセスすると接続は失敗します。

  • 不適切な RST 設定

    SLB で TCP 接続が確立されてから 900 秒以内にデータが転送されない場合、システムは RST パケットをクライアントとバックエンドサーバーに送信して接続を終了します。 バックエンドサーバーの RST 設定が正しく行われていない場合、バックエンドサーバーは無効な接続にデータを送信する可能性があり、接続タイムアウトの原因となります。

セッションの持続性が失敗する原因を教えてください。

セッション持続性障害の考えられる原因およびそれぞれの解決策は、次のとおりです。

  • セッション持続性を有効にしたことを確認してください。
  • HTTP / HTTPS リスナーは、セッションの持続性に必要なクッキーをバックエンドサーバーから返される 4xx コードメッセージに挿入することはできません。

    解決方法：HTTP / HTTPSリスナーを TCP リスナーに変更します。 TCP リスナーのセッション持続性は、送信元クライアントの IP アドレスに基づいています。つまり、クッキーをバックエンドサーバーに挿入することができます。

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

    SLB がバックエンド ECS インスタンスに Cookie を挿入するときに、HTTP ステータスコード 302 リダイレクトが ECS インスタンスによって返されると、セッション持続性の SERVERID 文字列が変更され、セッション持続性エラーが発生します。

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

    解決策：TCP リスナーを使用してください。 TCP リスナーのセッション持続性は、送信元クライアントの IP アドレスに基づいています。つまりクッキーをバックエンドサーバーに挿入できます。

  • タイムアウト期間が短すぎる タイムアウト期間をもっと大きい値に変更する必要があります。

セッション持続性文字列の表示方法を教えてください。

ブラウザの F12 キーを押して、SERVERID 文字列または指定したキーワードがレスポンスメッセージに含まれているかどうかを確認できます。 あるいは、 curl www.example.com -c / tmp / cookie123 を実行してクッキーを保存してから、 curl www.example.com -b / tmp / cookie123 を実行してクッキーを訪問することもできます。

Linux curl を使用したセッション持続性のテスト方法を教えてください。

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

    各バックエンド ECS インスタンスにテストページを作成し、サーバーのイントラネットIPアドレスがテストページに表示されていることを確認します。 次の図は、出力パラメーターの例を示しています。

  2. カールを使用してテストします。

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

    1. テストに使用する Linux サーバーにログオンします。
    2. 次のコマンドを実行して、サーバーに挿入されているクッキーの値を確認してください。 
      curl -c test.cookie http://1.1.1.1/check.jsp
      注 デフォルトでは、SLB はクッキーを挿入してセッション持続性を維持します。 ただし、カールはクッキーを保存または送信しません。 したがって、対応するクッキーを最初に保存する必要があります。 そうでないと、カールテストの結果、セッションの持続性が失敗したと誤って判断されることがあります。
    3. 次のコマンドを実行して、プロジェクトをコンパイルします。 
      for ((a=1;a<=30;a++)); 2="" do="" curl="" -b="" 1.cookie=""
            check.jsp="">/dev/null | grep '10.170.*';sleep 1; done`
      注 a≦30 の場合、 30 はテストの繰り返し数であり、必要なテスト数に変更できます。 grep ‘10.170.*’ では、10.170.* は検索される IP アドレスです。使用しているサーバーのイントラネット IP に変更することができます。
    4. 上記のテストで返された IP アドレスを確認してください。 それらが同じアドレスであれば、セッション持続性は機能しています。 アドレスが異なる場合、セッション持続性は失敗しています。

バックエンドサーバーから応答がある前にクライアントを SLB から切断した場合、SLB はバックエンドサーバーから切断されますか。

いいえ。 読み取り/書き込み操作中は、SLB はバックエンドサーバーから切断しません。