Many of the benefits we find from virtualization in general also apply to virtualizing workloads like Exchange Server 2013. Regardless of your Exchange configuration and number of servers, you can move your VMs around as required, without worrying about the hardware. This is, of course, assuming your hardware and virtualization platform of choice are in good working order.
Fellow writer Michael Van Horenbeeck recently argued in two articles that, in many cases, virtualizing Exchange doesn’t make sense. I'm here to look at the other side of the discussion and argue that – in most cases – a virtual Exchange Server makes sense.
Although both physical and virtual workload options for Exchange are valid, there are many scenarios when it might make more sense to virtualize.
Let's start with the storage side. Exchange 2013 has been designed for slow disks in a JBOD format, but is perfectly fine (and supported by Microsoft) on a storage area network (SAN) too. I prefer the SAN option, because it provides flexibility in the storage capacity you can provide to your Exchange environment. You can estimate disk space usage over the next three to four years based on the life of your server and buy appropriate disks, but it's only an estimate. Maybe your company will flourish or merge, doubling its size, or there could be extreme downsizing. On the other hand, the SAN(s) should be providing storage to the majority of your environment, giving you a much larger pool of storage to play with and allocate as necessary.
JBOD for Exchange limits you in several other ways. Sure it's cheaper, but your capacity is limited by how many drives your server can accommodate, or look to purchase an external chassis for storage. More concerning is the lack of redundancy with JBOD. Lose one disk and that chunk of data is now offline, rendering the physical server useless until the disk is replaced. Depending what data is lost, it may then require data to be reseeded from another Exchange DB server, restored from backup or rebuilt from scratch. This shouldn't cause an outage in itself -- as there should be at least one more Exchange server running -- but it can put you in a risky position.
There are some technologies Exchange incorporates, such as Auto Reseed, that can use online spare disks to reduce risk, but this is another path that continues to reduce cost savings.
Many small to midsize companies rely on one or two physical servers with JBOD. This is not a supported configuration by Microsoft, but many take this approach anyway, which can increase the risk of downtime within a company's Exchange environment.
This is also the case during maintenance and patching, as you'll have no live redundancy for your data. To alleviate this risk, some companies may add a third physical server, which is the minimum supported amount of database copies by Microsoft
Instead, most small companies would be better off running Exchange in the cloud due to reduced administrative overhead and hardware costs. Exchange Online or Office 365 are worth researching further to see if a cloud approach makes sense for you.
For large companies, the amount of data required for all the users may not work with the limitations of the JBOD approach covered earlier, and you should have enough of a budget to purchase a top-quality SAN.
For other resources, such as CPU and RAM, it's recommended that dedicated resources are used for Exchange or you're going to have a bad time. This is quite easily achievable in VMware and Hyper-V. The redundancy of Exchange is still covered by the application itself; database availability groups cover your failovers rather than the VM itself, so you don't need to keep spare resources available when a host goes down. As an example, in the environment I currently work in, each host has 256 GB of RAM and 16 CPU cores (with hyper-threading for 32 logical processors), which isn't considered excessive these days. Allocating 96 GB of RAM and 8 cores still gives you a lot of room to play with, especially for those low-powered servers that aren't CPU intensive.
To re-emphasise all this - a virtual Exchange Server will run fine, as long as you do it right. This means reading the documentation, and following Microsoft best practices. As a comparison, SQL Server took a long time to have virtualization support - not due to the product itself, but due to poor configuration of hypervisors providing the virtual server hosting SQL.
Another point to briefly cover is snapshotting. It is unsupported by Microsoft, so should not be considered a benefit of virtualization. It may work, but personally I'd recommend that if it's not supported, it's not worth the pain if something goes wrong with the process.
By no means am I saying that you need a virtual Exchange Server -- I recommend not getting too caught up in debates for one side or the other -- only that for many organizations, it may make more sense than keeping it physical. Armed with the knowledge of the benefits for physical and virtual, you should be able to make the choice that best suits your environment.
Editor's note: This article has been edited from its original form to correct an inaccuracy.