ADVANCED PROTECTION FOR MICROSOFT EXCHANGE 2010 ON EMC VNX STORAGE

Transcription

1 White paper ADVANCED PROTECTION FOR MICROSOFT EXCHANGE 2010 ON EMC VNX STORAGE EMC VNX and EMC AppSync Complement your protection strategy using VNX Snapshots as a first line of defense for critical Exchange environments Easily create up to 256 application consistent snapshots of Exchange with no upfront setup required Let application owners protect and restore their own data using AppSync service plans EMC Solutions Group Abstract This white paper demonstrates the improvements that EMC VNX release OE 5.32 for Block provides for Microsoft Exchange 2010 customers. It describes the performance as well as the enhanced protection provided by new VNX Snapshots and discusses the best practices for using VNX Snapshots for Exchange 2010 managed by EMC AppSync v1.0. October 2012

2 Copyright 2012 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. 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 H

3 Table of contents Table of contents 1 Introduction... 6 Executive summary... 6 Business Case... 6 Solution overview... 6 Document assumptions... 6 Audience... 7 Terminology... 7 Technology overview... 9 VNX Snapshots... 9 FAST Cache AppSync VMware vsphere EMC PowerPath/VE EMC Virtual Storage Integrator plug-in for vsphere Solution Architecture and Design Architecture overview Solution hardware and software components Overview Hardware Software Test environment Overview Simulated Exchange profile Exchange storage design Overview Building block design approach Mailbox server virtual machine building block details About VNX storage pools VNX storage pools deployment options VNX storage pool design for this solution Best practices for managing storage pools vsphere server design Exchange protection

4 Table of contents 3 AppSync and VNX Snapshots with Exchange AppSync overview AppSync deployment options Overview AppSync server AppSync host plug-in AppSync user interface AppSync service plans Additional AppSync features and configuration details AppSync interaction with VSS Exchange DAG configuration guidelines Exchange Database and log layout considerations AppSync Service plan advanced properties Exchange event log errors Exchange backup type Exchange database Validation Options Automatic expiration of VNX Snapshot copies Manual Copy Expiration Wizard Controlling VNX LUN utilization Using Exchange Restore options with AppSync Roll-forward restore Item level restore Restoring individual mailboxes and mailbox items Sizing guidelines for storage pools when using VNX Snapshots VNX Snapshots basics Thick LUN considerations VNX Snapshots desgn recommendations Solution validation and Test results Solution validation objectives Exchange performance validation tools Exchange Jetstress Exchange LoadGen Exchange performance on VNX storage with VNX Snapshots VNX storage pool space usage with VNX Snapshots under Exchange workload Overview VNX snapshots space usage during testing AppSync Performance

5 Table of contents Backup Test Exchange restore test Mount/unmount test Conclusion Findings References White papers Product documentation

6 Chapter 1: Introduction 1 Introduction Executive summary This chapter introduces the Advanced Protection for Microsoft Exchange 2010 on EMC VNX Storage solution and contains the following sections: Executive summary Document assumptions Audience Terminology Technology overview Business case Every day, our customers data centers are being transformed from physical, static computing assets to cloud-based virtualized, dynamic pools of resources. The pressure to eliminate backup windows and reduce recovery times is stronger than ever before. With dynamic, policy-based protection management, these dynamic environments can easily exceed demanding recovery objectives using advanced technologies such as snapshots and continuous protection technology. At the same time, EMC customers continuously look for ways to save storage costs and improve protection for Microsoft Exchange 2010, while providing larger mailboxes and more flexible, space efficient, snap based replication for their clients. Solution overview This solution presents a design approach to easily deploy and protect Exchange 2010 on EMC VNX storage with VNX Snapshots. It also provides design guidance and best practices for sizing storage pools when VNX Snapshots are used for Exchange protection. In this solution, we also describe how EMC AppSync technology automates the management of VNX Snapshots and simplifies Exchange protection. Document assumptions As part of an effort to improve and enhance the performance and capabilities of its product line, EMC regularly releases revisions of its hardware and software. Therefore, some functions described in this guide might not be supported by all revisions of the software or hardware currently in use. For the most up-to-date information on product features, refer to your product release notes. If a product does not function as described in this document, contact your EMC representative. Note This document was accurate as of the time of publication. However, as information is added, we may release new versions of this document to the 6

7 Chapter 1: Introduction EMC Online Support website. Check the website to ensure that you are using the latest version of this document. Audience This document is for EMC customers, partners, and employees who are installing and/or configuring VNX unified systems. We assume that you are familiar with EMC unified storage systems. Terminology Table 1 defines several terms used in this document. Table 1. Terminology used in this white paper Term Allocated capacity Available capacity Background Database Maintenance (BDM) Building-block Database Availability Group (DAG) Definition For a VNX storage pool, this is the space currently used by all Logical Unit Number (LUNs) in the pool. For a thin LUN, this is the physical space used by the LUN. For a thick LUN, this is the host-visible capacity used by the LUN. Allocated capacity is slightly larger than the capacity used by the host because metadata exists at the pool LUN level. The amount of actual physical pool space that is currently not allocated for pool LUNs. You can expand the available user capacity by adding drives to the pool. The process of the Exchange 2010 database maintenance that involves check summing both active and passive database copies. A design method that represents the required amount of disk and server resources required to support a specified number of Microsoft Exchange 2010 users. The amount of required resources is derived from: A specific user profile type Disk requirements Server CPU and memory requirements An Exchange 2010 base component that provides high availability (HA) and site resilience. A DAG can contain up to 16 Mailbox servers. The servers host a set of databases that provide automatic database-level recovery from failures affecting individual databases. Any server in a DAG can host a copy of a mailbox database from any other server in the DAG. FAST Cache A performance optimization feature unique to EMC CLARiiON CX4, Celerra NS, and VNX unified storage platforms. FAST Cache uses Flash drives to extend existing cache capacities for accelerated system performance and automatic absorption of unpredicted spikes in application workloads. 7

8 Chapter 1: Introduction Term Oversubscribed capacity Service-level agreement (SLA) Slice Storage Pool Storage pool (heterogeneous) Storage pool (homogeneous) Subscribed capacity Thick LUN Thin LUN Traditional LUN Definition The amount of user capacity configured for VNX storage pool LUNs that exceeds the physical capacity in a pool. Oversubscribing capacity is supported via thin LUNs. Policies defined by data center administrators that set the levels of availability, serviceability, performance, and operation in an organization s environment. A 1 GB unit of capacity, which represents the minimum amount you can physically allocate to a pool LUN. Pool LUNs are composed of slices. A group of disk drives for configuring pool LUNs (thick and thin). There may be zero or more pools in a storage system. Disks can only be a member of one pool, and they cannot be in a separate user-defined RAID group. A storage pool that uses multiple drive types (for example, a mix of SAS and NL-SAS in one pool). A storage pool that uses the same drive types (for example, all NL-SAS). The total amount of capacity configured for LUNs in the storage pool. This number can be greater than the available user capacity. You can expand the available user capacity by adding drives to the pool. A type of pool LUN in which the physical space allocated is equal to the user capacity seen by the host server A type of pool LUN where physical space allocated can be less than the user capacity seen by the host server Also known as FLARE LUNs. A logical unit of storage created on a user-defined RAID group. The amount of physical space allocated is the same as the user capacity seen by the host server. Traditional LUNs cannot be created in pools; you must always create them on a RAID group. 8

9 Chapter 1: Introduction Technology overview VNX Snapshots VNX Snapshots is a new VNX software feature introduced in EMC VNX operating environment for Block Release 5.32 (OE 5.32). This feature creates point-in-time data copies that customers can use for data backups, software development and testing, repurposing, data validation, and local rapid restores. Depending on your application needs, you can create VNX Snapshots and snapshots of VNX Snapshots. VNX Snapshots do not replace the existing SnapView technology. In fact, both features can coexist. In addition, SnapView clones can have their own VNX Snapshots. Unlike SnapView snapshots and clones, VNX Snapshots do not consume large amounts of pool capacity. As a result, this feature is preferred for modern data management. VNX Snapshots technology writes new data to a new area within a storage pool without the need to read and write the old data block. This improves the overall performance compared to SnapView Snapshots technology. VNX Snapshots uses redirect on write (ROW) technology. With ROW, the source LUN of a snapshot created by VNX Snapshots does not need to copy source LUN data to the reserved LUN pool to preserve the snapshot. Instead, new incoming writes to the source LUN are written to a location in the storage pool that is different from the location to which the original data is written, and index updates track the data changes. VNX Operating Environment (OE) 5.32 for Block also introduces the concept of consistency groups. You can combine several pool LUNs into a consistency group and snap them concurrently. When AppSync is used to protect Exchange, there is no need to create consistency groups as AppSync simplifies this process automatically when running a service plan. New VNX Snapshots now support 256 writable snaps per LUN and up to 32,000 per system (depending on the VNX system size). Snapshots of snapshots make VNX Snapshots ideal for testing, development, and disk backups. When used with AppSync, these snapshots are application consistent and can be used to quickly and efficiently provision copies of production data for application development and testing. You can create a snapshot from: Primary LUNs Consistency group(s) Snapshot mount points (if attached to a snapshot) Snapshots (through the Copy Snapshot operation) Some of the most important uses of VNX Snapshots include: Backing up point-in-time copies of your system to a backup server Verifying data integrity before restoring data by mounting snapshots Restoring data from a local snapshot 9

10 Chapter 1: Introduction Using a copy of the LUN for testing and development Deploying multiple copies of a single source for use in environments such as virtual environments and workstation deployments More information about VNX Snapshot is provided in the section entitled Sizing guidelines for storage pools when using VNX Snapshots on page 32. You can also review the VNX Snapshots white paper at FAST Cache FAST Cache is a performance optimization feature that is unique to EMC VNX family platforms. FAST Cache uses Flash drives to extend existing array cache capacities for accelerated system performance, and to absorb unpredicted spikes in application workloads automatically. FAST Cache: Supports up to 2 TB of usable capacity (4 TB raw) maximum capacities vary for each system model Supports read and write operations Provides simple configuration and monitoring through the VNX Unisphere management interface Is supported on CLARiiON CX4, Celerra NS, and VNX platforms (file and block) Accelerates performance to address unexpected spikes in application workloads Can be considered for use with Exchange 2010 in high I/O user profile environments where I/O, rather than space, is the determining factor for storage requirements Should be enabled on storage pools housing Exchange databases when VNX Snapshots are used to protect Exchange. EMC AppSync EMC AppSync offers a simple, self-service SLA-driven approach, for protecting virtualized Microsoft applications in VNX deployments. EMC designed AppSync to protect dynamic and constantly moving virtualized applications. AppSync follows the applications and stays in-sync with them during VMotion actions and failovers across physical and virtual boundaries. It has constant communications with applications about where the data resides. AppSync comes with pre-defined policies to meet common objectives set for tiered standards or classifications. AppSync also offers considerable flexibility. You can modify or create your own protection policies. Application administrators can also create custom service plans to protect production data and recover data quickly with item-level granularity. For example, for the highest level of protection (zero data loss), you can assign a gold protection plan that includes synchronous replication with EMC RecoverPoint SE. If the application has a 24-hour recovery time objective, you can assign a bronze plan to meet that SLA objective that applies the VNX Snapshot technology. AppSync also provides an 10

11 Chapter 1: Introduction application protection monitoring service that generates alerts when the SLAs are not met. VMware vsphere EMC PowerPath/VE VMware vsphere uses the power of virtualization to transform data centers into simplified cloud computing infrastructures and enables IT organizations to deliver flexible and reliable IT services. vsphere virtualizes and aggregates the underlying physical hardware resources across multiple systems and provides pools of virtual resources to the data center. As a cloud operating system, vsphere manages large collections of infrastructure (such as CPUs, storage, and networking) as a seamless and dynamic operating environment and manages the complexity of a data center. EMC PowerPath/VE provides intelligent, high-performance path management with path failover and load balancing optimized for EMC and selected third-party storage systems. PowerPath/VE supports multiple paths between a vsphere host and an external storage device. With multiple paths, the vsphere host can access a storage device, even if a specific path is unavailable. Multiple paths can also share the I/O traffic to a storage device. PowerPath/VE is particularly beneficial in highly available environments because it can prevent operational interruptions and downtime. The PowerPath/VE path failover capability avoids host failure by maintaining uninterrupted application support on the host in the event of a path failure (if another path is available). PowerPath/VE works with VMware ESX/ ESXi as a multipath plug-in (MPP) that provides path management to hosts. It is installed as a kernel module on the vsphere host. It plugs into the vsphere I/O stack framework to bring the advanced multipathing capabilities of PowerPath/VE, including dynamic load balancing and automatic failover, to the vsphere hosts. For this solution, we installed PowerPath/VE on all ESXi hosts. EMC Virtual Storage Integrator plug-in for vsphere EMC Virtual Storage Integrator (VSI ) for VMware vsphere is a free plug-in for VMware vsphere Client that provides a single management interface for managing EMC storage within the vsphere environment. You can add or remove features from VSI independently, which provides flexibility for customizing VSI user environments. You manage VSI features by using the VSI Feature Manager. VSI provides a unified user experience, allowing you to update each of the features independently and introduce new features rapidly in response to changing requirements. Examples of features available for VSI include VFCache, Storage Viewer, Path Management, Storage Pool Management, Symmetrix storage replication adapter utilities, and Unified Storage Management. 11

12 Chapter 2: Solution Architecture and Design 2 Solution Architecture and Design Architecture overview This chapter describes the solution s architecture as well as its hardware and software components, and includes the following sections: Architecture overview Solution hardware and software components Test environment Exchange storage design To validate Exchange 2010 performance on the VNX OE 5.32 for Bock, we used a common Exchange user profile and deployed the environment on the VMware vsphere virtualization platform. We used the EMC Proven building-block design methodology for sizing and deployment of Exchange 2010 on EMC storage in conjunction with EMC, Microsoft, and VMware best practices and guidance to deploy Exchange 2010 in virtual environments. Figure 1 depicts a high-level configuration of the deployed and validated Exchange 2010 solution on EMC VNX storage and VMware vsphere, using AppSync to protect Exchange with VNX Snapshots. Figure 1. Solution diagram Virtualized Exchange 2010 solution design with AppSync and VNX Snapshots 12

13 Chapter 2: Solution Architecture and Design Solution hardware and software components Overview Hardware The information below provides a summary of the hardware and software components used for this solution. Table 2 lists the hardware components used in the test environment. Table 2. Hardware components Item Storage platform Storage connectivity to host Storage system cache Number of storage ports used Maximum bandwidth of storage connectivity to host Fabric switch Physical hypervisor hosts Host bus adapter (HBA) type Total number of disks for Exchange database and logs used in this solution Maximum number of disks that can be hosted on the VNX5700 storage system Description EMC VNX5700 block Fiber Channel 36 GB 4 (2 per storage controller) 16 Gbps (2 x 8 Gbps) 8 Gbps FC switching module 2 Quad eight-core Intel Xeon x GHz CPU, 192 GB RAM (Hyper threading enabled) 1 Dual-port 8 Gb FC HBA per ESXi host TB NL-SAS (7.2k rpm) 500 Software Table 3 lists software components used in the test environment. Table 3. Software components Item Description VNX5700 operating environment VNX5700 OE for block release Multipathing software PowerPath/VE 5.7 for VMware vsphere Hypervisor operating system VMware vsphere 5.0 Virtual machines operating system Windows Server 2008 R2 Enterprise SP1 Exchange Server Exchange Server 2010 Enterprise SP2 Version 14.2 (Build 247.5) 13

14 Chapter 2: Solution Architecture and Design Item Exchange performance validation tools Replication automation and recovery software Description Exchange Jetstress 2010 (64 bit), version Exchange Load Generator 2010 (64 bit) version EMC AppSync v.1.0 Test environment Overview Simulated Exchange profile The following sections present the configuration details of this solution s test environment. Table 4 details the simulated Exchange 2010 customer workload profile used in the test environment. Table 4. Simulated Exchange 2010 profile Item Number of Exchange 2010 users User profile (in the mailbox resiliency configuration) Mailbox size Number of DAGs and database copies Number of hypervisor hosts hosting Exchange Mailbox server virtual machines Number of Exchange Mailbox server virtual machines Number of Exchange users per Mailbox server virtual machine Database read/write ratio (in Mailbox Resiliency configuration) Value 15,000 users 100 messages/user/day (0.10 IOPS) 1.5 GB 1 DAG with 2 copies 2 6 5,000 users in a switchover condition (2,500 active/2,500 passive) 3:2 Background Database Maintenance Enabled 24 x 7 Number of databases per Exchange Server 6 Number of users per database 834 Database LUN size Log LUN size Total database size used for performance testing 1.6 TB 90 GB 45 TB 14

15 Chapter 2: Solution Architecture and Design Note: The 15,000 Exchange 2010 users configured in this solution do not present the limiting factor for the VNX5700 storage array. The maximum user configuration depends on the Exchange 2010 user profile mailbox size, disk size, and RAID type. Review the EMC VNX5700 Unified Storage 60,000 Users with 2 GB Mailboxes Microsoft Exchange Server 2010 Mailbox Resiliency Storage Solution white paper for additional information about VNX5700 performance with Exchange Jetstress. Exchange storage design Overview To support the Exchange Server 2010 user profile and mailbox size requirements that are listed in Table 4, we used an EMC VNX5700 storage array with 2 TB 7.2k rpm NL- SAS drives to house the databases and logs. To simplify design and deployment, we designed and configured a Mailbox server building block with the appropriate number of drives to support the required performance and capacity for each Mailbox server. Building block design approach EMC provides methodologies to easily and efficiently deploy Microsoft Exchange on EMC VNX family of storage arrays. For this solution, we used an Exchange 2010 building block design method. A Mailbox server building block represents the amount of storage (I/O and capacity) and server compute (CPU and memory) 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 (messages sent/received, IOPS per user, and mailbox size). Using the building block approach simplifies the design and implementation of Exchange Server With the initial building block designed, we can easily reproduce it to support the required number of users in your enterprise. By using this approach, EMC customers can now create their own building blocks based on their company s specific Exchange environment requirements. This approach is very helpful when future growth is expected, because it makes Exchange environment expansion simple and straightforward. EMC s best practices involving the building block approach for Exchange Server design has proven to be very successful in many customer implementations. For more details on using the EMC building-block methodology for Exchange 2010 deployments, see the Microsoft Exchange 2010: Storage Best Practices and Design Guidance for EMC Storage. Mailbox server virtual machine building block details The Exchange Mailbox server virtual machine for this solution uses a building block for 5,000 users. The storage, CPU, and memory resources for this building block are derived from the design attributes presented in Table 5. For additional Microsoft guidelines considered for this solution s design, see the article Mailbox Server Processor Capacity Planning from Microsoft TechNet. Table 5 summarizes the Exchange Mailbox server virtual machine building block for 5,000 users with 100-message profile and a 1.5 GB mailbox quota. 15

16 Chapter 2: Solution Architecture and Design Table 5. Mailbox server building block summary Users per Exchange Mailbox server virtual machine Disks per Exchange Mailbox server virtual machine vcpus per Exchange Mailbox server virtual machine 5, CPUs 32 GB Memory per Exchange Mailbox server virtual machine Table 6 presents storage design details for a Mailbox server building block with 5,000 users. Table 6. Storage design details for a 5,000-user Mailbox server building block Attribute Number of users User profile Mailbox size Disk type Storage configuration/raid type Databases per server/users per database LUNs/LUN sizes Details 5,000 (in a switchover condition) 100 messages sent/received (0.10 IOPS) 1.5 GB 2 TB NL-SAS, 7.2k rpm 18 disks per building block for Exchange data: 16 disks in RAID 1/0 for databases 2 disks in a RAID 1/0 for logs 6 databases per server, 834 users per database 13 LUNs per Mailbox server virtual machine: 6 database LUNs TB (RDM/P) 6 log LUNs - 90 GB (RDM/P) 1 LUN for virtual machine operating system GB (VMFS) About VNX storage pools When deploying storage for Exchange Server 2010 in a virtualized environment on a VNX storage system, you can choose to use either storage pools or traditional RAID groups. The use of storage pools simplifies storage provisioning. Traditional storage provisioning with only RAID groups restricts the number of disks you can have in a group to 16. Storage pools, on the other hand, enable you to manage potentially hundreds of disks at a time. Such pool-based provisioning provides benefits similar to Meta LUN striping across many drives but, unlike Meta LUNs, storage pools require minimal planning and management effort. Storage pools support tiering, VNX Snapshots, and automatic rebalancing and have the same RAID protection levels as RAID groups do; RAID 1/0, RAID 5, and RAID 6. Using homogeneous thick storage pools (pools with the same disk type) for deploying Exchange storage on VNX systems can help to simplify storage design and LUN provisioning. 16

17 Chapter 2: Solution Architecture and Design Note: We used storage pools to take advantage of the new VNX Snapshots feature introduced in the VNX OE 5.32 for Block release. VNX storage pools deployment options You can use one of the following three main models when designing storage pools for deploying Exchange 2010 in physical or virtual environments: Storage pool per Mailbox server This model deploys a single storage pool for each Exchange Mailbox server virtual machine. This option provides more granularity and easy deployment with a building block methodology. It also provides database copy isolation if the server is deployed in a DAG with multiple copies. This deployment model also works well when deploying Exchange Server 2010 without mailbox resiliency (no DAG). Storage pool per database copy This model provides database copy isolation and, in many cases, can minimize the number of pools that you need to deploy. However, this model requires careful distribution of LUNs to vsphere hosts and virtual machines. You distribute database copies from each pool to multiple Mailbox server virtual machines. Storage pool per vsphere host This model works well when Exchange is deployed in a virtual environment with multiple DAG copies. In this model, each storage pool may contain both active and passive database copies from different Mailbox servers. It is important to be sure that the same ESX server does not host copies of the same database. With careful design, this model can provide database copy isolation and balanced performance. VNX storage pool design for this solution To efficiently utilize storage space and to use the new VNX Snapshots functionality, we deployed a model with a storage pool per vsphere host hosting multiple Exchange virtual machines. We balanced each pool with active and passive DAG copies. We also separated databases and logs into different storage pools to allow for more efficient storage resource utilization. For the Exchange databases, we deployed two RAID 1/0 storage pools with 48 NL-SAS disks per pool for each vsphere host hosting three Exchange Mailbox Server Role virtual machines. Each storage pool in our solution provides almost 43 TB of usable capacity (42.9 TB) and meets the IOPS and mailbox capacity requirements to support three Mailbox server building blocks with 15,000 users at 0.10 IOPS, each with a 1.5 GB mailbox. From each storage pool, we configured eighteen 1.6 TB database LUNs to accommodate the database space requirements. The LUNs are distributed between Exchange Mailbox server virtual machines on the same vsphere host. Note: We configured one of the storage pools in our solution with thin (virtually provisioned) LUNs. We did this to evaluate the performance of both configurations with VNX Snapshots. We used a similar design for configuring storage pools for the Exchange logs. We deployed two homogeneous RAID 1/0 storage pools, each with four NL-SAS disks, and with each pool supporting loc capacity for three Mailbox server building blocks. From each storage pool, we configured eighteen 90 GB LUNs and distributed them among Exchange Mailbox server virtual machines on the same vsphere host. 17

18 Chapter 2: Solution Architecture and Design We configured all database and log LUNs on each Exchange virtual machine as raw device mappings in physical compatibility mode (RDM/P) to take advantage of Microsoft Volume Shadow Service (VSS) framework functionality for application recovery. EMC AppSync enhances and leverages this framework to initiate application level protection and recovery. Note: The Microsoft Volume Shadow Service (VSS) is a Microsoft technology built into the Windows operating systems that allows applications to access a "point in time" snapshot of a logical drive, also enabling files that are in use or locked to be accessed. For each Exchange virtual machine operating system volume, we configured 200 GB LUNs from a separate RAID 5 storage pool comprised of 2 TB NL-SAS disks formatted as VMFS volume on the vsphere host. Figure 2 illustrates the VNX storage pool information from EMC Unisphere. Figure 2. EMC Unisphere Storage pools created for this solution Figure 3 illustrates the storage configuration for Exchange databases used for the Mailbox server virtual machines in this solution. 18

19 Chapter 2: Solution Architecture and Design Figure 3. Storage design for virtualized Exchange Mailbox servers Best practices for managing storage pools To ensure optimal performance, use the following EMC best practices for managing pools on VNX storage: Do not change the default owner of the pool LUN after you provision it. This can adversely affect performance. It changes the underlying private structures for pool LUNs that the original storage processor (SP) still controls. It is a best practice to let the system balance the pool LUNs on both SPs when you create the pool LUNs, which it does by default: If you must manually change the setting, you must also manually ensure balance between the SPs. 19

20 Chapter 2: Solution Architecture and Design If you must change the SP ownership after you create the LUN, you can leverage LUN migration to migrate the LUN to a new LUN with the desired SP owner. Then perform a trespass operation for the LUN from its previous owner to the new owner. Carefully consider the metadata overhead before provisioning pool thin LUNs for your applications. To estimate the metadata overhead, add the fixed overhead to the variable overhead. The fixed overhead is 3 GB for thin LUNs. The variable overhead is equal to 3 percent of the LUN s user capacity. (This is a conservative estimate for thin LUNs that are 250 GB and larger, while smaller LUNs may have a slightly higher variable overhead.) vsphere server design To provide high availability for Exchange virtual machines, we configured two vsphere hosts as a HA/DRS cluster. Each physical host in the cluster had enough CPU and memory resources to sustain failure or maintenance of another cluster node. During vsphere host maintenance, all Exchange virtual machines hosted on this server can be automatically migrated to another vsphere cluster host. In our solution, we deployed two vsphere servers with 32 CPUs and 192 GB of RAM capacity to support six Mailbox Server Role virtual machines (with three virtual machines per vsphere server during normal operations). We provisioned Exchange Client Access and Hub Transport role virtual machines on another vsphere host. Exchange protection For high availability, Exchange 2010 is usually deployed in a DAG with at least two copies. In most cases, this is sufficient to protect Exchange during Mailbox server failure or maintenance. However, DAG does not provide protection from logical database corruption because such corruption can replicate to other copies. To protect your environment from logical corruption, implement VSS backup with point-in-time recovery. In this solution, we used EMC AppSync to initiate application-consistent snapshots on a VNX storage array. Note: An Exchange Server 2010 lagged copy can also provide protection from database corruption. However, lagged copies cannot provide multiple pointin-time recoveries. After using a lagged copy for recovery, you must recreate (seed) it. This process may be resource and time consuming in some environments. For additional information about Exchange database corruption types and lagged copy limitations, refer to the article Managing Mailbox Database Copies from Microsoft TechNet. 20

21 Chapter 3: AppSync and VNX Snapshots with Exchange AppSync and VNX Snapshots with Exchange 2010 AppSync overview This chapter describes how to configure AppSync with Exchange 2010 and includes the following sections: AppSync overview AppSync deployment options AppSync service plans Additional AppSync features and configuration details Using Exchange restore options with AppSync Sizing guidelines for storage pools when using VNX Snapshots In this solution, we used EMC AppSync to create application-consistent copies of Exchange 2010 data on a VNX storage array to protect Exchange from logical database corruption. AppSync will provide point-in-time recovery based on RPO policy settings. EMC AppSync provides simple, self-service application protection with tiered protection options and proven recoverability. AppSync protects Exchange by creating application-consistent copies of application data. You indicate to AppSync what you want to protect by subscribing the Microsoft Exchange databases to a service plan. When the service plan runs, one or more copies are created. The service plan can also mount the copy, validate it, and run user-created scripts. When you add an Exchange Mailbox Server to AppSync, it identifies whether it is an Exchange standalone or an Exchange DAG member server. For example, you can also add other Windows Servers as utility hosts to AppSync, where you can mount the copies to back up to long term storage, or run a consistency check (if Exchange 2010 management tools are installed). AppSync can also restore individual Exchange Mailboxes and mailbox items when EMC ItemPoint for Microsoft Exchange Server is installed on a utility host. Note: For more details about EMC AppSync and Microsoft Exchange configuration, refer to the AppSync User Guide available at 21

22 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 AppSync deployment options Overview AppSync components include the AppSync server, host plug-in software, and the user interface. Figure 4 shows how we deployed AppSync with VNX storage and VMware vsphere to protect Exchange 2010 data using VNX Snapshot replication technology. Figure 4. EMC AppSync deployment architecture in this solution AppSync server AppSync host plug-in The AppSync server software resides on a supported Windows system. It controls the service plans and stores data about each copy it creates. The repository is stored in a database on the AppSync server, which can be a physical or virtual machine. In this solution, we deployed AppSync server as a virtual machine on a vsphere host. We also deployed an additional virtual machine to be used as a mount host. On this virtual machine, we installed just the Exchange 2010 management tools so that AppSync can initiate database consistency checks if this option is selected in the service plan. AppSync installs lightweight plug-in software on the production and mount hosts. AppSync pushes the plug-in software from the AppSync server to the host when you add the host as a resource. In an environment that prevents the AppSync server from accessing a host, you can install the plug-in manually. An Exchange Mailbox server or an Exchange validation or mount host are examples of hosts on which this plug-in can reside. In this solution, we installed the AppSync host plug-in on all Exchange Mailbox servers as well as the AppSync utility host (where we installed only the 22

23 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Exchange 2010 Management tools). Figure 5 shows the AppSync host plug-in configured on Exchanged Mailbox servers. Note: Do not use the AppSync server as the mount host because the server performance may be impacted while running multiple consistency checks on a large number of databases. The best practice is to deploy another virtual machine for this operation. For more information, refer to the white paper entitled EMC AppSync Performance and Scalability Guidelines published on Figure 5. AppSync host plug-in configured on Exchange Mailbox servers AppSync user interface The AppSync console is web-based and shares the same look and feel as the EMC Unisphere interface. Figure 6 details the AppSync dashboard, which provides a consolidated view of the service plan activities, SLA compliance, and any recent activity. 23

24 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Figure 6. AppSync Dashboard view AppSync service plans An AppSync service plan is comprised of multiple phases, including: Create copy Mount copy Validate copy Unmount copy Phases that run optional user-provided scripts AppSync includes several application-specific plans that work without modification. The default service plans, Platinum, Gold, Silver, and Bronze offer tiered protection levels and are designed based on the EMC replication technology used. For example, the Bronze service plan is automatically configured for Microsoft Exchange protection with EMC VNX Snapshots. You can also modify the service plan settings to match your requirements, or create a new plan. Figure 7 details some of the default and custom plans created in AppSync. For this solution, we created two custom plans: Full Backups-- This plan creates a full application-consistent copy of the databases in the DAG and schedules it to run once per day. VSS Snapshots--This plan creates hourly snapshots for point-in-time recovery with the RPO policy of one hour. 24

25 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Figure 7. Default and custom AppSync service plans 25

26 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Additional AppSync features and configuration details This section describes several other AppSync features used in this solution. AppSync interaction with VSS Exchange DAG configuration guidelines Microsoft VSS service provides the infrastructure that enables AppSync to create application-aware copies. When it creates a copy, AppSync coordinates with VSS and Exchange to create a shadow copy, which is a point-in-time copy of the volumes that contain the data, logs, and system files for Exchange databases. AppSync coordinates with VSS and Exchange to quiesce I/Os to the databases when creating the copy, and then resumes the data flow after creating the copy. During a restore, AppSync coordinates with VSS and Exchange to recover the point-in-time shadow copy. AppSync supports the replication of Exchange databases that are part of an Exchange 2010 DAG. This functionality protects Exchange databases by using a subset of Windows failover clustering technologies. There is no shared storage in a DAG environment. When you subscribe a DAG server to an AppSync service plan, by default, it selects one of the passive DAG cluster members for protection. To protect a different type of DAG database member, make that change from the plan's Subscriptions tab. If you want to run the protection immediately, subscribe the DAG to a plan, change the type of database you wish to protect from the service plan, and choose Run from the service plan, as shown in Figure 8. The protection begins immediately for all databases subscribed to the plan. Figure 8. Protecting a DAG database member 26

27 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Exchange Database and log layout considerations Exchange 2010 supports environments in which the database and logs reside on the same volume. However, a limitation in the VSS architecture prevents successful mounts and restores when the root drive letter has mount points on it and they are all included in the same plan. For instance, if the log and system files are on F:\ and the Mailbox databases are on F: \DB1MP (where DB1MP is a mount point), AppSync cannot mount or restore the replica. Instead, create a very small LUN and put the F: volume on that LUN. Then create two mount points on the volume: one for the database file, and one for the transaction logs. The other option is to create the mount points on one of the volumes that is local to the server. As shown in Figure 9, two mount points are created on the local server and each Exchange database LUN is mounted individually to a mount point in C:\MP_DB, and each log LUN is mounted individually in C:\MP_Logs. Figure 9. Configuring mount points AppSync Service plan advanced properties You can configure service plans to ignore the restriction that prevents databases and logs from residing on the same volume. When creating copies of Exchange 2010 databases, it is a best practice to restrict a service plan from allowing this configuration, because having databases and logs on the same volume limits your restore options. However, you can choose whether service plans with this configuration should succeed or not. You set this option in the Create Copy phase located in the service plans Settings tab. When selecting this option, you are limited to restoring the database and logs together. A restore overwrites newer log files. To preserve newer log files for use during recovery, copy them to another volume before performing a restore. Exchange event log errors Exchange logs certain errors in the Application Event log when they occur. These errors can cause copy creation to fail unless you specifically instruct AppSync to ignore them. AppSync searches the application event log for these errors every time it creates a copy. The first time it runs, AppSync searches the entire log. Subsequent runs search the log events that occurred since the last successful run. If there are no existing copies, AppSync searches the entire log when creating the next copy. In a service plan's Create Copy phase settings, you can configure AppSync to ignore any or all of these errors. 27

28 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Figure 10 shows a service plan s Advanced Copy Creation Settings properties with a check box selected to allow a service plan to successfully complete when the database and logs resides on the same volume. It also indicates the Exchange event log errors that AppSync will look for, if selected, when the service plan runs. Figure 10. AppSync service plan properties for Advanced Copy creation settings Exchange backup type AppSync uses VSS to make a consistent online copy at the volume level. There are three types of backup options available: A Full backup creates a copy of the databases in the service plan using VSS, and includes the database files, transaction logs, and checkpoint files. When the backup completes successfully, the logs are truncated. A Copy backup creates a copy of the databases in the service plan using VSS, which includes the database files, transaction logs, and checkpoint files, just as it does using the Full backup option. However, it does not truncate the logs. A Differential backup copies only the transaction logs since the last full backup. A full backup of the selected database must exist or the backup fails. This option does not truncate the transaction logs upon completion of the backup. Figure 11 details a service plan configuration with a backup type and snapshot expiration settings for a VNX Advanced Snapshots copy. 28

29 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Figure 11. AppSync service plan configuration settings Exchange database Validation Options When configuring the AppSync service plan, in the Setting tab, you can choose to mount a snapshot and run a validation (consistency check) on Exchange databases. Note, that consistency checks are no longer required for an Exchange 2010 database if you deploy Exchange 2010 in a DAG with at least two copies of the data because Exchange automatically performs the checks during replication process. For additional information on when to run consistency checks, refer to Microsoft s best practices. If you choose to run a consistency check during the AppSync backup, AppSync will perform this task with the options you specify in the service plan Settings tab against the files that exist on the snapshot. If any of the files fail the consistency check, AppSync will fail the backup, generate an alert, and flag the copy as completed with errors (indicated by a yellow warning icon). The Exchange VSS Writer is notified of the failure. When this type of backup failure occurs, AppSync will not truncate the Exchange log files. Failure of the consistency check may indicate either a database corruption or a problem with the snapshot. Also note that the mount with database validation option may add a considerable amount of time to each service plan cycle. For more information, see the section Mount/unmount test on 39 later in this chapter. Automatic expiration of VNX Snapshot copies The Automatic Expiration value in a service plan s Create Copy phase ( see Figure 11) specifies the maximum number of VNX Snapshot copies that can exist simultaneously. When the Always keep x copies value is reached, older copies are expired to free storage for the next copy in the rotation. Failed copies do not count. This setting is independent of the VNX pool policy settings in Unisphere that automatically delete the oldest snapshots. The service plan administrator should work with the storage administrator to ensure that the VNX pool policy settings support the specified number of snapshot copies required for the application residing in that pool. AppSync does not expire copies under the following circumstances: Mounted copies A copy that contains the only replication of a database 29

30 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Manual Copy Expiration Wizard When you choose to expire a copy of an Exchange database, AppSync automatically discovers and deletes the other associated Exchange database copies that were created together with the one that you chose to delete. This ensures consistency across all databases. Figure 12 shows the details of the AppSync Copy Expiration wizard. AppSync identifies several other copies to be expired at the same time as DB03 and DB11, which we manually selected for expiration. Figure 12. AppSync copy expiration wizard copy expiration selection Controlling VNX LUN utilization When setting up a service plan with VNX Snapshots, avoid overutilization and depletion of LUNs by using care when setting the RPO value in the Start Service Plan phase and the Automatic Expiration value in the Create copy phase. You should also monitor your VNX LUNs with the Unisphere management interface. Using Exchange restore options with AppSync AppSync restores VNX copies of Exchange at the LUN level. With AppSync, you can restore: One or more databases, including the logs One or more database files (.edb) One or more active or passive databases or database files if the server is a member of a DAG Only the logs for one or more databases Figure 13 shows the AppSync Restore wizard, which provides a very simple user interface in which you can select the type of data you want to restore. 30

31 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Figure 13. AppSync Restore Wizard Roll-forward restore The roll-forward option enables you to fully recover your Exchange Server database to its most current state. For this option, you only need to restore the most recent full backup and then replay current transaction logs that occurred after the last successful backup. You should use roll-forward recovery only if you want to restore all of your Exchange Server data to the current state. With AppSync, the Restore wizard procedure is to restore data from the most recent full copy and select the Recover and mount the databases after restore option. After restoring the data, Exchange replays the appropriate logs. Item level restore AppSync can restore individual Exchange mailboxes and messages when EMC ItemPoint for Microsoft Exchange Server is installed on a utility (mount) host. The following software must be installed and running on the mount host where you want to perform item level restores: AppSync host plug-in EMC ItemPoint for Microsoft Exchange Server Restoring individual mailboxes and mailbox items Use ItemPoint to restore individual Exchange mailboxes and mailbox items. This operation requires the Data Administrator role in AppSync. To restore individual mailboxes and mailbox items, perform the following steps: 1. Select Restore > Individual items from the Action button next to an Exchange mailbox server, DAG name, database name, or copy name. The AppSync Item Restore wizard opens. 2. From the Select Copy screen, select one or more copies from the list. If the copy was made with RecoverPoint, you can choose Add a desired point in time and select that copy. Specify a date and time (and DAG server if appropriate) when you select this option. (If you started the wizard from a copy, you do not perform this step.) 31

32 Chapter 3: AppSync and VNX Snapshots with Exchange If the copy is not mounted, select Mount Options. From the Select Mount Options screen, select the mount host and the mount path (the original path or the default). 4. From the Item Level Restore Settings screen, enter a user name and password to access the Item Level Restore wizard, and select a temporary directory. 5. From the Summary screen, confirm your settings and select Finish to launch EMC ItemPoint for Microsoft Exchange Server. The Results screen displays your progress and launches ItemPoint. Note: Use ItemPoint to restore mailbox items. For more information about using EMC ItemPoint for Microsoft Exchange Server, refer to EMC ItemPoint for Microsoft Exchange Server. Sizing guidelines for storage pools when using VNX Snapshots To properly design storage pools for use with VNX Snapshots, review the basic VNX Snapshots concepts and how they work as described in this section. VNX Snapshots basics VNX Snapshots use ROW technology, which redirects new writes destined for the primary LUN, to a new location in the storage pool without the need to read or write to the old data block. This improves overall performance compared to SnapView. Figure 14 details VNX Snapshots read and write operations. For additional details, refer to the white paper entitled VNX Snapshots, available at Figure 14. VNX Snapshots write/read operations VNX Snapshots are a part of the storage pool. A snapshot does not consume space from the pool until the new data is written to the primary LUN or to the snapshot itself. Snapshots have a granularity of 8 KB, and their blocks are tracked just like the blocks in thin LUNs. 32

33 Chapter 3: AppSync and VNX Snapshots with Exchange 2010 Thick LUN considerations When you create a VNX Snapshot on a thick LUN, portions of its address space change to indirect mode. In other words, when writes come in to the snapped thick LUN, the LUN starts converting the address mapping from direct to 8 KB blocks for each portion of the thick LUNs that are being written. Note: The thick LUN remains classified as thick in the CLI and GUI. The thick LUN remains in an indirect mode while it has VNX Snapshots. When the last snapshot of the thick LUN is removed, the mode automatically converts the LUN to direct mode. This conversion is not instantaneous, and is performed in the background. You can stop the conversion by creating a new VNX Snapshot on the LUN. The operations to a thick LUN while in indirect mode might exhibit some overhead. You can limit this overhead by enabling FAST Cache on a storage pool. In most cases, a very small amount of the FAST Cache absorbs all the metadata associated with converting thick LUNs from direct to indirect mode. We validated this configuration and included the test results in the chapter entitled Solution validation and test results on page 4. VNX Snapshots design recommendations When using VNX Snapshots for protecting Exchange 2010, follow these recommendations: Size your VNX pools for performance and capacity based on user requirements Always enable FAST Cache on the storage pools with Exchange database LUNs (thick or thin) Enable proactive monitoring of the storage space used by the pool Do not perform excessive deletion of snapshots during busy array operations 33

34 Chapter 4: Solution validation and test results 4 Solution validation and test results This chapter details solution validation and performance test results and has the following sections. Solution validation objectives Exchange performance validation tools Exchange performance on VNX storage with VNX Snapshots VNX storage pool space usage with VNX Snapshots under Exchange workload AppSync Performance Solution validation objectives The goal of the validation and testing phase of this solution was to answer several questions: How will the VNX storage array perform with Exchange 2010 Jetstress when VNX snapshots are enabled (Thick and Thin LUNs)? How will Exchange perform when we configure storage on thin or thick LUNs and an AppSync service plan initiating VNX Snapshots? How do you size VNX storage pools with VNX Snapshots for Exchange workloads to meet specific user RPO requirements? If you allocate too little space for snapshots, you will not be able to meet your RPO requirements and might lose some snapshots because they will be overwritten by new ones. If you allocate too much space, you will waste valuable storage resources. To obtain all the answers, we split the solution validation testing into two phases. In the first phase, we validated our storage design using Jetstress in order to answer the first question. In the second phase, we used Exchange LoadGen to verify the solution, so that we could answer the remaining questions. 34

35 Chapter 4: Solution validation and test results Exchange performance validation tools For this solution, we used two Microsoft tools to validate Exchange performance Jetstress and Loadgen. For additional information about using Jetstress and LoadGen, refer to the following Microsoft document at Exchange Jetstress Exchange Jetstress is used for validating the Exchange storage design before placing it into production environment. Jetstress simulates Exchange I/O at the database level by interacting directly with the database technology of the ESE, also known as the Jet on which Exchange is built. You can configure Jetstress to test the maximum I/O throughput available to your disk subsystem within the required performance constraints of Exchange. You can also configure it to accept a user count, profile, and I/O per second per user to validate that the disk subsystem is capable of maintaining an acceptable performance level with that profile. We strongly recommend that you use Jetstress to validate storage reliability and performance before deploying your Exchange servers to a production environment. You can download Jetstress from The Jetstress documentation describes how to configure and execute an I/O validation or evaluation on your server hardware. While the Jetstress tool tests the performance of the Exchange storage subsystem before placing it in the production environment, it does not test the impact of the server CPU and memory configuration of MAPI user activity. Use Microsoft LoadGen for this purpose. Exchange LoadGen The Load Generator (LoadGen) tool is designed to produce a simulated client workload against a test Exchange deployment. You can use this workload to evaluate how Exchange performs, and can also be used to analyze the effect of various configuration changes to Exchange and performance behavior while the system is under load. To simulate the delivery of messaging requests, use LoadGen to test client computers. LoadGen is a useful tool for administrators when sizing servers and validating a deployment plan. Note: LoadGen does not represent real-world workloads, but rather helps you determine if each server can handle its intended load based on known user profile configurations. Another use for LoadGen is to help validate an overall solution. 35

36 IOPS Latency (ms) Chapter 4: Solution validation and test results Exchange performance on VNX storage with VNX Snapshots To validate Exchange performance on a VNX array with VNX Snapshots, we used Microsoft Jetstress For this test, we configured storage as follows: Two storage pools, each with 48 x 2 GB NL-SAS drives containing three mailbox server building blocks with 15,000 users per pool (30,000 users in total) One storage pool configured with thin LUNs and the other with thick LUNs VNX Snapshots created in each storage pool during Jetstress testing FAST Cache was enabled on each storage pool We ran multiple two--hour Jetstress tests against each storage pool. We were targeting 1,800 user IOPS (600 users at.10 IOPS plus 20 percent headroom) and read latencies below 20 ms. While Jetstress was generating heavy I/O load to the storage subsystem, we performed snapshots against Exchange databases during the test. Figure 15 shows the results of the tests. We observed that the VNX5700 array successfully handled the load and exceeded the Exchange 2010 user IOPS target in both configurations (thick and thin). In addition, database read latencies were below the 20 ms target. Exchange 2010 Performance with VNX snapshots on VNX Thick LUNs with VNX Snaps & FAST Cache 17.0 Thin LUNs with VNX Snaps & FAST Cache DB Read Latency (ms) Achieved User IO Target IOPS 15,000 users per storage pool k rpm 2TB NL-SAS drives per RAID 1/0 pool Performance target user IOPS per pool and < 20ms DB read latency to pass Jetstress Figure 15. Exchange 2010 performance on the VNX array with VNX Snapshots 36

37 Chapter 4: Solution validation and test results VNX storage pool space usage with VNX Snapshots under Exchange workload Overview To evaluate storage pool space usage with snapshots, we ran multiple tests using LoadGen to measure the snapshots space usage under load with specific RPO requirements. We configured LoadGen to generate the MAPI workload load for 10 hours. We also configured an AppSync service plan to perform hourly VSS snapshots of the passive database copies to provide a one-hour RPO. VNX snapshots space usage during testing Table 8 presents the VNX snapshots space usage test results. For further clarification about the content of these results, review the descriptions of the VNX storage pool properties provided in Table 7. Table 7. VNX storage pool properties - Physical and virtual capacity Physical capacity Total Free Percent full Total allocation (visible when VNX Snapshot Enabler is installed) Snapshot allocation (visible when VNX Snapshot Enabler is installed) Total usable space in the pool (raw disk space minus RAID overhead) Total amount of available space in the pool Percentage of consumed pool user capacity Amount of space in the pool allocated for all data Amount of space in the pool allocated to VNX Snapshot LUNs Virtual capacity Total Subscription Snapshot subscription (visible when VNX Snapshot Enabler is installed) Percent subscribed Oversubscribed by Total amount of LUN user capacity configured in the pool and is presented to the attached hosts. If there are thin LUNs in the pool, the subscribed capacity can exceed the physical user capacity of the pool. When this number exceeds 100%, the pool capacity is oversubscribed. Total potential size required by snapshots if their primary data was completely overwritten, plus the size of any writable (attached) snapshots. Percentage of user capacity assigned to all LUNs in the pool and visible to the attached hosts. This includes primary and snapshot capacity. Amount of subscribed capacity that exceeds the user capacity of the pool. If this value is equal to or less than zero, this option appears grayed out. 37

38 Chapter 4: Solution validation and test results Table 7 presents VNX storage pool space and snapshots allocation space usage during 10-hour LoadGen test. The data points were collected at two our intervals. At the end of the test, we observed that only 123 GBs from the pool were allocated for snapshots. This is just less than 3 percent from the total physical pool capacity of 42.9 TB. We can estimate that given the same change rate over a 24-hour period, snapshots space would take no more than 7 percent of the total physical pool capacity. We suggest that you allocate about 10 percent of the pool s total capacity to snapshots when you size the database storage pool. Be advised that the numbers presented in Table 8 serve only as an estimated guideline. Use these results as a reference point for sizing VNX storage pools with Snapshots for Exchange 2010 workloads. We recommend that you size Snapshots based on actual change rates in your production environment. The test results presented in the Table 8 are based on the following criteria: LoadGen workload for 5,000 users per server with 100 sent/received messages per user and Outlook clients in online mode (~75 k message size) Hourly application-consistent (VSS) Snapshots with AppSync for each database The VNX storage pools contains active and passive DAG database copies The snapshots are created from the passive copies Table 8. Timeline Start 0 hours VNX Storage pool space usage with snapshots and Exchange 2010 workload Storage pool free space (GB) Total allocation (GB) Percent full (%) 13, , Snapshot allocation (GB) 2 hours 13, , hours 13, , hours 13, , hours 13, , hours 13, , Note: Performance is measured based on a 15 Mb/s change rate generated by the LoadGen tool. 38

39 Chapter 4: Solution validation and test results AppSync Performance To evaluate AppSync performance with Exchange 2010 replication and recovery, we performed multiple tests and measured timing for each activity. Backup Test In this test all 18 passive databases were backed up at once and logs were truncated on each Mailbox server. We did not perform a consistency check, as it is no longer a requirement for Exchange 2010 when deployed in a DAG. To perform a database consistency check, specify this option in the AppSync service plan. AppSync automatically mounts the database on the mount host of your choice and run a consistency check. Also, note that the mount with database validation option may add a considerable amount of time to each service plan cycle. For more information, see Mount/unmount test below. Table 9 shows the test results observed during the AppSync service plan with VNX Snapshots and Exchange 2010 full and copy backups. Table 9. AppSync Service plan performance with Exchange Copy and Full backups Dataset Service plan duration (copy backup) Service plan duration (full backup) 1database (1.2 TB) 2 min. 11 sec. 2 min. 18 sec. 6 databases (~7.2 TB) 3 min. 02 sec 3 min. 47 sec. 18 databases (~22 TB) 6 min. 01 sec 6 min. 14 sec. Exchange restore test Table 10 shows test results for our Exchange restore test. In this test, we restored one database from a full copy snapshot. Table 10. AppSync service plan performance for an Exchange restore Dataset 1database (~1.2 TB) Total duration 2 min. 54 sec Mount/unmount test The AppSync Mount wizard provides a simple and intuitive process for performing mount operations. During the copy mount process, AppSync fully automates all the necessary steps and eliminates the need for creating mount points and consistency groups on the VNX array. After selecting the copy you want to mount, the wizard allows you to mount additional copies that were protected and snapped together on the same mailbox server during the backup. All these copies are application consistent because VSS framework was used for this operation. In Figure 16, you can see that when we selected DB01 to be mounted, AppSync provided a selection choice of five databases configured on the same Mailbox server. 39

40 Chapter 4: Solution validation and test results Figure 16. AppSync mount wizard multiple copy selection choice Table 11 displays the performance results of the mount and unmount operations. Note that the mount test did not include the option of performing a database validation. Table 11. Mount/Unmount timings Dataset Mount Duration Unmount Duration 1 database (~1.2 TB) 3 min. 23 sec. 4 min. 20 sec. 6 databases (7.2 TB) 12 min. 14 sec. 15 min. 45 sec. Mount with validation option test Table 12 shows the AppSync results using the mount with validation option. In this test, we performed the mount with validation option and ran the database consistency check in parallel on all six databases. The mount host was a virtual machine with two CPUs and 8 GB of RAM configured on a vsphere 5 host that did not host Exchange Mailbox virtual machines. The host had two 8 Gb HBAs zoned to two front-end 8 Gb VNX ports. To ensure that the consistency check runs efficiently, ensure that you provide enough bandwidth and throughput between the mount host and the storage. The more bandwidth you have, the more throughput you can achieve, and the faster the consistency checks will complete. Table 12. Mount with validation options test results Dataset Mount duration Validation duration Total duration 6 databases (7.2 TB) 12 min. 14 sec. 1 hrs. 48 min. 2 hrs. 14 sec. 40