After
decisions have been made about AD design, Exchange server placement,
and client access, optimization of the Exchange server itself helps
ensure efficiency, reliability, and security for the messaging platform.
Designing an Optimal Operating System Configuration for Exchange Server
As previously mentioned,
Exchange Server 2010 only operates on the Windows Server 2008 (Service
Pack 2 or later) or Windows Server 2008 R2 operating systems. The
enhancements to the operating system, especially in regard to security,
make Windows Server 2008 the optimal choice for Exchange Server. The
Standard Edition of Windows Server 2008 is sufficient for any Exchange
Server installation.
Note
Contrary
to popular misconception, the Enterprise Edition of Exchange Server can
be installed on the Standard Edition of the operating system, and vice
versa. Although there has been a lot of confusion on this concept, both
versions of Exchange Server were designed to interoperate with either
version of Windows.
Configuring Disk Options for Performance
The single most
important design element that improves the efficiency and speed of
Exchange Server is the separation of the Exchange Server database and
the Exchange Server logs onto a separate hard drive volume. Because of
the inherent differences in the type of hard drive operations performed
(logs perform primarily write operations, databases primarily read),
separating these elements onto separate volumes dramatically increases
server performance. Figure 1 illustrates some examples of how the database and log volumes can be configured.
On Server1, the OS and
logs are located on the same mirrored C:\ volume and the database is
located on a separate RAID-5 drive set. With Server2, the configuration
is taken up a notch, with the OS only on C:\, the logs on D:\, and the
database on the RAID-5 E:\ volume. Finally, Server3 is configured in the
optimal configuration, with separate volumes for
each database and a volume for the log files. The more advanced a
configuration, the more detailed and complex the drive configuration can
get. However, the most important factor that must be remembered is to
separate the Exchange Server database from the logs wherever possible.
Note
With the use of
Database Availability Groups (DAGs) in Exchange Server 2010, the
performance of the disk infrastructure has become less of a concern.
DAGs enable an organization’s mailboxes to be spread across multiple
servers and to exist in multiple locations (up to 16), which reduces the
need for expensive SAN disks and enables Exchange Server to be
installed on DAS or SATA disk.
Working with Multiple Exchange Server Databases
Exchange Server 2010
Database Availability Groups (DAGs) allow for multiple databases to be
installed across multiple servers and to have multiple versions of those
databases in more than one location. This allows for the creation of
multiple large databases that reside on cheaper disks, which in turn
allows for larger mailbox sizes. It also has the following advantages:
Reduce database restore time—
Multiple databases (rather than a smaller number of larger databases)
take less time to restore from tape. This concept can be helpful if
there is a group of users who require quicker recovery time (such as
management). All mailboxes for this group could then be placed in a
separate database to provide quicker recovery time in the event of a
server or database failure.
Provide for separate mailbox limit policies—
Each database can be configured with different mailbox storage limits.
For example, the standard user database could have a 200-MB limit on
mailboxes, and the management database could have a 500-MB limit.
Mitigate risk by distributing user load—
By distributing user load across multiple databases, the risk of losing
all user mail connectivity is reduced. For example, if a single
database failed that contained all users, no one would be able to mail.
If those users were divided across three databases, however, only one
third of those users would be unable to mail in the event of a database
failure.
Monitoring Design Concepts with System Center Operations Manager 2007 R2
The enhancements to
Exchange Server 2010 do not stop with the improvements to the product
itself. New functionality has been added to the Exchange Management Pack
for System Center Operations Manager that enables OpsMgr to monitor
Exchange servers for critical events and performance data. The OpsMgr
Management Pack is preconfigured to monitor for Exchange Server-specific
information and to enable administrators to proactively monitor
Exchange servers.
