A Forum reader recently asked:
"I'm wondering if someone can give me some guidance on load-balancing my two iChain 2.3 SP5 boxes. I currently have 2 boxes running exactly the same config. I physically remove the network cables from one; if one fails or I need to update it, I simply plug in the other.
I'd like to load-balance these two behind a content switch. I understand that I need to run the session broker for session persistence and can introduce a third box if required just to do this.
Is it just a simple case of giving the second iChain box different primary IP's? What about the secondary accelerator IP's bound in the ichain proxy config - will they conflict if both boxes are listening on those same IP addresses?"
And here's the reply from Steve Bratt ...
I am doing hardware-based load balancing, but the method used by my switch doesn't require the session broker (http://www.novell.com/documentation/ichain23/ichain23/data/ag8qlag.html) etc. I don't know if this will help you, but it's good to see different approaches.
First, I have 2 NIC's in each box, one for the external world to reach the
accelerators, and one on the back for the iChain boxes to communicate with the source webservers. The second connection is not load-balanced, so when iChain A requests a source page from webserver B through the second NIC, there is no question that the reply will go back to the correct iChain box. It takes a couple of extra network and host gateway entries to ensure that connections go out the right NIC, but it's not too complicated.
My switch (Extreme Networks) supports 4 different "server load balancing" modes, but the simplest is what they cal "go-go" mode.
With my SLB switch, I need to force both external NIC's to have the same MAC address. The switch will then transparently send half the source IP's in the world to box A and half to box B on a simple hash. (Basically, you could imagine that all even-numbered IP's go to one, and all odd-numbered to the other, but I don't know its real algorithm). As long as both boxes are up, all requests from a certain IP will always go to the same iChain box, so the persistence isn't an issue. This only allows a basic 50/50 split of your traffic. It doesn't account for an unusual load on one box or every request coming from an odd or even IP number during a freak period, but I figure it stays pretty balanced most of the time.
The Switch is also set up to poll both boxes for a TCP connection on port 1595. If the iChain management page doesn't respond or the link goes down, the switch sends all requests to the remaining good box. Only existing
connections to the box that went down would lose their sessions in this case, getting picked up by the remaining box.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.