It’s a best practice to use Hardware load balancer rather Windows NLB for SharePoint (or any other web applications!) for the following reasons:
- NLB uses local resources on each server in the cluster – Which means the additional load on SharePoint servers!
- NLB Cannot detect service outages. It can only detect server outages by IP address. If a particular server service fails, is hung, slow, or depreciated – WNLB cannot detect the failure and will still route requests to that server.
- NLB doesn’t provide any specific feature or optimization such as SSL offloading, compression, Caching, Certificates management, etc.
- NLB is DNS Round Robin (RR) which simply forward the client hits to defined interfaces. So it leads to uneven spread of workloads across cluster nodes resulting in slow user response times and high latency for the application.
- Performance can degrade as more nodes are added to the cluster
- Adding or removing a single node can cause clients to reconnect to the WNLB cluster.
- It cannot provide reverse proxy services functionality.
- Only supports source IP address affinity/persistence.
- All hosts in a cluster must be located in the same subnet.
- NLB Cannot provide pre-authentication and Single-Sign-On functionality features which are important for SharePoint.
So, A dedicated hardware load balancer addresses these drawbacks and makes configuring and managing a load-balanced environment a whole lot easier! Use NLB ONLY if the hardware load balancer is not available.