ACE Sticky Connections, Show Conn Output and Show serverfarm

[Plinio Brandao]

Olá comunidade,

Estou implementando um Cisco ACE e surgiram algumas dúvidas relacionadas ao recurso do sticky e dos comandos show conn e show serverfarm.

Eu possuo a seguinte configuração:

rserver host srv_1
  ip address 10.4.11.14
  inservice
rserver host srv_2
  ip address 10.4.11.18
  inservice
serverfarm host farm_144
  rserver srv_1 144
    weight 1
    inservice
  rserver srv_2 144
    weight 3
    inservice
sticky ip-netmask 255.255.255.255 address source st_host144
  timeout 10080
  serverfarm farm_144
class-map match-all vip_144
  2 match virtual-address 10.4.11.208 tcp eq 143
policy-map type loadbalance first-match lb_144
  class class-default
policy-map multi-match policy_vip_webcache
  class vip_webcache_144
    loadbalance vip inservice
    loadbalance policy lb_144
    loadbalance vip icmp-reply active
    nat dynamic 411 vlan 411

Podemos assumar que a service policy foi aplicada corretamente na interface vlan. Vamos as perguntas!

1- Se o sticky está habilitado, na saída do comando "show conn" não deveria ser mostrado apenas 1 entrada para cada endereço IP relacionado a cada VIP?

A saída atual é a seguinte:

DC01-ACE-01-PRIMARY-SW1/context_servidores# show conn | inc :143
333046     1  in  TCP   411  10.2.158.87:3616      10.4.11.208:143       ESTAB 
286390     3  in  TCP   411  10.2.158.87:3562      10.4.11.208:143       ESTAB
310233     1  in  TCP   411  10.1.5.87:3424        10.4.11.208:143       ESTAB

Observer que o IP 10.2.158;87 aparece 2 vezes. Em alguns momentos, ele chega a aparecer até 4 vezes para o mesmo VIP e para a mesma porta. Isso é normal? Com o sticky a quantidade de conexões não deveria ser reduzida?

2- De acordo com a configuração, o rserver srv_2 tem peso 3 e o srv_1 tem peso 1, mas a saída do comando "show severfarm" mostra algo estranho:

DC01-ACE-01-PRIMARY-SW1/context_servidores# show serverfarm farm_144
 serverfarm     : farm_144, type: HOST
 total rservers : 2
 state          : ACTIVE
 DWS state      : DISABLED
 ---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total      failures 
   ---+---------------------+------+------------+----------+----------+---------
   rserver: srv_1
       10.4.11.14:144        1   OPERATIONAL     11         386        0
   rserver: srv_2
       10.4.11.18:144        3   OPERATIONAL     35         66         0

Podemos ver que o balanceamento/peso está funcionado de forma correta. Entretanto, o número total de conexões no servidor srv_1 está muito maior. O que poderia estar causando isso?

Aguardo um retorno de vocês. Se precisarem de maiores informações, favor avisar.

Agrandeço desde já.

A mensagem foi editada por: Plinio Brandao

[Ruben Cocheno]

Viva,

A função de sticky é fazer com que os pedidos subsequentes sejam enviados para o mesmo server balanceado. As ligações existentes é normal, uma vez que são abertos diversos "pipes" ter acesso á aplicação.

Uma vez que foram definidos Pesos (Weight) diferentes para cada servidor, existirá sempre uma diferença no número total de ligações a cada um destes. Os Pesos podem variar de 1 a 100(Máx) , sendo que o valor superior tem maior prioridade, ou seja, recebe mais pedidos.

Limpa os contadores através do comando clear stats conn e observa.

Deixo-te um DocWiki da Cisco sobre Cisco ACE muito interessante.

http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_%28ACE%29_Troubleshooting_Guide

[Plinio Brandao]

Ruben,

Obrigado pelo retorno.

Com relação ao sticky ficou claro. Agora com relação aos servidores, se você observar, o que está recebendo um maior número de conexões é o que está com o menor peso e não com o maior. Isso eu não estou conseguindo entender.

Alguma sugestão sobre essa diferença?

Obrigado.

[Pedro Ivo Santos Mauri]

Olá Plinio,

Como comentado pelo Ruben, o "stickiness" é um recurso do ACE para garantir de determinada sessão seja encaminhada sempre para o mesmo REAL SERVER, enquanto durar essa sessão. A intenção não é reduzir o número de conexões e sim garantir de sessões que dependam de informações locais dos servidores (como o shopping cart de um site e-commerce) não sejam encaminhadas sempre a esse mesmo servidor.

Desta maneira, é absolutamente normal ter várias conexões no output do "show conn". A diferença é que aquelas conexões, que antes poderia ser distribuídas entre vários servidores do seu server farm, agora serão encaminhadas sempre para o mesmo sevirdor (reforçando que isso vale para a duração da sessão).

Quanto ao output do show serverfarm, especificamente o contador "total", trata-se de uma contagem total de conexões recebidas por este servidor. Dependendo de quando o server farm foi habilitado e de quando "stickiness" foi habilitado pode-se gerar essa discrepância. Outro fator que pode influenciar é a duração das sessões, já o critério para se balancear é o "current connections". Se uma determinada sessão dura muito tempo em um servidor, enquanto outras 3 são iniciadas e encerradas em outro servidor, o balanceamento será influenciado por isso. Esse contador não precisa necessariamente refletir os pesos de cada real server. O "current connection" é o contador que deve refletir essa distribuição.

Espero ter sido claro em minhas colocações.

Abraços,

Pedro

[Plinio Brandao]

Pedro, bom dia!

Obrigado pelo retorno. As informações ficaram claras sim.

Apenas um questionamento, o TCP Reuse é um recurso apenas para solicitações HTTP, correto? Ou existe alguma forma de otimizar as conexões TCP para um servidor?

Pergunto isso, porque no meu cenário atual, tenho diversos clientes que usam outlook com um "connector" para IMAP e cada cliente está abrindo, normalmente, 3 a 4 conexões TCP para o ACE, consequentemente para o servidor. Existem hoje 2 servidores e um total de quase 2.8k conexões e isso está gerando impacto no módulo de imap.

Segundo o cliente, isso não acontecia quando eles utilizavam o BigIP. Depois que migramos para o ACE, o cliente passou a reclamar deste serviço especificamente.

Agradeço desde já.

[vicdacos]

Plinio,

O Total corresponde ao total de conexões para este servidor. Sendo assim, caso este servidor faça parte de outras serverfarms, o total representará a soma de todas as conexões para este servidor, em todas serverfarms .

Victor da Costa

[Plinio Brandao]

Victor, bom dia.

Obrigado pelo retorno.

Neste caso, quando especifico o serverfarm/porta (serviço), acredito que o entendimento seja de outra forma. Vou colocar aqui duas saídas para o mesmo servidor:

DC01-ACE-01-PRIMARY-SW1/context_servidores# show serverfarm farm_webcache_26
  serverfarm     : farm_webcache_26, type: HOST
 total rservers : 1
 state          : ACTIVE
 DWS state      : DISABLED
 ---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total      failures 
   ---+---------------------+------+------------+----------+----------+---------
   rserver: srv_webcache_2
       10.4.11.18:26         8   OPERATIONAL     0          166333     63

DC01-ACE-01-PRIMARY-SW1/context_servidores# show serverfarm farm_webcache_144 


 serverfarm     : farm_webcache_144, type: HOST
 total rservers : 2
 state          : ACTIVE
 DWS state      : DISABLED
 ---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total      failures 
   ---+---------------------+------+------------+----------+----------+---------
   rserver: srv_webcache_2
       10.4.11.18:144        2   OPERATIONAL     1883       26533      115

Se observarmos, o mesmo servidor, 10.4.11.18 possui um número de conexões totais X para o serviço na porta 26 e y para o serviço na porta 144.

Acredito que não faria sentido que ele contabilizasse um total de conexões de forma global e não para o serverfarm com o serviço especificado, não concorda?

Desde já agradeço.

[vicdacos]

Plinio,

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA5_1_0/configuration/slb/guide/rsfarms.html#wp1000722

Current	Number of active connections to the real server (name and detail options only).
Total	Total number of connections to the specified server farm (name and detail options only).

Victor da Costa

[Plinio Brandao]

Victor, obrigado mais uma vez pela resposta.

Entretanto,

O comentário acima aponta que é o total de conexões para o serverfarm "específico" e não para todos os serverfarms.

Isso também pode ser comprovado com as saídas dos comandos que eu postei.

Se assumirmos que possuímos a seguinte configuração:

rserver host srv_webcache_2

  ip address 10.4.11.18

  inservice

serverfarm host farm_webcache_144

  rserver srv_webcache_2 144

    inservice

serverfarm host farm_webcache_25

  rserver srv_webcache_2 25

    inservice

Cada serverfarm possui o mesmo servidor com portas/serviços diferentes. De acordo com o seu comentário, não seria possível contabilitar o total de conexões recebidas pelo serverfarm_25, nem pelo serverfarm_144, correto?

Mas de acordo com a documentação que você passou, ela fala que o total refere-se ao total do serverfarm específico, que possui um servidor em uma porta específica. Tanto que na saída dos comandos, os números possuem uma grande diferença de conexões.

De qualquer forma, a minha dúvida não é mais essa e sim a seguinte: o TCP Reuse é um recurso apenas para solicitações HTTP, correto? Ou existe alguma forma de otimizar as conexões TCP para um servidor?

Agradeço desde já.

Plínio Monteiro

[Pedro Ivo Santos Mauri]

Olá Plinio,

Exatamente, o TCP Reuse é um recurso disponível apenas para conexões HTTP, pois estas possuem um fluxo bem definido (é fácil para o ACE dizer quando uma resposta a um HTTP GET terminou) para reutilizar a conexão:

Com outros protocolos, não é fácil para o ACE saber quando o servidor terminou sua resposta, impossibilidando o uso do reuse.

Infelizmente, não existe outro mecanismo que otimize (reduza) o número de conexões feitas a um servidor, para outros protocolos, além do HTTP.

Abraços,

Pedro