Forum Discussion

Steffen_Beach_8's avatar
Steffen_Beach_8
Icon for Nimbostratus rankNimbostratus
Dec 10, 2010

New connections going to wrong default pool

Hey all,

 

 

I've got a bit of a problem and I'm trying to get a better understanding of the ltm behavior to help solve a problem.

 

 

As part of our regular code deployments, our process is to change the default pool mapped to our application and web service virtual servers to redirect traffic to members in pools with updated code.

 

 

Ex. ApplicationX makes SOAP calls to WebServiceX

 

 

VirtualServer ApplicationX (Default Pool: ApplicationX_a)

 

Pool ApplicationX_a (members: 1-10 code version 1.0)

 

Pool ApplicationX_b (members: 11-20 code version 1.1)

 

 

VirtualServer WebServiceX (Default Pool: WebServiceX_a)

 

Pool WebServiceX_a (members: 1-10 code version 1.0)

 

Pool WebServiceX_b (members: 11-20 code version 1.1)

 

 

Once code is tested and ready for production, we remap the default pools for the VirtualServers as such:

 

 

VirtualServer ApplicationX (Default Pool: ApplicationX_b)

 

Pool ApplicationX_a (members: 1-10 code version 1.0)

 

Pool ApplicationX_b (members: 11-20 code version 1.1)

 

 

VirtualServer WebServiceX (Default Pool: WebServiceX_b)

 

Pool WebServiceX_a (members: 1-10 code version 1.0)

 

Pool WebServiceX_b (members: 11-20 code version 1.1)

 

 

This happens almost instantaneously using tmsh scripts, yet for minutes on end we see new connections going to WebServiceX_a pools. We don't have persistence enabled and our applications don't maintain connections to our services. We've been doing our deployments this way for over a year without any issues, but recently we started seeing exceptions from our application. In the exception we could see that old methods from v1.0 were being called. This got us looking at the ltm and we realized that not all new connections were going to the WebServiceX_b pool.

 

 

Any ideas why this is happening?

 

 

Thanks,

 

-Beach
config
design

3 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Dec 10, 2010
    Hi Steffen,

     

     

    If the existing client connections have been closed and you see new client connections being sent to the old pools, the only thing I can think of is OneConnect allowing use of existing connections. Do you have OneConnect enabled on the virtual server? If so, one option might be to clear the connection table entries for the specific virtual server. You can do this with b conn. See the 'b conn help' output for details on this.

     

     

    Aaron
  • Steffen_Beach_8's avatar
    Steffen_Beach_8
    Icon for Nimbostratus rankNimbostratus
    Dec 10, 2010
    Aaron,

     

     

    We're not using OneConnect. I mentioned to our systems team that after they flip to the new pool to run 'b conn server delete' if they see traffic still going to the old pool, but it's just odd that we'd have to do this. We're going to do a deployment tonight so I'm going to write out the traffic information to a file for additional analysis. I'll see what I can come up with.

     

     

    I wish I could 'b conn server ' via the iControl API. I have a web interface that I could wire up quickly to query and capture data opposed to having a putty session output to a file.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Dec 10, 2010
    I'd actually recommend opening a case on this and getting feedback from Support. If you're willing to test this again, they'd probably be looking for tcpdumps during the switch along with 'b conn all show all' output.

     

     

    Aaron