TCP-Zurücksetzung und Leerlauftimeout für Load Balancer

  • Artikel

Sie können Load Balancer Standard verwenden, um ein besser vorhersagbares Anwendungsverhalten für Ihre Szenarien zu erzielen, indem Sie für eine bestimmte Regel die TCP-Rücksetzung bei Leerlauf aktivieren. Das Standardverhalten von Load Balancer besteht darin, Flows ohne Rückmeldung zu verwerfen, wenn das Leerlauftimeout eines Flows erreicht ist. Durch Aktivieren der TCP-Zurücksetzung wird der Load Balancer dazu veranlasst, bidirektionale TCP-Zurücksetzungen (TCP RST-Pakete) bei Leerlauftimeout zu senden, um Ihre Anwendungsendpunkte darüber zu informieren, dass während der Verbindung ein Timeout aufgetreten ist und sie nicht mehr verwendet werden kann. Die Endpunkte können dann bei Bedarf sofort eine neue Verbindung herstellen.

Diagram shows default TCP reset behavior of network nodes.

TCP-Zurücksetzung

Sie ändern dieses Standardverhalten und ermöglichen das Senden von TCP-Rücksetzungen bei Leerlauftimeout in NAT-Eingangsregeln, Lastenausgleichsregeln und Ausgangsregeln. Wenn dies durch eine Regel aktiviert ist, sendet Load Balancer zum Zeitpunkt des Leerlauftimeouts für alle passenden Flows bidirektionale TCP-Rücksetzungen (TCP-RST-Pakete) sowohl an den Client- als auch an den Serverendpunkt.

Endpunkte, die TCP-RST-Pakete empfangen, schließen den entsprechenden Socket sofort. Damit werden Endpunkte sofort darüber benachrichtigt, dass die Verbindung getrennt wurde und jegliche weitere Kommunikation über die gleiche TCP-Verbindung zu einem Fehler führt. Anwendungen können Verbindungen bereinigen, wenn der Socket geschlossen wird, und Verbindungen bei Bedarf ohne Berücksichtigung des Timeouts der TCP-Verbindung erneut herstellen.

In vielen Szenarios müssen mit der TCP-Rücksetzung weniger TCP-Keepalives (bzw. Keepalives auf der Anwendungsschicht) gesendet werden, um das Leerlauftimeout eines Flows zu aktualisieren.

Wenn die Leerlaufzeiträume die Konfigurationsgrenzwerte überschreiten oder Ihre Anwendung mit aktivierten TCP-Rücksetzungen ein unerwünschtes Verhalten zeigt, können Sie diese TCP-Keepalives (bzw. Keepalives auf der Anwendungsschicht) weiterhin verwenden, um die Verfügbarkeit der TCP-Verbindungen zu überwachen. Keepalives (insbesondere Keepalives auf der Anwendungsschicht) sind zudem weiterhin nützlich, wenn eine Verbindung an irgendeiner Stelle im Pfad über einen Proxy geleitet wird.

Durch sorgfältige Überprüfung des gesamten Szenarios können Sie die Vorteile der Aktivierung von TCP-Rücksetzungen und der Anpassung des Leerlauftimeouts ermitteln. So können Sie entscheiden, ob weitere Schritte erforderlich sind, um das gewünschte Anwendungsverhalten sicherzustellen.

Konfigurierbares TCP-Leerlauftimeout

Azure Load Balancer verfügt über einen Timeoutbereich von 4 Minuten bis 100 Minuten für Load Balancer-Regeln, Ausgangsregeln und NAT-Regeln für eingehenden Datenverkehr. Der Standardwert beträgt 4 Minuten. Wenn die Dauer einer Inaktivitätsperiode den Timeoutwert überschreitet, gibt es keine Garantie dafür, dass die TCP- oder HTTP-Sitzung zwischen dem Client und Ihrem Clouddienst aufrechterhalten wird.

Wenn die Verbindung geschlossen wird, erscheint in der Clientanwendung unter Umständen eine Fehlermeldung wie die folgende: „Die zugrunde liegende Verbindung wurde geschlossen: Eine Verbindung, deren Aufrechterhaltung erwartet wurde, ist vom Server geschlossen worden.“

Eine gängige Methode zur Aufrechterhaltung von Verbindungen ist TCP-Keep-Alive. Dadurch bleibt die Verbindung länger aktiv. Weitere Informationen finden Sie in diesen .NET-Beispielen. Bei aktivierter Keep-Alive-Funktion werden während inaktiver Phasen Pakete über die Verbindung gesendet. Keep-Alive-Pakete sorgen dafür, dass der Wert für das Leerlauftimeout nicht erreicht und die Verbindung über einen langen Zeitraum aufrechterhalten wird.

Die Einstellung funktioniert nur für eingehende Verbindungen. Um den Verlust der Verbindung zu vermeiden, konfigurieren Sie ein TCP-Keep-Alive-Intervall, das kürzer ist als das Leerlauftimeout, oder erhöhen Sie den Leerlauftimeout-Wert. Für diese Szenarios ist Unterstützung für konfigurierbare Leerlauftimeouts verfügbar.

TCP-Keep-Alive eignet sich für Szenarien, in denen die Akkulaufzeit keine Einschränkung darstellt. Bei mobilen Anwendungen ist die Verwendung dieser Funktion hingegen nicht empfehlenswert. TCP-Keep-Alive kann bei mobilen Anwendungen zu einer schnelleren Entladung des Geräteakkus führen.

Rangfolge

Es ist wichtig zu berücksichtigen, wie sich die für verschiedene IP-Adressen festgelegten Leerlauftimeoutwerte möglicherweise gegenseitig beeinflussen können.

Eingehend

  • Wenn eine (eingehende) Lastenausgleichsregel vorhanden ist, deren Leerlauftimeout auf einen anderen Wert als das Leerlauftimeout der Front-End-IP-Adresse, auf die verwiesen wird, festgelegt ist, hat das Leerlauftimeout der Front-End-IP-Adresse des Lastenausgleichs Vorrang.
  • Wenn eine NAT-Regel für eingehenden Datenverkehr vorhanden ist, deren Leerlauftimeout auf einen anderen Wert als das Leerlauftimeout der Front-End-IP-Adresse, auf die verwiesen wird, festgelegt ist, hat das Leerlauftimeout des der Front-End-IP-Adresse des Lastenausgleichs Vorrang.

Ausgehend

  • Wenn es eine Ausgangsregel mit einem Leerlauftimeoutwert gibt, der nicht 4 Minuten ist (Timeout für ausgehende öffentliche IP-Adressen im Leerlauf), hat das Leerlauftimeout der Ausgangsregel Vorrang.
  • Da ein NAT-Gateway immer Vorrang vor Ausgangsregeln für den Lastenausgleich hat (und vor öffentlichen IP-Adressen, die VMs direkt zugewiesen sind), wird der Leerlauftimeoutwert verwendet, der dem NAT-Gateway zugewiesen ist. (Ebenso wird der Timeoutwert für öffentliche IP-Adressen im Leerlauf von 4 Minuten für alle IP-Adressen, die dem NAT-Gateway zugewiesen sind, nicht berücksichtigt.)

Begrenzungen

  • TCP-Zurücksetzung wird nur während der TCP-Verbindung im Status ESTABLISHED gesendet.
  • Das TCP-Leerlauftimeout wirkt sich nicht auf die Lastenausgleichsregeln des UDP-Protokolls aus.
  • Die TCP-Rücksetzung wird für ILB-Hochverfügbarkeitsports nicht unterstützt, wenn sich ein virtuelles Netzwerkgerät im Pfad befindet. Eine Problemumgehung könnte sein, eine Ausgangsregel mit TCP-Zurücksetzung von NVA zu verwenden.

Nächste Schritte