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 Balanceador de Carga envie redefinições de TCP bidirecionais (pacotes de redefinição de TCP) no tempo limite de ociosidade 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.

O diagrama mostra o comportamento padrão de redefinição de TCP dos nós de rede.

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 de descanso TCP 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 Azure Load Balancer Standard tem um intervalo de tempo limite de 4 minutos a 100 minutos para regras de balanceador de carga, regras de saída e regras 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. O Azure Load Balancer Basic tem um intervalo de tempo limite de até 30 minutos.

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."

Se as redefinições de TCP estiverem habilitadas e forem perdidas por qualquer motivo, serão redefinidas para quaisquer pacotes subsequentes. Se a opção de redefinição de TCP não estiver ativada, os pacotes serão descartados silenciosamente.

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.
  • Não há suporte para redefinição de TCP para portas HA do Balanceador de Carga Interno 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 Network Virtual Appliance.

Próximos passos