I'm spec'ing out the requirements for a client, and they're dead set against using WNLB. I agree with them.
Does anyone have any compelling arguments as to why the following (which I took from an MS doc on Live Communications Server 2005, and adjusted somewhat) would not represent a very good and fair guideline of what you'd want a Load Balancing appliance to achieve? Is there anything obviously missing?
Also, I'm a$$-u-me-ing that we're talking Layer 2/3 LB and not Layer 4/7.
Pat
A Load Balancer must meet the following requirements. · Must expose a VIP address through ARP (Address Resolution Protocol). · The VIP address must have a single DNS entry called the Pool FQDN (fully qualified domain name). · The VIP address must be a static IP address if the Load Balancer is not capable of performing dynamic DNS registrations. · Must allow multiple ports to be opened on the same VIP. · Must provide TCP-level affinity. This means that the Load Balancer must ensure that TCP connections can be established with one Server in the pool and all traffic on that connection will be destined for that same Server. · Must provide a configurable TCP idle-timeout interval. · Should support a rich set of load balancing metrics (round robin, least connections, weighted, and so forth.). A weighted, least connections-based, load balancing mechanism is recommended for the Load Balancer. This means that the Load Balancer will rank all Servers based on the weight assigned to them and the number of outstanding connections. This rank will then be used to pick the Live Communications Server to be used for the next connection request. · Must be able to detect Server availability by establishing TCP connections to ports (often called a ‘heartbeat’ or ‘monitor’). The pooling interval must be a configurable value, with a minimum value of at least five seconds. The Load Balancer must not select a Server that shuts down until a successful TCP connection (heartbeat) can be established again. · The network adapters must have at least one static IP address. This IP address will be used for the incoming load-balanced traffic. · The computer must have a registered FQDN. The IP address registered for this FQDN must be publicly accessible from within the enterprise. · Less than a gigabit capacity of network bandwidth for up to 50,000 clients (nominally). · Support up to 100,000 concurrent TCP connections (or higher) – for higher-end deployments on one or more gigabit Ethernet ports. · Must allow for adding and removing servers to the pool without shutting down. · NAT (network address translation) capable. · Support IP forwarding.
You get what you pay for <wry g>. FWIW, the rule of thumb I use is that a dedicated appliance is pretty much always going to out-perform a server and oftentimes can reduce complexity. If an appliance can be used then it should be. Not mandated, by any stretch, but certainly a 'best practice'. I don't want to turn this into a holy war!
The main issue is the lack of smarts that you get from an appliance i.e. intelligent/statistical load balancing rather than the simple round-robin wnlb gives you. It's entirely feasible that, owing to session disconnects, you could wind up with a disproportionate loading between hosts.
On the other hand, I suspect (but cannot prove) that NLB is going to handle the mobile client who changes IP address in mid-session in a way that a Layer 2/3 Load Balancer would barf all over the place on. This is something we're going to see more and more of over time, and something I can see ISA handling quite nicely without breaking stride.
From what I'm seeing wrg2 MS's position - specifically concerning LCS and OCS, and not, I hasten to add, ISA - is very clear deprecation. In LCS2005 it's recommended for test use only with slews of disclaimers about putting it into production (not supported). For OCS2007 it's not supported in any environment, period. Gotta wonder why, right? It's unheard of for MS to change stance like this, and they wouldn't do so without extremely good reason.