Load Balancer の TCP リセットおよびアイドルのタイムアウト
-
[アーティクル]
-
-
Standard Load Balancer を使用して、特定の規則のアイドル時の TCP リセットを有効にすることにより、シナリオのより予測可能なアプリケーション動作を作成します。 ロード バランサーの既定の動作では、フローのアイドル タイムアウトに達したときに、警告なしでフローを削除します。 TCP リセットを有効にすると、ロード バランサーがアイドル タイムアウト時に双方向 TCP リセット (TCP RST パケット) を送信します。 これは、接続がタイムアウトしたため、使用できなくなったことをアプリケーション エンドポイントに通知します。 エンドポイントは、必要に応じて直ちに新しい接続を確立できます。
この既定の動作は変更でき、受信 NAT 規則、負荷分散規則、送信規則に基づいて、アイドル タイムアウト時の TCP リセットの送信を有効にできます。 規則ごとに有効にすると、ロード バランサーは双方向 TCP リセット (TCP RST パケット) を、クライアントとサーバーの両方のエンドポイントに対して、一致するすべてのフローのアイドル タイムアウト時に送信します。
TCP RST パケットを受信するエンドポイントでは、対応するソケットをすぐに閉じます。 これは、接続のリリースが行われ、今後同じ TCP 接続での通信は失敗するという即時通知をエンドポイントに提供します。 ソケットが閉じられて接続が再確立されたら、TCP 接続が最終的にタイムアウトになるまで待つことなく、必要に応じてアプリケーションが接続を削除できます。
多くのシナリオでは、TCP リセットにより、フローのアイドル タイムアウトを更新するために TCP (またはアプリケーション層) キープアライブを送信する必要が減る場合があります。
アイドル状態の期間が構成上の制限を超えた場合、または TCP リセットが有効になっているアプリケーション望ましくない動作を示す場合、TCP 接続の存続性を監視するために、TCP キープアライブまたはアプリケーション層キープアライブを引き続き使用することが必要になる場合があります。 さらに、キープアライブは、接続がパスのどこかでプロキシされている場合にも引き続き役立ちます (特にアプリケーション レイヤー キープアライブ)。
エンド ツー エンドのシナリオ全体を慎重に調べることで、TCP リセットを有効にしてアイドル タイムアウトを調整することのベネフィットを判断できます。 次に、アプリケーションの望ましい動作を保証するために、さらなる手順が必要かどうかを判断します。
Azure Load Balancer には、Load Balancer 規則、アウトバウンド規則、インバウンド NAT 規則に対して 4 分から 100 分のタイムアウト範囲があります。
既定では 4 分に設定されています。 アイドル時間がタイムアウト値よりも長い場合、クライアントとクラウド サービス間の TCP または HTTP セッションが維持されるという保証はありません。
接続が閉じられると、クライアント アプリケーションは、次のエラー メッセージを受信する場合があります。"基になる接続が閉じられました: 維持される必要があった接続が、サーバーによって切断されました。"
一般的な方法として、TCP keep-alive を使用します。 この方法を使用すると、接続が長時間アクティブ状態に維持されます。 詳細については、こちらの .NET の例をご覧ください。 keep-alive を有効にすると、接続のアイドル時間にパケットが送信されます。 keep-alive パケットにより、アイドル タイムアウト値に達することがなくなり、接続が長時間維持されます。
設定は、着信接続に対してのみ有効です。 接続の切断を避けるためには、アイドル タイムアウト設定よりも小さい間隔で、TCP keep-alive を構成するか、アイドル タイムアウト値を大きくします。 これらのシナリオをサポートするために、構成可能なアイドル タイムアウトのサポートが追加されました。
TCP keep-alive は、バッテリーの寿命に制約がないシナリオに適しています。 モバイル アプリケーションでは推奨されません。 モバイル アプリケーションで TCP keep-alive を使用すると、デバイスのバッテリーの消耗を速める可能性があります。
さまざまな IP に対して設定されたアイドル タイムアウト値がどのように相互に作用する可能性があるかを考慮することは重要です。
- 参照するフロントエンド IP のアイドル タイムアウトとは異なるアイドル タイムアウト値が設定された (インバウンド) ロード バランサー規則がある場合、ロード バランサーのフロントエンド IP のアイドル タイムアウトが優先されます。
- 参照するフロントエンド IP のアイドル タイムアウトとは異なるアイドル タイムアウト値が設定されたインバウンド NAT 規則がある場合、ロード バランサーのフロントエンド IP のアイドル タイムアウトが優先されます。
- アイドル タイムアウト値が 4 分 (パブリック IP 送信アイドル タイムアウトがロックされている値) とは異なる送信規則がある場合、送信規則のアイドル タイムアウトが優先されます。
- NAT ゲートウェイはロード バランサーの送信規則 (および VM に直接割り当てられたパブリック IP アドレス) よりも常に優先されるため、NAT ゲートウェイに割り当てられたアイドル タイムアウト値が使用されます。 (同様の流れで、NAT GW に割り当てられた IP の 4 分というロックされたパブリック IP 送信アイドル タイムアウトは考慮されません)
- TCP リセットが送信されるのは、ESTABLISHED 状態の TCP 接続時のみです。
- TCP アイドル タイムアウトは、UDP プロトコルの負荷分散規則には影響しません。
- ネットワーク仮想アプライアンスがパス内にある場合、ILB HA ポートでは TCP のリセットはサポートされません。 これは、NVA からの TCP リセットでアウトバウンド規則を使用することで回避できます。