IPvsadm não balanceando igualmente no agendador wlc

Question

Por alguma razão, o ipvsadm não parece estar equilibrando as conexões entre meus servidores reais ao usar os escalonadores wlc ou lc. Um servidor real recebe absolutamente pedidos, enquanto os outros recebem relativamente poucas conexões.

Meu arquivo ldirectord.cf tem esta aparência:

quiescent     = yes
autoreload    = yes
checktimeout  = 10
checkinterval = 10

# *.example.com http
virtual = 192.0.2.111:http
    real = 10.10.10.1:http  ipip    10
    real = 10.10.10.2:http  ipip    10
    real = 10.10.10.3:http  ipip    10
    real = 10.10.10.4:http  ipip    10
    real = 10.10.10.5:http  ipip    10
    scheduler = lc
    protocol = tcp
    service = http
    checktype = negotiate
    request = "/lb"
    receive = "Up and running"
    virtualhost = "site.com"
    fallback = 127.0.0.1:http

A coisa estranha que eu acho que esteja causando o problema (mas eu não tenho certeza) é que o ipvsadm não parece estar rastreando as conexões ativas corretamente, todas elas aparecem como conexões inativas

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn    
TCP  192.0.2.111:http lc
  -> 10.10.10.1:http              Tunnel  10     0          10        
  -> 10.10.10.2:http              Tunnel  10     0          18        
  -> 10.10.10.3:http              Tunnel  10     0          3         
  -> 10.10.10.4:http              Tunnel  10     0          10        
  -> 10.10.10.5:http              Tunnel  10     0          5

Se eu fizer ipvsadm -Lnc , vejo muitas conexões, mas somente em ESTABLISHED & Estados FIN_WAIT.

Eu estava usando o ldirectord anteriormente em um balanceador de carga baseado no Gentoo e o ativamento costumava ser preciso, já que mudar para o Ubuntu 10.4 LTS parece ser algo diferente.

# ipvsadm -v
ipvsadm v1.25 2008/5/15 (compiled with popt and IPVS v1.2.1)

Portanto, o ipvsadm não está rastreando as conexões ativas corretamente e, portanto, fazendo o balanceamento de carga funcionar incorretamente e, em caso afirmativo, como faço para que ele funcione corretamente novamente?

Editar: É mais estranho, se eu cat /proc/net/ip_vs , parece que as configurações ativas corretas estão lá:

IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP  C000026F:0050 rr 
  -> 0AB42453:0050      Tunnel  10     1          24        
  -> 0AB4321D:0050      Tunnel  10     0          23        
  -> 0AB426B2:0050      Tunnel  10     2          25        
  -> 0AB4244C:0050      Tunnel  10     2          22        
  -> 0AB42024:0050      Tunnel  10     2          23

    

Answer 1

Com lc (menos conexão) se todos os servidores tiverem o mesmo número de conexões, sempre dará uma nova conexão ao primeiro servidor da lista. Isso pode significar que, se você tiver uma utilização muito baixa e apenas uma conexão de vez em quando, essa conexão sempre irá para o primeiro host na lista.

    

Answer 2

Meu favorito é wrr (weigthed round robin). Estou certo em assumir que você está usando a abordagem DR (roteamento direto)?

Nesse caso, o ipvsadm não vê a conexão como tal, já que a resposta do RS (servidor real) irá diretamente para o cliente - não para o LB.

    

Answer 3

A julgar pelo seu número de conexões, provavelmente não é um problema para você, mas você pode obter distribuição desigual com menos conexões se um dos servidores reais estiver respondendo mais devagar que os outros, receberão menos novas conexões por hora que os outros como se empilha em conexões mais rapidamente.

    

Answer 4

As saídas de comando de David indicam que ele está usando o modo de túnel (IPIP), que geralmente é configurado como uma variante do DR. Precisamos ver algumas tabelas de roteamento ou diagramas para entender melhor sua configuração.

Mas eu concordo que provavelmente o rastreamento de conexão no LVS é confuso, já que ele não vê os pacotes TCP FIN.

O ipvsadm tem algumas configurações para tempo limite das conexões expiradas mais rapidamente. Por exemplo, o comando a seguir esgotará o tempo limite das conexões inativas após 1 hora:

/sbin/ipvsadm --set 3600 120 300

A origem dos clientes deve ser verificada novamente. O comportamento padrão do LVS é fazer conexões persistentes pelo IP do cliente. Então, se o teste de estresse com wget ou ab do mesmo IP do cliente de teste, todas as conexões serão enviadas para o mesmo servidor real.

O Haproxy é um balanceador de carga mais inteligente, mas precisa se sentar no caminho de retorno dos pacotes para funcionar de forma totalmente transparente.