Understanding Multiple Server Role Configurations in Capacity Planning

Applies to: Exchange Server 2010

Several trends in server hardware apply to the Microsoft Exchange Server 2010 timeframe. One trend is a significant increase in processor performance and an increasing number of processor cores supported on a physical processor. This means that deploying a single Exchange server role on a standard commodity server with two physical processors might leave a large portion of available CPU underutilized. Some customers expect server virtualization to more effectively utilize server CPU resources. Other customers want to combine Exchange server roles on the same physical server. Both are valid solutions.

Another trend is the availability of server models with two physical processors and 10 to 16 internal disks. If you consider the number of mailboxes that can be supported by the input/output (I/O) provided by 10 to 16 disks, the Mailbox server role by itself generally won't utilize more than half of the available CPU resources. Adding the Client Access server role and the Hub Transport server role to this server will more effectively utilize the capacity of the server.

You can use the information in this topic as guidance for when to deploy multiple role server configurations and how to correctly plan for multiple role server configurations. An example illustrates the server sizing process for multiple role servers.

Contents

When Multiple Role Configurations Are Recommended

When Multiple Role Configurations Aren't Recommended

Processor Recommendations for Multiple Role Servers

Multiple Role Server Configuration Alignment with Recommended Processor Core Ratios

Memory Recommendations for Multiple Role Servers

Determining Multiple Role Server Hardware Requirements

Deploying a Multiple Role Server in a DAG

Exchange 2010 Multiple Role Example

When Multiple Role Configurations Are Recommended

Multiple role configurations are recommended for the following:

• **Small organizations such as a branch office for server consolidation   **For deployments where the primary goals are to minimize the number of physical servers, operating system instances, and Exchange servers to manage, a multiple role deployment is a recommended solution. Running the Client Access, Hub Transport, and Mailbox server roles on the same physical server provides the necessary role redundancy with a minimum requirement of two or three physical servers.
• **Simple unit of scale model   **Organizations that anticipate regular growth in the number of mailboxes should consider deploying multiple role servers. Because each multiple role server represents a building block, this model allows the easy addition of building blocks to support the need for increased capacity.
• **Server deployments with internal storage   **There are many servers available today with two physical processors (8 to 12 cores) and 10 to 16 internal disks. There have been several improvements in Exchange 2010 to reduce I/O requirements, making these servers a cost-effective solution. Depending on user profile and disk type, these servers will generally support up to 4,000 mailboxes. We recommend adding the Client Access and Hub Transport server roles to these servers to utilize the additional CPU and make these servers self-contained building blocks.
• **Risk mitigation scenarios where the number of mailboxes hosted on a Mailbox server is capped   **Multiple role servers are a solution for deployments where risk management policies cap the number of mailboxes that can be deployed on a Mailbox server. For example, an organization with 10,000 mailboxes has a policy that a single server outage can't impact more than 25 percent of the mailboxes in the environment. This limits the number of mailboxes per Mailbox server to 2,500. The additional capacity on that server could be utilized by adding the Client Access and Hub Transport server roles to the server.
• **Large scale deployments that want to leverage 24 core servers   **Based on scalability testing performed prior to the release-to-manufacturing (RTM) version of Exchange 2010, multiple role servers can effectively use 24 cores in a single server. This capability allows large organizations to reduce the number of servers by combining the Mailbox, Hub Transport, and Client Access server roles instead of deploying these roles separately on servers with fewer processor cores. This approach leverages the simple unit of scale model described earlier to provide a building block platform for large scale deployments while reducing the overall number of servers required. Scalability of the multi-role configuration on larger core count systems should be validated with lab testing prior to production deployment.

Return to top

When Multiple Role Configurations Aren't Recommended

Multiple role configurations aren't recommended for the following:

• **Small organizations such as a branch office for server consolidation with Windows Network Load Balancing (NLB)   **Multiple role servers may not work well for small deployments where two or three multiple role servers are being deployed as members of a database availability group (DAG). For more information about DAGs, see Managing Database Availability Groups. The clustering component added to Mailbox servers that are members of a DAG prevents NLB from being installed on the server. However, there's still a requirement to load balance inbound traffic to the Client Access servers. In this case, there are two main options:

  • Purchase a hardware load balancing appliance. Although there are some entry-level NLB appliances, this option can be costly, especially for smaller environments.
  • Virtualize the Exchange server roles. With this isolation, you can run NLB for Client Access servers running on virtual machines.

• **Small organizations such as a branch office for server consolidation with other applications   **In some environments, a limited number of servers results in having to deploy domain controllers, file and print servers, and other applications on the same physical hardware as the Exchange 2010 servers. We recommend that you implement the physical servers as host servers and isolate applications inside a virtual environment.

  Note

  Only management software (for example, antivirus software, backup software, or virtual machine management software) can be deployed on host servers. No other server-based applications (for example, Exchange, Microsoft SQL Server, or Active Directory) should be installed on the host server. The host servers should be dedicated to running guest virtual machines.

• **Virtualization   **We don't recommend running a multiple role configuration inside of a virtual machine with four virtual processors. This significantly limits the number of active mailboxes that can be hosted by the virtual machine. In most cases, it's more effective to deploy a single Exchange server role in each virtual machine, or to deploy one Client Access and Hub Transport combined role virtual machine for every Mailbox server role virtual machine.
  For more information about Client Access and Hub Transport combined role configurations, see Understanding Client Access and Hub Transport Combined Role Configurations in Capacity Planning. For deployments with less than 500 total mailboxes, it's acceptable to run a multiple role configuration inside a virtual environment to reduce the number of operating systems and Exchange servers to manage.

Return to top

Processor Recommendations for Multiple Role Servers

As a general guideline, a multiple role server should be sized to use half of the available processor cores for the Mailbox server role, and the remaining half for the Client Access and Hub Transport server roles. The maximum recommended processor core configuration is listed at 24 processor cores for the multiple role servers. Although the multiple role server configuration can use more than 24 processor cores, we don't recommend it.

The following describes the minimum requirements and recommended maximum configurations:

• Minimum   This is the minimum processor and memory configuration suitable for multiple role servers. The minimum hardware requirements must be met to receive support from Microsoft Customer Service and Support.
• Recommended maximum   This is the recommended maximum processor and memory configuration for multiple role servers. Maximum is defined as the upper bound of viable memory configurations based on price and performance. The recommended maximum configuration is a guideline. It isn't a support criterion, and it doesn't take into account the resource requirements of third-party applications that might access or be installed on the server. The recommended maximum configuration may change over time based on price changes and technology advancements.

The following table shows the minimum and recommended maximum processor cores for Exchange 2010 for multiple role servers.

Processor configuration for Exchange 2010 multiple role servers

Return to top

Multiple Role Server Configuration Alignment with Recommended Processor Core Ratios

The following table outlines the recommended number of processor cores deployed for the Client Access and Hub Transport server roles relative to the number of processor cores deployed for the Mailbox server role. The standard core ratios don't align well to the number of processor cores available on systems today. Unless you have a large organization with many Client Access, Hub Transport, and Mailbox servers, your deployment probably won't match the desired processor core ratios.

Multiple role server configurations can solve this problem and should result in more optimal hardware utilization. For example, if you have a server with eight processor cores, those cores can be virtually allocated to the three Exchange 2010 server roles. If the Mailbox server role uses approximately four cores, the Client Access server role uses approximately three cores, and the Hub Transport server role uses approximately one core, the result is a 4:1 Mailbox to Hub Transport server role core ratio and a 4:3 Mailbox to Client Access server role core ratio. This closely aligns with the recommended processor core ratio guidance.

The following table shows the recommended server role ratios based on processor core for multiple role servers.

Recommended server role ratios based on processor core for multiple role servers

Return to top

Memory Recommendations for Multiple Role Servers

After the number of processor cores has been determined, baseline memory recommendations can be applied. The following table illustrates the minimum and recommended memory configurations for Exchange 2010 multiple role server configurations.

Memory configuration for Exchange 2010 multiple role servers

Return to top

Determining Multiple Role Server Hardware Requirements

The simplest way to determine hardware requirements for the multiple role server is to start with estimating the number of active mailboxes that your hardware configuration will support. The following table provides some preliminary estimates of the number of users that can be supported by a processor core for a specific user profile. These are estimates, and we recommend that you read Mailbox Server Processor Capacity Planning for information about calculating mailbox counts based on available megacycles to determine a more accurate mailbox count for the server processor model. After you determine the user count, you can use the table in "Memory Recommendations for Multiple Role Servers" earlier in this topic to determine the required system memory.

The following table shows the recommended number of users per processor core for multiple role configurations.

Recommended number of users per processor core for multiple role configurations

Return to top

Deploying a Multiple Role Server in a DAG

When you're deploying single Mailbox servers in a DAG, consider capacity planning for single and multiple server failures in relationship to Mailbox server load. If you have four Mailbox servers in a DAG, size the Mailbox servers at 50 percent capacity so that they can accommodate double the number of active users, in the event of simultaneous failure of two Mailbox servers. Because the Hub Transport and Client Access servers are on different physical servers, the load on those servers isn't impacted much by the loss of one or two Mailbox servers.

When you're deploying multiple role servers in a DAG, think about capacity planning for Client Access, Hub Transport, and Mailbox server load. If you have four multiple role servers in a DAG, make sure there is sufficient capacity to accommodate a potential doubling of Hub Transport and Client Access server load. Because the multiple role configuration aligns with the recommended processor core ratios for server roles, if you correctly size the maximum active databases for the Mailbox server role, Hub Transport and Client Access servers should meet the performance objectives for this scenario.

Return to top

Example of Sizing for an Exchange 2010 Multiple Role Scenario

The following example illustrates the server sizing process for multiple role servers. The example has the following design assumptions:

• Total mailbox count   8,000
• Mailbox profile   100 messages per day (for example, 20 sent and 80 received)
• Database cache per mailbox   6 MB (based on a 100 message per day profile)
• Availability requirements   Mailbox resiliency within a single site; protection against simultaneous failure of two servers
• Database requirements   40 databases in the DAG, 200 mailboxes per database
• Server platform   2 x 4 core 3.33 gigahertz (GHz) processor-based server (8 cores)

The following process applies:

1. Calculate server count   A four-node DAG is required to protect against the simultaneous failure of two servers, so the design begins with four Mailbox servers within the DAG.
2. Calculate maximum active mailboxes per server based on the activation model   Assuming the active databases are equally distributed across the nodes, each server would ideally host 2,000 active mailboxes (8,000 ÷ 4). To calculate the active mailbox count after a double-node failure (based on this example), the mailbox count would be divided by the remaining two nodes, which equals 4,000 active mailboxes per node (8,000 ÷ 2).
   In this example, the MaximumActiveDatabases parameter on the Set-MailboxServer cmdlet would be configured for 20 to ensure that no more than 50 percent of the databases become active on a single server.
3. Calculate active mailbox CPU requirements   Multiply the maximum number of active mailboxes on a server by the megacycles per active mailbox (4,000 × 2 megacycles = 8,000 megacycles), based on the Estimated IOPS per mailbox based on message activity and mailbox database cache table in Understanding the Mailbox Database Cache. Multiply this value by 10 percent for each additional database copy.
   In this example, there's one active copy and two passive copies for every database, so the 8,000 megacycles is increased by 20 percent (8,000 × 1.2 = 9,600 megacycles). For more information, see "Database Cache Metrics" in Understanding the Mailbox Database Cache.
4. Calculate passive mailbox CPU requirements   Multiply the number of passive mailboxes (when a server is hosting the maximum number of active mailboxes) by the megacycles per passive mailbox (4,000 × .3 megacycles = 1,200 megacycles), based on the Estimated IOPS per mailbox based on message activity and mailbox database cache table in Understanding the Mailbox Database Cache. For more information, see "Database Cache Metrics" in Understanding the Mailbox Database Cache.
5. Add active and passive CPU requirements to get total CPU requirement   In this example, 9,600 active mailbox megacycles + 1,200 passive mailbox megacycles = 10,800 megacycles total CPU requirement.
6. Apply total CPU requirement to hardware platform   This example uses a 2 x 4 core 3.3-GHz processor-based server. This equates to 26,400 megacycles (8 × 3,300 MHz). Divide the required megacycles by the available megacycles based on the server platform to estimate the CPU utilization at peak period after a double-node failure (10,800 ÷ 26,640 = 41 percent predicted CPU utilization).
   We recommend that the Mailbox server role portion of multiple role configurations be designed to not exceed 40 percent utilization during peak periods (for example, simultaneous failure of two nodes). This will allow sufficient space to accommodate CPU utilization of Client Access and Hub Transport server roles while maintaining total server CPU utilization at less than 80 percent during peak periods (for example, simultaneous failure of two nodes).
7. Calculate active mailbox memory requirements   Multiply the number of active mailboxes by the required database cache per mailbox. In this example, with a double server failure, the remaining servers will host 4,000 active mailboxes (4,000 × 6 MB) ÷ 1,024 = 23.4 GB. The database cache requirements are based on the mailbox profile. For more information, see "Database Cache Metrics" in Understanding the Mailbox Database Cache.
8. Apply total memory requirements to hardware platform   The total memory required is based on the database cache requirements. For more information, see the Default mailbox database cache sizes table in Understanding the Mailbox Database Cache. The total memory requirement for the multiple role server in this example is 37.3 GB ((4 GB + 23.4 GB)/.75). Because 37 GB isn't a standard memory configuration, round up to 48 GB or the closest memory configuration that your server supports.

Return to top