Blogging just to remember something

2011/08/30

SharePoint 2010 – NLB vs Hardware Load Balancer

In the last period, many times I was involved in discussions with customers regarding the adoption of the out-of-the-box Windows Server NLB (Network Load Balancer) or dedicated hardware solution (Cisco, F5, Coyote, etc.)

I’ve tried to summarize my mental pattern about this argument, in the table below (…well, I censored Duff & Donuts from my thoughts):

 

PROS

CONS

NLB

  • It’s cheaper (already available as part of Windows Server stack).
  • Rapid deployment and adoption:
    • SharePoint team doesn’t need to rely on the infrastructure team for the configuration;
    • No real technical expertise needed;
  • NLB works at socket level (TCP/UDP) and doesn’t provide any specific feature or optimization for http/https.
  • A dedicated NIC (network card) is strongly recommended.
  • Governance and Operations of NLB cluster could be tricky:
    • more people must be made aware of NLB configurations
  • Configuration could be tricky in presence of multicast traffic.
  • No caching capability is provided:
    • for http/https is expected to rely on Microsoft ISA or IAG;
  • No certificate management:
    • Certificate must be individually managed in IIS;
    • Some Governance is needed;
  • No compression capability:
    • for http/https is expected to rely on IIS 7.x
  • Technology is …antique, well not really an issue but NLB was created to balance COM+ application with NT4/OptionPack

Hardware Load Balancer

  • Improved Performance, https traffic is managed at hardware level;
  • Low latency during the switching in case of High-Availability configuration.
  • SSL and HTTPS configuration is managed internally, making it transparent to IIS/SharePoint configuration.
  • Caching capabilities if needed (don’t abuse of this).
  • High-Availability generally supports dependency rules on how to route packets in case of unavailability of specific servers/application tiers.
  • Support of protocol specific rules (http, https, etc.)
  • Support of Security Rules;
  • Technical Agnosticism, the tools can be used to balance Windows, Linux, Web Server, sockets, email servers.
  • Governance in the sense that there is a centralized point of management for all the needs regarding balancing, high-availability, security etc.
  • Expensive, for sure it something to be acquired and identifying the best solution won’t be easy ‘cause the huge amount of options in the market.
  • Learning Curve

Rules of Thumb

  • Use NLB if hardware load balancer is not available  and there are no plans on that (polite way to say no budget);
  • In the Intranet, if reverse proxy isn’t available (sometimes the hardware load balancer is available only for Internet traffic);
  • As Tactical Solution (as example for running stress test on your new project in a stage environment if the hardware solution is not available or cannot be used);
  • We can definitely state that a strategic solution must rely on hardware load balancer, a tactical solution could rely on a software NLB.

No comments: