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

EMC Backup and Recovery for Microsoft Exchange 2007

Enabled by EMC CLARiiON, EMC

NetWorker, and EMC Avamar

Proven Solution Guide

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

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

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 .................................................................................................................. 10 Validated environment profile ........................................................................................................ 11 Hardware and software resources ................................................................................................. 11 Prerequisites and supporting documentation ................................................................................ 13 Terminology ................................................................................................................................... 14

Chapter 2: Exchange 2007 on CLARiiON Design .................................................................................. 15 Overview ........................................................................................................................................ 15 Exchange 2007 design................................................................................................................... 16 Storage design ............................................................................................................................... 18

Chapter 3: Application Design ................................................................................................................ 23 Overview ........................................................................................................................................ 23 NetWorker server and NMM design ............................................................................................... 24 Avamar design ............................................................................................................................... 34

Chapter 4: Testing and Validation ........................................................................................................... 38 Overview ........................................................................................................................................ 38 Methodology ................................................................................................................................... 39 Testing tools ................................................................................................................................... 39 Test results summary ..................................................................................................................... 41

Chapter 5: Conclusion ............................................................................................................................. 51 Overview ........................................................................................................................................ 51

Supporting Information: Installation and Configuration ........................................................................... 52 Overview ........................................................................................................................................ 52 Task 1: Install and configure NetWorker NMM on Exchange servers ........................................... 53 Task 2: Install and configure the NetWorker Proxy client .............................................................. 55 Task 3: Configure a backup pool, schedules, snapshot policy, and privileges.............................. 56 Task 4: Configure a backup client and group in NetWorker .......................................................... 58 Task 5: Integrate Avamar Data Store with NetWorker ................................................................... 62

Chapter 1: About this document


4


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 See Page

Audience and purpose 5

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



5

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.



6

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.



7

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 e-mail, 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: • http://technet.microsoft.com/en-us/exchange/bb412164.aspx (Microsoft ESRP) • http://www.emc.com/collateral/hardware/white-papers/h5662-cx4-480-ccr-stor-

solut-esrp.pdf (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 2007. 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

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

http://www.emc.com/collateral/hardware/white-papers/h5662-cx4-480-ccr-stor-solut-esrp.pdf�

http://www.emc.com/collateral/hardware/white-papers/h5662-cx4-480-ccr-stor-solut-esrp.pdf�



8

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.



9

Objectives

Overview The following table lists the objectives of this solution:

Objective Details

Backup and restore with NetWorker NMM

Use NMM to back up and restore Exchange databases. The tests will involve initial full backup, daily full backups, snapshot restore, and conventional restore.

Validate the deduplication function through Avamar

This use case focuses on the source-based (Avamar) deduplication. Performance data will be investigated.

Validate NetWorker NMM with hardware VSS

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.

Validate NetWorker NMM with software VSS

NetWorker NMM will use software VSS on the passive node of the Exchange CCR for database backup.



10

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.



11

Validated environment profile

Profile characteristics

The solution was validated with the following environment profile.

Profile characteristic Value

Number of Exchange 2007 Users 8,000

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_10, 300 GB, 15k rpm FC disk

RAID Type for Clone 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® 29 • 48 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 E5530 @ 2.4 GHz • 36 GB RAM, 3 x 4-port NICs



12

• 2 dual-port, 4 Gb/s Emulex HBAs

Exchange Hub and CAS Servers

2 Dell PowerEdge R710 • 2-socket quad-core, Intel Xeon E5530 @ 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 E5530 @ 2.4 GHz • 36 GB RAM, 3 x 4-port NICs

NetWorker Server 1 Dell PowerEdge 6850 • 4-socket quad-core, Intel Xeon CPU @ 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 E5530 @ 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 E7450 @ 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 6.5.2.3

EMC PowerPath® 5.3

Emulex driver 7.2.20.6

VMware ESX server 4.0

Microsoft LoadGen 2007 8.2.45



13

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 2.2 - 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



14

Terminology

Terms and definitions

This section defines important terms used in this Proven Solution Guide.

Term Definition

Building block Defines the number of spindles required to support the IOPS and the space requirements for a certain number of users per Exchange Server 2007.

Deduplication 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)

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.

RAIN technology 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.

Chapter 2: Exchange 2007 on CLARiiON Design


15


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 time-consuming; 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 See Page

Exchange 2007 design 16

Storage design 18



16

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? 0.48 IOPS per user and 350 MB mailbox

How long will the deleted items be retained?

14 days

What is the read/write ratio? 1:1

What kind of high-availability technology will be implemented for Exchange 2007 Mailbox Servers?

Both Exchange 2007 Single Copy Cluster (SCC) and Exchange 2007 Clustered Continuous Replication (CCR) are considered in this solution.

How many Exchange 2007 Clustered Mailbox Servers are in the SCC or CCR?

2 Clustered Mailbox Servers in a active/1 passive configuration

How many Exchange storage groups (ESGs) per server are there?

Each CMS server will host 4,000 users spread across 8 Exchange storage groups (ESGs)

How many Exchange databases (EDBs) per ESG are there?

1 Mailbox database per ESG, with 500 users per mailbox database.

How many logs will be produced and how long will they be retained?

10 logs per day, per user

What is the user concurrency? 100 percent

User profile types

The values in the following table represent user profile definitions for Microsoft Exchange 2007. 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 0.11 2 MB

10 sent/40 received 0.18 3.5 MB





17

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.



18

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 2007. 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,000 12 spindles -- 8 DB 4 log



8,000 44 spindles -- 32 DB 12 log

10,000 54 spindles -- 40 DB 14 log

12,000 64 spindles -- 48 DB 16 log

14,000 76 spindles -- 56 DB 20 log

16,000 86 spindles -- 64 DB 22 log

18,000 96 spindles -- 72 DB 26 log



19

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 CX4-480. For a list of related documents, see the “Prerequisites and supporting documentation” section.



20

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 2007. 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) = Required Physical Disks Physical Disk Speed

Parameter Meaning

IOPS 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% = Required Physical Disks Physical Disk Speed Database IOPS: The number of input/output operations per second.



21

Calculation examples Spindle requirements for the referenced solution:

(1920 x 0.5) + 2 x (1920 x 0.5) =16 180 Note 4,000 users (single server) x 0.48 IOPS =1,920

Spindle requirements for logs for the referenced solution: (1920 x 0.5) =6 180

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 16 300 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.



22

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

Chapter 3: Application Design


23


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.


Topic See Page

NetWorker server and NMM design 24

Avamar design 34



24

NetWorker server and NMM design

Design considerations

Before the NetWorker application layout can be created, the following essential questions need to be answered.

Question Answer

How much data to be backed up? 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?

VSS Hardware Provider is used for Exchange SCC, and VSS Software Provider is used for Exchange CCR.

Is NetWorker Proxy client involved?

NetWorker Proxy client is involved in the Exchange SCC backup, using VSS Hardware Provider.

What is the impact to the production environment?

As minimum as possible.

What kind of backup policy? Daily full backups.

What kind of retention policy? 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 http://technet.microsoft.com/en-us/library/ee923636(WS.10).aspx. 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

http://technet.microsoft.com/en-us/library/ee923636(WS.10).aspx�

http://technet.microsoft.com/en-us/library/ee923636(WS.10).aspx�



25

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.



26

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.



27

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.



28

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:



29

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

Storage Processor B

1 Building Block 1 EXSCC_SG1







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



30

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 EXSCC_SG1 20:00 -- 0:00

Building Block 2 EXSCC_SG6









31

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



32

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) = 218.75 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:



33

--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 218.75 MB for hash cache. It does not mean that one Exchange server only needs 218.75 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) = 437.5 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.



34

Avamar design

Avamar overview

An Avamar system is a client/server network backup and restore solution consisting of one or more Avamar servers and the network servers or desktop clients that back up data to those servers. The primary building block in any Avamar server is a “node.” Each node is a self-contained rack-mountable network-addressable computer that runs Avamar server software on the Linux operating system. Nodes can also contain internal storage in the form of hard disk drives. In this solution, two kinds of nodes are introduced: • Utility node: A node dedicated to scheduling and managing background Avamar

server jobs. In scalable multi-node Avamar servers, a single utility node provides essential internal services for the server (Management Console Server (MCS), cron job, External authentication, Network Time Protocol (NTP), and Web access). Since utility nodes are dedicated to running these essential services, they cannot be used to store backups.

• Storage nodes: Nodes that store the actual backup data. Multiple storage nodes

are configured with multi-node Avamar servers based upon performance and capacity requirements. Storage nodes can be added to an Avamar server over time to expand performance with no downtime required. Avamar clients connect directly with Avamar storage nodes; client connections and data are load balanced across storage nodes.

Avamar system availability considerations and design

To ensure the long-term reliability, availability, and supportability of the Avamar server, it is recommended to use the following main redundancy methods for maintaining data integrity for Avamar. • Configuring RAID_5 internal SAS disks on the Avamar storage nodes to protect

the system from disk failures. • Enabling the unique Avamar Redundant Array of Independent Nodes (RAIN)

technology on the multi-node Avamar server to protect the system from single-node failure.

• Including an active node when deploying a RAIN configuration to minimize the Avamar system downtime.

• Efficiently replicating data from one Avamar server to another on a scheduled basis to ensure complete data recovery if the primary backup Avamar server is lost.

In this solution, the RAID and RAIN technologies are adopted to protect the Avamar server, while the method of replicating data is not being implemented. Meanwhile, to maximize the storage capacity of the appliance, no spare node is configured in the Avamar server for this solution.



35

Avamar capacity considerations

It is important to understand how Avamar uses and manages its capacity, and some key points should be considered for an Avamar capacity design.

Calculating writeable capacity Since Avamar uses the RAID and RAIN technologies to protect data, the capacity available for the actual backup is less than the raw capacity. In this solution, each Avamar node has six 300 GB SAS disks attached, so that the raw size of each storage node is approximately 1,610 GB (268 GB x 6). RAID 5 reduces the raw capacity to 1,340 GB per storage node. Meanwhile, by default, the Avamar server puts a 65 percent read-only limit on each node. As a result, five storage nodes total can provide a writeable capacity of about 4.3 TB.

Capacity usage Typically, the Avamar server is filled up rapidly for the first few weeks when it starts the backup operations. Its capacity then reaches a steady state shortly after the longest retention period for the backups. The steady state is a point where the expiring subfile hashes being deleted from the grid roughly equal the number of new bytes added during the regular client backups.

The capacity usage has an impact on the Avamar server in terms of performance. You are recommended to restrict the storage capacity usage to 80 percent of the Storage Subsystem (GSAN) capacity.

Avamar capacity design

When designing the Avamar capacity, make sure the data from the initial full backup and daily full backups (daily full backup data times retention period) does not exceed 80 percent of the GSAN capacity (4.3 TB x 0.8 = 3.44 TB in this solution). In this solution, a total of 2.8 TB data needs to be backed up. As the deduplication ratio for the initial full backup can reach 72 percent, the size of the deduplicated data is about 2.02 TB. RAIN technology requires 25 percent disk space for the redundancy of the deduplicated data (2.02 TB x 25 percent). Therefore, the initial full backup uses a disk space of 2.53 TB. Since 80 percent of the GSAN capacity is 3.44 TB, 0.91 TB of free space will be left for the subsequent daily full backups. In the tests, the deduplication ratio for the daily full backups can reach 97 percent, which means only 84 GB of deduplicated data is transferred to the Avamar grid. Plus with 25 percent additional consumption by RAIN, each daily full backup will use 105 GB of disk space. The 0.91 TB free space allows the Avamar server to retain the backup for one week. Note In this solution, the Avamar Data Store grid is integrated with NetWorker, so the retention time is configured on NetWorker. To maximize Avamar backup capacity, do one or both of the following: • Reduce the backup retention period • Add more nodes to the Avamar server



36

Schedule considerations

During the planning and design stage, properly scheduling activities throughout the day is one of the most important factors that influence the system reliability, availability, and supportability. The Avamar server maintenance cron jobs such as Checkpoint, Garbage Collect, and Hfscheck should be properly scheduled to avoid overlapping with the daily backup windows. For detailed information, refer to the EMC Avamar 4.1 System Administration Manual.

Schedule design

Below is the schedule designed for this solution: • 9 a.m. through 9 p.m.: 12-hour maintenance window for cron jobs. No backup

occurs during this period.

• 3 a.m. through 8 a.m.: 5-hour backup window for daily full backups.

Note Since the initial full backup takes about 15 hours, EMC recommends that you choose the setting “Always allow overtime” for the backup client. For detailed information, refer to the EMC Avamar 4.1 System Administration Manual.

Performance tuning considerations

Enabling multi-threads to optimize backup and restore performance Since the Avamar Data Store grid is integrated with NetWorker as a deduplication node, the NMM client, instead of the Avamar client, is installed on the Exchange server or the NetWorker Proxy client to conduct daily backups to the Avamar Data Store grid. This allows using multiple Nsravtar processes on the NMM client for both backup and recovery operations to achieve performance improvements.

Tuning client caches to optimize backup performance To speed up the backup process, the hashcacheMax parameter is used in this solution. For detailed information about the parameter, refer to Application Design > NetWorker server and NMM design > Disk space considerations for cache files.

Configuring Avamar Integration with NetWorker

In this solution, Avamar is integrated with the NetWorker software as a deduplication storage node. Therefore, the backup and restore operations can be executed from NetWorker instead of from Avamar; however, you still need to use Avamar Administrator Console and Avamar Enterprise Manager Web Console to monitor the Avamar system and the daily backup activities and to obtain the deduplication ratio from each backup. Although settings in Avamar still take effect, EMC recommends that you set all parameters using the NetWorker Console.

Avamar Data Store grid configuration In the test environment of this solution, 4.3 TB of storage is available to perform the



37

backup operations. The six-node Avamar grid is comprised of one utility node and five storage nodes with RAIN enabled. Note No spare node is configured in this solution although it is recommended due to high-availability considerations. This does not impact the testing results of this solution.

Chapter 4: Testing and Validation


38


Overview

Introduction This chapter describes the design validation and the performance results for this

solution. The NMM backup/restore features were validated under different scenarios and performance was measured. An EMC Avamar Data Store appliance is used for data deduplication. Microsoft LoadGen is used to simulate the Exchange 2007 client load and submit data changes to Exchange servers on a daily basis. After that, a daily full backup test was performed to validate the solution design.


Topic See Page

Methodology 39

Testing tools 39

Test results summary 41



39

Methodology

Purpose The testing purposes for this solution are to:

• Validate the NMM backup and restore features, collaborating with an EMC Avamar

grid • Validate the backup window and the data deduplication ratio • Validate disk performance throughout the backup/restore process • Validate the impact to the production environment, such as CPU, memory, and

network usage • Identify any bottleneck that might interfere with the backup/restore performance

Testing scenarios

The following testing scenarios are designed and implemented for this solution.

Scenario Description

1 Initial full backup of Exchange mailbox databases

2 Second full backup of Exchange mailbox databases without LoadGen

3 Daily full backups of Exchange mailbox databases with LoadGen running for eight hours per day

4 Data recovery

5 Scalability test

Testing tools

Overview of testing tools

Microsoft LoadGen 2007 is used to validate and test the solution design against the solution environment. The tool is used to generate mailbox databases, simulate client load, and create a realistic environment for testing. The Microsoft Outlook MAPI protocol is used during the simulation. The LoadGen clients require a fully deployed Exchange 2007 environment with configured Exchange 2007 HUB and CAS server roles. For additional information on LoadGen deployment, visit http://technet.microsoft.com/en-us/library/bb508893.aspx.

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



40

Load simulation

To test the full solution under as realistic a load as possible, Microsoft's LoadGen tool was used to simulate an 8,000-user Exchange 2007 workload. After generating the mailbox databases, LoadGen was started at 9 a.m. every day, running an eight-hour load simulation against Exchange servers. Throughout the day, the database would be changing. LoadGen was able to simulate as closely as possible 8,000 Very Heavy Exchange 2007 users sending, receiving, and deleting mail. The LoadGen profile used for the testing was Very Heavy, which is equal to 0.48 IOPS per user. With the above simulation, NetWorker NMM’s backup job was started to perform a daily full backup against the current databases in the evening. The following table shows the LoadGen profile parameters used for the daily load simulation.

Parameter Value

Total Simulated User Number 8,000

Users per Exchange 2007 Server 4,000

Mailbox Size 350 MB

User Profile 0.48 (Very Heavy)

LoadGen Simulation Duration 8 hours

Task Simulated Per User 178

Simulated Outlook Client Outlook 2007 Cache mode

LoadGen Client (VM) Number 6



41

Test results summary

Introduction This section summarizes the test results of different test scenarios.

Scenario 1: Initial backup of Exchange mailbox database

The initial full backup is different from the subsequent full backups as there is no data patent cached on the Avamar appliance. The NetWorker clients have to scan the whole database file, segment the data, calculate the hash value, and transfer the deduplicated data to the Avamar grid. Therefore, the initial full backup against one database would take a much longer time than a subsequent full backup would. For the same reason, the deduplication ratio is lower than that of the subsequent full backups.

For the initial full backup, Avamar nodes are capable of deduplicated data at the rate of 200 GB per hour. During the testing, it took around 15 hours to back up the 2.8 TB data, including about 1 hour for a database consistency check. The following table depicts the test results of Scenario 1. The deduplication ratio for the initial full backup is 27 percent, which means about 2.04 TB (2.8 TB x 0.73) deduplicated data was transferred to Avamar grid through the LAN.

Note The deduplication ratios in this solution are based on data generated from LoadGen. Results obtained in a real environment may vary. The following charts depict the performance counters for Avamar Disk Writes (#/sec) and NetWorker (Kb/sec), which were kept at stable levels throughout the initial full backup.



42

Through monitoring the disk performance, the same behaviors for both clone LUNs and CCR passive node database LUNs are observed. In the first 70 minutes, the disk I/Os have reached as high as 750 IOPS for each LUN. The reason is that NetWorker NMM has to perform a consistency check against all database files simultaneously. After that, database files were deduplicated by Nsravtar processes four by four, as the default parallelism is set to 4 to ensure the best performance. During the deduplication, the I/O throughput is not as high as in the Consistency Check phase.

The following table lists the performance data collected from Exchange mailbox servers and the NetWorker Proxy client in order to measure the impact to the production environment during the initial full backup. Both the Exchange SCC active node and Exchange CCR active node are not affected during the initial full backup. The data deduplication only consumes resources on the Exchange CCR passive node and the NetWorker Proxy client.



43

% Processor Time

Memory Usage (by nsravtar.exe)

Network Usage (MB/sec)

EXSCC-1 0.37 0 0

NWKPRXY 13.06 around 4 GB 20

EXCCR-1 0.297 0 0

EXCCR-2 13.6 around 4 GB 20 The following chart shows the memory usage of the Nsravtar processes on the NetWorker Proxy client.

Note The memory usage increases during data deduplication, in which an Nsravtar process always doubles its current size in memory usage until it reaches approximately 1 GB.



44

Scenario 2: Second full backup of Exchange mailbox databases without LoadGen

In the test, the second full backup is run after the initial full backup to verify any performance differences. A huge improvement has been observed in terms of the backup window. The 2.8 TB of data was backed up within only 4.5 hours, including 70 minutes for a database consistency check. As there is no data change since the initial full backup, the deduplication ratio reached almost 100 percent. The following image shows the test result of Scenario 2.

Note Although LoadGen is not included, the database files still changed during the 15 hours of the initial full backup. This is why the deduplication process has to scan the whole database again, rather than bypassing the files. Another difference is that the backup programs take more resources from the CCR passive node and the Proxy client. From the following table, you can see an obvious increase in CPU usage as against the table in Scenario 1.

% Processor Time

Memory Usage (by Nsravtar.exe)

Network Usage (MB/sec)

EXSCC-1 0.8 0 0

NWKPRXY 36 around 4 GB 0

EXCCR-1 0.4 0 0

EXCCR-2 38 around 4 GB 0

Scenario 3: Daily full backups of Exchange mailbox databases with LoadGen running for 8 hours per day

To simulate the Exchange user activity during business hours (9 A.M. - 6 P.M.), LoadGen was configured to run eight-hour tests. During the test period, more than 1,428,000 Outlook tasks were executed by 8,000 Outlook 2007 clients in Cache mode and processed by the two Exchange 2007 servers. The majority of these tasks included:

• Reading and processing messages (~956,000) • Sending mail (~166,000) • Browsing contacts (~167,000)

During each test LoadGen simulated database changes and log creation. See the following table.

Number of Logs Size (in GB)

Per ESG 4,500 4.5

Per Server 36,000 36

Total per Run 72,000 72



45

For daily full backups, the maximum deduplication rate of each backup stream can be achieved as high as 180 GB per hour. With four backup streams initiated on each server, the 2.8 TB of data can be backed up within five hours, and the deduplication ratio can reach as high as 97 percent for each database, which means only 3 percent of net new bytes (about 850 MB) are transferred to Avamar grid for backup. The following image shows the test result of Scenario 3.

Note The deduplication ratios in this solution are based on data generated from LoadGen. Results obtained in a real environment may vary. Through monitoring the disk performance, the same behaviors for both clone LUNs and CCR passive node database LUNs are observed. In the first 70 minutes, because of the database consistency check, disk I/Os reached 750 IOPS for each LUN. After that, the database LUNs still have large I/O throughput, which indicates that the database files were scanned and deduplicated quickly.

The memory usage of this scenario is different from that of the initial full backup. The Nsravtar processes were allocated 4 GB of memory (1 GB for each process) at the beginning, because the processes have to read the hash cache file from the disk. Reading all the hash cache file into memory could speed up the deduplication progress. This explains why the daily full backups can be completed much faster.



46

The performance data from Exchange mailbox servers and the NetWorker Proxy client shows that the CPU usage was higher than that of the initial full backup. However, the network usage reduced significantly, which means that the deduplicated data transferred over the network is much less than a typical backup. The production environment was not impacted during the daily backup operations.

The following table lists the performance data collected from Exchange mailbox servers and the NetWorker Proxy client.

% Processor Time

Memory Usage (by Nsravtar.exe)

Network Usage (MB/s)

EXSCC-1 0.85 0 0

NWKPRXY 37.22 around 4 GB 2.9

EXCCR-1 0.42 0 0

EXCCR-2 39.32 around 4 GB 3.37



47

Scenario 4: Data restore

The following data recovery methods are validated in the solution tests:

Snapshot restore Data is restored from either persistent snapshots or clone disks. In this solution, the clone LUNs are mounted to the NetWorker Proxy client, then NMM on the Proxy client is responsible for transferring data to the production environment through the LAN. After the data transfer completes, NMM on the production server can bring up the restored databases. The test results show that:

• The recovery speed for a single database can reach 200 GB per hour - the 175 GB

database files can be restored within 52 minutes. • Approximately 50 percent of the network bandwidth is utilized for the restore. • The snapshot restore consumes very little CPU and memory usage. The following chart illustrates the network usage between the Exchange SCC active node and the NetWorker Proxy client.

Conventional restore Data is restored from Avamar grids. The test results show that: • The recovery speed for a single database can reach 70 GB per hour with Avamar,

as compared to 48 GB per hour with the traditional single tape drive. In this instance, 175 GB database files are restored within 150 minutes.

• Approximately 12.5 percent of the network bandwidth is utilized for the restore. • The conventional restore also consumes very little CPU and memory usage. The following chart illustrates the network usage on the Exchange SCC active node.



48

Considering the scalability of Avamar, the performance will increase a lot if data can be restored to different servers. In this solution, the database restore to both Exchange servers simultaneously almost doubles the throughput of Avamar without increasing too much restore time. Refer to the following table for details.

Task Restored Data Size (GB)

Restore Speed (GB/hr)

Time (Min)

Single-DB Restore (175 GB) 175 70 150

Single-DB Restore (175 GB) on both servers simultaneously

350 120 175



49

Scenario 5: Scalability test

The scalability of the solution is also validated in the tests. Since the backup streams have little impact to the production environment (for example, network usage, CPU usage, and so on), the solution can be scaled up easily. The following test steps are designed and implemented for Scenario 5.

Step Action

1 Perform daily full backups for one building block (four databases) on Exchange CCR through the passive node

2 Perform daily full backups for one building block (four databases) on Exchange SCC through the proxy client

3 Run step 1 and 2 simultaneously

4 Perform daily full backups only for Exchange CCR (eight databases) through the passive node

5 Perform daily full backups only for Exchange SCC (eight databases) through the proxy client

The following image indicates that when the amount of backup data increased, the backup window did not increase a lot, as compared to the linear increase with the commonly used tape backup method.

Note The full backup time without Avamar in the table above is for the single tape drive. The scalability of Avamar nodes is another important factor to consider in this solution. Some simple tests were run against the Avamar grid that contains different Avamar nodes in order to measure the performance and capacity. The test results show that the performance of daily full backups was not affected regardless of the number of Avamar nodes. This is natural because daily full backups consume very little resources from the Avamar grid. However, for the initial full backup, the performance varied a lot.

Basically, the performance and the capacity are proportional to the number of Avamar nodes. The following table details information about the capacity and deduplication speed in this solution.



50

Size Capacity Maximum deduplication speed for the initial full backup

3-node 2.6 TB 128 GB/Hour

4-node 3.4 TB 200 GB/Hour

5-node 4.3 TB 226 GB/Hour The chart below illustrates that the more Avamar nodes you use, the higher capacity and deduplication rate you can get for the backup.

Chapter 5: Conclusion

Overview

Introduction Operating a high-performing enterprise class e-mail environment of over 8,000 users

with 2.8 TB of storage requires efficient and optimized backup and recovery operations. This Proven Solution Guide depicts a validated design using an EMC CLARiiON CX4-480 storage system, EMC NetWorker, and EMC Avamar.

Conclusion This proven solution provides technical recommendations and validated test results

for customers seeking a sound framework for a repeatable, high-performing backup solution that can be incorporated into existing IT environments. By implementing this solution, customers can expect one or more of the following results. • Reduced backup timeframes: Backing up 2.8 TB of data would take

approximately 30 hours with a traditional tape-based backup solution. However, this solution enables you to take only five hours for a nightly full backup. This is six times faster than traditional backup solutions.

• Reduced backup storage requirements: With the data deduplication ratio of 97 percent, only 3 percent of additional capacity is required on the Avamar grid during daily full backups, as compared to the traditional 100 percent backup storage capacity requirement.

• Reduced Exchange environment footprint: This solution uses the Exchange passive node and NetWorker Proxy client for data rollover to the Avamar nodes. In this way, there is almost no impact to the production environment for backup operations. In addition, network congestion can be minimized since only 4 percent of data is transferred through the network.

• Improved data protection: The Avamar system provides several levels of fault tolerance to protect the backup data. In this solution, RAID is configured to protect the system from disk failures, and RAIN protection is enabled in case of Avamar node failure.

Next steps With its integrated set of storage platforms, software and deduplication capabilities,

EMC can help to accelerate assessment, design, implementation, and management while lowering the implementation risks and costs of a backup and disaster recovery solution for a Microsoft Exchange 2007 environment. To learn more about this and other solutions contact an EMC representative or visit www.EMC.com/solutions/microsoft.

http://www.emc.com/solutions/microsoft�

Supporting Information: Installation and Configuration


52


Overview

Introduction This section provides procedures and guidelines for installing and configuring the

components that make up the validated solution, including: • EMC NetWorker • EMC NetWorker NMM • EMC Avamar Data Store The installation and configuration instructions presented in this section apply to the specific revision levels of components used during the development of this solution. Before attempting to implement any real-world solution based on this validated solution, you should gather the appropriate installation and configuration documentation for the revision levels of the hardware and software components planned in the solution. Version-specific release notes are especially important.

Contents This appendix contains the following topics:

Topic See Page

Task 1: Install and configure NetWorker NMM on Exchange servers

53

Task 2: Install and configure the NetWorker Proxy client 55

Task 3: Configure a backup pool, schedules, snapshot policy, and privileges

56

Task 4: Configure a backup client and group in NetWorker 58

Task 5: Integrate Avamar Data Store with NetWorker 62



53

Task 1: Install and configure NetWorker NMM on Exchange servers

Prerequisites Before you begin, make sure the following prerequisites are met:

• An EMC NetWorker server is installed and configured • EMC PowerPath is installed on Exchange servers • EMC Navisphere® Agent is installed on Exchange servers Note For detailed information on installing and configuring an EMC NetWorker server, refer to the NetWorker Release 7.5 Installation Guide.

Procedure The following topics describe the required steps to install and configure NMM on

Exchange servers. For detailed information, refer to the following documents: • EMC NetWorker Module for Microsoft Applications Release 2.2 Installation Guide • EMC NetWorker Module for Microsoft Applications Release 2.2 Administration

Guide

Installing and configuring VSS Hardware Provider

To install and configure VSS Hardware Provider (for Exchange SCC only), do the following:

Step Action

1 Download and install EMC Solutions Enabler with VSS.

2 Run the following command to verify that EMC VSS Provider has been registered and installed as a service: Vssadmin list providers

3 The output “EMC VSS Hardware Provider” should be displayed.

4 Run the following command to update the SYMCFG Authorization list: C:\Program Files\EMC\SYMCLI\bin\symcfg authorization add –host <CLARiiON IP> -user <CLARiiON UserName> -password <Corresponding Password>

5 Repeat step 4 for the other CLARiiON IP address.

6 Verify the SYMCFG Authorization with the following command. Both IP addresses should be displayed. C:\Program Files\EMC\SYMCLI\bin\symcfg auth list

7 Add the following line to the file CLARcnfg at C:\Program Files\EMC\SYMAPI\config\clarcnfg : <CX_Array_Name> <CX_SPA_IP> <CX_SPB_IP>

For example, APM00083503280 192.168.76.200 192.168.76.201



54

Installing and configuring Navisphere CLI

To install and configure EMC Navisphere CLI (for Exchange SCC only), do the following:

Step Action

1 Download and install Navisphere CLI with the normal steps.

2 In Windows, select Start > My Computer > Properties > Advanced > Environment Variables > System variables > Path.

3 Add the Navisphere CLI installation path to the PATH variable. For example, if Navisphere CLI was installed in C:\Program Files (x86)\EMC\Navisphere CLI, add this to the path.

4 Configure Navisphere security with the following naviseccli command: Navisecli -user USERNAME -scope 0 -address CX_IP_ADDR -addusersecurity

Where USERNAME is the admin account name, and CX_IP_ADDR is one of the CLARiiON IP addresses.

5 After running this command, enter the corresponding password.

6 Repeat step 5 for the other CLARiiON IP address.

Installing EMC Admsnap

For detailed information on installing EMC Admsnap (for Exchange SCC only), refer to the EMC SnapView and Admsnap Installation Guide.

Installing NetWorker NMM

For detailed instructions on installing EMC NetWorker NMM, refer to the EMC NetWorker Module for Microsoft Applications Release 2.2 Installation Guide.



55

Task 2: Install and configure the NetWorker Proxy client

Prerequisites Before you begin, make sure the following prerequisites are met:

• An EMC NetWorker server is installed and configured. • EMC PowerPath is installed on the NetWorker Proxy client. • EMC Navisphere Agent is installed on the NetWorker Proxy client. Note For detailed information on installing and configuring an EMC NetWorker server, refer to the NetWorker Release 7.5 Installation Guide.

Installing and configuring NMM on Exchange servers

To install and configure NMM on Exchange servers, do the following:

Step Action

1 Install the NetWorker Storage server. Note For detailed instructions, refer to the NetWorker Release 7.5 Installation Guide.

2 Install and configure VSS Hardware Provider (Refer to Step 1 in Task 1).

3 Install and configure Navisphere CLI (Refer to Step 2 in Task 1).

4 Install Admsnap (Refer to Step 3 in Task 1).

5 Install the Exchange 2007 Management Component.

6 Install NMM. For detailed instructions, refer to the EMC NetWorker Module for Microsoft Applications Release 2.2 Installation Guide.



56

Task 3: Configure a backup pool, schedules, snapshot policy, and privileges

Configuring a backup pool and privileges

To configure a backup pool, including device and label template, and privileges, refer to “Configuring a Scheduled Backup” in the EMC NetWorker Module for Microsoft Applications Release 2.2 Administration Guide.

Adding a backup schedule in NetWorker

To add a backup schedule in NetWorker, do the following:

Step Action

1 In the Administration window of the NetWorker Management Console, click Configuration.

2 In the expanded left pane, select Schedules.

3 From the File menu, select New.

4 Specify the Name as Full Every Day.

5 Set every day’s backup level to full, as shown below.

6 Click OK to confirm.



57

Adding a snapshot schedule in NetWorker

To add a backup schedule in NetWorker, do the following:

Step Action


2 In the expanded left pane, select Snapshot Policies.


4 Specify Once a Day as the Name.

5 Set the Number Of Snapshots to 1.

6 Set the Retain Snapshots to 1.

7 Select Day for Snapshot Expiration Policy.

8 Specify First for Backup Snapshots.

9 Click OK to confirm.



58

Task 4: Configure a backup client and group in NetWorker

Procedure The following topics describe the steps required to configure NetWorker NMM

backup groups and clients for Exchange servers.

Configuring groups

To configure groups for both Exchange SCC and Exchange CRR servers, do the following:

Step Action


2 In the expanded left pane, select Groups.


4 In the Name attribute, type a name for the backup group.

5 In the Comment attribute, type a description.

6 For the Start Time attribute, enter the time when the daily full backup to be executed.

7 For the Autostart attribute, select Enabled.

8 Click the Snapshot attribute so that a check mark appears beside it.

9 For the Snapshot Policy attribute, select Serverless Backup.

10 For the Snapshot Pool attribute, select a pool that was created for the snapshot.

11 Click the Advanced tab.

12 For the Interval attribute, specify how often a snapshot will be created. When performing daily backups, set the value to “24:00”.

13 Ensure that the Restart Window attribute value is less than or equal to the Interval attribute value.

14 Set the Client Retries attribute to 0 (zero).

15 Set the Inactivity Timeout attribute to more than 100. Note: This value should be larger than the consistency check time.

16 Click OK to create the backup group.

17 Repeat the above steps to create a backup group for the other Exchange server.



59

Configuring client resource for Exchange SCC

To configure client resource for the Exchange SCC server, do the following:

Step Action


2 In the expanded left pane, select Clients.


4 In the Name attribute, type the fully qualified domain name (FQDN) of the NetWorker client computer. Note The FQDN name should be the name for Exchange virtual server.

5 Select the Scheduled Backups attribute.

6 In the Save Set attribute, specify the components to be backed up. List them in specific order. For example, APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG1

APPLICATIONS:\Microsoft Exchange 2007\EXSCC_SG6







7 For the Group attribute, select the backup group to which this Client resource will be added.

8 For the Schedule attribute, select the backup schedule Full Every Day you just created.

9 Click the Apps & Modules tab.

10 In the Backup Command attribute, type the backup command: nsrsnap_vss_save.exe

11 In the Application Information attribute, enter the following values: NSR_SNAP_TYPE=vss

NSR_ALT_PATH=C:\Mount_Replica\

NSR_DATA_MOVER=nwkprxy.shex.gsc.emc.com

NSR_DM_PORT=6728

NSR_ESE_UTIL_SEQUENTIAL=false

NSR_ESE_UTIL_THROTTLE=true

NSR_ESE_THROTTLE_IOS=1000

NSR_ESE_THROTTLE_DURATION=3000

12 Select the Deduplication checkbox.



60

13 Under the Globals (2 of 2) tab, fill in the NetBIOS names and FQDN names of both Exchange cluster nodes for Remote access.

14 In the Storage nodes box, enter the FQDN name of the NetWorker Storage server.

15 Click OK.

Configuring a client resource for Exchange CCR

To configure a client resource for the Exchange CCR server and the Exchange CCR passive node, do the following:

Step Action

1 To configure a client resource for Exchange CCR server, follow the same steps in the topic “Configuring client resource for Exchange SCC”, except that: • In step 5, uncheck the Scheduled Backups attribute. • In step 11, enter the following values: NSR_SNAP_TYPE=vss






2 To configure a client resource for the Exchange CCR passive node, follow the same steps in the topic “Configuring client resource for Exchange SCC”, except that: • In step 4, enter the FQDN name of the Exchange passive node. • In step 11, enter the following values: NSR_SNAP_TYPE=vss



61


NSR_VIRT_SERV=exccr

NSR_INDEX_CLIENT=exccr





• In step 13, keep the Remote access box empty.



62

Task 5: Integrate Avamar Data Store with NetWorker

Prerequisites Make sure the following prerequisites are met before integrating Avamar Data Store

with the NetWorker server as a deduplication node: • An EMC NetWorker server is installed and configured. For detailed information on

installing and configuring an EMC NetWorker server, refer to the NetWorker Release 7.5 Installation Guide.

• An EMC Avamar Data Store grid appliance is installed and configured. For detailed information on installing and configuring an EMC Avamar Data Store grid appliance, refer to the EMC Avamar 4.1 Server Software Installation Manual.

Procedure The following topics describe the required steps to add the Avamar Data Store grid

into the NetWorker server as a deduplication node. Important This task requires operating system root privileges on the Avamar server utility node.

Installing the NetWorker client software

To install the NetWorker client software into the Avamar server utility node, do the following:

Step Action

1 Open a command shell and log in to the Avamar server utility node as the root user.

2 Obtain the NetWorker Linux Client software and upload it to the Avamar server utility node.

3 Install the NetWorker Linux client software in the default location: rpm -ivh --nodeps lgtoclnt-7.5-1.i686.rpm

4 Start the NetWorker daemons: /etc/init.d/networker start

5 Verify that the NetWorker daemons have been started: ps -ef | grep nsr

The nsrexecd daemon should be running.

Adding a NetWorker domain to the Avamar server

To add a NetWorker domain to the Avamar server, do the following:

Step Action

1 Start Avamar Administrator.

2 Select Navigation > Administration. The Administration window is displayed.

3 Click the Account Management tab.



63

4 In the tree, right-click the root domain and select New Domain… The New Domain dialog box is displayed.

5 Enter NetWorker as the new domain name, and click OK.

Configuring AFTD or file type devices

To configure the advanced file type devices (AFTD) or file type devices on local disks of Microsoft Windows servers and storage nodes, do the following:

Step Action

1 Create one directory for each disk (or partition) to be used for AFTD or file type devices.

2 In the Administration interface of the NetWorker server, click Devices.

3 Right-click Devices in the navigation tree, and select New. The Create Device window is displayed. Do the following in the new window: a. Replace the default name with the complete path address of the

directory that is created. b. Select the appropriate type from the drop-down Media type field.

For the AFTD file, select Adv_file. c. In the Status field, make sure that the Auto Media Management

feature for AFTD or file type devices is not enabled.



64

4 Click OK to continue.

5 Label and mount the device.

Creating a deduplication node

To create a deduplication node, do the following:

Step Action

1 In the Administration interface of the NetWorker server, click Devices.

2 Right-click De-duplication Nodes in the navigation tree, and select New. The Create De-duplication Node window is displayed.

3 Under the General tab, enter the fully qualified domain name or short name of the deduplication node (an Avamar server) in the Name field.

4 Enter the remote username MCUser and password MCUser1 for the Avamar server, that is, the deduplication node.

5 Click OK.



65

6 Configure a deduplication client as shown:

Documents

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