Forum Discussion
Sandesh_Lohar_8
Nimbostratus
NimbostratusDynamic 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
hoolioCirrostratus
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- Sandesh_Lohar_8
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.
