ACE Sticky Connections, Show Conn Output and Show serverfarm

Unanswered Question
Mar 24th, 2012

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 4.3 (3 ratings)
rcochenos Sun, 03/25/2012 - 15:10

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

pliniomonteiro Sun, 03/25/2012 - 20:18

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.

psantosm Tue, 03/27/2012 - 05:43

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

pliniomonteiro Tue, 03/27/2012 - 06:47

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 Tue, 03/27/2012 - 07:01

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

pliniomonteiro Tue, 03/27/2012 - 07:21

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.

pliniomonteiro Tue, 03/27/2012 - 08:02

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

psantosm Tue, 03/27/2012 - 08:37

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

Actions

Login or Register to take actions

This Discussion

Posted March 24, 2012 at 8:09 PM
Stats:
Replies:9 Avg. Rating:4.33333
Views:1340 Votes:0
Shares:0