Redefinição do TCP do Load Balancer e tempo limite ocioso

  • Artigo

Você pode usar o Standard Load Balancer para criar um comportamento de aplicativo mais previsível para seus cenários, permitindo a Redefinição de TCP no modo ocioso para uma determinada regra. O comportamento de padrão do Load Balancer é remover fluxos silenciosamente quando o tempo limite de ociosidade de um fluxo for 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) em tempo limite ocioso para informar aos pontos de extremidade do aplicativo que a conexão atingiu o tempo limite e não é mais utilizável. Pontos de extremidade podem estabelecer imediatamente uma nova conexão se necessário.

Diagrama que mostra o comportamento de redefinição de TCP padrão de nós de rede.

Redefinição de TCP

Alterar esse comportamento padrão e habilitar envio de Redefinições de TCP no tempo limite de ociosidade 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 de TCP bidirecionais (pacotes TCP RST) para os pontos de extremidade do cliente e do servidor no momento do tempo limite ocioso para todos os fluxos correspondentes.

Os pontos de extremidade que recebem pacotes de redefinição de TCP fecham imediatamente o soquete correspondente. Isso fornece uma notificação imediata para os pontos de extremidade que a liberação da conexão ocorreu e qualquer comunicação futura na mesma conexão TCP falhará. Aplicativos podem limpar conexões quando o soquete é fechado e restabelecer as conexões conforme necessário, sem esperar o tempo limite eventual da conexão TCP.

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

Se as durações ociosas excederem os limites de configuração ou seu aplicativo apresentar um comportamento indesejado com Redefinições de TCP habilitadas, você ainda precisará usar keepalives de TCP, ou keepalives da camada de aplicativo, para monitorar a atividade das conexões TCP. Além disso, keepalives também podem ser úteis para quando a conexão é transmitida com proxy em algum lugar no caminho, particularmente em keepalives de camada de aplicativo.

Examinando 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 ociosidade de TCP configurável

O Azure Load Balancer Standard tem um intervalo de tempo limite de 4 a 100 minutos para regras do 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 que o valor de tempo limite, não haverá nenhuma garantia de que a sessão TCP ou HTTP seja mantida entre o cliente e o 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 deveria ser mantida ativa foi fechada pelo servidor".

Se as redefinições de TCP estiverem habilitadas e forem perdidas por qualquer motivo, ela será redefinida para quaisquer pacotes subsequentes. Se a opção de redefinição de TCP não estiver habilitada, 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 maior. Para obter mais informações, consulte estes exemplos do .NET. Com o keep alive habilitado, 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 de ociosidade não será atingido, e a conexão será mantida por um longo período.

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

O TCP keep-alive funciona para cenários em que a vida útil da bateria não é uma restrição. Não é recomendável para aplicativos móveis. Usar o TCP keep alive em um aplicativo móvel pode consumir 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 interagir.

Entrada

  • Se houver uma regra do 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 ao qual ela faz referência, o tempo limite ocioso 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 ocioso do IP de front-end ao qual ela faz referência, o tempo limite ocioso do IP de front-end do balanceador de carga terá precedência.

Saída

  • Se houver uma regra de saída com um valor de tempo limite ocioso diferente de 4 minutos (que é o tempo limite ocioso de saída de IP bloqueado), o tempo limite ocioso 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 ociosos de saída de IPs bloqueados de 4 minutos de quaisquer IPs atribuídos ao NAT GW não são considerados.)

Limitações

  • Redefinição do TCP enviada apenas durante a conexão TCP no estado ESTABELECIDO.
  • O tempo limite ocioso de TCP não afeta as regras de balanceamento de carga no protocolo UDP.
  • Não há suporte para a redefinição de TCP para portas HA do Load Balancer Interno quando uma solução de virtualização de rede está no caminho. Uma solução alternativa seria usar a regra de saída com a redefinição de TCP da Solução de Virtualização de Rede.

Próximas etapas