EMC Backup and Recovery for Microsoft Exchange 2007

Transcription

1 EMC Backup and Recovery for Microsoft Exchange 2007 Enabled by EMC CLARiiON, EMC NetWorker, and EMC Avamar Proven Solution Guide

2 Copyright 2010 EMC Corporation. All rights reserved. Published July 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: H6960.1

3 Table of Contents Chapter 1: About this document... 4 Overview... 4 Audience and purpose... 5 Scope... 6 Business challenge... 7 Technology solution... 7 Objectives... 9 Reference Architecture Validated environment profile Hardware and software resources Prerequisites and supporting documentation Terminology Chapter 2: Exchange 2007 on CLARiiON Design Overview Exchange 2007 design Storage design Chapter 3: Application Design Overview NetWorker server and NMM design Avamar design Chapter 4: Testing and Validation Overview Methodology Testing tools Test results summary Chapter 5: Conclusion Overview Supporting Information: Installation and Configuration Overview Task 1: Install and configure NetWorker NMM on Exchange servers Task 2: Install and configure the NetWorker Proxy client Task 3: Configure a backup pool, schedules, snapshot policy, and privileges Task 4: Configure a backup client and group in NetWorker Task 5: Integrate Avamar Data Store with NetWorker

4 Chapter 1: About this document Chapter 1: About this document Overview Introduction This document summarizes a series of best practices that were discovered, validated, or otherwise encountered during the validation of a Backup and Recovery solution for using EMC CLARiiON CX4-480, EMC NetWorker Module for Microsoft Applications, and EMC Avamar. 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. Use case definition A use case reflects a defined set of tests that validates the reference architecture for a customer environment. This validated architecture can then be used as a reference point for a Proven Solution. Contents The content of this chapter includes the following topics. Topic Audience and purpose 5 See Page Scope 6 Business challenge 7 Technology solution 7 Objectives 9 Reference Architecture 10 Validated environment profile 11 Hardware and software resources 11 Prerequisites and supporting documentation 13 Terminology 14 4

5 Chapter 1: About this document Audience and purpose Audience The intended audience for the Proven Solution Guide is: Internal EMC personnel EMC partners Customers Purpose This Proven Solution Guide provides details of the EMC Backup and Recovery solution for Microsoft Exchange 2007 enabled by EMC CLARiiON CX4-480, EMC NetWorker Module for Microsoft Applications, and EMC Avamar. The purpose of this solution is to: Showcase the value of performing an advanced disk-based backup and deduplication solution for 8,000 Very Heavy Microsoft Exchange 2007 users, compared to a traditional tape-based backup strategy Validate the backup performance of 2.8 TB of data and the recovery functions provided by the integrated NetWorker Module for Microsoft Applications (NMM) on Microsoft Exchange 2007 Investigate the performance for different backup and recovery approaches, and compare the test results Validate the deduplication functions and document data deduplication rate by Avamar and NetWorker Client, which makes this solution ideal for long-term retention of Exchange backups Validate NetWorker NMM s interaction with both hardware and software Microsoft Volume Shadow Copy Service (VSS) Determine the best practice, including the NetWorker NMM and Avamar design overview and considerations In the solution, an EMC CLARiiON CX4-480 storage array is used for storage and consolidation, while Microsoft Exchange Server 2007 is used as the main application for the enterprise s communication and collaboration. NMM is used for Exchange database backup and recovery, using VSS technology. NMM also rolls over the clone to the backup media with its NetWorker client. In this solution, an EMC Avamar Data Store appliance is used as the backup media and to provide data deduplication. Both Microsoft Exchange High Availability technologies, Exchange 2007 Clustered Continuous Replication (CCR) and Exchange 2007 Single Copy Cluster (SCC), are implemented in this solution. The intent of providing design and testing data for both options in a single Proven Solution Guide is to help customers more easily determine which option best fits their requirements. 5

6 Chapter 1: About this document Scope Scope This Proven Solution Guide describes the architecture of an EMC solution built at EMC s Information Infrastructure Solutions labs. The main focus is the design, configuration, and validation of a backup and recovery solution for Exchange servers. In this solution, a configuration is designed and built to support up to 8,000 Very Heavy Exchange 2007 users. Each of the 8,000 users is profiled with a value of 0.48 IOPS (Microsoft Outlook Very Heavy profile) and a 350 MB mailbox. The backup and recovery solution provides design and configuration guidelines for incorporating: EMC CLARiiON CX4 with Exchange 2007 to provide storage with performance, scalability, and advanced data management features EMC NetWorker Module for Microsoft Applications (NMM) to provide backup and recovery services with VSS technology for Exchange 2007 EMC Avamar to reduce the size of backup data at the source and to provide central management leveraging a NetWorker agent Not in scope The information contained in this Proven Solution Guide is not intended to replace existing, detailed product implementation guides or pre-sales site evaluations. The steps outlined during each stage are high-level in nature and should be read in conjunction with the documentation referenced throughout this guide. The solution environment simulates an enterprise environment. It is important to note that actual customer configurations will be different. 6

7 Chapter 1: About this document Business challenge Overview Today, customers are managing their IT environments to meet a number of corporate directives. They are charted to meet strict service level agreements (SLAs) for user access to , comply with regulatory requirements for archiving and retention, and deliver more efficient IT operations. These factors require the implementation of an efficient backup solution and effective storage management policies for the widely used Microsoft Exchange Server application. Currently, Exchange users mailbox sizes are growing to keep pace with increased file sizes, growth of remote users, and the need for 100 percent uptime. Technology solution Overview This solution is designed and built to support up to 8,000 Very Heavy Exchange 2007 users. Each of the 8,000 users is profiled with a value of 0.48 IOPS (Microsoft Outlook Very Heavy profile) and a 350 MB mailbox. Storage design The EMC CLARiiON CX4 series delivers performance, scalability, and advanced data management features. It is considered a versatile and cost-effective midrange storage system, which is the natural choice for Exchange solutions. In this use case, EMC CX4-480 is used for the solution test. The storage configuration of EMC CLARiiON CX4 series has been validated per the Microsoft Exchange Solution Review Program (ESRP). Detailed information are available at: (Microsoft ESRP) (EMC website) To make Exchange 2007 storage design as scalable and useful to as many implementations as possible, an Exchange 2007 building block approach is used. The building-block approach defines the number of spindles required to support the IOPS and space requirements for a certain number of users per Exchange server Once the first server s requirements are calculated, additional servers can be added based on the same storage design, which makes it easy for you to scale up/down the Exchange environments. Backup design Microsoft Exchange High Availability technology is well adopted by businesses of all sizes to provide business continuity. For Exchange 2007 Clustered Continuous Replication (CCR), NMM is used to take a snapshot of the CCR target copy and to perform consistency check, data deduplication on the passive node, without involving resources on the active Exchange server. In addition, as Exchange 2007 Single Copy Cluster (SCC) is also a popular High Availability Technology, an alternative backup method for SCC is also considered in this use case. Exchange 2007 CCR 7

8 Chapter 1: About this document An Exchange 2007 CCR consists of one active node and one passive node, each with dedicated storage, respectively. To fully utilize storage and server resources, NMM backup is designed on the CCR passive node with software VSS, so that no additional storage is required for the clone. Furthermore, the data consistency check and roll-over are also performed on the CCR passive node, without an additional NetWorker Proxy Client. Exchange 2007 SCC An Exchange 2007 SCC consists of one active node and one passive node, sharing the same underlying storage. An EMC SnapView clone is configured for each DB LUN and Log LUN, so that NMM can leverage this hardware VSS technology for backup purposes. Backup data s consistency check and rolling over to backup media take CPU resources and network bandwidth. To minimize the impact on the production environment, one NetWorker Proxy client is introduced into the environment. The clone LUNs are mounted on the Proxy client for consistency check, and are subsequently rolled over to the backup media. Data deduplication An Avamar Data Store appliance acts as the backup media, and provides the deduplication function for the Exchange mailbox data. In this solution, Avamar Data Store is integrated into NetWorker as a deduplication node, so that by deploying the NMM Client on the Exchange server and the NetWorker Proxy client, you can easily back up only the deduplicated data that has changed at the mail subfile/record level, that is, new GUIDs for mail messages, new subfile hash data contained in messages or attachments, and so on, to the Avamar appliance. To ensure the long-term reliability, availability, and supportability of the Avamar server, RAID_5 is configured for internal SAS disks on the Avamar storage nodes, and the unique Avamar Redundant Array of Independent Nodes (RAIN) technology is enabled to provide the means for the Avamar server to continue to operate even when one node fails. Test method Microsoft Exchange 2007 Load Generator (LoadGen tool) is used to generate user mail, populate the databases, and introduce workloads into the Exchange system. LoadGen simulates the delivery of multiple MAPI client messaging requests to Exchange servers. It also confirms all components (DC/GC, Hub, CAS, and Mailbox Role) are working as designed. Daily full backups are tested after the LoadGen simulation. With the deduplication feature, the amount of data backed up for all subsequent Exchange backups can be greatly reduced in this test only 3 percent. 8

9 Chapter 1: About this document Objectives Overview The following table lists the objectives of this solution: Objective Backup and restore with NetWorker NMM Validate the deduplication function through Avamar Validate NetWorker NMM with hardware VSS Validate NetWorker NMM with software VSS Details Use NMM to back up and restore Exchange databases. The tests will involve initial full backup, daily full backups, snapshot restore, and conventional restore. This use case focuses on the source-based (Avamar) deduplication. Performance data will be investigated. Exchange databases will be cloned through hardware VSS, and NetWorker NMM will leverage clones for the database backup. In addition, restore will also be performed using the database clones. NetWorker NMM will use software VSS on the passive node of the Exchange CCR for database backup. 9

10 Chapter 1: About this document Reference Architecture Corresponding Reference Architecture This use case has a corresponding Reference Architecture document that is available on Powerlink and EMC.com. Refer to EMC Backup and Recovery for Microsoft Exchange 2007 Enabled by EMC CLARiiON, EMC NetWorker, and EMC Avamar Reference Architecture for details. If you do not have access to this content, contact your EMC representative. Architecture diagram The following diagram depicts the overall physical architecture of the use case. 10

11 Chapter 1: About this document Validated environment profile Profile characteristics The solution was validated with the following environment profile. Profile characteristic Number of Exchange 2007 Users 8,000 Value Exchange 2007 IOPS per User 0.48 (Very Heavy) Read/Write Ratio 1:1 Number of Exchange 2007 Mailbox Servers 2 User Count per Mailbox Server 4,000 Mailbox Size 350 MB Number of ESGs per Mailbox Server 8 Database per Storage Group 1 User Count per Database 500 RAID Type for DB/Log RAID Type for Clone RAID_10, 300 GB, 15k rpm FC disk RAID_5, 300 GB, 15k rpm FC disk Hardware and software resources Hardware The hardware used to validate the use case is listed below. Equipment Quantity Configuration Storage array 1 CLARiiON CX4-480 FLARE x 300 GB FC, RAID_10, 15k rpm disks (DB) 18 x 300 GB FC, RAID_10, 15k rpm disks (Log) 15 x 300 GB FC, RAID_5, 15k rpm disks (Clone) 1 x 300 GB FC, 15k rpm disks (hot spare) SAN switch 1 Cisco MDS 9509, 4 Gb/s FC switch IP switch 1 Cisco Catalyst 3560E, 24 ports, 1Gb/s Ethernet switch Avamar appliance 1 EMC Avamar Data Store Grid (six nodes with 4.3 TB total capacity) Exchange Mailbox Servers 4 Dell PowerEdge R710 2-socket quad-core, Intel Xeon 2.4 GHz 36 GB RAM, 3 x 4-port NICs 11

12 Chapter 1: About this document Exchange Hub and CAS Servers 2 dual-port, 4 Gb/s Emulex HBAs 2 Dell PowerEdge R710 2-socket quad-core, Intel Xeon 2.4 GHz 36 GB RAM, 3 x 4-port NICs 2 dual-port, 4 Gb/s Emulex HBAs DC Servers 2 Dell PowerEdge R710 2-socket quad-core, Intel Xeon 2.4 GHz 36 GB RAM, 3 x 4-port NICs NetWorker Server 1 Dell PowerEdge socket quad-core, Intel Xeon 3.4 GHz 32 GB RAM, 2 x 2-port NICs 2 dual-port, 4 Gb/s Emulex HBAs NetWorker Proxy Client/Storage Node 1 Dell PowerEdge R710 2-socket quad-core, Intel Xeon 2.4 GHz 36 GB RAM, 3 x 4-port NICs 2 dual-port, 4 Gb/s Emulex HBAs LoadGen Client VM Farm 1 Dell PowerEdge R900 4-socket Six-core, Intel Xeon 2.4 GHz 128 GB RAM, 3 x 4-port NICs 2 dual-port, 4 Gb/s QLogic HBAs Software The software used to validate the use case is listed below. Software Version Windows Server 2008 Enterprise Edition SP2 Microsoft Exchange 2007 Enterprise Edition SP2 NetWorker 7.5 SP1 with latest patch NetWorker Module for Microsoft Application 2.2 with latest patch Avamar Software 4.1 EMC Solutions Enabler with VSS 64-bit EMC PowerPath 5.3 Emulex driver VMware ESX server 4.0 Microsoft LoadGen

13 Chapter 1: About this document Prerequisites and supporting documentation Technology It is assumed the reader has a general knowledge of the following products: EMC CLARiiON storage arrays EMC NetWorker EMC Avamar Microsoft Exchange Server 2007 Microsoft LoadGen Supporting documents The following documents, located on Powerlink.com, provide additional, relevant information. Access to these documents is based on your login credentials. If you do not have access to the following content, contact your EMC representative: EMC Avamar 4.1 Operational Best Practices EMC Avamar 4.1 Server Software Installation Manual EMC Avamar 4.1 System Administration Manual EMC Avamar 4.1 Release Notes EMC NetWorker Release 7.5 Installation Guide EMC NetWorker Release 7.5 Administration Guide EMC NetWorker Module for Microsoft Applications Release 2.2 Installation Guide EMC NetWorker Module for Microsoft Applications Release 2.2 Administration Guide EMC NetWorker Module for Microsoft Applications and EMC CLARiiON Implementing Proxy Node Backups - Technical Notes Configuration Options for Exchange Backups and Recovery with EMC NetWorker Module for Microsoft Applications Release Technical Notes EMC Business Continuity for Microsoft Exchange 2007 Enterprise EMC CLARiiON CX3-80 Exchange 2007 Data Protection and Single Site Recovery Enabled by EMC Replication Manager and Exchange 2007 with SCR - Integration Guide EMC Business Continuity for Microsoft Exchange 2007 Enterprise EMC CLARiiON CX3-80 Exchange 2007 Data Protection and Single Site Recovery Enabled by EMC Replication Manager and Exchange 2007 with SCR - Integration Guide Third-party documents The following document is available on the Microsoft Technet website, which provides additional, relevant information on the tools used to validate and simulate an Exchange 2007 workload: Exchange Server 2007 LoadGen Simulator 13

14 Chapter 1: About this document Terminology Terms and definitions Term Building block Deduplication This section defines important terms used in this Proven Solution Guide. Definition Defines the number of spindles required to support the IOPS and the space requirements for a certain number of users per Exchange Server Identifies files that are inactive, compresses them, and then removes all duplicate copies. Deduplication has the potential to save customers significant amounts of storage capacity, including removing the redundant data from the daily backup process. Volume Shadow Copy Service (VSS) RAIN technology VSS is a technology included in Microsoft Windows that allows taking manual or automatic backup copies or snapshots of data, even if the data is locked, on a specific volume at a specific point in time over regular intervals. Redundant Array of Independent Nodes provides the means for the Avamar server to continue to operate even when a node fails. If a node fails, RAIN can be used to replace the failed node and reconstruct the data on the replacement node. In addition to providing failsafe redundancy, RAIN can also be used to rebalance the capacity across the nodes after the Avamar server has expanded the nodes. 14

15 Chapter 2: Exchange 2007 on CLARiiON Design Chapter 2: Exchange 2007 on CLARiiON Design Overview Introduction to Exchange 2007 on CLARiiON design Designing and implementing a storage layout for any solution is critical. Correcting errors made in the storage-system layout after the fact can be expensive and timeconsuming; therefore, doing it right the first time should be the primary goal. This chapter details the storage-system layout design process employed for this proven solution. The information provided here can be used as a starting point for designing and implementing a similar solution. The production Exchange 2007 spindle calculations and layout are described, as well as the local clone requirements and LUN placement. The design details and layout provided here can be used as a reference architecture for similar field campaigns. Contents This chapter contains the following topics: Topic Exchange 2007 design 16 See Page Storage design 18 15

16 Chapter 2: Exchange 2007 on CLARiiON Design Exchange 2007 design Exchange 2007 design considerations Before the spindle requirements can be calculated and the Exchange 2007 layout can be created, a number of essential questions need to be answered. The questions and answers are listed in the following table: Question Answer How many users in the environment? 8,000 What is the user profile? How long will the deleted items be retained? 0.48 IOPS per user and 350 MB mailbox 14 days What is the read/write ratio? 1:1 What kind of high-availability technology will be implemented for Exchange 2007 Mailbox Servers? How many Exchange 2007 Clustered Mailbox Servers are in the SCC or CCR? How many Exchange storage groups (ESGs) per server are there? How many Exchange databases (EDBs) per ESG are there? How many logs will be produced and how long will they be retained? What is the user concurrency? Both Exchange 2007 Single Copy Cluster (SCC) and Exchange 2007 Clustered Continuous Replication (CCR) are considered in this solution. 2 Clustered Mailbox Servers in a active/1 passive configuration Each CMS server will host 4,000 users spread across 8 Exchange storage groups (ESGs) 1 Mailbox database per ESG, with 500 users per mailbox database. 10 logs per day, per user 100 percent User profile types The values in the following table represent user profile definitions for Microsoft Exchange This data helped in determining the user profile used in this use case, which is a 0.48 (Very Heavy) profile. Send/receive per day approximately 50-kilobyte (KB) message size Exchange I/Os per second (cached mode) Database cache per user 5 sent/20 received MB 10 sent/40 received MB 20 sent/80 received MB 30 sent/120 received MB 16

17 Chapter 2: Exchange 2007 on CLARiiON Design Note The data presented in the table above is referenced from the Microsoft article Exchange 2007 Planning Storage Configurations - Mailbox Server Storage Design. Exchange design layout In an effort to create as realistic a user environment as possible, two domain controller servers are created to increase the availability. Two Exchange 2007 HUB/CAS servers are deployed for high availability and load balancing, in addition to two Exchange CCR servers and two Exchange SCC servers. The IP network is provided by Cisco Catalyst 3560Es, and the Fibre Channel (FC) SAN is managed through Cisco MDS 9509 FC switches. All the domain controllers and Exchange servers are built on Dell PowerEdge R710 servers (with 36 GB RAM and eight-core CPU). LoadGen clients are simulated from one VMware ESX 4.0 server farm with six Windows 2003 virtual machines. Exchange layout The following image illustrates the layout of the Exchange design. 17

18 Chapter 2: Exchange 2007 on CLARiiON Design Storage design Building block concept To make this Exchange 2007 solution scalable and useful to as many implementations as possible, the concept of an Exchange Server 2007 building block is introduced in this Proven Solution Guide. The building block approach defines the number of spindles required to support the IOPS and the space requirements for a certain number of users per Exchange Server After the requirements of the first server are calculated, you can add additional servers. Since this building block may not be appropriate for all environments, the concept should be helpful as a starting point for most medium-to-large implementations. To simplify the configuration process of similar environments that may be larger or smaller than the environment in this use case, the following server building blocks are used: 4,000 users per Exchange server 22 spindles per server for Exchange 2007 database and logs (16 for databases and six for logs) This spindle count represents the building block and the spindle created based on the questions listed in the Exchange 2007 design considerations section. For details about the validation and performance results of the building block, see the ESRP document on EMC.com and Microsoft.com. Building block scaling The server building block created for this solution is very flexible. See the following table for the details about building-block scaling. Number of heavy users Number of 15k spindles 2, spindles -- 8 DB 4 log 4, spindles DB 6 log 6, spindles DB 8 log 8, spindles DB 12 log 10, spindles DB 14 log 12, spindles DB 16 log 14, spindles DB 20 log 16, spindles DB 22 log 18, spindles DB 26 log 18

19 Chapter 2: Exchange 2007 on CLARiiON Design Building block characteristics The following table describes the characteristics of building blocks for each Exchange server in this solution. Item Quantity Number of users per server 4,000 Number of Exchange 2007 servers 1 IOPS per user 0.48 Read / Write ratio 1:1 Mailbox size 350 MB Number of disks required for databases 16 Number of disks required for logs 6 Disk type 6 x 300 GB 15k (logs) and 16 x 300 GB 15k (databases) RAID type 1/0 Best practices for storage design This topic lists the best practices that are associated with storage design layout for CLARiiON. These best practices form the basis of this solution environment. To determine the optimum storage design, consider the following: Determine the required number of IOPS that the storage system must support, including a factor for growth and local/remote replication. Determine the user profile, such as user count, user concurrency, user IOPS, mailbox size, and the read/write ratio of the I/O. Define customer response time service level agreements (SLAs) for common and unusual operations. Determine the local and remote recovery time objective (RTO) and recovery point objective (RPO). Determine the size of the database and log LUNs. Determine the number of clones. Determine the required size of the guest virtual machine OS drives for various farm roles, if needed. References EMC has a number of documents that identify recommendations and guidelines associated with the operation of EMC CLARiiON CX For a list of related documents, see the Prerequisites and supporting documentation section. 19

20 Chapter 2: Exchange 2007 on CLARiiON Design Storage design objectives The CLARiiON storage design focuses on the following objectives: Meet the user profile through setting performance and space requirements. Provide good utilization using the building block concept that can be easily understood and built upon. Minimize the time and complexity of designing a storage layout for Exchange 2007 on the CLARiiON storage. To meet these objectives, you need to analyze both the local and remote RPO and RTO and integrate the correct products into the solution. Storage system spindle design The following IOPS calculations are used to figure out the spindle requirements for a single server. When you calculate spindle requirements, spindle performance is one of the required parameters. The 300 GB 15k drives yield 180 IOPS per spindle when used in a random read/write environment such as Exchange RAID 1/0 groups are used for the production database and logs. Database spindle calculations Use the following calculation to determine the spindle requirements for the Exchange databases: (IOPS x %R) + WP(IOPS x %W) Physical Disk Speed = Required Physical Disks Parameter IOPS Meaning The number of input/output operations (I/Os per second) %R Percentage of I/Os that are reads WP RAID write penalty multiplier (RAID 1= 2, RAID 5= 4) %W Percentage of I/Os that are writes Log spindle calculations Use the following calculation to determine the spindle requirements for the Exchange logs: Database IOPS x 50% Physical Disk Speed = Required Physical Disks Database IOPS: The number of input/output operations per second. 20

21 Chapter 2: Exchange 2007 on CLARiiON Design Calculation examples Spindle requirements for the referenced solution: (1920 x 0.5) + 2 x (1920 x 0.5) 180 =16 Note 4,000 users (single server) x 0.48 IOPS =1,920 Spindle requirements for logs for the referenced solution: (1920 x 0.5) 180 =6 Exchange database space requirements The space requirement for a single database is calculated as below: (Individual Mailbox Size x User Count) x (Factor for Deletion Retention and white space) = Single Database Space Requirement In this use case, the figures are: (350 MB x 500 users) x (1 + 30%) = 230 GB (rounded up) Since another 10 percent of database size is reserved for content indexing, a single database requires 260 GB of space. Exchange log files space requirements Based on the user profile, each user generates 10 logs per day. If you keep log files for six days on the server, the total log file space required by each database is: (10 MB) x (500 users) x (6 days) = 30 GB Note In this solution, 50 GB capacity is allocated to each log LUN. Space requirement validation With eight ESGs per server at 260 GB, a total of 2,080 GB per server is required. The GB 15k database drives are configured into two RAID 1/0 (4+4) groups yielding 2,146 GB total capacity per server. This configuration yields over 96 percent utilization. High utilization like this is very cost-effective and energy-efficient. Since space is not a problem with the log LUNs, each of the eight database log LUNs is configured on six 300 GB 15k drives in one RAID 10 (3+3) group configuration, yielding capacity of more than 300 GB. Note Each Enterprise Exchange 2007 deployment has a number of factors that affect final spindle calculations. You should consider and test each of these factors. 21

22 Chapter 2: Exchange 2007 on CLARiiON Design Clone design For the VSS Hardware Provider to create a clone, one local clone copy is required on CLARiiON. The total database clone space required per server is 2,080 GB (260 GB x 8 = 2,080 GB). To accomplish the clone, ten 300 GB 15k drives are required per server for the database LUNs. The 10 spindles are configured into two (4+1) RAID_5 groups yielding 2,146 GB. The database clones are divided evenly among the two (4+1) RAID groups, yielding over 96 percent utilization. For the log LUNs, the total clone space required per server is 400 GB (50 GB x 8), and three 300 GB 15k drives are configured as the (2+1) RAID group, yielding 1,070 GB capacity. For the VSS Software Provider to create a snapshot, certain disk space should be reserved on the host to store the shadow copy data. In this solution, 10 GB of space is reserved for each volume, and a space of 160 GB (eight DB volumes and eight log volumes) is reserved in total. The SAS disks in RAID_1 that come with the Dell server are sufficient for the solution. RAID group layout design To spread the load as evenly as possible across the spindles, each RAID group for databases is configured to span two buses, with two enclosures within each bus. Each RAID group for logs is configured on different enclosures that reside on two buses. The RAID groups for clone LUNs are arranged on different buses from the source database LUNs. Spindle breakdown After you complete the calculations of production and clone spindles, the breakdown is determined. See the following table for detailed information. Configuration Drive and RAID type Number of disks Logs 300 GB 15k 18 Databases 300 GB 15k 48 Hot spares 300 GB 15k 2 Exchange 2007 clone 300 GB 15k 15 Total 300 GB 15k 83 22

23 Chapter 3: Application Design Chapter 3: Application Design Overview Introduction This chapter describes the aspects considered during the application design of the solution components, including NetWorker server and NMM design and Avamar design. Contents This chapter contains the following topics: Topic NetWorker server and NMM design 24 See Page Avamar design 34 23

24 Chapter 3: Application Design NetWorker server and NMM design Design considerations Before the NetWorker application layout can be created, the following essential questions need to be answered. Question How much data to be backed up? Answer 2.8 TB. How long to finish the backup? The backup window should be less than 12 hours. Less than eight hours is better. Which VSS technology should be used for backup? Is NetWorker Proxy client involved? What is the impact to the production environment? What kind of backup policy? What kind of retention policy? VSS Hardware Provider is used for Exchange SCC, and VSS Software Provider is used for Exchange CCR. NetWorker Proxy client is involved in the Exchange SCC backup, using VSS Hardware Provider. As minimum as possible. Daily full backups. The retention period is set to one week. VSS Providers overview The EMC NetWorker Module for Microsoft Applications (NMM) works with Microsoft Volume Shadow Copy Service (VSS) technology to provide snapshot backup and recovery services for file systems, applications, and the operating system. The supporting Windows VSS Providers fall into two categories: VSS Hardware Provider (used to back up the SCC configuration) VSS Software Provider (used to back up the CCR configuration). For detailed information about why and how VSS Providers are used in this solution, refer to the NMM design overview section. The default VSS Software Provider on a Windows platform is Microsoft Software Shadow Copy Service, which does not require any separate configuration for taking application backups. It coordinates the copy activities between the snap engines, applications, and hardware to produce uncorrupted snapshots of volumes. For information on how Volume Shadow Copy Service works on Windows 2008, refer to the Microsoft TechNet article at VSS Hardware Providers, which are used to back up the SCC configuration, allow you to create shadow copies at the hardware level, without imposing a load on the production server. For the purposes of VSS, the snapshot/clone is referred to as a shadow. Furthermore, an option to make the shadow transportable has been provided, which allows you to mount, or import the shadow on, another client. If a shadow is not marked as transportable, you will not be able to mount the shadow 24

25 Chapter 3: Application Design and perform rollback recovery. The transportable technology allows the data clone/snapshot to be mounted onto a non-production environment for backup tasks, such as consistency check, log truncation, and data deduplication. This simple fact has the following far-reaching consequences: The ability to control the lifetime of your data without affecting the performance of your existing servers The ability to manage multiple independent copies of your data volumes across several machines NMM design overview EMC has VSS Providers for Symmetrix, CLARiiON, and Celerra, coming with EMC Solutions Enabler. You can take hardware snapshots of these arrays using these specific providers, which become the default provider when installed. A VSS Hardware Provider has a higher precedence than a Microsoft Software Shadow copy provider. NMM will use the default hardware provider to create shadow copies. NMM also provides support for transportable shadow copies. It has the ability to "clone" images of your disks, and surface them later on a separate machine. This is done in real time, with no apparent impact on the production server. In this solution, the following factors are considered for the NMM backup design: Impact on the production environment (as low as possible) Capacity requirement (as low as possible) To minimize the impact on the production environment, EMC recommends that you use data clone and transportable technology so that the backup program reads data from clone LUNs mounted on a non-production client, rather than from a snapshot, which actually reads data from the production database LUNs. To minimize the capacity requirement, EMC recommends that you use snapshots that contain differential data only. Since Exchange CCR already retains two copies of Exchange mailbox data, and the passive node does not provide direct service to mailbox users, VSS Software Providers are used in this solution to take a snapshot on the passive node. The subsequent data verification and backup processing are also performed on the passive node. In this way, no additional disks for clone LUNs are required, and the impact to the production environment can be minimized. For Exchange SCC, since there is only one copy of the database, it is better to create a data clone for backup using VSS Hardware Providers to minimize the impact on the production environment. After that, transportable technology should be utilized to mount the clone to a NetWorker Proxy client for data verification and backup processing. 25

26 Chapter 3: Application Design NMM design for Exchange CCR The following image illustrates the NMM design for Exchange CCR. The VSS Software Provider technology is used for the Exchange CCR server. While performing a backup, Microsoft Volume Shadow Copy Service takes a software snapshot of the current database on the passive node. Then, the snapshot will be used for consistency check, log truncation, and deduplication calculation. All backup activities happen on the passive node, and the deduplicated data will be transferred from the passive node to the Avamar appliance through a LAN. 26

27 Chapter 3: Application Design NMM design for Exchange SCC The following image illustrates the NMM design for Exchange SCC. The VSS Hardware Provider and transportable shadow copy technology are used for the Exchange SCC server. While performing a backup, the database changes are updated on the clone LUNs on the storage level, with no impact to the production servers. After that, the clone LUNs will be mounted to the NetWorker Proxy client for consistency check, log truncation, and deduplication calculation. As a result, the deduplicated data will be transferred from the NetWorker Proxy client to the Avamar appliance through a LAN. 27

28 Chapter 3: Application Design Storage considerations for NMM For VSS Hardware Provider to create a clone, CLARiiON SnapView clone technology is used in this solution, which is also known as PLEX or split mirror by making a full copy of the selected volume. To create a clone, a target disk volume whose size is the same as that of the source volume is needed. You can configure any type of disks that CLARiiON supports as clone LUNs. In this solution, the same FC disks are configured. To ensure effective use of capacity, RAID 5 has been configured rather than RAID 10. For VSS Software Provider to create a snapshot, when the shadow copies are enabled on the volumes, they will reserve disk space to store the shadow copy data. In this solution, 3 GB of disk space is reserved by NMM for each volume without an upper limit. This means if there is too much data change, the reservation can be as large as the volume size. The 3 GB reservation should be enough for a normal backup procedure. However, since the online maintenance and database indexing may introduce additional data changes, EMC recommends that you reserve more disk space on the CCR passive node. An example would be 10 GB for each volume, and 160 GB (eight database volumes and eight log volumes) in total on the passive node. As there is no heavy workload against the reserved space, the SAS disks in RAID_1 that come with the Dell server are sufficient for the solution. Deduplication parallelism considerations To improve the deduplication performance, multiple backup and restore processes, which are called Nsravtar (avtar when using an Avamar client), will be started on the NetWorker client. According to the best practice, having four parallel processes of the NetWorker client is the most efficient way to do this. In this solution, each building block has four Exchange databases, which is a perfect fit for the default parallelism number. Note Under certain circumstances, you might need to manually control the parallelism number. You can adjust the parallelism using the Application information parameter NSR_PS_SAVE_PARALLELISM. For example, to start only one Nsravtar process for deduplication, add the following line to the Application information attribute of the client resource: NSR_PS_SAVE_PARALLELISM=1 Configuring Save Set To maximize the deduplication performance, the disk utilization should also be considered. You can configure the Save Set attribute of the client resource in order to spread the I/O across different building blocks and different storage processors as evenly as possible. You can specify the following value in the Save Set attribute to back up all databases on the Exchange server: APPLICATIONS:\Microsoft Exchange 2007 As a result, the database will be backed up sequentially, so the first storage group is #1, then the second storage group is #2, and so on. You can also specify individual storage groups for the backup with the following parameter: 28

29 Chapter 3: Application Design APPLICATIONS:\Microsoft Exchange Writer\Group_1 This enables you to control the backup order, so that I/O workload can be distributed as desired. In this solution, each Exchange server has two Exchange building blocks, and the deduplication parallelism is set to 4. This means that two database files are deduplicated simultaneously from each building block, with each database owned by a storage processor. The following table was used to determine the backup order. Backup Order Building Block Storage Processor A 1 Building Block 1 EXSCC_SG1 Storage Processor B 2 Building Block 2 EXSCC_SG6 3 Building Block 1 EXSCC_SG3 4 Building Block 2 EXSCC_SG8 5 Building Block 1 EXSCC_SG2 6 Building Block 2 EXSCC_SG5 7 Building Block 1 EXSCC_SG4 8 Building Block 2 EXSCC_SG7 Note During a backup process, the first four backup jobs are started simultaneously as the first batch. When a backup job is completed, the remaining backup jobs are then started based on the backup order. As a result, the following values will be specified in the Save Set attribute of the client resource: APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG1 APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG6 APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG3 APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG8 APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG2 APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG5 APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG4 APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG7 29

30 Chapter 3: Application Design Schedule considerations To design an optimal and well-performing backup job schedule for an Exchange 2007 user environment, you should consider the following: What is the backup window? What has the least impact on the production system? What will have as little impact on Exchange online maintenance (OLM) as possible? How to avoid disk contention? To accomplish this, the following factors should be taken into account when designing the backup schedule: Do not run Exchange online maintenance against an Exchange storage group (ESG) while its backup job is taking a snapshot/resyncing clone. Failure to follow this suggestion results in a large decrease in the clone resync speed and slowing of the OLM. Run the backup jobs off-hours whenever possible. Set the clone resync rate to high. Have the NetWorker Proxy client's HBAs zoned to different CLARiiON ports from those to which the production Exchange servers' HBAs are zoned. In this solution, the backup window lasts about five hours the backup job starts at 3 a.m. and ends around 8 a.m. This leaves another seven-hour window (8 p.m. 3 a.m.) for Exchange OLM. To spread the I/O workload, the following table is used to design the OLM schedule. Building Block Storage Processor A Storage Processor B OLM Schedule Building Block 1 Building Block 2 EXSCC_SG1 EXSCC_SG6 20: :00 Building Block 1 Building Block 2 EXSCC_SG3 EXSCC_SG8 21: :00 Building Block 1 Building Block 2 EXSCC_SG5 EXSCC_SG2 22: :00 Building Block 1 Building Block 2 EXSCC_SG7 EXSCC_SG4 23: :00 30

31 Chapter 3: Application Design Snapshot policy considerations EMC NetWorker provides preconfigured policies that can be used with NMM: Serverless Backup: A single snapshot is taken per day. The data is then backed up to traditional tape and the snapshot is deleted. Daily: Eight snapshots are taken in a single day. The data in the first snapshot is backed up to tape. Each snapshot has an expiration policy of 24 hours. Retaining the snapshot enables you to perform snapshot restore for the databases. The snapshot restore is much faster than conventional restore, which reads data from the backup media. The disadvantage of keeping a snapshot is that the disk space used by the snapshot will grow rapidly during daytime. For snapshot retention, no impact to disk space has been observed in this solution. EMC recommends that you use the Serverless Backup policy for the Exchange CCR backup because performing the snapshot restore for the Exchange CCR database recovery is not always necessary. In the event that the database files are corrupted on active node, the Exchange server will fail over to the passive node, and database re-seeding will be carried out to recover the corrupted database. For Exchange SCC, keeping the clone mounted on the NetWorker Proxy client does not have any side effects in this solution. In the event that the database files are corrupted on the active node, snapshot restore can be performed to restore the database in a timely manner. The default Daily policy does not meet the requirement as it retains eight snapshots for a single day. In this solution, a new snapshot policy was created to retain only one clone per day. For detailed information about configuring the snapshot policy, refer to Supporting Documentation: Installation and Configuration > Task 3: Configure a backup pool, schedules, snapshot policy, and privileges. Client cache files When deduplicating data, the NetWorker client (Nsravtar.exe) loads two cache files, file cache and hash cache, into memory, in order to: Reduce the amount of time required for the whole procedure Reduce the load on the servers where NetWorker clients are installed Reduce the load on the Avamar server File cache The file cache (f_cache.dat) stores a 20-byte SHA-1 hash of the file attributes, and is used to quickly identify which files have previously been backed up to the Avamar server. This cache file is extremely helpful when backing up file servers, as it screens out approximately 98 percent of the files on a daily basis. By default, the file cache could consume up to 1/8th of the physical RAM on the NetWorker client. For example, if the client has 4 GB of RAM, the file cache will be limited to 4 GB/8, or 512 MB maximum. Meanwhile, the file cache doubles in size each time it needs to grow. The current file cache sizes are grown to the value as listed in the following table. 5.5 MB 11 MB 22 MB 44 MB 88 MB 176 MB 352 MB 704 MB 1408 MB 31

32 Chapter 3: Application Design To figure out how much space should be reserved for the file cache, use the following formula: (File Count x 40 MB) / 1,000,000 = Minimum File Cache Size Required Then, check the next available increment in the table. Example: (100,000 x 40 MB) / 1,000,000 = 4 MB => Next increment is 5.5 MB Hash cache The hash cache (p_cache.dat) stores the hashes of the chunks and composites that have been sent to the Avamar server. The hash cache is used to quickly identify which chunks or composites have previously been backed up to the Avamar server. It is very important when backing up databases. By default, the hash cache could consume up to 1/16th of the physical RAM on the NetWorker client. For example, if the client has 4 GB of RAM, the hash cache will be limited to 4 GB/16, or 256 MB maximum. The hash cache also doubles in size each time it needs to grow. The current hash cache sizes are grown to the value as listed in the following table. 24 MB 48 MB 96 MB 192 MB 384 MB 768 MB 1536 MB To figure out how much space should be reserved for the hash cache, use the following formula: (DB Size x 20 MB)/(Chunk Size x 1,000,000) = Minimum Hash Cache Size Required Then, check the next available increment in the table. Note For Exchange database files, the chunk size is 16 KB. For others, use 24 KB for the chunk size. Example: (175 GB x 20 MB) / (16 KB x 1,000,000) = MB => Next increment is 384 MB. Disk space considerations for cache files Control the Maximum Cache Size You can override the default limits on the size of the file and hash caches by using the following two options: --filecachemax=value --hashcachemax=value Where VALUE is an amount in MB or a fraction (negative value = fraction of RAM). In this solution, the default values are: 32

33 Chapter 3: Application Design --filecachemax=-8 --hashcachemax=-16 To apply the parameters, simply create the nsravtar.cmd file at the directory C:\Program Files\legato\nsr\dedup on the backup client. Then, add the parameters line by line in the file. The parameters will be read and applied once the NMM client is invoked for backup. In this solution, the file count (database files plus log files) for daily full backups is no more than 100,000, which means the default 1/8th of the physical RAM (36 GB) is good enough. For the Exchange databases, each database file size is about 175 GB and needs at least MB for hash cache. It does not mean that one Exchange server only needs x 8 = 1,750 MB disk space to store the cache files. You should also take into account the factor of deduplication parallelism, as the deduplication client process will use separate cache files. In this solution, the eight Exchange databases are dispatched to four Nsravtar processes for deduplication as the parallelism is set to 4. Each process handles two database files. The hash cache size for each process should be 768 MB. Therefore, one Exchange server needs 768 x 4 = 3,072 MB disk space for hash cache files. Note The hash cache size of 768 MB is calculated through the following formula: (175 GB x 2 x 20 MB) / (16 KB x 1,000,000) = MB => Next increment is 768 MB Best practices and recommendations The following are the best practices and recommendations to follow when configuring NMM: Perform a full backup of the Exchange server after every successful recovery. Ensure that all databases in a specified storage group are mounted before backing up the application servers. Unmounted databases are not backed up. Perform a full backup copy after upgrading to NMM from previous releases of NetWorker clients. Ensure that database files and transaction log files reside on separate volumes for Exchange backup, otherwise the backup will fail. If a rollback restore is performed, ensure that this volume is not in use. 33