Microsoft Releases Exchange 2019 Preferred Architecture

The One True Way

Last week, Microsoft released a document describing their preferred architecture for Exchange 2019. A preferred architecture is just that: it describes the way that Microsoft thinks you should deploy their technology based on their experience drawn from customer engagements and Office 365. Customer engagements are the usual source of problems and flaws while Office 365 is where Microsoft can test components at scale. In this case, the MetaCache (SSD acceleration) for the Information Store.

Good as it is to have a preferred architecture, it’s still only preferred. You can deploy Exchange 2019 according to your own recipe for success because it’s on-premises and you control how and when software is deployed. Recognizing that customers ultimately control on-premises software, it’s useful to understand how Microsoft builds their preferred architecture. You can then make your mind up to follow the architecture or use your own design. Or as Microsoft says, “not our recommended practice.”

Nothing Surprising

If you’ve followed the advice given by Microsoft for Exchange 2013 and Exchange 2016, there’s nothing surprising listed for Exchange 2019. Four basic principles are advanced.

• Simplify your namespace.
• Deploy datacenter pairs.
• Use physical servers with lots of memory and CPU cores.
• Use DAGs as basic building blocks for resilience.

Namespace and Datacenters

An uncluttered namespace to make it easy to switch resources and a site resilient datacenter design is what you find in Exchange Online. Think about what happens in the cloud. Users connect to outlook.office.com and behind the scenes this is resolved to the datacenter and server where the user’s active mailbox is running. In the case of the larger Office 365 regions, the active mailbox could be in up to four datacenters (for example, in Europe, the datacenters are in Amsterdam, Dublin, Helsinki, and Vienna). In the smaller (like the U.K.), there’s two datacenters. The same advice is given to on-premises customers, who are also told to restrict DAG stretching to two datacenters even if more are available.

Servers

A recommendation to use physical servers doesn’t mean that you can’t deploy Exchange 2019 on virtual servers. Instead, it reflects the way that physical servers are used within Exchange Online to simplify the operational environment by removing a layer of complexity for deployment, operations, and tooling. You can use virtual servers if you want but need to adjust your plans to reflect the constraints of the virtual infrastructure you use.

Although Exchange 2019 supports larger servers with more memory than ever before, Microsoft says that they prefer to scale out (more servers) than up (bigger servers). The logic is impeccable: don’t put all your eggs in a large Exchange basket to “reduce the risk of discovering other system bottlenecks.” Again, this is what Microsoft does inside Exchange Online, which now spans over 175,000 servers (a massive example of scaling out).

Speed for Hot Data

The big news in Exchange 2019 performance is the introduction of the MetaCache, or copies of mailbox data running on SSD storage instead of the normal JBOD drives to accelerate access to “hot” data. Exchange 2019 will run as normal if the MetaCache is unavailable because you choose not to deploy the SSD drives or if the cache has a problem. Microsoft says that customers should plan to use between 5 and 10% added storage (based on the size of mailbox databases) for the MetaCache.

The added SSD storage caches message and user data to speed up user logins to mailboxes and access to important data like mailbox tables with the idea that the cache can satisfy requests for this information much faster than issuing requests to fetch data held on relatively slow JBOD drives. Attachments are not cached.

Microsoft has been using SSD caches with Exchange Online for well over a year and are confident that the MetaCache will deliver increased performance for on-premises customers. This is a good example of how technology designed for the cloud transitioning to on-premises customers. It will take a little while to become used to Metacache configuration and operations, but will be second-nature soon, especially inside large Exchange deployments.

No Backups Please

The preferred architecture emphasizes the use of Exchange Native Data Protection and says that “With all of these technologies in play, traditional backups are unnecessary.” In other words, have four copies of every database, one of which is a lagged copy and use single item recovery to make sure that data is held for the full retention period – and then you can say good bye to traditional backups.

Exchange Online doesn’t use backups, but a reasonable set of Office 365 tenants still seek the comfort blanket of backup copies. The cloud forces all sorts of behavioral change when it comes to IT operations, but I suspect that it will take longer for on-premises deployments to drop their attachment to backups.

Too Influenced by the Cloud?

Some accuse Microsoft of basing the preferred architecture for Exchange 2019 on what they do for Exchange Online instead of on-premises deployments. Although true, it’s natural for Microsoft to advance the case that the basic principles used for Exchange Online are successful for on-premises too. You can’t argue that simplification is better than complication, that scaling out can avoid the creation of bottlenecks, and that it’s good to transfer proven technologies from the cloud to on-premises.

Whether those committed to virtual platforms or traditional backups will take all the preferred architecture on board is arguable. But they can at least listen and understand why Microsoft makes the recommendations in this architecture. And go ahead if they have strong arguments to do something different. That is, after all, the beauty of on-premises software.