Exchange 2010 Tested Solutions: 15000 Mailboxes in Two Sites Running Hyper-V on Unisys ES7000 Servers and Hitachi Adaptable Modular Storage 2000 Family

 

Letztes Änderungsdatum des Themas: 2016-12-14

Rob Simpson, Program Manager, Microsoft Exchange; Ted Buiting, Director Communication & Collaboration Solutions, Unisys; Linda Krasinski, Senior Engineer Communication Solutions Performance, Test & Engineering, Unisys; Steve Burns, Solutions Engineer, Hitachi Data Systems

February 2011

Zusammenfassung

In Exchange 2010 Tested Solutions, Microsoft and participating server, storage, and network partners examine common customer scenarios and key design decision points facing customers who plan to deploy Microsoft Exchange Server 2010. Through this series of white papers, we provide examples of well-designed, cost-effective Exchange 2010 solutions deployed on hardware offered by some of our server, storage, and network partners.

You can download this document from the Microsoft Download Center.

Applies To

Microsoft Exchange Server 2010 release to manufacturing (RTM)

Microsoft Exchange Server 2010 with Service Pack 1 (SP1)

Windows Server 2008 R2

Windows Server 2008 R2 Hyper-V

Table of Contents

• Einführung

• Solution Summary

• Customer Requirements

  • Mailbox Profile Requirements

  • Geographic Location Requirements

  • Server and Data Protection Requirements

• Design Assumptions

  • Server Configuration Assumptions

  • Storage Configuration Assumptions

• Solution Design

  • Determine High Availability Strategy

  • Estimate Mailbox Storage Capacity Requirements

  • Estimate Mailbox I/O Requirements

  • Determine Storage Type

  • Choose Storage Solution

  • Estimate Mailbox Memory Requirements

  • Estimate Mailbox CPU Requirements

  • Determine Whether Server Virtualization Will Be Used

  • Determine Whether Client Access and Hub Transport Server Roles Will Be Deployed in Separate Virtual Machines

  • Determine Server Model for Hyper-V Root Server

  • Calculate CPU Capacity of Hyper-V Root Server

  • Determine CPU Capacity of Virtual Machines

  • Determine Number of Mailbox Server Virtual Machines Required

  • Determine Memory Required per Mailbox Server

  • Determine Number of Client Access and Hub Transport Combination Virtual Machines Required

  • Determine Number of Physical Servers Required

  • Determine How the Server Will Be Partitioned

  • Determine Virtual Machine Distribution

  • Determine Virtual Machine Layout

  • Identify Failure Domains Impacting Database Copy Layout

  • Design Database Copy Layout

  • Determine Storage Design

  • Determine Placement of the File Share Witness

  • Plan Namespaces

  • Determine Client Access Server Array and Load Balancing Strategy

• Solution Overview

  • Logical Solution Diagram

  • Physical Solution Diagram

  • Server Hardware Summary

  • Client Access and Hub Transport Server Configuration

  • Mailbox Server Configuration

  • Database Layout

  • Storage Hardware Summary

  • Storage Configuration

• Solution Validation Methodology

  • Storage Design Validation Methodology

  • Server Design Validation

  • Functional Validation Tests

  • Datacenter Switchover Validation

  • Primary Datacenter Service Restoration Validation

  • Test Facility

• Solution Validation Results

  • Functional Validation Results

  • Storage Design Validation Results

  • Server Design Validation Results

• Schlussbemerkung

• Weitere Informationen

Einführung

This document provides an example of how to design, test, and validate an Exchange Server 2010 solution for a customer environment with 15,000 mailboxes deployed on Unisys servers and Hitachi Data Systems storage solutions. One of the key challenges with designing Exchange 2010 environments is examining the current server and storage options available and making the right hardware choices that provide the best value over the anticipated life of the solution. Following the step-by-step methodology in this document, we walk through the important design decision points that help address these key challenges while ensuring that the customer's core business requirements are met. After we have determined the optimal solution for this customer, the solution undergoes a standard validation process to ensure that it holds up under simulated production workloads for normal operating, maintenance, and failure scenarios.

Zurück zum Seitenanfang

Solution Summary

The following tables summarize the key Exchange and hardware components of this solution.

Exchange components

Exchange component	Value or description
Target mailbox count	15000
Target mailbox size	850 megabytes (MB)
Tiered mailbox size	5000 @ 1.5 gigabytes (GB) 10000 @ 500 MB
Target message profile	50 messages per day
Total database copy count	3
High availability database copy count	3
Volume Shadow Copy Service (VSS) backup	None
Site resiliency	Yes
Virtualization	Hyper-V
Exchange server count	4
Physical server count	2

Hardware components

Hardware component	Value or description
Server partner	Unisys
Server model	ES7600 Model 7600R
Server type	Rack
Processor	Intel Xeon X7460
Storage partner	Hitachi Data Systems
Storage model	Hitachi Adaptable Modular Storage 2100
Storage type	Storage area network (SAN)
Disk type	450 GB 15,000 rpm SAS 3.5"

Zurück zum Seitenanfang

Customer Requirements

One of the most important first steps in Exchange solution design is to accurately summarize the business and technical requirements that are critical to making the correct design decisions. The following sections outline the customer requirements for this solution.

Zurück zum Seitenanfang

Mailbox Profile Requirements

Determine mailbox profile requirements as accurately as possible because these requirements may impact all other components of the design. If Exchange is new to you, you may have to make some educated guesses. If you have an existing Exchange environment, you can use the Microsoft Exchange Server Profile Analyzer tool to assist with gathering most of this information. The following tables summarize the mailbox profile requirements for this solution.

Mailbox count requirements

Mailbox count requirements	Value
Mailbox count (total number of mailboxes including resource mailboxes)	15000
Projected growth percent (%) in mailbox count (projected increase in mailbox count over the life of the solution)	0
Expected mailbox concurrency % (maximum number of active mailboxes at any time)	100%

Mailbox size requirements

Mailbox size requirements	Value
Average mailbox size in MB	850 MB
Tiered mailbox size	Yes 5000 @ 1.5 GB 10000 @ 500 MB
Average mailbox archive size in MB	0
Projected growth (%) in mailbox size in MB (projected increase in mailbox size over the life of the solution)	0
Target average mailbox size in MB	850 MB

Mailbox profile requirements

Mailbox profile requirements	Value
Target message profile (average total number of messages sent plus received per user per day)	50 messages per day
Tiered message profile	No
Target average message size in kilobytes (KB)	75
% in MAPI cached mode	0
% in MAPI online mode	0
% in Outlook Anywhere cached mode	100
% in Microsoft Office Outlook Web App (Outlook Web Access in Exchange 2007 and previous versions)	0
% in Exchange ActiveSync	0

Zurück zum Seitenanfang

Geographic Location Requirements

Understanding the distribution of mailbox users and datacenters is important when making design decisions about high availability and site resiliency.

The following table outlines the geographic distribution of people who will be using the Exchange system.

Geographic distribution of people

Mailbox user site requirements	Value
Number of major sites containing mailbox users	2
Number of mailbox users in site 1	7500
Number of mailbox users in site 2	7500

The following table outlines the geographic distribution of datacenters that could potentially support the Exchange e-mail infrastructure.

Geographic distribution of datacenters

Datacenter site requirements	Value or description
Total number of datacenters	2
Number of active mailboxes in proximity to datacenter 1	7500
Number of active mailboxes in proximity to datacenter 2	7500
Requirement for Exchange to reside in more than one datacenter	Yes

Zurück zum Seitenanfang

Server and Data Protection Requirements

It's also important to define server and data protection requirements for the environment because these requirements will support design decisions about high availability and site resiliency.

The following table identifies server protection requirements.

Server protection requirements

Server protection requirements	Value
Number of simultaneous server or virtual machine (VM) failures within site	1
Number of simultaneous server or VM failures during site failure	0

The following table identifies data protection requirements.

Data protection requirements

Data protection requirement	Value or description
Requirement to maintain a backup of the Exchange databases outside of the Exchange environment (for example, third-party backup solution)	No
Requirement to maintain copies of the Exchange databases within the Exchange environment (for example, Exchange native data protection)	Yes
Requirement to maintain multiple copies of mailbox data in the primary datacenter	Yes
Requirement to maintain copies of mailbox data in a secondary datacenter	Yes
Requirement to maintain multiple copies of mailbox data in a secondary datacenter	No
Requirement to maintain a lagged copy of any Exchange databases	No
Lagged copy period in days	Not applicable
Target number of database copies	3
Deleted Items folder retention window in days	14 days

Zurück zum Seitenanfang

Design Assumptions

This section includes information that isn't typically collected as part of customer requirements, but is critical to both the design and the approach to validating the design.

Zurück zum Seitenanfang

Server Configuration Assumptions

The following table describes the peak CPU utilization targets for normal operating conditions, and for site server failure or server maintenance conditions.

Server utilization targets

Target server CPU utilization design assumption	Value
Normal operating for Mailbox servers	<70%
Normal operating for Client Access servers	<70%
Normal operating for Hub Transport servers	<70%
Normal operating for multiple server roles (Client Access, Hub Transport, and Mailbox servers)	<70%
Normal operating for multiple server roles (Client Access and Hub Transport servers)	<70%
Node failure for Mailbox servers	<80%
Node failure for Client Access servers	<80%
Node failure for Hub Transport servers	<80%
Node failure for multiple server roles (Client Access, Hub Transport, and Mailbox servers)	<80%
Node failure for multiple server roles (Client Access and Hub Transport servers)	<80%
Site failure for Mailbox servers	<80%
Site failure for Client Access servers	<80%
Site failure for Hub Transport servers	<80%
Site failure for multiple server roles (Client Access, Hub Transport, and Mailbox servers)	<80%
Site failure for multiple server roles (Client Access and Hub Transport servers)	<80%

Zurück zum Seitenanfang

Storage Configuration Assumptions

The following tables summarize some data configuration and input/output (I/O) assumptions made when designing the storage configuration.

Data configuration assumptions

Data configuration assumption	Value or description
Data overhead factor	20%
Mailbox moves per week	1%
Dedicated maintenance or restore logical unit number (LUN)	No
LUN free space	20%
Log shipping compression enabled	Yes
Log shipping encryption enabled	Yes

I/O configuration assumptions

I/O configuration assumption	Value or description
I/O overhead factor	20%
Additional I/O requirements	None

Zurück zum Seitenanfang

Solution Design

The following section provides a step-by-step methodology used to design this solution. This methodology takes customer requirements and design assumptions and walks through the key design decision points that need to be made when designing an Exchange 2010 environment.

Zurück zum Seitenanfang

Determine High Availability Strategy

When designing an Exchange 2010 environment, many design decision points for high availability strategies impact other design components. We recommend that you determine your high availability strategy as the first step in the design process. We highly recommend that you review the following information prior to starting this step:

• Grundlegendes zu hoher Verfügbarkeit

• Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten

• Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung

Step 1: Determine whether site resiliency is required

If you have more than one datacenter, you must decide whether to deploy Exchange infrastructure in a single datacenter or distribute it across two or more datacenters. The organization's recovery service level agreements (SLAs) should define what level of service is required following a primary datacenter failure. This information should form the basis for this decision.

*Design Decision Point*

In this example, the customer has two datacenters and will deploy Exchange infrastructure in both datacenters to provide site resiliency for the messaging environment.

Step 2: Determine relationship between mailbox user locations and datacenter locations

In this step, we look at whether all mailbox users are located primarily in one site or if they're distributed across many sites and whether those sites are associated with datacenters. If they're distributed across many sites and there are datacenters associated with those sites, you need to determine if there's a requirement to maintain affinity between mailbox users and the datacenter associated with that site.

*Design Decision Point*

In this example, each datacenter is co-located with the main regional offices. There's a desire to maintain affinity between the mail users location and the location of the active copy of their mailbox during normal operating conditions.

Step 3: Determine database distribution model

Because the customer has decided to deploy Exchange infrastructure in more than one physical location, the customer needs to determine which database distribution model best meets the needs of the organization. There are three database distribution models:

• Active/Passive distribution   Active mailbox database copies are deployed in the primary datacenter and only passive database copies are deployed in a secondary datacenter. The secondary datacenter serves as a standby datacenter and no active mailboxes are hosted in the datacenter under normal operating conditions. In the event of an outage impacting the primary datacenter, a manual switchover to the secondary datacenter is performed and active databases are hosted there until the primary datacenter returns online.

  Active/Passive distribution

  

• Active/Active distribution (single DAG)   Active mailbox databases are deployed in the primary and secondary datacenters. A corresponding passive copy is located in the alternate datacenter. All Mailbox servers are members of a single database availability group (DAG). In this model, the wide area network (WAN) connection between two datacenters is potentially a single point of failure. Loss of the WAN connection results in Mailbox servers in one of the datacenters going into a failed state due to loss of quorum.

  Active/Active distribution (single DAG)

  

• Active/Active distribution (multiple DAGs)   This model leverages multiple DAGs to remove WAN connectivity as a single point of failure. One DAG has active database copies in the first datacenter and its corresponding passive database copies in the second datacenter. The second DAG has active database copies in the second datacenter and its corresponding passive database copies in the first datacenter. In the event of loss of WAN connectivity, the active copies in each site continue to provide database availability to local mailbox users.

  Active/Active distribution (multiple DAGs)

  

*Design Decision Point*

In this example, because there are two datacenter locations and active mailbox users are located in both locations, the database distribution model will be active/active. There are some additional design considerations when deploying an active/active database distribution model. Whether to deploy an active/active database distribution model with a single DAG or multiple DAGs will be determined in a later step.

Step 4: Determine backup and database resiliency strategy

Exchange 2010 includes several new features and core changes that, when deployed and configured correctly, can provide native data protection that eliminates the need to make traditional data backups. Backups are traditionally used for disaster recovery, recovery of accidentally deleted items, long term data storage, and point-in-time database recovery. Exchange 2010 can address all of these scenarios without the need for traditional backups:

• Disaster recovery   In the event of a hardware or software failure, multiple database copies in a DAG enable high availability with fast failover and no data loss. DAGs can be extended to multiple sites and can provide resilience against datacenter failures.

• Recovery of accidentally deleted items   With the new Recoverable Items folder in Exchange 2010 and the hold policy that can be applied to it, it's possible to retain all deleted and modified data for a specified period of time, so recovery of these items is easier and faster. For more information, see Messagingrichtlinie und -einhaltung, Grundlegendes zu wiederherstellbaren Elementen, and Grundlegendes zu Aufbewahrungstags und Aufbewahrungsrichtlinien.

• Long-term data storage   Sometimes, backups also serve an archival purpose. Typically, tape is used to preserve point-in-time snapshots of data for extended periods of time as governed by compliance requirements. The new archiving, multiple-mailbox search, and message retention features in Exchange 2010 provide a mechanism to efficiently preserve data in an end-user accessible manner for extended periods of time. For more information, see Grundlegendes zu persönlichen Archiven, Grundlegendes zur Suche in mehreren Postfächern, and Grundlegendes zu Aufbewahrungstags und Aufbewahrungsrichtlinien.

• Point-in-time database snapshot   If a past point-in-time copy of mailbox data is a requirement for your organization, Exchange provides the ability to create a lagged copy in a DAG environment. This can be useful in the rare event that there's a logical corruption that replicates across the databases in the DAG, resulting in a need to return to a previous point in time. It may also be useful if an administrator accidentally deletes mailboxes or user data.

There are technical reasons and several issues that you should consider before using the features built into Exchange 2010 as a replacement for traditional backups. Prior to making this decision, see Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung.

*Design Decision Point*

In this example, there is a new recovery time objective of 20 minutes. With the current Exchange implementation, the primary use of the traditional backup solution is to provide additional protection from database loss and to allow recovery from accidental deletion of mail items that aren't discovered and recovered during the seven-day deleted item retention period. The traditional backup solution doesn't meet the new recovery time objective of 20 minutes. Ninety-five percent of requests for single item recovery are for messages that are less than 15 days old. Therefore, the deleted items retention period is increased to 14 days to cover this requirement. Because traditional VSS backups don't meet the new recovery time objective, Exchange Native Data Protection will be used as the database resiliency strategy.

Step 5: Determine number of database copies required

The next important decision when defining your database resiliency strategy is to determine the number of database copies to deploy. We strongly recommend deploying a minimum of three copies of a mailbox database before eliminating traditional forms of protection for the database, such as Redundant Array of Independent Disks (RAID) or traditional VSS-based backups.

For additional information, see Grundlegendes zu Postfachdatenbankkopien.

*Design Decision Point*

In this example, the decision is made to deploy three copies of each mailbox database to ensure that the recovery time objective requirements can be met. Two copies will be located in the primary datacenter and a third copy will be located in the secondary datacenter to provide site resiliency.

Step 6: Determine database copy type

There are two types of database copies:

• High availability database copy   This database copy is configured with a replay lag time of zero. As the name implies, high availability database copies are kept up-to-date by the system, can be automatically activated by the system, and are used to provide high availability for mailbox service and data.

• Lagged database copy   This database copy is configured to delay transaction log replay for a period of time. Lagged database copies are designed to provide point-in-time protection, which can be used to recover from store logical corruptions, administrative errors (for example, deleting or purging a disconnected mailbox), and automation errors (for example, bulk purging of disconnected mailboxes).

*Design Decision Point*

In this example, all three mailbox database copies will be deployed as high availability copies. The primary need for a lagged copy would be to provide the ability to recover accidentally deleted items and to protect from logical corruption. It's much easier to recover accidentally deleted items using the deleted items retention feature. There are no applications that potentially modify messaging data and no history of logical database corruption in the environment. Therefore, the decision is made not to deploy any lagged copies.

Step 7: Determine number of database availability groups

A DAG is the base component of the high availability and site resilience framework built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that hosts a set of replicated databases and provides automatic database-level recovery from failures that affect individual servers or databases.

A DAG is a boundary for mailbox database replication, database and server switchovers and failovers, and for an internal component called Active Manager. Active Manager is an Exchange 2010 component, which manages switchovers and failovers. Active Manager runs on every server in a DAG.

From a planning perspective, you should try to minimize the number of DAGs deployed. You should consider going with more than one DAG if:

• You deploy more than 16 Mailbox servers.

• You have active mailbox users in multiple sites (active/active site configuration).

• You require separate DAG-level administrative boundaries.

• You have Mailbox servers in separate domains. (DAG is domain bound.)

*Design Decision Point*

In a previous step, it was decided to deploy an active/active database distribution model. A single DAG that has active mailbox users in each site could be deployed. However, in the event that the servers in one site temporarily lose connectively with the other servers in the DAG, the DAG members with the minority of voters will lose quorum and cease to function. For this reason, the decision is made to deploy two DAGs. Each DAG will contain member servers from the primary datacenter that will host the primary and secondary database copies. Each DAG will also contain servers in the alternate datacenter that will host the third database copy. Consider the new design as two active/passive DAGs with each datacenter hosting the primary and secondary copies from one DAG as well as the third copy from another DAG.

Step 8: Determine Mailbox server resiliency strategy

Exchange 2010 has been re-engineered for mailbox resiliency. Automatic failover protection is now provided at the mailbox database level instead of at the server level. You can strategically distribute active and passive database copies to Mailbox servers within a DAG. Determining how many database copies you plan to activate on a per-server basis is a key aspect to Exchange 2010 capacity planning. There are different database distribution models that you can deploy, but generally we recommend one of the following:

• Design for all copies activated   In this model, the Mailbox server role is sized to accommodate the activation of all database copies on the server. For example, a Mailbox server may host four database copies. During normal operating conditions, the server may have two active database copies and two passive database copies. During a failure or maintenance event, all four database copies would become active on the Mailbox server. This solution is usually deployed in pairs. For example, if deploying four servers, the first pair is servers MBX1 and MBX2, and the second pair is servers MBX3 and MBX4. In addition, when designing for this model, you will size each Mailbox server for no more than 40 percent of available resources during normal operating conditions. In a site resilient deployment with three database copies and six servers, this model can be deployed in sets of three servers, with the third server residing in the secondary datacenter. This model provides a three-server building block for solutions using an active/passive site resiliency model.

  This model can be used in the following scenarios:

  • Active/Passive multisite configuration where failure domains (for example, racks, blade enclosures, and storage arrays) require easy isolation of database copies in the primary datacenter

  • Active/Passive multisite configuration where anticipated growth may warrant easy addition of logical units of scale

  • Configurations that aren't required to survive the simultaneous loss of any two Mailbox servers in the DAG

  This model requires servers to be deployed in pairs for single site deployments and sets of three for multisite deployments. The following table illustrates a sample database layout for this model.

  Design for all copies activated

  

  In the preceding table, the following applies:

  • C1 = active copy (activation preference value of 1) during normal operations

  • C2 = passive copy (activation preference value of 2) during normal operations

  • C3 = passive copy (activation preference value of 3) during site failure event

• Design for targeted failure scenarios   In this model, the Mailbox server role is designed to accommodate the activation of a subset of the database copies on the server. The number of database copies in the subset will depend on the specific failure scenario that you're designing for. The main goal of this design is to evenly distribute active database load across the remaining Mailbox servers in the DAG.

  This model should be used in the following scenarios:

  • All single site configurations with three or more database copies

  • Configurations required to survive the simultaneous loss of any two Mailbox servers in the DAG

  The DAG design for this model requires between 3 and 16 Mailbox servers. The following table illustrates a sample database layout for this model.

  Design for targeted failure scenarios

  

  In the preceding table, the following applies:

  • C1 = active copy (activation preference value of 1) during normal operations

  • C2 = passive copy (activation preference value of 2) during normal operations

  • C3 = passive copy (activation preference value of 3) during normal operations

*Design Decision Point*

In a previous step, it was decided to deploy two DAGs with each DAG configured in an active/passive database distribution model with two high availability database copies in the primary datacenter and one high availability copy in the secondary datacenter. Because the two high availability copies in the primary datacenter are usually deployed in separate hardware failure domains, this model usually results in a Mailbox server resiliency strategy that designs for all copies being activated.

Step 9: Determine number of Mailbox servers per DAG

In this step, you need to determine the minimum number of Mailbox servers required to support the DAG design. This number may be different from the number of servers required to support the workload, so the final decision on the number of servers is made in a later step.

*Design Decision Point*

This examples uses three high availability database copies. To support three copies, a minimum of three Mailbox servers in each DAG is required. In an active/passive configuration, two of the servers will reside in the primary datacenter, and the third server will reside in the secondary datacenter. In this model, the number of servers in the DAG should be deployed in multiples of three. The following table outlines the possible configurations.

Total Mailbox server count

DAG1 primary datacenter	DAG1 secondary datacenter	DAG2 primary datacenter	DAG2 secondary datacenter	Total Mailbox server count
2	1	2	1	6
4	2	4	2	12
6	3	6	3	18

Hinweis

In a three-node DAG model, if you lose the two nodes in the primary datacenter, the cluster will lose quorum and along with it, automatic activation. So the third copy in the secondary datacenter will provide additional data availability, but recovering the service in the secondary datacenter will be a manual operation.

Zurück zum Seitenanfang

Estimate Mailbox Storage Capacity Requirements

Many factors influence the storage capacity requirements for the Mailbox server role. For additional information, we recommend that you review Grundlegendes zu Postfachdatenbank- und Protokollkapazität.

The following steps outline how to calculate mailbox capacity requirements. These requirements will then be used to make decisions about which storage solution options meet the capacity requirements. A later section covers additional calculations required to properly design the storage layout on the chosen storage platform.

Microsoft has created a Mailbox Server Role Requirements Calculator that will do most of this work for you. To download the calculator, see E2010 Mailbox Server Role Requirements Calculator. For additional information about using the calculator, see Exchange 2010 Mailbox Server Role Requirements Calculator.

Step 1: Calculate mailbox size on disk

Before attempting to determine what your total storage requirements are, you should know what the mailbox size on disk will be. A full mailbox with a 1-GB quota requires more than 1 GB of disk space because you have to account for the prohibit send/receive limit, the number of messages the user sends or receives per day, the Deleted Items folder retention window (with or without calendar version logging and single item recovery enabled), and the average database daily variations per mailbox. The Mailbox Server Role Requirements Calculator does these calculations for you. You can also use the following information to do the calculations manually.

The following calculations are used to determine the mailbox size on disk for the three mailbox tiers in this solution:

• Tier 1 (512 MB mailbox quota, 50 messages per day message profile, 75 KB average message size)

  • Whitespace = 50 messages per day × 75 ÷ 1024 MB = 3.7 MB

  • Dumpster = (50 messages per day × 75 ÷ 1024 MB × 14 days) + (512 MB × 0.012) + (512 MB × 0.058) = 87 MB

  • Mailbox size on disk = mailbox limit + whitespace + dumpster

    = 512 MB + 3.7 MB + 87 MB

    = 603 MB

• Tier 2 (1536 MB mailbox quota, 50 messages per day message profile, 75 KB average message size)

  • Whitespace = 50 messages per day × 75 ÷ 1024 MB = 3.7 MB

  • Dumpster = (50 messages per day × 75 ÷ 1024 MB × 14 days) + (1536 MB × 0.012) + (1536 MB × 0.058) = 159 MB

  • Mailbox size on disk = mailbox limit + whitespace + dumpster

    = 1536 MB + 3.7 MB + 159 MB

    = 1699 MB

Average mailbox size on disk for all tiers = (603 × 10000) + (1699 × 5000) ÷ 15000

= 968

Step 2: Calculate database storage capacity requirements

In this step, the high level storage capacity required for all mailbox databases is determined. The calculated capacity includes database size, catalog index size, and 20 percent free space.

To determine the storage capacity required for all databases, use the following formulas:

• Tier 1 (512 MB mailbox quota, 50 messages per day message profile, 75 KB average message size)

  • Database size = (number of mailboxes × mailbox size on disk × database overhead growth factor) + (20% data overhead)

    = (10000 × 603 × 1) + (1206000)

    = 7236000 MB

    = 7066 GB

  • Database index size = 10% of database size

    = 707 GB

  • Total database capacity = (database size + index size) ÷ 0.80 to add 20% volume free space

    = (7066 + 707) ÷ 0.8

    = 9717 GB

• Tier 2 (1536 MB mailbox quota, 50 messages per day message profile, 75 KB average message size)

  • Database size = (number of mailboxes × mailbox size on disk × database overhead growth factor) + (20% data overhead)

    = (5000 × 1699 × 1) + (1699000)

    = 10194000 MB

    = 9955 GB

  • Database index size = 10% of database size

    = 996 GB

  • Total database capacity = (database size + index size) ÷ 0.80 to add 20% volume free space

    = (9955 + 996) ÷ 0.8

    = 13689 GB

Total database capacity for all tiers

= 23406 GB

Step 3: Calculate transaction log storage capacity requirements

To ensure that the Mailbox server doesn't sustain any outages as a result of space allocation issues, the transaction logs also need to be sized to accommodate all of the logs that will be generated during the backup set. Provided that this architecture is leveraging the mailbox resiliency and single item recovery features as the backup architecture, the log capacity should allocate for three times the daily log generation rate in the event that a failed copy isn't repaired for three days. (Any failed copy prevents log truncation from occurring.) In the event that the server isn't back online within three days, you would want to temporarily remove the copy to allow truncation to occur.

To determine the storage capacity required for all transaction logs, use the following formulas:

• Tier 1 (512 MB mailbox quota, 50 messages per day message profile, 75 KB average message size)

  • Log files size = (log file size × number of logs per mailbox per day × number of days required to replace failed infrastructure × number of mailbox users) + (1% mailbox move overhead)

    = (1 MB × 10 × 3 × 10000) + (10000 × 0.01 × 512 MB)

    = 351200 MB

    = 343 GB

  • Total log capacity = log file size ÷ 0.80 to add 20% volume free space

    = (343) ÷ 0.80

    = 429 GB

• Tier 2 (1536 MB mailbox quota, 50 messages per day message profile, 75 KB average message size)

  • Log files size = (log file size × number of logs per mailbox per day × number of days required to replace failed infrastructure × number of mailbox users) + (1% mailbox move overhead)

    = (1 MB × 10 × 3 × 5000) + (5000 × 0.01 × 1536 MB)

    = 226800 MB

    = 221 GB

  • Total log capacity = log files size ÷ 0.80 to add 20% volume free space

    = (221) ÷ 0.80

    = 277 GB

Total log capacity for all tiers

= 706 GB

Step 4: Determine total storage capacity requirements

The following table summarizes the high level storage capacity requirements for this solution. In a later step, you will use this information to make decisions about which storage solution to deploy. You will then take a closer look at specific storage requirements in later steps.

Summary of storage capacity requirements

Disk space requirements	Value
Average mailbox size on disk (MB)	968
Database capacity required (GB)	23406
Log capacity required (GB)	706
Total capacity required (GB)	24112
Total capacity required for three database copies (GB)	72336
Total capacity required for three database copies (terabytes)	71
Total capacity required per site (terabytes)	36

Zurück zum Seitenanfang

Estimate Mailbox I/O Requirements

When designing an Exchange environment, you need an understanding of database and log performance factors. We recommend that you review Grundlegendes zu Faktoren für Datenbank- und Protokollleistung.

Calculate total mailbox I/O requirements

Because it's one of the key transactional I/O metrics needed for adequately sizing storage, you should understand the amount of database I/O per second (IOPS) consumed by each mailbox user. Pure sequential I/O operations aren't factored in the IOPS per Mailbox server calculation because storage subsystems can handle sequential I/O much more efficiently than random I/O. These operations include background database maintenance, log transactional I/O, and log replication I/O. In this step, you calculate the total IOPS required to support all mailbox users, using the following:

• Total required IOPS = IOPS per mailbox user × number of mailboxes × I/O overhead factor

  = 0.05 × 15000 × 1.2

  = 900

Hinweis

To determine the IOPS profile for a different message profile, see the table "Database cache and estimated IOPS per mailbox based on message activity" in Grundlegendes zu Faktoren für Datenbank- und Protokollleistung.

Zurück zum Seitenanfang

Determine Storage Type

Exchange 2010 includes improvements in performance, reliability, and high availability that enable organizations to run Exchange on a wide range of storage options.

When examining the storage options available, being able to balance the performance, capacity, manageability, and cost requirements is essential to achieving a successful storage solution for Exchange.

For more information about choosing a storage solution for Exchange 2010, see Speicherentwurf für Postfachserver.

Determine whether you prefer a DAS or SAN storage solution

There is a wide range of storage options available for Exchange 2010. The list of choices can be reduced by determining whether deploying a direct-attached storage (DAS) solution (including using local disk) or a SAN solution is preferred. There are many reasons for choosing one over the other, and you should work with your preferred storage vendor to determine which solution meets your business and total cost of ownership (TCO) requirements.

*Design Decision Point*

In this example, a Fibre Channel SAN storage solution is used for the current Exchange environment, and there are a number of SANs supporting other applications. A Fibre Channel SAN storage solution will continue to be used for the messaging environment.

Zurück zum Seitenanfang

Choose Storage Solution

Use the following steps to choose a storage solution.

Step 1: Identify preferred storage vendor

In this example, Hitachi Data Systems storage has been used for years. Hitachi Data Systems provides best-in-class information technologies, services, and solutions that deliver compelling customer return on investment (ROI), unmatched return on assets (ROA), and demonstrable business impact.

Hitachi Data Systems has many whitepapers describing planning and deployment of Exchange 2010 on Hitachi storage. For details, see Solutions : Microsoft Exchange.

Hitachi Data Systems actively participates in the Exchange 2007 Solution Reviewed Program (ESRP) - Storage v2.1, a program established by Microsoft to help customers evaluate the effectiveness of storage solutions in supporting highly available messaging infrastructures. Hitachi Data Systems has numerous ESRP submissions ranging from environments of 5,000 users to environments of over 100,000 users. For details, see Exchange 2010 Solution Reviewed Program (ESRP) – Storage v3.0.

Step 2: Review available options from preferred vendor

Hitachi Data Systems offers several options for Exchange 2010 storage. The choice should be based on I/O and capacity requirements as well as whether the storage system will be dedicated to Exchange 2010 or shared by multiple applications. Any of the storage systems offered by Hitachi Data Systems can be dedicated or shared depending on the size of the environment and the requirements. For information about all of the storage options available from Hitachi Data Systems, see Hitachi Data Systems Products.

For an Exchange 2010 environment with dedicated storage, the members of the Hitachi Adaptable Modular Storage family have been tested with the Microsoft ESRP program defined testing methodology for various sizes of Exchange 2010 environments.

The specifications for the members of the Hitachi Adaptable Modular Storage 2000 family are shown in the following table.

Hitachi Adaptable Modular Storage 2000 family specifications

Component	Adaptable Modular Storage 2100	Adaptable Modular Storage 2300	Adaptable Modular Storage 2500
Controller options	Symmetric active/active controllers 4 or 8 GB cache Dual redundant power supplies Dual batteries	Symmetric active/active controllers 8 or 16 GB cache Dual redundant power supplies Dual batteries	Symmetric active/active controllers 16 or 32 GB cache Dual redundant power supplies Dual batteries
Host interface options	4 x 8 gigabits per second (Gbps) Fibre Channel 8 x 8 Gbps Fibre Channel 4 x 8 Gbps Fibre Channel + 4 x 1 Gbps Internet SCSI (iSCSI)	8 x 8 Gbps Fibre Channel 16 x 8 Gbps Fibre Channel 8 x 8 Gbps Fibre Channel + 4 x 1 Gbps iSCSI	16 x 8 Gbps Fibre Channel 8 x 1 Gbps iSCSI 8 x 8 Gbps Fibre Channel + 4 x 1 Gbps iSCSI
Maximum attached host ports through virtual ports	1024	2048	2048
Data in place upgrades	To Adaptable Modular Storage 2300 or 2500	To Adaptable Modular Storage 2500	Not applicable
Drive interface	16 Serial Attached SCSI (SAS) wide links	16 Serial Attached SCSI (SAS) wide links	32 Serial Attached SCSI (SAS) wide links
RAID Levels	RAID-1, RAID-1+0, RAID-5, RAID-6 and RAID-0 (SAS drives only)	RAID-1, RAID-1+0, RAID-5, RAID-6 and RAID-0 (SAS drives only)	RAID-1, RAID-1+0, RAID-5, RAID-6 and RAID-0 (SAS drives only)
Maximum number of RAID groups	50	75	100
Maximum number of logical units (LUs)	2048	4096	4096
Maximum LU size	60 terabytes	60 terabytes	60 terabytes
Supported drives	SAS: 300 GB 15,000 rpm 450 GB 15,000 rpm 600 GB 15,000 rpm SATA-II: 1 terabyte 7,200 rpm 2 terabytes 7,200 rpm Solid-state drive (SSD): 200 GB (SAS interface)	SAS: 300 GB 15,000 rpm 450 GB 15,000 rpm 600 GB 15,000 rpm SATA-II: 1 terabyte 7,200 rpm 2 terabytes 7,200 rpm SSD: 200 GB (SAS interface)	SAS: 300 GB 15,000 rpm 450 GB 15,000 rpm 600 GB 15,000 rpm SATA-II: 1 terabyte 7,200 rpm 2 terabytes 7,200 rpm SSD: 200 GB (SAS interface)
Trays	Controller tray: 4 (minimum) to 15 (maximum) hard disk drives Expansion tray (up to 7): 2 (minimum) to 15 (maximum) hard disk drives Dense tray (up to 3): 4 (minimum) to 48 (maximum) hard disk drives Maximum of 159 total hard disk drives	Controller tray: 4 (minimum) to 15 (maximum) hard disk drives Expansion trays (up to 15): 2 (minimum) to 15 (maximum) hard disk drives Dense tray (up to 4): 4 (minimum) to 48 (maximum) hard disk drives Maximum of 240 total hard disk drives	Controller tray: 0 hard disk drives First expansion tray: 4 (minimum) to 15 (maximum) hard disk drives Up to 31 additional expansion trays, each with 2 (minimum) to 15 (maximum) hard disk drives Dense tray (up to 10): 4 (minimum) to 48 (maximum) hard disk drives Maximum of 480 total hard disk drives
Maximum capacity	313 terabytes	472 terabytes	944 terabytes

In addition to the Hitachi Adaptable Modular Storage 2000 family, the Hitachi Universal Storage Platform V, the Hitachi Universal Storage Platform VM, and the Hitachi Virtual Storage Platform enterprise class storage systems can be used for environments that require I/O performance or storage capacity greater than what the Hitachi Adaptable Modular Storage 2000 family can support.

Step 3: Select an array

In this example, the Hitachi Adaptable Modular Storage 2100 is selected for the following reasons:

• The requirements of this environment can be met by placing a Hitachi Adaptable Modular Storage 2100 at each site.

• The Hitachi Adaptable Modular Storage 2100 can be upgraded, in-place, if necessary in the future.

The Hitachi Adaptable Modular Storage 2100 is a medium-size, high-performance, highly reliable midrange storage system that can scale to 159 disks while maintaining 99.999 percent availability. It is highly suitable for a variety of applications and host platforms and is modular in scale. With the option of in-system and cross-system replication functionality, the Hitachi Adaptable Modular Storage 2100 is fully capable of being used as the core underlying storage platform for high-performance Exchange Server 2010 architectures.

The Hitachi Adaptable Modular Storage 2100 can support up to 136 SAS drives or 159 SATA drives or a mixture of SAS and SATA drives.

Step 4: Select a disk type

The Hitachi Adaptable Modular Storage 2100 supports the following disk types and sizes:

• 300 GB 15,000 rpm SAS

• 450 GB 15,000 rpm SAS

• 600 GB 15,000 rpm SAS

• 1 terabyte SATA II 7,200 rpm

• 2 terabytes SATA II ,7200 rpm

• 200 GB SSD

To help determine which disk type to choose, see Grundlegendes zur Speicherkonfiguration.

*Design Decision Point*

In this example, the 600 GB 15,000 rpm SAS disk type was selected to achieve the best mix of capacity and performance at the lowest cost. For an Exchange 2010 environment, the recommended disk type depends on the mailbox sizes and I/O profiles of the users in the environment. Hitachi Data Systems recommends SAS drives when the mailbox size is 2 GB or less.

Step 5: Determine RAID level

The Hitachi Adaptable Modular Storage 2100 supports the following RAID levels:

• RAID-0 (SAS drives only)

• RAID-1

• RAID-1+0

• RAID-5

• RAID-6

For Exchange 2010 environments, Hitachi Data System recommends RAID-5 when SAS drives are used and RAID-1+0 when SATA drives are used.

*Design Decision Point*

For this environment, RAID-5 (4D+1P) is selected for the RAID level. With Exchange 2010, a RAID-5 configuration using SAS disks will meet the I/O requirements for this environment at the lowest cost.

Step 6: Determine the number of arrays deployed

A single Hitachi Adaptable Modular Storage 2100 in each location will meet the IOPS and capacity requirements of this solution. Each storage system can be expanded or upgraded in the future as the Exchange environment grows or if the decision is made to use the storage system for additional applications. If the storage system is shared, don't place data from other applications on the same spindles as the Exchange data. Instead, create additional pools for the new application's data. Always ensure that any growth in the Exchange environment or the addition of other applications can be handled by the storage system presently in place.

*Design Decision Point*

In this example, it was decided to purchase two Hitachi Adaptable Modular Storage 2100s. This provides availability at the local site due to reliability, native support for Multipath I/O (MPIO), and 99.999 percent data availability with no single point of failure. In the event of a total site failure, the storage system at the second site can support all of the Exchange users with the same level of availability and reliability.

In a previous step, it was determined that 37 terabytes of storage capacity at each site is needed. A Hitachi Adaptable Modular Storage 2100 can meet that requirement using the drive and RAID types listed previously, with 16 RAID groups and 80 drives.

Zurück zum Seitenanfang

Estimate Mailbox Memory Requirements

Sizing memory correctly is an important step in designing a healthy Exchange environment. We recommend that you review Grundlegendes zu Speicherkonfigurationen und Exchange-Leistung and Grundlegendes zum Postfachdatenbankcache.

Calculate required database cache

The Extensible Storage Engine (ESE) uses database cache to reduce I/O operations. In general, the more database cache available, the less I/O generated on an Exchange 2010 Mailbox server. However, there's a point where adding additional database cache no longer results in a significant reduction in IOPS. Therefore, adding large amounts of physical memory to your Exchange server without determining the optimal amount of database cache required may result in higher costs with minimal performance benefit.

The IOPS estimates that you completed in a previous step assume a minimum amount of database cache per mailbox. These minimum amounts are summarized in the table "Estimated IOPS per mailbox based on message activity and mailbox database cache" in Grundlegendes zum Postfachdatenbankcache.

The following table outlines the database cache per user for various message profiles.

Database cache per user

Messages sent or received per mailbox per day (about 75 KB average message size)	Database cache per user (MB)
50	3 MB
100	6 MB
150	9 MB
200	12 MB

In this step, you determine high level memory requirements for the entire environment. In a later step, you use this result to determine the amount of physical memory needed for each Mailbox server. Use the following information:

• Total database cache = profile specific database cache × number of mailbox users

  = 3 MB × 15000

  = 45000 MB

  = 44 GB

The total database cache requirements for the environment are 44 GB.

Zurück zum Seitenanfang

Estimate Mailbox CPU Requirements

Mailbox server capacity planning has changed significantly from previous versions of Exchange due to the new mailbox database resiliency model provided in Exchange 2010. For additional information, see Kapazitätsplanung für den Postfachserverprozessor.

In the following steps, you calculate the high level megacycle requirements for active and passive database copies. These requirements will be used in a later step to determine the number of Mailbox servers needed to support the workload. Note that the number of Mailbox servers required also depends on the Mailbox server resiliency model and database copy layout.

Using megacycle requirements to determine the number of mailbox users that an Exchange Mailbox server can support isn't an exact science. A number of factors can result in unexpected megacycle results in test and production environments. Megacycles should only be used to approximate the number of mailbox users that an Exchange Mailbox server can support. It's always better to be conservative rather than aggressive during the capacity planning portion of the design process.

The following calculations are based on published megacycle estimates as summarized in the following table.

Megacycle estimates

Messages sent or received per mailbox per day	Megacycles per mailbox for active mailbox database	Megacycles per mailbox for remote passive mailbox database	Megacycles per mailbox for local passive mailbox
50	1	0.1	0.15
100	2	0.2	0.3
150	3	0.3	0.45
200	4	0.4	0.6

Step 1: Calculate active mailbox CPU requirements

In this step, you calculate the megacycles required to support the active database copies, using the following:

• Active mailbox megacycles required = profile specific megacycles × number of mailbox users

  = 1 × 15000

  = 15000

Step 2: Calculate active mailbox remote database copy CPU requirements

In a design with three copies of each database, there is processor overhead associated with shipping logs required to maintain database copies on the remote servers. This overhead is typically 10 percent of the active mailbox megacycles for each remote copy being serviced. Calculate the requirements, using the following:

• Remote copy megacycles required = profile specific megacycles × number of mailbox users × number of remote copies

  = 0.1 × 15000 × 2

  = 3000

Step 3: Calculate local passive mailbox CPU requirements

In a design with three copies of each database, there is processor overhead associated with maintaining the local passive copies of each database. In this step, you calculate the high level megacycles required to support local passive database copies. You refine these numbers in a later step so that they match the server resiliency strategy and database copy layout. Calculate the requirements, using the following:

• Local passive mailbox megacycles required = profile specific megacycles × number of mailbox users × number of passive copies

  = 0.15 × 15000 × 2

  = 4500

Step 4: Calculate total CPU requirements

Calculate the total requirements, using the following:

• Total megacycles required = active mailbox + remote passive + local passive

  = 15000 + 3000 + 4500

  = 22500

Average megacycles per mailbox = 22500 ÷ 15000 = 1.5

Zurück zum Seitenanfang

Determine Whether Server Virtualization Will Be Used

Several factors are important when considering server virtualization for Exchange. For more information about supported configurations for virtualization, see Exchange 2010 – Systemanforderungen.

The main reasons customers use virtualization with Exchange are as follows:

• If you expect server capacity to be underutilized and anticipate better utilization, you may purchase fewer servers as a result of virtualization.

• You may want to use Windows Network Load Balancing (NLB) when deploying Client Access, Hub Transport, and Mailbox server roles on the same physical server.

• If your organization is using virtualization in all server infrastructure, you may want to use virtualization with Exchange, to be in alignment with corporate standard policy.

*Design Decision Point*

In this solution, deploying additional physical hardware for Client Access servers and Hub Transport servers isn't wanted. Active/Passive site resiliency design would require several Mailbox servers to support the DAG design and database copy layout, which may result in unused capacity on the Mailbox servers. Virtualization will be used to better utilize capacity across server roles.

Zurück zum Seitenanfang

Determine Whether Client Access and Hub Transport Server Roles Will Be Deployed in Separate Virtual Machines

When using virtualization for the Client Access and Hub Transport server roles, you may consider deploying both roles on the same VM. This approach reduces the number of VMs to manage, the number of server operating systems to update, and the number of Windows and Exchange licenses you need to purchase. Another benefit to combining the Client Access and Hub Transport server roles is to simplify the design process. When deploying roles in isolation, we recommend that you deploy one Hub Transport server logical processor for every four Mailbox server logical processors, and that you deploy three Client Access server logical processors for every four Mailbox server logical processors. This can be confusing, especially when you have to provide sufficient Client Access and Hub Transport servers during multiple VM or physical server failures or maintenance scenarios. When deploying Client Access, Hub Transport, and Mailbox servers on like physical servers or like VMs, you can deploy one server with the Client Access and Hub Transport server roles for every one Mailbox server in the site.

*Design Decision Point*

The decision is to locate the Hub Transport and Client Access server roles together in the same VM. The Mailbox server role is deployed separately in a second VM. This reduces the number of VMs and operating systems to manage, and makes it much easier to plan for server resiliency.

Zurück zum Seitenanfang

Determine Server Model for Hyper-V Root Server

You can use the following steps to determine the server model for Hyper-V root servers.

Step 1: Identify preferred server vendor

In this example, the preferred server vendor is Unisys. Unisys has a history of deploying enterprise-class Exchange solutions in commercial and public sector environments worldwide, as well as for U.S. federal government entities. Unisys provides these solutions along a continuum of IT delivery options, including traditional on-premises, hosted, hosted/managed, outsourced, and public cloud. Unisys provides solutions to meet current and future needs, and performs extensive testing of best practices and optimized deployment. For more information, see Unisys.

Step 2: Review available options from preferred vendor

The Unisys portfolio of enterprise servers offers rack, blade, and scalable server technology that could be a good fit for this solution.

Option 1: Unisys ES3000 Model 3560R G2

The Unisys ES3000 Model 3560R enterprise server is suited to a variety of corporate workloads. This 2-socket, 2U Intel Xeon processor rack server is designed for deployment in a range of enterprise applications including application virtualization, e-mail, and database workloads.

Unisys ES3000 Model 3560R G2

Component	Description
Processors (x2)	Choice of up to two Intel Xeon 5600 series processors
Form factor	2U rack mount
Memory	Up to 144 GB (18 DIMM slots) 1 GB, 2 GB, 4 GB, or 8 GB DDR3 @ 800 megahertz (MHz), 1066 MHz, or 1333 MHz
Drives	Three hard disk drive cage choices: 8 x 2.5" hard disk drive option 6 x 3.5" hard disk drive option 4 x 3.5" hard disk drive option 2.5" SSD: 50 GB and 100 GB 10,000 rpm 2.5" 6 Gbps SAS: 146 GB and 300 GB 15,000 rpm 2.5" 6 Gbps SAS: 73 GB and 146 GB 7,200 rpm 2.5" 6 Gbps Near-Line SAS: 500 GB 7,200 rpm 2.5" SATA II: 80 GB, 160 GB, 250 GB 15,000 rpm 3.5" 6 Gbps SAS: 300 GB, 450 GB and 600 GB 7,200 rpm 3.5" SATA: 250 GB, 500 GB, 750 GB, 1 terabyte and 2 terabyte
I/O slots	2 x8 plus 2 x4 PCIe Gen2 slots or 1 x16 plus 2 x4 PCIe Gen2 slots
Network interfaces	Dual, embedded Broadcom NetXtreme II 5709c gigabit Ethernet network card with failover and load balancing TCP/IP Offload Engine Optional 1 gigabit and 10 gigabit add-in network cards available

Option 2: Unisys ES5000 Model 5400B G1

The ES5000 series of blade servers delivers the newest Intel processors, fast I/O, and solid availability in a space-efficient and energy-efficient chassis.

The Unisys ES5000 Model 5400B G1 server is a new design, supporting a range of workloads, including virtualization and enterprise applications.

The ES5000 Model 5400B server delivers performance through the latest Intel Xeon 6-core processors, with Quick Path Interconnect, high-speed I/O, and fast, high-capacity memory options.

Unisys ES5000 Model 5400B G1

Component	Description
Processors (x2)	Choice of up to two Intel Xeon 5600 series processors
Form factor	Blade/modular with half-height slot
Memory	12 registered Double Data Rate-3 (DDR-3) very low profile DIMM slots with up to 96 GB of total memory capacity and memory speeds up to 1333 MHz
Drives	2 hot-swap bays supporting SAS hard disk drives or solid-state drives
Expansion slots	1 CIOv slot (standard PCI-Express daughter card) and 1 CFFh slot (high-speed PCI-Express daughter card) for a total of 8 ports of I/O to each blade, including 4 ports of high-speed I/O
Network interfaces	Broadcom 57095 on-board network card with dual gigabit Ethernet ports with TCP/IP Offload Engine

Option 3: Unisys ES7000 Model 7600R

The Unisys ES7000 Model 7600R enterprise server delivers mission-critical performance in standards-based environments. With the scalability of the ES7000 Model 7600R server, you can handle complex and demanding online transaction processing (OLTP) and database environments. Designed to be highly available and scalable, the ES7000 Model 7600R server provides flexibility for current and future environments.

Unisys ES7000 Model 7600R

Component	Description
Processors	16 Intel Xeon Processor X7460 (2.66 GHz)
CPU scalability	4, 8, 12, or 16 processors (four processors per cell, one to four cells)
Form factor	Rack mount and modular 7" high x 17.6" wide x 29" deep
Partitions	One to four independent partitions
Memory	Per cell: 256 GB (8 GB DIMMs) Per system: 1 terabyte (8 GB DIMMs)
Drives	Internal hot-swappable drives: 2.5" SAS (10,000 rpm): 36 GB, 73 GB, 146 GB, 300 GB, 600 GB 2.5" SAS (15,000 rpm): 36 GB, 73 GB 146 GB SSD: 25 GB, 50 GB, 100 GB, 150 GB Maximum internal storage: Up to 1.2 terabytes via 4 x 300 GB SAS hard drives
I/O slots	Per cell: 6 internal PCI-Express slots at 8X; Optional expansion I/O rack adds 9 external PCI-Express slots for a total of 14 slots per cell; 6 internal SAS hard disk drives Per system: Maximum of 56 PCI-Express slots

Step 3: Select a server model

In this scenario, the choice is the ES7600 Model 7600R enterprise-class server because it allows maximum server consolidation and is the best option in terms of datacenter footprint and power and cooling requirements.

The ES7600 Model 7600R server has up to 16 sockets with 2.66 GHz Intel Xeon X7460 processors. Each processor has six cores, providing 96 processing cores total. The memory capacity per server is one terabyte.

Zurück zum Seitenanfang

Calculate CPU Capacity of Hyper-V Root Server

In previous steps, you calculated the megacycles required to support the number of active mailbox users. In the following steps, you determine how many available megacycles the server model and processor can support, to determine the number of active mailboxes each server can support.

Step 1: Determine benchmark value for server and processor

Because the megacycle requirements are based on a baseline server and processor model, you need to adjust the available megacycles for the server against the baseline. To do this, independent performance benchmarks maintained by Standard Performance Evaluation Corporation (SPEC) are used. SPEC is a non-profit corporation formed to establish, maintain, and endorse a standardized set of relevant benchmarks that can be applied to the newest generation of high-performance computers.

To help simplify the process of obtaining the benchmark value for your server and processor, we recommend you use the Exchange Processor Query tool. This tool automates the manual steps to determine your planned processor's SPECint 2006 Rate Value. To run the tool, your computer must be connected to the Internet. The tool uses your planned processor model as input, and then runs a query against the spec.org site, returning all test result data for that specific processor model. The tool also calculates an average SPECint 2006 Rate Value based on the number of processors planned to be used in each Mailbox server. Use the following calculations:

• Processor = Intel X7460 2.66 GHz

• SPECint_rate2006 value = 527

• SPECint_rate2006 value per processor core = 527 ÷ 48

  = 11

Step 2: Calculate adjusted megacycles

In previous steps, you calculated the required megacycles for the entire environment based on megacycle per mailbox estimates. Those estimates were measured on a baseline system (HP DL380 G5 x5470 3.33 GHz, 8 cores) that has a SPECint_rate2006 value of 150 (for an 8 core server), or 18.75 per core.

In this step, you need to adjust the available megacycles for the chosen server and processor against the baseline processor so that the required megacycles can be used for capacity planning.

To determine the megacycles of the Intel X7460 2.66 GHz platform, use the following formula:

• Adjusted megacycles per core = (new platform per core value) × (hertz per core of new platform) ÷ (baseline per core value)

  = (11 × 3330) ÷ 18.75

  = 1954

• Adjusted megacycles per server = adjusted megacycles per core × number of cores

  = 1954 × 48

  = 93773

Step 3: Adjust available megacycles for virtualization overhead

When deploying VMs on the root server, you need to account for megacycles required to support the hypervisor and virtualization stack. This overhead varies from server to server and under different workloads. A conservative estimate of 10 percent of available megacycles will be used. Use the following calculation:

• Adjusted available megacycles = usable megacycles × 0.90

  = 93773 × 0.90

  = 84396

Each server has a usable capacity for VMs of 84,396 megacycles.

The usable capacity per logical processor is 1,758 megacycles.

Zurück zum Seitenanfang

Determine CPU Capacity of Virtual Machines

In a previous step, you determined that the virtual processor allocation for the two VM types would be as follows:

• Client Access and Hub Transport server   4 virtual processors

• Mailbox server   4 virtual processors

Step 1: Calculate available megacycles per virtual machine

In this step, you determine how many megacycles are available for each VM deployed on the root server. Use the following calculation:

• Megacycles per VM = megacycles per virtual processor × number of virtual processors

  = 1758 × 4

  = 7033

Step 2: Determine target available megacycles per virtual machine

Because the design assumptions state not to exceed 80 percent processor utilization, in this step, you adjust the available megacycles to reflect the 80 percent target. Use the following calculation:

• Megacycles per VM = available megacycles × max CPU percent utilization target

  = 7033 × 0.80

  = 5626

Zurück zum Seitenanfang

Determine Number of Mailbox Server Virtual Machines Required

You can use the following steps to determine the number of Mailbox server VMs required.

Step 1: Determine maximum number of mailboxes supported by a single Mailbox server virtual machine

To determine the number of active mailboxes supported by a Mailbox server VM, use the following calculation:

• Number of active mailboxes = available megacycles ÷ megacycles per mailbox

  = 5626 ÷ 1.5

  = 3750

Each Mailbox server VM can support a maximum of 3,750 active mailboxes.

Step 2: Determine minimum number of Mailbox server virtual machines required per site to support the required workload for each DAG

Each DAG has 7,500 active mailboxes. To determine the minimum number of Mailbox servers required to support all mailboxes in a DAG, use the following calculation:

• Number of VMs required = total mailbox count per DAG ÷ active mailboxes per VM

  = 7500 ÷ 3750

  = 2

A minimum of two Mailbox server VMs are required to support the workload of 7,500 mailboxes.

Step 3: Determine minimum number of Mailbox server virtual machines required to support the mailbox resiliency strategy for each DAG

In the previous step, you determined that a minimum of two Mailbox server VMs was needed to support the target workload. In an active/passive database distribution model, a minimum of two Mailbox server VMs in the secondary datacenter is needed to support the workload during a site failure event. An additional two Mailbox server VMs are needed in the primary datacenter to provide server resiliency. Therefore, the DAG design will have six Mailbox server VMs with four in the primary site and two in the secondary site.

Minimum number of Mailbox server VMs required

DAG1 primary datacenter	DAG1 secondary datacenter	Mailbox server count
2	1	3
4	2	6
6	3	9

Step 4: Determine number of Mailbox server virtual machines required to support the mailbox resiliency strategy for both DAGs

The total number of Mailbox server VMs required to support both DAGs is 12 as shown in the following table.

Number of Mailbox server VMs required

DAG1 primary datacenter	DAG1 secondary datacenter	DAG2 primary datacenter	DAG2 secondary datacenter	Total Mailbox server count
4	2	4	2	12

Step 5: Determine number of active mailboxes per Mailbox server virtual machine during normal operation

To determine the number of active mailboxes hosted by each Mailbox server VM in the primary datacenter, use the following calculation:

• Number of mailboxes per VM = total mailbox count in DAG ÷ number of Mailbox servers

  = 7500 ÷ 4

  = 1875

During normal operating conditions, each Mailbox server VM hosts 1,875 active mailboxes. During the simultaneous loss of two servers (failure or planned maintenance scenario) in the primary datacenter, each Mailbox server VM hosts 3,750 active mailboxes. During a site failure, each Mailbox server VM in the secondary datacenter hosts 3,750 active mailboxes.

Zurück zum Seitenanfang

Determine Memory Required per Mailbox Server

In a previous step, you determined that the database cache requirements for all mailboxes was 44 GB and the average cache required per active mailbox was 3 MB. In the following steps, you will determine the amount of memory required for each Mailbox server VM.

Step 1: Determine database cache requirements per server for the worst case scenario

To determine the required memory for each Mailbox server VM, size memory to accommodate the scenario that results in the maximum number of active mailboxes being hosted on that VM.

In a previous step, you determined that the maximum number of active mailboxes per VM is 3,750. To determine the database cache requirements, use the following calculation:

• Memory required for database cache = number of active mailboxes × average cache per mailbox

  = 3750 × 3 MB

  = 11250 MB

  = 11 GB

Each Mailbox server VM requires 11 GB to support the database cache requirements of 3,750 active mailboxes.

Step 2: Determine total memory requirements per Mailbox server virtual machine for the worst case scenario

In this step, reference the following table to determine the recommended memory.

Memory requirements per mailbox VM

Server physical memory (RAM)	Database cache size: (Mailbox server role only)	Database cache size: multiple server roles (for example, Mailbox and Hub Transport)
8 GB	3.6 GB	2 GB
16 GB	10.4 GB	8 GB
24 GB	17.6 GB	14 GB

The recommended physical memory configuration to support 11 GB of database cache for a Mailbox server role is 16 GB.

Zurück zum Seitenanfang

Determine Number of Client Access and Hub Transport Combination Virtual Machines Required

In a previous step, you determined that six Mailbox server VMs were required in each site (four from one DAG and two from the other DAG). We recommend that you deploy one combination Client Access and Hub Transport server VM for every one Mailbox server VM (assuming an identical number of virtual processors are assigned to each VM) as shown in the following table.

Recommended processor core ratio

Server role configuration	Recommended processor core ratio
Mailbox server role:combination Client Access and Hub Transport server role	1:1

However, when you have two DAGs represented in the same site, you need to examine the worst case failure scenario before you can determine the number of Client Access and Hub Transport servers required. In this solution, the worst case failure scenario would be to lose two of the four Mailbox servers in the primary DAG and have a simultaneous site failure where the two Mailbox servers in the secondary DAG are hosting active mailbox databases. In this case, you require a minimum of four Client Access and Hub Transport servers in each site to support 15,000 active users in one site, as shown in the following figure.

Client Access and Hub Transport server sizing

Memory configurations for Exchange 2010 servers based on installed server roles

Exchange 2010 server role	Minimum supported	Recommended maximum
Client Access and Hub Transport combined role (Client Access and Hub Transport server roles running on the same physical server)	4 GB	2 GB per core (8 GB minimum)

Based on the preceding table, each combination Client Access and Hub Transport server VM requires a minimum of 8 GB of memory.

Zurück zum Seitenanfang

Determine Number of Physical Servers Required

You can use the following steps to determine the number of physical servers required.

Step 1: Summarize virtual server count

In previous steps, you determined that 20 VMs running Exchange server roles were required. You now add two additional domain controllers to each site to support additional Active Directory requirements for the Exchange environment. A total of 24 VMs are now required as summarized in the following table.

VM count

	Combination Client Access and Hub Transport server	Mailbox server	Domain controller	Total
Datacenter 1	4	6	2	12
Datacenter 2	4	6	2	12
Total	8	12	4	24

Step 2: Summarize virtual processor count

Each VM will have four virtual processors assigned. The following table summarizes the virtual processor requirements for the 24 VMs.

Virtual processor requirements for the 24 VMs

	Combination Client Access and Hub Transport server	Mailbox server	Domain controller	Total
Site A	16	24	8	48
Site B	16	24	8	48
Total	32	48	16	96

Step 3: Summarize memory required

Each combination Client Access and Hub Transport server VM requires 8 GB of memory. Each Mailbox server VM requires 16 GB of memory. Each domain controller VM requires 8 GB of memory. The following table summarizes the memory requirements of the 24 VMs.

Memory requirements for the 24 VMs

	Combination Client Access and Hub Transport server	Mailbox server	Domain controller	Total
Site A	32	96	16	144
Site B	32	96	16	144
Total	64	192	16	288

Step 4: Determine number of ES7600 Model 7600R servers required

A single Unisys ES7600 Model 7600R enterprise server has 96 cores and up to 1 terabyte of memory. The server consists of four cells. Each cell has 24 cores and up to 256 GB of memory. Each cell will be configured with only 128 GB of memory.

ES7600 Model 7600R servers

To support the site resiliency model, one ES7600 Model 7600R server is required at each of the two sites. Within a site, the processor and memory requirements can be met with two of the four cells. Half of the server will be allocated to support the Exchange environment, and the other half of the server will be used to support other virtualized applications.

Zurück zum Seitenanfang

Determine How the Server Will Be Partitioned

The server can be configured to run as 1, 2, or 4 partitions. Each partition can act as a separate server running its own Hyper-V root server, as shown in the following figure.

Server partitions

*Design Decision Point*

Because only half of the server will be used for Exchange VMs, it doesn't make sense to create a single partition. If you needed to restart the single Hyper-V root server, you would have to coordinate downtime for all the Exchange and non-Exchange VMs running on the single partition. If two partitions are used, you could isolate the Exchange VMs from other VMs, but if the Hyper-V root server needed to be restarted, all Exchange VMs in the site would be unavailable. This would require a manual activation of the secondary site. To provide flexibility during root server maintenance or failure events, a configuration with four partitions is selected.

Zurück zum Seitenanfang

Determine Virtual Machine Distribution

When deciding which VMs to host on which Hyper-V root server, your main goal should be to eliminate single points of failure. Don't locate all Client Access and Hub Transport server role VMs on the same root server, and don't locate all Mailbox server role VMs on the same root server.

Virtual machine distribution (incorrect)

The correct distribution is to have an equal distribution of the Client Access and Hub Transport server VMs on each of the root servers and an equal distribution of the Mailbox server VMs on each of the root servers.

Virtual machine distribution (correct)

Zurück zum Seitenanfang

Determine Virtual Machine Layout

In the previous step, you determined that as a best practice you want to ensure that server roles are distributed across multiple root servers. In this step, you will determine which VMs will be hosted by which root servers.

Step 1: Evenly distribute combination Client Access and Hub Transport server virtual machines

You have eight combination Client Access and Hub Transport server VMs and four root servers. Each root server will host two combination Client Access and Hub Transport server VMs. This allows half of the combination Client Access and Hub Transport servers to remain active during a root server failure or maintenance event.

Step 2: Evenly distribute Mailbox server virtual machines from DAG 1

In datacenter 1, distribute two of the four Mailbox server VMs on each root server. In datacenter 2, distribute one of the two Mailbox server VMs on each root server.

Step 3: Evenly distribute Mailbox server virtual machines from DAG 2

In datacenter 2, distribute two of the four Mailbox server VMs on each root server. In datacenter 1, distribute one of the two Mailbox server VMs on each root server.

The VM distribution should look as shown in the following figure.

VM distribution

Step 4: Evenly distribute domain controller virtual machines

You have four domain controllers and four root servers. Place one domain controller VM on each root server.

Zurück zum Seitenanfang

Identify Failure Domains Impacting Database Copy Layout

You can use the following steps to identify failure domains impacting database copy layout.

Step 1: Identify failure domains associated with storage

In a previous step, you decided to deploy a single Hitachi Adaptable Modular Storage 2100 array in each site. In this scenario, each Hitachi Adaptable Modular Storage 2100 array represents a failure domain that aligns with the site boundary and may impact the layout of database copies in the DAG.

Step 2: Identify failure domains associated with physical servers

In a previous step, you decided to deploy a single ES7600 Model 7600R server in each site. In this scenario, each ES7600 Model 7600R server represents a failure domain that aligns with the site boundary and may impact the layout of database copies in the DAG.

Step 3: Identify failure domains associated with Hyper-V root servers

In a previous step, you decided to create two partitions on the ES7600 Model 7600R in each site so that you can run two Hyper-V root servers in each site. In this scenario, each Hyper-V root server represents a failure domain that may impact the layout of database copies in the DAG.

Zurück zum Seitenanfang

Design Database Copy Layout

You can use the following steps to design a database copy layout.

Step 1: Determine number of unique Exchange databases in the DAG

The easiest way to determine the optimal number of Exchange databases to deploy is to use the Exchange 2010 Mailbox Server Role Requirements Calculator. To download the calculator, see E2010 Mailbox Server Role Requirements Calculator. For additional information about using the storage calculator, see Exchange 2010 Mailbox Server Role Requirements Calculator. Enter the appropriate information on the input worksheet and then select Yes for Automatically Calculate Number of Unique Databases / DAG.

Database configuration

On the Role Requirements tab, the recommended number of databases appears.

Recommended number of databases

In this solution, the calculator recommends that each DAG have eight unique databases.

*Design Decision Point*

Each DAG has four Mailbox servers in the primary site. The recommended eight databases can be evenly distributed across the Mailbox servers, so no adjustment is needed to accommodate the database layout. Eight databases will be deployed in each DAG, for a total of 16 databases in the entire environment.

Step 2: Determine number of database copies per Mailbox server

Because there are eight unique databases and three copies of each database, there are a total of 24 database copies in each DAG. There are six servers in the DAG, and each server will host four database copies.

Step 3: Determine database layout during normal operating conditions

Because you have eight unique databases per DAG and six servers in the DAG, each of the four servers in the primary site will host two active database copies during normal operating conditions.

Add the active database copies to the four servers as shown in the following table.

Active database copies with one activation preference value

DAG1	SITE1
	MBX1 (root1)	MBX2 (root1)	MBX3 (root2)	MBX4 (root2)
DB1	C1
DB2	C1
DB3		C1
DB4		C1
DB5			C1
DB6			C1
DB7				C1
DB8				C1

In the preceding table, the following applies:

• C1 = active database copy (database activation preference of 1)

In a previous step, you determined that MBX1 and MBX2 were in the same failure domains and that MBX3 and MBX4 were in another failure domain. To protect against failure, the C2 copies (activation preference value of 2) should be placed in the alternate failure domain from the C1 copies (activation preference value of 1). In addition, the copies should be evenly distributed across both servers in the alternate failure domain so that in the event of a single VM failure or maintenance scenario, the load is evenly distributed across the two servers in the alternate failure domain.

Active database copies with two activation preference values

DAG1	SITE1
	MBX1 (root1)	MBX2 (root1)	MBX3 (root2)	MBX4 (root2)
DB1	C1		C2
DB2	C1			C2
DB3		C1	C2
DB4		C1		C2
DB5	C2		C1
DB6		C2	C1
DB7	C2			C1
DB8		C2		C1

In the preceding table, the following applies:

• C1 = active database copy (database activation preference of 1)

• C2 = active database copy (database activation preference of 2)

Step 4: Determine database layout during in-site server failure or maintenance conditions

Before you add the secondary datacenter and distribute the C3 copies, examine what happens during a server failure scenario in the primary datacenter. In the following example, if server MBX1 fails, the active database copies will automatically move to servers MBX3 and MBX4. Notice that both servers in the alternate failure domain are now running with three active databases, and the active databases are equally distributed across both servers.

Database copy layout during server maintenance or failure

In a maintenance scenario, you could move the active mailbox databases from the servers in the first failure domain (MBX1 and MBX2) to the servers in the second failure domain (MBX3 and MBX4), complete maintenance activities, and then move the active database copies back to the C1 copies on the servers in the first failure domain. You can conduct maintenance activities on all servers in the primary datacenter in two passes.

Database copy layout during server maintenance

Step 5: Add database copies to secondary datacenter to support site resiliency

The next step is to add a third database copy to the DAG members in the secondary datacenter to provide site resiliency. The C3 copies (activation preference value of 3) should also be evenly distributed across the two Mailbox servers in the secondary site.

Active database copies with three activation preference values

DAG1	SITE1					SITE2
	MBX1 (root1)	MBX2 (root1)	MBX3 (root2)	MBX4 (root2)		MBX5 (root3)	MBX6 (root4)
DB1	C1		C2			C3
DB2	C1			C2			C3
DB3		C1	C2			C3
DB4		C1		C2			C3
DB5	C2		C1			C3
DB6		C2	C1				C3
DB7	C2			C1		C3
DB8		C2		C1			C3

In the preceding table, the following applies:

• C1 = active database copy (database activation preference of 1)

• C2 = active database copy (database activation preference of 2)

• C3 = active database copy (database activation preference of 3)

Step 6: Determine database layout during site failure conditions

In the event of a failure of the primary datacenter, the C3 copies (activation preference value of 3) will be activated in the secondary site as the following table illustrates. Note that until the primary site comes back online, there will only be a single copy of the database.

Database layout during site failure conditions

DAG1	SITE1					SITE2
	MBX1 (root1)	MBX2 (root1)	MBX3 (root2)	MBX4 (root2)		MBX5 (root3)	MBX6 (root4)
DB1	C1		C2			C3
DB2	C1			C2			C3
DB3		C1	C2			C3
DB4		C1		C2			C3
DB5	C2		C1			C3
DB6		C2	C1				C3
DB7	C2			C1		C3
DB8		C2		C1			C3

Zurück zum Seitenanfang

Determine Storage Design

A well designed storage solution is a critical aspect of a successful Exchange 2010 Mailbox server role deployment. For more information, see Speicherentwurf für Postfachserver.

Step 1: Summarize storage requirements

The following table summarizes the storage requirements that have been calculated or determined in a previous design step.

Summary of disk space requirements

Disk space requirements	Value
Average mailbox size on disk (MB)	968
Database capacity required (GB)	23406
Log capacity required (GB)	706
Total capacity required (GB)	24112
Total capacity required for three database copies (GB)	72336
Total capacity required for three database copies (terabytes)	71
Total capacity required per site (terabytes)	36

Step 2: Determine whether Hitachi Dynamic Provisioning software will be used

Hitachi Dynamic Provisioning software is an optional feature of the Hitachi Adaptable Modular Storage 2100. On the Hitachi Adaptable Modular Storage 2100, Hitachi Dynamic Provisioning software provides wide striping and thin provisioning functionalities. In the most basic sense, Hitachi Dynamic Provisioning software is similar to the use of a host-based logical volume manager, but with several additional features available within the Hitachi Adaptable Modular Storage 2100 and without the need to install software on the host or incur host processing overhead. Hitachi Dynamic Provisioning software provides for one or more pools of wide striping across many RAID groups within a Hitachi Adaptable Modular Storage 2100. One or more Dynamic Provisioning virtual volumes (DP-VOLs) of a user-specified logical size of up to 60 terabytes (with no initial physical space allocated) are created against each pool.

Primarily, you deploy Hitachi Dynamic Provisioning software to avoid the routine issue of hot spots that occur on logical devices (LDEVs) from individual RAID groups when the host workload exceeds the IOPS or throughput capacity of that RAID group. By using many RAID groups as members of a striped Dynamic Provisioning pool underneath the virtual or logical volumes seen by the hosts, a host workload is distributed across many RAID groups, which provides a smoothing effect that reduces hot spots.

Hitachi Dynamic Provisioning software also has the benefit of thin provisioning, where physical space is only assigned from the pool to the DP-VOL as needed, up to the logical size specified for each DP-VOL. A pool can also be dynamically expanded by adding more capacity or reduced by withdrawing pool capacity. Either operation is performed without disruption or requiring downtime. Upon expansion, a pool can be rebalanced so that the data and workload are wide striped evenly across the current and newly added RAID groups that make up the pool.

The Hitachi Dynamic Provisioning software thin provisioning and wide striping functionalities provide virtual storage capacity to eliminate application service interruptions, reduce costs, and simplify administration.

*Design Decision Point*

In this example, Hitachi Dynamic Provisioning software will be used. This will minimize the complexity of the solution, simplify storage administration, and provide expansion of capacity to accommodate future growth.

Step 3: Determine whether logs and databases will be co-located on the same volume

In previous Exchange releases, it was a recommended best practice to separate database files and log files from the same mailbox database to different volumes backed by different physical disks for recoverability purposes. This is still a recommended best practice for stand-alone architectures and architectures using VSS-based backups.

*Design Decision Point*

Because Exchange native data protection is being used and because three database copies will be deployed, the logs and databases will be co-located on the same volume.

Step 4: Determine number of databases per LUN

Because VSS-based backup and restore operations operate at the logical unit number (LUN) level, the number of databases per LUN is usually determined by the backup strategy. In a previous step, it was decided not to include VSS-based backups as part of the database resiliency strategy. The decision on the number of databases per LUN will be based on other factors. As a best practice, you should generally deploy a single database per LUN. Having more than one database per LUN could result in the following:

• An overloaded database impacting a healthy database.

• A seeding operation on one database impacting a healthy database.

• Passive database I/O impacting active databases.

*Design Decision Point*

The best practice of one database per LUN will be followed.

Step 5: Determine number of LUNs per server

In a previous step, you identified that each Mailbox server in the primary datacenter for the DAG would support two active databases and two passive databases during normal operating conditions. There will be a total of four LUNs for each primary datacenter Mailbox server.

Number of LUNs per server

Database per log LUNs	Number of LUNs
Active database per log LUNs	2
Passive database per log LUNs	2
Total LUNS	4

Step 6: Determine required LUN size

In this step, to determine the volume size required to support both the database and log capacity requirements, use the following calculation:

• Database capacity = [(number of mailbox users × average mailbox size on disk) + (20% data overhead factor)] + (10% content indexing overhead)

  = [(938 × 968) + (181597)] + [108958]

  = 1198539 MB

  = 1170 GB

• Log capacity = [(log size × number of logs per mailbox per day × number of days required to support equipment failure × number of mailbox users) + (mailbox move percent overhead)]

  = (1 MB × 10 × 3 × 938) + (938 × 0.01 × 968 MB)

  = 37220 MB

  = 36 GB

• Volume size = [(database capacity) + (log capacity)] ÷ 0.80 to add 20% volume free space

  = [(1170) + (36)] ÷ 0.8

  = 1507

The required volume size is 1,507 GB.

Step 7: Determine number of Dynamic Provisioning pools

In a previous step, you determined that each Hyper-V root server represented a failure domain. During the database copy layout planning steps, you ensured that the C1 and C2 copies were located on Mailbox server VMs in different failure domains. To ensure that the C1 and C2 copies reside on a different set of spindles, we recommend that a separate Dynamic Provisioning pool be created for each failure domain.

Because failure domains are specific to individual DAGs, you aren't required to deploy the C3 copies for the alternate DAG on a different set of spindles than the C1 or C2 copies from the primary DAG. However, for administrative purposes, it may make sense to separate database volumes from different DAGs onto different Dynamic Provisioning pools.

*Design Decision Point*

One Dynamic Provisioning pool will be deployed for each Hyper-V root server to align with the failure domains and to ensure that C1 and C2 copies reside on different pools of disk. The C3 copies from the alternate DAG are spread across both failure domains in the secondary datacenter and will be equally distributed across each of the two Dynamic Provisioning pools in the site.

Step 8: Determine volume layout on the Hitachi Adaptable Modular Storage 2100

There are two Dynamic Provisioning pools in each site that align with the Hyper-V root servers in each site. In Datacenter1, Pool 1-1 is associated with Root1 and Pool 1-2 is associated with Root2. All of the LUNs containing the C1 and C2 copies from Mailbox servers MBX1 and MBX2 in DAG1 as well as all of the LUNs containing the C3 copies from MBX11 in DAG2 are located on Pool 1-1. All of the LUNs containing the C1 and C2 copies from Mailbox servers MBX3 and MBX4 in DAG1 as well as all of the LUNs containing the C3 copies from MBX12 in DAG2 are located on Pool 1-2. All of the LUNs containing the C1 and C2 copies from Mailbox servers MBX7 and MBX8 in DAG2 as well as all of the LUNs containing the C3 copies from MBX5 in DAG1 are located on Pool 2-1. All of the LUNs containing the C1 and C2 copies from Mailbox servers MBX9 and MBX10 in DAG2 as well as all of the LUNs containing the C3 copies from MBX6 in DAG1 are located on Pool 2-2. This design keeps each copy of a database on a separate set of spindles. This layout offers the best availability and reliability. The following table summarizes the pool layout.

Hitachi Adaptable Modular Storage 2100 layout

Zurück zum Seitenanfang

Determine Placement of the File Share Witness

In Exchange 2010, the DAG uses a minimal set of components from Windows failover clustering. One of those components is the quorum resource, which provides a means for arbitration when determining cluster state and making membership decisions. It's critical that each DAG member have a consistent view of how the DAGs underlying cluster is configured. The quorum acts as the definitive repository for all configuration information relating to the cluster. The quorum is also used as a tiebreaker to avoid split brain syndrome. Split brain syndrome is a condition that occurs when DAG members can't communicate with each other but are available and running. Split brain syndrome is prevented by always requiring a majority of the DAG members (and in the case of DAGs with an even number of members, the DAG witness server) to be available and interacting for the DAG to be operational.

A witness server is a server outside of a DAG that hosts the file share witness, which is used to achieve and maintain quorum when the DAG has an even number of members. DAGs with an odd number of members don't use a witness server. Upon creation of a DAG, the file share witness is added by default to a Hub Transport server (that doesn't have the Mailbox server role installed) in the same site as the first member of the DAG. If your Hub Transport server is running in a VM that resides on the same root server as VMs running the Mailbox server role, we recommend that you move the location of the file share witness to another highly available server. You can move the file share witness to a domain controller, but because of security implications, do this only as a last resort.

*Design Decision Point*

The file and print servers in the environment are reasonably stable and are managed by the same administrator who supports the Exchange servers, so it's a good choice for the location of the file share witness. In datacenter 1, one server will host the primary file share witness for DAG1 and the secondary file share witness for DAG2. In datacenter 2, one server will host the primary file share witness for DAG2 and the secondary file share witness for DAG1.

Zurück zum Seitenanfang

Plan Namespaces

When you plan your Exchange 2010 organization, one of the most important decisions that you must make is how to arrange your organization's external namespace. A namespace is a logical structure usually represented by a domain name in Domain Name System (DNS). When you define your namespace, you must consider the different locations of your clients and the servers that house their mailboxes. In addition to the physical locations of clients, you must evaluate how they connect to Exchange 2010. The answers to these questions will determine how many namespaces you must have. Your namespaces will typically align with your DNS configuration. We recommend that each Active Directory site in a region that has one or more Internet-facing Client Access servers have a unique namespace. This is usually represented in DNS by an A record, for example, mail.contoso.com or mail.europe.contoso.com.

For more information, see Grundlegendes zu Clientzugriffsserver-Namespaces.

There are a number of different ways to arrange your external namespaces, but usually your requirements can be met with one of the following namespace models:

• Consolidated datacenter model   This model consists of a single physical site. All servers are located within the site, and there is a single namespace, for example, mail.contoso.com.

• Single namespace with proxy sites   This model consists of multiple physical sites. Only one site contains an Internet-facing Client Access server. The other sites aren't exposed to the Internet. There is only one namespace for the sites in this model, for example, mail.contoso.com.

• Single namespace and multiple sites   This model consists of multiple physical sites. Each site can have an Internet-facing Client Access server. Alternatively, there may be only a single site that contains Internet-facing Client Access servers. There is only one namespace for the sites in this model, for example, mail.contoso.com.

• Regional namespaces   This model consists of multiple physical sites and multiple namespaces. For example, a site located in New York City would have the namespace mail.usa.contoso.com, a site located in Toronto would have the namespace mail.canada.contoso.com, and a site located in London would have the namespace mail.europe.contoso.com.

• Multiple forests   This model consists of multiple forests that have multiple namespaces. An organization that uses this model could be made up of two partner companies, for example, Contoso and Fabrikam. Namespaces might include mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.fabrikam.com, and mail.europe.fabrikam.com.

*Design Decision Point*

For this scenario, the regional namespaces model is selected because it's the best fit for organizations with active mailboxes in multiple sites.

The advantage of this model is that proxying is reduced because a larger percentage of users will be able to connect to a Client Access server in the same Active Directory site as their Mailbox server. This will improve the end-user experience and performance. Users who have mailboxes in a site that doesn't have an Internet-facing Client Access server will still be proxied.

This solution also has the following configuration requirements:

• Multiple DNS records must be managed.

• Multiple certificates must be obtained, configured, and managed.

• Managing security is more complex because each Internet-facing site requires a Microsoft Forefront Threat Management Gateway computer or other reverse-proxy or firewall solution.

• Users must connect to their own regional namespace. This may result in additional Help desk calls and training.

Zurück zum Seitenanfang

Determine Client Access Server Array and Load Balancing Strategy

In Exchange 2010, the RPC Client Access service and the Exchange Address Book service were introduced on the Client Access server role to improve the mailbox users experience when the active mailbox database copy is moved to another Mailbox server (for example, during mailbox database failures and maintenance events). The connection endpoints for mailbox access from Microsoft Outlook and other MAPI clients have been moved from the Mailbox server role to the Client Access server role. Therefore, both internal and external Outlook connections must now be load balanced across all Client Access servers in the site to achieve fault tolerance. To associate the MAPI endpoint with a group of Client Access servers rather than a specific Client Access server, you can define a Client Access server array. You can only configure one array per Active Directory site, and an array can't span more than one Active Directory site. For more information, see Grundlegendes zum RPC-Clientzugriff and Grundlegendes zum Lastenausgleich in Exchange 2010.

*Design Decision Point*

Because this is a two site deployment with four servers running the Client Access server role in each site, there will be two Client Access server arrays. With only four servers to load balance, a Windows NLB software solution will be used, which is an installable component of the Windows Server operating system.

Zurück zum Seitenanfang

Solution Overview

The previous section provided information about the design decisions that were made when considering an Exchange 2010 solution. The following section provides an overview of the solution.

Zurück zum Seitenanfang

Logical Solution Diagram

This solution consists of 20 Exchange 2010 servers located in two sites. Each site has its own regional namespace that's load balanced across the combination Client Access and Hub Transport servers in each Client Access server array. The Mailbox servers are deployed in two DAGs with the primary and alternate file share witness located on a file server in each site.

Logical solution

Zurück zum Seitenanfang

Physical Solution Diagram

Site 1 contains a Unisys ES7600 Model 7600R enterprise server connected to a Hitachi Adaptable Modular Storage 2100 via redundant paths to redundant Brocade 300 Fibre Channel switches. The network consists of redundant Brocade FastIron Ethernet switches. Site 2 is an exact replica of Site 1.

Physical solution

Zurück zum Seitenanfang

Server Hardware Summary

The following table summarizes the physical server hardware used in this solution.

Server hardware

Component	Value or description
Server vendor	Unisys
Server model	ES7600 Model 7600R
Processor	16 Intel X7460 2.6 GHz
Total logical processors	96
Memory	512 GB
Partitions	4 (2 partitions used for Exchange)
Operating system	Windows Server 2008 R2
Virtualization	Hyper-V 2008 R2

Zurück zum Seitenanfang

Client Access and Hub Transport Server Configuration

The following table summarizes the Client Access and Hub Transport server configuration used in this solution.

Client Access and Hub Transport server configuration

Component	Value or description
Physical or virtual	Hyper-V VM
Virtual processors	4
Memory	8 GB
Storage	Virtual hard disk on root server operating system volume
Operating system	Windows Server 2008 R2
Exchange version	Exchange 2010 Update Rollup 2
Additional software	Microsoft Forefront Protection 2010 for Exchange Server

Zurück zum Seitenanfang

Mailbox Server Configuration

The following table summarizes the Mailbox server configuration used in this solution.

Mailbox server configuration

Component	Value or description
Physical or virtual	Hyper-V VM
Virtual processors	4
Memory	24 GB
Storage	Virtual hard disk on root server operating system volume
Pass-through storage	Yes
Operating system	Windows Server 2008 R2
Exchange version	Exchange 2010 Update Rollup 2

Zurück zum Seitenanfang

Database Layout

The following diagrams summarize the database copy layout used in this solution during normal operating conditions.

Database layout for DAG 1

Database layout for DAG 2

Zurück zum Seitenanfang

Storage Hardware Summary

The following table summarizes the storage hardware used in this solution.

Storage hardware

Component	Value or description
Storage vendor	Hitachi Data Systems
Storage model	Adaptable Modular Storage 2100
Disks	136 x 600 GB 15,000 rpm SAS
Maximum usable capacity with RAID-5 (4D+1P)	62 terabytes
Fibre Channel ports	8 x 8 gigabits per second (Gbps) Fibre Channel
Maximum attached host ports through virtual ports	1024

Zurück zum Seitenanfang

Storage Configuration

Each of the Hitachi Adaptable Modular Storage 2100 units used in the solution were configured as illustrated in the following table.

Storage configuration

Component	Value or description
Storage enclosures	2
RAID level	RAID-5 (4D+1P)
RAID groups per enclosure	16
Dynamic Provisioning pools per enclosure	2
LUNs per enclosure	24
LUNs per Hyper-V root	12
LUNs per Mailbox server VM	4
LUN size	1507 GB

The following table illustrates how the available storage was designed and allocated between the two Hitachi Adaptable Modular Storage 2100 units.

Storage configuration between Hitachi Adaptable Modular Storage 2100 units

Database	Array-1		Database	Array-2
DB1	C1, C2		DB1	C3
DB2	C1, C2		DB2	C3
DB3	C1, C2		DB3	C3
DB4	C1, C2		DB4	C3
DB5	C1, C2		DB5	C3
DB6	C1, C2		DB6	C3
DB7	C1, C2		DB7	C3
DB8	C1, C2		DB8	C3
DB9	C3		DB9	C1, C2
DB10	C3		DB10	C1, C2
DB11	C3		DB11	C1, C2
DB12	C3		DB12	C1, C2
DB13	C3		DB13	C1, C2
DB14	C3		DB14	C1, C2
DB15	C3		DB15	C1, C2
DB16	C3		DB16	C1, C2

Zurück zum Seitenanfang

Solution Validation Methodology

Prior to deploying an Exchange solution in a production environment, validate that the solution was designed, sized, and configured properly. This validation must include functional testing to ensure that the system is operating as desired as well as performance testing to ensure that the system can handle the desired user load. This section describes the approach and test methodology used to validate server and storage design for this solution. In particular, the following tests will be defined in detail:

• Performance tests

  • Storage performance validation (Jetstress)

  • Server performance validation (Loadgen)

• Functional tests

  • Database switchover validation

  • Server switchover validation

  • Server failover validation

  • Datacenter switchover validation

Zurück zum Seitenanfang

Storage Design Validation Methodology

The level of performance and reliability of the storage subsystem connected to the Exchange Mailbox server role has a significant impact on the overall health of the Exchange deployment. Additionally, poor storage performance will result in high transaction latency, primarily reflected in poor client experience when accessing the Exchange system. To ensure the best possible client experience, validate storage sizing and configuration via the method described in this section.

Tool Set

For validating Exchange storage sizing and configuration, we recommend the Microsoft Exchange Server Jetstress tool. The Jetstress tool is designed to simulate an Exchange I/O workload at the database level by interacting directly with the ESE, which is also known as Jet. The ESE is the database technology that Exchange uses to store messaging data on the Mailbox server role. Jetstress can be configured to test the maximum I/O throughput available to your storage subsystem within the required performance constraints of Exchange. Or, Jetstress can accept a target profile of user count and per-user IOPS, and validate that the storage subsystem is capable of maintaining an acceptable level of performance with the target profile. Test duration is adjustable and can be run for a minimal period of time to validate adequate performance or for an extended period of time to additionally validate storage subsystem reliability.

The Jetstress tool can be obtained from the Microsoft Download Center at the following locations:

• Microsoft Exchange Server Jetstress 2010 (64 bit)

• Microsoft Exchange Server Jetstress 2010 (32 bit)

The documentation included with the Jetstress installer describes how to configure and execute a Jetstress validation test on your server hardware.

Approach to Storage Validation

There are two main types of storage configurations:

• Direct-attached storage (DAS) or internal disk scenarios

• Storage area network (SAN) scenarios

With DAS or internal disk scenarios, there's only one server accessing the disk subsystem, so the performance capabilities of the storage subsystem can be validated in isolation.

In SAN scenarios, the storage utilized by the solution may be shared by many servers and the infrastructure that connects the servers to the storage may also be a shared dependency. This requires additional testing, as the impact of other servers on the shared infrastructure must be adequately simulated to validate performance and functionality.

Test Cases for Storage Validation

The following storage validation test cases were executed against the solution and should be considered as a starting point for storage validation. Specific deployments may have other validation requirements that can be met with additional testing, so this list isn't intended to be exhaustive:

• Validation of worst case database switchover scenario   In this test case, the level of I/O is expected to be serviced by the storage subsystem in a worst case switchover scenario (largest possible number of active copies on fewest servers). Depending on whether the storage subsystem is DAS or SAN, this test may be required to run on multiple hosts to ensure that the end-to-end solution load on the storage subsystem can be sustained.

• Validation of storage performance under storage failure and recovery scenario (for example, failed disk replacement and rebuild)   In this test case, the performance of the storage subsystem during a failure and rebuild scenario is evaluated to ensure that the necessary level of performance is maintained for optimal Exchange client experience. The same caveat applies for a DAS vs. SAN deployment: If multiple hosts are dependent on a shared storage subsystem, the test must include load from these hosts to simulate the entire effect of the failure and rebuild.

Analyzing the Results

The Jetstress tool produces a report file after each test is completed. To help you analyze the report, use the guidelines in Jetstress 2010 Test Summary Reports.

Specifically, you should use the guidelines in the following table when you examine data in the Test Results table of the report.

Jetstress results analysis

Performance counter instance	Guidelines for performance test
I/O Database Reads Average Latency (msec)	The average value should be less than 20 milliseconds (msec) (0.020 seconds), and the maximum values should be less than 50 msec.
I/O Log Writes Average Latency (msec)	Log disk writes are sequential, so average write latencies should be less than 10 msec, with a maximum of no more than 50 msec.
%Processor Time	Average should be less than 80%, and the maximum should be less than 90%.
Transition Pages Repurposed/sec (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2)	Average should be less than 100.

The report file shows various categories of I/O performed by the Exchange system:

• Transactional I/O Performance   This table reports I/O that represents user activity against the database (for example, Outlook generated I/O). This data is generated by subtracting background maintenance I/O and log replication I/O from the total I/O measured during the test. This data provides the actual database IOPS generated along with I/O latency measurements required to determine whether a Jetstress performance test passed or failed.

• Background Database Maintenance I/O Performance   This table reports the I/O generated due to ongoing ESE database background maintenance.

• Log Replication I/O Performance   This table reports the I/O generated from simulated log replication.

• Total I/O Performance   This table reports the total I/O generated during the Jetstress test.

Zurück zum Seitenanfang

Server Design Validation

After the performance and reliability of the storage subsystem is validated, ensure that all of the components in the messaging system are validated together for functionality, performance, and scalability. This means moving up in the stack to validate client software interaction with the Exchange product as well as any server-side products that interact with Exchange. To ensure that the end-to-end client experience is acceptable and that the entire solution can sustain the desired user load, the method described in this section can be applied for server design validation.

Tool Set

For validation of end-to-end solution performance and scalability, we recommend the Microsoft Exchange Server Load Generator tool (Loadgen). Loadgen is designed to produce a simulated client workload against an Exchange deployment. This workload can be used to evaluate the performance of the Exchange system, and can also be used to evaluate the effect of various configuration changes on the overall solution while the system is under load. Loadgen is capable of simulating Microsoft Office Outlook 2007 (online and cached), Office Outlook 2003 (online and cached), POP3, IMAP4, SMTP, ActiveSync, and Outlook Web App (known in Exchange 2007 and earlier versions as Outlook Web Access) client activity. It can be used to generate a single protocol workload, or these client protocols can be combined to generate a multiple protocol workload.

You can get the Loadgen tool from the Microsoft Download Center at the following locations:

• Exchange Load Generator 2010 (64 bit)

• Exchange Load Generator 2010 (32 bit)

The documentation included with the Loadgen installer describes how to configure and execute a Loadgen test against an Exchange deployment.

Approach to Server Validation

When validating your server design, test the worst case scenario under anticipated peak workload. Based on a number of data sets from Microsoft IT and other customers, peak load is generally equal to 2x the average workload throughout the remainder of the work day. This is referred to as the peak-to-average workload ratio.

Peak load

In this Performance Monitor snapshot, which displays various counters that represent the amount of Exchange work being performed over time on a production Mailbox server, the average value for RPC operations per second (the highlighted line) is about 2,386 when averaged across the entire day. The average for this counter during the peak period from 10:00 through 11:00 is about 4,971, giving a peak-to-average ratio of 2.08.

To ensure that the Exchange solution is capable of sustaining the workload generated during the peak average, modify Loadgen settings to generate a constant amount of load at the peak average level, rather than spreading out the workload over the entire simulated work day. Loadgen task-based simulation modules (like the Outlook simulation modules) utilize a task profile that defines the number of times each task will occur for an average user within a simulated day.

The total number of tasks that need to run during a simulated day is calculated as the number of users multiplied by the sum of task counts in the configured task profile. Loadgen then determines the rate at which it should run tasks for the configured set of users by dividing the total number of tasks to run in the simulated day by the simulated day length. For example, if Loadgen needs to run 1,000,000 tasks in a simulated day, and a simulated day is equal to 8 hours (28,800 seconds), Loadgen must run 1,000,000 ÷ 28,800 = 34.72 tasks per second to meet the required workload definition. To increase the amount of load to the desired peak average, divide the default simulated day length (8 hours) by the peak-to-average ratio (2) and use this as the new simulated day length.

Using the task rate example again, 1,000,000 ÷ 14,400 = 69.44 tasks per second. This reduces the simulated day length by half, which results in doubling the actual workload run against the server and achieving our goal of a peak average workload. You don't adjust the run length duration of the test in the Loadgen configuration. The run length duration specifies the duration of the test and doesn't affect the rate at which tasks will be run against the Exchange server.

Test Cases for Server Design Validation

The following server design validation test cases were executed against the solution and should be considered as a starting point for server design validation. Specific deployments may have other validation requirements that can be met with additional testing, so this list isn't intended to be exhaustive:

• Normal operating conditions   In this test case, the basic design of the solution is validated with all components in their normal operating state (no failures simulated). The desired workload is generated against the solution, and the overall performance of the solution is validated against the metrics that follow.

• Single server failure or single server maintenance (in site)   In this test case, a single server is taken down to simulate either an unexpected failure of the server or a planned maintenance operation for the server. The workload that would normally be handled by the unavailable server is now handled by other servers in the solution topology, and the overall performance of the solution is validated.

Test Execution and Data Collection

Exchange performance data has some natural variation within test runs and among test runs. We recommend that you take the average of multiple runs to smooth out this variation. For Exchange tested solutions, a minimum of three separate test runs with durations of eight hours was completed. Performance data was collected for the full eight-hour duration of the test. Performance summary data was taken from a three to four hour stable period (excluding the first two hours of the test and the last hour of the test). For each Exchange server role, performance summary data was averaged between servers for each test run, providing a single average value for each data point. The values for each run were then averaged, providing a single data point for all servers of a like server role across all test runs.

Validation of Expected Load

Before you look at any performance counters or start your performance validation analysis, verify that the workload you expected to run matched the workload that you actually ran. Although there are many ways to determine whether the simulated workload matched the expected workload, the easiest and most consistent way is to look at the message delivery rate.

Calculating Expected Peak Message Delivery Rate

Every message profile consists of the sum of the average number of messages sent per day and the average number of messages received per day. To calculate the message delivery rate, select the average number of messages received per day from the following table.

Peak message delivery rate

Message profile	Messages sent per day	Messages received per day
50	10	40
100	20	80
150	30	120
200	40	160

This example assumes that each Mailbox server has 5,000 active mailboxes with a 150 messages per day profile, as shown in the following table (30 messages sent and 120 messages received per day).

Peak message delivery rate for 5,000 mailboxes

Description	Calculation	Value
Message profile	Number of messages received per day	120
Mailbox server profile	Number of active mailboxes per Mailbox server	5000
Total messages received per day per Mailbox server	5000 × 120	600000
Total messages received per second per Mailbox server	600000 ÷ 28800	20.83
Total messages adjusted for peak load	20.83 × 2	41.67

You expect 41.67 messages per second delivered on each Mailbox server running 5,000 active mailboxes with a message profile of 150 messages per day during peak load.

Measuring Actual Message Delivery Rate

The actual message delivery rate can be measured using the following counter on each Mailbox server: MSExchangeIS Mailbox(_Total)\Messages Delivered/sec. If the measured message delivery rate is within one or two messages per second of the target message delivery rate, you can be confident that the desired load profile was run successfully.

Server Validation: Performance and Health Criteria

This section describes the Performance Monitor counters and thresholds used to determine whether the Exchange environment was sized properly and is able to run in a healthy state during extended periods of peak workload. For more information about counters relevant to Exchange performance, see Leistungs- und Skalierbarkeitsindikatoren und -schwellenwerte.

Hyper-V Root Servers

To validate the performance and health criteria of a Hyper-V root server and the applications running within VMs, you should have a basic understanding of the Hyper-V architecture and how that impacts performance monitoring.

Hyper-V has three main components: the virtualization stack, the hypervisor, and devices. The virtualization stack handles emulated devices, manages VMs, and services I/O. The hypervisor schedules virtual processors, manages interrupts, services timers, and controls other chip-level functions. The hypervisor doesn't handle devices or I/O (for example, there are no hypervisor drivers). The devices are part of the root server or installed in guest servers as part of integration services. Because the root server has a full view of the system and controls the VMs, it also provides monitoring information via Windows Management Instrumentation (WMI) and performance counters.

Processor

When validating physical processor utilization on the root server (or within the guest VM), the standard Processor\% Processor Time counter isn't very useful.

Instead, you can examine the Hyper-V Hypervisor Logical Processor\% Total Run Time counter. This counter shows the percentage of processor time spent in guest and hypervisor runtime and should be used to measure the total processor utilization for the hypervisor and all VMs running on the root server. This counter shouldn't exceed 80 percent or whatever the maximum utilization target you have designed for.

Counter	Target
Hyper-V Hypervisor Logical Processor\% Total Run Time	<80%

If you're interested in what percentage of processor time is spent servicing the guest VMs, you can examine the Hyper-V Hypervisor Logical Processor\% Guest Run Time counter. If you're interested in what percentage of processor time is spent in hypervisor, you can look at the Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time counter. This counter should be below 5 percent. The Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time counter shows the percentage of processor time spent in the virtualization stack. This counter should also be below 5 percent. These two counters can be used to determine what percentage of your available physical processor time is being used to support virtualization.

Counter	Target
Hyper-V Hypervisor Logical Processor\% Guest Run Time	<80%
Hyper-V Hypervisor Logical Processor\% Hypervisor Run Time	<5%
Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time	<5%

Memory

You need to ensure that your Hyper-V root server has enough memory to support the memory allocated to VMs. Hyper-V automatically reserves 512 MB (this may vary with different Hyper-V releases) for the root operating system. If you don't have enough memory, Hyper-V will prevent the last VM from starting. In general, don't worry about validating the memory on a Hyper-V root server. Be more concerned with ensuring that sufficient memory is allocated to the VMs to support the Exchange roles.

Application Health

An easy way to determine whether all the VMs are in a healthy state is to look at the Hyper-V Virtual Machine Health Summary counters.

Counter	Target
Hyper-V Virtual Machine Health Summary\Health OK	1
Hyper-V Virtual Machine Health Summary\Health Critical	0

Mailbox Servers

When validating whether a Mailbox server was properly sized, focus on processor, memory, storage, and Exchange application health. This section describes the approach to validating each of these components.

Processor

During the design process, you calculated the adjusted megacycle capacity of the server or processor platform. You then determined the maximum number of active mailboxes that could be supported by the server without exceeding 80 percent of the available megacycle capacity. You also determined what the projected CPU utilization should be during normal operating conditions and during various server maintenance or failure scenarios.

During the validation process, verify that the worst case scenario workload doesn't exceed 80 percent of the available megacycles. Also, verify that actual CPU utilization is close to the expected CPU utilization during normal operating conditions and during various server maintenance or failure scenarios.

For physical Exchange deployments, use the Processor(_Total)\% Processor Time counter and verify that this counter is less than 80 percent on average.

Counter	Target
Processor(_Total)\% Processor Time	<80%

For virtual Exchange deployments, the Processor(_Total)\% Processor Time counter is measured within the VM. In this case, the counter isn't measuring the physical CPU utilization. It's measuring the utilization of the virtual CPU provided by the hypervisor. Therefore, it doesn't provide an accurate reading of the physical processor and shouldn't be used for design validation purposes. For more information, see Hyper-V: Clocks lie... which performance counters can you trust.

For validating Exchange deployments running on Microsoft Hyper-V, use the Hyper-V Hypervisor Virtual Processor\% Guest Run Time counter. This provides a more accurate value for the amount of physical CPU being utilized by the guest operating system. This counter should be less than 80 percent on average.

Counter	Target
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%

Memory

During the design process, you calculated the amount of database cache required to support the maximum number of active databases on each Mailbox server. You then determined the optimal physical memory configuration to support the database cache and system memory requirements.

Validating whether an Exchange Mailbox server has sufficient memory to support the target workload isn't a simple task. Using available memory counters to view how much physical memory is remaining isn't helpful because the memory manager in Exchange is designed to use almost all of the available physical memory. The information store (store.exe) reserves a large portion of physical memory for database cache. The database cache is used to store database pages in memory. When a page is accessed in memory, the information doesn't have to be retrieved from disk, reducing read I/O. The database cache is also used to optimize write I/O.

When a database page is modified (known as a dirty page), the page stays in cache for a period of time. The longer it stays in cache, the better the chance that the page will be modified multiple times before those changes are written to the disk. Keeping dirty pages in cache also causes multiple pages to be written to the disk in the same operation (known as write coalescing). Exchange uses as much of the available memory in the system as possible, which is why there aren't large amounts of available memory on an Exchange Mailbox server.

It may not be easy to know whether the memory configuration on your Exchange Mailbox server is undersized. For the most part, the Mailbox server will still function, but your I/O profile may be much higher than expected. Higher I/O can lead to higher disk read and write latencies, which may impact application health and client user experience. In the results section, there isn't any reference to memory counters. Potential memory issues will be identified in the storage validation and application health result sections, where memory-related issues are more easily detected.

Storage

If you have performance issues with your Exchange Mailbox server, those issues may be storage-related issues. Storage issues may be caused by having an insufficient number of disks to support the target I/O requirements, having overloaded or poorly designed storage connectivity infrastructure, or by factors that change the target I/O profile like insufficient memory, as discussed previously.

The first step in storage validation is to verify that the database latencies are below the target thresholds. In previous releases, logical disk counters determined disk read and write latency. In Exchange 2010, the Exchange Mailbox server that you are monitoring is likely to have a mix of active and passive mailbox database copies. The I/O characteristics of active and passive database copies are different. Because the size of the I/O is much larger on passive copies, there are typically much higher latencies on passive copies. Latency targets for passive databases are 200 msec, which is 10 times higher than targets on active database copies. This isn't much of a concern because high latencies on passive databases have no impact on client experience. But if you are using the traditional logical disk counters to measure latencies, you must review the individual volumes and separate volumes containing active and passive databases. Instead, we recommend that you use the new MSExchange Database counters in Exchange 2010.

When validating latencies on Exchange 2010 Mailbox servers, we recommend you use the counters in the following table for active databases.

Counter	Target
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 msec
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 msec
MSExchange Database\IO Log Writes Average Latency	<1 msec

We recommend that you use the counters in the following table for passive databases.

Counter	Target
MSExchange Database\I/O Database Reads (Recovery) Average Latency	<200 msec
MSExchange Database\I/O Database Writes (Recovery) Average Latency	<200 msec
MSExchange Database\IO Log Read Average Latency	<200 msec

Note   To view these counters in Performance Monitor, you must enable the advanced database counters. For more information, see How to Enable Extended ESE Performance Counters.

In addition to disk latencies, review the Database\Database Page Fault Stalls/sec counter. This counter indicates the rate of page faults that can't be serviced because there are no pages available for allocation from the database cache. This counter should be 0 on a healthy server.

Counter	Target
Database\Database Page Fault Stalls/sec	<1

Also, review the Database\Log Record Stalls/sec counter, which indicates the number of log records that can't be added to the log buffers per second because the log buffers are full. This counter should average less than 10.

Counter	Target
Database\Log Record Stalls/sec	<10

Exchange Application Health

Even if there are no obvious issues with processor, memory, and disk, we recommend that you monitor the standard application health counters to ensure that the Exchange Mailbox server is in a healthy state.

The MSExchangeIS\RPC Averaged Latency counter provides the best indication of whether other counters with high database latencies are actually impacting Exchange health and client experience. Often, high RPC averaged latencies are associated with a high number of RPC requests, which should be less than 70 at all times.

Counter	Target
MSExchangeIS\RPC Averaged Latency	<10 msec on average
MSExchangeIS\RPC Requests	<70 at all times

Next, make sure that the transport layer is healthy. Any issues in transport or issues downstream of transport affecting the transport layer can be detected with the MSExchangeIS Mailbox(_Total)\Messages Queued for Submission counter. This counter should be less than 50 at all times. There may be temporary increases in this counter, but the counter value shouldn't grow over time and shouldn't be sustained for more than 15 minutes.

Counter	Target
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	<50 at all times

Next, ensure that maintenance of the database copies is in a healthy state. Any issues with log shipping or log replay can be identified using the MSExchange Replication(*)\CopyQueueLength and MSExchange Replication(*)\ReplayQueueLength counters. The copy queue length shows the number of transaction log files waiting to be copied to the passive copy log file folder and should be less than 1 at all times. The replay queue length shows the number of transaction log files waiting to be replayed into the passive copy and should be less than 5. Higher values don't impact client experience, but result in longer store mount times when a handoff, failover, or activation is performed.

Counter	Target
MSExchange Replication(*)\CopyQueueLength	<1
MSExchange Replication(*)\ReplayQueueLength	<5

Client Access Servers

To determine whether a Client Access server is healthy, review processor, memory, and application health. For an extended list of important counters, see Leistungsindikatoren für Clientzugriffsserver.

Processor

For physical Exchange deployments, use the Processor(_Total)\% Processor Time counter. This counter should be less than 80 percent on average.

Counter	Target
Processor(_Total)\% Processor Time	<80%

For validating Exchange deployments running on Microsoft Hyper-V, use the Hyper-V Hypervisor Virtual Processor\% Guest Run Time counter. This provides an accurate value for the amount of physical CPU being utilized by the guest operating system. This counter should be less than 80 percent on average.

Counter	Target
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%

Application Health

To determine whether the MAPI client experience is acceptable, use the MSExchange RpcClientAccess\RPC Averaged Latency counter. This counter should be below 250 msec. High latencies can be associated with a large number of RPC requests. The MSExchange RpcClientAccess\RPC Requests counter should be below 40 on average.

Counter	Target
MSExchange RpcClientAccess\RPC Averaged Latency	<250 msec
MSExchange RpcClientAccess\RPC Requests	<40

Transport Servers

To determine whether a transport server is healthy, review processor, disk, and application health. For an extended list of important counters, see Leistungsindikatoren für Transport-Server.

Processor

For physical Exchange deployments, use the Processor(_Total)\% Processor Time counter. This counter should be less than 80 percent on average.

Counter	Target
Processor(_Total)\% Processor Time	<80%

For validating Exchange deployments running on Microsoft Hyper-V, use the Hyper-V Hypervisor Virtual Processor\% Guest Run Time counter. This provides an accurate value for the amount of physical CPU being utilized by the guest operating system. This counter should be less than 80 percent on average.

Counter	Target
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%

Disk

To determine whether disk performance is acceptable, use the Logical Disk(*)\Avg. Disk sec/Read and Write counters for the volumes containing the transport logs and database. Both of these counters should be less than 20 msec.

Counter	Target
Logical Disk(*)\Avg. Disk sec/Read	<20 msec
Logical Disk(*)\Avg. Disk sec/Write	<20 msec

Application Health

To determine whether a Hub Transport server is sized properly and running in a healthy state, examine the MSExchangeTransport Queues counters outlined in the following table. All of these queues will have messages at various times. You want to ensure that the queue length isn't sustained and growing over a period of time. If larger queue lengths occur, this could indicate an overloaded Hub Transport server. Or, there may be network issues or an overloaded Mailbox server that's unable to receive new messages. You will need to check other components of the Exchange environment to verify.

Counter	Target
MSExchangeTransport Queues(_total)\Aggregate Delivery	<3000
MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250
MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250
MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100
MSExchangeTransport Queues(_total)\Submission Queue Length	<100

Zurück zum Seitenanfang

Functional Validation Tests

You can use the information in the following sections for functional validation tests.

Database Switchover Validation

A database switchover is the process by which an individual active database is switched over to another database copy (a passive copy), and that database copy is made the new active database copy. Database switchovers can happen both within and across datacenters. A database switchover can be performed by using the Exchange Management Console (EMC) or the Exchange Management Shell.

To validate that a passive copy of a database can be successfully activated on another server, run the following command.

Move-ActiveMailboxDatabase <DatabaseName> -ActivateOnServer <TargetServer>

Success criteria: The active mailbox database is mounted on the specified target server. This result can be confirmed by running the following command.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Server Switchover Validation

A server switchover is the process by which all active databases on a DAG member are activated on one or more other DAG members. Like database switchovers, a server switchover can occur both within a datacenter and across datacenters, and it can be initiated by using both the EMC and the Shell.

• To validate that all passive copies of databases on a server can be successfully activated on other servers hosting a passive copy, run the following command.

  Get-MailboxDatabase -Server <ActiveMailboxServer> | Move-ActiveMailboxDatabase -ActivateOnServer <TargetServer>
  

• To validate that one copy of each of the active databases will be successfully activated on another Mailbox server hosting passive copies of the databases, shut down the server by performing the following action.

  Turn off the current active server.

  Success criteria: The active mailbox databases are mounted on another Mailbox server in the DAG. This can be confirmed by running the following command.

  Get-MailboxDatabaseCopyStatus <DatabaseName>
  

Server Failover Validation

A server failover occurs when the DAG member can no longer service the MAPI network, or when the Cluster service on a DAG member can no longer contact the remaining DAG members.

To validate that one copy of each of the active databases will be successfully activated on another Mailbox server hosting passive copies of the databases, turn off the server by performing one of the following actions:

• Press and hold the power button on the server until the server turns off.

• Pull the power cables from the server, which results in the server turning off.

Success criteria: The active mailbox databases are mounted on another Mailbox server in the DAG. This can be confirmed by running the following command.

Get-MailboxDatabase -Server <MailboxServer> | Get-MailboxDatabaseCopyStatus

Zurück zum Seitenanfang

Datacenter Switchover Validation

A datacenter or site failure is managed differently from the types of failures that can cause a server or database failover. In a high availability configuration, automatic recovery is initiated by the system, and the failure typically leaves the messaging system in a fully functional state. By contrast, a datacenter failure is considered to be a disaster recovery event, and as such, recovery must be manually performed and completed for the client service to be restored and for the outage to end. The process you perform is called a datacenter switchover. As with many disaster recovery scenarios, prior planning and preparation for a datacenter switchover can simplify your recovery process and reduce the duration of your outage.

For more information, including detailed steps for performing a datacenter switchover, see Datencenterswitchover.

There are four basic steps that you complete to perform a datacenter switchover, after making the initial decision to activate the second datacenter:

1. Terminate a partially running datacenter.

2. Validate and confirm the prerequisites for the second datacenter.

3. Activate the Mailbox servers.

4. Activate the Client Access servers.

The following describes the steps used to validate a datacenter switchover.

Terminate Partially Failed Datacenter (Assuming DAG Is in DAC Mode)

When the DAG is in DAC mode, the specific actions to terminate any surviving DAG members in the primary datacenter depend on the state of the failed datacenter. Perform one of the following:

• If the Mailbox servers in the failed datacenter are still accessible (usually not the case), run the following command on each Mailbox server.

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename>
  

• If the Mailbox servers in the failed datacenter are unavailable but Active Directory is operating in the primary datacenter, run the following command on a domain controller.

  Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly
  

Hinweis

Failure to either turn off the Mailbox servers in the failed datacenter or to successfully perform the Stop-DatabaseAvailabilityGroup command against the servers will create the potential for split brain syndrome to occur across the two datacenters. You may need to individually turn off computers through power management devices to satisfy this requirement.

Success criteria: All Mailbox servers in the failed site are in a stopped state. You can verify this by running the following command from a server in the failed datacenter.

Get-DatabaseAvailabilityGroup | Format-List

Validate and Confirm Prerequisites for Secondary Datacenter

The second datacenter must be updated to represent which primary datacenter servers are stopped. From a server in the secondary datacenter, run the following command.

Stop-DatabaseAvailabilityGroup -ActiveDirectorySite <insertsitename> -ConfigurationOnly

The purpose of this step is to inform the servers in the secondary datacenter about which Mailbox servers are available to use when restoring service.

Success criteria: All Mailbox servers in the failed datacenter are in a stopped state. To verify this, run the following command from a server in the secondary datacenter.

Get-DatabaseAvailabilityGroup | Format-List

Activate Mailbox Servers (Assuming DAG Is in DAC Mode)

Before activating the DAG members in the secondary datacenter, we recommend that you verify that the infrastructure services in the secondary datacenter are ready for messaging service activation.

When the DAG is in DAC mode, the steps to complete activation of the Mailbox servers in the second datacenter are as follows:

1. Stop the cluster service on each DAG member in the secondary datacenter. You can use the Stop-Service cmdlet to stop the service (for example, Stop-Service ClusSvc), or use net stop clussvc from an elevated command prompt.

2. To activate the Mailbox servers in the secondary datacenter, run the following command.

   Restore-DatabaseAvailabilityGroup -Identity <DAGname> -ActiveDirectorySite <insertsitename>
   

   If this command succeeds, the quorum criteria are shrunk to the servers in the secondary datacenter. If the number of servers in that datacenter is an even number, the DAG will switch to using the alternate witness server as identified by the setting on the DAG object.

3. To activate the databases, run one of the following commands.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinPrimarySite>
   

   or

   Move-ActiveMailboxDatabase -Server <DAGMemberInSecondarySite> -ActivateOnServer <DAGMemberinPrimarySite>
   

4. Check the event logs and review all error and warning messages to ensure that the secondary site is healthy. Any indicated issues should be followed up and corrected prior to mounting the databases.

5. To mount the databases, run the following command.

   Get-MailboxDatabase <DAGMemberInSecondarySite> | Mount-Database
   

Success criteria: The active mailbox databases are mounted on Mailbox servers in the secondary site. To confirm, run the following command.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Activate Client Access Servers

Clients connect to service endpoints to access Exchange services and data. Activating Internet-facing Client Access servers therefore involves changing DNS records to point to the new IP addresses that will be configured for the new service endpoints. Clients will then automatically connect to the new service endpoints in one of two ways:

• Clients will continue to try to connect, and should automatically connect after Time to Live (TTL) has expired for the original DNS entry, and after the entry is expired from the client's DNS cache. Users can also run the ipconfig /flushdns command from a command prompt to manually clear their DNS cache. If using Outlook Web App, the Web browser may need to be closed and restarted to clear the DNS cache used by the browser. In Exchange 2010 SP1, this browser caching issue can be mitigated by configuring the FailbackURL parameter on the Outlook Web App virtual directory owa.

• Clients starting or restarting will perform a DNS lookup on startup and will get the new IP address for the service endpoint, which will be a Client Access server or array in the second datacenter.

To validate the scenario with Loadgen, perform the following actions:

1. Change the DNS entry for the Client Access server array to point to the virtual IP address of the hardware load balancing in the secondary site.

2. Run the ipconfig /flushdns command on all Loadgen servers.

3. Restart the Loadgen test.

4. Verify that the Client Access servers in the secondary site are now servicing the load.

To validate the scenario with an Outlook 2007 client, perform the following:

1. Change the DNS entry for the Client Access server array to point to the virtual IP of the hardware load balancing in the secondary site.

2. Run the ipconfig /flushdns command on the client or wait until TTL expires.

3. Wait for the Outlook client to reconnect.

Zurück zum Seitenanfang

Primary Datacenter Service Restoration Validation

The process of restoring service to a previously failed datacenter is referred to as a failback. The steps used to perform a datacenter failback are similar to the steps used to perform a datacenter switchover. A significant distinction is that datacenter failbacks are scheduled, and the duration of the outage is often much shorter.

It's important that failback not be performed until the infrastructure dependencies for Exchange have been reactivated, are functioning and stable, and have been validated. If these dependencies aren't available or healthy, it's likely that the failback process will cause a longer than necessary outage, and it's possible the process could fail altogether.

Mailbox Server Role Failback (Assuming DAG Is in DAC Mode)

The Mailbox server role should be the first role that's failed back to the primary datacenter. The following steps detail the Mailbox server role failback process.

1. To reincorporate the DAG members in the primary site, run the following command.

   Start-DatabaseAvailabilityGroup -Identity <DatabaseAvailabilityGroupIdParameter> -ActiveDirectorySite <insertsitename>
   

2. To verify the state of the database copies in the primary datacenter, run the following command.

   Get-MailboxDatabaseCopyStatus
   

After the Mailbox servers in the primary datacenter have been incorporated into the DAG, they will need some time to synchronize their database copies. Depending on the nature of the failure, the length of the outage, and actions taken by an administrator during the outage, this may require reseeding the database copies. For example, if during the outage, you remove the database copies from the failed primary datacenter to allow log file truncation to occur for the surviving active copies in the secondary datacenter, reseeding will be required. At this time, each database can be synchronized individually. After a replicated database copy in the primary datacenter is healthy, you can proceed to the next step.

1. During the datacenter switchover process, the DAG was configured to use an alternate witness server. To reconfigure the DAG to use a witness server in the primary datacenter, run the following command.

   Set-DatabaseAvailabilityGroup -Identity <DAGName> -WitnessServer <PrimaryDatacenterWitnessServer>
   

2. The databases being reactivated in the primary datacenter should now be dismounted in the secondary datacenter. Run the following command.

   Get-MailboxDatabase | Dismount-Database
   

3. After the databases have been dismounted, the Client Access server URLs should be moved from the secondary datacenter to the primary datacenter. To do this, change the DNS record for the URLs to point to the Client Access server or array in the primary datacenter.

   Wichtig

   Don't proceed to the next step until the Client Access server URLs have been moved and the DNS TTL and cache entries have expired. Activating the databases in the primary datacenter prior to moving the Client Access server URLs to the primary datacenter will result in an invalid configuration (for example, a mounted database that has no Client Access servers in its Active Directory site).

4. To activate the databases, run one of the following commands.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Move-ActiveMailboxDatabase -ActivateOnServer <DAGMemberinSecondSite>
   

   or

   Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
   

5. To mount the databases, run the following command.

   Get-MailboxDatabase <insertcriteriatoselectDBs> | Mount-Database
   

Success criteria: The active mailbox databases are successfully mounted on Mailbox servers in the primary site. To confirm, run the following command.

Get-MailboxDatabaseCopyStatus <DatabaseName>

Zurück zum Seitenanfang

Test Facility

Testing was conducted at the Microsoft Enterprise Engineering Center, a state-of-the-art enterprise solutions validation laboratory on the Microsoft main campus in Redmond, Washington.

With more than 125 million dollars in hardware and with ongoing strong partnerships with the industry's leading original equipment manufacturers (OEMs), virtually any production environment can be replicated at the EEC. The EEC offers an environment that enables extensive collaboration among customers, partners, and Microsoft product engineers. This helps ensure that Microsoft end-to-end solutions will meet the high expectations of customers.

Zurück zum Seitenanfang

Solution Validation Results

The following section summarizes the results of the functional and performance validation tests.

Zurück zum Seitenanfang

Functional Validation Results

The following table summarizes the functional validation test results.

Functional validation results

Test case	Result	Comments
Database switchover	Successful	Completed without errors
Server switchover	Successful	Completed without errors
Server failure	Successful	Completed without errors
Site failure	Successful	Completed without errors

Zurück zum Seitenanfang

Storage Design Validation Results

The following tables summarize the Jetstress storage validation results. This solution achieved higher than target transactional I/O while maintaining database latencies well under the 20 msec target.

Overall test result

Pass

Overall throughput

Transactional I/O per second	Result
Target transactional I/O per second	383
Achieved transactional I/O per second	540

Transactional I/O performance: database reads

Database	I/O database reads per second	I/O database reads average latency (msec)
Instance1	42.2	18.9
Instance2	42.7	17.9
Instance3	42.9	17.4
Instance4	42.0	17.9
Instance5	42.0	18.0
Instance6	41.8	17.0
Instance7	42.8	17.7
Instance8	42.6	17.4

Transactional I/O performance: database writes

Database	I/O database writes per second	I/O database writes average latency (msec)
Instance1	25.9	25.9
Instance2	26.4	25.1
Instance3	26.4	21.7
Instance4	26.1	22.6
Instance5	25.9	23.8
Instance6	25.5	19.8
Instance7	26.3	21.2
Instance8	26.5	18.5

Transactional I/O performance: log writes

Database	I/O log writes per second	I/O database writes average latency (msec)
Instance1	23.8	3.8
Instance2	23.7	3.7
Instance3	24.0	3.3
Instance4	23.5	3.8
Instance5	23.7	3.8
Instance6	23.7	3.5
Instance7	23.7	3.7
Instance8	24.3	3.3

Zurück zum Seitenanfang

Server Design Validation Results

The following sections summarize the server design validation results for the test cases.

Test Case: Normal Operating Conditions

The following test case involves normal operating conditions.

Validation of Expected Load

The message delivery rate verifies that tested workload matched the target workload. The actual and target message delivery rates are the same.

Counter	Target	Tested result
Message Delivery Rate / Server	5.2	5.2

Validation of Mailbox Servers

The following tables show the validation of Mailbox servers.

Processor

Processor utilization is below 70 percent as expected.

Counter	Target	Tested result
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	55

Storage

Counter	Target	Tested result
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 msec	15
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 msec	4
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 msec	3
Database\Log Record Stalls/sec	0	0
MSExchange Database\I/O Database Reads (Recovery) Average Latency	<200 msec	7
MSExchange Database\I/O Database Writes (Recovery) Average Latency	<200 msec	4
MSExchange Database\IO Log Read Average Latency	<200 msec	1

Application Health

Counter	Target	Tested result
MSExchangeIS\RPC Requests	<70	2.7
MSExchangeIS\RPC Averaged Latency	<10 msec	4.6
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	7
MSExchange Replication(*)\CopyQueueLength	<1	0.4
MSExchange Replication(*)\ReplayQueueLength	<2	4

Validation of Client Access and Hub Transport Servers

Processor

Processor utilization is low as expected.

Counter	Target	Tested result
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<70%	26

Storage

The storage results look good. The very low latencies should have no impact on message transport.

Counter	Target	Tested result
Logical/Physical Disk(*)\Avg. Disk sec/Read	<20 msec	0.002
Logical/Physical Disk(*)\Avg. Disk sec/Write	<20 msec	0.009

Application Health

The low RPC Averaged Latency values confirm a healthy Client Access server with no impact on client experience.

Counter	Target	Tested Result
MSExchange RpcClientAccess\RPC Averaged Latency	<250 msec	12
MSExchange RpcClientAccess\RPC Requests	<40	1.8

The Transport Queue counters are all well under target, confirming the Hub Transport server is healthy and able to process and deliver the required messages.

Counter	Target	Tested result
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	1.2
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	1.2
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	0
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	0

Validation of Root Server Health

Processor

As expected, the processor utilization is very low and well under target thresholds.

Counter	Target	Tested result
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time	<75%	34
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time	<5%	4
Hyper-V Hypervisor LogicalProcessor(_total)\% Total Run Time	<80%	38
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time	<5%	2.2

Application Health

The VM health summary counters indicate that all VMs are in a healthy state.

Counter	Target	Tested result
Hyper-V Virtual Machine Health Summary\Health Critical	0	0

Test Case: Single Server Failure or Single Server Maintenance (In Site)

The following test case involves a single server failure or single server maintenance.

Validation of Expected Load

The message delivery rate verifies that tested workload matched the target workload. The tested result was slightly lower than the target message delivery rates indicating that there was slightly less load than expected.

Counter	Target	Tested result
Message Delivery Rate / Mailbox	10.4	9.6

Validation of Mailbox Servers

Processor

Processor utilization is slightly above 80 percent and just over target.

Counter	Target	Tested result
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%	81.5

Storage

Storage results look good.

Counter	Target	Tested result
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 msec	16
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 msec <Reads average	4
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 msec	5
Database\Log Record Stalls/sec	0	2

Application Health

Exchange is very healthy and all of the counters used to determine application health are well under target values.

Counter	Target	Tested result
MSExchangeIS\RPC Requests	<70	3
MSExchangeIS\RPC Averaged Latency	<10 msec	3
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	4
MSExchange Replication(*)\CopyQueueLength	<1	<1
MSExchange Replication(*)\ReplayQueueLength	<2	3

Validation of Client Access and Hub Transport Servers

Processor

Processor utilization is low as expected.

Counter	Target	Tested result
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%	50%

Storage

Storage results look good. The very low latencies should have no impact on message transport.

Counter	Target	Tested result
Logical/Physical Disk(*)\Avg. Disk sec/Read	<20 msec	0.002
Logical/Physical Disk(*)\Avg. Disk sec/Write	<20 msec	0.008
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	3
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	2.2
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	0
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	0.8

Application Health

The low RPC Averaged Latency values confirm a healthy Client Access server with no impact on client experience.

Counter	Target	Tested result
MSExchange RpcClientAccess\RPC Averaged Latency	<250 msec	16
MSExchange RpcClientAccess\RPC Requests	<40	4.6

The Transport Queue counters are all well under target, confirming that the Hub Transport server is healthy and able to process and deliver the required messages.

Counter	Target	Tested result
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	3
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	2.2
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	0
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	0.8

Validation of Root Server Health

Processor

As expected, the processor utilization is very low and well under target thresholds.

Counter	Target	Tested result
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time	<75%	51
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time	<5%	4
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time	<80%	55
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time	<5%	2.1

Application Health

The VM health summary counters indicate that all VMs are in a healthy state.

Counter	Target	Tested result
Hyper-V Virtual Machine Health Summary\Health Critical	0	0

Test Case: Site Switchover

The following test case involves a site switchover.

Validation of Expected Load

The message delivery rate verifies that tested workload matched the target workload. The tested result was slightly lower than the target message delivery rates indicating that there was slightly less load than expected.

Counter	Target	Tested result
Message Delivery Rate / Mailbox	10.4	9.9

Validation of Mailbox Servers

Processor

Processor utilization is slightly above the 80 percent target.

Counter	Target	Tested result
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%	80.5%

Storage

The storage results look good.

Counter	Target	Tested result
MSExchange Database\I/O Database Reads (Attached) Average Latency	<20 msec	14
MSExchange Database\I/O Database Writes (Attached) Average Latency	<20 msec <Reads average	4
Database\Database Page Fault Stalls/sec	0	0
MSExchange Database\IO Log Writes Average Latency	<20 msec	6
Database\Log Record Stalls/sec	0	2.6

Application Health

Exchange is very healthy and all of the counters used to determine application health are well under target values.

Counter	Target	Tested result
MSExchangeIS\RPC Requests	<70	3.6
MSExchangeIS\RPC Averaged Latency	<10 msec	3.0
MSExchangeIS Mailbox(_Total)\Messages Queued for Submission	0	2.3

Validation of Client Access and Hub Transport Servers

Processor

Processor utilization is below 80 percent as expected.

Counter	Target	Tested result
Hyper-V Hypervisor Virtual Processor\% Guest Run Time	<80%	54

Storage

Storage results look good. The very low latencies should have no impact on message transport.

Counter	Target	Tested result
Logical/Physical Disk(*)\Avg. Disk sec/Read	<20 msec	0.005
Logical/Physical Disk(*)\Avg. Disk sec/Write	<20 msec	0.007
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	2.1
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	1.4
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	0
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	0.7

Application Health

The low RPC Averaged Latency values confirm a healthy Client Access server with no impact on client experience.

Counter	Target	Tested result
MSExchange RpcClientAccess\RPC Averaged Latency	<250 msec	10
MSExchange RpcClientAccess\RPC Requests	<40	3.6

The Transport Queue counters are all well under target, confirming that the Hub Transport server is healthy and able to process and deliver the required messages.

Counter	Target	Tested result
\MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)	<3000	2.1
\MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length	<250	0
\MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length	<250	1.4
\MSExchangeTransport Queues(_total)\Submission Queue Length	<100	0
\MSExchangeTransport Queues(_total)\Retry Mailbox Delivery Queue Length	<100	0.7

Validation of Root Server Health

Processor

As expected, the processor utilization is under target thresholds.

Counter	Target	Tested result
Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time	<75%	53
Hyper-V Hypervisor Logical Processor(_total)\% Hypervisor Run Time	<5%	4
Hyper-V Hypervisor Logical Processor(_total)\% Total Run Time	<80%	58
Hyper-V Hypervisor Root Virtual Processor(_total)\% Guest Run Time	<5%	2.5

Application Health

The VM health summary counters indicate that all VMs are in a healthy state.

Counter	Target	Tested result
Hyper-V Virtual Machine Health Summary\Health Critical	0	0

Zurück zum Seitenanfang

Schlussbemerkung

This white paper provides an example of how to design, test, and validate an Exchange 2010 solution for customer environments with 15,000 mailboxes in two sites deployed on Unisys servers and a Hitachi Adaptable Modular Storage 2100. The step-by-step methodology in this document walks through the important design decision points that help address key challenges while ensuring that the customer's core business requirements are met.

Zurück zum Seitenanfang

Weitere Informationen

For the complete Exchange 2010 documentation, see Exchange Server 2010.

For additional information related to Unisys and Hitachi Data Systems, see the following resources:

• Unisys Enterprise Servers: Data Center Transformation and Outsourcing - Enterprise Servers

• Unisys Email Management Services: Data Center Transformation and Outsourcing - Enterprise Computing Solutions

• Unisys and Exchange 2010: Unisys Solutions for Latest Microsoft Software Boost Clients’ Productivity Options – from Data Centers to Mobile Offices

• Hitachi Data Systems storage products: Transform Your Data Center into Your Information Center

• Hitachi Data Systems storage software products: Manage Your Data, Optimize Performance and Reduce Costs

• Hitachi Data Systems solutions for Exchange: Solutions : Microsoft Exchange

This document is provided "as-is." Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Zurück zum Seitenanfang