In the April 8 post on the Exchange team’s blog, a clear direction is given that single-role Exchange servers are not the preferred starting point for designs. In fact, a rather bold statement is made:
“… always start design discussions with multi-role, and that is the recommended solution from the Exchange team.”
There’s a lot of good information and recommendations in the post that I totally agree with and some that I don’t. For example, I don’t agree with the notion that you should start with RAID-less JBOD direct-attached disk configurations simply because most shops don’t have the time, energy, or operational efficiency to monitor JBOD disks and take action when failures occur – and they will. It seems to make a lot more sense to plan for a degree of robustness in the solution up-front and take advantage of all the smart technology that companies such as EMC, NetApp, and HP include in their disk controllers today. Sure, you can go cheap-and-cheerful with JBOD if you like and get the warm glow that results from a successful deployment, but be prepared for “interesting times” when disks fail over the course of server lifetime. Of course, if you’re a consultant who parachutes in to do a design and departs immediately upon payment, you don’t need to worry about long-term operational robustness, but that’s getting away from the point I originally started to discuss.
When Microsoft introduced Exchange 2007 way back in 2006, they made a big fuss about the wonders of single-role servers and the splendid code isolation that they had achieved by giving administrators the chance to install just the code required to do the job – and no more – on their Exchange servers. Less code was exposed to hackers and speedier performance was assured because excessive instructions and data couldn’t get in the way. The horrible mess of Exchange 2000 and Exchange 2003, which of course are multi-role servers and come equipped with all the code necessary to do whatever task is demanded of them, was discarded in a wonderful embrace of the notion of “less is better”.
I just wonder what’s happened in the five years since to make Microsoft recant and realize that multi-role servers are actually very flexible and the right option to begin with for all deployments. Of course, the default installation mode for Exchange 2007 and Exchange 2010 has always been to offer to install a multi-role MBX/HT/CAS server, so maybe the fuss and bother about the joy of single-role has been so much smoke and mirrors? As outlined in my own post of March 1, I suspected as much…
No, you say. Microsoft would never do such a thing to their faithful community of Exchange administrators. So there’s got to be another reason. I suggest that the answer is encapsulated in another sentence in the blog post:
“In Exchange 2007, we did not support the Client Access or Hub Transport roles on clustered servers, so there was no way to have a high availability deployment…”
The penny drops! Single-role deployments are useful and valuable in some specific circumstances, usually encountered in very large deployments, but the notion that single-role is wonderful is so much marketing powerfully pungent brown bovine emissions thrown out to disguise the fact that Exchange 2007 only ever aspires to be a partially highly-available application because the HT and CAS roles can’t be installed onto a server that operates in a Continuous Cluster Replication (CCR) or Standby Cluster Replication (SCR) configuration. The situation is very different with Exchange 2010 because the Database Availability Group (DAG) supports multi-role servers as well as dedicated mailbox servers, so you can include all of the necessary servers into a single highly-available entity (in Exchange terms anyway – there are other parts of the infrastructure that also need protection before you achieve true high availability).
Now that we’ve cleared up the confusion, we can consider what happens from this point. According to their blog (second only to TechNet in terms of accuracy, clarity, and insightfulness) Microsoft’s best practice is now firmly focused on multi-role servers. We can therefore anticipate that this trend will continue and that future engineering efforts will support this position.
No more single-role servers are needed unless you need them for a specific purpose. For example, virtualizing HT and CAS servers has always seemed to be a pretty good idea to me because these server roles are essentially stateless and it seems practical and logical to isolate these servers on virtualized machines for large deployments. But for smaller deployments built around a few servers in a DAG, follow the excellent recommendations of the EHLO post, keep everything simple and go with multi-role. You know it makes sense.
For more information about how to configure and deploy Exchange 2010 SP1 servers, including how to approach many tickly design problems, see Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition.