“Hello, Helpdesk? Email is down”
“I’ve just sent everyone home. We have lost a whole day of business. I don’t care how you do it, but when we get in tomorrow morning, email had better be working.”
There are some conversations you never forget. The date was July 21st, 2005, and the Chief Operating Officer walked out of the server room, and my manager and I sat back down, after our dressing down. We had been battling a dead Exchange Server for over 3 hours, with no resolution in sight. It took another 3 hours to get it back up and running.
Email plays a crucial role in business operations, as you can see from the real-life example above, everything grinds to a halt when it’s unavailable. In a recent survey, VMTurbo found that the mail server is the most commonly cited business-critical application. Every minute email is down can literally cost you money.
The complaint I used to dread the most as an IT administrator was “Email is slow”. How do you define ‘slow’? And troubleshooting ‘slow’ is really difficult. Usually, the problem solves itself, and sometimes, like I found out way too many times, it’s a symptom for an imminent total failure.
Microsoft Exchange – King of Email
With 64% market share (expected to grow to 72% over the next few years), Microsoft Exchange is by far the most popular messaging platform in use today. Over the last 15 years, Microsoft has pursued an aggressive release schedule, with major changes to the architecture of the server in each release. We’ve had Exchange Server 5.5, 2003, 2007, 2010, 2013 and Exchange Server 2016 is literally just round the corner.
Version 5.5 to 2003 Server introduced integration with Active Directory. We’ve gone from a single server in 5.5/2003, to 4 (Client Access, Hub Transport, Mailbox and Edge Transport) main roles in 2007/2010. For the 2013 Server, everything was consolidated into just 2 roles (Client Access and Mailbox), and in 2016, we’re right back where we started, with all the roles on one server.
The reason for these architecture changes is simple, Microsoft was trying to improve stability and performance by splitting out the roles, but as server hardware has become more powerful, consolidation is now possible.
To Virtualise or Not to Virtualise? That is the Question
There are clearly several benefits to virtualising the Exchange infrastructure. The key one is server consolidation, but virtualising also helps with:
- Easier Application upgrades and installs
- Easier Disaster Recovery
- Reduced IT expenses
However, there are downsides - moving your precious Exchange Server to an environment where it’s sharing infrastructure with other applications can lead to degradation in performance. There are some static management methods you can use to mitigate this risk – memory and CPU reservation, affinity rules to keep Exchange server(s) on specific hosts, but by doing this, you start to lose the benefits of virtualisation.
Microsoft vs. VMware
Microsoft’s Preferred Architecture is to use physical, multi-role servers. The reason given is to remove the additional layer of management and complexity virtualisation adds to the solution. According to the above article, out of the box, Exchange provides recovery features that means anything you get from a virtual platform does not really add value.
So what does VMware say? Well, as you can imagine, VMware is seeing more and more people who are prepared to virtualise their critical business applications, as seen from the chart below.
With regards to Exchange, their preference is single role design over multi-role. This allows for easier root cause analysis when problems occur (and they will!).
What’s Actually Happening?
In the real world, you see deployments somewhere between Microsoft’s and VMware’s approaches. In my experience, I am starting to see more and more people virtualising Exchange, mostly as single-role servers, however, I have come across a few multi-role virtual environments.
A lot of the time, administrators take steps to try and guarantee the performance of the Exchange setup, given that the application is not virtualisation aware. So you see a lot of:
- CPU and Memory Reservations
- Affinity Rules: Exchange servers are used tied to specific hosts and migrations between physical hosts are only done in the most extreme circumstances.
- Sizing: Microsoft offer a sizing tool, however, most people use this as a guide, and then to size generously. Best practices will be to size for a physical machine, and then build a VM with the same configuration. (or size up 10-12% to account for the virtualisation overhead)
The first two points diminish the benefits of virtualisation. If you would like to employ static management methods like these, you might as well use just physical servers.
Microsoft caution against oversizing the server – physical or virtual. Believe it or not, oversizing leads to performance bottlenecks. It makes sense, right? The bigger the server, the less likely you’ll have performance issues? Think again.
The product is designed for commodity servers, so when it’s installed on larger servers, there is excessive contention amongst threads, leading to locks and thread scheduling.
Mission-Critical Exchange Servers, Let’s Talk About It
So what do you do with such a critical application? There are several moving parts you need to keep your eye on in order to keep your Exchange environment in a healthy state, it’s an immense challenge several Email administrators take every day.
Let’s have a discussion, please leave a comment below to talk about how you manage your current Exchange environment, and any challenges you are currently experiencing.