Menu
Exchange Server on AWS
Quick Start Reference Deployment Guide

Designing for Performance

Much of the capacity planning for a new Microsoft Exchange Server deployment centers on the Exchange Server Mailbox role, and the quantity, activity, and size of the Exchange Server mailboxes required to satisfy the target usage scenario. With that in mind, the first planning tool you should use in any new Exchange Server deployment is the Exchange 2013 Server Role Requirements Calculator. As of this writing, the current version of the calculator is v6.6.

You can download the Exchange 2013 Server Role Requirements Calculator v6.6 from the Microsoft TechNet Gallery.

The following sections address specific areas of the calculator as they pertain to the AWS cloud infrastructure. Configure any areas that we do not mention as though your Exchange Server environment were to be deployed using dedicated hardware.

Processor Sizing

The guest operating system gives you some visibility into the processor specifications of the virtualization host's physical hardware. The actual performance of the virtual CPU type and cores presented to the virtual machine will vary from the dedicated physical equivalent, because the underlying hypervisor controls the scheduling of its tasks. To produce a more quantifiable performance metric, CPU overhead must be accounted for when defining Amazon EC2 instances in the design.

In the Microsoft Exchange 2013 Server Role Requirements Calculator spreadsheet, several fields on the Input tab pertain to processor performance. These inputs determine the following:

  • Whether you should deduct an arbitrary overhead percentage from the resulting processor performance calculation based on the cost of virtualization

  • The number of processor cores that will be made available to the virtual machine

  • The optional SPECint2006 performance rating of the target platform onto which the Mailbox role will be deployed

As with any virtualization platform, you must account for hypervisor CPU overhead when planning to run Microsoft Exchange Server 2013. The CPU overhead varies depending on the instance type selected. In addition, AWS is constantly innovating to provide maximum performance for Amazon EC2 instances, and we also add new instance types over time. Therefore, we recommend that you start with a Hypervisor CPU Adjustment Factor of 10% using the Server Role Requirements Calculator. You can perform your own load testing to validate the design and adjust the percentage if needed. Before you start working with the Server Role Requirements Calculator to design CPU requirements, you'll need to determine your planned processor's SPECint2006 Rate Value.

The Microsoft Exchange Server team provides the Exchange Processor Query Tool that will help you determine the SPECint2006 Rate Value. As of this writing, the current version of the tool is v1.1.

You can download v1.1 of the Exchange Processor Query Tool from the Microsoft TechNet Gallery.

The tool takes a specific processor number as input and searches the SPECint2006 baseline for systems that include that processor number. It outputs an average performance rating for the specified processor.

In step 2 of the Processor Query Tool, we recommend that you use an approximation for your closest matching processor. For example, the R3 instance types use Intel Xeon E5-2670 v2 (formerly Ivy Bridge) processors. If you were planning to use an r3.2xlarge instance type, you'd specify Intel Xeon E5-2670 v2 for the processor model in step 2.

In step 3 of the Processor Query Tool, you query the SPECint2006 baseline for systems that include the specified processor number, and the tool provides an average performance rating for that processor, as shown in Figure 3.


		Completing Steps 1-5 in the Processor Query Tool

Figure 3: Completing Steps 1-5 in the Processor Query Tool

Next you need to indicate that you'll be deploying virtualized servers. Steps 6 and 7 are used to determine the SPECint2006 Rate Value for the instance type you’ve selected, as shown in Figure 4.


		Completing Steps 6-8 in the Processor Query Tool

Figure 4: Completing Steps 6-8 in the Processor Query Tool

In this example, the tool provides an average Rate Value result of 809 for the R3 instance processor model. You define a 1:1 virtual-to-physical processor ratio, and enter the number of virtual cores for the selected instance type. In this example, the instance type is r3.2xlarge, which provides 8 vCPUs. The final SPECint2006 Rate Value for the instance is 324.

Next you can move on to the Server Role Requirements Calculator, where you can input the required values. On the Input tab, in step 1, indicate that the design will utilize Server Role Virtualization.


		Server Role Virtualization on the Input Tab

Figure 5: Server Role Virtualization on the Input Tab

On the Input tab, scroll down to the Server Configuration section in step 5, and enter the number of cores and the SPECint2006 Rate Value.


		Server Configuration on the Input Tab

Figure 6: Server Configuration on the Input Tab

Immediately below the Server Configuration section, you can define the Hypervisor CPU Adjustment Factor.


		Processor Configuration on the Input Tab

Figure 7: Processor Configuration on the Input Tab

After you've defined the remaining input values for your design, you can use the Role Requirements tab in the calculator to determine if the predicted server CPU utilization is acceptable. We recommend keeping this value below 80%.


		Recommended RAM Configuration on the Role Requirements Tab

Figure 8: Recommended RAM Configuration on the Role Requirements Tab

You might need to deploy more Exchange Server instances, or choose a more suitable instance type, to reduce the estimated CPU utilization so it's within the recommended threshold.

Memory Sizing

Microsoft Exchange Server memory requirements start with a minimum of 8 GiB for the recommended multi-role configuration. On the Server Role Requirements Calculator, Role Requirements tab, the Recommended RAM Configuration output value continues upward from 8 GiB, based on the target quantity and size of mailboxes that you specify on the Input tab.

AWS offers a number of instance types with different memory configuration options. The general best practice is to pick the instance type with exact or slightly lower memory configuration based on your requirements. For example, you can pick r3.xlarge as a starting point, which provides 30.5 GiB of memory. You may need to switch to a higher memory configuration instance type (for example, r3.2xlarge) depending on the requirements of your deployment.


		Recommended RAM Configuration on the Role Requirements Tab

Figure 9: Recommended RAM Configuration on the Role Requirements Tab

For the Exchange Server Edge Transport role, 4 GiB is the required minimum.

Storage Sizing

The total storage capacity required to support the target deployment scenario is the result of a variety of parameters, including primary and archive mailbox quantity and size, other mailbox usage profile parameters, database storage overhead, volume free space percentage, the number of copies for each database (database availability groups or DAGs), and others.

On the Input tab of the Server Role Requirements Calculator, you might need to specify a custom maximum database size, as shown in Figure 10. This will help avoid having the resulting configuration include volumes that exceed the maximum size of an Amazon EBS volume.


		Custom Maximum Database Size on the Input Tab

Figure 10: Custom Maximum Database Size on the Input Tab

Each Amazon EBS volume attaches to one of 26 possible mount points on the instance: /dev/sda1 and xvdb through xvdz. The operating system root volume is mounted at /dev/sda1. You can attach additional Amazon EBS volumes or host-based instance storage to the 25 remaining mount points. You might need to add multiple instances so the resulting configuration doesn't exceed the maximum number of Amazon EBS volume mount points per instance.

There are three Amazon EBS volume types to choose from:

  • General Purpose (SSD) – These volumes are the default for Amazon EC2 instances. They're backed by Solid-State Drives (SSDs) and are suitable for a broad range of workloads. General Purpose (SSD) volumes provide the ability to burst to 3,000 IOPS per volume, independent of volume size. This volume type also delivers a consistent baseline of 3 IOPS/GiB and provides up to 128 MiB/s of throughput per volume.

  • Provisioned IOPS (SSD) – These volumes offer storage with consistent and low-latency performance, and are designed for applications with I/O-intensive workloads. They're backed by Solid-State Drives (SSDs) and support up to 30 IOPS per GiB, which enables you to provision 4,000 IOPS on a volume as small as 134 GiB. You can also achieve up to 128 MiB/s of throughput per volume with as little as 500 provisioned IOPS. Additionally, you can stripe multiple volumes together to achieve up to 48,000 IOPS or 800 MiB/s when attached to larger Amazon EC2 instances.

  • Magnetic – These volumes provide the lowest cost per GiB of all Amazon EBS volume types. Magnetic volumes are backed by magnetic drives and are ideal for workloads where data is accessed infrequently, and scenarios where the lowest storage cost is important. Magnetic volumes provide approximately 100 IOPS on average, with an ability to burst to hundreds of IOPS. Magnetic volumes are an option for Exchange databases in a non-production environment. For production use, we do not recommend utilizing Magnetic volumes unless you have a small number of mailboxes with very low I/O demand.

For consistent and predictable bandwidth use cases, use EBS-optimized or 10 gigabit network connectivity instances and General Purpose (SSD) or Provisioned IOPS (SSD) volumes. For additional information, see Amazon EBS Volume Types in the AWS documentation.

You might need to use the Server Role Requirements Calculator to produce several possible configurations and validate the performance of each using the Exchange Server version of the Microsoft Jetstress tool.

In additional to including Amazon EBS volumes, some Amazon EC2 instances include instance storage. Instance storage is ephemeral; the configured instance storage appears as a new disk each time the instance is stopped and started again. All data located on instance storage is lost after the instance is stopped. Instance storage is included in the runtime cost of the instance.

Instance store volumes are ideal for temporary storage of information that changes frequently, such as operating system paging and temporary file storage.

Keep the following recommendations in mind when you plan the quantity and size of volumes that your Exchange Server instances will require for the volumes that will not host Microsoft Exchange Server database files:

  • Choose a root volume size that will provide sufficient capacity for patching and diagnostic logging. This Quick Start deploys Exchange multi-role servers with a 300 GiB root volume. You can change the default root volume size when launching the instance either through the AWS Management Console or by using AWS CloudFormation templates.

  • Place the operating system paging file on volumes separate from the operating system files for optimal performance. Instance storage is an excellent candidate for this.

When designing for storage using the Server Role Requirements Calculator, on the Input tab, step 4, you can use the Server Disk Configuration section for each data center, and select 7.2K RPM SATA 3.5" for the Disk Type value. For system volumes, set the Disk Capacity to at least 100 GiB. For Database + Log and Restore volumes, set the value to the maximum Amazon EBS volume size, 1,000 GiB. This disk type selection most closely resembles the performance characteristics of a standard Amazon EBS volume.


   			Disk Configuration on the Input Tab

Figure 11: Disk Configuration on the Input Tab

On the Input tab, step 3, the Backup Methodology value must be set to either Software VSS Backup/Restore or Exchange Native Data Protection.

Note

Microsoft does not recommend using only Exchange Native Data Protection (no backups/replication only) unless you have configured three or more copies of each database within a database availability group. For architectures based on the Exchange PA, you can select Exchange Native Data Protection.


   			Backup Configuration on the Input Tab

Figure 12: Backup Configuration on the Input Tab

Additional Storage Considerations

As you provision Amazon EBS volumes to support your Microsoft Exchange Server databases and log files, Microsoft recommends formatting those NTFS volumes with an allocation unit size of 64 KiB. The automated AWS CloudFormation template automatically provisions Amazon EBS volumes for our sample deployment scenario, and we handle formatting the volumes based on recommended best practices.

Additionally, Amazon EBS–optimized instances deliver dedicated throughput to Amazon EBS. When attached to an Amazon EBS–optimized instance, General Purpose (SSD) volumes are designed to deliver within 10% of their baseline and burst performance 99.9% of the time in a given year, and Provisioned IOPS (SSD) volumes are designed to deliver within 10% of their provisioned performance 99.9% of the time in a given year. For more information, see Amazon EBS–Optimized Instances in the AWS documentation.

There are a number of other Microsoft best practices for configuring storage in your Microsoft Exchange Server deployment. For details on storage architectures and best practices for storage configuration options, see Exchange 2013 storage configuration options in the Microsoft TechNet Library.

Validating Storage and Server Performance

Before you place any Microsoft Exchange Server Mailbox role design into production, you should consider testing the storage subsystem to ensure that the design supports the required IOPS within acceptable thresholds for latency. Storage subsystem performance is critical to an acceptable Exchange Server client experience. You can use two tools to validate storage and server performance: Microsoft Exchange Server Jetstress 2013 and Microsoft Exchange Load Generator 2013.

Microsoft Exchange Server Jetstress 2013 is a free tool provided by the Microsoft Exchange Server team to simulate realistic Exchange Server I/O patterns against one or more test databases. The tool creates the specified test databases on the target volumes and performs simulated transactions for client access, background maintenance, and transaction log replication. You can customize the behavior of the tool through the GUI and the configuration XML file. Throughout the simulation, the tool collects values for a variety of Exchange Server performance counters, and, at the conclusion of the simulation, compares them to acceptable latency thresholds for database and transaction log operations.

You can download the Microsoft Exchange Server Jetstress 2013 Tool from the Microsoft Download Center.

Microsoft Exchange Load Generator 2013 helps validate server performance by simulating the server workload that is generated by user interaction with various messaging client software. It is a useful tool for server administrators or messaging deployment engineers who are sizing servers and validating deployment plans. Exchange Load Generator helps you determine whether each of your servers can handle the load that they are intended to carry.

We recommend that you run Exchange Load Generator against your candidate Exchange Server deployment to validate its ability to handle the anticipated client load. Exchange Load Generator affects the performance of all systems involved, so you should run the tool after you have fully configured Exchange Server for your target deployment and before you introduce production user mailboxes or production data.

You can download the Exchange Load Generator 2013 from the Microsoft Download Center.

Log Replication and Network Traffic

Amazon Availability Zones within the same region are connected through high-speed links. Start to plan your Exchange Server database availability group (DAG) transaction log replication by choosing Fast Ethernet for the Network Link Type in the Server Role Requirements Calculator, Input tab, step 6. Leave Network Link Latency at the default of 50.00, or run your own tests between temporary instances to establish a more precise value.


				Network Configuration on the Input Tab

Figure 13: Network Configuration on the Input Tab

You can use the Exchange Client Network Bandwidth Calculator to predict the network bandwidth requirements for a specific set of clients. The prediction algorithms used in this calculator are entirely new and are derived from significant testing and observation.

You can download the Exchange Client Network Bandwidth Calculator from the Microsoft TechNet Gallery.