Reposição de TCP do Balanceador de Carga e Tempo Limite de Inatividade

  • Artigo

Você pode usar o Balanceador de Carga Padrão para criar um comportamento de aplicativo mais previsível para seus cenários, habilitando a Redefinição de TCP em Ocioso para uma determinada regra. O comportamento padrão do Load Balancer é soltar fluxos silenciosamente quando o tempo limite ocioso de um fluxo é atingido. Habilitar a redefinição de TCP faz com que o Load Balancer envie redefinições TCP bidirecionais (pacotes TCP RST) no tempo limite ocioso para informar os pontos de extremidade do aplicativo de que a conexão atingiu o tempo limite e não é mais utilizável. Os pontos de extremidade podem estabelecer imediatamente uma nova conexão, se necessário.

Diagram shows default TCP reset behavior of network nodes.

Redefinição de TCP

Você altera esse comportamento padrão e habilita o envio de redefinições de TCP no tempo limite ocioso em regras NAT de entrada, regras de balanceamento de carga e regras de saída. Quando ativado por regra, o Balanceador de Carga envia Redefinições TCP bidirecionais (pacotes TCP RST) para pontos de extremidade cliente e servidor no momento do tempo limite ocioso para todos os fluxos correspondentes.

Os pontos de extremidade que recebem pacotes TCP RST fecham o soquete correspondente imediatamente. Isso fornece uma notificação imediata para a liberação de conexão do ponto de extremidade e qualquer comunicação futura na mesma conexão TCP falhará. Os aplicativos podem limpar conexões quando o soquete fecha e restabelecer conexões conforme necessário sem esperar que a conexão TCP atinja o tempo limite.

Para muitos cenários, a redefinição de TCP pode reduzir a necessidade de enviar keepalives TCP (ou camada de aplicativo) para atualizar o tempo limite ocioso de um fluxo.

Se as durações ociosas excederem os limites de configuração ou se seu aplicativo mostrar um comportamento indesejável com Redefinições TCP habilitadas, você ainda poderá precisar usar keepaplives TCP ou keepalives da camada de aplicativo para monitorar a vida útil das conexões TCP. Além disso, keepalives também podem permanecer úteis para quando a conexão é proxy em algum lugar no caminho, particularmente keepalives da camada de aplicação.

Ao examinar cuidadosamente todo o cenário de ponta a ponta, você pode determinar os benefícios de habilitar redefinições de TCP e ajustar o tempo limite ocioso. Em seguida, você decide se mais etapas podem ser necessárias para garantir o comportamento desejado do aplicativo.

Tempo limite de inatividade TCP configurável

O Balanceador de Carga do Azure tem um intervalo de tempo limite de 4 minutos a 100 minutos para regras do Balanceador de Carga, Regras de Saída e regras de NAT de Entrada. O padrão é 4 minutos. Se um período de inatividade for maior do que o valor de tempo limite, não há garantia de que a sessão TCP ou HTTP seja mantida entre o cliente e seu serviço de nuvem.

Quando a conexão é fechada, seu aplicativo cliente pode receber a seguinte mensagem de erro: "A conexão subjacente foi fechada: uma conexão que se esperava que fosse mantida ativa foi fechada pelo servidor."

Uma prática comum é usar um TCP keep-alive. Essa prática mantém a conexão ativa por um período mais longo. Para obter mais informações, consulte estes exemplos do .NET. Com o keep-alive ativado, os pacotes são enviados durante os períodos de inatividade na conexão. Os pacotes Keep-alive garantem que o valor de tempo limite ocioso não seja atingido e que a conexão seja mantida por um longo período.

A configuração funciona apenas para conexões de entrada. Para evitar perder a conexão, configure o keep-alive TCP com um intervalo menor que a configuração de tempo limite ocioso ou aumente o valor de tempo limite ocioso. Para dar suporte a esses cenários, o suporte para um tempo limite ocioso configurável está disponível.

O TCP keep-alive funciona para cenários em que a duração da bateria não é uma restrição. Não é recomendado para aplicações móveis. Usar um keep-alive TCP em um aplicativo móvel pode drenar a bateria do dispositivo mais rapidamente.

Ordem de precedência

É importante levar em conta como os valores de tempo limite ocioso definidos para diferentes IPs podem potencialmente interagir.

Interna

  • Se houver uma regra de balanceador de carga (de entrada) com um valor de tempo limite ocioso definido de forma diferente do tempo limite ocioso do IP de front-end a que ele faz referência, o tempo limite de inatividade do IP de front-end do balanceador de carga terá precedência.
  • Se houver uma regra NAT de entrada com um valor de tempo limite ocioso definido de forma diferente do tempo limite de ociosidade do IP de front-end a que faz referência, o tempo limite de inatividade do IP de front-end do balanceador de carga terá precedência.

De Saída

  • Se houver uma regra de saída com um valor de tempo limite ocioso diferente de 4 minutos (que é o tempo limite de ocioso de saída de IP público bloqueado), o tempo limite de ociosidade da regra de saída terá precedência.
  • Como um gateway NAT sempre terá precedência sobre as regras de saída do balanceador de carga (e sobre os endereços IP públicos atribuídos diretamente às VMs), o valor de tempo limite ocioso atribuído ao gateway NAT será usado. (Na mesma linha, os tempos limite de inatividade de IP público bloqueado de 4 minutos de quaisquer IPs atribuídos ao NAT GW não são considerados.)

Limitações

  • Reposição de TCP apenas enviada durante a ligação TCP no estado ESTABELECIDO.
  • O tempo limite de inatividade do TCP não afeta as regras de balanceamento de carga no protocolo UDP.
  • A redefinição de TCP não é suportada para portas ILB HA quando um dispositivo virtual de rede está no caminho. Uma solução alternativa pode ser usar a regra de saída com redefinição de TCP do NVA.

Próximos passos