Time-out voor tcp opnieuw instellen en inactiviteit van load balancer

  • Artikel

U kunt Standard Load Balancer gebruiken om een beter voorspelbaar toepassingsgedrag voor uw scenario's te maken door TCP Reset in te schakelen voor inactiviteit voor een bepaalde regel. Het standaardgedrag van Load Balancer is om stromen op de achtergrond te verwijderen wanneer de time-out voor inactiviteit van een stroom wordt bereikt. Als u TCP opnieuw instellen inschakelt, verzendt Load Balancer bidirectionele TCP-resets (TCP RST-pakketten) bij time-out voor inactiviteit om uw toepassingseindpunten te informeren dat er een time-out optreedt voor de verbinding en niet meer bruikbaar is. Eindpunten kunnen zo nodig onmiddellijk een nieuwe verbinding tot stand brengen.

Diagram shows default TCP reset behavior of network nodes.

Opnieuw instellen van TCP

U wijzigt dit standaardgedrag en schakelt het verzenden van TCP-resets in op inkomende NAT-regels, taakverdelingsregels en uitgaande regels. Wanneer deze optie per regel is ingeschakeld, verzendt Load Balancer bidirectionele TCP-resets (TCP RST-pakketten) naar zowel client- als servereindpunten op het moment van time-out voor inactiviteit voor alle overeenkomende stromen.

Eindpunten die TCP RST-pakketten ontvangen, sluiten de bijbehorende socket onmiddellijk. Dit biedt een onmiddellijke melding voor de verbindingsrelease van het eindpunt en toekomstige communicatie op dezelfde TCP-verbinding mislukt. Toepassingen kunnen verbindingen opschonen wanneer de socket indien nodig wordt gesloten en opnieuw tot stand wordt gebracht zonder te wachten tot de TCP-verbinding uiteindelijk een time-out heeft.

Voor veel scenario's kan TCP-reset de noodzaak verminderen om TCP-keepalives (of toepassingslaag) te verzenden om de time-out voor inactiviteit van een stroom te vernieuwen.

Als uw niet-actieve duur de configuratielimieten overschrijdt of uw toepassing een ongewenst gedrag vertoont waarbij TCP-resets zijn ingeschakeld, kunt u nog steeds TCP-keepalives of toepassingslaag-keepalives gebruiken om de liveness van de TCP-verbindingen te bewaken. Bovendien kunnen keepalives ook nuttig blijven wanneer de verbinding ergens in het pad wordt geproxied, met name keepalives in de toepassingslaag.

Door het volledige end-to-endscenario zorgvuldig te onderzoeken, kunt u de voordelen bepalen van het inschakelen van TCP-resets en het aanpassen van de time-out voor inactiviteit. Vervolgens besluit u of er meer stappen nodig zijn om het gewenste toepassingsgedrag te garanderen.

Configureerbare time-out voor TCP-inactiviteit

Azure Load Balancer heeft een time-outbereik van 4 minuten tot 100 minuten voor load balancer-regels, uitgaande regels en binnenkomende NAT-regels. De standaardwaarde is 4 minuten. Als een periode van inactiviteit langer is dan de time-outwaarde, is er geen garantie dat de TCP- of HTTP-sessie wordt onderhouden tussen de client en uw cloudservice.

Wanneer de verbinding is gesloten, kan de clienttoepassing het volgende foutbericht ontvangen: 'De onderliggende verbinding is gesloten: een verbinding die naar verwachting actief blijft, is gesloten door de server.'

Een veelvoorkomende procedure is het gebruik van een TCP-keep-alive. Deze procedure houdt de verbinding gedurende een langere periode actief. Zie deze .NET-voorbeelden voor meer informatie. Als keep alive is ingeschakeld, worden pakketten verzonden tijdens perioden van inactiviteit op de verbinding. Keep-alive-pakketten zorgen ervoor dat de time-outwaarde voor inactiviteit niet wordt bereikt en dat de verbinding gedurende een lange periode wordt onderhouden.

De instelling werkt alleen voor binnenkomende verbindingen. Om te voorkomen dat de verbinding verloren gaat, configureert u de TCP-keep-alive met een interval dat kleiner is dan de time-outinstelling voor inactiviteit of verhoogt u de time-outwaarde voor inactiviteit. Ter ondersteuning van deze scenario's is ondersteuning beschikbaar voor een configureerbare time-out voor inactiviteit.

TCP keep-alive werkt voor scenario's waarbij de levensduur van de batterij geen beperking is. Het wordt niet aanbevolen voor mobiele toepassingen. Als u een TCP-keep-alive gebruikt in een mobiele toepassing, kan de batterij van het apparaat sneller leegmaken.

Volgorde van prioriteit

Het is belangrijk om rekening te houden met de manier waarop de time-outwaarden voor inactiviteit voor verschillende IP-adressen mogelijk kunnen communiceren.

Inkomend

  • Als er een (inkomende) load balancer-regel is met een niet-actieve time-outwaarde die anders is ingesteld dan de time-out voor inactiviteit van het front-end-IP-adres waarnaar wordt verwezen, heeft de time-out voor inactiviteit van de load balancer prioriteit.
  • Als er een binnenkomende NAT-regel is met een niet-actieve time-outwaarde die anders is ingesteld dan de time-out voor inactiviteit van het front-end-IP-adres waarnaar wordt verwezen, heeft de time-out van de front-end-IP van de load balancer prioriteit.

Uitgaand

  • Als er een uitgaande regel is met een niet-actieve time-outwaarde anders dan 4 minuten (dit is wat een time-out voor uitgaand uitgaand verkeer via openbaar IP-verkeer is vergrendeld), heeft de time-out voor inactiviteit van de uitgaande regel voorrang.
  • Omdat een NAT-gateway altijd voorrang krijgt op uitgaande load balancer-regels (en via openbare IP-adressen die rechtstreeks aan VM's zijn toegewezen), wordt de time-outwaarde voor inactiviteit die aan de NAT-gateway is toegewezen, gebruikt. (Langs dezelfde regels worden de vergrendelde time-outs voor uitgaande uitgaande IP-adressen van 4 minuten van eventuele IP-adressen die zijn toegewezen aan de NAT GW niet overwogen.)

Beperkingen

  • TCP reset alleen verzonden tijdens TCP-verbinding met DE STATUS ESTABLISHED.
  • Time-out voor inactiviteit van TCP heeft geen invloed op taakverdelingsregels in het UDP-protocol.
  • TCP-reset wordt niet ondersteund voor ILB HA-poorten wanneer een virtueel netwerkapparaat zich in het pad bevindt. Een tijdelijke oplossing is het gebruik van een uitgaande regel met TCP-reset vanuit NVA.

Volgende stappen