Designing an Optimal Operating System Configuration for Exchange
Exchange Server 2007 only operates on the Windows
Server 2003 operating system, and is scheduled to be able to run on the
next version of the Windows Server operating system, currently referred
to as Windows Longhorn. The enhancements to the operating system,
especially in regard to security, make Windows Server 2003 the optimal
choice for Exchange. Unless clustering (including Cluster Continuous
Replication) is required, which is not common for smaller organizations,
the Standard Edition of Windows Server 2003 can be installed as the OS.
Note
Contrary to
popular misconception, the Enterprise Edition of Exchange 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 were designed to interoperate with either version
of Windows.
Avoiding Virtual Memory Fragmentation Issues
The previous
iterations of Windows Server have suffered from a problem with virtual
memory (VM) fragmentation. The problem would manifest itself on systems
with greater than 1GB of RAM, which run memory-intensive applications
such as SQL Server or Exchange. The Advanced Server Edition of Windows
2000 Server enabled a workaround for this problem, in the form of a
memory allocation switch that allocated additional memory for the user
kernel.
Windows Server 2003
includes the capability of using this memory optimization technique in
both the Standard and the Enterprise Editions of the software, so that
the switch can now be used on any Windows Server 2003 system with more
than 1GB of physical RAM. The switch is added to the end of the boot.ini file.
The /3GB switch tells Windows to allocate 3GB of memory for the user kernel, and the /USERVA=3030
switch optimizes the memory configuration, based on tests performed by
Microsoft that determined the perfect number of megabytes to allocate
for optimal performance and the least likely instance of VM
fragmentation. This setting only applies to the 32-bit version of
Windows 2003, so it would not apply to Exchange 2007 servers but would
apply to 32-bit domain controllers and any other supporting 32-bit
servers in an Exchange 2007 environment.
Configuring Disk Options for Performance
The single most
important design element, which improves the efficiency and speed of
Exchange, is the separation of the Exchange database and the Exchange
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. Keep these components separate in even the smallest
Exchange server implementations. 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
database from the logs wherever possible.
Working with Multiple Exchange Databases and Storage Groups
The Enterprise Edition
of Exchange Server 2007 not only enables databases of larger than 75GB,
it also enables the creation of multiple separate databases on a single
server. This concept gives great flexibility in design while enabling
reduced downtime and increased performance.
A
storage group is a logical grouping of databases that share a single
set of logs. Each Exchange Server 2007 Enterprise system can handle a
maximum of 50 storage groups per server. Each storage group can contain a
maximum of five databases each, although the total number of databases
on a server cannot equal more than 50.
Note
If Cluster Continuous
Replication (CCR) is to be used, it is important to note that CCR only
supports a single database per storage group. Also, Microsoft recommends
no more than 30 databases on a server running CCR.
In practice, however,
each instance of a storage group that is created uses a greater amount
of resources, so it is wise to create additional storage groups only if
absolutely necessary. Multiple databases, on the other hand, can solve
several problems:
Reduce database restore time—
Smaller 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.
Note
One disadvantage
to multiple databases is that the concept of single-instance storage is
lost across databases. Single-instance storage occurs when only one
copy of an email message sent to multiple people is stored on the
server, dramatically reducing the space needed to store mass mailings.
Each separate database must keep a copy of mass mailings, however, which
increases the aggregate total size of the databases.
Understanding Clustering for Exchange Server 2007
Exchange Server 2007
is configured to use Windows Server 2003 clustering for enhanced
redundancy and increased uptime. Clustering is an expensive option, but
one that will increase reliability of the Exchange Server 2007
implementation.
Clustering
options with Exchange Server 2007 have significantly changed over those
available in previous versions. Traditional, shared storage clustering
is now referred to as a Single Copy Cluster. New options for clustering
databases across geographical locations automatically using asynchronous
synchronization of log files is now available and is referred to as
Cluster Continuous Replication (CCR).
Note
Microsoft no longer
supports a full active-active clustering configuration. Consequently, at
least one cluster node should be configured as passive. With eight-way
clustering, for example, this means that seven nodes can be active and
one node must be passive.
Monitoring Design Concepts with Microsoft Operations Manager 2005
The enhancements to
Exchange Server 2007 do not stop with the improvements to the product
itself. New functionality has been added to the Exchange Management Pack
for Microsoft Operations Manager (MOM) that enables MOM to monitor
Exchange servers for critical events and performance data. The MOM
Management Pack is preconfigured to monitor for Exchange-specific
information and to enable administrators to proactively monitor Exchange
servers.
