Programming4us
         
 
 
Applications Server

Optimizing an Exchange Server 2007 Environment : Properly Sizing Exchange Server 2007

12/1/2011 9:14:32 AM
Before delving into recommended configurations for Exchange Server 2007, 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 2003). Being a client/server messaging application, maximizing Exchange Server 2007 involves fine-tuning all of its core and extended components. Optimization of each of these components affects the overall performance of Exchange.

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 functions are equally influential.

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 2003 (that is, FAT and NTFS), it is recommended to use only NTFS on all Exchange 2007 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 2003, like its predecessors, supports RAID (Redundant Array of Inexpensive Disks). The levels of RAID supported by the operating system are as follows:

  • RAID 0 (Striping)

  • RAID 1 (Mirroring)

  • RAID 5 (Striping with parity)

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 2007.

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 2007 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 2007 server can still remain operational.

After the drive fails, Windows Server 2003 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 2003 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 2003) 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

Exchange Server 2007 is available in two versions: Standard and Enterprise. The Standard Edition supports one storage group with one private and one public Information Store. The maximum Information Store (database) size is 75GB with Exchange Server 2007, Standard Edition. The Enterprise Edition provides support for up to 50 storage groups with a combined total of 50 usable databases per server with practically unlimited database size. Technically, the databases are limited to 16,000GB but it’s unlikely that you’ll grow them that large. Unlike with previous versions of Exchange, it is currently recommended that for performance and recoverability purposes, you should only place one database into each storage group.

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.

  • 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 10GB–20GB range. 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 2007 Mailbox servers that are required to support the number of users in the organization.


Determining the number of storage groups and databases for Exchange Server 2007 Mailbox servers should also be based on workload characterization. Users can be grouped based on the how they interact with the messaging system (for example, in terms of frequency, storage requirements, and more). Users placing higher demands on Exchange Server 2007 can be placed into a separate storage group and 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 storage groups and 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 50 of your potential storage groups.

Optimizing Exchange Logs

Similar to the previous versions of Exchange, 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.

Tip

Because transaction logs are as important to Exchange Server 2007 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 2007 server is 2GB of RAM per server + 5MB 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 2007 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 2007. Based on the various roles of the Exchange servers, the strategic placement of Exchange 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 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
ResourceDescription
RAM2GB + 5MB/user
ProcessorPentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor
Hard diskRAID 1 for Windows Server 2003 RAID 0+1 for mailbox data
NetworkGigabit Ethernet NIC(s)
Other considerationsIf 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
ResourceDescription
RAM1GB
ProcessorPentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor
Hard diskRAID 1 for Windows Server 2003 and Exchange Server 2007
NetworkGigabit Ethernet NIC(s)
Other considerationsIf 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
ResourceDescription
RAM1GB
ProcessorPentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor
Hard diskRAID 1 for Windows Server 2003 and Exchange Server 2007
NetworkGigabit Ethernet NIC(s)
Other considerationsIf 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
ResourceDescription
RAM1GB
ProcessorPentium IV 3.0GHz or higher processor with E64MT support or equivalent AMD processor
Hard diskRAID 1 for Windows Server 2003 and Exchange Server 2007
NetworkGigabit Ethernet NIC(s)
Other considerationsIf extensive content rules will be applied, consider a dual-core processor

Unified Messenger 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
ResourceDescription
RAM1GB
ProcessorPentium IV 3.4GHz or higher processor with E64MT support or equivalent AMD processor
Hard diskRAID 1 for Windows Server 2003 and Exchange Server 2007
NetworkGigabit Ethernet NIC(s)
Other considerationsUse of very high-compression audio codecs might increase the minimum CPU requirements

Combined Role Server Sizing

Various factors affect the performance of an Exchange 2007 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 2007 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
ResourceDescription
RAM3GB +5MB per user
ProcessorPentium IV 3.4GHz or higher processor with E64MT support or equivalent AMD processor
Hard diskRAID 1 for Windows Server 2003 and Exchange Server 2007 RAID 0+1 for mailbox data
NetworkGigabit Ethernet NIC(s)
Other considerationsIf there will be a large number of functions run on this system, consider implementing a dual-core processor for added processing power
Other -----------------
- Optimizing an Exchange Server 2007 Environment : Analyzing and Monitoring Core Elements
- SharePoint 2010 : Using Data Connection Libraries (part 1) - Connecting to Data Using Alternative Credentials & Configuring the Secure Store Service
- SharePoint 2010 : Using Data Connection Libraries (part 1) - Restricting Data Connection Types & Adding Connections to Data Connection Libraries
- SharePoint 2010 : Excel Services - Using the JavaScript Object Model
- Optimizing Exchange 2007 Servers & Monitoring Exchange Server 2007
- Optimizing an Exchange Server 2007 Environment : Analyzing Capacity and Performance
- Exchange Server 2010 : Planning Certificates for Autodiscover (part 2) - Deploying Exchange Certificates
- Exchange Server 2010 : Planning Certificates for Autodiscover (part 1) - The X.509 Certificate Standard
- Exchange Server 2010 Autodiscover : Autodiscover Concepts
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 5) - Protecting DCs as Virtual Machines
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 4) - Performing Proactive Restores
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 3) - Relying on Windows Server Backup to Protect the Directory
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 2) - Relying on Built-in Directory Protection Measures
- Active Directory 2008 : Proactive Directory Maintenance and Data Store Protection (part 1) - Twelve Categories of AD DS Administration
- BizTalk 2009 : The BizTalk Management Database
- BizTalk 2009 : Handling Failed Messages and Errors
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 3) - Additional steps
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 2) - Loading sample company data & Creating a new Dynamics GP company
- Microsoft Dynamics GP 2010 : Dynamics GP Utilities (part 1) - Completing the Dynamics GP installation
- Microsoft Dynamics GP 2010 : Creating an ODBC data source
 
 
Most View
- How to Approach Disaster Recovery
- Microsoft SQL Server 2008 R2 : Setting Up Replication (part 1) - Creating a Distributor and Enabling Publishing
- Navigating the Central Administration Home Page (part 2)
- Programming WCF Services : Data Contracts - Collections (part 2) - The CollectionDataContract Attribute & Dictionaries
- Adding Macs to Your Windows 7 Network : Connecting to a Windows Shared Folder
- SharePoint 2010 : Making Enterprise Content Management Work - Records Management (part 2) - Configuring Enterprise Document and Records Management
- SharePoint 2010 : Office 2010 Client Applications (part 2) - Documents and Data Caching
- Using asynchronous services in BizTalk with WCF (part 2) - Exposing asynchronous services
- Windows 7 : Configuring the Fax Service
- Windows Server 2008 : Configuring Remote Access (part 1) - Routing and Remote Access Services
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS