This article is a cross-post from the VMware blog, view the article here.
As enterprise IT teams, leadership and business owners continuously drive towards service improvements, they invariably look at the public cloud infrastructure as a possible target for their mission critical applications. Whereas virtualization is now generally accepted as the default platform for enterprise-grade applications, businesses looking to leverage the public cloud for most of these applications are still constrained in their ability to do so.
These constraints can be directly attributed to the following (among others):
- Performance Concerns – is the target public cloud robust enough to meet the application’s scale and performance requirements?
- Vendor Support – is the target cloud platform certified for the application? Will the vendor provide the necessary technical support and assistance when (not if) the enterprise requires it?
- Level of Effort – mission critical applications demand considerable attention to configuration and other considerations beyond those required for lower-tiered applications and moving from one hosting platform to another may not be a simple or quick undertaking.
This article will address two of these constraints in relations to enterprises’ desire to operate their Microsoft Exchange Server workloads on the VMware Cloud on AWS platform – Performance and Support. Part II of this article will address the “Level of Effort” aspect – we feel that this deserves a stand-alone article of its own.
Microsoft Exchange Server is one of the most prevalent Messaging and Collaboration applications in enterprises today. Microsoft officially supports virtualizing Microsoft Exchange Server (hereafter simply referred to as “Exchange” or “Exchange Server”) on the VMware vSphere virtualization platform. Because VMware has been supporting (and providing guidance for) the virtualization of Exchange Server for more than 10 years (even before official Microsoft support), virtualizing Exchange Server on the vSphere platform has become quite mainstream.
The vSphere platform has been the number one target for virtualized Exchange Server workloads for many years, largely due to the fact that enterprises have realized that vSphere not only provides a very robust, flexible, scalable and optimal platform which exceeds all performance requirements for the largest Exchange Server infrastructure in the world, it does so at very reduced financial, operational and maintenance cost – helping customers achieve considerable savings and ROI.
Amazon AWS is the acknowledged Leader in the public cloud space, providing enterprises a robust infrastructure to move some of their workloads from their (on-premise) datacenters to a public cloud infrastructure at considerable cost-savings, resilience and operational efficiencies. Major enterprises’ have adopted AWS as their standard public cloud destinations and have transitioned many core applications and workloads to AWS over the years. These enterprises have been exploring the feasibility of moving their Exchange Server workloads to AWS but have been unable to do so due to one or all of the aforementioned constraints.
The most significant of the constraints associated with running Exchange Server workloads on AWS are the fact that such an operation is NOT supported by Microsoft, and the efforts involved in the exercise are too significant to justify. Microsoft Exchange Server is a Windows-based suite of applications requiring specific configuration, packaging, administration and other requirements. While Exchange Server workloads can be operated optimally in a native AWS infrastructure using a combination of tooling, scripting and human efforts, this combination has proved to be daunting enough to discourage most enterprises from considering moving their production Exchange Server workloads to AWS.
Until now.
VMware Cloud on AWS provides enterprises the opportunity to operate their mission critical applications on their preferred familiar virtualization platform, in their preferred and familiar public cloud infrastructure. A VMware Cloud on AWS infrastructure consists of a cluster of VMware ESXi hosts situated in an AWS public cloud, augmented with a combination of the best elements of the VMware vSphere and Amazon AWS Suites, and managed with the same administrative toolset operators and administrators are already familiar with.
Operating and managing a VMware Cloud on AWS infrastructure presents little to no learning curve for most administrators, making the transition from on-premise vSphere infrastructure to VMware Cloud on AWS a very attractive and logical proposition.
Does running Exchange Server on VMware Cloud on AWS make sense for enterprises? Exchange Server workloads demands “considerable resources” and can, therefore “suffer” performance degradation when hosted in a cloud environment, right? Not.
The absolute operational and technical resource limits for a single Exchange Server is as shown in the screenshot below:
https://blogs.technet.microsoft.com/exchange/2015/10/15/ask-the-perf-guy-sizing-exchange-2016-deployments/
In contrast, a typical ESXi host in a VMware Cloud on AWS has 72 Processor Cores and 512 GB Memory. While a 24-way, 192GB (RAM) Exchange Server is arguably “large” in comparison to other workloads, even the required resource is still a fraction of the average capacity of an ESXi host in a VMware Cloud on AWS infrastructure. Considering the average sizes of modern server hardware today, the resource limitations of Exchange Server argues against enterprises running their Exchange Server workloads on physical hardware servers, and favorably in support of running them virtualized – in a VMware Cloud on AWS infrastructure.
Yes, this contrast does not, by itself, answer the question of whether or not the cloud platform can satisfy the acceptable performance level required by such a mission critical, enterprise application. So, let’s look deeper.
Microsoft provides a very handy tool (Jetstress) for baselining Exchange Server performance by simulating Exchange database I/O patterns and characteristics for a desired threshold. While not an exact science, most Exchange Server administrators rely on the resulting validation provided by Jetstress to determine whether or not a given server hardware configuration can provide and sustain a desired number of Exchange user mailboxes, profiles and performance. The output of a Jetstress test is quite unambiguous – you get a PASS or a FAIL. Period.
Originally intended for Exchange Servers running on physical hardware server, the current version of Jetstress now supports simulation in a virtual environment. What this means for us is that we have a reliable and trusted tool in our toolbox with which we can answer the query: Can an Exchange Server hosted in a VMware Cloud on AWS environment achieve a level of performance similar to that achievable by an identical Exchange Server hosted elsewhere (in this case, an on-premise VMware vSphere environment)?
We use an on-premise vSphere environment for comparison because it has since long been established that there is no performance difference between Exchange Server running on this platform and a physical Exchange Server.
The screenshots below document the result of our comparison tests, and the accompanying embedded video documents the entire test plans, execution and result. Both of these provide indisputable evidence that a similarly configured Exchange Server workload running in a VMware Cloud on AWS infrastructure does achieve the same level of performance as one running in an on-premise VMware vSphere infrastructure.
Can you tell which server is running on which platform? No? Neither could we.
Our Jetstress performance test outputs are identical in all respect.
Jetstress for VMware Cloud on AWS Exchange Server VMs Demo
So, yeah, ok. We have parity in performance, but is it supported?
Yes, it is supported – by everyone – VMware, Microsoft and AWS. Well, to be technically accurate, let’s explain it as follows:
- Microsoft supports Exchange Server virtualization
- Microsoft provides support for Exchange Server virtualization on third-party hypervisors, provided that the hypervisor vendor is one with whom Microsoft has established a joint support relationship. VMware is one of those vendors – https://support.microsoft.com/en-us/help/944987
- Microsoft has established strict requirements and standards for supporting Exchange Server workloads virtualization, and VMware vSphere satisfies ALL of these requirements.
- The support for virtualized Exchange Server workloads on vSphere is without constraints, provided that the vSphere version is equally certified by Microsoft.
- All current versions of VMware vSphere are certified and listed on the Microsoft Server Virtualization Validation Program.
- VMware Cloud on AWS is a cluster of VMware vSphere hosts, running the latest versions of ESXi (6.5 as of this writing).
- Microsoft has published the following criteria for supporting Exchange Server hosted on an Infrastructure as a Service (IaaS) platform. VMware Cloud on AWS is one such IaaS
https://technet.microsoft.com/en-us/library/jj619301(v=exchg.160).aspx#BKMK_Prereq
In the very unlikely event that enterprises running their Exchange Server workloads experiencing issues require technical support which couldn’t be provided by either VMware or Microsoft, customers have the added security and assurance of the TSANet Alliance through with both VMware and Microsoft will combine efforts to provide the required support.
https://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm
VMware Cloud on AWS affords enterprises the ability and flexibility to run their virtualized Microsoft Exchange Server infrastructure, using the same superior hypervisor platform they have standardized upon, in the external public cloud infrastructure they have adopted, without any fear of losing performance or support, and without undertaking any complex workload, application or VM transformation or reconfiguration.
As we will show in Part II of this article, moving Exchange Server workloads from on-premise datacenters to the public cloud is a very simplified process.
