Introduction
Planning an enterprise messaging infra-structure with Microsoft Exchange Server 2010 can be more or less complex, depending on several factors, like the size of the organization, services to be implemented, security policies, volume of information and so on.
Sizing the servers it’s just a small part of the whole process, but is without a doubt, one of the more important tasks involved.
As I said in the article I wrote for Exchange Server 2007, the present article is not intended to be a deep technical dive into sizing an Exchange infrastructure. Instead, it’s just a collection of rules of thumb that will, hopefully, speed up this specific part of the planning process of the different Exchange server roles.
Figure 1: Exchange 2010 Server Roles
General Guidelines
Although CPU and memory play a crucial role in performance, increasing any of these 2 doesn’t necessarily mean a faster system. The following table shows the recommend memory and CPU for single role servers and for multiple role servers:
|
Role |
Recommended |
Recommended |
Recommended |
Recommended Memory Configuration |
|
Hub Transport |
12 cores |
4 cores |
16GB |
1 GB per core or 8GB (minimum) |
|
Client Access Server |
12 cores |
8 cores |
16GB |
2GB per core or 8GB (minimum) |
|
Mailbox |
12 cores |
8 cores |
64GB |
4GB plus 2-10MB per mailbox |
|
Unified Messaging |
12 cores |
8 cores |
16GB |
2GB per core or 4GB (minimum) |
|
Multiple Role Server |
24 cores |
8 cores |
64GB |
8GB plus 2-10MB per mailbox |
Table 1
There are also some role ratio guidelines that should be met:
|
CAS : Mailbox |
§ 3 : 4 |
|
HUB : Mailbox |
§ 1 : 7 (no A/V on Hub) § 1 : 5 (with A/V Hub) |
|
GC : Mailbox |
§ 1 : 4 (32–bit GC) § 1 : 8 (64-bit GC) |
Table 2
Mailbox Role
Let’s start by the Mailbox server role, since this is the king of all roles. It’s one of the three mandatory roles (the other ones are CAS and Hub) and it’s where all the user data will be stored.
Before entering technical details, I strongly advise you to use the Exchange 2010 Mailbox Server Role Requirements Calculator to size the Mailbox role. If you prefer to do it manually, then continue reading.
User profile usually determines resource requirements, but you should take into account some factors that influence sizing, such as:
- Number of mailboxes
- Security/auditing mechanisms
- Use of mobile devices
- Outlook mode (online/cached)
- Archiving/Messaging Record Management
- High Availability (DAG)
CPU
- Estimated Per-Mailbox CPU Consumption:
|
Messages Sent+Received |
Megacycles for active or stand-alone mailbox |
Megacycles for passive mailbox |
|
50 |
1 |
.15 |
|
100 |
2 |
.3 |
|
150 |
3 |
.45 |
|
200 |
4 |
.6 |
|
250 |
5 |
.75 |
|
300 |
6 |
.9 |
|
350 |
7 |
1.05 |
|
400 |
8 |
1.2 |
|
450 |
9 |
1.35 |
|
500 |
10 |
1.5 |
Table 3
Memory
To size the necessary amount of RAM, first determine the amount of required database cache by multiplying the mailbox count by the memory requirements based on the user profile. The following table provides estimated values of database cache per mailbox, based on message activity:
|
Messages Sent+Received |
Database cache per mailbox (MB) |
|
50 |
3 |
|
100 |
6 |
|
150 |
9 |
|
200 |
12 |
|
250 |
15 |
|
300 |
18 |
|
350 |
21 |
|
400 |
24 |
|
450 |
27 |
|
500 |
30 |
Table 4
After determining the database cache size, the next step is to determine the necessary RAM per server to ensure the database cache size requirements can be met.
|
Server Installed Physical Memory |
Database Cache Size (Mailbox Role Only) |
Database Cache Size (Multi-role) |
|
2GB |
512MB |
Not supported |
|
4GB |
1GB |
Not supported |
|
8GB |
3.6GB |
2GB |
|
16GB |
10.4GB |
8GB |
|
24GB |
17.6GB |
14GB |
|
32GB |
24.4GB |
20GB |
|
48GB |
39.2GB |
32GB |
|
64GB |
53.6GB |
44GB |
|
96GB |
82.4GB |
68GB |
Table 5
For example:
- 1000 users with the 50 profile (3MB per mailbox): 1000 x 3MB = 3GB
- 3GB fits in 3.6GB default cache
- Deploy 8GB of RAM
Network
- 1 x Gbit minimum
- DAG – each server should have at least two networks: a single MAPI network and a single Replication network.
Disk
The storage for the Mailbox role must be sized for
- Capacity (GB)
- Performance (IOPS)
Capacity is sized based on user mailbox size (read Understanding Mailbox Database and Log Capacity Factors for details on required overhead).
Mailbox Size = Mailbox Limit + Whitespace + Dumpster
Performance sizing is based on user profile (message activity).
Database Volume I/O = Number of Mailboxes x IOPS Profile
The following table provides per mailbox estimated IOPS based on user profile and message activity
|
Messages Sent+Received |
Estimated IOPS: Single database copy |
Estimated IOPS: Multiple database copies |
|
50 |
.060 |
.050 |
|
100 |
.120 |
.100 |
|
150 |
.180 |
.150 |
|
200 |
.240 |
.200 |
|
250 |
.300 |
.250 |
|
300 |
.360 |
.300 |
|
350 |
.420 |
.350 |
|
400 |
.480 |
.400 |
|
450 |
.540 |
.450 |
|
500 |
.600 |
.500 |
Table 6
Hub & Edge Role
CPU
|
With A/V and A/S |
Without A/V and A/S |
|
|
Recommended processor cores / server |
8 |
4 |
|
Hub Cores : mailbox server cores ratio |
1:5 |
1:7 |
Table 7
Memory
- 4GB min, 8GB max
- 1GB/core
Disk
- Use battery-backed write cache disk controller
o Disk I/O can be a bottleneck on an un-tuned Hub
o Log I/O becomes virtually free with a BBWC controller - Size storage capacity for queue requirements
- Capacity = average message size x maximum queue
- Separate mail.que and logs from system disks (RAID 10)
- Back Pressure:500 MB minimum free space
Network
- Gbit recommended
CAS Role
- CPU and memory are key for CAS
- Performance impact on CAS server is dependent on user profiles and mix of workloads
- CPU and memory scale guidance for CAS based on assumptions of a mixed-protocol heavy information worker profile
o Consider other workloads and adjust
o Remember all MAPI traffic now affects CAS - Use Windows Server 2008 R2 for best CAS scale
o Major improvements in rpcproxy (Outlook Anywhere)
|
CAS Workload Relative Cost Comparison |
||
|
Workload |
CPU Cost (MHz/user) |
Network Cost (Kbytes/sec/user) |
|
Outlook |
0.35 |
0.37 |
|
Outlook Anywhere |
0.80 |
0.44 |
|
Exchange ActiveSync |
1.60 |
1.04 |
|
Exchange Web Services (Microsoft Entourage) |
0.71 |
0.54 |
|
Outlook Web Access |
0.86 |
0.88 |
|
IMAP4* |
0.86 |
0.14 |
|
POP3* |
0.33 |
0.79 |
Table 8
CPU
- 2 core minimum
- Up to 12 cores
- 3:4 CAS:Mailbox cores
Memory
- 2GB/core
- 8GB min, 16GB max
Disk
- There are no special needs regarding the disk subsystem
Network
- Gbit recommended
UM Role
- CPU and network are key for UM
- Scale out UM servers based on concurrent call requirements
- Size CPU based on requirements for Voice Mail Preview:~1 message/min/core
- 2-socket platform best for perf/TCO
- Default 100 concurrent calls/server (inbound or outbound)
CPU
- 2 core minimum
- Up to 12 cores
Memory
- 2GB/core (4GB minimum)
- 8GB maximum
Disk
- UM doesn’t have significant storage requirements
Network
- Gbit recommended
Virtualization
Since virtualization is becoming popular in Exchange deployments, here are a few guidelines and recommendations:
- Size for physical resources, add ~12% CPU overhead for hypervisor
- Don’t oversubscribe resources
o Disable dynamic memory - Server Virtualization Validation Program (SVVP) Support Policy Wizard helps to determine supported configurations
- Be aware of major support limitations
o Root clustering + DAG
o Snapshots & differencing disks - Important TechNet articles:
o Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments
o Exchange 2010 System Requirements
Validating the Solution
Before putting your newly sized servers in production, maybe you want to spend some time validating the deployed configuration. There are some tools from Microsoft that can help you with that task:
- Microsoft Exchange Server Jetstress2010 – Jetstress simulates the Exchange database and log file loads produced by a specific number of users, thus allowing you to verify the performance and stability of your disk subsystem before putting your server into a production environment.
- Exchange Load Generator – The Load Generator (LoadGen) tool is designed to produce a simulated client workload against a test Exchange deployment. This workload can be used to evaluate how Exchange performs, and can also be used to analyze the effect of various configuration changes on Exchange behavior and performance while the system is under load. The documentation for LoadGen describes how to configure and execute a load test against an Exchange server. LoadGen is capable of simulating Microsoft Office Outlook 2003 (online and cached), Outlook 2007 (online and cached), POP3, IMAP4, SMTP, ActiveSync, and Outlook Web App client activity. It can be used to generate a single-protocol workload, or these client protocols can be combined in some form to generate a multi-protocol workload.
- Exchange Server Profile Analyzer – Use the Microsoft Exchange Server Profile Analyzer tool to collect estimated statistical information from a single mailbox store or across an Exchange Server organization. The collected data can be used for such tasks as analyzing the performance and health of a server that has mailboxes, improving capacity planning models, and improving testing methodologies and tools.
- Performance Monitor – Part of the Operating System,PerfMon uses the Exchange performance objects to retrieve counter information, provides information that allows you to gauge the health of your messaging solution.
Third-Party Tools
Nowadays, most of major hardware vendors have tools that facilitate the sizing process of the whole messaging infrastructure. Below you can find some of these tools from 2 of those hardware vendors (descriptions taken from the vendors’ website).
- Dell Exchange 2010 Advisor – The Dell Exchange Advisor tool is subject to change without notice and is provided as-is without warranty of any kind, express or implied. Dell does not make any representations regarding the use, validity, accuracy or reliability of the tool or the results of the use of the Tool. The entire risk arising out of the use of this tool remains solely with the customer. In no event shall Dell be liable for any direct, consequential, incidental, special, punitive or other damages, even if Dell is negligent or has been advised of the possibility of such damages, arising from use of the tool or the information provided herein. This tool is not for use by or for Individual/Consumer purposes.
- HP Sizer for Microsoft Exchange Server 2010 – Microsoft® Exchange Server 2010 is a complex application that requires intensive knowledge of deployment strategies, interdependencies, server and storage performance related issues. HP has developed the HP Sizer for Microsoft Exchange Server 2010 to assist customers with proper server and storage sizing for their Exchange Server 2010 deployments. The algorithms developed and implemented in this tool are based upon extensive testing of Exchange Server 2010 server roles and technologies, HP’s deep experience with Microsoft Exchange, and intricate knowledge of server CPU, memory, and I/O subsystems. This tool is free to download and use, and is designed to simplify configuration across a broad range of deployments. This newest Microsoft Exchange Server Sizer provides support for multiple site deployments, varied client types and access methods, all Exchange Server 2010 server roles, Database Availability Group (DAG) high availability options, choice of tower, rack mounted, or HP BladeSystem server platforms, and either direct attached or SAN-based storage solutions. Based on your input, the tool provides a comprehensive bill of materials along with a deployment overview of the Exchange Server 2010 server roles and storage configurations. Once this Sizer is installed, updates can be downloaded automatically to the underlying software engines that are necessary to provide support for HP server and storage product information details.
Conclusion
Exchange sizing and performance tuning can be a complex job, fortunately there are several tools provided by Microsoft and third-parties that can assist you with that task. Although manually sizing an Exchange infra-structure can be fun, my advice is to use all the technical tools available, but always with the vague knowledge of the algorithms that support them.
Related Links
