Forum Discussion

Sandesh_Lohar_8's avatar
Sandesh_Lohar_8
Icon for Nimbostratus rankNimbostratus
Jun 24, 2008

Dynamic switching of requesting between pools

 

Hi Guys,

 

 

Just want to check if somebody can help me resolve a typical scenario for achieving zero downtime deployments, as detailed below.

 

 

( Note: I had read the post at

 

http://devcentral.f5.com/Default.aspx?

 

tabid=53&forumid=5&tpage=1&view=topic&postid=14781478 )

 

 

Background:

 

 

1. I am using F5 BiGIP load Balancer to balance a IIS 6.0 based Web Farm

 

of say 2 nodes, which maybe scaled to include new nodes, in future.

 

 

2. I plan to setup two Pools A & B - with A serving older version of the

 

application & other pool B serving the newer version of the application.

 

 

3. Also, only in newer version of application, I am considering inserting

 

a unique Header into the HTTP request when the response is generated

 

from the server.

 

 

4. Now when the request is sent from the Browser, I am aware that at the

 

load balancer, HTTP request's unique Header which was earlier inserted

 

(refer above point 3.) can be read & consecutively used to route the

 

request to pool B - since, request meant for for older version of the

 

application will not have this unique HTTP Header.

 

 

5. I plan to use the iRules at Load Balancer level, to use a simple if

 

else statement as shown below, (please ignore the syntax..):

 

 

if {HTTP_HEADER contains "UNIQUE_NEW_VERSION_HEADER"}

 

{ use pool B }

 

else

 

{

 

use pool A }

 

 

 

Currently I don't have access to F5 enabled Web Farm. So I am unable to

 

validate the point 5 stated above.

 

 

I would truly appreciate if somebody can validate this or suggest an even

 

better alternative.

 

 

Thanks

 

Sandesh.

 

2 Replies

  • Hello Sandesh,

     

     

    A web browser will not send any arbitrary HTTP header it receives in a response in subsequent requests to the server, so 3 won't work exactly as you've described.

     

     

    You could use any type of persistence on the VIP and then when you are ready to upgrade one server in the pool, mark the node down (set it to: 'Only active connections allowed'). While the node is marked down, it will receive no new TCP connections. Once you've upgraded the software on that node and you are ready to upgrade the second server, enable the first node and change the second node's status to 'Only persistent or active connections allowed'. This ensures that clients who make a request with a persistence record pointing to the first node will continue to be persisted there. Once all connections to the second node are closed, change the status to 'Only active connections allowed'. Once the second node has been upgraded, enable it once more.

     

     

    You could build this same logic in an iRule, but the default configuration options are much easier to implement.

     

     

    Aaron
  •  

    Thanks a lot Aaron !!

     

     

    I was somehow unaware about the fact you stated - that, headers inserted into a Response Headers collection are not accessible in the Request Headers collection, as this is dictated by the Browser...

     

     

    With regards to an earlier approach (my earlier post) as mentioned in this link,

     

     

    http://devcentral.f5.com/Default.aspx?tabid=53&forumid=31&postid=25259&view=topic

     

    (Also please check these related posts which I had put put earlier ...

     

     

    http://forums.asp.net/t/1277783.aspx

     

    http://forums.asp.net/t/1275980.aspx

     

     

    )

     

     

    only if my assumption (in the first link above ) turns out to be true - i.e., drained out node still services the postback requests, I would have no need to consider the current approach of switching between pools based on the custom header !!

     

     

    By the way, keeping inline with the current approach, I am considering using cookies instead to HTTP Header to achieve the same effect, but a problem would arise if users don't accept the cookies...

     

     

    So still working on pro & cons of other alternatives like hidden variables, etc & whether thses can be retrieved or accessed at the Load Balancer level ...

     

     

    Sandesh.