emc virtual infrastructure for microsoft exchange 2010 of contents emc virtual infrastructure for...

EMC Virtual Infrastructure for Microsoft Exchange 2010

Enabled by

EMC Symmetrix VMAX, VMware vSphere 4, and EMC Replication Manager

Proven Solution Guide

EMC Virtual Infrastructure for Microsoft Exchange 2010 - Enabled by EMC Symmetrix VMAX, VMware

vSphere 4, and EMC Replication Manager - Proven Solution Guide 2

Copyright © 2010 EMC Corporation. All rights reserved.

Published November, 2010

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

Benchmark results are highly dependent upon workload, specific application requirements, and system design and implementation. Relative system performance will vary as a result of these and other factors. Therefore, this workload should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated.

All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary significantly.

EMC Corporation does not warrant or represent that a user can or will achieve similar performance expressed in transactions per minute.

No warranty of system performance or price/performance is expressed or implied in this document. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their respective owners.

Part number: H7392

Table of Contents



Table of Contents

Chapter 1: About this Proven Solution Guide .......................................................... 4

Audience and purpose ...................................................................................................................... 5

Business challenge ........................................................................................................................... 5

Objectives.......................................................................................................................................... 6

Technology solution .......................................................................................................................... 7

Hardware and software resources .................................................................................................... 8

Physical architecture ......................................................................................................................... 9

Chapter 2: Exchange Server 2010 Database and DAG Design ............................. 10

Overview ......................................................................................................................................... 10

Chapter 3: Exchange Server 2010 Storage Design on the Symmetrix VMAX ..... 13

Overview ......................................................................................................................................... 13

Virtual Provisioning design on the Symmetrix VMAX ..................................................................... 20

Chapter 4: Backup and Restore of Exchange Server 2010 Data with Replication Manager ................................................................................................. 24

Overview ......................................................................................................................................... 24

RM and Exchange Server 2010 ...................................................................................................... 24

Replication Manager design............................................................................................................ 26

Rapid Restore using Replication Manager ..................................................................................... 30

Chapter 5: Performance Testing and Validation Results ...................................... 34

Overview ......................................................................................................................................... 34

Methodology and tools .................................................................................................................... 35

Database seeding performance ...................................................................................................... 36

Environment validation with LoadGen ............................................................................................ 37

Test 1 – 24-hour end-to-end validation testing ............................................................................... 38

Chapter 6: Conclusion ............................................................................................. 46

Chapter 1: About this Proven Solution Guide



Chapter 1: About this Proven Solution Guide Introduction This Proven Solution Guide outlines a collection of design guidance best practices

for a solution using EMC Virtual Infrastructure for Microsoft Exchange 2010 enabled by EMC® Symmetrix® VMAX™, VMware vSphere 4, and Replication Manager.

EMC's commitment to consistently maintain and improve quality is led by the Total Customer Experience (TCE) program, which is driven by Six Sigma methodologies. As a result, EMC has built Customer Integration Labs in its Global Solutions Centers to reflect real-world deployments in which TCE use cases are developed and executed. These use cases provide EMC with an insight into the challenges currently facing its customers.




Audience and purpose

Audience The intended audience for the Proven Solution Guide is:

• Internal EMC personnel, who are responsible for selling and designing EMC application-related solutions.

• EMC partners, who are responsible for selling and designing EMC application-related solutions.

• Customers, who are responsible for purchasing and designing application-related solutions.

Purpose The purpose of this solution is to:

• Validate the process of creating virtualized Exchange Server 2010 building blocks for the VMAX storage array with VMware vSphere. Multiple building blocks were validated to better highlight the flexibility of the design methodology.

• Show how Virtual Provisioning™ can successfully and easily be used on a VMAX with Exchange Server 2010 mailbox database volumes to provide significant up-front cost savings and unlimited mailbox growth.

• Provide best practice guidance and recommendations as well as performance details about implementing and using DAGs to provide local HA for Exchange Server 2010 with VMAX.

• Provide best practices and recommendations as well as performance details about using RM and VMAX snapshots to back up and restore Exchange Server 2010.

In this solution all of the key components have been integrated and leveraged to provide a highly scalable storage solution for Exchange Server 2010. EMC Replication Manager is also a part of this solution. It is used to coordinate the creation of online snapshots of the passive database copy to automate the backup and restore of the Exchange Server 2010 databases.

Business challenge

Overview Today, customers are striving to provide users with larger mailboxes, improved

uptime while reducing their organizations’ Exchange Server 2010 backup window, and overall mailbox cost. With current trends, Exchange users’ mailbox sizes are growing rapidly, thus making it more challenging, if not impossible, to back up all of the Exchange data within the nightly backup windows.

Businesses also consider reducing the server and storage cost and footprint for the Exchange servers and storage to be of vital importance. With the use of vSphere and VMAX Virtual Provisioning, users can achieve significant reduction in these areas without performance degradation.




Objectives

Objectives The following describes the objectives of this solution:

• Design the Exchange Server 2010 vSphere environment on a VMAX array using

the building block approach.

• Validate all aspects of the Exchange environment by executing performance testing with Jetstress and LoadGen.

• Implement and test EMC Virtual Provisioning (VP) for Exchange Server 2010 and show how VP can be used to grow a volume without production interruption.

• Design and implement DAGs for local HA.

• Design and implement Replication Manager for Exchange Server 2010 to take Microsoft Volume Shadow Copy Service (VSS) backup of a DAG copy using TimeFinder® snaps.

• Provide design guidance and performance results for vSphere, VMAX, RM, DAGs, Virtual Provisioning, and TimeFinder snaps.




Technology solution

Overview This enterprise Microsoft Exchange Server 2010 solution provides:

• Information on using VMware vSphere and EMC Symmetrix VMAX with Microsoft Exchange 2010 servers and how this can significantly reduce hardware requirements of Exchange.

• Reduced total cost of ownership (TCO) by reducing initial allocation of storage capacity and simplifying management. Thin provisioning provided by the EMC Symmetrix Virtual Provisioning feature allows the application to consume space only as needed, without reallocation or reconfiguration.

• Minimal to no impact on the Exchange servers during the backup with RM and VMAX TimeFinder® software, which creates VSS space-efficient snapshots for logical protection. This requires much less disk space than tape or full clone copies.

• Exceptional backup and recovery performance so that data remains highly available. Once a snapshot of the Exchange data is taken and presented to the mount host, you can use any backup software to take a backup from that copy, which is isolated from the production environment.




Hardware and software resources

EMC used the following equipment to validate this solution.

Hardware Equipment Quantity Configuration

Symmetrix VMAX 1 • Microcode version 5874.207.166 • 480, 600 GB 10k FC disks • 240, 1 TB 10k SATA disks

Storage connectivity (FC, SAS, SATA, iSCSI) FC

SAN switch 1 Cisco® MDS 9509

IP switch 1 Cisco Catalyst 3560

ESX server 4 • Dell PowerEdge R900 • 6 core, 128 GB RAM • 2 dual-port, 4 Gb QLogic HBA Each will host 4 Exchange Mailbox VM Servers

Host bus adapter (HBA) and firmware 8 2 dual-port, 4 GB HBAs (QLA2562) per host

Total number of disks tested in the solution 128 600 GB 10k FC disks Profile 2: 64 1 TB 7.2k SATA disks

Replication Manager Server & Mount host 1 Dell R900

EMC used the following software to validate this solution.

Software Version

HBA driver QLogic 9.1.7.16 2/15/2008

VMAX microcode 5874.207.166

Multipathing EMC PowerPath®/VE 5.4 (64 bit)

Host OS Microsoft Windows Server 2008 - Enterprise Service Pack 2

Exchange Server 2010 14.0.639.19

VMware vSphere Version 4.0, Update 1, Build 208111

Replication Manager 5.2.3




Physical architecture

Architecture diagram

The following illustration depicts the solution’s overall physical architecture.

Figure 1 Physical architecture diagram

Chapter 2: Exchange Server 2010 Database and DAG Design




Overview

What is a DAG? A DAG is the base component of the High Availability (HA) and site resilience

framework built into Microsoft Exchange Server 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide 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 Server 2010 component that manages switchovers and failovers and that runs on every server in a DAG.

Planning your DAG deployment

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.

• Have active mailbox users in multiple sites (Active/Active site configuration).

• Require separate DAG-level administrative boundaries.

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

It is also recommended to evenly distribute your active and passive database copies among your Mailbox servers. This will provide for best distribution of server resources, especially memory, in servicing your active databases and users. Our design accommodates this goal by deploying four active and four passive databases for each Mailbox VM.

Each VM has the capacity to handle all eight databases or 5,000 users, but in normal conditions only 2,500 users would be active against each Mailbox server VM. In this design the grouping of four databases and 2,500 users was used and carried forward to the backup configuration with RM in an effort to make the management as easy as possible.

Since this is a vSphere environment, the design also accounted for the reboot or loss of an ESX server. If an active database was on a VM housed on ESX server 1, its passive copies would be on ESX server 2. So, if either ESX server needed to be rebooted, due to patching or maintenance, there would be no loss of service to the user mailboxes. The design incorporated the following:

• Total of 32 active and 32 passive databases, with 625 users per database to house the 20,000 users.

• Mailbox databases are grouped in collections of 4 (2500 Users).

• Each Mailbox VM has 4 active and 4 passive mailbox databases.




• The active and passive database copies do not reside on the same server.

• RM Application sets and jobs are based on the grouping of four.

The database placement among the VMs and ESX servers is described in Table 1 Database placement. Table 1 Database placement

The design provided for no single point of failure and spreading the load for maximum performance in normal operating conditions.

Occasionally a DAG copy will need to be re-seeded. It is important to understand the impact on the server and seeding performance that can be achieved to best plan for seeding operations. Our re-seed testing was not conducted under load so the results represent a best case scenario.

• Steady 40 percent network utilization on a 1 Gb/s link during re-seeding of a single database was observed.

• With a database of 575 GB and Index of 250 GB it took 6 hours and 15 minutes to seed both database & index. This equates to approximately 2.2 GB per minute for a single database.

• When re-seeding more than one DB at a time seeding results were inconsistent and often resulted in the seeding for one of the databases failing. Based on our testing, it is recommended that a single DB be seeded at a time whenever possible.




Figure 2 represents what a seeding operation looks like from the Exchange Management Console and Windows Task Manager applets and highlights the steady 40 utilization on a 1 Gb/s link for a single database.

Figure 2 Network utilization during database seeding process

Chapter 3: Exchange Server 2010 Storage Design on the Symmetrix VMAX




Overview

Introduction to EMC Virtual Infrastructure for Microsoft Exchange Server 2010

Storage design is an important element to ensure the successful development for creating a Microsoft Exchange 2010 building block on the Symmetrix VMAX. The process is essentially the same design for a physical environment as a virtual building block, from a disk perspective, except that in the virtual environment the VM’s OS volume also needs to be accounted for.

The virtualized Exchange Server 2010 Storage Design includes a number of different pieces including:

• Storage Design Requirements - Disk requirements and layout.

• Virtual Provisioning – Pool design.

• vSphere VM Building Block – ESX and VM design and resource requirements.

Each of these will be discussed in detail in this section.

Design guidelines for virtualized Exchange Server 2010 on the Symmetrix VMAX array

The following list provides design guidance for Exchange Server 2010 on a VMAX:

• I/O requirements include user I/O (send/receive) plus 20 percent. The 20 percent accounts for some overhead as well as sequential I/Os such as log and BDM.

• Database and log I/O should be evenly distributed among the SAN switch and storage back end.

• Laying out database and log volumes across the same spindle is recommended with Exchange 2010 data on VMAX.

• Use the Exchange building block DAG design approach whenever possible for both thick and thin device configurations.

• To achieve better performance, use fewer larger hyper-volumes when creating LUNs.

• A minimum of two HBAs are required per server.

• When using a hypervisor to virtualize the Exchange servers a minimum of three IP connections is recommended for each ESX server.

• Always calculate I/O spindle requirements first, then capacity requirements.

• When unsure of the Read/Write ratio, use the default ratio of 3:2 with Exchange Server 2010 in the Mailbox Resiliency configuration (DAG).

• Isolate the Microsoft Exchange server database workload from other I/O-intensive applications or workloads. This ensures the highest level of performance for Exchange and simplifies troubleshooting in the event of a disk-related Microsoft Exchange performance issue.

• Install EMC PowerPath for optimal path management and maximum I/O




performance. For more information on installing and configuring the PowerPath application, visit: http://www.emc.com/products/detail/software/powerpath-multipathing.htm

Visit the following Microsoft websites for guidance on determining server memory and CPU requirements:

http://technet.microsoft.com/en-us/library/ee832793.aspx (Memory)

http://technet.microsoft.com/en-us/library/ee712771.aspx (CPU)

Sizing storage for the Exchange Server 2010 environment

Sizing and configuring storage for use with Microsoft Exchange Server 2010 can be a complicated process, driven by many variables and factors, which vary from organization to organization. Properly configured Exchange storage, combined with properly sized server and network infrastructure, can guarantee smooth Exchange operation and best user experience. One of the methods that can be used to simplify the sizing and configuration of large Microsoft Exchange Server 2010 environments is to define a unit of measure—a building block.

What is a building block?

A building block represents the required amount of disk and server resources required to support a specific number of Exchange Server 2010 users. The amount of required resources is derived from: • A specific user profile type.

• Mailbox size.

• Disk requirements.

Using the building block approach takes out the guesswork and simplifies the implementation of Exchange Server 2010 Mailbox Server. Once the initial building block is designed, it can be easily reproduced to support the required number of total users in your organization. By using this approach, Exchange administrators can now create their own building blocks that are based on their company’s specific Exchange environment requirements. This approach is very helpful when future growth is expected, as it makes Exchange environment expansion much easier, and straightforward. EMC’s best practices involving the building block approach for Exchange Server design proved to be very successful throughout many customer implementations.

Exchange Server 2010 building block design process

The high-level building block design process for Exchange Server 2010 is similar to that used for Exchange 2007. Review Table 2 for an understanding of the process flow used to develop and validate the test environment’s storage design.

http://www.emc.com/products/detail/software/powerpath-multipathing.htm�

http://technet.microsoft.com/en-us/library/ee832793.aspx�

http://technet.microsoft.com/en-us/library/ee712771.aspx�




Table 2 Process flow used in test environment storage design

Phase Description

1 In this phase, the Exchange administrator identifies: Collect user requirements

• Number of users.

• Average message size.

• User I/O profile = Send/Receive and message size per user.

• Mailbox size.

• Deleted Item Retention.

• Concurrency.

• Replication required, number of DAG database copies.

• Backup Restore requirements (RTO or RPO).

• Third-party software that affects capacity or I/O (BlackBerry).

2 In this phase, the Exchange design is developed based on: Design the storage architecture based on user requirements

• EMC Exchange building block methodology.

• EMC Exchange Server 2010 proven solutions.

• EMC and Microsoft best practices.

• Published Exchange Server 2010 Exchange Solution Review Program (ESRP) documentation is located at:

o http://technet.microsoft.com/en-us/exchange/ff182054.aspx.

3 In this phase, the design is validated with the following tools: Validate the design

• Jetstress is used to validate storage.

• LoadGen is used to validate storage and Exchange server performance and an end-to-end Exchange 2010 environment.

http://technet.microsoft.com/en-us/exchange/ff182054.aspx�




Applying the building block design process to Exchange Server 2010

The following sections walk you through the storage design process applied.

Phase 1—Collect user requirements

The user requirements used to validate both the building block storage design methodology and VMAX performance are detailed in Table 3.

Table 3 Collect user requirements Item User requirement

Total Number of users per server 20,000

User I/O profile 150 messages sent\received per day = .15 IOPS per user per day in a DAG setup

User Mailbox size Start with 1 GB, grow to 2.5 GB

Deleted item retention 15 days

Concurrency 100 percent

RTO for Database and Server 5 Minutes

Replication required Yes (1 DAG) 2 Copies

Backup/Restore required Yes (Hardware VSS) Note that the requirements include starting with a user mailbox size of 1 GB with the ability to seamlessly grow to 2.5 GB. We will show how with VMAX Virtual Provisioning this can be easily accomplished.

Based on the user requirements a virtual Exchange Building block of 5,000 users per server was created. The decision on the number of users per server was based on a number of factors, including:

• Total Number of users - Use this number to find a figure that can be evenly divided by a per-server number.

• User Profile - A larger user I/O profile or large mailbox will usually dictate fewer users per building block.

• Recovery Time Objective - With a short RTO and depending on the backup and restore technology used, fewer users may be able to be supported within a single building block.

• Array features - The ability of an intelligent array, such as the VMAX, to back up and restore larger amounts of Exchange data in seconds make it much easier to achieve good consolidation.

• Simplicity & ease of design - Fewer larger databases will help and using a SAN and intelligent storage will make this easier to achieve.

• ESX Server configuration, memory and number of virtual CPUs available - Your building block must fit your hardware so that your ESX resources need to be




factored in.

Table 4 Required information for Building Block design Building Block characteristic Value

Maximum number of Exchange Server 2010 users that the Mailbox server needs to support in a failure situation

5000

Number of Databases per server 8 (4 active - 4 passive)

Number of users per database 625

RAID Type RAID 5 (7+1)

Disk Type 600 GB 10k FC drives

Number of ESX servers for Mailbox VMs 4

Total number of Exchange Mailbox VMs 8

Number of DAGs 1

Number of database copies (Mailbox Resiliency) 2 (1 active - 1 passive)

Phase 2—Design the storage architecture based on user requirements

First calculate the spindle requirements per building block from an I/O perspective, then the space requirements. The following formula can be used to calculate storage for the Exchange Server 2010 database and logs from an I/O perspective on EMC storage.

(IOPS * percent R) + WP (IOPS * percent W) / Physical Disk Speed = Required Physical Disks

Table 5 Formula details Where Is

IOPS The number of input/output operations per second

Percent R The percentage of I/Os that are reads

Percent W The percentage of I/Os that are writes

WP The RAID write penalty multiplier (RAID 1=2, RAID 5=4)

Physical Disk Speed 60 IOPs for 7.2k rpm drives or 130 IOPs for 10k rpm drives on VMAX




Storage requirements calculated for the Exchange Server 2010 test environment

The calculations for the Exchange Server 2010 test environment are summarized below. These requirements were calculated using the formula detailed in the Microsoft Exchange 2010 Efficiency, Flexibility, Performance, and Availability at Scale - Enabled by EMC Symmetrix VMAX, Virtual Provisioning, and VMware vSphere White Paper, located at:

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/h7018-exchange-vmax-vp-vsphere-wp.pdf Note: When using thick or thin devices with Exchange the initial spindle requirements for the pools must meet the I/O requirements. Once that has been accomplished the sizing calculations should follow.

Disk requirements calculations based on IOPs

• Number of users * I/O Profile = User IOPs + 20 percent (Logs, BDM etc) = Total user IOPS.

• (Total IOPs *.60 Read) + write penalty 2 R1/0 4 R5 (Total IOPs *.40 Write) = Array IOPs / IOPs per Spindle = Disks required.

• Shown above is the EMC recommended formula for manually calculating disk requirements per server, based on IOPS.

• Additional I/O should be added to the user I/O profile for such things as BlackBerry, ActiveSync and so on, to the I/O Profile.

IOPS calculation example

• 5,000 users * .15 = 750 + 20 percent = 900 IOPS.

• RAID 5 FC: R (900 *.60) + W 4(900 *.40) = 1,980 / 130 = 16 disks.

Note Based on IOPs requirements, 16 spindles are needed.

Disk space calculation

• Microsoft has changed their guidance on this a number of times. At this point, until the EMC Exchange 2010 calculator is ready, EMC recommends the Microsoft calculator be used to compute the required number of disks.

• Current MS Calculations require more than 60 percent capacity over user mailbox target size.

• EMC’s Virtual Provisioning is a key to reducing up-front storage purchase and handling any unforeseen growth.

Capacity Requirements: Start with a 1 GB mailbox (initial requirements). The database sizing information below is an example for this use case. It is recommended that the Microsoft Exchange Server 2010 Mailbox Role Calculator be used to size your production databases from a space perspective. Additional information for the Exchange 2010 Mailbox Server Role Requirements Calculator may be found at:

http://msexchangeteam.com/archive/2009/11/09/453117.aspx

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/h7018-exchange-vmax-vp-vsphere-wp.pdf�


http://msexchangeteam.com/archive/2009/11/09/453117.aspx�




DB Space: 5,000 users * 1 GB = 5,000 GB * 35 percent = 6,750 GB Log space: User profile (150 sent/received messages) with 75k avg message = 30

logs per day 30 * 4 days = 120 * 5,000 = 600 GB

Total space required: 7,350 GB for database and log LUNs

Disk space based on RAID and disk type

600 GB drive on VMAX will provide ~538 GB user capacity and in a 7+1 configuration will yield 3766 GB total user capacity.

The following formula is used for disk calculation based on capacity requirements:

Disks Required = (Database <or logs> capacity requirements) / (Disk Group user capacity) x (Number of disks in a RAID set)

7350 / 3766 * 8 = 16 disks

Sixteen 600 GB 10k rpm drives in two RAID 5 (7+1) DGs = 7,630 GB

Initial Number of Disks Required per Building Block

Based on the above calculations, sixteen 600 GB 10k rpm disks are the best choice to support the 5,000 user building block.

End Database Capacity Requirements 2.5 GB DB

• DB Space: 5,000 users * 2.5 GB = 12,500 GB * 35 percent = 16,875 GB.

• A 2.1 TB thin LUN is required for the database volumes.

• Additional space required: 9,345 GB for database growth.

• Additional disk required per building block: 24 Disks.

• Total initial disk savings, due to the use of Virtual Provisioning: 160 600 GB 10k drives.

Phase 3—Validate the design

For a complete summary of Jetstress and LoadGen findings, see Chapter 5: Performance testing and validation results.




Virtual Provisioning design on the Symmetrix VMAX

Overview The following section provides design details on how VMAX Virtual Provisioning was

used to provide a well-performing, easy–to-use and economical platform for Exchange Server 2010. One of the main advantages of using VMAX Virtual Provisioning for Exchange is the ability to easily and without any server interruptions increase the database volumes storage as your users’ mailboxes grow. This can deliver tremendous savings in disk cost, power, cooling and reduced footprint. It also provides for outstanding storage flexibility for your Exchange environment.

VMAX Virtual Provisioning works with VMware, Hyper-V, and storage technologies such as snaps, clones and SRDF. For more information on VMAX Virtual Provisioning please see the following link:

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/FS_Symm_Virtual_Provisioning.pdf

Virtual Provisioning design considerations

With Virtual Provisioning for Exchange on a VMAX there are three main approaches that can be taken with regards to the thin pool design; they include:

A thin pool for each Exchange Mailbox server:

• Provides for more granular (building block) design, easier troubleshooting & analysis.

One large thin pool for all Exchange database and logs: • Simplest and provides for best utilization of space but may make troubleshooting

and performance analysis more changeling. One thin pool supporting multiple applications: • Not recommended and should only be done when the I/O of all applications is

well understood and will not change. Other recommendations for the design of the disk layout for Exchange Server 2010 with thin pools on VMAX, include: • Use large Data Devices 120 - 240 GB for your thin pools. • Use concatenated Thin Device Metas, since the data devices are already striped

from a disk group perspective. The design used for our testing environment included: • A thin pool per Exchange Mailbox Server. • Each thin pool was supported by a Disk Group containing 16 600 GB 10k drives.

• 240 GB Data Devices were used with RAID 5 (7+1) protection.

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/FS_Symm_Virtual_Provisioning.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwNGZmMzkxLGRhdGFTb3VyY2U9RENUTV9lbl9VU18w�

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/FS_Symm_Virtual_Provisioning.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwNGZmMzkxLGRhdGFTb3VyY2U9RENUTV9lbl9VU18w�




• 16 Devices per Pool, 8 thin devices at 2.1 TB for the Database, 8 thick devices at 120 GB for the Log.

Database thin device details are as follows:

• Used a 2.1 TB DB Thin Device to accommodate the 2.5 GB mailbox requirement.

• 8 DBs per server - 625 users per database.

• 625 * 2.5 GB = 1562 GB * 35 percent = 2.1 TB.

This calculation is performed for spoofing storage requirements to hosts.

The following screenshot shows the thin pools and the thin device detail that is displayed within the Symmetrix Management Console (SMC). It is a quick way to obtain a view of the pool and check the disk space used.

In order to prevent a situation where a thin pool runs out of space, it is recommended that the thin pool utilization threshold tool be used to monitor each pool’s disk space utilization. These settings can be found within the Symmetrix Management Console. The tool can be set to send warnings and alerts when the pools space utilization reaches a certain level. The following screenshot represents a view for the Pool Utilization Threshold tool.




vSphere VM building block

Once the user per building block and disk calculations are complete the virtual machine and ESX requirements can be calculated. The memory and CPU requirements are based on Microsoft best practice for Exchange Server 2010 Mailbox servers. Additional information may be found at:

http://technet.microsoft.com/en-us/library/dd346700.aspx.

CPU and memory requirement calculations start with the Mailbox server role. Based on the requirements a building block must be able to support 5,000 users per server. Additionally, we need to provision sufficient megacycles so that Mailbox server CPU utilization does not exceed 80 percent. Table 6 lists the Mailbox server megacycle and memory requirement calculations.

Table 6 Mailbox CPU requirements Parameter Value

Active megacycles 5,000 mailboxes x 3 megacycles per mailbox = 15000

Passive megacycles 0 (sizing for all active)

Replication megacycles 0 (sizing for all active)

Maximum mailbox access concurrency 100 percent

Total required megacycles during Mailbox server failure

15000

Using megacycle capacity to determine the number of mailbox users that an Exchange Mailbox server can support is not an exact science. There are a number of factors that can result in unexpected megacycle results in test and production

http://technet.microsoft.com/en-us/library/dd346700.aspx�




environments. Therefore, megacycles should only be used to approximate the number of mailbox users that an Exchange Mailbox server can support. Remember that it's always better to be a bit conservative rather than overly aggressive during the capacity planning portion of the design process.

Based on Microsoft guidelines and server vendor specifications we have determined CPU and memory requirements for each VM role. Table 7 provides the summary of the VM CPU and Memory configurations.

Table 7 VM CPU and Memory configurations summary Virtual Machine Role vCPUs per VM Memory per

VM

Mailbox (to support 5000 users during failover) 6 32 GB

For the Mailbox Servers OS a 120 GB VMFS volume was used. Raw Device Mappings (RDM) disks were used for the database and log volumes primarily to accommodate the requirement for a hardware VSS snapshot. Table 8 describes those values.

Table 8 Mailbox VM resources Item Description

Number of users supported

5,000

User profile supported .15 IOPS 150 messages/user/day

Database LUN 8 2.1 TB thin LUNs (RDM)

Log LUN 8 120 GB thick LUNs (RDM)

OS LUN 120 GB (VMFS)

VM CPU 6 vCPUs Xeon X7460 2.66 GHz

VM Memory 32 GB

Table 9 ESX Server configuration Item Description

Max Number of users supported

20,000 Very Heavy (4 Exchange VMs per host)

Server Type Dell PowerEdge R900

Total Memory 128 GB

Total Virtual CPUs 24

Number of HBAs 2 dual-port 4 GB QLogic

Chapter 4: Backup and Restore of Exchange Server 2010 Data with Replication Manager




Overview

Introduction to Replication Manager

EMC Replication Manager relies upon disk-based replicas as the foundation of the recovery operation. Replicas can be used for granular backup and restore of databases and file-systems or for simplifying and automating data refreshes in development testing, quality assurance and reporting cycles.

Specifically Replication Manager provides the following:

• Eliminates scripting and makes replication technologies easy to use through an intuitive point-and-click user interface and configuration wizards.

• Enables fast reaction or recovery of data in the event of corrupt or lost information.

• Saves operations time by automating the mounting, dismounting, scheduling and expiration of replicas.

RM and Exchange Server 2010

How RM works with Exchange Server 2010

Replication Manager leverages the VSS functionality provided by Microsoft that facilitates the creation of application-integrated snapshot backups. Specifically, Replication Manager provides support for Exchange Server 2010 snapshots via Volume Shadow Copy Service (VSS). Replication Manager supports Exchange Server 2010 in standalone or DAG environments.

The Volume Shadow Copy Service, also known as VSS, provides the framework to create point-in-time, transportable backups of Exchange Server 2010 with snapshot backups. There are three components of VSS: a requestor, a writer, and a provider. A VSS requestor is typically a backup application—it requests the shadow copy set. Replication Manager is a VSS requestor. The VSS writer is the application-specific logic needed in the snapshot creation and restore/recovery process. The VSS writer is provided by Exchange Server 2010. The VSS provider is third-party hardware control software that actually creates the shadow copy. EMC has its own provider for VMAX. The Volume Shadow Copy Service coordinates these component functions as shown in the following diagram.




Figure 3 Volume Shadow Copy Service

On the VMAX arrays, Replication Manager can take advantage of both clone and snapshot functionality. When you create a replica using clone functionality, you make an exact copy of the data onto a separate logical unit (LUN) or disk. When you create a snap, the data is stored as a copy on first write to disk-based cache memory. Snaps only store the information from changed tracks, so they use a minimum amount of save device space on the VMAX array.

TimeFinder snaps are virtual point-in-time copies of a LUN. Snaps are comprised of data that resides on the source LUN and on the save devices. The data on the save devices consists of copies of the original source LUN data that have been modified since the snap was taken. When a snap is taken, the production host is still able to write to the source LUN and modify data. When this occurs, the software stores a copy of the original data in the save devices. This operation is referred to as copy on first write and occurs only once for each chunk of data that is modified on the source LUN.

Utilizing Replication Manager Exchange Server 2010 aware technology in the backup and restore design provides the following benefits:

• Improve Recovery Time Objective (RTO) for Exchange Storage Group and database recovery. Recovery from a VSS integrated replica via Replication Manager is faster than a restore from tape or even a restore from a disk based backup.

• Improve Recovery Point Objective (RPO) for Exchange Storage Group and database recovery. Multiple VSS integrated replicas via Replication Manager




can be made during a 24-hour period. For example, creating a replica every 4 hours would minimize data loss to only 4 hours (time between replicas) in the event a full database and log volume restore was required. A partial restore of only the database volume would allow the Exchange transaction logs to replay and bring the database back up with no data loss.

• To help meet backup to tape windows, VSS integrated replicas can be mounted to a backup server directly via Replication Manager. This eases the complexity of meeting backup windows for large Exchange databases across the LAN or SAN.

In most environments with large mailboxes, Exchange Server 2010 is capacity driven. So taking snaps of the passive copy will provide huge space savings advantages as opposed to using full clone copies.

RM leverages Microsoft VSS to provide point-in-time recovery and roll-forward recovery via Copy and Full backup mode for Exchange Server 2010. Both modes back up the databases and transaction logs, but only Full mode truncates the logs after successful backup. Since these snapshots are transportable, they can also be used for repurposing. For instance, if your server is attached to a storage area network (SAN), backup to tape can be offloaded to the snaps thus alleviating the performance impact on the active production copy.

Replication Manager design

RM functionality Overview with Exchange Server 2010

Replication Manager is a robust enterprise-level application that can be used to perform a number of functions and provide great benefits in conjunction with TimeFinder local replication technology and Microsoft Exchange Server 2010. RM can be used with Exchange Server 2010 and TimeFinder snaps to:

• Create Exchange database application sets.

• Create online full and copy replicas of Exchange databases and logs using Microsoft Volume Shadow Copy Services (VSS).

• Create replicas of Exchange databases protected as part of a Database Availability Group (DAG), whether it is an active or passive copy of the database.

• Check the consistency of replicated data.

• Provide on-demand mount and dismount.

• Perform point-in-time or roll-forward restores to the production databases in the event of a corruption.

Design considerations and recommendations for best performance

Outlined below are some best practice considerations when designing a Replication Manager environment for Exchange Server 2010: • In a DAG environment, it is recommended to take snaps of the passive copy

to lessen any potential performance impact when snapping the active copy. • It is good practice to separate the database and logs onto different LUNs to

take advantage of RM’s ability to provide roll-forward recovery that result in




no data loss. • It is recommended to not exceed four databases (eight LUNs) per RM

application set. Beyond that, the possibility of VSS timeouts and checksum timeouts increase, which can result in job failures.

• If possible, use a physical mount host as opposed to a virtual machine with physical RDMs as this will reduce the time it takes to mount the volumes.

• In Exchange Server 2010, it is not required anymore to run consistency checks on the mounted snap copy. It is, however, suggested to do this once a week.

• Use separate dedicated spindles for the save pool for better performance. • Zone the RM mount hosts’ HBAs to different array ports than the Production

Exchange server’s HBAs for performance reasons. • Use EMC PowerPath on the mount host for optimal multipathing and load

balancing, particularly when running consistency checks.

Replication Manager Design layout

Description of the application design layout

The following components outline the environment that will be part of the Replication Manager design:

• VMAX running 5874 microcode.

• TimeFinder snaps off database passive copies for local protection.

• Exchange Server 2010 with DAG.

• There are four passive copies and eight total LUNs being snapped per Mailbox VM.

• Two ESX servers each hosting four VM Mailbox servers.

• Single stand-alone server to run Replication Manager server software, which also acts as the mount host. A general rule of thumb is to have one mount host for every three Exchange servers.

Note This is a guideline and will vary based on customer requirements.




Figure 4 Replication Manager design layout The following are the high-level steps performed by Replication Manager when taking a snap of the Exchange Server 2010 databases: 1) The RM jobs are configured to first check the event logs for events that are

reporting any database corruption issues, verify if circular logging is disabled, and map the Exchange databases to the backend storage volumes.

2) The RM job will then take a TimeFinder snap copy of the databases defined in the application set. This copy is an application-consistent VSS copy of the source databases. The snaps will be taken from the passive DAG copy.

3) Once the snap is taken, Replication Manager will mount the replica (snapshot volumes) into a specified directory on the RM/Mount server.

4) Once successfully mounted, RM can initiate a checksum process against the mounted volumes to ensure consistency. If this process is successful RM will truncate the Exchange logs. If it is not successful the RM job will fail and current transaction logs will not be truncated until the next scheduled backup.

5) After the process has completed, the snap volumes will remain mounted on the mount server until the next replica rotation. This will allow adequate time for the data to be archived to tape.




6) The jobs were scheduled to run four times a day, every day to provide a RPO of 6 hours.

Replication Manager disk backup layout

Database Replication Technology Schedule Application

Set Job Storage Pool Mount host

DB1-DB4 TimeFinder Snap 6:00 DB1-DB4 DB1-DB4 DB1-DB4 R900DMX_05








Figure 5 Replication Manager design

Figure 5 highlights the Replication Manager design for this solution. A total of eight jobs were created. They were scheduled to run 30 minutes apart.

There were several considerations taken into account to design the Replication Manager backup environment:

• Four databases were included in every application set. Since the databases all reside on separate RDM LUNs, the layout allows performing a restore of a single database as well as roll-forward restores if needed. Placing four databases per application set also helps reduce the number of RM jobs that essentially results in simplified management.

• Each RM job is directly associated with an application set and hence configured to take a snap of four databases. The job is configured to take snaps from the passive DAG copy. This design approach was adopted to reduce any potential performance impact on the active database copy.

• The local replication technology used for this solution is TimeFinder snaps. Microsoft recommends hosting multiple full copies of Exchange databases on separate servers to provide local recoverability capability. But in most environments with large mailboxes, Exchange Server 2010 is capacity driven more so than performance. For this reason, using snaps will provide huge space savings. TimeFinder snaps are pointer-based copies of the source LUN that store just the changed tracks; hence they use minimum space on the VMAX array. And by taking snaps of the passive DAG we are minimizing any potential performance impact on the production Exchange databases. Finally, Replication Manager integrates well with the TimeFinder/Snap technology and provides for instant restore capabilities – both point-in-time




and roll-forward.

• The jobs were scheduled using Replication Manager to minimize administrative tasks and automate the solution. The snap jobs were scheduled to run four times a day. This lowered the RPO for recovery to 6 hours. This worked well in both roll-forward and point-in-time restores. Since the databases and logs were located on separate LUNs, it also provided for a roll-forward restore capability and no data loss solution when the logs were intact.

Rapid Restore using Replication Manager

Restoring Exchange databases in a DAG environment

The most likely recovery scenario involves a single database .edb becoming corrupt and a recovery needing to be performed. This situation would involve a single database being recovered through RM from the latest, successful VSS snapshot. It took about 3 minutes and 30 seconds to execute this recovery, where RM executed the roll-forward database only recovery and brought the database online. It is also possible to execute a point-in-time recovery where RM will restore both the database and log LUNs to the time when the snapshot was taken. The time taken for this is roughly the same but will require reseeding since the logs have been over-written too.

In an Exchange Server 2010 DAG environment, replicas can be restored only to the same server on which the replica was originally created. Microsoft restricts restores of database copies to the active copy only. To perform a single database roll-forward (database only) recovery, using Replication Manager, the following quick and simple process is taken.

(Note: This procedure is dependent on the customer’s specific configuration. High-level steps are provided here as a reference point.)

1. Right-click on replica that you want to restore back to source and click Next.




2. Choose just the database files from the list of objects.




3. If the server is not hosting the active copy of the database, then choose the Activate databases before restore checkbox in the Restore Options screen of the Restore Wizard and click Finish. Once this is checked, RM will automatically move the active copy to the server.

Before activating the database, Replication Manager verifies that the passive copy of the database is healthy and the CopyQueueLength is zero. If the passive copy is not healthy or the queue length is greater than zero, the restore fails.




4. Once the restore is completed, go the Exchange Management console, and resume the database copy.

5. Then move the Active copy back to the original server.

Chapter 5: Performance Testing and Validation Results




Overview

Introduction The following section describes the approach and methodology used to validate this

solution. To ensure that the design and guidance presented in this document delivers good performance, end-to-end validation testing was done on the entire infrastructure. The performance testing was conducted in three sections:

• 24-hour end-to-end performance validation testing of the entire solution using LoadGen.

• Replication Manager backup and restore performance results.

• TimeFinder Snap performance and impact with Exchange Server 2010.




Methodology and tools

Overview The solution involved a combination of a number of components. Each component

needs to perform well for the solution to be deemed successful. There were two main focuses for the testing validation: overall 24-hour life cycle testing of Exchange and the backup and restore of Exchange Server 2010. Each space test was run twice to ensure that the results were consistent.

An additional 48-hour LoadGen testing was run to help with the sizing of the TimeFinder snapshot space.

Data collection points

To validate the complete health of the solution and identify any bottlenecks, results were collected and analyzed from a number of places. The performance results will be broken down into the following four areas:

• VMware, ESX and Mailbox VM performance.

• Exchange Server & Exchange Client performance.

• Storage and SAN performance.

• Replication Manager backup and restore performance.

Microsoft JetStress 2010

The Microsoft JetStress tool verifies the performance and stability of a disk subsystem prior to putting an Exchange 2010 server into production. JetStress helps verify disk performance by simulating Exchange disk IO load. Specifically JetStress simulates the Exchange database and log file loads produced by the specified number of users. For more information on JetStress visit

http://msexchangeteam.com/archive/2009/09/01/452271.aspx

The storage layout for this solution is identical to another proven solution for Exchange 2010 with VMAX, Virtual Provisioning and vSphere. The JetStress storage performance results may be obtained in the “Disk layout validation testing with JetStress” section in the white paper for that solution. The paper is located at:

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/h7018-exchange-vmax-vp-vsphere-wp.pdf

LoadGen Exchange Load Generator (LoadGen) is used for a full end-to-end assessment of the

Exchange Server 2010 environment. You can use LoadGen to perform pre-deployment validation and stress testing tasks that introduce various workload types into a test (non-production) Exchange messaging system. This test simulates the delivery of multiple MAPI, Outlook Web access, IMAP, POP, and SMTP client messaging requests to an Exchange server.

http://msexchangeteam.com/archive/2009/09/01/452271.aspx�






Important!

LoadGen should only be used in a test lab configuration and in non-production Exchange environments. For more information on LoadGen go to the following website:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cf464be7-7e52-48cd-b852-ccfc915b29ef

Database seeding performance

Overview Database mobility is a new architecture in Microsoft Exchange Server 2010 that

removes the concept of storage groups and uncouples an Exchange Server 2010 Mailbox database from a Mailbox server. Because Microsoft removed storage groups from Exchange Server 2010, continuous replication now operates at the database level. In Exchange Server 2010, transaction logs are replicated to one or more Mailbox servers and replayed into one or more copies of a mailbox database stored on those servers.

For a variety of reasons, such as performing planned maintenance, it may be necessary to suspend and resume continuous replication activity for a database copy. In addition, some administrative tasks, such as seeding, require that you suspend a database copy first. Microsoft recommends that you suspend all replication when you change the path for the database or its log files. You can suspend and resume database copy activity by using the Exchange Management Console, or by running the Suspend-DatabaseCopy and Resume-DatabaseCopy cmdlets in the Shell.

For detailed steps that explain how to suspend or resume continuous replication activity for a database copy, visit Microsoft’s TechNet Website at: Suspend or Resume a Mailbox Database Copy.

Note: Log truncation does not occur on the active mailbox database copy when one or more passive copies are suspended. If your planned maintenance activities are going to take an extended period of time (for example, several days), you may have considerable log file buildup. That is why it is critical to size your log LUNs to accommodate for these activities. To prevent the log drive from filling up with transaction logs, you can remove the affected passive database copy instead of suspending it. When the planned maintenance is completed, you can re-add the passive database copy.

Database seeding considerations

While the database is being seeded, the backup cannot occur. Careful planning is required to seed all databases in the entire environment.

In this solution, 64 database copies are configured; of which 32 are active and 32 are passive, across a single DAG.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cf464be7-7e52-48cd-b852-ccfc915b29ef�

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cf464be7-7e52-48cd-b852-ccfc915b29ef�






Performing a seed operation

When performing a seed operation, you can choose to seed the mailbox database copy, the content index catalog for the mailbox database copy, or both. The default behavior of the Update Database Copy wizard and the Update-MailboxDatabaseCopy cmdlet is to seed both the mailbox database copy and the content index catalog copy. To seed just the mailbox database copy without seeding the content index catalog, use the DatabaseOnly parameter when running the Update-MailboxDatabaseCopy cmdlet. To seed just the content index catalog copy, use the CatalogOnly parameter when running the Update-MailboxDatabaseCopy cmdlet.

Seeding performance

Table 10 provides database seeding performance information from our test environment. These results are based on the test environment configuration and can be different in the customer’s environment. In our tests, the seeding was performed over a 1 Gb/s network with no latency. Each source database was approximately 575 GB and the content index was about 250 GB. The total single replication source size (DB + Index) was approximately 825 GB.

Note: In production environments, the content index is usually about 20 percent of the database size. It is 40-45 percent of the index size in our test environment due to the dynamic content generation feature in LoadGen.

Table 10 Seeding performance information What is seeded? Size Average

seeding time Throughput (GB/min)

Single database (DB+index) 825 GB 6 hours 15 minutes

2.2 GB/min

Environment validation with LoadGen

Overview The LoadGen tool was used to simulate MAPI workload against the entire Exchange

infrastructure. LoadGen testing is necessary to determine how each Exchange component performs under a real, close-to-production user load.

LoadGen requires full deployment of the Exchange environment for validation testing. You should perform all LoadGen validation testing in an isolated lab environment where there is no connectivity to production data. LoadGen generates users and the workloads against the entire Exchange environment including Exchange Server VM, network and storage components.

LoadGen simulates the entire mail flow, helping to determine any bottlenecks in the solution. It is the only tool that helps you determine the CPU and memory resources that are necessary to sustain the load for which the Exchange environment was designed.

In our tests, Exchange Server Load Generator 2010 (LoadGen) is used to simulate Outlook 2007 online mode mailboxes with the following characteristics:








• The Outlook 2007 profile with 150 messages produced 178 Outlook tasks per user, per day, and was used for all 20,000 users.

• Each mailbox is 1,000 MB in size.

• Four LoadGen Client machines were used in the testing. Each producing load for 5,000 very heavy users.

LoadGen was run in 24-hour and 48-hour increments to simulate a normal work day’s operation and change; the simulated workday duration is set to 9 hours.

During testing the following user load was produced in a 24-hour period:

• The Outlook 2007 150 message profile generated a total of 9.5 million tasks per day across all 8 servers.

• The load produced an average of 12.5 GB of logs per DB during 24 hours.

• 20 logs a day were produced per user, which is a good measure to compare to customer environments.

Test 1 – 24-hour end-to-end validation testing

Test 1 objectives

The objective of this test was to validate the entire solution under normal operating condition for a normal work day. All aspects of the solution were evaluated including the ESX server and VMs’ performance, Exchange server and client experience, as well as the VMAX array.

Test 1 configuration

In this test, all Exchange databases and VMs were placed under normal operating condition, four active and four passive copies per Exchange VM. Replication Manager was set to take a single backup per day of the passive copies. The LoadGen tool was configured to simulate a 24-hour very heavy load with a 9 hour work day.




Test 1 performance results and analysis

ESX & VM performance results

Two of the primary performance counters, ESX and VM CPU utilization, were analyzed. Figure 6 and Figure 7 represent the CPU utilization on the two ESX Servers and four Mailbox VMs during the daytime hours of the 24-hour test.

During this test, LoadGen ran at a very heavy load for the first 9 hours. As can be seen from the ESX Performance tab:

• The mailbox VMs for building block 1 averaged around 50 percent CPU utilization with spikes up to 75 percent.

• Both ESX Servers were very similar, averaging approximately 48 percent CPU utilization with spikes to 63 percent.

• Overall the VMware virtual environment performed well under the load and had some additional headroom to handle spikes.

Figure 6 ESX 1 and its VMs’ performance for Test 1




Figure 7 ESX 2 and its VMs’ performance for Test 1

Exchange Client results

Mailbox server response times for client requests are tracked to determine the amount of time it takes the Mailbox server to respond to a client request and gauge the overall client experience. The response time average per request should not exceed 10 milliseconds. Use the following performance monitor counter on the Mailbox server to monitor response time:

MSExchangeIS/RPC Averaged Latency

Use the following performance monitor counters on the Mailbox server to monitor the message sent and delivered rates:

• MSExchangeIS Mailbox (_Total)/Messages Sent/sec.

• MSExchangeIS Mailbox (_Total)/Messages Delivered/sec.

The validity of each test run, from an Exchange client perspective, is determined by comparing the results of select performance counters to Microsoft-specified criteria. Performance counter data is collected at 10-second intervals for the duration of each test run. The results of the first and last hours are discarded. Results are averaged over the remaining duration of test duration.




Table 11 lists the primary counters and their validation criteria:

Table 11 Primary counters and validation criteria

From an Exchange client perspective all performance counters were well below the target and indicate a healthy client experience.

For additional information about monitoring Exchange Server 2010 performance and other key performance counters, visit “Performance and Scalability Counters and Thresholds" on Microsoft’s TechNet site at http://technet.microsoft.com/en-us/library/dd335215.aspx.

Storage and performance

From a storage perspective the array and thin pools performed well. During the 9-hour day the disk pools reached 75 percent maximum utilization and averaged approximately 60 percent. It should be noted that when testing Jetstress against the same configuration with the same user profile the disk utilization averaged around 80 percent.

Figure 8 shows a well-performing VMAX. You can see during the 9-hour day the utilization increases and during the off-hours the utilization decreases.






Figure 8 VMAX utilization during 24-hour test run

Another useful view of the array is the disk heat map for the 24-hour test. It shows that while a number of the disks were reaching 70-80 percent utilization overall the Exchange layout with snaps performed well.




Performance results summary for Replication Manager

During the 24-hour LoadGen testing TimeFinder snaps were active against all the passive database and log volumes. A total of 64 snaps were active. Two hours into the 24-hour testing the Replication Manager jobs started to run. There were six jobs, each contained four databases, and ran in 30-minute increments.

RM job performance

It is important to understand the impact and length of each Exchange backup job. This information can be very helpful in designing your RM job schedule. Table 12 illustrates the timings for each part of the RM jobs replicating four sets of databases and logs. As can be seen, the most time-consuming part is the consistency check on all four databases, when fully populated. In most environments, it is acceptable to run consistency checks once per week. The mount host here is a physical machine, which can help improve mounts timings. Table 12 provides the summary of the RM job timings.

The tested RM job setup:

• Each RM job contained 2.532 TB of Exchange data.

• Consistency checks were performed on the snaps of the passive copies during peak day hours conditions.

Table 12 Replication Manager job timings

With Exchange 2010, although it is not required to execute a consistency check after every run, it is good practice to run one at least once a week. Table 13 illustrates the consistency check timings on the mounted snap copies when under heavy load and no load. As noticed below, the timings are almost the same in both cases. This is because the database is completely populated in both cases and hence it takes pretty much the same time to run the check.

Table 13 Replication Manager Consistency Check timings




Snap space sizing

An important sizing question is how much snap space is required to protect the Exchange data. If there is too little snap space you could end up losing the snapshot copy. If there is too much snap space you could be wasting storage. As part of testing, snap space requirements on the VMAX were measured over a period of 24 and 48 hours when LoadGen was running to help with sizing. Table 14 shows the snap space usage of a single snapshot over 6-hour increments when LoadGen was running. The total snap space for a single set of database and log LUNs was a little more than 2 percent a day based on our testing results. The numbers shown in Table 14 will only act as a rough guideline to size the save pool for snaps with Exchange. It is recommended to size the pool based on actual change rates.

The results noted in the VMAX Snap Usage with Exchange Server 2010 table are based on:

• Snaps against 24 passive copies.

• Percent based on a fully provisioned DB/Log set of 2.2 TB.

• Total space being snapped is 52.8 TB.

Table 14 VMAX Snap Usage with Exchange Server 2010

Additional testing

Additional DAG testing was performed in order to provide data around different saturations that could occur the tests include:

• Test 1 - (normal operations) Very Heavy LoadGen load against 20,000 users all DAGs in place and snap off passive copy.

• Test 2 - (Mailbox server down) Very Heavy LoadGen load against 20,000 users MBX18 with all DAGs active; data is just for one server.

• Test 3 - (consistency check on passive) Very Heavy LoadGen load against 20,000 users. One server has consistency check run against the passive copy. The results are measured for 24 hours during consistency check.




Table 15 Additional scenario testing results

Chapter 6: Conclusion



Chapter 6: Conclusion

Overview The virtualized Exchange 2010 building block approach adopted in this solution

allows scaling the messaging environment in a cost-effective and flexible manner by combining EMC's Virtual Provisioning technology for storage, EMC Replication Manager for backup and recovery, and VMware vSphere 4 for server infrastructure. Leveraging these proven technologies provides for the following benefits:

• Users can achieve a 4:1 server consolidation ratio by incorporating VMware vSphere as the server virtualization platform.

• The Symmetrix VMAX Virtual Provisioning technology is true Virtual Provisioning for Exchange Server 2010. Unlike DAS Virtual Provisioning, which involves building new servers, provisioning new storage, and performing mailbox moves to the new servers, EMC Virtual Provisioning eliminates this operational overhead and allows the database volumes to grow seamlessly.

• With EMC Virtual Provisioning, customers purchase only the storage required for the initial mailbox size. As user mailboxes grow, more storage can be seamlessly added with no effect on the users or Exchange server performance. The only additional cost is the purchase of additional disk space.

• With EMC Replication Manager, users can gain a very small backup window regardless of the database size with little to no impact on the production Exchange Mailbox servers. A small percentage of the production space is required for the snap space compared to clones. During testing, with a heavy Exchange Server 2010 load, as little as 2 percent of production storage was required to protect the databases for a 24-hour period.

• The automated and rapid recovery capabilities that Replication Manager and Symmetrix snapshots provide are unmatched. A typical database restore and recovery takes only 6 minutes regardless of the size of the mailbox.

emc virtual infrastructure for microsoft exchange 2010 of contents emc virtual infrastructure for...

Documents