Load-Balancing!!

“Load-Balancing” a very common term that is coined whenever we come across a multi-node environment.

The simple question that arises is Why do we need a Load-balancer ??

Well, most of the Business Applications we build for our customers/clients it is expected to be available with a very limited i.e less that 0.0001% down time. But due to some unforeseen circumstances and calamities, a disruption of the services might take place, which might affect the application, the business and finally in terms of revenue. To avoid these situations, there is always a demand for a backup server or database for the Business Continuity Planning.

In most cases the Multi-Node feature of the Application Servers are leveraged for the Continuity of Business and ZERO Down Time.

• Some of the in-depth questions that might pop-up are :
• How fast can the Secondary Node take over, once the Primary Node is Down ?
• What happens to the Transaction that was in Progress ?
• How is the session consistency maintained ?
• What are the different approaches to achieve this ?

Here we go!!..

Load-balancing techniques are basically used to maintain session persistence or “sticky connections” A sticky connection is one that exists between and client and server and is maintained for some period of time. On the Web, streaming audio or video and e-commerce transactions online are a few  examples

The Sticky connections can be performed over standard web based ports or extended to encrypted sessions (HTTPS) if required and with varying configurable algorithms.

There are two different ways of achieving Load-Balancing :

• Hardware Load Balancers
• Software Load Balancers

Each of these approaches have their pros and cons, which needs to be evaluated before finalizing upon it.

Hardware Load Balancers :

Some of the advantages that can be reaped from the Hardware Load Balancer implementation are :

Affinity : The balancer reads the cookie information from the URL  for each request and rewrites the header information to the appropriate node in the cluster where the session is being maintained. The messages are SSL Encrypted to protect the data.

Stateful Failover : The hardware load balancers actually provide the request level failover as apart of maintaining the continuity.All the requests for the dead node are re-directed to the New Server Active Node. The hardware balancers do not provide a transparent handover during failover. Unless the session snapshot is taken the info in the dead-node is lost for ever.

Better Metrics : As all the requests pass through the load balancing system, it can give a clear picture of the number of active sessions maintained for an instance, the number of sessions maintained during maximum and minimum Load. These statistics are very important to understand the performance and the throughput of the system. this can also be used for tuning and improvizing the performance.

Caching : Some of the load balancers provide Caching capabilities, which can  reduce unnecessary repeated processing of complex requests and improve performance.

Back to Back Load Balancing : Even if the Application load balancer is working fine, but sometimes the Database where the actual data is persisted, can pose a problem. So, in order to maintain a perfect cntinuity, it should be ensured that the data in the database is also maintained with a necessary load balancing technique complementing each other.

Some of the dis-advantages of using Hardware Load Balancer implementation are :

• Cost – Very Expensive
• Single Point of Failure – As all the requests pass through the hardware load balancer in place, a falut in this case can ruin all the data and requests hitting the system
• SSL and Secured HTTP Requests : The requests that come via a HTTPS channel are actually encrypted, so it becomes quite difficult on the part of the H/W Load balancer to decrypt and understand the real  beneath it.
  • This Issue can be solved by using the following two approaches
    • Using We-Server proxies
    • Hardware SSL Decoders
  • But these additional approaches for decoding adds on to the Total cost and expenditure.

F5 Networks actually provides a H/W Load Balancer with a SSL decoder blended with it.

Software Load Balancers :

Some of the approaches for Software Load Balancer implementation are :

Web Server Proxy : A Web server proxy that sits in front of a cluster of Web servers takes all requests and decrypts them and redirects it to the appropriate Nodes based on the header information, cookie and URL.

The good part with this implementation is, it provides a server affinity for the SSL encrypted messages with no hardware cost.

Apache & Tomcat : In most of the HTTP Requests the Apache handles the static pages while the Tomcat handles the dynamic pages. To implement load balancing, we need to create a special type of Tomcat instance, called a Tomcat Worker. It can be configured to handle HTTPS Requests.

Some of the dis-advantages of using Software Load Balancer implementation are :

Depending on your Web server and operating system, a software load balancer may require additional investments.

If we want to run Apache on Linux and want to use Microsoft’s Network Load balancing, then additional server and OS should be purchased.

Now the final thought that arises is which one should I opt for!!

H/W Load Balancer Or S/W Load Balancer : The software load balancer might look very cheap and easy option , but it may not be. If we consider all the dependency factors like the OS, the Environment and other decoders that are required the expense shoots up to match up with the hardware load balancer cost.

So, as a best solution most of the organizations go with the low cost hardware load balancer.

Well the choice of a load balancer can always be a debating topic!! it depends upon the needs and the environment.

Load balancing Software Vendors and Manufacturers :

• F5 Networks Big IP:  www.f5.com
• Cisco Content Services: www.cisco.com
• Microsoft ISA server:  www.microsoft.com
• Zeus Technology Extensible Traffic Mgr:  www.zeus.com

Happy Learning!! 🙂