The new advice from Ross Smith IV's session entitled UNC311 - How Outlook connects to Exchange 2010 Client Access Server is in some ways contrary to the TechNet documentation online, which specifically recommends using NLB. However given the source, and that it comes direct from the Exchange team along with reasons why, it's certainly advice worth following.
You can (and should) watch and listen to the whole session online, but for quick reference I've transcribed the relevant part as delivered by Ross along with a little context:
"What we [Microsoft] recommend is a hardware load balancer for most deployments.. there are several reasons..
Hardware load balancers provide you service awareness, so you can actually get down to the individual, not only the individual TCP port, TCP 443 as an example, but you can potentially get down to the individual application as part of that service, depending on the load balancer you deploy. So now you can know if the web service, or the EWS service I should say, is failed - but OWA is still functioning on the CAS array. And you could take that member out of service as the result of that one failure because maybe you have.. Lync deployed and you rely heavily on the EWS service.
Hardware load balancers allow you to deploy different types of persistent methods for the different types of clients, which can then enable you to do different thing depending on your architecture.
What we don't recommend - is DNS round robining; DNS round robin does not provide persistent. It merely provides a means to alternate which servers are responding at a particular time. It does not provide any sort of persistence, or necessarily fault tolerance. So we don't recommend it.
We don't recommend Windows Network Load Balancing, and from a cross site architecture, while there are ways to deploy a single, unified, namespace across multiple datacentres, it's extremely complex, it requires extremely expensive load balancing solutions - you can do it, but it is an operational cost that you have to manage.
So - from our perspective, we recommend creating two separate namespaces, and accessing those namespaces from that perspective."
"Why not Windows Network Load Balancing? Well - there's several issues with it. One - it only provides the ability to do IP-based affinity. So we don't get the persistent capabilities that we need.
Two - it doesn't provide service awareness… it's "server-aware". If the web service fails, Windows Network Load Balancing has no concept of that. It just continues to route requests to that and then the user has a broken experience.
It doesn't scale well. When we talk about Outlook connectivity, and Outlook going to this load balancing solution, you know, if it's just direct Outlook connectivity, at a minimum we're doing 4 TCP sessions - plus one or two HTTP sessions, for that connectivity. So - 4 MAPI sessions, 2 HTTP sessions. So that's 6 sessions that you have to deal with, per Outlook client at a minimum. And then, you look at the perspective that you might have 50,000 of those clients, or a 100,000 of those clients, all connecting to this array. That's just a scale that Windows Network Load Balancing does not deal with.
So anything over 8 nodes - we don't recommend that you use Windows Network Load Balancing.
It also isn't supported with Windows Failover Clustering. So you cannot co-locate CAS and the Mailbox roles and expect to be able to use Windows Failover Clustering and Windows Network Load Balancing on the same machine.
And then, the last one - adding or removing a single node does cause all clients to have to be reconnected to the Network Load Balancing Array.
So there are a multitude of problems of why we no longer recommend Windows Network Load Balancing with Exchange 2010 in enterprise type deployments. Obviously in certain scenarios like a branch office, where you only have a small set of user populations, it obviously makes sense from a cost perspective."
So there you have it. In most circumstances, Windows NLB is not recommended because (as you probably already know) it has no clue as to whether OWA, EWS or any other Exchange service is available on your CAS, it doesn't have decent affinity, and doesn't scale. The first two reasons will apply to every load balanced CAS array designs, so if you budget allows it you should consider a hardware load balancer (or even two, for redundancy!).
If by any chance you're now looking for Microsoft's list of qualified Hardware Load Balancers for Exchange 2010 check out the Microsoft Unified Communications Load Balancer Deployment page on the Microsoft site, and if you're looking for a good article on setup and further recommendations, check out Henrik Walther's multi-part article Load Balancing Exchange 2010 Servers using a Hardware Load Balancer Solution at msexchange.org
No comments:
Post a Comment