TCP-återställning och timeout för lastbalanserare

  • Artikel

Du kan använda Standard Load Balancer för att skapa ett mer förutsägbart programbeteende för dina scenarier genom att aktivera TCP-återställning vid inaktivitet för en viss regel. Load Balancers standardbeteende är att tyst släppa flöden när tidsgränsen för inaktivt flöde uppnås. Aktivering av TCP-återställning gör att Load Balancer skickar dubbelriktade TCP-återställningar (TCP RST-paket) vid tidsgränsen för inaktivitet för att informera programslutpunkterna om att anslutningen uppnådde tidsgränsen och inte längre kan användas. Slutpunkter kan omedelbart upprätta en ny anslutning om det behövs.

Diagram shows default TCP reset behavior of network nodes.

TCP-återställning

Du ändrar det här standardbeteendet och aktiverar sändning av TCP-återställningar vid inaktiv timeout för inkommande NAT-regler, belastningsutjämningsregler och regler för utgående trafik. När det är aktiverat per regel skickar Load Balancer dubbelriktade TCP-återställningar (TCP RST-paket) till både klient- och serverslutpunkter vid tidpunkten för tidsgränsen för inaktivitet för alla matchande flöden.

Slutpunkter som tar emot TCP RST-paket stänger motsvarande socket omedelbart. Detta ger ett omedelbart meddelande till slutpunktens anslutningsversion och all framtida kommunikation om samma TCP-anslutning misslyckas. Program kan rensa anslutningar när socketen stängs och återupprätta anslutningar efter behov utan att vänta på att TCP-anslutningen så småningom ska överskrida tidsgränsen.

I många scenarier kan TCP-återställning minska behovet av att skicka TCP-keepalives (eller programskikt) för att uppdatera tidsgränsen för inaktivitet för ett flöde.

Om dina inaktiva varaktigheter överskrider konfigurationsgränserna eller om programmet visar ett oönskat beteende med TCP-återställningar aktiverade, kan du fortfarande behöva använda TCP keepalives, eller programlager keepalives, för att övervaka TCP-anslutningarnas livslängd. Dessutom kan keepalives också vara användbara för när anslutningen är proxied någonstans i sökvägen, särskilt programlager keepalives.

Genom att noggrant undersöka hela scenariot från slutpunkt till slutpunkt kan du fastställa fördelarna med att aktivera TCP-återställningar och justera tidsgränsen för inaktivitet. Sedan bestämmer du om fler steg kan krävas för att säkerställa önskat programbeteende.

Konfigurerbar tidsgräns för TCP-inaktivitet

Azure Load Balancer har ett tidsgränsintervall på 4 minuter till 100 minuter för Regler för lastbalanserare, utgående regler och inkommande NAT-regler. Standardvärdet är 4 minuter. Om en period av inaktivitet är längre än tidsgränsvärdet finns det ingen garanti för att TCP- eller HTTP-sessionen underhålls mellan klienten och molntjänsten.

När anslutningen stängs kan klientprogrammet få följande felmeddelande: "Den underliggande anslutningen stängdes: En anslutning som förväntades hållas vid liv stängdes av servern."

En vanlig metod är att använda en TCP keep-alive. Den här metoden håller anslutningen aktiv under en längre period. Mer information finns i dessa .NET-exempel. Med keep-alive aktiverat skickas paket under perioder av inaktivitet på anslutningen. Keep-alive-paket säkerställer att tidsgränsvärdet för inaktivitet inte nås och att anslutningen upprätthålls under en längre period.

Inställningen fungerar endast för inkommande anslutningar. Om du vill undvika att förlora anslutningen konfigurerar du TCP keep-alive med ett intervall som är mindre än tidsgränsinställningen för inaktivitet eller ökar tidsgränsvärdet för inaktivitet. För att stödja dessa scenarier finns stöd för en konfigurerbar tidsgräns för inaktivitet tillgänglig.

TCP keep-alive fungerar för scenarier där batteritiden inte är en begränsning. Det rekommenderas inte för mobila program. Om du använder en TCP keep-alive i ett mobilprogram kan enhetens batteri tömmas snabbare.

Prioritetsordning

Det är viktigt att ta hänsyn till hur timeoutvärdena för inaktivitet som angetts för olika IP-adresser potentiellt kan interagera.

Inkommande

  • Om det finns en (inkommande) lastbalanserare med ett inaktivt timeout-värde som är annorlunda än tidsgränsen för inaktivitet för klientdels-IP-adressen som den refererar till, prioriteras tidsgränsen för lastbalanserarens ip-inaktiva IP-inaktiva klientdel.
  • Om det finns en inkommande NAT-regel med ett inaktivt timeout-värde på ett annat sätt än tidsgränsen för inaktivitet för klientdels-IP-adressen som den refererar till, prioriteras tidsgränsen för lastbalanserarens IP-inaktiva IP-inaktivitet.

Utgående

  • Om det finns en utgående regel med ett timeoutvärde för inaktivitet som skiljer sig från 4 minuter (vilket är vad den offentliga tidsgränsen för utgående IP-inaktivitet är låst vid) prioriteras tidsgränsen för utgående regelinaktivering.
  • Eftersom en NAT-gateway alltid har företräde framför regler för utgående lastbalanserare (och över offentliga IP-adresser som tilldelats direkt till virtuella datorer) används det timeout-värde för inaktivitet som tilldelats NAT-gatewayen. (På samma sätt beaktas inte den låsta offentliga IP-tidsgränsen för utgående inaktivitet på 4 minuter av ip-adresser som tilldelats NAT GW.)

Begränsningar

  • TCP-återställning skickas endast under TCP-anslutning i ETABLERAT tillstånd.
  • Tidsgränsen för TCP-inaktivitet påverkar inte belastningsutjämningsregler i UDP-protokollet.
  • TCP-återställning stöds inte för ILB HA-portar när en virtuell nätverksinstallation är i sökvägen. En lösning kan vara att använda utgående regel med TCP-återställning från NVA.

Nästa steg