Why Kemp Load Balancer is Better than Windows NLB!

Luddite is not a word that we hear all that often these days. For those that don’t know what or who the Luddites were, they were a group of English textile workers opposed to the modernisation of the textile industry during the industrial revolution in the 19th century. They believed that the traditional way of cloth and textile manufacturing, despite its many flaws, was the historic and correct way of doing it. Their name is now synonymous with a person who is opposed to new technology or ways of working.

This is directly comparable to the Load Balancing market of today. Most industry experts, are in agreement that we are in the midst of our very own industrial revolution. So then why are so many companies content with using technology from the last century?  Windows NLB is a case in point, while excellent when developed back in 1996 it has hardly changed since then and is prone to numerous failings and flaws that a modern Application Delivery Controller (ADC) does not.

Here at Celestix, we have partnered with Kemp for a number of years to provide best in class ADC, and as part of their acquisition of Flowmon are now able to package this with best in class Network Detection and automated response, as well as Network Performance Monitoring.

Kemp are the ADC of the future and we are proud to partner with them to help our customers get the most out of their technology.

So, what are the well-known Issues with Windows NLB that we have also come across in our years of dealing with them.

Bear in mind, Windows NLB was released in 1996 and has not really changed since. The product has known performance issues so Microsoft do not recommend it for their own applications because it cannot deliver true High Availability, and because of its age the features are also limited.

The Windows NLB has the below known disadvantages:  

• Causes switch flooding. Unicast mode relies on this to operate, multicast mode also causes switch flooding unless the switch is configured with static mappings of the multicast MAC addresses to the ports that the NLB nodes are connected to.
• Does not support multiple scheduling algorithms for distributing client load.
• Potential uneven spread of workloads across cluster nodes resulting in slow user response times and high latency for the application.
• Cannot detect service outage. It can only detect server outage by IP address. If a particular server service fails, WNLB cannot detect the failure and will still route requests to that server.
• Unable to consider each servers current CPU load and RAM utilisation when distributing client load.
• All hosts in a cluster must be located in the same subnet.
• Only supports source IP address affinity/persistence.
• Since WNLB is incompatible with Windows Clustering, WNLB cannot be used for application such as Exchange DAGs where this is used.
• Manual configuration of all nodes is required making it more difficult to scale and troubleshoot.
• Limited scalability. Based on official figures a WNLB cluster should support up to 32 nodes. However Microsoft frequently state in various articles that a cluster should be limited to 8 nodes.
• Uses local resources on each server in the cluster.
• Performance can degrade as more nodes are added to the cluster.
• More complex than using a dedicated hardware or virtual load balancer.
• Adding or removing a single node can cause clients to reconnect to the WNLB cluster.
• Limited control of source IP NATing so cannot support complex network topologies and security zoning.
• No Layer 7 features such as extended persistence options, multiple scheduling methods, URL re-writing etc.
• Cannot provide reverse proxy services functionality that is required for applications such as Skype, Exchange
• Microsoft does not recommend WNLB for application such as Exchange due to performance issues.

Kemp is a true ADC and you can find out more about load balancing Always on VPN with Kemp here.  Or try it out for free with a 30 day trial here

Don’t be a luddite, update your technology!