I've used Cisco CSS 15001 and it had two modes for maintaining server affinity:
A) via Cokies - load-balancer adds is own cookie to served content B) via IP ranges - admin has to manually define IPs of clients served by each server in a cluster.
Method A doesn't work if load-balancer uses HTTPS to connect to the servers.
If load-balancer is equipped with encryption module it is possible to use method A with HTTPS. Load-balancer uses HTTP to connect to servers, adds cookie and then sends content to a client via HTTPS. This way servers don't waste CPU for HTTPS handling.
Method B doesn't support automatic failover.
Jacek [ April 30, 2007: Message edited by: Jacek Ostrowski ]
Joined: Oct 03, 2003
Interesting and important points, thank for sharing! But I'm still a bit curious about session management.
For example, if the user adds an item to his shopping cart (on a new session) consider that at latter time he/she adds another item.  In this case, what's the behavior on a clustered environment? Would the user be forced to maintain a conversation to that web server who served him/her the first time in order to have access to the session?  And in this case, what roles does the load-balancer play?  Would HTTP or HTTPS behave differently in this scenario?
Your thoughts on this matter are much appreciated.
Joined: Feb 09, 2007
If load-balancer uses predefined IP ranges (I think that this is called sticky IP) to maintain server affinity then all request from given client goes always to same server. So from client's perspective there is only one server in a cluster. No problem with sessions here. Works regardless of used protocol.
All this is far beyond requirements for SCEA part 1. For exam you need to know that load-balancer needs to maintain client sessions.