Exchange Server 2019 Virtualization

The virtualized operation of Exchange Server has been a hot topic for discussion ever since the introduction of hypervisor platforms. Often these discussions are very emotional, and the valid arguments rarely heard.

There is an essential principle for planning and running virtualized Exchange Servers, regardless of the product version:

The processor, memory, and other system requirements for virtualized servers are identical to the requirements when running Exchange Server on physical servers.

In reality, a lot of administrators tend to deviate from this clear principle. But a deviation from this principle affects the stable and secure operation of Exchange Server automatically.

The product group updated the recommended system parameters for Exchange Server 2019 compared to the previous versions.

The recommended processor configuration is still a 2-socket architecture but now with a total of up to 48 processor cores. A memory size of 128GB is recommended for operating an Exchange server with Mailbox role and a memory size of 64GB for a server with Edge Transport role.

You must decide whether these recommended operating parameters make sense for your Exchange Server 2019 platform or whether other operating parameters are necessary. The "Exchange Server 2019 Sizing Calculator" helps you to plan your Exchange Server platform and to identify the required resources. The 2019-version of the calculator is still based on an Excel file, but it is now part of the ISO file for Exchange Server 2019 as of Cumulative Update 2. For Exchange Server 2016, you can download the file from the Microsoft Download Center.

Exchange Server 2019, MetaCacheDatabase and Virtualization

Virtualization of Exchange Server 2019 is a challenge if you follow the recommendation. You will rightly argue that nobody follows these recommendations to run Exchange Server 2019 in a production environment. My counter question is then automatically: Why do you not follow this recommendation? The recommendations are based on the experience of the Exchange Server product group in operating Exchange Server in large and highly available environments.

At this point, I would like to point out that Exchange Server is a software solution for running a highly available and secure massaging platform.

With the preferred recommendations for processor and memory in mind, virtualization of Exchange Server does not always make sense. If you configure a database availability group (DAG) with the minimum requirement of four Exchange Servers, you also need at least four hypervisor host systems. The operation of two Exchange Servers on a single host system is an operational risk. For the recommended service of virtualized Exchange Servers, you must assign dedicated processor and memory resources to the guest systems. You can configure a ratio of 1:2 (pCore:vCore) for CPU resource allocation. However, this only makes sense if you monitor both the CPU usage of the guest system and the host system very carefully. As soon as the host system hosts other virtual machines that have a high CPU load, this is also at the expense of the Exchange Server system.

When configuring system resources, always keep in mind that an application running on a Windows Server at all times sees just the resources that the operating system reports. So if a server system has a configuration with 24 virtual cores (vCores) and 128GB of memory, the application tends to use these resources.

In addition to the hypervisor challenges for CPU cores and main memory arise for the connection of the necessary storage media.

Ideally, the server system for Exchange Server has only one disk volume configured with a drive letter for the operating system and Exchange Server binary files. The disk volumes for storing mailbox databases and log files are connected using mount points. Depending on the number of disk volumes required and the technology used to provide disk volumes to the hypervisor platform, you might face limitations. The highly available operation of a DAG requires the use of the AutoReseed function. The AutoReseed functionality requires additional data volumes provided by the hypervisor platform.

The way how data volumes are connected to the Hypervisor host systems and how these volumes are provided to the guest systems is the nerve center of every virtualized Exchange Server platform.

Numerous manufacturers offer you the most imaginative solutions for the supply of the necessary data storage capacity. In most cases, these are solutions that promise to reduce the total disk space required by Exchange Server for storing database and log files. Often, this is achieved through a (magic) form of data deduplication for the mailbox databases and log files. In such a case, you must be aware that you are leaving the field of a supported operation of Exchange Server. You take Exchange Server one of the essential functions in the event of a disaster, the database portability.

With additional levels of technology for operating your Exchange Server platform, you add complexity and error domains. Also, you must run such externally connected data storage systems redundantly, to minimize the operational risk. In this context, also keep in mind that the Exchange Server product team recommends traditional HDD disk drives for storing data files because SSD drives do not have the same reliability and robustness.

Exchange Server 2019 introduced the function of the MetaCacheDatabase (MCDB). MCDB accelerates data access to frequently used mailbox information. The use of the MCDB feature is optional, but it has some requirements to activate it for a DAG:

1. You need to run your Exchange Server in a DAG configuration (no surprise)
2. You need to configure your DAG for AutoReseed
3. You need to provide the right number of SSD drives for the MCDB feature

When operating an Exchange Server platform with physical servers, ideally you will be using suitable M.2 SSD drives installed directly inside the server enclosure. Placing the SSD drives inside the server will give you more standard slots for the data volume HDD drives.

But how can you benefit from the MCDB functionality when running virtualized Exchange Servers?

As mentioned before, the use of MCDB requires SSD disks. In a hypervisor platform, there are always additional layers of technology between the guest operating system and the actual data store, which decrease the speed advantages of a direct SSD connection in a physical server.

In a hypervisor platform, it does not make sense to run an MCDB configuration. The extra drives, insofar as they can be provisioned as SSD drives, further increase the complexity of the platform and create additional CPU load on the host system with their disk I/O. This increases the risk of slowing data access as soon as other guest systems with high system requirements run on the same host system.

My recommendation is to use the MCDB feature of Exchange Server 2019 only with physical servers.

The Role Requirements Calculator, which comes with Exchange Server 2019, helps you plan such an MCDB implementation.

Conclusion

If you plan for a virtualized operation of Exchange Server 2019, always follow the recommendations of the Exchange Server product group as described in the online product documentation. These recommendations are based on the experience in the day-to-day operation of Exchange Server and numerous Exchange Server support cases, based on very distinct Exchange Server implementations.

When virtualizing Exchange Server 2019, be sure to implement it as simple as possible. Each additional level of infrastructure components not only adds to the complexity of the operation but is always an added failure domain. Do not rely on the promises of supposedly performance-enhancing storage solutions for your Exchange Server systems, which some system vendors like to sell as a universal remedy.

The MCDB will provide the desired speed advantages as a cache between the application and the mailbox databases only on physical servers.

And do not forget, the Exchange Server 2019 provides built-in high availability at the application level.

If you plan to run a single-server installation of Exchange Server 2019, I'd like to encourage you to switch to Microsoft 365 and Exchange Online. There is no better email service out there.

Until then, have fun with Exchange Server 2019.

Links

• Exchange Server – Systemanforderungen
• Exchange 2019 – Bevorzugte Architektur
• Exchange Server Virtualization
• Announcing The Exchange Server 2019 Sizing Calculator
• Exchange Server Role Requirements Calculator v9.1
• Exchange Server Database Portability

Monitor Exchange with ENow