Before
delving into recommended configurations for Exchange Server 2010, it is
essential to not only understand the fundamentals of this messaging
system, but to also understand the dependencies and interactions those
components have with the underlying operating system (that is, Windows
Server 2008). Being a client/server messaging application, maximizing
Exchange Server 2010 involves fine-tuning its entire core and extended
components. Optimization of each of these components affects the overall
performance of Exchange Server.
The core components of
Exchange Server (for example, the Information Stores, connectors,
transaction logs, and more) have a direct bearing on gauging resource
requirements. The number of users in a messaging environment and the
various Exchange Server functions are equally influential.
Expected User Loads
In Exchange Server 2010,
one can predict with fair accuracy the load that will be generated by
various types of users. Consider the following information when planning
out CPU and disk configurations for an Exchange 2010 Mailbox server:
Light user – 5 receive/20 send – 0.5 MCycles/user – 0.04 IO/user/sec
Average user 10/40 – 0.9 MCycles/user – 0.08 IO/user/sec
Heavy user – 20/80 – 1.8 MCycles/user – 0.15 IO/user/sec
Very Heavy – 30/120 – 2.7 MCycles/user – 0.23 IO/user/sec
In this context, MCycles/user is the number of Mhz of processing time consumed by a user.
Mhz / MCycles per user * desired utilization = users
So a light user consuming
0.5 MCycles / user means that a 1Ghz (1,000 Mhz) CPU would support 2,000
light users at 100% CPU load. Similarly, it would only support 370 Very
Heavy users at 100% CPU load. To put things into a more realistic
perspective, a dual core 3.0Ghz processor would support:
| 2*3*1000 = 6,000 Mhz / (1.8 MCycles per user) * 0.6 (desired 60% CPU utilization) = 2000 users. |
This formula is generally
more accurate than a flat claim of “500 users per core” as it will take
into account the fact that a 3.2Ghz processor will support more users
than a 2.0Ghz processor.
Optimizing the Disk Subsystem Configuration
Many
factors, such as the type of file system to use, physical disk
configuration, database size, and log file placement, need to be
considered when you are trying to optimize the disk subsystem
configuration. The desire for performance must also be balanced with the
requirements for redundancy and revocability.
Choosing the File System
Among the file
systems supported by Windows Server 2008 (that is, FAT and NTFS), it is
recommended to use only NTFS on all Exchange Server 2010 servers. NTFS
provides the best security, scalability, and performance features. For
instance, NTFS supports file- and directory-level security, large file
sizes (files of up to 16TB), large disk sizes (disk volumes of up to
16TB), fault tolerance, disk compression, error detection, and
encryption.
Choosing the Physical Disk Configuration
Windows Server
2008, like its predecessors, supports RAID (Redundant Array of
Inexpensive Disks). The levels of RAID supported by the operating system
are as follows:
Various other levels of RAID can be supported through the use of hardware-based RAID controllers.
The deployment of the
correct RAID level is of utmost importance because each RAID level has a
direct effect on the performance of the server. From the viewpoint of
pure performance, RAID level 0 by far gives the best performance.
However, fault tolerance and the reliability of system access are other
factors that contribute to overall performance. The skillful
administrator strikes a balance between performance and fault tolerance
without sacrificing one for the other. The following sections provide
recommended disk configurations for Exchange Server 2010.
Note
As mentioned earlier,
various levels of RAID are available, but for the context of Exchange
Server 2007, there are two recommended basic levels to use: RAID 1 and
RAID 5. Other forms of RAID, such as RAID 0+1 or 1+0, are also optimal
solutions for Exchange Server 2007. These more advanced levels of RAID
are supported only when using a hardware RAID controller.
Disk Mirroring (RAID 1)
In this type of
configuration, data is mirrored from one disk to the other participating
disk in the mirror set. Data is simultaneously written to the two
required disks, which means read operations are significantly faster
than systems with no RAID configuration or with a greater degree of
fault tolerance. Write performance is slower, though, because data is
being written twice; once to each disk in the mirror set.
Besides
adequate performance, RAID 1 also provides a good degree of fault
tolerance. For instance, if one drive fails, the RAID controller can
automatically detect the failure and run solely on the remaining disk
with minimal interruption.
The biggest drawback
to RAID 1 is the amount of storage capacity that is lost. RAID 1 uses
50% of the total drive capacity for the two drives.
Tip
RAID 1 is particularly well suited for the boot drive and for volumes containing Exchange Server 2010 log files.
Disk Striping with Parity (RAID 5)
In a RAID-5
configuration, data and parity information is striped across all
participating disks in the array. RAID 5 requires a minimum of three
disks. Even if one of the drives fails within the array, the Exchange
Server 2010 server can still remain operational.
After the drive
fails, Windows Server 2008 continues to operate because of the data
contained on the other drives. The parity information gives details of
the data that is missing because of the failure. Either Windows Server
2008 or the hardware RAID controller also begins the rebuilding process
from the parity information to a spare or new drive.
RAID 5 is most commonly
used for the data drive because it is a great compromise among
performance, storage capacity, and redundancy. The overall space used to
store the striped parity information is equal to the capacity of one
drive. For example, a RAID-5 volume with three 200-GB disks can store up
to 400GB of data.
Tip
Although RAID 5
has a significant performance penalty for disk activity that has a large
percentage of writes, this can be mostly compensated for via caching on
the RAID controller. This allows the writes to be done in cache and
later be committed to disk. If you are going to utilize write caching on
your RAID controller, ensure that the cache is protected by a battery.
Otherwise a system failure could result in cached information never
getting written to disk. This is a sure way to corrupt a database.
Hardware Versus Software RAID
Hardware RAID
(configured at the disk controller level) is recommended over software
RAID (configurable from within the Windows Server 2008) because of
faster performance, greater support of different RAID levels, support
for caching, and capability of recovering from hardware failures more
easily.
Database Sizing and Optimization
As mentioned
throughout this book, Exchange Server 2010 is available in two versions:
Standard and Enterprise. The Standard Edition supports 5 databases. The
maximum Information Store (database) size is not limited with Exchange
Server 2010, Standard Edition. The Enterprise Edition provides support
for up to 150 databases per server with unlimited database size.
The flexibility
with the Enterprise Edition is beneficial not just in terms of growth
but also in terms of performance and manageability. More specifically,
the advantages for segmenting can include the following:
Administrators are enabled to segment the user population on a single Exchange server.
Multiple
mailboxes can more evenly distribute the size of the messaging data and
help prevent one database from becoming too large and possibly unwieldy
for a given system.
Multiple databases present greater opportunities for faster enumeration of database indexing.
Multiple databases can be segmented onto different RAID volumes and RAID controller channels.
Transaction logs can be segmented from other log files using separate RAID volumes.
Failures such as database corruption affect a smaller percentage of the user population.
If utilizing Database Availability Groups, there is plenty of room to support replicas for other servers.
Offline maintenance routines require less scheduled downtime, and fewer users are affected.
Tip
If using the
Enterprise Edition, the recommended best practice is to keep database
sizes in the 100GB–120GB range. This will allow Eseutils to be run in a
reasonable amount of time should they be needed. An administrator can
use this guideline to gauge or plan for the number of users each
database should optimally contain. This best practice is also useful in
determining the appropriate number of Exchange Server 2010 mailbox
servers that are required to support the number of users in the
organization.
Determining the
number of databases for Exchange Server 2010 mailbox servers should also
be based on workload characterization. Users can be grouped based on
how they interact with the messaging system (for example, in terms of
frequency, storage requirements, and more). Users placing higher demands
on Exchange Server 2010 can be placed into separate databases so that
the greater number of read/write operations do not occur in the same
database and are more evenly distributed. This is beneficial to
performance only if the storage groups and databases are located on
physically different disks.
If
a deployment calls for a large number of databases, it is necessary to
mount disks as mount points rather than as drive letters or you would
quickly run out of drive letters before utilizing all 150 of your
potential databases, depending on how the databases were laid out across
your disks. This becomes very noticeable in situations where a SAN is
utilized as most often the databases would live on unique LUNs within
volumes to align with storage snapshot behaviors.
Optimizing Exchange Server Logs
Similar to the
previous versions of Exchange Server, transaction log files should be
stored on separate RAID volumes. This enables significant improvements
in disk input/output (I/O) operations. Transaction logs are created on a
per–storage group level rather than per database. Therefore, when you
have multiple storage groups, multiple log files are created that enable
simultaneous read and write operations. If the transaction logs are
then placed on separate RAID volumes, there can be significant
improvements to performance. This recommendation applies to Exchange
Server 2010 mailbox servers that are not utilizing DAG.
Tip
Because transaction logs
are as important to Exchange Server 2010 as the data contained in the
databases, the most suitable RAID configuration to use for transaction
log files is RAID 1. This provides suitable performance without
sacrificing fault tolerance. Because the logs are written sequentially,
they require significantly fewer disks than a database would to achieve
sufficient I/O capacity.
Sizing Memory Requirements
The recommended starting
point for the amount of memory for an Exchange Server 2010 server is 2GB
of RAM per server + 2-4MB of RAM per user. The specific memory
requirements naturally vary based on server roles, server
responsibilities, and the number of users to support. In addition, some
organizations define certain guidelines that must be followed for base
memory configurations. A more accurate representation of how much memory
is required can be achieved by baselining memory performance
information gathered from the Performance snap-in or third-party tools
during a prototype or lab testing phase.
Another important factor
to take into consideration is when the organization adds functionality
to Exchange Server 2010 or consolidates users onto fewer servers. This
obviously increases resource requirements, especially in terms of adding
more physical memory. In these scenarios, it is recommended to use the
base amount of memory (for example, 8GB) and then add the appropriate
amount of memory based on vendor specifications. It is also important to
consult with the vendor to determine what the memory requirements might
be on a per user basis. This way, the organization can plan ahead and
configure the proper amount of memory prior to needing to scale to
support a larger number of users in the future.
Sizing Based on Server Roles
Server
roles can have a considerable bearing on both the performance and
capacity of Exchange Server 2010. Based on the various roles of the
Exchange servers, the strategic placement of Exchange Server services
and functionality can greatly improve performance of the overall
messaging system while reducing the need for using additional resources.
By the same token, a misplaced Exchange Server service or functional
component can noticeably add to network traffic and degrade the overall
performance of the messaging system.
Servers are divided into
five roles: client access servers, mailbox servers, Hub Transport
servers, Edge Transport servers, and Unified Messaging servers.
Mailbox Server Sizing
Various factors affect the performance of a mailbox server, including the following:
The number and type of protocols supported
The number of users supported
The authentication methods supported
Encryption requirements
Table 1
shows the recommended resource requirements of mailbox servers. It is
important to note that these guidelines are minimum recommendations, and
actual requirements might vary depending upon the organization.
Table 1. Recommended Minimum Mailbox Server Configurations
| Resource | Description |
|---|
| RAM | 2GB + 2-4MB/user |
| Processor | Pentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor |
| Hard disk | RAID 1 for Windows Server 2008 and Exchange Server 2010
RAID 0+1 for mailbox data |
| Network | Gigabit Ethernet NIC(s) |
| Other considerations | If connections to this server are over SSL, consider using a NIC that off-loads SSL processing |
Client Access Server Sizing
Various factors affect the performance of a client access server, including the following:
The number and type of protocols supported
The number of type of applications supported
The number of users supported
The authentication methods supported
Encryption requirements
Table 2
shows the recommended resource requirements of client access servers.
It is important to note that these guidelines are minimum
recommendations, and actual requirements might vary depending upon the
organization.
Table 2. Recommended Minimum Client Access Server Configurations
| Resource | Description |
|---|
| RAM | 2GB |
| Processor | Pentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor |
| Hard disk | RAID 1 for Windows Server 2008 and Exchange Server 2010 |
| Network | Gigabit Ethernet NIC(s) |
| Other considerations | If connections to this server are over SSL, consider using a NIC that off-loads SSL processing |
Hub Transport Server Sizing
Various factors affect the performance of a Hub Transport server, including the following:
The number and type of protocols supported
The number of users supported
The authentication methods supported
Encryption requirements
Table 3
shows the recommended resource requirements of a Hub Transport server.
It is important to note that these guidelines are minimum
recommendations, and actual requirements might vary depending upon the
organization.
Table 3. Recommended Minimum Hub Transport Server Configurations
| Resource | Description |
|---|
| RAM | 2GB |
| Processor | Pentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor |
| Hard disk | RAID 1 for Windows Server 2008 and Exchange Server 2010 |
| Network | Gigabit Ethernet NIC(s) |
| Other considerations | If connections to this server are over SSL, consider using a NIC that off-loads SSL processing |
Edge Transport Server Sizing
Various factors affect the performance of an Edge Transport server, including the following:
The number of messages sent and received
The types of rules implemented
The types of filtering performed
Encryption requirements
Table 4
shows the recommended resource requirements of an Edge Transport
server. It is important to note that these guidelines are minimum
recommendations, and actual requirements might vary depending upon the
organization.
Table 4. Recommended Minimum Edge Transport Server Configuration
| Resource | Description |
|---|
| RAM | 2GB |
| Processor | Pentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor |
| Hard disk | RAID 1 for Windows Server 2008 and Exchange Server 2010 |
| Network | Gigabit Ethernet NIC(s) |
| Other considerations | If extensive content rules will be applied, consider a dual-core processor |
Unified Messaging Server Sizing
Various factors affect the performance of a Unified Messaging server, including the following:
The number and type of codecs supported
The number of users supported
The type of phone system integrated with
Table 5
shows the recommended resource requirements of a Unified Messaging
server. It is important to note that these guidelines are minimum
recommendations, and actual requirements might vary depending upon the
organization.
Table 5. Recommended Minimum Unified Messaging Server Configurations
| Resource | Description |
|---|
| RAM | 2GB |
| Processor | Pentium IV 3.4GHz or higher processor with E64MT support or equivalent AMD processor |
| Hard disk | RAID 1 for Windows Server 2008 and Exchange Server 2007 |
| Network | Gigabit Ethernet NIC(s) |
| Other considerations | Use of very high-compression audio codecs might increase the minimum CPU requirements |
Combined Role Server Sizing
Various factors affect the performance of an Exchange Server 2010 server with combined roles, including the following:
The number and type of protocols supported
The number of users supported
The authentication methods supported
Encryption requirements
Table 6
shows the recommended resource requirements of a combined role Exchange
Server 2010 server. It is important to note that these guidelines are
minimum recommendations, and actual requirements might vary depending
upon the organization.
Table 6. Recommended Minimum Combined Server Configuration
| Resource | Description |
|---|
| RAM | 4GB +2-4MB per user |
| Processor | Pentium IV 3.4GHz or higher processor with E64MT support or equivalent AMD processor |
| Hard disk | RAID 1 for Windows Server 2008 and Exchange Server 2010
RAID 0+1 for mailbox data |
| Network | Gigabit Ethernet NIC(s) |
| Other considerations | If a large number of functions run on this system, consider implementing multi-core processors for added processing power |
