LCS 2005 – Why no NLBs?
There are a couple of reasons why we are recommending a 3rd party LB for LCS2005 EE deployments (particularly those that for large number of clients):
1. The traffic patterns and hold times are different when compared to HTTP - SIP connections are characterized by long hold times, and do not have the asymmetric nature of 'HTTP GET (small)->200 OK (large)'.
2. The metric that is used for balancing load in the case of NLB is a simple round robin - we would prefer a least connection or a weighted least connection metric for heavy SIP traffic.
3. Please read the "Planning for Availability" section in the LCS2005 Planning Guide
There are 'flows' beyond the client to server that we need to accomodate (for e.g. MMC-WMI, DCOM/RPC for move-user etc) that do not work with NLB. The 3rd party LB is used as a LB and also as a layer 3 ethernet switch with VLAN capability. its a pretty complex network topology.
4. One of the constraints that we were working under was to use a single NIC on each front end EE server box. this is not possible with NLB - we would require a 2nd NIC on the front end EE server to provide an interconnect into the SQL BE, AD, DNS, Kerb etc
5. HLB's are common place in the enterprise data centers, customers we spoke to while planning LCS2005 stated clearly that enterprise data centers use HLB's and that network admins are familiar with the technology. Further, most of these HLBs can be shared with other applications (like web servers etc).
6. There are 3 vendors we have worked with for 3rd party LB; and we will have a white paper describing NLB usage with LCS2005 (for non-production environments).
7. The LCS 2005 Enterprise Edition "high availability" feature, which includes a Front-End failover mechanism for Windows Messenger 5.1 clients, was not designed to work using Windows NLB and is not supported using Windows NLB. Windows NLB has certain limitations and should only be used for lab testing or smaller pools of up to 20k users.
8. Multiple pool deployments within an organization are not supported using Windows NLB. DCOM activations from a non-cluster machine to the dedicated IP address of a cluster machine can potentially fail.