Disable pool member when using HTTP/1.1

jiseruk,

Have you tried Force Offline rather than Disable on the pool member? With Disable any persistence connections, or requests on existing connections are allowed. With Force Offline then no new connections are allowed, only existing open ones. These should die out pretty quickly.

Hope this helps, N

Hi Nathan.

The problem are the the existing open connections, not the new ones. New requests are still going to the disabled or forced offline pool member thru that active connections. How can avoid that ? Is it possible ?

Thanks!

The only way to clear the connections immediately is to remove the member from the Pool. Otherwise you need to wait until the existing connections have 'drained' off; new connections can also be created where persistence records point to the disabled server.

Enabling OneConnect will speed up the process considerably in my experience.

We tried first removing the member instead of disabled it, but we saw the same behaviour with the active connections: If you send a request thru an active connection, it reach the member even if you remove it previously from the pool.

Thanks.

I think you can achieve what you want by turning on a OneConnect profile. Then each request gets load balanced instead of each TCP session. so when you disable a pool member the LTM will stop sending requests to that member even though it may still have active TCP sessions that haven't timed out yet. There are other trade-offs to using OneConnect so be sure to read up on on it, but I think it will solve the problem you describe. You can also achieve per request load balancing using LB::detach in an iRule.

I tried LB::detach, but I could see that the SERVER_CONNECTED event is executed in every request, so it`s using HTTP/1.0 from de virtualserver to the pool members instead of HTTP/1.1.
Am I right? 

Thanks!

i'm not sure i totally understand your question. can you post your iRule? I think you should be using the HTTP_REQUEST method to trigger the LB::detach. check out this SOL article http://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html . It is geared toward persistence, but i think it should apply in your case too. you want this behavior for all connections, not just persistent ones so i think your iRule would simple be:

when HTTP_REQUEST {
  LB::detach
}

By far the simpler route would be to use OneConnect though. is that something you are able to test?

    Ok. I will try to explain it better.
    First of all: we don´t use persistence ( I´m talking about cookie persistence or something related to that. We don´t need that each client goes to the same pool member).
    We do want to use HTTP/1.1 from the client to the pool members (I want to send a lot of requests thru the same connection). 
    In this context, we need to do clean deploys in the pool members without loosing requests.
    To do a deploy in a pool member we have tried:
    1) Put the member disabled and then stop de member´s webserver
    2) Put the member in "forced offline" and then stop the member´s webserver
    3) Remove the member from the pool and then stop the member´s webserver

    In the three options, we have noticed that new requests were still coming to the member thru the active connections that it has with the virtualserver, so when we stop the members´s webserver, we lost some requests.

I want that new requests go only to active pool members in a HTTP/1.1 environment.
If I disabled or forced offline a pool member, I don´t want that requests were still coming to it thru the active connections.
I don´t know if this is possible. 
If LB::detach causes that from the virtualserver to the pool members each new request will generate a new connection (HTTP/1.0 environment), that`s not an option.

I hope yo can understand me now. And sorry for my bad english.
Thanks!

If you don't need Persistence, simply removing that (if configured) and enabling OneConnect should make this happen pretty quickly, whether it's quickly enough for you I don't know.