H8936: EMC Backup and Recovery for Microsoft … · EMC Backup and Recovery for Microsoft Exchange and SharePoint 2010 Servers 3 . EMC Avamar, EMC VNX, VMware vCenter . Table of contents

White Paper

EMC Solutions Group

Abstract

This white paper explains the testing and validation of the backup and recovery capabilities and benefits of EMC® Avamar™ in a virtualized Microsoft SharePoint 2010 and Microsoft Exchange Server 2010 environment on EMC VNX™.

March 2012

EMC BACKUP AND RECOVERY FOR MICROSOFT EXCHANGE AND SHAREPOINT 2010 SERVERS EMC Avamar, EMC VNX, VMware vCenter

• Improved multi-streaming backups with Avamar

• Backup space savings with deduplication

EMC Backup and Recovery for Microsoft Exchange and SharePoint 2010 Servers EMC Avamar, EMC VNX, VMware vCenter

2

Copyright © 2012 EMC Corporation. All Rights Reserved.

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

The information in this publication is provided “as is.” EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

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

VMware, ESX, ESXi, VMware vCenter, VMware vCenter Server, and VMware vSphere are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. All other trademarks used herein are the property of their respective owners.

Part Number: H8936

3 EMC Backup and Recovery for Microsoft Exchange and SharePoint 2010 Servers EMC Avamar, EMC VNX, VMware vCenter

Table of contents

Executive summary ............................................................................................................................. 6

Business case .................................................................................................................................. 6

Microsoft Exchange 2010 ............................................................................................................ 6

Microsoft SharePoint 2010 .......................................................................................................... 6

Solution overview ............................................................................................................................ 6

Key results ....................................................................................................................................... 7

Introduction ....................................................................................................................................... 8

Purpose ........................................................................................................................................... 8

Scope .............................................................................................................................................. 8

Audience.......................................................................................................................................... 8

Technology overview .......................................................................................................................... 9

Introduction ..................................................................................................................................... 9

EMC Avamar ..................................................................................................................................... 9

Application plug-ins .................................................................................................................... 9

EMC VNX .......................................................................................................................................... 9

VMware vCenter ............................................................................................................................. 10

VMware vCenter Server .............................................................................................................. 10

VMware vSphere ............................................................................................................................ 10

Kroll Ontrack PowerControls ........................................................................................................... 10

Configuration ................................................................................................................................... 11

Introduction ................................................................................................................................... 11

Physical environment ..................................................................................................................... 11

Hardware resources ....................................................................................................................... 12

Software resources ........................................................................................................................ 13

Disk layout ..................................................................................................................................... 14

Networking .................................................................................................................................... 15

Environment profile ........................................................................................................................ 16

Deployment ...................................................................................................................................... 17

Introduction ................................................................................................................................... 17

VNX5500 ....................................................................................................................................... 17

VMware vCenter Server .................................................................................................................. 17

VMware vSphere ............................................................................................................................ 17

Avamar .......................................................................................................................................... 17

Load balancer ................................................................................................................................ 18

Kroll Ontrack PowerControls ........................................................................................................... 18


4

Microsoft Exchange Server 2010 ...................................................................................................... 19

Introduction ................................................................................................................................... 19

Design ........................................................................................................................................... 19

Configuration ................................................................................................................................. 20

Jetstress validation ........................................................................................................................ 21

Microsoft SharePoint Server 2010 .................................................................................................... 23

Introduction ................................................................................................................................... 23

Design ........................................................................................................................................... 23

Test methodology .......................................................................................................................... 23

Configuration ................................................................................................................................. 23

Backup testing methodology ............................................................................................................ 25

Backup methodology ..................................................................................................................... 25

Data change rates explained .......................................................................................................... 25

Test types ...................................................................................................................................... 25

Initial baseline performance ...................................................................................................... 25

No data change and no load backup ......................................................................................... 25

Percentage data change with no load backup ............................................................................ 25

Same daily percentage data change with full user load backup ................................................. 26

Backup configuration ..................................................................................................................... 26

Exchange configuration ............................................................................................................. 26

SharePoint configuration ........................................................................................................... 28

Summary of test results .................................................................................................................... 31

Introduction ................................................................................................................................... 31

Summary charts and tables for backups and restores .................................................................... 31

Exchange backups .................................................................................................................... 31

SharePoint backups .................................................................................................................. 32

Exchange restores ..................................................................................................................... 32

SharePoint restores ................................................................................................................... 33

Deduplication measurements .................................................................................................... 34

Detailed observations .................................................................................................................... 34

Performance testing results ....................................................................................................... 34

Benefits ......................................................................................................................................... 35

Notes and recommendations ......................................................................................................... 36

Conclusion ....................................................................................................................................... 37

Summary ....................................................................................................................................... 37

Findings ......................................................................................................................................... 37


References ....................................................................................................................................... 39

White papers ................................................................................................................................. 39

Product documentation .................................................................................................................. 39

Appendix A: Detailed test results ...................................................................................................... 40

Baseline application performance testing ...................................................................................... 41

Introduction .............................................................................................................................. 41

Exchange 2010 Server ............................................................................................................... 41

SharePoint 2010 Server ............................................................................................................. 46

Avamar: Backup testing with no data change and no load .............................................................. 49

Introduction .............................................................................................................................. 49

SharePoint 2010 Server: Test results ......................................................................................... 49

Combined Avamar backup testing: With data change and without load ......................................... 51

Introduction .............................................................................................................................. 51

Exchange 2010 Server: Test results ........................................................................................... 51


Combined Avamar backup testing: With data change and load ...................................................... 54

Introduction .............................................................................................................................. 54



Avamar test results with encryption ............................................................................................... 62

Exchange ................................................................................................................................... 62

SharePoint ................................................................................................................................ 62

Avamar performance with encryption ........................................................................................ 62

Restore testing: Avamar Exchange native GLR restore .................................................................... 63

Introduction .............................................................................................................................. 63


Restore testing: Avamar/Exchange database recovery ................................................................... 64

Introduction .............................................................................................................................. 64


Restore testing: Avamar/ SharePoint VSS restore of site collection database ................................. 65

Introduction .............................................................................................................................. 65

Test results ................................................................................................................................ 65 Avamar restore testing: Kroll recovery of a site and single item in SharePoint ................................. 66

Introduction .............................................................................................................................. 66

List restore ................................................................................................................................ 66

Single-item restore .................................................................................................................... 68

Hardware load balancing ............................................................................................................... 69

Introduction .............................................................................................................................. 69

Test results ................................................................................................................................ 70


6

Executive summary

Data is one of the single most valuable assets a company can own. With the explosion in both the volume of data being retained and its speed of change, you are challenged to ensure constant access and protection against corruption or loss, either through hardware, environmental, or man-made disasters. The introduction of virtualization and the move to the cloud also further complicates this challenge.

Downtime can represent failure to critical business processes, which can effectively halt business operations and lead to lost revenue, regulatory fines, and, potentially, lost customers. The loss of even some megabytes of data in recovery can amount to hundreds and thousands of transactions lost, which affects businesses in terms of financial revenue, operational effectiveness, and legal obligation.

Microsoft often forms the foundation for today's most demanding, enterprise-level, transaction-based companies. Microsoft SharePoint Server and Exchange may be core platforms within the mission-critical framework for many businesses. Availability and recoverability become critical factors when designing the supporting IT infrastructure.

Microsoft Exchange 2010

Customers are striving to provide users with larger mailboxes while reducing their businesses' Exchange backup data storage requirements and complexity. With current trends, Exchange users' mailbox sizes are growing rapidly, thus making it more challenging, if not impossible, to back up all of the Exchange data within the nightly backup windows.

Microsoft SharePoint 2010

SharePoint collaboration is an integral part of many businesses. Designing and building a database infrastructure that supports this collaboration and protects the data is a major challenge.

SharePoint is always on and accessed by users. At the same time, users store more and more data. In many cases, it is not acceptable to take the SharePoint application and its databases offline for nightly backups. If you require a restore, it must happen quickly with minimum impact to users.

This solution offers an efficient approach to protect Microsoft Exchange 2010 and Microsoft SharePoint 2010 on a physical or virtualized environment. This solution uses a virtualized environment.

EMC® Avamar™ provides comprehensive backup and recovery for Microsoft environments by using Avamar 6.0 Volume Shadow Copy Services (VSS) agent. This solution tests and validates Avamar and provides recommendations and best practices for using Avamar to back up Microsoft Exchange and SharePoint based on the test results.

Avamar multi-streaming is highlighted, which enables higher throughput of backups.

Business case

Solution overview


Benefits of the solution for Exchange and SharePoint are:

• Enables a rapid yet application-consistent backup and restore using Microsoft VSS framework.

• Enables fast recovery to support strict recovery time objectives (RTOs) for databases and single items without requiring a slow item-level based backup.

• Significantly reduces backup windows and backup-storage footprints by using Avamar client-side data deduplication to only store unique daily changes, while always maintaining daily full backups for immediate single-step restore.

• Provides easy management by using one Avamar GUI for Avamar backups.

• Provides hardware load balancing that introduces redundancy to SharePoint and improves SharePoint farm performance.

Key results


8

Introduction

This white paper documents the testing and validation of backup, deduplication, and restore processes for Microsoft Exchange Server 2010 and Microsoft SharePoint 2010 using Avamar and EMC VNX5500™ in a virtualized server environment, enabled by VMware® vSphere™ 5.0.

This solution shows the new multi-streaming support of the Avamar agents to enable higher throughput of backups. For Microsoft Exchange, VSS copies of passive availability group (PAG) databases were used to offload backup from active databases. For Microsoft SharePoint, VSS copies of the SharePoint farm databases were used.

This use case shows the performance of backups and restores to the Avamar grid. Testing of this scenario provides best practices.

The solution was also tested for backup and recovery, and deduplication performance aspects, with a focus on backup and recovery throughput and timing to showcase the ability to meet RPO and RTO requirements.

This white paper is intended for EMC employees, partners, and customers with an interest in backup and recovery for Microsoft environments. Readers should already be familiar with Microsoft Exchange and Microsoft SharePoint technologies and EMC backup and recovery services.

Purpose

Scope

Audience


Technology overview

This chapter provides an overview of the primary technologies used in this solution:

• EMC Avamar

• EMC VNX5500

• VMware vCenter Server™

• VMware vSphere

• Kroll Ontrack PowerControls

EMC Avamar enables fast, efficient backup and recovery by reducing the size of backup data at the client—before it is transferred across the network and stored. Avamar’s data deduplication dramatically reduces network traffic by only sending unique blocks over the LAN/WAN. Blocks that were previously stored are never backed up again. This means huge savings in bandwidth for backup, a lot less disk storage needed on the back end, and very fast backups—often as much as ten times faster.

Avamar backups can be quickly recovered in just one step—eliminating the hassle of restoring full and subsequent incremental backups to reach the desired recovery point. The backup data is encrypted during transit across the network and at rest for added security.

Application plug-ins

For tight integration with your Microsoft applications, EMC offers the following Avamar application plug-ins:

• EMC Avamar plug-in for Exchange VSS—Delivers backup and recovery with data deduplication for Microsoft Exchange Server. Supports granular recovery of individual mailboxes, folders, or messages.

• EMC Avamar plug-in for SharePoint VSS—Provides backup and recovery with data deduplication for Microsoft SharePoint. Achieves granular recovery for SharePoint objects such as Web applications, sites, and calendars.

The EMC VNX family delivers industry-leading innovation and enterprise capabilities for file, block, and object storage in a scalable, easy-to-use solution. This storage platform combines powerful and flexible hardware with an advanced efficiency, management, and protection software to meet the demanding needs of today's businesses.

The VNX series is designed to meet the high-performance, high-scalability requirements of midsize and large businesses.

The VNX array model used in this solution is VNX5500. While the VNX5500 is selected, this solution also applies to EMC VNX5300™, EMC VNX5700™ and EMC VNX7500™ models.

Introduction

EMC Avamar

EMC VNX


10

You can simplify your IT management with VMware vCenter virtualization and cloud management solutions. vCenter solutions help you accelerate IT service delivery, transform operational efficiency, automatically assure compliance, and reduce business risks.

VMware vCenter Server

By using VMware vCenter Server, key elements like hosts, clusters, resource pools, datastores, networks, and virtual machines can be viewed, configured, and managed. vCenter Server aggregates physical resources from multiple ESX/ESXi hosts and presents a central collection of simple and flexible resources for you to provision to virtual machines in the virtual environment.

vCenter Server has the following characteristics:

• Centralized management

• Operational automation

• Secure access control

• Availability and resource management

• High levels of security

• Automated energy efficiency

VMware vSphere uses the power of virtualization to transform datacenters into simplified cloud computing infrastructures, and enables IT organizations to deliver flexible and reliable IT services. vSphere virtualizes and aggregates the underlying physical hardware resources across multiple systems and provides pools of virtual resources to the datacenter.

As a cloud operating system, vSphere manages large collections of infrastructure (such as CPUs, storage, and networking) as a seamless and dynamic operating environment, and also manages the complexity of a datacenter.

Kroll Ontrack PowerControls software enables you to quickly and easily find, recover, and restore granular SharePoint content, such as documents, lists, libraries, and folders, or entire SharePoint sites, from full Avamar backups.

VMware vCenter

VMware vSphere

Kroll Ontrack PowerControls


Configuration

This solution shows how a customer can back up and restore applications, Microsoft Exchange Server 2010, and Microsoft SharePoint 2010, using EMC Avamar application plug-ins for Exchange and SharePoint.

Performance results are shown for the Avamar grid as backup targets.

The solution is configured as follows:

• All the virtual machines use VNX5500 for disk storage and management. The virtual machines are split between the ESX servers.

• EMC used converged networking such as Fibre Channel over Ethernet (FCoE) to significantly reduce the connectivity complexity and port count for this solution, from server to VNX storage connectivity. The platform, optimized for virtual environments, is designed within open industry-standard technologies and aims to reduce the total cost of ownership (TCO) and increase business agility. The system integrates a low-latency, lossless, 10-gigabit Ethernet (GbE) unified network fabric with enterprise-class, x86-architecture servers.

• Avamar is used for backup and restore, and Kroll Ontrack is used to perform granular restores for SharePoint. The Avamar plug-in for Exchange VSS includes a granular level recovery (GLR) feature that enables recovery of mailboxes, folders, and mail messages.

• A hardware load balancer is used between the client load and the web front-ends (WFEs) for SharePoint load testing.

Figure 1 shows the overall physical architecture of the solution.

Introduction

Physical environment


12

Figure 1. Physical architecture

The hardware used to validate the solution is listed in Table 1.

Table 1. Hardware

Equipment Used for Quantity Configuration

ESX Servers VMware, Exchange, SharePoint

2 • 256 GB of RAM

• 32-core

• 146 GB RAID 5 internal hard disk drives (HDD)

Management servers

VMware vCenter server 1 • 16 GB of RAM

• Dual-core

EMC VNX5500 VMWare virtual machines, Exchange databases and logs, SharePoint content databases and logs

1 • Exchange – NL-SAS

• SharePoint – SAS

Hardware resources


Equipment Used for Quantity Configuration

EMC Avamar Backup of SharePoint and Exchange databases

1 • Gen 4, 6-node

• OS version 6.0 SP1

The software used to validate the solution is listed in Table 2.

Table 2. Software

Software Version

Microsoft Windows Server 2008 R2 Enterprise Edition

Microsoft Exchange Server 2010 SP1 Enterprise Edition

Microsoft SharePoint Server 2010 Enterprise Edition

Microsoft SQL Server 2008 R2 Enterprise Edition

EMC Avamar Windows Client 6.0 SP1

EMC Avamar Windows Exchange VSS Plug-in 6.0 SP1

EMC Avamar Windows Exchange GLR Plug-in 6.0 SP1

EMC Avamar Windows SharePoint VSS Plug-in 6.0 SP1

Kroll Ontrack PowerControls 6.1

VMware vSphere 4.1

Software resources


14

Figure 2 shows the disk layout for the solution.

Figure 2. VNX disk layout

As Figure 2 shows, the first enclosure 0_0 was not used. Two 8+8 RAID 1/0 storage pools were used for the Exchange databases. The Exchange logs were on two 1+1 RAID 1/0 storage pools.

The boot LUNs for all the virtual machines were on a five-disk 4+1 RAID 5 storage pool.

The SharePoint ContentDB data and log LUNs were on an nine-disk 8+1 storage pool, while the TempDB and SearchDB LUNs were on a 2+2 RAID 1/0 storage pool.

Disk layout


Figure 3 shows the network layout of the solution.

Figure 3. Network layout

At the time of this solution testing, Avamar supported 1 Gb network interfaces. Figure 3 shows how EMC used a 1/10 Gb switch to connect Avamar to the 10 Gb FCoE network. Since each Avamar node had a 1 Gb connection to the network, multi-streaming allowed Avamar to use several nodes at once; therefore, multiple 1 Gb network connections at once. The network was not a bottleneck in any of EMC’s tests.

EMC attached the VNX5500 and ESX servers to the 10 Gb FCoE network.

Client load was generated from the 1 Gb network in the same way it would in a normal production environment. The client load used a public network to connect to the virtual machines on the ESX servers.

The Avamar nodes used a separate backup network to do backups and restores.

Networking


16

This solution was validated with the environment profile listed in Table 3.

Table 3. Environment profiles

Application Requirements Quantity/Type/Size

Exchange

Server 2010

Exchange mailbox count total

(2,500 per active server)

5,000

Exchange mailbox size 1.5 GB

Exchange User profile 150 messages sent/received per day (0.15 IOPS per user)

Exchange—Availability DAG

Disk type and RAID configuration 2 TB NL-SAS–7.2k RAID 1/0

SharePoint

Server

SharePoint—Total user count 6,000

SharePoint—Total data 2.5 TB

SharePoint—Max content DB size 200 GB

SharePoint—Number of ContentDBs 14

SharePoint—Document size range 200 k to 2 MB

SharePoint—Total site collection count 14

SharePoint—Size per site About 10 GB

SharePoint—Sites per site collection 3–10

SharePoint—Total site count 200

SharePoint—Usage profile(s) (%browse/% search/%modify)

80%/10%/10%

SharePoint—User concurrency 10%

Disk type 600 GB SAS–10k RAID 5

Environment profile


Deployment

This chapter describes the deployment of the hardware and software used in this solution:

• VNX5500

• VMware vCenter Server

• Avamar

• Load balancer

• Kroll Ontrack PowerControls

VNX5500 was configured with eight 100 GB Flash drives, fifty-seven 600 GB SAS drives, and forty-five 2 TB NL-SAS drives. The drives were split between two buses. The Flash drives were not used for this use case. Two front-end ports per storage processor (SP) were connected to the FCoE network.

vCenter Server was installed on a management server and used to manage the ESX servers, and provision and manage virtual machines for Exchange and SharePoint.

For high availability of the virtual machines across the ESX servers, VMware high availability (HA) with vMotion was configured and enabled in vCenter Server.

vSphere was used as a platform to which virtual machines for Exchange and SharePoint were provisioned.

Avamar was deployed with one utility node and five storage nodes. Each Avamar node had dual internal network connections and an external network connection. The external network connections were split between two network switches. This layout has an additional external switch, which is the only difference to the layout shown in Figure 4.

Introduction

VNX5500

VMware vCenter Server

VMware vSphere

Avamar


18

Figure 4. Avamar deployment

A hardware load balancer was used for the load balancing testing. This was configured to accept requests for the WFEs and then to split the requests equally between them.

Kroll Ontrack PowerControls was installed on the Avamar front-end server (lightly utilized SharePoint application server) to do SharePoint granular restores. Kroll Ontrack PowerControls is able to extract items from the raw database files. This saves time as well as the extra space required by doing a full restore of the database to another SQL Server and then extracting the items.

Load balancer

Kroll Ontrack PowerControls


Microsoft Exchange Server 2010 In this solution, the Exchange organization consists of two mailbox servers and two client access and hub transport servers. High availability is provided through the use of the database availability group (DAG). Within a DAG, a set of mailbox servers performs continuous database replication through the use of host-based log shipping, to provide automatic database recovery in the event of failures. In this solution, each database is deployed with two DAG copies on two Exchange Server 2010 mailbox servers.

Due to the many variables and diversities between different organizations, sizing and configuring storage for use with Microsoft Exchange Server 2010 can be a complicated process. One of the methods used to simplify the sizing and configuration of storage for use with Exchange Server 2010 is to define a unit of measure—a building block.

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

• Specific user profile type

• Mailbox size

• Disk requirements

Using the building block approach helps to remove much of the guesswork required to simplify the implementation of the Exchange Server 2010 mailbox server. After the initial building block is designed, it can easily be reproduced and scaled to support the required number of total users in the organization.

Your Exchange administrators can now create building blocks that are based on your company’s specific requirements for the Exchange environment. This approach is very helpful when you expect future growth, because it makes scalability of the Exchange environment much easier and more straightforward.

EMC’s best practices involving the building-block approach for Exchange Server design have proven to be very successful throughout many customer implementations.

For more information about the building block calculation, refer to Microsoft Exchange Server 2010 Performance Review Using the EMC VNX5300 Unified Storage Platform—An Architectural Overview.

Table 4 and Table 5 show the user profile and building block used in this solution.

Table 4. User profile

User profile characteristic Value

Number of users supported 5,000 users

User profile supported 150 messages sent/received per day (0.15 IOPS per user)

Introduction

Design


20

User profile characteristic Value

Read/write ratio 3:2

Number of mailbox servers 2

Number of DAG copies 2

Mailbox size 1.5 GB

Table 5. Building block

Building block Value

User count per server 5,000 (2,500 active users, 2,500 passive users)

Number of databases per server 10 (5 active, 5 passive)

User count per database 500

Database LUN size 1.4 TB

RAID type and disks required (database LUN)

RAID 1/0 (16 x 2 TB NL-SAS drives) in a storage pool

Log LUN size 72 GB

RAID type and disks required (log LUN) RAID 1/0 (2 x 2 TB NL-SAS drives)

In this solution, the first client access server also acts as the file share witness. To remove a single point of failure, the virtual machines of the two mailbox servers and the two client access and hub transport servers are hosted on different ESX hosts.

The virtual machine and LUN configurations are shown in Table 6 and Table 7.

Table 6. Virtual machine configurations

Virtual machine Quantity CPU RAM (GB)

Mailbox server 2 6 36

Hub/client access servers combination

2 4 16

Table 7. LUN configurations

Virtual machine Role Quantity LUN size (GB)

Storage pools File system type

Mailbox server Boot 1 100 SAS 600 GB RAID 5 4+1 (shared pool)

VMFS

Mount point 1 10 SAS 600 GB RAID 5 4+1 (shared pool)

RDM

Database 10 1,400 2 TB NL-SAS RAID 1/0 RDM

Log 10 72 2 TB NL-SAS RAID 1/0 RDM

Configuration


Virtual machine Role Quantity LUN size (GB)

Storage pools File system type

Hub/client access servers combination

Boot 1 100 SAS 600 GB RAID 5 4+1 VMFS

You should validate Exchange 2010 storage design for expected transactional I/O per second (IOPS) before it is placed in a production environment. To ensure that the environment functions appropriately, EMC recommends that the Microsoft Jetstress tool is used to validate the Exchange storage design.

The Jetstress tool simulates Exchange I/O at the database level by interacting directly with the Extensible Storage Engine (ESE) database technology (also known as Jet) on which Exchange is built.

You can configure Jetstress to test the maximum I/O throughput available to the disk subsystem within the required performance constraints of Exchange. Jetstress can accept a simulated profile of specific user counts and IOPS per user to validate that the disk subsystem is capable of maintaining an acceptable performance level by the metrics defined in that profile.

The 64-bit version of Jetstress 2010 can be downloaded from the Microsoft Download Center.

In this solution, EMC used Jetstress version 14.01.0225.017 to simulate an I/O profile of 0.15 IOPS per user. EMC validated the building blocks using a two-hour performance test.

Table 8 and Table 9 show the average I/O and the average latency on the mailbox server. The performance meets the design target.

Table 8. I/O and latency for mailbox server (database)

Database I/O Target values Achieved values

Achieved transactional IOPS (I/O database reads/sec + I/O database writes/sec)

750 (5,000 x 0.15) 755.6

I/O database reads/sec N/A 459.8

I/O database writes/sec N/A 295.8

I/O database reads average latency (ms)

Less than 20 ms 17.9

I/O database writes average latency (ms)

This counter is not a good indicator for client latency because database writes are asynchronous

2.3

Jetstress validation

http://www.microsoft.com/download/en/details.aspx?id=4167�



22

Table 9. I/O and latency for mailbox server (transaction log)

Transaction log I/O Target values Achieved values

I/O log writes/sec N/A 251.9

I/O log writes average latency (ms) Less than 10 ms 0.9

Total I/O Target values Achieved values

(DB+Logs+BDM+Replication)/sec N/A 1168.7


Microsoft SharePoint Server 2010 In this solution, the SharePoint farm consists of a Microsoft SQL Database Server, an application server for central administration, two WFEs, and one crawl/query server.

The SharePoint farm is designed to support a specific number of users at a certain concurrency. It is designed with SharePoint best practices in mind, the only change being the use of SAS storage pools for all SharePoint components. EMC used storage pools instead of RAID groups for all LUNs.

The design is based on the best practices provided in EMC Virtual Infrastructure for Microsoft SharePoint Server 2010 Enabled by EMC CLARiiON and VMware vSphere 4—A Detailed Review.

EMC used Microsoft Visual Studio Team System (VSTS) to simulate the load on the SharePoint farm. A client load emulation tool was used to ensure that the SharePoint farm was operating at the optimal performance level.

All users adhered to a Microsoft heavy-user profile, which specifies 60 requests per hour. A think time of zero percent was applied to all tests. “Zero percent think time” is the elimination of typical user decision-making time when browsing, searching, or modifying data using Microsoft Office SharePoint Server. Every user request is completed from start to finish without a pause, which generates a continuous workload on the system.

The maximum user capacity is derived from the following formula:

# = seconds per hour/RPH/Concurrency_percent*RPS Example: 3,600/60/1 percent*12=72,000 Example: 3,600/60/10 percent*12=7,200 (supported user capacity for 10 percent concurrency)

The response times for each organization are detailed in Table 10.

Table 10. Response times

Test type Action Percent Mix Response time

Browse User browse 80 Less than 3 seconds

Search Unique value search

10 Less than 3 seconds

Modify Browse and metadata modify

10 Less than 3 seconds

The SharePoint farm consists of 14 site collections, with three to ten sites each, for a total of 100 sites. Each site contains different numbers and sizes of documents for a total of 2.5 TB of documents for all sites combined.

Introduction

Design

Test methodology

Configuration


24

The virtual machine and LUN configurations are shown in Table 11, Table 12, and Table 13.

Table 11. SharePoint virtual machine configuration

Virtual machine Quantity CPUs RAM (GB)

SQL Server 1 8 32

WFE 2 4 4

Crawl/Query 1 4 8

Application 1 4 4

Table 12. SharePoint LUN configuration

Virtual machine

Role Quantity VMFS disk sizes

LUN sizes

Storage pools

SQL Server Boot 1 50 1 TB (shared)

SAS 600 GB RAID 5 4+1

ContentDBs

CDB Logs

SP Config

SQL Internal

14

1

1

1

100-250

10-30

100

10

1.5 TB

1.5 TB

500 GB


TempDB Data

TempDB Log

SearchDB

SearchDB Log

1

1

1

1

100

10

350

35

1 TB SAS 600 GB RAID 1/0 2+2

WFE Boot 6 50 1 TB (shared)


Crawl/Query Boot

Index

2

2

50

100

1 TB (shared)


Application Boot 1 50 1 TB (shared)


Table 13. Number of ContentDBs per LUN

LUN Number of ContentDBs

ContentDBs_1 6

ContentDBs_2 5

ContentDBs_3 3


Backup testing methodology

EMC ran a full initial backup before backup testing to Avamar. This simulates the initial backup that customers would have to do when they first back up an environment to Avamar. The backup times for these initial backups are not relevant to EMC’s testing because they are not the day-to-day backup operations that would happen in an organization.

When a backup to Avamar runs, the Avamar client separates the data into segments and calculates a hash for each segment. These hashes are then checked against existing hashes on the Avamar grid. If the hash already exists, then it is not backed up. This is client-side deduplication.

During testing, EMC used a specific rate of data change against the Exchange and SharePoint databases, 3 percent for Exchange and 10 percent for SharePoint. These parameters were accurately defined in the load tools used for the testing.

Application data change rate in Exchange or SharePoint is not that same as the data change rate that is reported by Avamar. Avamar compares every segment of the changed data file and only copies the changed segment of any data file and not the whole data file. When a 2 MB file is modified in SharePoint, it does not mean the whole file has changed; Avamar only backs up the changed segments.

In this solution, an Exchange data change rate of 3 percent equates to a 1.5 percent data change rate for Avamar, and a SharePoint data change rate of 10 percent equates to an 8 percent data change rate in Avamar.

Initial baseline performance

EMC’s initial test was a baseline performance test to establish a baseline for comparison with subsequent backup tests. EMC wanted to compare the impact of backups on application performance.

For more details on the baseline performance test, see Baseline application performance testing.

No data change and no load backup

EMC then did a backup test where there was no data change and no load. This gave a baseline backup result that EMC could compare to other backup tests. Even though there is no data change, there are still time, CPU, IOPS, and processing costs related to the segmenting and hashing functions.

Percentage data change with no load backup

The next test was a percentage data change with no load. For SharePoint this was approximately 10 percent, and for Exchange this was approximately 3 percent. This test simulated a customer environment where backups would take place daily during a backup window with no user load.

Backup methodology

Data change rates explained

Test types


26

Same daily percentage data change with full user load backup

The final backup test was the same daily percentage data change but with full user load. This test simulated backups run after a data change rate of 10 percent for SharePoint and 3 percent for Exchange. This scenario might apply to customers who have no downtime window for backups, for example, customers who need to operate 24 hours a day but still want to do daily backups.

On-demand backups were used due to the test schedule, with a retention policy of No end date. Encryption was set to "none" apart from the specific encryption test that was run.

Exchange configuration

In order to get optimized backup performance, Exchange backup was configured as follows:

• Exchange 2010 was configured with a DAG, which contains two Exchange servers with the mailbox role installed.

• Exchange backups were performed on passive database copies from both mailbox servers.

• Each database was placed on two separate disks—one disk for the database file and one disk for the transaction logs.

• Each database was roughly the same size.

• Six backup streams were specified in each backup job.

Figure 5 shows the Avamar backup GUI with only passive database copies selected.

Figure 5. Selecting an Exchange Information Store for backup

Backup configuration


Figure 6 shows the Backup Options window with the default setting for backup set to “Always” to backup all selected databases.

Figure 6. Setting backup options for Exchange

Alternatively, you can select all databases and change Set when backup occurs on clustered or DAG systems to “Replica (passive) writer only”. Selecting this option means you do not have to determine which databases are passive and you do not have to individually select them for backup; the passive databases are automatically selected and backed up by the program.

The maximum of six backup streams were chosen to back up the targets in parallel. Consistency checking was disabled when simulating daily backups because this was a DAG configuration and Exchange 2010 has internal database integrity checking. As a best practice, EMC recommends that you enable consistency checks on a weekly basis.

Note Improved internal database integrity checking in Exchange 2010 reduces the likelihood that any database corruption will be included in backup images. This reduces the need to take a database offline to perform consistency checking by using the CHKSGFILES API or the ESEUTIL application. For more details, refer to the Microsoft Library Exchange Server 2010 SP1 Backup and Restore SDK.

http://msdn.microsoft.com/en-us/library/dd877010.aspx�

http://msdn.microsoft.com/en-us/library/dd877010.aspx�


28

SharePoint configuration

In order to get optimized backup performance, SharePoint backup was configured as follows:

• EMC used the Multi-stream by database backup option with the maximum of six streams selected.

• The Windows SharePoint VSS plug-in provided VSS backup and recovery of SharePoint and discovered components.

• Database sizes ranged from 70 GB to 200 GB.

• Windows SharePoint GLR plug-in provided support for granular-level recovery of SharePoint items when used in conjunction with a supported third-party recovery tool.

Figure 7 shows the Avamar backup GUI where a SharePoint farm VSS backup is selected. The tce-sp-app-01 server is the Avamar front-end server. When the farm is selected, Avamar VSS automatically selects the SharePoint instance on the SQL Server as well as the Search Service Application.

Figure 7. Selecting a SharePoint farm for backup


Figure 8 shows backup options where you can set the retention period as well as the encryption method, if required.

Figure 8. Setting backup options for SharePoint


30

Figure 9 shows SharePoint VSS backup options where you can choose to select multiple targets and set the maximum number of backup streams. You can also choose how you want to group the backup components, either by database or by volume. In this solution, we grouped by database.

Figure 9. Windows SharePoint VSS-specific backup options


Summary of test results

These results show the comparative backup and restore times and deduplication rates based on EMC’s tests.

For more detailed information on the testing and validation done for this solution, see Appendix A: Detailed test results

Exchange backups

As Figure 10 shows, an Exchange backup to Avamar is running at a rate of 174 MB/s with data change and no load, and at a rate of 142 MB/s with data change and load. This speed is because of Avamar’s client-side deduplication as well at its multi-streaming capabilities. For Exchange, EMC did not test for No data change and no load backup.

Figure 10. Exchange backups 3.4 TB per server (hours)

Note During all backup test scenarios, eight vCPUs and 48 GB RAM were allocated on both Microsoft Exchange mailbox servers and the Microsoft SQL Server. This is the minimum recommendation for Avamar multi-streaming.

05:26

06:40

AV data change no load (174 MB/s)

AV data change and load (142 MB/s)

Introduction

Summary charts and tables for backups and restores


32

SharePoint backups

As Figure 11 shows, SharePoint backups to Avamar are running at a rate of 176 MB/s with no data change and no load. The rate decrease for data change and no load to 140 MB/s because of the new data that has to be compared and backed up.

The rate decreases to 113 MB/s for data change with load because less CPU is available from the SQL Server under load.

Figure 11. SharePoint backups 2.5 TB (hours)

Exchange restores

Figure 12 shows the Exchange database restores from Avamar. For GLR restore, the limiting factor is the Exchange application programming interface (API) retrieving individual mail items, rather than the network.

04:15

05:22

06:40

AV No data change no load (176 MB/s)

AV data change no load (140 MB/s)

AV data change and load (113 MB/s)


Figure 12. Exchange restore times (hours)

SharePoint restores

Figure 13 shows the SharePoint restores from Avamar. For SharePoint granular restores, most of the restore time is taken up by Kroll Ontrack PowerControls reading the ContentDB and log files necessary for the granular restore.

Figure 13. SharePoint restore times (hours)

AV single DB restore (679GB) 35 MB/s

AV GLR single mailbox restore (832MB)

Restore Times 05:22 01:05

00:00

01:12

02:24

03:36

04:48

06:00

Hou

rs

AV DB restore (70

GB) 38 MB/s

AV list restore (1520 items)

Kroll restore

time from AvFS

AV single file restore

Kroll restore

time from AvFS

Restore Times 00:31 02:02 02:00 00:10 00:08

00:00

00:14

00:28

00:43

00:57

01:12

01:26

01:40

01:55

02:09

Hou

rs


34

Deduplication measurements

Figure 14 shows the deduplicated data size for Avamar backups in GB. This example is based on the SharePoint backups. For the first full backup, the data was deduplicated by 49.56 percent. For the No data change backup, deduplication was 99.98 percent. For the Data change backup, deduplication was 92.07 percent. The Data change and load backup deduplication was 92.67 percent.

Figure 14. Avamar deduplication for backups (GB)

Performance testing results

EMC made the following observations during and after testing.

Application workload • The Exchange environment supported 5,000 users at 150 messages per day

• The SharePoint farm supported 6,000 users at 10 percent concurrency

• Hardware load balancing improved SharePoint performance by 3 percent

Backup • No data change no load backup:

2.6 TB of SharePoint data to Avamar took 4 hours and 15 minutes

• Data change no load backup (1.5 percent Exchange, 8 percent SharePoint data change):

6.9 TB of Exchange data to Avamar took 5 hours and 26 minutes


• Data change with load backup (2 percent Exchange, 10 percent SharePoint data change):

6.9 TB of Exchange data to Avamar took 6 hours and 40 minutes


2464.18 2500.3 2520.45 2520.65

1242.87

0.47 199.18 184.69

First Full backup No data change backup

Data change backup Data Change and load

Data size Data size with deduplication

Detailed observations


Restores from Avamar Exchange single database restore of 679 GB took 5 hours and 22 minutes

Exchange mailbox restore of 832 MB took 1 hour and 5 minutes

SharePoint database restore of 70 GB took 31 minutes

List restore of 1,520 SharePoint items took 2 hours and 2 minutes

Single file SharePoint restore took 10 minutes

Deduplication rates • Deduplication rate for first full backup to Avamar:

Exchange was 1.67:1

SharePoint was 1.98:1

• Deduplication rate for incremental backups to Avamar:

Exchange was 81:1 for a 3 percent data change rate

SharePoint was 12.61:1 for a 10 percent data change rate

Based on the testing results, these are the main benefits of this solution.

Reduce backup time through Avamar multi-streaming Backing up terabytes of data took a long time with a traditional, tape-based, backup solution. For example, when backing up 6.4 TB of data with LTO-5 (maximum 140 MB/s), the most advanced tape technology requires 13 hours for conventional tape backup, not including backup application time and performance. However, it took about only 5.5 hours to back up the same amount of Microsoft Exchange data through 1 Gb Ethernet with Avamar multi-streaming, which means the backup time is reduced by up to 58 percent. Reduction of backup times compared to traditional backups is much faster because Avamar deduplicates and sends only unique changes, thus less data, combined with faster ingests.

Reduce granular recovery time The EMC Avamar plug-in for the Exchange GLR plug-in provides the capability to mount an existing backup’s database from the Avamar grid, which makes that database available on a mount point. This eliminates the time required to restore the database to a recovery database. Once you mount the database, it can be browsed, and individual items can be extracted from the database for recovery. The SharePoint GLR plug-in also mounts the content database using a mount point and eliminates the need to restore it to a different location before extracting items.

Reduced backup storage requirements Compared with the traditional 100-percent-backup storage capacity requirement on tape, only a relatively small amount of additional capacity is required with data deduplication on Avamar grid.

In this solution, the first full backup to Avamar of 9.76 TB of data used 6.51 TB of disk space after client-side deduplication. For a subsequent backup of a 3.15 percent data change under load, 9.85 TB of data used 278.20 GB of disk space after client-side deduplication.

Benefits


36

Note Your results may vary depending on how many duplicates are in your specific environment.

When EMC backed up to the Avamar grid, the CPU load on SharePoint SQL Server and Exchange mailbox servers were at 90 percent with the recommended eight cores. Avamar was configured to the maximum of six cores. Microsoft does not recommend such a high CPU usage, even though it did not affect performance.

Restore times for Avamar were acceptable for both Exchange and SharePoint, however, Avamar backup times can be improved by adding more cores to the SQL and Exchange mailbox servers. Avamar backups used almost all of the spare CPU of the SQL and Exchange mailbox servers but application performance was not affected by this.

With the advent of Avamar 6.0 and its multi-streaming backup capability, Avamar backs up and restores everything from small to enterprise-level environments, as proven in this solution.

Notes and recommendations


Conclusion

EMC Avamar extends the optimization capabilities of EMC backup and recovery solutions to accelerate performance, enhance replication control, and simplify administration. Your IT backup administrator can now manage organization-wide backup workloads associated with each dataset from a single management interface.

The EMC Avamar application plug-ins for Exchange and SharePoint enable application-consistent backups. Avamar client-side deduplication saves backup space and minimizes the amount of data that needs to be backed up.

Table 14 to Table 16 summarize the objectives of this solution and the results achieved.

Table 14. Baseline performance

Objective Results

Validate Exchange 2010 design and layout by showing acceptable performance levels

Exchange 2010 performed at acceptable levels, and storage layout was within parameters for performance.

Validate SharePoint 2010 design and layout by showing acceptable performance levels

SharePoint 2010 performed at acceptable levels, and storage layout was within parameters for performance.

Table 15. Hardware load balancing

Objective Results

Show SharePoint farm performance impact of a hardware load balancer

Using a load balancer gives a slightly better performance (3%).

Table 16. Avamar backups

Objective Results

Show backup times for SharePoint 2010 and Exchange 2010 to Avamar

With the recommended eight cores, CPU load on SharePoint SQL Server and Exchange mailbox servers were at 90%.

Microsoft does not recommend such a high CPU usage for SQL Server or Exchange, although it did not affect application performance in EMC’s tests.

Show deduplication rates for backups to Avamar

• Initial deduplication rate of 1.67:1 for Exchange data

• Initial deduplication rate of 1.98:1 for SharePoint data

• Subsequent data change deduplication rate of 85:1 for Exchange data

• Subsequent data change deduplication rate of 12.61:1 for SharePoint data

Summary

Findings


38

Objective Results

Show restore times from Avamar for SharePoint 2010 and Exchange 2010

Restore times for Avamar were acceptable for both Exchange and SharePoint.

Show how Avamar affects SharePoint and Exchange

Avamar backups used almost all of the spare CPU of the SQL Server and Exchange mailbox servers, but application performance was not affected by this.

Show in which environments Avamar is best suited

With the advent of Avamar 6.0 and its new multi-streaming backup capability, Avamar backs up and restores everything from small to enterprise-level environments, as proven in this solution.

For more information on the testing and validation done for this solution, see Appendix A: Detailed test results


References

For additional information, see the white papers listed below.

• EMC Virtual Infrastructure for Microsoft SharePoint Server 2010

• Microsoft Exchange Server 2010 Performance Review Using the EMC VNX5300 Unified Storage Platform—An Architectural Overview

For additional information, see the product documents listed below.

• Avamar 6 Portfolio

• Avamar Data Store Gen4 Multi-Node System Installation Guide

• Avamar 6.0 for Exchange VSS Guide

White papers

Product documentation


40

Appendix A: Detailed test results

Testing scenarios for this solution include:

• Baseline application performance testing

• Avamar: Backup testing with no data change and no load

• Combined Avamar backup testing: With data change and without load

• Combined Avamar backup testing: With data change and load

• Avamar test results with encryption

• Restore testing: Avamar Exchange native GLR restore

• Restore testing: Avamar Exchange database recovery

• Restore testing: Avamar SharePoint VSS restore of site collection database

• Avamar restore testing: Kroll recovery of a site and single item in SharePoint

• Hardware load balancing


Introduction

EMC ran this test to establish baseline performance and to validate the design and configuration of Exchange and SharePoint.

Baseline test The objective of this test is to show the baseline performance when both Exchange applications and SharePoint applications are running at the same time in the environment. The load profiles are explained in each of the application sections that follow:

• Microsoft Exchange 2010 Server

• Microsoft SharePoint 2010 Server

EMC ran all the tests for a minimum of eight hours concurrently to simulate a normal working day.

Notes 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, you should not use this workload as a substitute for a specific customer application benchmark when you are considering critical capacity planning and/or product evaluation decisions.

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 second.

Exchange 2010 Server

Performance After EMC completed the storage validation with Jetstress and determined that the storage was sized correctly and performed as expected, the next step in the validation process was to use the Microsoft Exchange Server Load Generator (LoadGen) tool to simulate a MAPI workload against the entire Exchange infrastructure. LoadGen testing is necessary to determine how each Exchange component performs under close-to-production user load.

LoadGen requires full deployment of the Exchange environment for validation testing. You must perform all LoadGen validation testing in an isolated lab environment where there is no connectivity to production data.

LoadGen:

• Generates users and workloads against the entire Exchange environment, including network and storage components

• Simulates the entire email flow and locates any bottlenecks in the solution

• Assists in determining the CPU and memory resources that are required to sustain the load for which the Exchange environment is designed

Baseline application performance testing


42

The 64-bit version of LoadGen 2010 can be downloaded from the Microsoft Download Center.

Test results In this solution, LoadGen 2010 was used to simulate Outlook 2007 online mode mailboxes with the following characteristics:

• The action profile was 150 messages per mailbox per day

• Each mailbox was 1.16 GB in size

Note The building block design in this solution can support a mailbox size up to 1.5 GB. Due to the long time required for mailbox initialization, the mailbox size configured in LoadGen was 1 GB. The actual mailbox size populated by LoadGen was around 1.16 GB.

EMC determined the validity of each test run by comparing the results of selected performance counters to Microsoft-specified criteria. Performance counter data was collected at one-minute intervals for the duration of each test run. The results of the first and last hours were discarded. Results were averaged over the remainder of the test.

For additional information about monitoring Exchange 2010 performance and other key performance counters, see Microsoft Exchange Server Library topic Performance and Scalability Counters and Thresholds.

Table 17 shows the LoadGen tests used to measure the performance of the Exchange infrastructure of this solution.

Table 17. LoadGen tests

Test Description

1 Normal operation: 8 hours, 100 percent concurrency test under normal operating conditions with 150 messages MAPI profile. The objective was to validate the entire Exchange environment under normal operating conditions.

2 Mailbox server failure: 8 hours, 100 percent concurrency test during the failure of one mailbox server and one client access server. All databases become active on the other mailbox server. All client RPC requests are processed by one client access server. The objective was to validate the environment's performance when one mailbox server and one client access server were lost.

As shown in Table 18, the performance achieved by the Exchange virtual machines meets the target metrics in all test scenarios. In the second test scenario, the processor utilization on the remaining servers is increased due to the loss of one mailbox server and one client access server.



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

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


Table 18. Performance of virtual machines

Server Performance counter Target Normal situation (2,500 users per server)

Failover situation (5,000 users on single server)

Mailbox server Processor\Percent processor time Less than 80% 38% 59%

MSExchange database\I/O database reads (attached) average latency

Less than 20 ms 10 11

MSExchange database\I/O database writes (attached) average latency

Less than 20 ms 1 2

Less than reads avg.

MSExchange database\I/O database reads (recovery) average latency

Less than 200 ms

21 0

MSExchange database\I/O database writes (recovery) average latency

Less than 200 ms

2 0

MSExchange database\I/O log read average latency

Less than 20 ms 3 0

MSExchange database\I/O log writes average latency

Less than 20 ms 3 1

MSExchange Replication(*)\ReplayQueueLength

Less than 2 1 0

MSExchangeIS\RPC requests Less than 70 2 5

MSExchangeIS\RPC averaged latency

Less than 10ms 3 4

CAS/HUB servers combo

Processor\Percent processor time Less than 80% 30% 60%

MSExchange RpcClientAccess\RPC Requests

Less than 40 2 6

MSExchange RpcClientAccess\RPC Averaged Latency

Less than 250 ms

9 13

MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues)

Less than 3,000 1 7

MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length

Less than 250 0 0


44

Server Performance counter Target Normal situation (2,500 users per server)

Failover situation (5,000 users on single server)

MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length

Less than 250 1 7

Figure 15 shows the throughput on Exchange active database LUNs. LoadGen simulated user actions were the main contributor to the activities on these LUNs. The average IOPS was 58.75, while the maximum was 126.66.

Figure 15. Exchange active database LUN throughput

0

20

40

60

80

100

120

140 03

:01:

16

03:1

1:16

03:2

1:16

03:3

1:16

03:4

1:16

03:5

1:16

04:0

1:16

04:1

1:16

04:2

1:16

04:3

1:16

04:4

1:16

04:5

1:16

05:0

1:16

IOPS

Exchange MB1 DB_1

Exchange MB1 DB_3

Exchange MB1 DB_5

Exchange MB1 DB_7

Exchange MB1 DB_9

Exchange MB2 DB_2

Exchange MB2 DB_4

Exchange MB2 DB_6

Exchange MB2 DB_8

Exchange MB2 DB_10


Figure 16 shows the throughput on Exchange passive database LUNs. Exchange DAG replication was the main contributor to the activities on these LUNs. The average IOPS was 45.45, while the maximum was 58.15.

Figure 16. Exchange passive database LUN throughput

Figure 17 shows the throughput on all Exchange log LUNs. The average IOPS was 36.24.

Figure 17. Exchange log LUN throughput

0

10

20

30

40

50

60

70

80

90

100

03:0

1:16

03:1

1:16

03:2

1:16

03:3

1:16

03:4

1:16

03:5

1:16

04:0

1:16

04:1

1:16

04:2

1:16

04:3

1:16

04:4

1:16

04:5

1:16

05:0

1:16

IOPS

Exchange MB1 DB_2

Exchange MB1 DB_4

Exchange MB1 DB_6

Exchange MB1 DB_8

Exchange MB1 DB_10

Exchange MB2 DB_1

Exchange MB2 DB_3

Exchange MB2 DB_5

Exchange MB2 DB_7

Exchange MB2 DB_9

0

5

10

15

20

25

30

35

40

45

50

03:0

1:16

03

:06:

16

03:1

1:16

03

:16:

16

03:2

1:16

03

:26:

16

03:3

1:16

03

:36:

16

03:4

1:16

03

:46:

16

03:5

1:16

03

:56:

16

04:0

1:16

04

:06:

16

04:1

1:16

04

:16:

16

04:2

1:16

04

:26:

16

04:3

1:16

04

:36:

16

04:4

1:16

04

:46:

16

04:5

1:16

04

:56:

16

05:0

1:16

IOPS


46

In summary, all key counters were well within the recommended thresholds. The results met the design target.

SharePoint 2010 Server

Introduction EMC completed the SharePoint farm baseline test with the aim of a reasonable user count to establish a baseline for backup testing.

Objective The objective of this test was to have a baseline to compare the impact of backups and load balancing on the environment.

Setup The setup is explained in the configuration and deployment sections.

Test results The SharePoint farm averaged 11.43 passed tests per second, as shown in Figure 18. This is equivalent to 6,858 users at 10 percent concurrency. The load profile was 80 percent browse, 10 percent search, and 10 percent modify.

Figure 18. SharePoint farm performance

0 2 4 6 8

10 12 14 16

02:0

0:00

02

:05:

45

02:1

1:30

02

:17:

15

02:2

3:00

02

:28:

45

02:3

4:30

02

:40:

15

02:4

6:00

02

:51:

45

02:5

7:30

03

:03:

15

03:0

9:00

03

:14:

45

03:2

0:30

03

:26:

15

03:3

2:00

03

:37:

45

03:4

3:30

03

:49:

15

03:5

5:00

Passed Tests/Sec


Browse averaged 2.34 seconds, search averaged 1.01 seconds, and modify averaged 2.31 seconds, as shown in Figure 19. The recommended Microsoft limit for common operations is three seconds; these times were well within that limit.

Figure 19. SharePoint average test times

Figure 20 shows that the CPUs on the WFE servers were very busy averaging at 77.07 percent, and the SQL Server CPU averaging 50.40 percent.

Index crawls were not running during this test.

Figure 20. SharePoint farm CPU usage

The ContentDB LUNs and log LUNs were spread over three VMFS file systems on three LUNs. The Search and Temp DBs were on a single VMFS file system.

0

1

2

3

4

5

6

02:0

0:00

02

:07:

15

02:1

4:30

02

:21:

45

02:2

9:00

02

:36:

15

02:4

3:30

02

:50:

45

02:5

8:00

03

:05:

15

03:1

2:30

03

:19:

45

03:2

7:00

03

:34:

15

03:4

1:30

03

:48:

45

03:5

6:00

Seco

nds

Avg. Test Time, Browse

Avg. Test Time, Search

Avg. Test Time, Modify

0

10

20

30

40

50

60

70

80

90

100

02:0

0:00

02

:06:

30

02:1

3:00

02

:19:

30

02:2

6:00

02

:32:

30

02:3

9:00

02

:45:

30

02:5

2:00

02

:58:

30

03:0

5:00

03

:11:

30

03:1

8:00

03

:24:

30

03:3

1:00

03

:37:

30

03:4

4:00

03

:50:

30

03:5

7:00

Perc

ent TCE-SP-SQL01

TCE-SP-INDEX01

TCE-SP-WFE01

TCE-SP-WFE02

TCE-SP-APP-01


48

Figure 21 shows the IOPS for the ContentDB, log, Search, and Temp DB LUNs. The ContentDBs_3 LUN has a lower IOPS because it hosted a smaller number of ContentDB LUNs. IOPS averaged 155.16, while the maximum IOPS was 411.93.

Figure 21. SharePoint ContentDB LUN throughput

0

50

100

150

200

250

300

350

400

450

02:0

1:16

02:1

1:16

02:2

1:16

02:3

1:16

02:4

1:16

02:5

1:16

03:0

1:16

03:1

1:16

03:2

1:16

03:3

1:16

03:4

1:16

03:5

1:16

04:0

1:16

IOPS

ContentDBs_1(IO/s)

ContentDBs_2(IO/s)

ContentDBs_3(IO/s)

Search and Temp(IO/s)


Introduction

Backup SharePoint datasets to the grid using the relevant plug-ins without any user load and without data change on SharePoint.

Objective This test showed the effect of backup to Avamar with no data change and no load to set a baseline for backup testing.

Setup Setup is as per the configuration and deployment sections. EMC did a full initial backup before backup testing to Avamar.

SharePoint 2010 Server: Test results

The backup time for this test was 4 hours and 15 minutes. This is an average backup rate of 171 MB/s for 2.5 TB of SharePoint data. There was very little data to deduplicate because there was no data change.

Figure 22 shows that the SQL server CPU averaged 80.47 percent. This is because the Avamar client performs CPU-intensive source hashing and deduplication during the backup.

Figure 22. SQL Server CPU usage

0

10

20

30

40

50

60

70

80

90

100

10:

49:3

5 1

1:03

:20

11:

17:0

5 1

1:30

:50

11:

44:3

5 1

1:58

:20

12:

12:0

5 1

2:25

:50

12:

39:3

5 1

2:53

:20

13:

07:0

5 1

3:20

:50

13:

34:3

5 1

3:47

:20

13:

59:3

5 1

4:13

:20

14:

27:0

5 1

4:40

:50

14:

54:3

5

Perc

ent

TCE-SP-SQL01

Avamar: Backup testing with no data change and no load


50

Figure 23 shows that the read IOPS for the ContentDBs averaged 200.06, while the maximum was 743.08. As you can see from the figure different ContentDBs on the three LUNs were being backed up at different times.

Figure 23. ContentDB LUNs read throughput

Figure 24 shows the disk utilization of two of the disks in the storage pool where the ContentDBs and logs reside. The average utilization was 8.42 percent.

Figure 24. ContentDB and log LUN disk utilization

0

100

200

300

400

500

600

700

800

04:5

1:16

05

:06:

16

05:1

6:16

05

:31:

16

05:4

6:16

06

:01:

16

06:1

6:16

06

:31:

16

06:4

6:16

07

:01:

16

07:1

6:16

07

:31:

16

07:4

6:16

08

:01:

16

08:1

6:16

08

:31:

16

08:4

6:16

09

:01:

16

09:1

6:16

IOPS

ContentDBs_1

ContentDBs_2

ContentDBs_3

0

10

20

30

40

50

60

70

80

90

100

04:5

1:16

05

:08:

46

05:2

6:16

05

:46:

16

06:0

6:16

06

:26:

16

06:4

6:16

07

:06:

16

07:2

6:16

07

:46:

16

08:0

6:16

08

:26:

16

08:4

6:16

09

:06:

16

09:2

6:16

Perc

ent

Bus 1 Enclosure 1 Disk 0 [Disk]



Introduction

Backup SharePoint and Exchange datasets to the grid using the relevant plug-ins without any user load on SharePoint and Exchange.

Objective The objective of this test scenario was to validate daily backup performance in a dedicated backup window when choosing Avamar grid as the backup target.

Setup Eight-hour LoadGen and VSTS tools were running before each backup test to simulate daily change in the environment. This change would be approximately 3 percent for Exchange data and 10 percent for SharePoint data.

Exchange backups were performed on passive database copies from both mailbox servers. Both Exchange backup jobs and SharePoint backup jobs were run with six streams to the Avamar nodes. Exchange backup jobs and SharePoint backup jobs were launched simultaneously.

Exchange 2010 Server: Test results

Figure 25 shows the CPU usage on Exchange mailbox server during the backup. The average value was 82.3 percent.

Figure 25. Exchange CPU usage

0

10

20

30

40

50

60

70

80

90

100

11:2

0:18

11

:25:

18

11:3

0:18

11

:35:

18

11:4

0:18

11

:45:

18

11:5

0:18

11

:55:

18

12:0

0:18

12

:05:

18

12:1

0:18

12

:15:

18

12:2

0:18

12

:25:

18

12:3

0:18

12

:35:

18

12:3

9:18

12

:44:

18

12:4

9:18

12

:54:

18

12:5

9:18

13

:04:

18

13:0

9:18

13

:14:

18

13:1

9:18

Combined Avamar backup testing: With data change and without load


52

Figure 26 shows the throughput on passive database LUNs from both Exchange servers. Backup jobs were the main contributor to the activities on these LUNs. The average IOPS was 148.32.

Figure 26. Exchange passive DB LUN read throughput

The backup time for this test was 5 hours and 26 minutes. This is an average backup rate of 171 MB/s for 3.2 TB of Exchange data. The deduplication ratio was 85:1.

Note The test results of deduplication ratio are based on the data generated by LoadGen. Because LoadGen is not specialized to test deduplication ratio, the results provided in this section may differ from the actual data in a customer production environment.


These results show SharePoint farm performance with a data change rate of 8 percent and without any user load.

Since there is no user load the SharePoint application has no performance results.

The backup time for this test was 5 hours and 22 minutes. This is an average backup rate of 136 MB/s for 2.5 TB of Exchange data. The deduplication ratio was 12.61:1.

Figure 27 shows the SQL Server CPU usage averaging 80.28 percent. This is very similar to SQL Server CPU usage for no data change, since the Avamar client has to do the same hashing and deduplication each time before comparing the hashes to the backup data.

0

20

40

60

80

100

120

140

160

180

200

07:0

1:16

07:1

1:16

07:2

1:16

07:3

1:16

07:4

1:16

07:5

1:16

08:0

1:16

08:1

1:16

08:2

1:16

08:3

1:16

08:4

1:16

08:5

1:16

09:0

1:16

IOPS

Exchange MB1 DB_2

Exchange MB1 DB_4

Exchange MB1 DB_6

Exchange MB1 DB_8

Exchange MB1 DB_10

Exchange MB2 DB_1

Exchange MB2 DB_3

Exchange MB2 DB_5

Exchange MB2 DB_7

Exchange MB2 DB_9



As shown in Figure 28, read IOPS averaged 207.91. The drop at the end for the ContentDBs_2 LUN shows the end of its backup while ContentDBs_3 is spiking as its ContentDBs are backed up.


Read size averaged 227.74 KB and peaked at 256 KB. Avamar decides what the best segment size is for the backup based on the content size.

0

10

20

30

40

50

60

70

80

90

13:2

0:14

13

:26:

29

13:3

2:44

13

:38:

59

13:4

5:14

13

:51:

29

13:5

7:44

14

:03:

59

14:1

0:14

14

:16:

29

14:2

2:44

14

:28:

59

14:3

5:14

14

:41:

29

14:4

7:44

14

:53:

59

15:0

0:14

15

:06:

29

15:1

2:44

15

:18:

59

Perc

ent

TCE-SP-SQL01

0

100

200

300

400

500

600

700

06:0

1:16

06:1

1:16

06:2

1:16

06:3

1:16

06:4

1:16

06:5

1:16

07:0

1:16

07:1

1:16

07:2

1:16

07:3

1:16

07:4

1:16

07:5

1:16

08:0

1:16

IOPS

ContentDBs_1

ContentDBs_2

ContentDBs_3


54

Introduction

Backup SharePoint and Exchange datasets to the grid using the relevant plug-ins with predefined data change rates and user loads for SharePoint and Exchange.

Objective The objective of this test scenario was to validate daily backup performance with data change and normal workload on Exchange and SharePoint servers when choosing Avamar grid as the backup target.

Setup Eight-hour LoadGen and VSTS tools were running before each backup test to simulate daily change in the environment.

Exchange backups were performed on passive database copies from both mailbox servers. Both Exchange backup jobs and SharePoint backup jobs were run with six streams to the Avamar nodes. Exchange backup jobs and SharePoint backup jobs were launched simultaneously.

LoadGen and VSTS were running throughout the entire backup window to evaluate the impact to both backup jobs and end-user experience.


Figure 29 shows the CPU usage on Exchange mailbox servers during the backup. The average value was 90.1 percent.

Figure 29. Exchange CPU usage

0

10

20

30

40

50

60

70

80

90

100

8:00

:48

8:05

:48

8:10

:48

8:15

:48

8:20

:48

8:25

:48

8:30

:48

8:35

:48

8:40

:48

8:45

:48

8:50

:48

8:55

:48

9:00

:48

9:05

:48

9:10

:48

9:15

:48

9:20

:48

9:25

:48

9:30

:48

9:35

:48

9:40

:48

9:45

:48

9:50

:48

9:55

:48

10:0

0:48

Combined Avamar backup testing: With data change and load


Table 19 shows the key Exchange performance counters that can reflect the end-user experience during the backup window. Although the processor time exceeded the recommended threshold, all other key counters were well below the target, which means the end-user experience was not affected during backup.

Table 19. Key Exchange performance counters

Performance counter Target AV backup under load

Processor\Percent processor time Less than 80% 90%

MSExchange database\I/O database reads (attached) average latency

Less than 20 ms 17

MSExchange database\I/O database writes (attached) average latency

Less than 20 ms 2

Less than reads avg.

MSExchange database\I/O database reads (recovery) average latency

Less than 200 ms 40

MSExchange database\I/O database writes (recovery) average latency

Less than 200 ms 15

MSExchange database\IO log read average latency Less than 20 ms 3

MSExchange database\IO log writes average latency Less than 20 ms 6

MSExchange Replication(*)\ReplayQueueLength Less than 2 1

MSExchangeIS\RPC requests Less than 70 2

MSExchangeIS\RPC averaged latency Less than 10 ms 3


56

Figure 30 shows the disk utilization for the storage pool that the mailbox databases used. It is an indication of how busy the backend disks are. Both LoadGen simulated user actions and backup jobs contribute to the activities in the storage pool. Utilization averaged 71.36 percent.

Figure 30. Exchange database disk utilization

0

10

20

30

40

50

60

70

80

90

100

04:0

1:17

04:1

1:17

04:2

1:17

04:3

1:17

04:4

1:17

04:5

1:17

05:0

1:17

05:1

1:17

05:2

1:17

05:3

1:17

05:4

1:17

05:5

1:17

06:0

1:17

Axi

s Ti

tle






Figure 31 shows the throughput on active database LUNs. LoadGen simulated user actions were the main contributor to the activities on these LUNs. The average IOPS was 42.45, while the maximum was 111.39.

Figure 31. Exchange active database LUN read throughput

Figure 32 shows the throughput on Exchange passive database LUNs. Backup jobs were the main contributor to the activities on these LUNs. The average IOPS was 142.51, while the maximum was 172.33.

Figure 32. Exchange passive database LUN read throughput

0

20

40

60

80

100

120

04:0

1:17

04:1

1:17

04:2

1:17

04:3

1:17

04:4

1:17

04:5

1:17

05:0

1:17

05:1

1:17

05:2

1:17

05:3

1:17

05:4

1:17

05:5

1:17

06:0

1:17

IOPS

Exchange MB1 DB_1

Exchange MB1 DB_3

Exchange MB1 DB_5

Exchange MB1 DB_7

Exchange MB1 DB_9

Exchange MB2 DB_2

Exchange MB2 DB_4

Exchange MB2 DB_6

Exchange MB2 DB_8

Exchange MB2 DB_10

0

20

40

60

80

100

120

140

160

180

200

04:0

1:17

04:1

1:17

04:2

1:17

04:3

1:17

04:4

1:17

04:5

1:17

05:0

1:17

05:1

1:17

05:2

1:17

05:3

1:17

05:4

1:17

05:5

1:17

06:0

1:17

IOPS

Exchange MB1 DB_2

Exchange MB1 DB_4

Exchange MB1 DB_6

Exchange MB1 DB_8

Exchange MB1 DB_10

Exchange MB2 DB_1

Exchange MB2 DB_3

Exchange MB2 DB_5

Exchange MB2 DB_7

Exchange MB2 DB_9


58

The average read size was 213.25 KB. The large I/O was used to improve backup performance.

Wrote IOPS for the active databases averaged 17.20 because of load and for the passive databases averaged 35.74 because of the backups running.

The backup time for this test was 6 hours and 40 minutes. This is an average backup rate of 144 MB/s for 3.3 TB of Exchange data. The deduplication ratio was 78:1.


These results show SharePoint farm performance with a data change rate of 10 percent and with full user load.

SharePoint performance was acceptable even though the backup was running.

The backup time for this test was 6 hours and 40 minutes. This is an average backup rate of 109 MB/s for 2.5 TB of Exchange data. The deduplication ratio was 13.65:1.

As shown in Figure 33, the SharePoint farm averaged 11.61passed test/sec, which is equivalent to 6,966 users at 10 percent concurrency. This is lower than the baseline because of the increased load of Avamar backups.


0

2

4

6

8

10

12

14

16

02:0

0:00

02

:06:

15

02:1

2:00

02

:17:

45

02:2

3:30

02

:29:

15

02:3

5:00

02

:40:

45

02:4

6:30

02

:52:

15

02:5

8:00

03

:03:

45

03:0

9:30

03

:15:

15

03:2

1:00

03

:26:

45

03:3

2:30

03

:38:

15

03:4

4:00

03

:49:

45

03:5

5:30

Passed Tests/Sec


As shown in Figure 34, average browse was 2.24 seconds, search was 0.89 seconds, and modify was 2.88 seconds.

Figure 34. Average test times

As shown in Figure 35, SQL Server CPU averaged 87.23 percent, which was 7 percent higher than the no load tests. This extra load was caused by user load and Avamar backup.


0

1

2

3

4

5

6

7

02:0

0:00

02

:07:

45

02:1

5:00

02

:22:

15

02:2

9:30

02

:36:

45

02:4

4:00

02

:51:

15

02:5

8:30

03

:05:

45

03:1

3:00

03

:20:

15

03:2

7:30

03

:34:

45

03:4

2:00

03

:49:

15

03:5

6:30

Seco

nds




0

10

20

30

40

50

60

70

80

90

100

08:5

9:16

09

:06:

16

09:1

3:16

09

:20:

16

09:2

7:16

09

:34:

16

09:4

1:16

09

:48:

16

09:5

5:16

10

:02:

16

10:0

9:16

10

:16:

16

10:2

3:16

10

:30:

16

10:3

7:16

10

:44:

16

10:5

1:16

10

:58:

16

Perc

ent

% Processor Time


60

WFE CPU usage averaged 75.57 percent, which is slightly lower than the baseline load test, as shown in Figure 36. This is because the SQL Server CPU is much busier, so the WFEs are no longer the bottleneck.

Figure 36. WFE CPU usage

As shown in Figure 37, utilization for disks in the ContentDB LUN RAID groups averaged 44.46 percent, which shows that the back-end disks in the storage pool could handle more load.

Figure 37. ContentDB and log disk utilization

0

10

20

30

40

50

60

70

80

90

02:0

0:00

02

:06:

15

02:1

2:30

02

:18:

45

02:2

5:00

02

:31:

15

02:3

7:30

02

:43:

45

02:5

0:00

02

:56:

15

03:0

2:30

03

:08:

45

03:1

5:00

03

:21:

15

03:2

7:30

03

:33:

45

03:4

0:00

03

:46:

15

03:5

2:30

03

:58:

45

Perc

ent

TCE-SP-WFE01

TCE-SP-WFE02

0

10

20

30

40

50

60

70

80

90

100

04:0

1:17

04:1

1:17

04:2

1:17

04:3

1:17

04:4

1:17

04:5

1:17

05:0

1:17

05:1

1:17

05:2

1:17

05:3

1:17

05:4

1:17

05:5

1:17

06:0

1:17

Perc

ent

Bus 1 Enclosure 1 Disk 0

Bus 1 Enclosure 1 Disk 4


Figure 38 shows that read IOPS averaged 431.93 and peaked at 1,012.84. The busiest ContentDB LUN is the one which has the most ContentDBs being actively backed up.


The read size varied because of Avamar and SharePoint reading at the same time.

0

200

400

600

800

1000

1200

04:0

1:17

04:1

1:17

04:2

1:17

04:3

1:17

04:4

1:17

04:5

1:17

05:0

1:17

05:1

1:17

05:2

1:17

05:3

1:17

05:4

1:17

05:5

1:17

06:0

1:17

IOPS

ContentDBs_1

ContentDBs_2

ContentDBs_3


62

Exchange

As shown in Table 20, encryption setting has little impact on Exchange backup time.

Table 20. Exchange encryption settings

Encryption Backup time CPU usage

MB01 MB02 MB01 MB02

No encryption 5:46 5:38 83% 83%

High encryption 5:30 5:30 83% 83%

When EMC enabled high encryption, the backup time on Exchange servers were slightly reduced (MB01 5 percent, MB02 2 percent). The CPU usages were almost the same.

SharePoint

As shown in Table 21, encryption setting has little impact (2 percent) on SharePoint backup time.

Table 21. SharePoint encryption settings

Encryption Backup time SQL Server CPU

No Encryption 4:15 87%

High Encryption 4:21 88%

Avamar performance with encryption

The above differences can be caused by variation between tests. Therefore, you can consider the performance with encryption to be almost the same as with no encryption.

Avamar test results with encryption


Introduction

EMC used Avamar client for Individual exchange mailbox and message restores.

Objective The objective of this test scenario was to validate the granular-level recovery function through the EMC Avamar plug-in for the Exchange GLR plug-in.

Setup In this test, EMC used the EMC Avamar plug-in for the Exchange GLR plug-in to restore one individual Exchange mailbox.

Note For the detailed configurations required to enable message level restores (granular level recoveries), see Avamar 6.0 for Exchange VSS Guide.


The EMC Avamar plug-in for Exchange GLR plug-in provides the capability to mount an existing backup’s content database through Avamar File System, which makes that database available on a mount point. This eliminates the time required to restore the database to a recovery database. Once the database is mounted, it can be browsed, and individual items can be extracted from the database for recovery.

Figure 39 shows the Avamar GUI for GLR restore.

Figure 39. Avamar GUI for mailbox restore

The restore time for a single mailbox was 1 hour and 5 minutes. It restored 36,494 mail items with 832 MB in total size.

Restore testing: Avamar Exchange native GLR restore


64

Introduction

EMC used Avamar client for individual Exchange mailbox database restores.

Objective The objective of this test scenario was to validate the Exchange mailbox database recovery function.

Setup In this test, EMC used the EMC Avamar Plug-in for Exchange VSS to restore one Exchange database and replay all transaction logs.


Figure 40 shows the Avamar GUI for an Exchange database restore.

Figure 40. Avamar GUI for Exchange database restore

The restore time for this test was 5 hours and 22 minutes. This is an average restore rate of 36 MB/s for 678.7 GB of Exchange data.

Restore testing: Avamar/Exchange database recovery


Introduction

EMC used the EMC Avamar Plug-in for SharePoint VSS to restore a content database (site collection).

Objective The objective of this test scenario was to show the Avamar restore of a content database in an existing SharePoint farm.

Setup In this test, EMC used Avamar to restore directly back onto the SharePoint SQL server. The original ContentDB was removed from the SQL Server and deleted before the restore.

Test results

Figure 41 shows the Avamar GUI for restoring a single ContentDB.

Figure 41. Avamar GUI restoring a ContentDB

The restore time for this test was 31 minutes. This is an average restore rate of 38 MB/s for 70 GB of SharePoint data.

The ContentDB was restored onto the SQL Server in the original location and then was automatically added back to SQL Server. If the site collection was not deleted in SharePoint, then no user interaction was required besides running the restore.

Restore testing: Avamar/ SharePoint VSS restore of site collection database


66

Introduction

EMC used Kroll Ontrack PowerControls against a mounted virtual saveset to recover a site, list, and single item in SharePoint.

Objective The objective of this test scenario was to restore a site and a single item back into a SharePoint farm.

Setup The site and item were deleted from SharePoint before the restores were run.

List restore

Figure 42 and Figure 43 show the Avamar GUI for doing a SharePoint GLR restore and the Kroll Ontrack PowerControls GUI for restoring the list.

Figure 42. SharePoint GLR restore

Avamar restore testing: Kroll recovery of a site and single item in SharePoint


Figure 43. Restoring a list

The restore time for this test was 2 hours and 2 minutes. The Kroll Ontrack PowerControls restore time was 2 hours. The test restored a total of 1,520 items of data.


68

Single-item restore

Figure 44 shows Kroll Ontrack PowerControls restoring a single item.

Figure 44. Restoring a single item

The restore time for this test was 10 minutes. The Kroll restore time was 8 minutes. The test restored one item of data in total.


Introduction

Most customer deployments of SharePoint with multiple web front ends use a load balancer to spread the client load equally and to add redundancy in case of WFE failure.

For this solution, EMC tested the performance impact of using a hardware load balancer on the environment. The load balancer only supported 1 Gb connections.

Objective The objective of this test was to show the value and impact of using hardware load balancers for SharePoint farms.

Setup As shown in Figure 45, the load balancer is on the IP network and receives the requests from the clients before distributing them equally between the WFE servers.

Load balancing logical design Figure 45 shows the logical network design for the load balancer.

Figure 45. Logical load balancing design

Hardware load balancing


70

Test results

As shown in Figure 46, passed test per second under load averaged 11.78, which is equivalent to 7,068 users at 10 percent concurrency. This is a slight (3 percent) improvement on the baseline test.


As shown in Figure 47, browse averaged 2.26 seconds, search averaged 0.93 seconds, and modify averaged 2.35 seconds.

Figure 47. Average test times

0

2

4

6

8

10

12

14

16

01:0

0:00

01

:06:

45

01:1

3:30

01

:20:

15

01:2

7:00

01

:33:

45

01:4

0:30

01

:47:

15

01:5

4:00

02

:00:

45

02:0

7:30

02

:14:

15

02:2

1:00

02

:27:

45

02:3

4:30

02

:41:

15

02:4

8:00

02

:54:

45

Passed Tests/Sec

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

01:0

0:00

01

:08:

45

01:1

7:30

01

:26:

15

01:3

5:00

01

:43:

45

01:5

2:30

02

:01:

15

02:1

0:00

02

:18:

45

02:2

7:30

02

:36:

15

02:4

5:00

02

:53:

45

Seco

nds




Documents

H8936: EMC Backup and Recovery for Microsoft … · EMC Backup and Recovery for Microsoft Exchange and SharePoint 2010 Servers 3 . EMC Avamar, EMC VNX, VMware vCenter . Table of contents