Load Balancing and Failover
Previous  Top  Next


The concept of Load Balancing and Failover is that if you have more than one server, you can increase site performance and improve site stability. If your web server is heavily loaded, either CPU-wise or disc-wise, then simply adding a second server might be far cheaper than re-writing your web applications, if that's even possible.

And if your web application tends to halt, Failover can save the day by removing the broken server from the rotation and sending surfers to servers that are still working.

Persistent Sessions
What really makes OctaGate Switch™ powerful when it comes to Load Balancing is that handles persistent sessions. This means that once a surfer has been connected to a specific server, he or she will keep being served by that server. This means that your web server can function just as it always has, it need not be aware that it's only one of several servers making up a web site.

When a user has been in-active for a period of time, the session is canceled. How long this period is is up to the administrator. Generally, if you have a web application in the back end that has a session time out, OctaGate Switch™ should have a sligthly longer time out period. The default is 1800 seconds (30 minutes).

Failover Settings
When a server is determined to be offline, OctaGate Switch™ will not assign any new sessions to it. It will also redirect existing sessions to another server - one that is still online.

How OctaGate Switch™ determines that a server is offline is very customizable. Two values, "Max Faile Before Offline" and "Failover Check Interval" together determine how fast a server that isn't responded is considered to be offline. OctaGate Switch™ will poll all servers in the cluster every "Failover Check Interval" seconds. If a server is not responding, a fail counter will be increased for the server. If that counter exceeds the value in "Max Faile Before Offline", then the server is considered to be offline. The reason that the server can have several chances before it's considered to be offline is that if the web server simply hickups and misses a single connection - or all connection during a short period of time, all sessions would be terminated.

The default value is that the server can fail once before it's flagged as offline and OctaGate Switch™ checks every five seconds that the servers are online. This means that a server could be offline no more than 10 seconds before OctaGate Switch™ notices. If that value is too long for you, or you want to guard against frivolently dropping sessions, you can either increase or decrease those two settings.

Once a server starts resoponding again, it will again be flagged as online.

Testing Load Balancing and Failover
If you add a server cluster that load balances between two servers and you connect to it through a browser, you will continually be sent to the same server. This is because OctaGate Switch™ will remember the IP you're connecting from and make sure that you have a persistent session. You will need to connect from another computer for the Load Balancing part to take place.

Moreover, OctaGate Switch™ will assign you to the least loaded server in the cluster. The load is calculated on a running average during the last 300 seconds (5 minutes see "Load Averaging Period" in Server cluster/Edit). If no servers has had any load for the last five minutes, a server will be picked at random - proportional to the capacity of the server. This means that if you start a browser to try the load balancing, then walk to another computer and start another browser, then you might just be assigned to the same server - if it takes you more than five minutes to open the second browser!

If you significantly increase Load Averaging Period you will have more time to move to the next browser to make sure you're assigned to a new server.

A Demo
We've created a demo where the "Session Timeout" is set to only five seconds. In this demo, if you refresh the page often you'll keep the same server each time. But if you wait a longer period - more than five seconds - you will be assigned to a less loaded server, if there is one.

You can test the demo here
.

Balancing by session count
OctaGate Switch™ doesn't load balance by the number of sessions per server, since it's not really possible to determine load from that. Say you have one server in the cluster, and that server has 500 sessions - but they're all pretty much dormant. Then you add a new server which will then have 0 sessions. If session count is the determining factor, the new server will soak up ALL new sessions because it looks unloaded compared to the old server. But the new sessions will be far more busy than the old dormant sessions, so load will not be evenly distributed. OctaGate Switch™ uses a more sophisticated method based on requests per second.

Instant Failover
We're planning Instant Failover as an alternative for OctaGate Switch™ 2.1, but it's currently not available. Instant Failover would mean that as OctaGate Switch™ tries to connect to the backend server it would failover to another server if the first didn't answer. The difference between Instant Failover and say a 5 to 10 second delayed failover is smaller than you might think, the majority of active sessions wouldn't notice the difference between the two, given that they most likely wouldn't refresh during the failover delay. However we're looking to adding this feature to OctaGate Switch™ 2.1.