Load Balancer の TCP リセットおよびアイドルのタイムアウト

  • [アーティクル]

Standard Load Balancer を使用して、特定の規則のアイドル時の TCP リセットを有効にすることにより、シナリオのより予測可能なアプリケーション動作を作成します。 ロード バランサーの既定の動作では、フローのアイドル タイムアウトに達したときに、警告なしでフローを削除します。 TCP リセットを有効にすると、Load Balancer によりアイドル タイムアウト時に双方向 TCP リセット (TCP RST パケット) が送信され、接続がタイムアウトし、使用できなくなったことがアプリケーション エンドポイントに通知されます。 エンドポイントは、必要に応じて直ちに新しい接続を確立できます。

Diagram shows default TCP reset behavior of network nodes.

TCP リセット

この既定の動作は変更でき、受信 NAT 規則、負荷分散規則、送信規則に基づいて、アイドル タイムアウト時の TCP リセットの送信を有効にできます。 規則ごとに有効にすると、Load Balancer により、双方向 TCP リセット (TCP RST パケット) が、クライアントとサーバーの両方のエンドポイントに対して、一致するすべてのフローのアイドル タイムアウト時に送信されます。

TCP RST パケットを受信するエンドポイントでは、対応するソケットをすぐに閉じます。 これにより、エンドポイントの接続の解放の即時通知が提供され、同じ TCP 接続での今後の通信は失敗します。 ソケットが閉じられて接続が再確立されたら、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 リセットでアウトバウンド規則を使用することで回避できます。

次の手順