04-24-2010 05:58 PM
Hi,
I have a two new VIPs created ( http and https )
VIP 1 = 10.10.20.15 80 ( Real Servers 192.168.10.45 and 192.168.10.55 listing on port 80 )
VIP 2 = 10.10.20.15 443 ( Real Servers 192.168.10.45 and 192.168.10.55 listing on port 443 )
I would like to maintain stickness across these two VIPs. Is this possible?
For example: User is using a web browsers and types http://10.10.20.15 the user is directed to VIP 10.10.20.15 80 and then to real 192.168.10.55:80 (based on the predictor method) After browing a few http pages, there is a re-direct on the http page to https://10.10.20.15/idbi/index.htm
My understanding is that the browser sends a new request to VIP 10.10.20.15 443 and there is a 50-50 chance that the connection comes back to the 192.168.10.55:443
How can i ensure that the https connection comes back to the same server?
I have tried source ip stickiness. But no luck.
My config is as follows
serverfarm host HTTP-10.10.20.15
rserver 192.168.10.45 80
inservice
rserver 192.168.10.55 80
inservice
serverfarm host HTTPS-10.10.20.15
rserver 192.168.10.45 443
inservice
rserver 192.168.10.55 443
inservice
sticky ip-netmask 255.255.255.255 address source vip-10.10.20.15-http
timeout 30
replicate sticky
serverfarm HTTP-10.10.20.15
sticky ip-netmask 255.255.255.255 address source vip-10.10.20.15-https
timeout 30
replicate sticky
serverfarm HTTPS-10.10.20.15
Regards
Jack
04-25-2010 09:28 AM
Jack,
My guess is, that because you have two class'es that matches incoming traffic, two sticky-configs and two serverfarms, any subsequent traffic that is matchet against a different class, will be re-loadbalanced towards a different serverfarm. And different stickies will be applied to the https-portion of the flow.
Since you're not translating the dst.port for your traffic, one serverfarm and one sticky-config should be sufficient. I've done this myself for traffic, for which I'm not translating the dst.port and it works fine. Basically, you remove the port parameter and simply configure the ip-address of your rservers, as shown below:
serverfarm host [something]
rserver 192.168.10.45
inservice
rserver 192.168.10.55
inservice
And one sticky-config:
sticky ip-netmask 255.255.255.255 address [source/destination/both] vip-10.10.20.15
timeout 30
replicate sticky
serverfarm [something]
Then, use the same stickyconfig in both your classes under your multi-match policy. If this doesn't do the trick, plz let me know. Another option would be cookie-based stickyness, although there's a few more things that has to be considered. I would probably use the 'both' parameter in sticky-config, as the sticky would be based on both the src. and dst. address.
hth
/Ulrich
04-25-2010 02:34 PM
Ulrich,
Thanks for your reply. Was very Helpful. I will try this and get our developers to do their test.
Theoritically I believe your solution will work.
Just out of interest, I have one questionsto ask (for future reference)
How to use the cookie-based stickiness in my scenario?
Jack
04-25-2010 11:45 PM
Basically, just replace your current sticky config with something like this:
sticky http-cookie [cookie-name] [sticky-group-id]
cookie insert browser expire
timeout [seconds]
replicate sticky
serverfarm [name]
The 'browser expire' is optional, but simply allows for the browser to determine the expiration of the cookie.
ACE assign a unique cookie-value for each of your rservers by calculating a hashed value based on the rserver ip.addr and port and inserts that value into the database. You can display the content of the database with 'sh sticky cookie-insert group sticky-group-id. The result would be something like this:
Cookie | HashKey | rserver-instance
------------+----------------------+-------------------+------------------------------------------------------+
R3055599550 | 7033142962938655715 | serverfarm/realserver:port
This value is inserted into the http-header of the clients request and used for stickyness. However, unless you configure 'persistence rebalance', the ACE will only loadbalance based on the first request. Any subsequent requests will simply be packet-switched to the same rserver, until the end-of-flow or the rserver is taken out of rotation/fails. If you need to inspect your http-header at each request, you need to configure an http-parameter-map with persistence-rebalance.
Additionally, you can assign your own cookie values, rather than using a hashed value. Simply configure the following under your sticky-config:
static cookie-value value rserver rserver-name.
hth
/Ulrich
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide