EMC VSPEX for Virtualized Microsoft Exchange Server Design Guide

6 downloads 164 Views 2MB Size Report
This Design Guide describes how to design virtualized Microsoft Exchange. Server 2010 ..... VSPEX for virtualized Exchange Server qualification worksheet .
DESIGN GUIDE

EMC VSPEX FOR VIRTUALIZED MICROSOFT EXCHANGE 2010

EMC VSPEX Abstract This Design Guide describes how to design virtualized Microsoft Exchange Server 2010 resources on the appropriate EMC© VSPEX™ Proven Infrastructures for Microsoft Hyper-V or VMware vSphere. The guide also illustrates how to size Exchange, allocate resources following best practices, and use all the benefits that VSPEX offers. April 2013

Copyright © 2013 EMC Corporation. All rights reserved. Published in the USA. Published April 2013 EMC believes the information in this publication is accurate 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. EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners. For the most up-to-date regulatory document for your product line, go to the technical documentation and advisories section on the EMC Online Support website. EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide Part Number H11463

2

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Contents

Chapter 1

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

Purpose of this guide .................................................................................. 12 Business value ............................................................................................ 12 Scope.......................................................................................................... 13 Audience ..................................................................................................... 13 Terminology ................................................................................................ 14 Chapter 2

Before You Start .................................................................. 15

Documentation workflow ............................................................................. 16 Essential reading......................................................................................... 16 Solution Overviews .............................................................................................. 16 Implementation Guides for Exchange Server ........................................................ 16 VSPEX Proven Infrastructures ............................................................................... 17 Exchange best practices for EMC storage ............................................................. 17

Chapter 3

Solution Overview ............................................................... 19

Overview ..................................................................................................... 20 Solution architecture ................................................................................... 20 Key components .......................................................................................... 21 Introduction ......................................................................................................... 21 Microsoft Exchange Server 2010 .......................................................................... 21 EMC VSPEX Proven Infrastructure ......................................................................... 22 EMC VNX and EMC VNXe series ............................................................................ 23 EMC Unisphere .................................................................................................... 25 VMware vSphere 5.1 ............................................................................................ 26 Microsoft Windows Server 2012 with Hyper-V ...................................................... 26 EMC Virtual Storage Integrator for VMware vSphere ............................................. 27 VNX VMware vStorage API for Array Integration support ....................................... 27 EMC Storage Integrator ........................................................................................ 27 EMC XtremSW Cache ............................................................................................ 27 EMC AppSync ....................................................................................................... 28 EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

3

Contents

EMC Avamar ......................................................................................................... 28 EMC Data Domain ................................................................................................ 29 EMC PowerPath .................................................................................................... 29

Chapter 4

Choosing a VSPEX Proven Infrastructure .............................. 31

Overview ..................................................................................................... 32 Step 1: Evaluate the customer use case ....................................................... 32 VSPEX for virtualized Exchange Server qualification worksheet ............................ 32

Step 2: Design the application architectures................................................ 34 VSPEX Sizing Tool ................................................................................................ 34

Step 3: Choose the right VSPEX Proven Infrastructure .................................. 37 Considerations..................................................................................................... 37 Examples ............................................................................................................. 38

Chapter 5

Solution Design Considerations and Best Practices .............. 45

Overview ..................................................................................................... 46 Network design considerations ................................................................... 46 Overview of network design considerations ......................................................... 46 Design best practices ........................................................................................... 46

Storage layout and design considerations ................................................... 48 Overview of storage layout and design considerations ......................................... 48 Storage design best practices .............................................................................. 51 Storage layout examples ...................................................................................... 53 FAST Suite design best practices .......................................................................... 55 XtremSW Cache design best practices.................................................................. 56

Virtualizing Exchange Server design considerations..................................... 57 Overview of virtualizing Exchange Server design considerations .......................... 57 Design best practices ........................................................................................... 57

Local protection design considerations ....................................................... 58 Overview of local protection design considerations.............................................. 58 Design best practices ........................................................................................... 58

Backup and recovery design considerations ................................................ 60 Overview of backup and recovery design considerations...................................... 60 Backup and recovery considerations .................................................................... 60 Backup strategies ................................................................................................ 61 Federated backups of Exchange 2010 DAG environments .................................... 64 Avamar Cluster Client Configuration ..................................................................... 64 Avamar Cluster Client Resource ............................................................................ 64 Preferred Server Order List ................................................................................... 64 Multistreaming..................................................................................................... 66

4

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Contents

Chapter 6

Solution Verification Methodologies .................................... 67

Overview ..................................................................................................... 68 Baseline hardware verification methodology ............................................... 68 Application verification methodology .......................................................... 68 High-level steps for application verification ......................................................... 68 Understanding the testing tools ........................................................................... 69 Understanding key metrics................................................................................... 70 Determining the architecture ................................................................................ 71 Building the infrastructure environment ............................................................... 71 Using the Jetstress tool ........................................................................................ 71 Deploying the Exchange organization................................................................... 71 Using the LoadGen tool ........................................................................................ 72

Backup and recovery verification methodology ............................................ 72 Verifying backup and recovery ............................................................................. 72

Chapter 7

Reference Documentation ................................................... 73

EMC documentation .................................................................................... 74 Other documentation .................................................................................. 75 Links ........................................................................................................... 75 Appendix A

Qualification Worksheet ...................................................... 77

Qualification worksheet............................................................................... 78 Printing the worksheet for customer use .............................................................. 78

Appendix B

Manually Sizing Exchange for VSPEX ................................... 79

Manually sizing Exchange for VSPEX ............................................................ 80 Overview .............................................................................................................. 80 Exchange manual sizing procedure ...................................................................... 80

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

5

Contents

6

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Figures

Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9. Figure 10. Figure 11. Figure 12.

Architecture of the validated infrastructure ......................................... 20 VSPEX Proven Infrastructure ............................................................... 22 Required resources example: VSPEX Proven Infrastructure for small Exchange organization ....................................................................... 40 Required resources example: VSPEX Proven Infrastructure for medium Exchange organization .......................................................... 43 Exchange Server storage elements layered in VSPEX vSphere Proven Infrastructure .......................................................................... 48 Exchange storage elements layered in VSPEX Hyper-V Proven Infrastructure ..................................................................................... 50 Storage layout example: Exchange organization for the VNXe series... 54 Storage layout example: Exchange organization for the VNX series .... 55 Installation map ................................................................................. 61 Backup workflow for Exchange ........................................................... 62 Non-federated backup of all databases in the DAG ............................. 63 Federated backup of a DAG cluster example ....................................... 65

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

7

Figures

8

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Tables

Table 1. Table 2. Table 3. Table 4. Table 5. Table 6. Table 7. Table 8. Table 9. Table 10. Table 11. Table 12. Table 13. Table 14. Table 15. Table 16. Table 17. Table 18. Table 19. Table 20. Table 21. Table 22. Table 23. Table 24. Table 25. Table 26. Table 27. Table 28. Table 29.

Terminology........................................................................................ 14 VSPEX for virtualized Exchange Server deployment process................ 16 Reference virtual machine—characteristics......................................... 23 VSPEX Proven Infrastructure selection steps ....................................... 32 VSPEX for virtualized Exchange Server qualification worksheet questionnaire ..................................................................................... 33 VSPEX Sizing Tool output .................................................................... 35 VSPEX Proven Infrastructure: Selection steps ..................................... 37 Example VSPEX qualification worksheet: Small Exchange organization ....................................................................................... 38 Example of required resources: Small Exchange organization ............. 39 Example of additional storage pools: Small Exchange organization .... 39 Example VSPEX qualification worksheet: Medium Exchange organization ....................................................................................... 41 Example of required resources: Medium Exchange organization ......... 41 Example of additional storage pools: Medium Exchange organization ....................................................................................... 42 Exchange-related storage pools: Name and purpose on VNX .............. 49 Exchange related storage pools: Name and purpose on VNXe............. 50 Exchange data storage pools: Small Exchange organization ............... 53 Exchange data storage pools: Medium Exchange organization ........... 54 High-level steps for application verification ........................................ 68 Key metrics of Jetstress verification .................................................... 70 Key metrics of LoadGen verification .................................................... 70 Qualification worksheet for an Exchange organization ........................ 78 Example VSPEX qualification worksheet ............................................. 80 Exchange manual sizing procedure .................................................... 81 Reference virtual machine: Characteristics ......................................... 82 Summary of reference virtual machine resources ................................ 83 Disk number required for IOPS and capacity ....................................... 87 Exchange data storage pool configuration .......................................... 87 VSPEX storage model support matrix .................................................. 89 Storage system and drives.................................................................. 90

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

9

Tables

10

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 1

Introduction

This chapter presents the following topics:

Purpose of this guide ................................................................................. 12 Business value .......................................................................................... 12 Scope ........................................................................................................ 13 Audience ................................................................................................... 13 Terminology............................................................................................... 14

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

11

Chapter 1: Introduction

Purpose of this guide EMC® VSPEX™ Proven Infrastructures are optimized for virtualizing business-critical applications. VSPEX provides partners with the ability to plan and design the assets required to support Microsoft Exchange in a virtualized environment on a VSPEX Private Cloud. EMC VSPEX for virtualized Microsoft Exchange Server 2010 provides partners with a validated solution, capable of hosting virtualized Exchange at a consistent performance level. This solution is layered on a VSPEX Private Cloud solution using either a VMware vSphere or Microsoft Hyper-V virtualization platform, and uses the highly available EMC VNX® family, which provides the storage. EMC Avamar® and EMC Data Domain® enable partners to adopt a purpose-built backup appliance for Exchange Server. The compute and network components, while vendor-definable, are designed to be redundant and are sufficiently powerful to handle the processing and data needs of the virtual machine environment. This Design Guide describes how to design a VSPEX Proven Infrastructure for virtualized Exchange Server 2010 with best practices and how to select the right VSPEX Proven Infrastructure by using the EMC VSPEX Sizing Tool for sizing guidance.

Business value Email is an indispensable lifeline for communication within your business, as well as connecting you with customers, prospects, partners, and suppliers. IT administrators supporting Microsoft Exchange Server are challenged with maintaining the highest possible levels of performance and application efficiency. At the same time, most struggle to keep pace with relentless data growth while working to overcome diminishing budgets. Administering, auditing, protecting, and managing an Exchange environment for a modern geographically diverse work force is a major challenge for most IT departments. Many businesses try to address these challenges by adding physical servers and inefficient direct attached storage, which further compounds the problem. Traditional backup cannot keep pace either; businesses are struggling to get backups done within available windows and to control backup data growth. EMC has joined forces with the industry’s leading providers of IT infrastructure to create a complete virtualization solution that accelerates deployment of private cloud and Microsoft Exchange. VSPEX enables to accelerate their IT transformation with faster deployment, more simplicity, greater choice, higher efficiency, and lower risk. Validation by EMC ensures predictable performance and enables customers to select technology that utilizes their existing IT infrastructure while eliminating planning, sizing, and configuration burdens. VSPEX provides Exchange infrastructures for customers looking to simplify their system—which is characteristic of truly converged infrastructures—while at the same time gaining more choice in individual stack components.

12

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 1: Introduction

The designed methodology and best practices of EMC backup and recovery systems are to: 

Reduce the customer’s backup storage requirements and costs



Meet backup windows



Enable fast disk-based recovery

Scope This Design Guide describes how to design a VSPEX Proven Infrastructure for virtualized Exchange Server 2010 with Microsoft Hyper-V or VMware vSphere. Furthermore, it illustrates how to size Exchange, allocate resources following best practices, and exploit all the benefits that VSPEX offers.

Audience This guide is intended for internal EMC personnel and qualified EMC VSPEX partners. The guide assumes that VSPEX partners who intend to deploy this VSPEX Proven Infrastructure for virtualized Exchange Server 2010 are: 

Qualified by Microsoft to sell and implement Exchange solutions



Certified in Exchange, ideally with one or both of the following Microsoft certifications: 

Microsoft Certified Technology Specialist (MCTS)–Microsoft Exchange 2010-Configuring (Exam: 662)



Microsoft Certified IT Professional (MCITP)–Enterprise Messaging Administrator 2010 (Exam: 662 and 663)



Qualified by EMC to sell, install, and configure the VNX family of storage systems



Certified to sell VSPEX Proven Infrastructures



Qualified to sell, install, and configure the network and server products required for VSPEX Proven Infrastructures

Readers must also have the necessary technical training and background to install and configure: 

VMware vSphere or Microsoft Windows Server 2012 with Hyper-V virtualization platforms



Microsoft Windows Server 2008 R2 operating systems (OS)

Note

During the solution test, Microsoft Exchange Server 2010 was not supported for installation on computers running the Windows Server 2012 OS. At the date of publication of this guide, Exchange Server 2010 Service Pack 3 is available to support Exchange 2010 on Windows Server 2012 OS.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

13

Chapter 1: Introduction



Microsoft Exchange Server 2010



EMC next-generation backup, which includes Avamar and Data Domain

External references are provided where applicable and EMC recommends that readers are familiar with these documents. For details, see Essential reading.

Terminology Table 1 includes the terminology used in this guide. Table 1.

14

Terminology

Term

Definition

AD

Active Directory

BDM

Background Database Maintenance

CAS

Client Access server

CIFS

Common Internet File System

CLI

Command Line Interface

CSV

Cluster shared volume

DAG

Database Availability Group

DNS

Domain name system

GLR

Granular-level recovery

GUI

Graphical User Interface

IIS

Internet Information Services

IOPS

Input/output operations per second

NIC

Network interface card

NFS

Network File System

NLB

Network Load Balancing

NL-SAS

Near-line serial-attached SCSI

PSOL

Preferred Server Order List

RAIN

Redundant array of independent nodes

Reference virtual machine

Represents a unit of measure for a single virtual machine to quantify the compute resources in a VSPEX Proven Infrastructure

RTM

Release to manufacturing

VHDX

Hyper-V virtual hard disk format

VSS

Volume Shadow Copy Service

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 2

Before You Start

This chapter presents the following topics:

Documentation workflow ........................................................................... 16 Essential reading ....................................................................................... 16

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

15

Chapter 2: Before You Start

Documentation workflow EMC recommends that you refer to the process flow in Table 2 to design and implement your VSPEX Proven Infrastructure for virtualized Exchange Server 2010. Table 2.

VSPEX for virtualized Exchange Server deployment process

Step

Action

1

Use the VSPEX for virtualized Exchange Server qualification worksheet to collect user requirements. The one-page Qualification worksheet is in Appendix A of this Design Guide.

2

Use the VSPEX Sizing Tool to determine the recommended VSPEX Proven Infrastructure for virtualized Exchange Server 2010 based on the user requirements collected in Step 1. For more information about the VSPEX Sizing Tool, refer to the VSPEX Sizing Tool on the EMC Business Value Portal. Note In the event that the Sizing Tool is not available, you can manually size the application using the sizing guidelines Manually Sizing Exchange for VSPEX in Appendix B.

3

To determine your final design for the VSPEX Proven Infrastructure for virtualized Exchange Server 2010, refer to this Design Guide. Note Ensure that all application requirements are considered, not just this particular application.

4

To select and order the right VSPEX Proven Infrastructure, refer to the VSPEX Proven Infrastructure section.

5

To deploy and test your VSPEX Proven Infrastructure for virtualized Exchange Server 2010, refer to the Implementation Guides for Exchange Server section.

Essential reading EMC recommends that you read the following documents, available from the VSPEX space in the EMC Community Network or from EMC.com or the VSPEX Proven Infrastructure partner portal. Solution Overviews

Implementation Guides for Exchange Server

16

Refer to the following VSPEX Solution Overview documents: 

EMC VSPEX Server Virtualization for Midmarket Businesses



EMC VSPEX Server Virtualization for Small and Medium Businesses

Refer to the following VSPEX Implementation Guides: 

EMC VSPEX for Virtualized Microsoft Exchange 2010 with Microsoft Hyper-V Implementation Guide



EMC VSPEX for Virtualized Microsoft Exchange 2010 with VMware vSphere Implementation Guide

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 2: Before You Start

VSPEX Proven Infrastructures

Exchange best practices for EMC storage

Refer to the following VSPEX Proven Infrastructures: 

EMC VSPEX Private Cloud VMware vSphere 5.1 for up to 100 Virtual Machines



EMC VSPEX Private Cloud VMware vSphere 5.1 for up to 500 Virtual Machines



EMC VSPEX Private Cloud Microsoft Windows Server 2012 with Hyper-V for up to 100 Virtual Machines



EMC VSPEX Private Cloud Microsoft Windows Server 2012 with Hyper-V for up to 500 Virtual Machines

Refer to the following Best Practice Guide for Exchange on EMC storage: 

Microsoft Exchange Server 2010: Storage Best Practices and Design Guidelines for EMC Storage

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

17

Chapter 2: Before You Start

18

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 3

Solution Overview

This chapter presents the following topics:

Overview ................................................................................................... 20 Solution architecture ................................................................................. 20 Key components ........................................................................................ 21

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

19

Chapter 3: Solution Overview

Overview This chapter provides an overview of the VSPEX Proven Infrastructure for virtualized Microsoft Exchange Server 2010 and the key technologies used in this solution. The solution is layered on a VSPEX Private Cloud, which uses storage, compute, network, and backup resources. The solution enables customers to quickly and consistently deploy a virtualized Exchange organization in the VSPEX Proven Infrastructure. The reference architecture will support the reference virtual machine resources, based on the sizing guidance in the VSPEX Proven Infrastructure, and combine with additional storage for the Exchange application data. This Design Guide can help customers to deploy a simple, effective, and flexible Exchange Server solution on a VSPEX Proven Infrastructure. The guidance applies to all VSPEX Proven Infrastructures, including both VMware vSphere and Microsoft Hyper-V.

Solution architecture Figure 1 shows the architecture that characterizes the validated VSPEX Proven Infrastructure for virtualized Exchange Server 2010. All Exchange servers are deployed as virtual machines on VMware vSphere 5.1 or Microsoft Windows Server 2012 with Hyper-V.

Figure 1.

20

Architecture of the validated infrastructure

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 3: Solution Overview

For more information about the VSPEX infrastructure, refer to the VSPEX Proven Infrastructure section. We1 used the VSPEX Sizing Tool for Exchange to determine the number of Exchange Server virtual machines and the detailed compute resources for each Exchange Server role, as well as the recommended storage layout for Exchange 2010. The optional backup and recovery components of the solution provide Exchange data protection.

Key components Introduction

This section provides an overview of the key technologies used in this solution: 

Microsoft Exchange Server 2010



EMC VSPEX Proven Infrastructure 



EMC VNX and EMC VNXe® series



EMC Unisphere™



VMware vSphere 5.1 



VMware Native Multipathing Plug-in (NMP)

Microsoft Windows Server 2012 with Hyper-V 

Microsoft Exchange Server 2010

Reference virtual machine

Multipath I/O (MPIO) and Multiple Connections per Session (MCS)



EMC Virtual Storage Integrator for VMware vSphere



EMC VNX VMware vStorage API for Array Integration Support



EMC Storage Integrator



EMC XtremSW™ Cache



EMC AppSync™



EMC Avamar



EMC Data Domain



EMC PowerPath®

Microsoft Exchange Server 2010 is an enterprise email and communication system that enables businesses and customers to collaborate and share information. EMC enhances Exchange Server 2010 with a selection of storage platforms, software, and services. With Exchange Server 2010, Microsoft presents a new, unified approach to high availability (HA) and disaster recovery (DR) by introducing features such as Database Availability Group (DAG) and online mailbox moves. Mailbox servers can now be

1

In this guide, "we" refers to the EMC Solutions engineering team that validated the solution.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

21

Chapter 3: Solution Overview

implemented in mailbox resiliency configurations with database-level replication and failover. Major improvements with the application database structure and input/output (I/O) reduction include support for a larger variety of disk and RAID configurations including high-performance Flash drives, Fibre Channel (FC) and serial-attached SCSI (SAS) drives, and slower-performing SATA and near-line serial-attached SCSI (NL-SAS) drives. Exchange 2010 includes multiple server roles: 

Mailbox server: This server role hosts mailboxes and public folders.



Client Access server: This server role hosts the client protocols, such as Post Office Protocol 3 (POP3), Internet Message Access Protocol 4 (IMAP4), Secure Hypertext Transfer Protocol (HTTPS), Outlook Anywhere, Availability service, and Autodiscover service. It also hosts Web services.



Hub Transport server: This server role routes mail within the Exchange organization.



Edge Transport server: This server role typically sits at the perimeter of the topology and routes mail in to and out of the Exchange organization.



Unified Messaging server: This server role connects a Private Branch eXchange (PBX) system to Exchange 2010.

The first three server roles are the essential components in every Exchange organization and are the focus of this guide. EMC VSPEX Proven VSPEX Proven Infrastructure, as shown in Figure 2, is a modular, virtualized infrastructure validated by EMC and delivered by EMC partners. VSPEX includes a Infrastructure virtualization layer, server, network, and storage, designed by EMC to deliver reliable and predictable performance.

Figure 2. 22

VSPEX Proven Infrastructure

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 3: Solution Overview

VSPEX provides the flexibility to choose network, server, and virtualization technologies that fit a customer’s environment to create a complete virtualization solution. VSPEX delivers faster deployment for EMC partner customers, with greater simplicity and efficiency, more choice, and lower risk to a customer’s business. Reference virtual machine To simplify the virtual infrastructure discussion, the VSPEX solution has defined a reference virtual machine to represent a measure unit. By comparing your actual customer usage to this reference workload, you can extrapolate which reference architecture to choose. For VSPEX solutions, the reference virtual machine is defined as a measure unit of a single virtual machine to quantify the compute resources in the VSPEX virtual infrastructure. This virtual machine has the following characteristics, as shown in Table 3. Table 3.

Reference virtual machine—characteristics

Characteristic

Value

Virtual processors per virtual machine

1

Random access memory (RAM) per virtual machine

2 GB

Available storage capacity per virtual machine

100 GB

Input/output operations per second (IOPS) per virtual machine

25

I/O pattern

Random

I/O read:write ratio

2:1

For more information about a reference virtual machine and its characteristics, refer to the relevant documents in the VSPEX Proven Infrastructures section. EMC VNX and EMC VNXe series

The EMC VNX family is optimized for virtual applications delivering industry-leading innovation and enterprise capabilities for file, block, and object storage in a scalable, easy-to-use solution. This next-generation storage platform combines powerful and flexible hardware with advanced efficiency, management, and protection software to meet the demanding needs of today’s enterprises. The VNX series is powered by Intel Xeon processors, for intelligent storage that automatically and efficiently scales in performance, while ensuring data integrity and security. The VNXe series is purpose-built for the IT manager in smaller environments and is designed to meet the high-performance, high-scalability requirements of midsize and large enterprises.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

23

Chapter 3: Solution Overview

VNX features VNX supports the following features: 

Next-generation unified storage, optimized for virtualized applications



Capacity optimization features including compression, deduplication, thin provisioning, and application-centric copies



High availability, designed to deliver five 9s (99.999 percent) availability



Automated tiering with FAST VP (Fully Automated Storage Tiering for Virtual Pools) and FAST™ Cache that can be optimized for the highest system performance and lowest storage cost simultaneously



Simplified management with EMC Unisphere™ for a single management interface for all network-attached storage (NAS), storage area network (SAN), and replication needs



Up to three times improvement in performance with the latest Intel Xeon multicore processor technology, optimized for Flash

VNXe features VNXe supports the following features: 

Next-generation unified storage, optimized for virtualized applications



Capacity optimization features including compression, deduplication, thin provisioning, and application-centric copies



High availability, designed to deliver five 9s availability



Multiprotocol support for file and block



Simplified management with Unisphere for a single management interface for all NAS, SAN, and replication needs

VNX software suites available The following software suites are available with VNX:

24



FAST Suite: Automatically optimizes for the highest system performance and the lowest storage cost simultaneously



Local Protection Suite: Practices safe data protection and repurposing



Remote Protection Suite: Protects data against localized failures, outages, and disasters



Application Protection Suite: Automates application copies and proves compliance



Security and Compliance Suite: Keeps data safe from changes, deletions, and malicious activity

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 3: Solution Overview

VNX software packs available The following software packs are available with VNX: 

Total Efficiency Pack: Includes all five software suites



Total Protection Pack: Includes the Local, Remote, and Application Protection Suites

VNXe software suites available The following software suites are available with VNXe: 

Local Protection Suite: Increases productivity with snapshots of production data



Remote Protection Suite: Protects data against localized failures, outages, and disasters



Application Protection Suite: Automates application copies and proves compliance



Security and Compliance Suite: Keeps data safe from changes, deletions, and malicious activity

VNXe software packs available The following software packs are available with VNXe:

EMC Unisphere



VNXe3300 Total Protection Pack: Includes the Local, Remote, and Application Protection Suites



VNXe3150 Total Value Pack: Includes the Remote and Application Protection Suites, and the Security and Compliance Suite

EMC Unisphere is the next-generation unified storage management platform that provides intuitive user interfaces for the newest range of unified platforms including the EMC VNX and EMC VNXe series. Unisphere’s approach to storage management fosters simplicity, flexibility, self-help, and automation—all key requirements for the journey to the cloud. Unisphere can be customized to the needs of a midsize company, a department within large enterprises, or a smaller remote office or branch office type environment. With pluggable architecture, Unisphere is easily extensible and continues its seamless support for additional EMC offerings, including integration with data protection and security. Unisphere for VNXe provides provisioning wizards that have built-in best practices to provision and manage application data such as Microsoft Exchange, Microsoft Windows Hyper-V, VMware, and shared folder storage. The Exchange wizard automatically incorporates many of the best practices for Microsoft Exchange Server, along with recommendations specific to the VNXe platform, into the storage design without additional user intervention. It provides a resource to store Microsoft Exchange databases and log files based on simple parameters, such as the number of users and the average user mailbox size.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

25

Chapter 3: Solution Overview

VMware vSphere 5.1

VMware vSphere 5.1 transforms a computer’s physical resources by virtualizing the CPU, RAM, hard disk, and network controller. This transformation creates fully functional virtual machines that run isolated and encapsulated operating systems and applications just like physical computers. VMware HA provides easy-to-use, cost-effective high availability for applications running in virtual machines. The VMware vSphere vMotion and VMware vSphere Storage vMotion features of vSphere 5.1 enable the seamless migration of virtual machines and stored files from one vSphere server to another, with minimal or no performance impact. Coupled with VMware vSphere Distributed Resource Scheduler (DRS) and VMware vSphere Storage DRS, virtual machines have access to the appropriate resources at any point in time through load balancing of compute and storage resources. VMware Native Multipathing Plug-in VMware Native Multipathing Plug-in (NMP) is the default module in vSphere used for multipathing. It provides a default path selection algorithm based on the array type. NMP associates a set of physical paths with a specific storage device or logical unit number (LUN). The particular details for handling path failover for a given storage array are delegated to a Storage Array Type Plug-In (SATP). The specific details for determining which physical path is used to issue an I/O request to a storage device are handled by a Path Selection Plug-In (PSP). SATPs and PSPs are sub plug-ins within the NMP module.

Microsoft Windows Microsoft Windows Server 2012 with Hyper-V provides a complete virtualization platform, which offers increased scalability and performance with a flexible solution Server 2012 with from the data center to the cloud. It makes it easier for organizations to realize the Hyper-V cost savings from virtualization and to optimize server hardware investments. Windows Server 2012 Hyper-V high-availability options include incremental backup support, enhancements in clustered environments to support virtual adapters within the virtual machine, and inbox NIC Teaming. In Hyper-V, “shared nothing” live migration enables the migration of a virtual machine from a server running Hyper-V to another one without the need for both of them to be in the same cluster or to share storage. MPIO and MCS Multipathing solutions use redundant physical path components adapters, cables, and switches to create logical paths between the server and the storage device. MPIO architecture supports iSCSI, FC, and SAS SAN connectivity by establishing multiple sessions or connections to the storage array. In the event that one or more of these components fails, causing the path to fail, multipathing logic uses an alternate path for I/O so that applications can still access their data. Each network interface card (in the iSCSI case) or host bus adapter (HBA) should be connected by using redundant switch infrastructures to provide continued access to storage in the event of a failure in a storage fabric component. MCS is a feature of the iSCSI protocol, which enables combining several connections inside a single session for performance and failover purposes.

26

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 3: Solution Overview

Note

EMC Virtual Storage Integrator for VMware vSphere

Microsoft does not support the use of both MPIO and MCS connections to the same device. Use either MPIO or MCS to manage paths to storage and load balance policies.

EMC Virtual Storage Integrator (VSI) for VMware vSphere is a plug-in for the vSphere client that provides a single management interface, which is used for managing EMC storage within the vSphere environment. Features can be added and removed from VSI independently, which provides flexibility for customizing VSI user environments. Features are managed by using the VSI Feature Manager. VSI provides a unified user experience, which enables new features to be introduced rapidly in response to changing customer requirements. We used the following features during validation testing: 

Storage Viewer (SV): Extends the vSphere client to facilitate the discovery and identification of the VNX storage devices that are allocated to vSphere hosts and virtual machines. SV presents the underlying storage details to the virtual datacenter administrator, merging the data of several different storage mapping tools into a few seamless vSphere client views.



Unified Storage Management: Simplifies storage administration of the VNX unified storage platform. It enables VMware administrators to provision new network file system (NFS) and virtual machine file system (VMFS) datastores, and raw device mapping (RDM) volumes seamlessly within vSphere client.

For more information, refer to the EMC VSI for VMware vSphere product guides on EMC Online Support. VNX VMware vStorage API for Array Integration support

Hardware acceleration with VMware vStorage API for Array Integration (VAAI) is a storage enhancement in vSphere 5.1 that enables vSphere to offload specific storage operations to compatible storage hardware such as the VNX series platforms. With storage hardware assistance, vSphere performs these operations faster and consumes less CPU, memory, and storage fabric bandwidth.

EMC Storage Integrator

EMC Storage Integrator (ESI) is an agent-less, no-charge plug-in that enables application-aware storage provisioning for Microsoft Windows server applications, Hyper-V, VMware, and Xen Server environments. It provides the ability for administrators to easily provision block and file storage for Windows using wizards. ESI supports the following capabilities:

EMC XtremSW Cache



Provisioning, formatting, and presenting drives to Windows servers



Provisioning new cluster disks and adding them to the cluster automatically



Provisioning shared Common Internet File System (CIFS) storage and mounting it to Windows servers

If your customer has special performance requirements on Exchange Server, consider using EMC XtremSW Cache as a solution. XtremSW Cache (formerly known as EMC VFCache) is intelligent caching software that uses server-based Flash technology to reduce latency and accelerate throughput for dramatic application performance

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

27

Chapter 3: Solution Overview

improvement. XtremSW Cache accelerates reads and protects data by using a writethrough cache to the networked storage to deliver persistent high availability, integrity, and disaster recovery. XtremSW Cache, coupled with array-based EMC FAST software, creates the most efficient and intelligent I/O path from the application to the data store. The result is a networked infrastructure that is dynamically optimized for performance, intelligence, and protection for both physical and virtual environments. EMC AppSync

If your customer would like to implement local protection for the Exchange Server 2010 environment, EMC recommends using AppSync, which offers a simple, selfservice, SLA-driven approach for protecting virtualized Microsoft applications in VNX deployments. After defining service plans, application owners can protect production data and recover data quickly with item-level granularity. AppSync also provides an application protection monitoring service that generates alerts when the SLAs are not met. VNX Snapshot capabilities now support 256 writable snaps per LUN for up to 32,000 per system (depending on the VNX system size), as well as snapshots of snapshots, making it ideal for testing, development, and disk backups. When used with AppSync, these snapshots are application-consistent and can be used to quickly and efficiently provision copies of production data for application development and testing.

EMC Avamar

If you decide to implement a backup solution, EMC recommends EMC Avamar and EMC Data Domain. Avamar deduplication backup software and system performs variable-length deduplication at the client, so that backup data is reduced before it moves across networks (LAN or WAN). Avamar identifies duplicate data segments and sends only unique segments across the network to the backup appliance. This means shorter backup windows, less backup storage consumed, and maximum use of available bandwidth. Avamar provides:

28



Flexible deployment options. Avamar offers flexibility in solution deployments, depending on the specific use case and recovery requirements. Avamar is a turnkey backup and recovery solution that integrates with EMC-certified hardware for streamlined deployment.



Scalability, high availability, and reliability. Avamar uses a scalable grid architecture, which enables linear performance and storage scaling by simply adding storage nodes.



Manageability and support. You can securely access Avamar systems through existing network links and integrate them with management frameworks to use SNMP for remote access.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 3: Solution Overview

EMC Data Domain

If you use Avamar to implement a backup and recovery solution, you can choose to direct backups to an EMC Data Domain system instead of to the Avamar server. EMC Data Domain deduplication storage system deduplicates data inline so that the data lands on disk already deduplicated, which requires less disk space than the original dataset. With Data Domain, you can retain backup and archive data on site longer to quickly and reliably restore data from disk. The Data Domain software suite includes the following options:

EMC PowerPath



EMC Data Domain Replication



Virtual Tape Library (VTL)



Data Domain Boost



Retention Lock



Encryption



Extended Retention

EMC recommends that you install EMC PowerPath for advanced multipathing functionality, such as intelligent path testing and performance optimization. EMC PowerPath is a server-resident software solution designed to enhance performance and application availability. PowerPath combines automatic load balancing, path failover, and multiple path I/O capabilities into one integrated package. EMC PowerPath and PowerPath/VE for Windows is an intelligent path management application specifically designed to work within the Microsoft Multipathing I/O (MPIO) framework. EMC PowerPath/VE for VMware supports multiple paths between a vSphere host and an external storage device. Having multiple paths enables the host to access a storage device, even if a specific path is unavailable. Multiple paths can also share the I/O traffic to a storage device.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

29

Chapter 3: Solution Overview

30

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 4

Choosing a VSPEX Proven Infrastructure

This chapter presents the following topics:

Overview ................................................................................................... 32 Step 1: Evaluate the customer use case...................................................... 32 Step 2: Design the application architectures............................................... 34 Step 3: Choose the right VSPEX Proven Infrastructure ................................. 37

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

31

Chapter 4: Choosing a VSPEX Proven Infrastructure

Overview This chapter describes how to design VSPEX for virtualized Exchange Server and how to choose the right VSPEX Proven Infrastructure to layer on Exchange Server. Table 4 outlines the main steps you need to complete when selecting a VSPEX Proven Infrastructure. Table 4.

VSPEX Proven Infrastructure selection steps

Step

Action

1

Evaluate the customer Exchange workload by using the VSPEX for virtualized Exchange Server qualification worksheet, based on the business requirement. See Step 1: Evaluate the customer use case.

2

Determine the required infrastructure, Exchange resources, and architecture using the VSPEX Sizing Tool. See Step 2: Design the application architectures. Note In the event that the Sizing Tool is not available, you can manually size the application using the sizing guidelines Manually Sizing Exchange for VSPEX in Appendix B.

3

Choose the right VSPEX Proven Infrastructure, based on the recommendations from Step 2. See Step 3: Choose the right VSPEX Proven Infrastructure.

Step 1: Evaluate the customer use case VSPEX for virtualized Exchange Server qualification worksheet

Before deploying VSPEX for virtualized Exchange Server, it is important to gather and understand the infrastructure requirements and limitations, and the estimated workload, to design the Exchange Server environment properly. To better understand the customer’s business requirements for the VSPEX infrastructure design, EMC strongly recommends that you use the VSPEX for virtualized Exchange Server qualification worksheet when evaluating the workload requirements for the VSPEX solution. VSPEX for virtualized Exchange Server qualification worksheet The VSPEX for virtualized Exchange Server qualification worksheet presents a list of simple questions to help identify customer requirements, usage characteristics, and datasets. For a one-page EMC qualification worksheet for the VSPEX Proven Infrastructure for virtualized Exchange Server 2010, see the Qualification worksheet section in Appendix A. Table 5 provides a detailed explanation of the questionnaire and general guidance on how to determine the input values.

32

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 4: Choosing a VSPEX Proven Infrastructure

Table 5.

VSPEX for virtualized Exchange Server qualification worksheet questionnaire

Question

Description

Number of mailboxes?

Use this question to estimate the total number of users that will have a mailbox in your Exchange organization. This element is important for defining the resources required in the VSPEX for virtualized Exchange Server solution.

Maximum mailbox size (GB)?

This refers to the size of each user’s mailbox. This is an important element for sizing disk capacity.

Mailbox IOPS profile (messages sent/received per mailbox per day)?

Use this element to estimate the Exchange mailbox IOPS profile. This is an important element for sizing back-end storage to meet your Exchange IOPS requirement. If this is your first time estimating your mailbox IOPS profile, refer to the Microsoft TechNet topic Understanding Database and Log Performance Factors for detailed information about the IOPS profile definition.

DAG copies (including active copy)?

This is to define the high availability requirement of your Exchange mailbox databases. This factor includes both the active and passive copies of each mailbox database.

Deleted Items Retention (DIR) Window (days)?

The DIR window refers to how long items will remain in the Exchange store after the user empties the Deleted Items folder. This feature enables end users to recover items mistakenly deleted without having to call the help desk and have the Exchange administrator restore the database. However, this value will affect the database capacity by increasing the mailbox size footprint. In Exchange Server 2010, this element is 14 days by default.

Backup/Truncation Failure Tolerance (days)?

The backup failure tolerance enables you to choose how many days you can go without a backup that performs truncation. Full backups and incremental backups purge the transaction logs since the last full/incremental backup. However, if a backup job fails, ensure that you have enough capacity to restore or continue the service until the next backup window. For solutions that use the native data protection features within Exchange (mailbox resiliency), plan to set the backup failure tolerance value to 3 to ensure adequate capacity for your log volumes.

Snapshot (days retained)?

Use this element to define how many days of snapshots you want to retain. You will need to use EMC AppSync to protect your Exchange Server environment by leveraging the VNX Advanced Snap feature. This element enables to you to keep up to five days of snapshots and each day there are eight hourly snapshots. This value affects the storage capacity by reserving space for your snapshots. For more information, refer to the Local protection design considerations section of this Design Guide.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

33

Chapter 4: Choosing a VSPEX Proven Infrastructure Question

Description

Included number of years’ growth?

Use this element to define the number of years’ growth that will be calculated in the VSPEX Sizing Tool. Future growth is a key characteristic of the VSPEX solution. This answer helps you to understand the customer’s plan for future growth. EMC suggests planning for at least one year’s growth when using the VSPEX Sizing Tool.

Annual growth rate (number of mailboxes, %)?

Future growth is a key characteristic of the VSPEX solution. Use this element to define the expected annual growth rate for the number of mailboxes in your Exchange organization. Enter a number that is appropriate for your environment.

Step 2: Design the application architectures VSPEX Sizing Tool

Overview After you evaluate the real workload and requirements of your customer’s Exchange Server, use the VSPEX Sizing Tool for Microsoft Exchange Server to design your VSPEX for virtualized Exchange Server solution. Principle and guidelines In this VSPEX Proven Infrastructure solution, we defined a representative customer reference workload to be sized. The VSPEX Proven Infrastructure reference architectures create a pool of resources that are sufficient to host a target number of reference virtual machines with the characteristics shown in Table 3. For more information about a reference virtual machine and its characteristics, refer to the relevant documents in the VSPEX Proven Infrastructures section. VSPEX Sizing Tool output: Requirements and recommendations The VSPEX Sizing Tool enables you to input your Exchange organization configurations from the customer’s answers in the qualification worksheet. After you complete the inputs to the VSPEX Sizing Tool, the tool generates a series of recommendations, as listed in Table 6.

34

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 4: Choosing a VSPEX Proven Infrastructure

Table 6.

VSPEX Sizing Tool output

VSPEX Sizing Tool recommendation

Description

Reference virtual machines for each Exchange Server role

Provides detailed information, including the number of virtual machines, vCPU, memory, IOPS, and the capacity of the operating system volume for each Exchange Server role.

VSPEX configuration

Sums up the reference virtual machines consumed in this Exchange organization. Additional storage pools recommendation for Exchange data including Exchange databases and transaction logs.

Additional storage pools

In this VSPEX for virtualized Exchange Server solution, customers may need to add more disks and storage pools to the infrastructure layer to meet different business requirements, based on performance and capacity considerations for the Exchange organization.

For more information, see the examples in Step 3: Choose the right VSPEX Proven Infrastructure. Reference virtual machine best practices for Exchange Server roles The VSPEX Sizing Tool provides detailed recommendations for sizing the reference virtual machine based on the following basic resource types for each Exchange Server role: 

Exchange server role deployment best practices



vCPU resources best practices



Memory resources best practices



OS capacity resources best practices



OS IOPS best practices

This section describes the resource types, how they are used in the VSPEX Sizing Tool, and key considerations and best practices for a customer environment. 

Exchange server role deployment best practices Exchange Server 2010 provides the DAG feature for high availability of your mailbox databases and the Client Access server array feature for load balancing of your Client Access servers when combined with Windows Network Load Balancing (NLB). However, DAG requires Microsoft Cluster Service (MSCS), and installing both the Cluster service and Network Load Balancing on the same computer is not supported by Microsoft. For more information, refer to the Microsoft Knowledge Base article Interoperability between MSCS and NLB. In the VSPEX for virtualized Exchange Server solution, EMC recommends that you deploy the Exchange Mailbox server role in dedicated virtual machines and that you combine the Hub Transport (HUB) and Client Access server (CAS) roles in dedicated virtual machines. For more information on how to implement the Exchange Server roles, refer to the Implementation Guides for Exchange section.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

35

Chapter 4: Choosing a VSPEX Proven Infrastructure



vCPU resources best practices When sizing the Exchange Server virtual machines, follow the same rules for sizing Exchange on physical servers, and always size the Exchange Mailbox server first. Add 10 percent to CPU requirements for hypervisor overhead. The calculator provides the vCPU of the reference virtual machine measurement unit consumed for each Exchange role from the virtual infrastructure. The CPU type must meet or exceed the CPU or processor models defined in the relevant documents listed in the VSPEX Proven Infrastructures section. We validated this VSPEX for virtualized Exchange Server solution with a statically assigned processor and no virtual-to-physical CPU oversubscription. For more information about vCPU considerations for the Mailbox server, refer to the Microsoft TechNet topic Mailbox Server Processor Capacity Planning. From the HUB/CAS server’s perspective, the HUB/CAS combined role has a 1:1 CPU core ratio to the Mailbox server. For more information, refer to the Microsoft TechNet topic Understanding Server Role Ratios and Exchange Performance.



Memory resources best practices The VSPEX Sizing Tool shows the recommended memory for the reference virtual machine measurement unit for each Exchange Server role. We validated this VSPEX for virtualized Exchange Server solution with statically assigned memory, no over-commitment of memory resources, and no memory swapping or ballooning. The memory values provided by the tool are not hard limits but represent the value that was tested in the VSPEX solution. In general, Mailbox server memory requirements are highly dependent on the number of mailboxes on this server and the mailbox IOPS profile. For detailed information, refer to the Microsoft TechNet topic Understanding the Mailbox Database Cache.



OS capacity resources best practices The VSPEX Sizing Tool shows the recommended capacity of the reference virtual machine measurement unit suggested for the operating system for each Exchange Server role. EMC recommends that you put the OS volume into the VSPEX virtual infrastructure storage pool in the VSPEX Proven Infrastructure solution. For more information about the virtual infrastructure storage pool, see the VSPEX Proven Infrastructures section. In medium and small Exchange organizations, EMC recommends that the Exchange Mailbox servers and HUB/CAS combined servers are allocated at least 100 GB of disk space for the OS.



OS IOPS best practices The VSPEX Sizing Tool shows the estimated IOPS of the reference virtual machine measurement unit suggested for each Exchange Server role in the OS. EMC recommends that you put the OS volume into the VSPEX infrastructure storage pool. In this scenario, we considered more performance characteristics from the application perspective than from the capacity perspective.

36

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 4: Choosing a VSPEX Proven Infrastructure

The VSPEX Sizing Tool generates suggestions for the number of virtual machines for each Exchange Server role. These numbers are calculated based on the business requirement, as indicated by the answers in the qualification worksheet. Additional considerations When designing your Exchange organization, it is important to plan for growth so that the environment can continue to deliver an effective business solution. To maintain performance targets and accommodate growth, the VSPEX Sizing Tool enables customers to select from one to three years growth. The cost of over-investment in hardware is usually far less than the cumulative expense of troubleshooting problems caused by undersizing.

Step 3: Choose the right VSPEX Proven Infrastructure Considerations

The VSPEX program has produced numerous solutions designed to simplify the deployment of a consolidated virtual infrastructure using vSphere, Hyper-V, the VNX and VNXe series of products, and EMC next-generation backup. When the application architecture has been confirmed using the VSPEX Sizing Tool, you can choose the right VSPEX Proven Infrastructure based on the calculated results. Note

While this Design Guide is intended for Exchange Server organization requirements, this may not be the only application intended for deployment on the VSPEX Proven Infrastructure. For each application your customer plans to deploy, you must carefully consider your customer’s requirements. If you are uncertain about the best VSPEX Proven Infrastructure to deploy, consult EMC before making the decision.

Follow the steps shown in Table 7 when choosing a VSPEX Proven Infrastructure. Table 7.

VSPEX Proven Infrastructure: Selection steps

Step

Action

1

Use the VSPEX Sizing Tool to get the total number of reference virtual machines and any additional suggested storage layout for Exchange Server.

2

Use the VSPEX Sizing Tool to design the resource requirements for other applications, based on business needs. The VSPEX Sizing Tool calculates the total number of required reference virtual machines and additional recommended storage layouts for both Exchange and other applications.

3

Discuss with your customers the maximum utilization of the VSPEX Proven Infrastructure that meets their business requirements—this is the maximum utilization for both Exchange and other applications. Input the maximum utilization percentage in the VSPEX Sizing Tool. The tool provides a recommendation for the VSPEX Proven Infrastructure offering.

4

Select your network vendor and hypervisor software vendor with the recommended VSPEX Proven Infrastructure offering. For more information, visit the VSPEX Proven Infrastructure website.

For more information about the required reference virtual machines, refer to the relevant sizing section in VSPEX Proven Infrastructures.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

37

Chapter 4: Choosing a VSPEX Proven Infrastructure

Examples

This section describes two examples of Exchange Server 2010 organizations—one small, one medium—and demonstrates how you would select the right VSPEX Proven Infrastructure for each one. Example 1: Exchange small configuration In this scenario, a customer would like to deploy a small Exchange organization on a VSPEX Proven Infrastructure. The customer needs to deploy 900 mailboxes and anticipates a one-year 11percent growth in the number of mailboxes. The customer wants to deploy a DAG configuration so each of the mailbox databases will have one active copy and one passive copy for high availability. The expected mailbox size is 1.5 GB and the mailbox IOPS profile is 0.15 (that is, 150 messages sent/received per day). Deleted email messages will be kept on the Exchange store for 14 days and the backup failure tolerance is set to 3 days. The customer does not want to use snapshots for Exchange Server. In addition, the customer would like to use at most 75 percent of the VSPEX Proven Infrastructure for combined applications. There are no other applications to be deployed. After talking to the customer, complete the VSPEX qualification worksheet for the production Exchange 2010 organization, as shown in the example in Table 8. Table 8.

Example VSPEX qualification worksheet: Small Exchange organization

Question

Example answer

Number of mailboxes?

900

Maximum mailbox size (GB)?

1.5 GB

Mailbox IOPS profile (messages sent/received per mailbox per day)?

0.15 IOPS per mailbox (150 messages sent/received per mailbox per day)

DAG copies (including active copy)?

2

Deleted Items Retention (DIR) Window (days)?

14

Backup/Truncation Failure Tolerance (days)?

3

Snapshot (days retained)?

0

Included number of years’ growth?

1

Annual growth rate (number of mailboxes, %)?

11%

After inputting the answers from the qualification worksheet into the VSPEX Sizing Tool, the tool generates a series of recommendations for the resources needed from the resource pool, as shown in the example in Table 9. In this example, you need to set up two Exchange Mailbox servers and two HUB/CAS combined servers to support the Exchange requirements from the qualification worksheet in Table 8. Then you can determine the equivalent number of reference virtual machines required for each Exchange server role by calculating the maximum of the individual resources (CPU, memory, capacity, and IOPS).

38

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 4: Choosing a VSPEX Proven Infrastructure

Table 9.

Example of required resources: Small Exchange organization

Exchange Server role

vCPU

Memory (GB)

OS volume capacity

OS volume IOPS

No. of virtual machines

Total reference virtual machines

Mailbox server

Equivalent reference virtual machines

4

8

1

1

2

16

HUB/CAS server

Equivalent reference virtual machines

4

4

1

1

2

8

Total equivalent reference virtual machines

24

For example, each Mailbox server requires four vCPUs, 16 GB of memory, 100 GB of storage, and 25 IOPS. This translates to: 

Four reference virtual machines of CPU



Eight reference virtual machines of memory



One reference virtual machine of capacity



One reference virtual machine of IOPS

The values round up to eight reference virtual machines for each Mailbox server, multiplied by the number of virtual machines needed (two in this example), which results in 16 total reference virtual machines for the Mailbox server role: 8 reference virtual machines x 2 virtual machines = 16 total reference virtual machines

For more details on how to determine the equivalent reference virtual machines, refer to the appropriate document in Essential reading. The VSPEX Sizing Tool also lists recommendations for the type of storage array (VNXe in this case) and the storage layout, as shown in the example in Table 10. The suggested storage layout to store Exchange data is in addition to the VSPEX private cloud pool. Table 10.

Example of additional storage pools: Small Exchange organization Recommended additional storage layout

Storage pool name

RAID type

Disk type

Disk capacity

No. of disks

Exchange storage pool 1

RAID 5 (4+1)

15,000 rpm SAS disks

600 GB

10

Exchange storage pool 2

RAID 5 (4+1)

15,000 rpm SAS disks

600 GB

10

Again, in this example, Exchange Server is the only application planned for deployment on this VSPEX Proven Infrastructure. The VSPEX Sizing Tool recommends that customers consider the following two VSPEX infrastructures for the best fit with their requirements:

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

39

Chapter 4: Choosing a VSPEX Proven Infrastructure



EMC VSPEX Private Cloud VMware vSphere 5.1 for up to 100 Virtual Machines



EMC VSPEX Private Cloud Microsoft Windows Server 2012 with Hyper-V for up to 100 Virtual Machines

Implementing this small Exchange organization on a pool for 50 reference virtual machines consumes the resources of 24 reference virtual machines and leaves resources for 26 reference virtual machines for other applications, as shown in Figure 3.

Figure 3.

Required resources example: VSPEX Proven Infrastructure for small Exchange organization

In the Implementation Guide, we used 50 VMware vSphere virtual machines as a VSPEX solution example. For more information, refer to Implementation Guides for Exchange Server section. Example 2: Exchange medium organization In this scenario, a customer would like to deploy a medium Exchange organization on a VSPEX Proven Infrastructure. The customer needs to deploy 9,000 mailboxes and anticipates a one-year, 11-percent growth in the number of mailboxes. The customer wants to deploy a DAG configuration, so each of the mailbox databases will have one active copy and one passive copy for high availability. The expected mailbox size is 1.5 GB and the mailbox IOPS profile is 0.15 (that is, 150 messages sent/received per day). Deleted email messages will be kept on the Exchange store for 14 days and the backup failure tolerance is set to 3 days. The customer does not want to use snapshots for Exchange Server. Meanwhile, the customer also planned for other applications, such as Microsoft SharePoint and SQL Server, in the VSPEX Proven Infrastructure. In addition, the customer would like to use at most 75 percent of the VSPEX Proven Infrastructure for combined applications. After talking to the customer, complete the VSPEX qualification worksheet for the production Exchange Server 2010 organization, as in the example shown in Table 11.

40

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 4: Choosing a VSPEX Proven Infrastructure

Table 11.

Example VSPEX qualification worksheet: Medium Exchange organization

Question

Example answer

Number of mailboxes?

9,000

Maximum mailbox size (GB)?

1.5 GB

Mailbox IOPS profile (messages sent/received per mailbox per day)?

0.15 IOPS per mailbox (150 messages sent/received per mailbox per day)

DAG copies (including active copy)?

2

Deleted Items Retention (DIR) Window (days)?

14

Backup/Truncation Failure Tolerance (days)?

3

Snapshot (days retained)?

0

Included number of years’ growth?

1

Annual growth rate (number of mailboxes, %)?

11%

After inputting the answers from the qualification worksheet into the VSPEX Sizing Tool, the tool generates a series of recommendations for the resources needed from the resource pool, as shown in the example in Table 12. In this example, you need to set up four Exchange Mailbox servers and four HUB/CAS combined servers to support the Exchange requirements from the qualification worksheet in Table 11. Then you can determine the equivalent number of reference virtual machines required for each Exchange server role by calculating the maximum of the individual resources (CPU, memory, capacity, and IOPS). Table 12.

Example of required resources: Medium Exchange organization

Exchange server role

vCPU

Memory (GB)

OS volume capacity

OS volume IOPS

No. of virtual machines

Total reference virtual machines

Mailbox server

Equivalent reference virtual machines

4

24

1

1

4

96

HUB/CAS server

Equivalent reference virtual machines

4

4

1

1

4

16

Total equivalent reference virtual machines

112

For example, each Mailbox server requires four vCPUs, 48 GB of memory, 100 GB of storage, and 25 IOPS. This translates to: 

Four reference virtual machines of CPU



Twenty-four reference virtual machines of memory



One reference virtual machine of capacity



One reference virtual machine of IOPS

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

41

Chapter 4: Choosing a VSPEX Proven Infrastructure

The values round up to 24 reference virtual machines for each Mailbox server, multiplied by the number of virtual machines needed (four in this example), which results in 96 total reference virtual machines for the Mailbox server role: 24 reference virtual machines x 4 virtual machines = 96 total reference virtual machines

For more details about how to determine the equivalent reference virtual machines, refer to the appropriate document in Essential reading. The VSPEX Sizing Tool also lists recommendations for the type of storage array (VNX in this case) and the storage layout, as shown in the example in Table 13. The suggested storage layout to store Exchange data is in addition to the VSPEX private cloud pool. Table 13.

Example of additional storage pools: Medium Exchange organization Recommended additional storage layout

Storage pool name

RAID type

Disk type

Disk capacity

No. of disks

Exchange database pool 1

RAID 1/0 (24+24)

7,200 rpm NL-SAS disks

2 TB

48

Exchange database pool 2

RAID 1/0 (24+24)

7,200 rpm NL-SAS disks

2 TB

48

Exchange log pool 1

RAID 1/0 (4+4)

7,200 rpm NL-SAS disks

2 TB

8

Exchange log pool 2

RAID 1/0 (4+4)

7,200 rpm NL-SAS disks

2 TB

8

As Exchange Server is not the only application that the customer needs to plan for in the VSPEX Proven Infrastructure, EMC recommends using the VSPEX Sizing Tool to design the combined applications workload that has the best fit with the VSPEX Proven Infrastructure offering. For example, if the total combined applications required 180 reference virtual machines and the customer requested at most 75 percent utilization of the VSPEX Proven Infrastructure, the VSPEX Sizing Tool recommends the following VSPEX infrastructures for the best fit with the customer’s requirements: 

EMC VSPEX Private Cloud VMware vSphere 5.1 for up to 500 Virtual Machines



EMC VSPEX Private Cloud Microsoft Windows Server 2012 with Hyper-V for up to 500 Virtual Machines

Implementing this medium Exchange organization on a pool of 250 reference virtual machines consumes the resources of 112 reference virtual machines and leaves resources for 138 reference virtual machines for other applications, as shown in Figure 4.

42

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 4: Choosing a VSPEX Proven Infrastructure

Figure 4.

Required resources example: VSPEX Proven Infrastructure for medium Exchange organization

In the Implementation Guide, we used 250 VMware vSphere virtual machines as a VSPEX solution example. For more information, refer to the Implementation Guides for Exchange Server.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

43

Chapter 4: Choosing a VSPEX Proven Infrastructure

44

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5

Solution Design Considerations and Best Practices

This chapter presents the following topics:

Overview ................................................................................................... 46 Network design considerations .................................................................. 46 Storage layout and design considerations .................................................. 48 Virtualizing Exchange Server design considerations .................................... 57 Local protection design considerations ...................................................... 58 Backup and recovery design considerations ............................................... 60

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

45

Chapter 5: Solution Design Considerations and Best Practices

Overview This chapter provides best practices and considerations for the VSPEX Proven Infrastructure for virtualized Exchange Server 2010 solution. We considered the following aspects during the solution design: 

Network design



Storage layout design



Virtualizing Exchange Server design



Local protection design



Backup and recovery design

Network design considerations Overview of network design considerations

Networking in the virtual world follows the same concepts as in the physical world, but some of these concepts are applied in the software instead of using physical cables and switches. Although many of the best practices that apply in the physical world continue to apply in the virtual world, there are additional considerations for traffic segmentation, availability, and throughput. The advanced networking features of the VNXe and VNX series provide protection against network connection failures at the array. Meanwhile, each hypervisor host has multiple connections to user and storage Ethernet networks to guard against link failures. These connections should be spread across multiple Ethernet switches to guard against component failure in the network. For more information, refer to the VSPEX Proven Infrastructures section.

Design best practices

In this VSPEX Proven Infrastructure for virtualized Exchange Server 2010, EMC recommends that you consider the following aspects for network design: 

Separate different network traffic Keep the virtual machine, storage, and vSphere vMotion or Microsoft Windows Hyper-V Live Migration network traffic separate using VLAN segmentation.



Set up network redundancy A goal of redundant topologies is to eliminate network downtime caused by a single point of failure. All networks need redundancy for enhanced reliability. Network reliability is achieved through reliable equipment and network designs that are tolerant to failures and faults. Networks should be designed to recover rapidly so that the fault is bypassed. In this solution, we have two network switches and all networks have their own redundant link.



Use NIC teaming Aggregate multiple network connections in parallel to increase the throughput beyond what a single connection can sustain, and to provide redundancy in case one of the links fails. For example, in the VMware virtualization environment, use two physical NICs per vSwitch and uplink the physical NICs to separate physical switches.

46

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

When setting the NIC teaming settings, it is considered best practice to select “no” for the NIC teaming failback option. If there is some intermittent behavior in the network, this will prevent flip-flopping of the NIC cards being used. When setting up VMware HA, it is a good starting point to also set the following ESX Server timeouts and settings under the ESX Server advanced setting tab:





NFS.HeartbeatFrequency = 12



NFS.HeartbeatTimeout = 5



NFS.HeartbeatMaxFailures = 10

Use hardware load balancing or Windows NLB NLB, together with the Client Access server array, provides key benefits for Exchange Client Access servers, including that: 

It reduces the impact of a single Client Access server failure within one of the Active Directory (AD) sites.



It helps distribute the load evenly across the Client Access servers.

For more information on creating a Windows NLB cluster and setting up a Client Access server array, refer to the Implementation Guides for Exchange section. 

Disable Delayed Acknowledgement on iSCSI NICs On the Windows Hyper-V virtualization platform, modify the TCP/IP settings for the network interfaces carrying iSCSI traffic on Hyper-V hosts to immediately acknowledge incoming TCP segments, otherwise slow iSCSI performance may occur. For detailed steps, refer to the article On a Microsoft Windows Server 2008 R2

Fail over cluster with a Hyper-V guest with many pass-through disks, the machine configuration may take some time to come online on the Microsoft Support website. This article also applies to Windows Server 2012.

On the VMware virtualization platform, disable the Delayed Acknowledgement (ACK) which may cause slow iSCSI performance issues. For more information, refer to the article ESX/ESXi hosts might experience read/write performance issues with certain storage arrays on the VMware Knowledge Base website. 

Set up Replication network for Exchange DAG When deploying DAG in your environment, although a single network is supported, it is recommended that each DAG has at least two networks: 

A single Messaging Application Programming Interface (MAPI) network, which is used by other servers (such as Exchange 2010 servers and directory servers) to communicate with the DAG member



A single Replication network, which is dedicated to log shipping and seeding

This provides network redundancy and enables the system to distinguish between a server failure and a network failure. For detailed steps, refer to the Microsoft TechNet topic Deploying High Availability and Site Resilience. EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

47

Chapter 5: Solution Design Considerations and Best Practices

For other best practices in network design for the VSPEX Proven Infrastructure, refer to the VSPEX Proven Infrastructures section.

Storage layout and design considerations Overview of storage layout and design considerations

The best practice and design considerations in this section provide guidelines for effectively planning storage for various business requirements in Exchange Server 2010 environments. EMC VNX FAST Suite and XtremSW Cache design considerations are also covered in this section. Figure 5 shows an example of the high-level architecture of the Exchange components and storage elements validated in the VSPEX Proven Infrastructure for virtualized Exchange Server 2010 on a vSphere virtualization platform and VNX storage array. In this example, all the Exchange Server database and log volumes are stored in RDM due to local protection requirements by using EMC AppSync. Note

Microsoft has support policies on the types of storage (file or block protocols) that can be used by the Exchange virtual machines for Exchange data. For detailed information, refer to the Microsoft TechNet topic Understanding Exchange 2010 Virtualization.

Figure 5.

48

Exchange Server storage elements layered in VSPEX vSphere Proven Infrastructure

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

In addition to the VSPEX private cloud pool for virtual machines, EMC recommends that you use additional storage pools to store Exchange database and log files. When designing storage pools for deploying Exchange 2010, you can use different models— for example, one storage pool per Exchange Mailbox server, or one storage pool per database copy. DAG is configured on Exchange Server 2010 and each database has two copies in this example. We configured dedicated storage pools for each database copy, which provides database copy isolation and, in many cases, can minimize the number of pools needed for deployment compared to the model of one storage pool per Exchange Mailbox Server. We also separated the Exchange database and log files into different storage pools. For detailed information about VNX storage pool design for Exchange Server, see Table 14. For more information about storage design best practices for Exchange Server, refer to Storage design best practices in this section. Table 14.

Exchange-related storage pools: Name and purpose on VNX

Pool name

Purpose

RAID recommendation

VSPEX private cloud pool

The infrastructure pool where all the virtual machines reside. For details, refer to the appropriate VSPEX Proven Infrastructure.

RAID 5 with SAS disks

Exchange database pool 1

The pool where all the Exchange database data of the first database copy reside.

Exchange database pool 2

The pool where all the Exchange database data of the second database copy reside.

Exchange log pool 1

The pool where all the Exchange log files of the first database copy reside.

Exchange log pool 2

The pool where all the Exchange log files of the second database copy reside.

RAID 1/0 with NL-SAS disks

Figure 6 shows an example of the high-level architecture of the Exchange components and storage elements, validated in the VSPEX Proven Infrastructure for virtualized Exchange Server on a Microsoft Windows Server 2012 Hyper-V virtualization platform and VNXe storage array. All the Exchange Server virtual machine boot volumes are stored in the new Hyper-V virtual hard disk format (VHDX) on the cluster-shared volume (CSV), and all the Exchange Server database and log volumes are stored in pass-through disks. In this example, DAG is configured on Exchange Server 2010 and each database has two copies.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

49

Chapter 5: Solution Design Considerations and Best Practices

Figure 6.

Exchange storage elements layered in VSPEX Hyper-V Proven Infrastructure

The EMC VNXe product family is designed around application-aware wizards, including Exchange, for storage provisioning. The Exchange wizard automatically incorporates many of the best practices for Exchange Server, along with recommendations specific to the VNXe platform, into the storage design without additional user intervention. It creates storage pools and Exchange data LUNs, based on the user input for Exchange Mailbox requirements. For more information on VNXe storage pool design for Exchange Server, see Table 15. Table 15.

50

Exchange related storage pools: Name and purpose on VNXe

Pool name

Purpose

VSPEX private cloud pool

The infrastructure pool where all the virtual machines reside. For details, refer to the appropriate VSPEX Proven Infrastructure.

Exchange data pool 1

The pool where all the Exchange database data and log files of the first database copy reside

Exchange data pool 2

The pool where all the Exchange database data and log files of the second database copy reside.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

RAID recommendation

RAID 5 with SAS disks

Chapter 5: Solution Design Considerations and Best Practices

For detailed steps on VNXe storage provisioning for Microsoft Exchange environments, refer to the Microsoft Exchange 2010 or Exchange 2007 on EMC VNXe Series Deployment Guide. Storage design best practices

In this VSPEX Proven Infrastructure for virtualized Exchange Server 2010, consider the following best practices for storage layout and design: 





Disk and RAID type selection for Exchange database and log 

On EMC VNXe storage platform, SAS disks provide high capacity with moderate I/O speed, which makes them highly suitable for Exchange Server 2010 environments. Use RAID 5 for Exchange data storage pool where Exchange database and log files reside. This is because RAID 5 provides high capacity utilization, with good I/O performance, at a low cost for VNXe.



On EMC VNX storage platform, NL-SAS disks are a good fit due to the less demanding I/O requirements of Exchange Server 2010 compared to previous versions of Exchange Server. These disks support large mailboxes at a relatively low cost. Using NL-SAS disks in RAID 1/0 configuration produces better performance and minimal or no performance impact in the event of disk failure.

Disk layout considerations for Exchange Server 2010 

Isolate the Exchange Server database workload to a different set of spindles from other I/O-intensive applications or workloads such as SQL Server. This ensures the highest level of performance for Exchange and simplifies troubleshooting in the event of a disk-related Exchange performance issue.



Place Exchange storage on separate disks from the guest OS physical storage.



If DAG is configured, deploy each DAG copy of the Exchange mailbox databases on its own set of physical disks.



In a mailbox resiliency deployment, you do not have to place the database files and logs from the same mailbox database onto different physical disks. However, you can separate database and log volumes into different storage pools or RAID groups for optimal performance.

Storage pool or RAID group selection for Exchange Server 2010 



Storage pools or RAID groups work well with Exchange Server 2010. Use the correct multiplier for best performance when designing storage pools: 

Eight (4+4) drives for RAID 1/0 pools



Five (4+1) drives for RAID 5 pools



Eight (6+2) drives for RAID 6 pools

When using VNX Snapshots, storage pools are required for the Exchange database and log files. For more information about VNX Snapshot considerations, refer to the Local protection design considerations section.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

51

Chapter 5: Solution Design Considerations and Best Practices



Thin LUN considerations for Exchange 2010 on VNX Thick LUN is recommended to meet the Exchange 2010 performance requirement. However, thin provisioning can provide significant savings when large mailboxes are deployed. Use these guidelines for deploying Exchange 2010 on thin LUNs:





Use thin LUNs for lower to medium Exchange 2010 user workloads.



RAID 1/0 configuration is recommended for thin LUNs.



Although it is not required, you should enable FAST Cache on pools with thin LUNs.

VNX for block It is a best practice to let the system balance the pool LUNs on both storage processor (SP) when you create the pool LUNs, which it does by default; if you must manually change the setting, EMC recommends you manually ensure balance between the SPs. Do not change the default owner of the pool LUN after you provision it. This can adversely affect performance. It changes the underlying private structures for pool LUNs that the original SP still controls. If you must change the SP ownership after you create the LUN, you can use LUN migration to migrate the LUN to a new LUN with the desired SP owner. Then perform a trespass operation for the LUN from its previous owner to the new owner



VNX for file When creating LUNs on VNX for file, consider the following best practices: a.

Create approximately one LUN for every four drives in the storage pool.

b.

Create the LUNs in even multiples of 10. Numbers of LUNs = (number of drivers in pool divided by four), rounded up to nearest multiple of 10.

c.

Make all the LUNs the same size.

d.

Balance LUN ownership across SPA and SPB.

For more information, refer to EMC VNX Unified Best Practices for Performance. 

VNXe The EMC VNXe series is designed around application-aware wizards for storage provisioning. The Exchange wizard automatically incorporates many of the best practices for Exchange Server, along with recommendations specific to the VNXe platform, into the storage design without additional user intervention. EMC recommends you use the Exchange provisioning wizard to provision the storage on VNXe.



VMware VMDK or RDM disk selection for Exchange Server 2010 In VMware environments, you can configure either VMDK or RDM to house Exchange Server 2010 data. However, if you use AppSync for Exchange Server protection, make sure that you configure the storage for the Exchange database and log files as RDM disks rather than VMDK virtual disks. For more information

52

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

about AppSync design considerations, refer to the Local protection design considerations section. 

SOAP Tool SOAP Tool is a utility that optimizes the thick LUNs in the VNX storage pool for maximum performance after LUN creation and before disk partitioning on the Exchange Server. Run this utility for customers who require uniform high performance and low latencies across all LUNs within a VNX storage pool. EMC recommends that you use this tool when deploying Exchange in storage pools but only on VNX systems with FLARE® releases before FLARE 32. For more information about this tool, visit the EMC Online Support website.



Use 64 KB of the file allocation unit size for the Exchange data volumes Format Windows New Technology File System (NTFS) volumes used for Exchange databases and logs with an allocation unit size of 64 KB.

For more information, refer to the Exchange best practices for EMC storage section. Storage layout examples

This section describes two example storage layouts in this VSPEX Proven Infrastructure for virtualized Exchange Server 2010—one small organization for VNXe and one medium organization for VNX, both based on VSPEX Private Cloud. Both of these examples follow the best practice and design considerations previously discussed. Table 16 shows an example of a storage layout to store Exchange data in addition to the VSPEX private cloud pool for a small Exchange organization. For more information about the user profile in this example, refer to Example 1: Exchange small configuration. Table 16.

Exchange data storage pools: Small Exchange organization Recommended additional storage layout

Storage pool name

RAID type

Disk type

Disk capacity

No. of disks

Exchange storage pool 1

RAID 5 (4+1)

15,000 rpm SAS disks

600 GB

10

Exchange storage pool 2

RAID 5 (4+1)

15,000 rpm SAS disks

600 GB

10

Figure 7 shows an example of the storage layout for a small Exchange organization for the VNXe series. The number of disks used in the VSPEX private cloud pool may vary according to your customer’s requirements. For detailed information, refer to the VSPEX Proven Infrastructures section.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

53

Chapter 5: Solution Design Considerations and Best Practices

Figure 7.

Storage layout example: Exchange organization for the VNXe series

Table 17 shows an example of a storage layout to store Exchange data in addition to the VSPEX private cloud pool for a medium Exchange organization. For more information about the user profile in this example, refer to Example 2: Exchange medium organization. Table 17.

Exchange data storage pools: Medium Exchange organization Recommended additional storage layout

Storage pool name

RAID type

Disk type

Disk capacity

No. of disks

Exchange database pool 1

RAID 1/0 (24+24)

7,200 rpm NL-SAS disks

2 TB

48

Exchange database pool 2

RAID 1/0 (24+24)

7,200 rpm NL-SAS disks

2 TB

48

Exchange log pool 1

RAID 1/0 (4+4)

7,200 rpm NL-SAS disks

2 TB

8

Exchange log pool 2

RAID 1/0 (4+4)

7,200 rpm NL-SAS disks

2 TB

8

Figure 8 shows an example of the storage layout in the Exchange organization for the VNX series. The number of disks used in the VSPEX private cloud pool may vary according to your customer’s requirements. For detailed information, refer to the VSPEX Proven Infrastructures section.

54

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

Figure 8. Note

FAST Suite design best practices

Storage layout example: Exchange organization for the VNX series

These are only two examples of a storage layout. To plan and design your own storage layouts for Exchange Server over a VSPEX stack, follow the guidance in the VSPEX Sizing Tool and the best practices in the Storage layout and design considerations section of this Design Guide.

The EMC FAST Suite—FAST VP and FAST Cache—provides two key technologies, available in the VNX series, that enable extreme performance in an automated fashion, when and where needed. You can use FAST Cache and FAST VP to achieve high performance and lower the total cost of ownership (TCO) from the storage system. For example, you can use Flash drives to create FAST Cache, and use FAST VP for storage pools consisting of SAS and NL-SAS disk drives. From a performance point of view, FAST Cache provides an immediate performance benefit to “bursty” data, while FAST VP moves more active data to SAS drives and less active data to NL-SAS drives. From a TCO perspective, FAST Cache can service active data with fewer Flash drives, while FAST VP optimizes disk utilization and improves efficiency with SAS and NL-SAS drives. FAST technology is an available option in VSPEX Proven Infrastructures. For more information on FAST Suite for VSPEX Proven Infrastructures, see the VSPEX Proven Infrastructures section. EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

55

Chapter 5: Solution Design Considerations and Best Practices

Due to the changes in Exchange 2010 storage architecture, resulting in lower I/O to storage devices and the trend to deploy larger mailboxes, many Exchange designs are capable of utilizing high-capacity, low revolutions per minute (rpm) drives (for example, 7.2k rpm NL-SAS). However, there are Exchange configurations with considerably higher I/O demands and smaller mailbox requirements that would benefit from adding the Flash drives and enabling the FAST VP or FAST Cache feature. When using FAST Cache to benefit Exchange performance, consider the following best practices: 

FAST Cache is not required on thick pool LUNs if snapshots are not used.



FAST Cache is strongly recommended on thin pool LUNs to offset metadata overhead.



Use FAST Cache when VNX Snapshots are enabled (thick or thin pool LUNs). For more information about design considerations for VNX Snapshots, refer to the Local protection design considerations section.



When using FAST Cache, separate the Exchange database files and log files into different storage pools and enable FAST Cache on the storage pools housing Exchange databases. Do not enable FAST Cache on Exchange log storage pools.

For FAST VP, customer requirements will determine whether to use it with Exchange Server 2010 on VNX. Compared to FAST Cache, which is a global resource in the array, FAST VP is used on a dedicated storage pool for a particular application. To ensure that FAST VP will benefit your design, evaluate your current Exchange configuration to identify any hot spots. When designing FAST VP for Exchange 2010 on VNX, follow these guidelines: 

When using FAST VP, do not place database files and log files in the same storage pool, because log files have a lower I/O requirement and do not need to be moved to a higher tier. Always place the log files in separate storage pools and always use RAID 1/0. This can greatly reduce VNX SP, bus, and disk utilization due to the way that the VNX FLARE operating environment and write cache handles small, sequential I/Os.



When using FAST VP with DAG, do not place DAG copies of the same database in the same storage pool on the same disks.



When using FAST VP, set the FAST policy for the participating pool LUNs to Start High then Auto-Tier (Recommended).

For more information about FAST VP, refer to the white paper EMC FAST VP for Unified Storage Systems. XtremSW Cache design best practices

When you enable XtremSW Cache, you have complete and flexible control over the scope and level of granularity. In physical environments, you can enable or disable XtremSW Cache at the source volume level or LUN level. In virtual environments, you can provision XtremSW Cache capacity to an individual virtual machine. The allocated cache capacity inside the virtual machine is then configured at the virtual disk level. To learn more about EMC XtremSW Cache, refer to the EMC VFCache Data Sheet.

56

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

When you configure XtremSW Cache for volumes housing Exchange databases, it accelerates block I/O reads that require the highest IOPS, the lowest response time, or both. The software uses the Peripheral Component Interconnect Express (PCIe) card to cache the most frequently referenced data, shrinking storage access time while offloading the I/O processing from the storage array. By residing in the server on the PCIe bus, XtremSW Cache bypasses the overhead of network storage access, thus reducing the response time. XtremSW Cache puts Exchange data into the server I/O stack, closer to the application, to dramatically improve performance. Our validation testing of XtremSW Cache with Exchange 2010 shows a significant reduction in user response times and increased throughput. If you have very heavy to extreme Exchange workload requirements that are greater than 250 messages per user per day, consider implementing an XtremSW Cache solution. Note

Performance gain and reduction in response time will vary based on each customer's Exchange email usage. EMC highly recommends that you use a pilot phase test in your environment to determine the exact benefits of this technology.

Virtualizing Exchange Server design considerations Overview of virtualizing Exchange Server design considerations

Exchange Server 2010 is supported in a virtual environment that uses Microsoft Hyper-V technology or VMware vSphere ESXi technology. For additional information on Microsoft support policies for virtualizing Exchange Server 2010, refer to the Microsoft TechNet topic Understanding Exchange 2010 Virtualization.

Design best practices

In this VSPEX Proven Infrastructure for virtualized Exchange Server 2010, EMC recommends that you consider the following best practices for virtualizing Exchange Server 2010: 

Spread the same Exchange server role across different physical hosts. For example, you may have several Exchange Hub Transport servers in your environment. In this scenario, for a redundancy consideration, EMC recommends that you spread these Hub Transport servers across different physical hosts.



If using DAG, spread DAG copies across multiple physical hosts to minimize potential downtime in the event of physical server issues.



Balance the workload by mixing the Exchange Server roles on each physical host. For example, you can mix the Mailbox server and HUB/CAS server virtual machines on a physical host to balance the workloads and prevent one physical resource from being unduly stressed.



For deployments of Exchange 2010 SP1 or SP2, you can combine Exchange Server virtual machines, including Exchange mailbox virtual machines that are part of a DAG, with host-based failover clustering and migration technology, provided you configure the virtual machines so that they do not save and restore state on disk when moved or taken offline.



Disable dynamic memory feature on Exchange Server virtual machines.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

57

Chapter 5: Solution Design Considerations and Best Practices



Monitor the performance of your whole VSPEX Proven infrastructure regularly. Monitoring performance happens not only at the virtual machine level, but also at the hypervisor level. For example, when the hypervisor is ESXi, you can use the performance monitoring tool inside the Exchange Server virtual machine to ensure virtual machine or Exchange Server performance. Meanwhile, at the hypervisor level, you can use esxtop to monitor host performance. For detailed information on the performance monitoring tool, refer to the Implementation Guides for Exchange section.

Local protection design considerations Overview of local protection design considerations

In Exchange Server 2010, the DAG feature provides local high availability for mailbox databases. You can deploy DAG and configure two or more copies of each mailbox database. In most cases, this is sufficient to protect Exchange during Mailbox server failure or maintenance. However, DAG does not provide protection from logical database corruption because such corruption can replicate to other copies. To protect your environment from logical corruption, implement VSS backup with point-in-time recovery. In this solution, EMC AppSync is used to initiate application-consistent snapshots on a VNX storage array. AppSync supports Exchange 2010 in standalone or DAG configurations. When adding an Exchange Mailbox server as a host, AppSync identifies whether it is an Exchange standalone or an Exchange DAG member server. If the server is a member of a DAG, by default AppSync will select one of the passive database copies for protection. Note

Design best practices

In this VSPEX Proven Infrastructure for virtualized Exchange Server 2010, EMC recommends that you consider the following best practices for using AppSync to protect Exchange 2010 on a VNX storage array: 

58

An Exchange Server 2010 lagged copy can also provide protection from database corruption. However, lagged copies cannot provide multiple pointin-time recoveries. After using a lagged copy for recovery, you must recreate (seed) it. This process may be resource and time consuming in some environments. For additional information about Exchange database corruption types and lagged copy limitations, refer to the Microsoft TechNet topic Managing Mailbox Database Copies.

Exchange configuration considerations: 

AppSync requires circular logging to be disabled on Exchange databases. Verify that circular logging is disabled in the Exchange Management Console under a database's properties.



For protection, a standalone Exchange database copy must be in the Mounted state. In a DAG, an active copy must be in the Mounted state, even when backing up a passive copy, and a passive copy must be in the Healthy state. It is possible that AppSync will exclude a database from the service plan run if the database is not in the recommended state.



For better restore flexibility, Exchange databases should not share volumes.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices







Partitioned disks are not supported.



Do not use nested mount points. For example, if logs are on L: and the database is on mountpoint L:\SG1DB1, AppSync will not be able to mount or restore the replica. Instead, create a very small LUN and put the L: volume on it. Then create two mount points on the volume—one for the database file and one for the transaction logs. The other option is to create the mount points on one of the volumes that are local to the server.



In VMware environments, AppSync requires the storage for Exchange database and log files to be configured as RDM disks, not VMDK virtual disks.

Exchange mount host requirements: 

The version of Windows on the mount host must match the version of Windows on the production host. The Exchange Management Tools must be installed, and the AppSync Exchange Interface service must be configured, if consistency check is desired. The Exchange Management Tools on the mount host must be at the same version and service pack level as on the production host.



The mount host must have visibility to the same storage array from which the original replica was created. In the case of a DAG environment, you may need more than one mount host if your replicas are created from different copies of the database.

VNX Snapshot considerations: 

VNX Snapshots use redirect-on-write (ROW) technology. ROW redirects new writes destined for the primary LUN to a new location in the storage pool, without the need to read or write to the old data block. Every VNX Snapshot has an 8 KB granularity. When a VNX Snapshot is created on a thick LUN, portions of its address space are changed to indirect mode. In other words, when writes come in to the snapped thick LUN, the LUN starts converting the address mapping from direct to 8 KB blocks for each portion of the thick LUN being written. The thick LUN remains to be classified as thick in the command line interface (CLI) and graphical user interface (GUI). The thick LUN stays in indirect mode while it contains VNX Snapshots. When the last snapshot of the thick LUN is removed, the mode automatically converts to direct. Operations on a thick LUN while in indirect mode might exhibit some overhead. So when using VNX Snapshots, you can use FAST Cache to mitigate this overhead. In this case, separate the Exchange database files and log files into different storage pools, and enable FAST Cache on the storage pools housing the Exchange databases. Do not enable FAST Cache on Exchange log storage pools.



VNX Snapshots are a part of the storage pool. A snapshot does not consume space from the pool until the new data is written to the primary LUN or to the snapshot itself. Enable proactive monitoring of the storage space used by the pool.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

59

Chapter 5: Solution Design Considerations and Best Practices



Do not perform excessive deletion of snapshots during busy array operations.

For more information, refer to the VNX Snapshots white paper and the AppSync User Guide.

Backup and recovery design considerations Overview of backup and recovery design considerations

Avamar solves the challenges associated with traditional backup, enabling fast, reliable backup and recovery for remote offices, data center LANs, and Exchange environments. Avamar is backup and recovery software that uses patented global data deduplication technology to identify redundant sub-file data segments at the source, reducing daily backup data up to 500 times before it is transferred across the network and stored to disk. This enables companies to perform daily full backups even across congested networks and limited WAN links. This guide is not intended to replace the core documentation for planning, implementation, or installation steps. It is to be referenced as a best practice for those activities.

Backup and recovery considerations

The use of Avamar plug-ins supports backup and recovery of Exchange ranging from entire databases to various object levels such as mailboxes or individual email items. Additional flexibility includes the ability to use activation priority in preferred server order lists, so that even if the preferred copy is not available for backup, Avamar will back up the next available copy. Back up the other components in the Exchange environment with the Avamar Client for Windows. This enables recovery for the Exchange databases and related Exchange servers. In the event that VMware is being protected by Avamar virtual machine image protection, you can restore the virtual machines without needing an Avamar client installed on the hosts. If they are Exchange Mailbox Server roles, you can restore the databases from Exchange Volume Shadow (Copy) Service (VSS) backups. The Avamar Exchange VSS plug-in relies on the base Avamar Windows Client and enables database backups. For disaster-level recovery, a virtual machine image recovery enables OS-level recovery. The database recovery is applied after those resources are restored. Note

The implementation of VMware or Hyper-V image-level protection is beyond the scope of this guide, but is a viable option to restore base operating systems.

The Avamar Configuration Checker provides assurance that prerequisites are met. When you run it, it provides a report that confirms all the required components are installed for MAPI and Collaboration Data Objects (CDO) access, as well as the Exchange configuration for Exchange Mailbox Server roles. The Backup User Configuration Tool is also provided when the Exchange VSS plug-in is installed. This tool creates the Avamar Backup User. The Avamar Backup User must have the relevant rights assigned to be able to back up and restore databases and mailbox or mail items. The Avamar services run as this user to enable those activities.

60

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

It is possible to configure a user manually. For more information about manually configuring a user, refer to the Avamar Exchange VSS documents in the EMC documentation section. Note

Using Data Domain as the backup target for Avamar is also an option. The Avamar client and plug-ins are installed in the same way as when using Avamar as the backup target. If Data Domain is used, the only difference is a checkbox in the dataset definition. This is included in the implementation steps in the Avamar Exchange VSS documents referenced in the EMC documentation section.

Figure 9 shows a map of the Avamar installation.

Figure 9. Backup strategies

Installation map

The Exchange data is stored in the Exchange Information Store, which contains the following data: 

Exchange database (EDB) files, including mailbox databases and public folder databases.



Transaction log (LOG) files that store database operations such as creating or modifying a message. After the operations are committed, they are written to the EDB file.



Checkpoint (CHK) files that store information about successful operations when they are saved to the database on the hard disk.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

61

Chapter 5: Solution Design Considerations and Best Practices

When you select an Information Store or any database for backup, Avamar backs up the database file and accompanying LOG and CHK files. The backup strategy for a Microsoft Exchange environment should include the following backups: 

Back up the following components with the Windows Exchange VSS plug-in: 

Databases



Stand-alone (non-DAG) databases



Active or passive databases in a DAG environment

On-demand backup in a stand-alone environment When you perform an on-demand backup in a stand-alone (non-clustering) environment, you can back up the entire Exchange Server or a specific Exchange 2010 database. Figure 10 illustrates the backup workflow for a stand-alone Exchange 2010 environment.

Figure 10.

Backup workflow for Exchange

On-demand backup in a high-availability environment With the Windows Exchange VSS plug-in, you can back up both the active node and the passive node in a high-availability Exchange configuration. In Exchange 2010, a physical server (node) can contain both active and passive databases, but not active and passive copies of the same database. To back up all passive databases on a node, select all databases on the physical node, and then select the option to only back up the replicas (passive copies). To back up all active databases on a node, select all databases on the physical machine, and then select the option to only back up the active databases. Figure 11 illustrates a non-federated backup of all of the databases in an Exchange 2010 DAG.

62

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

Figure 11.

Non-federated backup of all databases in the DAG

In this example, there are three Exchange servers, with active and passive copies of four mailbox databases. In a non-federated backup, each Exchange server is a separate Avamar client, so to back up all passive mailbox databases, perform a passive node backup for each physical server in the cluster. You could set up and schedule a backup dataset that includes the backups of all of these servers, MBX1, MBX2, and MBX3. However, when you run passive node backups against all servers in the cluster, you may end up with multiple passive node backups of the same database. While this does not cause any errors for Avamar, it consumes extra server and storage resources to back up and store duplicate copies of the same database. Backing up copies of the same database could impact deduplication results for that database by 60 percent or more. This is a direct result of how those databases are created. Microsoft uses log replay. Replaying the logs into the database copies results in unique data.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

63

Chapter 5: Solution Design Considerations and Best Practices

Note

Backing up the passive node is recommended because it has less impact on Exchange server performance and mail users. In some environments, such as a stand-alone Exchange server, you may not have a choice and must back up an active database because the system does not have passive databases or replicas. As a last resort for an environment that has multiple DAG copies, you would allow the backup job to address an alternate database copy. This is explained in the next section.

Federated backups In an Exchange 2010 DAG environment, passive and active databases can be of Exchange 2010 replicated across multiple nodes for high availability. Backups are created from the DAG environments passive databases, which can reduce the impact on production servers and resources. To back up all databases in the DAG environment using a conventional backup method requires you to back up all the passive databases on each Exchange server, even if a database has multiple passive copies replicated across several nodes. However, with the Avamar federated backup for Exchange 2010 DAGs, you can back up Exchange databases under the DAG name rather than each server. With a federated backup, you can specify the order that Avamar polls each server in the DAG for passive copies of each Exchange database. Avamar federated backups of Exchange 2010 DAGs use several key features: 

Avamar Cluster Client Configuration



Avamar Cluster Client Resource



Preferred Server Order List (PSOL)

This feature is not a requirement of the implementation but without it there is no automated ability to back up, only an alternate copy of a database.

64

Avamar Cluster Client Configuration

The Avamar Cluster Client Configuration tool identifies which servers in the DAG to include in the Avamar Cluster Client. Run the Avamar Cluster Configuration tool after installing the Avamar Windows Client and Windows Exchange VSS plug-in.

Avamar Cluster Client Resource

The Avamar Cluster Client Configuration tool creates a separate Avamar client for the DAG cluster. This configuration provides a separate client resource in Avamar Backup and Restore, which you can select instead of selecting each individual Exchange server in the DAG. The Avamar Cluster Client must have its own unique IP and domain name system (DNS) name to use. The DNS name is not the DAG name. The implementation steps must identify a unique name and IP address strictly for the Avamar Cluster Resource.

Preferred Server Order List

When you perform a backup through the DAG resource, Avamar selects an Exchange Server to back up the passive copies of the databases. Since multiple Exchange servers can host replicas or passive copies of the same database, you can specify a PSOL to tell Avamar which Exchange servers to use to back up the Exchange databases. When the backup order starts, Avamar backs up the passive or replica copies of each database, running the backups from the Exchange servers in the order specified in the PSOL.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 5: Solution Design Considerations and Best Practices

Figure 12 illustrates an example of a federated backup of a DAG cluster with three Exchange servers: MBX1, MBX2, and MBX3. The cluster contains four Exchange databases: DB1, DB2, DB3, and DB4.

Figure 12.

Federated backup of a DAG cluster example

Each database can have only one active copy, but can have multiple passive or replica copies. In this example, there are two passive copies of DB1, one copy on two different Exchange servers, MBX2 and MBX3. The other databases DB2, DB3, and DB4 only have one passive copy each in the cluster. Only one copy of each database needs to be backed up. The PSOL specifies that Avamar backs up the databases from the Exchange servers in this order: MBX2, MBX3, and MBX1.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

65

Chapter 5: Solution Design Considerations and Best Practices

Multistreaming

Multistreaming enables parallel processing of backup jobs using multiple processors. You can use as many as six streams. Each stream requires a separate processor core. By taking advantage of multiprocessors, you can improve backup performance when storing backups either on the Avamar server or on a Data Domain system. You can configure multistreaming to group backups by volume or by database. If volumes have varying database sizes, for example 500 GB on g:\, 100 GB on h:\, and 100 GB on z:\, it will take more time for streams to release the volumes with bigger sizes. For balanced multistreaming backup performance, choose by volume if all volumes are similar in overall size, or by database if all databases are similar in size. If databases are balanced across volumes, so that each database is about the same size and each volume contains about the same number of databases, then there will be little difference between grouping backups by database or volume. Multistreaming places additional demands on computer hardware resources beyond the base requirements for the Windows Exchange VSS plug-in. This is not to say that multistreaming should be negated, but it should be used with technical caution. Note

66

A clustered or DAG environment is not required for multistreaming, but it is highly recommended. When using multistreaming, Avamar consumes much more CPU resources than when backing up as a single stream. If the backup is being performed on an active Exchange server node, this could have an impact on email server performance and for end users, if there is no window where the application is not servicing a workload.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 6

Solution Verification Methodologies

This chapter presents the following topics:

Overview ..................................................................................................... 68 Baseline hardware verification methodology .............................................. 68 Application verification methodology ......................................................... 68 Backup and recovery verification methodology ........................................... 72

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

67

Chapter 6: Solution Verification Methodologies

Overview This chapter provides a list of items that you should review after configuring the solution. The goal of this chapter is to verify the functionality and performance of specific aspects of the solution, and ensure that the configuration supports core availability and performance requirements.

Baseline hardware verification methodology Hardware consists of the computer's physical resources such as processors, memory, and storage. Hardware also includes physical network components such as NICs, cables, switches, routers, and hardware load balancers. You can avoid many performance and capacity issues by using the correct hardware for the VSPEX for virtualized Exchange Server solution. For detailed steps on verifying the redundancy of the solution components, refer to the Implementation Guides for Exchange section.

Application verification methodology High-level steps for application verification

After verifying the hardware and redundancy of the solution components, the next stage is Exchange application testing and optimization, which is also a critical step of the VSPEX for virtualized Exchange Server solution. Test the new VSPEX Proven Infrastructure before deploying it to production to confirm that the architectures you designed achieve the required performance and capacity targets. This enables you to identify and optimize potential bottlenecks before they impact users in a live deployment. Table 18 describes the high-level steps to complete before you put the Exchange environment into production. Table 18.

High-level steps for application verification

Step

Description

Reference

1

Understand the testing tools: Microsoft Jetstress and LoadGen tools.

Understanding the testing tools

2

Understand the key metrics for your Exchange environment to achieve performance and capacity that meet your business requirements.

Understanding key metrics

3

Use the VSPEX Sizing Tool for Exchange to determine the architecture and resources of your VSPEX Proven Infrastructure.

EMC VSPEX website

Note In the event that the Sizing Tool is not available, you can manually size the application using the sizing guidelines Manually Sizing Exchange for VSPEX in Appendix B. 4

68

Build the test environment and create Exchange virtual machines on your VSPEX Proven Infrastructure.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Implementation Guides for Exchange

Chapter 6: Solution Verification Methodologies

Understanding the testing tools

Step

Description

Reference

5

Run the Microsoft Jetstress tool to verify that the Exchange storage design meets the key performance metrics. You do not need to install Exchange Server to run Jetstress testing.

Microsoft Exchange Server Jetstress 2010

6

Install Exchange Server roles in the virtual machines and deploy the Exchange organization.

Implementation Guides for Exchange

7

Run the Microsoft LoadGen tool to verify that the entire Exchange organization meets your business requirements.

Microsoft Exchange Load Generator

Microsoft Jetstress The Exchange 2010 storage design should be verified for expected transactional IOPS before it is placed in a production environment. To make sure that the environment functions appropriately, EMC recommends using the Microsoft Jetstress tool to verify 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) without requiring Exchange to be installed. To simulate the Exchange I/O accurately, Jetstress makes use of the same ESE.dll file that Exchange uses in production. Jetstress can be configured 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 verify that all of the hardware and software components within the I/O stack, from the operating system down to the physical disk drive, are capable of maintaining an acceptable performance level. You can download the 64-bit version of Jetstress 2010 from the Microsoft Exchange Server Jetstress 2010 (64 bit) space on the Microsoft website. Microsoft LoadGen The next step in the verification process is to use the Microsoft Exchange Server 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 verification testing. Perform all LoadGen verification testing in an isolated lab environment where there is no connectivity to production data. You can download the 64-bit version of LoadGen 2010 from the Exchange Load Generator 2010 (64 bit) space on the Microsoft website.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

69

Chapter 6: Solution Verification Methodologies

Understanding key Before running the Jetstress or LoadGen tools, it is important to know which key metrics to capture and what thresholds must be met for each metric when running the metrics tests. Table 19 lists the key metrics of Jetstress verification. Table 19.

Key metrics of Jetstress verification

Performance counters

Target values

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

Number of mailboxes * Exchange 2010 user IOPS profile

I/O database reads/sec

N/A (for analysis purpose)

I/O database writes/sec

N/A (for analysis purpose)

Total IOPS (I/O database reads/sec + I/O database writes/sec + BDM reads/sec + I/O log replication reads/sec + I/O log writes/sec)

N/A (for analysis purpose)

I/O database reads average latency (ms)

Less than 20 ms

I/O log reads average latency (ms)

Less than 10 ms

Table 20 lists the key metrics of LoadGen verification. Table 20. Server type

Mailbox server

70

Key metrics of LoadGen verification Performance counter

Target

Processor\%Processor time

Less than 80%

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

Less than 20 ms

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

Less than 20 ms

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

Less than 200 ms

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

Less than 200 ms

Exchange database\IO log read average latency

Less than 10 ms

Exchange database\IO log writes average latency

Less than 10 ms

ExchangeIS\RPC requests

Less than 70

ExchangeIS\RPC averaged latency

Less than 10 ms

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Less than read average

Chapter 6: Solution Verification Methodologies Server type

CAS/HUB combined servers

Determining the architecture

Performance counter

Target

Processor\%Processor time

Less than 80%

Exchange RpcClientAccess\RPC Requests

Less than 40

Exchange RpcClientAccess\RPC Averaged Latency

Less than 250 ms

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

Less than 3,000

ExchangeTransport Queues(_total)\Active Remote Delivery Queue Length

Less than 250

ExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length

Less than 250

To design the virtualized Exchange Server solution on the VSPEX Proven Infrastructure, all the factors described previously in this Design Guide should be considered—for example, storage layout, network load balancing, networking, and so on. EMC recommends using the VSPEX Sizing Tool to determine the number of Exchange Server virtual machines required for your customer’s Exchange organization, and the resources (such as the processor, memory, and so on) required for each server role, according to your business needs.

Building the infrastructure environment

The next step is to build the solution environment and to create Exchange virtual machines in your VSPEX Proven Infrastructure, based on the information in the Implementation Guides for Exchange. Note

Exchange Server does not need to be installed for Jetstress testing.

Using the Jetstress Jetstress can automatically compare the observed performance results against a set of acceptable values after each test. These results are then written to a HTML report tool file. For more details on how to use the Jetstress tool and interpret the Jetstress report, refer to the Jetstress Field Guide whitepaper on the Microsoft TechNet website. Deploying the Exchange organization

After completing the storage verification with Jetstress and determining that the storage is sized correctly and performs as expected, install the Exchange server roles in the virtual machines and deploy the Exchange organization. Note

Perform all LoadGen verification testing in an isolated lab environment where there is no connectivity to production data.

For detailed information, refer to the corresponding section in the Implementation Guides for Exchange.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

71

Chapter 6: Solution Verification Methodologies

Using the LoadGen During the LoadGen verification, it is important to define the appropriate test scenarios based on the business requirements. EMC suggests verifying the overall tool performance under normal operating conditions as well as under a disaster condition with server failures. 

Normal operating condition: The objective is to verify the entire Exchange environment’s performance under normal operating conditions. Run a 10-hour LoadGen with 100 percent concurrency test under normal operating conditions.



Server failures condition: The objective is to verify the entire Exchange environment's performance under a server failure condition where a portion of the Mailbox and HUB/CAS servers fail and the rest of the servers support all the mailboxes in the Exchange organization. Run a 10-hour LoadGen with 100 percent concurrency test during the server failures. The maximum number of failed servers without impact to end-user experience is dependent on your Exchange and DAG configuration.

Note

The server failure test scenario can also be used to verify the functionality of CAS array and DAG. For more information, refer to the Implementation Guides for Exchange section.

The validity of each LoadGen test is determined by comparing the results of selected performance counters to Microsoft-specified criteria. Use Windows Performance Monitor to collect performance counter results. For more information, refer to the Microsoft TechNet topic Performance and Scalability Counters and Thresholds.

Backup and recovery verification methodology Verifying backup and recovery

Verification of the Exchange backup and recovery implementation requires a number of recovery options. The highest level is to recover an entire database. For Exchange 2010, it should be recovered into a recovery database (RDB). Confirm other lowerlevel elements in the event that the environment is configured with granular-level recovery (GLR). When recovering mailboxes or lower-level objects, consider backup and recovery steps. Backup and recovery steps Specific steps for the backup and recovery of these objects are mapped out in detail in the core Avamar Exchange VSS documentation:

72



EMC Avamar 6.1 for Exchange VSS User Guide



EMC Avamar 6.1 Operational Best Practices



EMC Avamar 6.1 Administration Guide

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 7

Reference Documentation

This appendix presents the following topics:

EMC documentation................................................................................... 74 Other documentation ................................................................................. 75 Links ......................................................................................................... 75

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

73

Chapter 7: Reference Documentation

EMC documentation The following documents, available from the EMC Online Support or EMC.com websites, provide additional and relevant information. If you do not have access to a document, contact your EMC representative.

74



EMC VNXe3150 Installation Guide



EMC VNXe Series Using a VNXe System with NFS Shared Folders



EMC VNXe Series Using a VNXe System with Generic iSCSI Storage



EMC VNXe Series Using VNXe System with Microsoft Exchange



EMC VNXe Series Using an EMC VNXe System with VMware



EMC VNXe Series Using an EMC VNXe System with Windows Hyper-V



VNX Snapshots—White Paper



Microsoft Exchange 2010 or Exchange 2007 on EMC VNXe Series—Deployment Guide



EMC Host Connectivity Guide for VMware ESX Server



EMC Host Connectivity Guide for Windows



EMC FAST VP for Unified Storage Systems—White Paper



TechBook: Using EMC VNX Storage with VMware vSphere



PowerPath/VE for VMware vSphere—Installation and Administration Guide



PowerPath for Windows—Installation and Administration Guide



VFCache Installation Guide for VMware



VFCache VMware VSI Plug-in—Administration Guide



EMC AppSync—Installation and Administration Guide



EMC AppSync—User Guide



EMC VSI for VMware vSphere: Storage Viewer—Product Guide



EMC VSI for VMware vSphere: Unified Storage Management—Product Guide



EMC VFCache Data Sheet



EMC Avamar 6.1 for Exchange VSS—User Guide



EMC Avamar 6.1—Administration Guide



EMC Avamar 6.1 for VMware—User Guide

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Chapter 7: Reference Documentation

Other documentation For documentation on Microsoft Exchange, refer to the Microsoft website at http://www.microsoft.com. For documentation on VMware vSphere and vCenter, refer to the VMware website at http://www.vmware.com.

Links Microsoft TechNet Refer to the following topics on the Microsoft TechNet website: 

Add a Mailbox Database Copy



Deploy a Highly Available Virtual Machine



Deploying High Availability and Site Resilience



Exchange 2010 Prerequisites



Install the Hyper-V Role and Configure a Virtual Machine



Jetstress Field Guide



Manage Exchange Diagnostic Logging Levels



Managing Database Availability Groups



Managing Mailbox Database Copies



Microsoft Exchange Analyzers



Microsoft Exchange Load Generator



Microsoft Exchange Server Jetstress 2010



Mailbox Server Processor Capacity Planning



Network Load Balancing Deployment Guide



Performance and Scalability Counters and Thresholds



Understanding Database and Log Performance Factors



Understanding Exchange 2010 Virtualization



Understanding a New Installation of Exchange 2010



Understanding RPC Client Access



Understanding Server Role Ratios and Exchange Performance



Understanding the Mailbox Database Cache

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

75

Chapter 7: Reference Documentation

Microsoft support Refer to the following topics on the Microsoft Support website: 

Interoperability between MSCS and NLB



On a Microsoft Windows Server 2008 R2 Fail over cluster with a Hyper-V guest with many pass-through disks, the machine configuration may take some time to come online

Note

76

The links provided were working correctly at the time of publication.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Appendix A

Qualification Worksheet

This appendix presents the following topics:

Qualification worksheet ............................................................................. 78

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

77

Qualification worksheet Before you start sizing the VSPEX for virtualized Exchange Server solution, use the qualification worksheet to gather information about the customer’s business requirements. Table 21 provides a qualification worksheet for an Exchange organization. Table 21.

Qualification worksheet for an Exchange organization

Question

Answer

Number of mailboxes? Maximum mailbox size (GB)? Mailbox IOPS profile (messages sent/received per mailbox per day)? DAG copies (including active copy)? Deleted Items Retention (DIR) Window (days)? Backup/Truncation Failure Tolerance (days)? Snapshot (days retained)? Included number of years’ growth? Annual growth rate (number of mailboxes, %)?

Printing the worksheet for customer use

78

A standalone copy of the VSPEX for virtualized Exchange Server qualification worksheet is attached to this PDF. Click the paper clip icon in the left-hand pane of Adobe Reader to reveal the attachment. Double-click the file to open the qualification worksheet and print it from your browser.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Appendix B

Manually Sizing Exchange for VSPEX

This appendix presents the following topic:

Manually sizing Exchange for VSPEX........................................................... 80

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

79

Manually sizing Exchange for VSPEX Overview

Properly configured Exchange storage, combined with optimally sized server and network infrastructures, can guarantee smooth Exchange operation and excellent user experience. This section introduces the procedure for manually sizing Exchange for VSPEX, including how to calculate reference virtual machine and storage resources to support a specific number of Exchange Server 2010 users. The amount of required resources is derived from your customer’s detailed requirements. Note

Exchange manual sizing procedure

If the VSPEX Sizing Tool is not available, these manual sizing instructions may be used to provide an approximate single-application sizing. The VSPEX Sizing Tool, with its multiapplication and multi-instance capability is recommended as the preferred sizing approach.

Before sizing Exchange Server, it is important to gather and understand the infrastructure requirements and limitations, and the estimated workload. The VSPEX for virtualized Exchange Server qualification worksheet presents a list of simple questions to help identify customer requirements, usage characteristics, and datasets. For a one-page EMC qualification worksheet for the VSPEX Proven Infrastructure for virtualized Exchange Server, see the Qualification worksheet section in Appendix A. Table 5 provides a detailed explanation of the questionnaire and general guidance on how to determine input values on this qualification worksheet. Table 22 shows an example of the qualification worksheet with customer requirements entered. This is the example used to introduce the Exchange manual sizing methodology in following sections. To meet a customer requirement of 9,000 mailboxes with one year’s 11 percent growth rate in the number of mailboxes, you should size for 10,000 mailboxes in total. Table 22.

Example VSPEX qualification worksheet

Question

Example answer

Number of mailboxes?

9,000

Maximum mailbox size (GB)?

1.5 GB

Mailbox IOPS profile (messages sent/received per mailbox per day)?

0.15 IOPS per mailbox (150 messages sent/received per mailbox per day)

DAG copies (including active copy)?

2

Deleted Items Retention (DIR) Window (days)?

14

Backup/Truncation Failure Tolerance (days)?

3

Snapshot (days retained)?

0

Included number of years’ growth?

1

Annual growth rate (number of mailboxes %)?

11%

After you determine the customer’s requirement, refer to the process flow in Table 23 to manually size Exchange 2010 for VSPEX.

80

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

Table 23.

Exchange manual sizing procedure

Step

Action

1

Determine the number of each Exchange server roles for your customer’s environment, and calculate reference virtual machine resources, including vCPU, memory, OS capacity and OS IOPS.

2

Calculate the storage resources for both IOPS and capacity requirements.

3

Finalize the calculation and choose the right VSPEX Proven Infrastructure to meet your customer’s requirement.

Reference virtual machine sizing

vCPU sizing When sizing the Exchange Server virtual machines, follow the same rules for sizing Exchange on the physical servers. Always size the Exchange Mailbox server first. The first step is to determine how many mailboxes will be hosted on each Exchange Mailbox server virtual machine and how many Exchange Mailbox servers are needed in the environment. Use the following guidelines for sizing: 

If there is only one copy for each mailbox database (DAG is not configured), each Exchange Mailbox server can host up to 4,000 mailboxes



If there are two copies for each mailbox database (DAG is configured), each Exchange Mailbox server can host up to 3,000 active mailboxes and 3,000 passive ones.

Therefore, in our example, 10,000 active mailboxes and 10,000 passive ones (two copies for each mailbox database) require four Exchange Mailbox servers in total. The second step is to calculate the vCPU requirement for each Exchange Mailbox server virtual machine. Use the following steps for the sizing procedure: 1.

Calculate how many active and passive mailboxes are hosted on each Exchange Mailbox server. Consider that in a server failure situation if one Exchange Mailbox server fails, the surviving Mailbox servers have to support all the active mailboxes in the environment.

2.

Estimate the CPU megacycles requirement for each mailbox, based on the mailbox IOPS profile and DAG configuration. For detailed information about CPU estimates on different mailbox IOPS profiles, refer to the Microsoft TechNet topic Mailbox Server Processor Capacity Planning.

3.

Calculate the total CPU megacycles requirement for each Exchange Mailbox server, and then calculate how many vCPUs are needed on each Exchange Mailbox server, according to the type of server processor your customer will use. Provision sufficient megacycles so that CPU utilization does not exceed 80 percent. For detailed steps on megacycles calculation, refer to the Microsoft TechNet topic Mailbox Server Processor Capacity Planning.

In this example, if we choose Intel Xeon X5550, 2.67 GHz as the server processor, we will need four vCPUs for each Exchange Mailbox server virtual machine.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

81

From the HUB/CAS server’s perspective, the HUB/CAS combined role has a 1:1 CPU core ratio to the Mailbox server. For more information, refer to the Microsoft TechNet topic Understanding Server Role Ratios and Exchange Performance.

Memory sizing Similar to vCPU sizing, the mailbox IOPS profile and the number of active and passive mailboxes determine the detailed memory requirement for each Exchange Mailbox server virtual machine. Use the following steps for the sizing procedure: 1.

Calculate how many active and passive mailboxes are hosted on each Exchange Mailbox server. Again, consider that in a server failure situation, if one Exchange Mailbox server fails, the surviving Mailbox servers have to support all the active mailboxes in the environment.

2.

Estimate the memory requirement for each mailbox based on mailbox IOPS profile and DAG configuration, and calculate the total memory requirement for each Exchange Mailbox server. For detailed steps, refer to the Microsoft TechNet topic Understanding the Mailbox Database Cache.

In this example, we need to have 48 GB of memory configured for each Exchange Mailbox server. For the Exchange HUB/CAS combined server, we recommend 8 GB of memory.

OS capacity sizing For each Exchange virtual machine, the capacity is fixed to 100 GB. This example has eight Exchange virtual machines in total. For detailed information, refer to the VSPEX Proven Infrastructures section.

OS IOPS sizing The OS IOPS is fixed to 25 IOPS per OS volume on each Exchange virtual machine. This example has eight Exchange virtual machines in total. For detailed information, refer to the VSPEX Proven Infrastructures section.

Reference virtual machine summary After you have obtained the sizing results for the vCPU, memory, OS capacity, and OS IOPS, you can determine the reference virtual machine resources needed for Exchange deployment. As shown in Table 24, the reference virtual machine in VSPEX solutions is defined as a measure unit of a single virtual machine to quantify the compute resources in the VSPEX virtual infrastructure. Table 24.

82

Reference virtual machine: Characteristics

Characteristic

Value

Virtual processors per virtual machine

1

RAM per virtual machine

2 GB

Available storage capacity per virtual machine

100 GB

Input/output operations per second (IOPS) per virtual machine

25

I/O pattern

Random

I/O read:write ratio

2:1

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

In this example, we need four Exchange Mailbox servers and four Exchange HUB/CAS combined virtual machines. Then we determine the equivalent number of reference virtual machines required for each Exchange server role by calculating the maximum of the individual resources (CPU, memory, capacity, and IOPS), as shown in Table 25. Table 25.

Summary of reference virtual machine resources

Exchange server role

vCPU

Memory (GB)

OS volume capacity

OS volume IOPS

No. of virtual machines

Total reference virtual machines

Mailbox server

Equivalent reference virtual machines

4

24

1

1

4

96

HUB/CA S server

Equivalent reference virtual machines

4

4

1

1

4

16

Total equivalent reference virtual machines

112

For example, each Mailbox server requires four vCPUs, 48 GB of memory, 100 GB of storage, and 25 IOPS. This translates to: 

Four reference virtual machines of CPU



Twenty-four reference virtual machines of memory



One reference virtual machine of capacity



One reference virtual machine of IOPS

The values round up to 24 reference virtual machines for each Mailbox server, multiplied by the number of virtual machines needed (four in this example), which results in 96 total reference virtual machines for the Mailbox server role: 24 reference virtual machines x 4 virtual machines = 96 total reference virtual machines

For more details about how to determine the equivalent reference virtual machines, refer to the appropriate document in Essential reading. Storage sizing for Exchange Mailbox server To size storage requirements, calculate the IOPS requirement first, and then calculate capacity requirement. Determine the final disk number by consolidating the results from the IOPS and capacity requirement calculations. As a best practice, EMC recommends using 7.2k rpm 2TB NL-SAS drives in a RAID 1/0 configuration on the VNX series to house the Exchange database and log files. As a best practice, EMC also recommends separating the database and log volumes into different storage pools for optimal performance. Therefore, calculate the storage requirements for the Exchange database and log files separately. Note

For VNXe series, the built-in Exchange provisioning wizard automatically incorporates many of the best practices for Exchange Server, along with recommendations specific to the VNXe platform, into the storage design without additional user intervention. EMC recommends using the VNXe EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

83

Exchange provisioning wizard to size the storage. For more information, refer to Microsoft Exchange 2010 or Exchange 2007 on EMC VNXe Series—

Deployment Guide.

Exchange storage IOPS calculation It is important to understand the amount of database IOPS consumed by each mailbox user because it is one of the key transactional I/O metrics needed for adequately sizing your storage. To determine the IOPS for different mailbox profiles, refer to the relevant table provided in the following Microsoft TechNet topic Understanding Database and Log Performance Factors. Use the following steps for the sizing procedure: 1.

Calculate the total database IOPS required to support all mailbox users using the building block methodology as follows: Total transactional IOPS = IOPS per mailbox * mailboxes per server * (1 + I/O overhead factor)

Add the 20 percent overhead suggested by Microsoft and add another 20 percent overhead required by EMC for additional I/O activities such as Background Database Maintenance (BDM). Do not confuse the EMCrequired 20 percent overhead, which must be added, with the Microsoftsuggested 20 percent overhead, which your customer may or may not choose to add. In this example, 0.15 * 5000 * (1 + 20% + 20%) = 1,050 IOPS. In the step above, we determined that the IOPS requirement is to support one Exchange Mailbox server of 5,000 mailboxes (both active and passive). The total IOPS required for 20,000 users mailboxes (both active and passive) is 4,200 (1,050 IOPS * 4). 2.

Calculate the number of disks required to provide the desired user performance for Exchange database, based on the IOPS requirements using the formula: Disks required for Exchange database IOPS = (Total backend database Read IOPS + Total backend database Write IOPS) / Physical Disk Speed = ((Total transactional IOPS * Read Ratio) + (RAID Write Penalty *( Total transactional IOPS * Write Ratio)) / Physical Disk Speed

84

Where:

Is:

Total transactional IOPS

The IOPS calculated in Step 1.

Read Ratio

The percentage of I/Os that are reads (60% for Exchange 2010).

Write Ratio

The percentage of I/Os that are writes (40% for Exchange 2010).

RAID Write Penalty

The RAID write penalty multiplier (RAID1/0=2).

Physical Disk Speed

65 Exchange 2010 database IOPS for 7,200 rpm NL-SAS drives.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

In this example, to support an Exchange database IOPS requirement for 20,000 mailboxes using 7,200 rpm NL-SAS drives, we need: (4200 * 0.6) + 2 * (4200 * 0.4) / 65 = 5880 / 65 = 90.46 (round-up to 96 disks)

3.

Calculate the number of disks required to provide the desired user performance for Exchange log files, based on the IOPS requirements by using the formula shown below: Disks required for Exchange log IOPS = (50% * Total backend database Write IOPS)/ Physical Disk Speed Where:

Is:

Total backend database Write IOPS

The IOPS calculated in Step 2.

Physical Disk Speed

180 Exchange 2010 sequential log IOPS as Physical Disk Speed for sequential log I/O.

In this example, to support and Exchange log IOPS requirement for 20,000 mailboxes by using 7,200 rpm NL-SAS drives, we need: 0.5 * 3360 / 180 = 1680 / 180 = 9.33 (round-up to 16 disks)

Exchange storage capacity calculation After the IOPS calculation, you need to calculate the disk number to meet Exchange capacity requirement. It is important to determine the mailbox size on disk will be, before attempting to determine your total storage requirements. A full mailbox with a 1.5 GB quota, for example, requires more than 1.5 GB of disk space because we have to account for the maximum mailbox size and also the deleted item retention window (including calendar version logging and single item recovery if enabled). Use the following steps for the sizing procedure: 1.

Use the following calculations to determine the mailbox size on disk: Mailbox size on disk = Maximum mailbox size + White space + Dumpster Where:

Is:

White space

Email messages sent/received per user per day * average message size. In this example, a mailbox in 0.15 IOPS profile sends and receives in total 150 email messages per day on average, so the whitespace = 150 * 75 / 1024 = 11 MB.

Dumpster

Email messages sent/received per user per day * average message size * deleted item retention window + Maximum mailbox size * 0.012 + Maximum mailbox size * 0.03. In this example, it is 150 * 75 * 14 / 1024 + 1536 * 0.012 + 1536 * 0.03 = 218 MB.

In this example, the mailbox size on disk is 1,536 + 11 + 218 = 1,765 MB.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

85

2.

To determine the total database LUN size, use the following formula: Total database LUN size = Number of mailboxes * Mailbox size on disk * (1 + Data overhead factor + Index space) / (1 + LUN free space)

In this example, considering 10 percent is needed for the data overhead factor (for unexpected data growth), 10 percent for the Index, and 20 percent for LUN-free protection, the database size will be 20,000 * 1,765 MB * (1 + 0.1 + 0.1) / (1 - 0.2) / 1,024 = 51,709 GB 3.

To determine the total log LUN size, use the following formula: Total log LUN size = Log size * Number of mailboxes * Backup/truncation failure tolerance days / (1 + LUN free space)

To ensure that the Mailbox server does not sustain any outages because of space allocation issues, make sure to size the transaction logs LUNs to accommodate all of the logs that will be generated during the backup set. If the architecture uses the mailbox resiliency and single item recovery features as the backup architecture, the log capacity should allocate enough space in case there is any backup or truncation failure (for example, a failed database copy prevents log truncation from occurring). In this example, the backup/truncation failure tolerance window is 3 days. A mailbox with a 0.15 IOPS profile generates 30 transaction logs per day on average, so in this example, the total log LUN size = (30 logs * 1MB) * 20,000 * 3 / 1,024 / (1 - 0.2) = 2,197 GB. 4.

To determine the number of disks, use the following formulas: Disks required for Exchange database capacity = Total database LUN size / Physical Disk Capacity * RAID penalty Disks required for Exchange log capacity = Total log LUN size) / Physical Disk Capacity * RAID penalty

In our example, each 2 TB NL-SAS disk provides 1,834 GB of raw capacity. The RAID penalty is 2 due to RAID 1/0 configuration, so the number of disks required for Exchange database capacity is 51,709 / 1,834 * 2 = 56. The number of disks required for Exchange log capacity is 2,197 / 1,834 * 2 = 2.4 (round up to 4).

Additional considerations if VNX snapshot is needed In this example, the customer does not need VNX snapshot; however, if your customer wants to enable VNX snapshot as local protection for Exchange, EMC recommends enabling FAST Cache on the VNX storage array. In this case, separate the Exchange database files and log files into different storage pools, and enable FAST Cache only on the storage pools housing the Exchange databases. For 1,000 GB Exchange data on the disk, allocate 1 GB Flash for FAST Cache. VNX snapshots are part of the storage pool. A snapshot does not consume space from the pool until the new data is written to the primary LUN or to the snapshot itself. If VNX snapshot is enabled, according to the verification test results for VSPEX,

86

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

consider adding 3 percent of the Exchange data on the disk for one-day snapshot space (up to eight snapshots per day) when you calculate the capacity requirement for the Exchange database.

Final storage calculation results At this stage, compare the results from IOPS calculation and capacity calculation and select the larger number to meet both requirements. In this example, as a final result, you need 96 * 2 TB 7,200 rpm NL-SAS disks in RAID 1/0 for the Exchange database, and 16 * 2 TB 7,200 rpm NL-SAS disks in RAID 1/0 for the Exchange log files. Table 26 shows a summary of the results in this example. Table 26. Data

Disk number required for IOPS and capacity

Calculation results

Final results

Disk type

Disk capacity

96 disks to meet IOPS requirement Exchange database

96 disks

56 disks to meet capacity requirement

7,200 rpm NL-SAS disks

16 disks to meet IOPS requirement Exchange log

2 TB

16 disks

4 disks to meet capacity requirement

As a best practice, separate different DAG copies for each database into different physical disks. In this example, we can configure dedicated storage pools for each database copy, and separate the Exchange database and log files into different storage pools. Table 27 shows the final storage layout in this example, based on the final disk number we determined in Table 26. Table 27.

Exchange data storage pool configuration Recommended Exchange data storage layout

Storage pool name Exchange database pool 1 Exchange database pool 2 Exchange log pool 1 Exchange log pool 2

RAID type

Disk type

Disk capacity

48

RAID 1/0 (24+24) 7,200 rpm NL-SAS disks RAID 1/0 (4+4)

No. of disks

2 TB

48 8 8

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

87

Selecting the right VSPEX Proven Infrastructure Once you have completed the application sizing and determined the numbers of reference virtual machines and suggested disk storage layouts, refer to the following steps to choose the right VSPEX Proven Infrastructure, based on the calculated results: 1.

Use the manual sizing logic and methodology to get the total number of reference virtual machines (RVM) and suggested Exchange data storage layout. In this example: ExchangeRVM = Total reference virtual machine required for Exchange = 112 RVMs ExchangeDisks = Total disk numbers required for Exchange = 112 Disks

2.

If customers want to deploy other applications in the same VSPEX Proven Infrastructure, refer to the appropriate VSPEX design guide for the applications and size the total number of reference virtual machines and storage layouts with the combined workload. For example, if customers want to deploy SQL Server 2012 and Oracle 11g in the same VSPEX Proven Infrastructure, refer to EMC VSPEX For virtualized Microsoft SQL Server 2012–Design Guide to size SQL Server 2012 manually and EMC VSPEX for virtualized Oracle 11g–Design Guide to size Oracle 11g manually. For example, you could get the following results: SQLRVM = Total reference virtual machines required for SQL Server 2012 = 12 RVMs SQLDisks = Total disk numbers suggested for SQL Server 2012 = 7 Disks OracleRVM = Total reference virtual machines required for Oracle 11g = 16 RVMs OracleDisks = Total disk numbers suggested for Oracle 11g= 55 Disks

3.

Aggregate the total number of reference virtual machines and total disk numbers for all applications. In this example: TotalRVMforApps = SQLRVM + ExchangeRVM + OracleRVM = 12 RVMs + 112 RVMs + 16 RVMs = 140 RVMs TotalDisksforApps = SQLDisks + ExchangeDisks + OracleDisks = 7 Disks + 112 Disks + 55 Disks = 174 Disks

4.

Discuss with your customers the maximum utilization of the VSPEX Proven Infrastructure for the application and virtualization solution that they want to use to meet their business requirements. Calculate the total disks and reference virtual machines suggested for the combined applications. In this example, since Oracle will be also deployed in the VSPEX Proven Infrastructure, EMC recommends using VMware as the virtualization solution, enabled by VNX. If customers want a maximum 75 percent utilization for all the combined applications, the calculation would be: TotalRVMNeededforAppsFinal = TotalRVMforApps / Maximum Utilization = 140 RVMs / 75% = 187 RVMs TotalDisksNeededforAppsFinal = TotalDisksforApps / Maximum Utilization = 174 Disks / 75% = 232 Disks

88

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

5.

Use the details in Table 28 and the total number of reference virtual machines to select the minimum recommended VSPEX Proven Infrastructure. In this example, EMC recommends you select VSPEX Private Cloud for VMware up to 250 reference virtual machines as the minimum VSPEX Proven Infrastructure for the combined workload.

Table 28.

VSPEX storage model support matrix VSPEX Proven Infrastructure model*

Maximum supported reference virtual machines

Supported storage array

Up to 50 virtual machines

50

VNXe3150

Up to 100 virtual machines

100

VNXe3300

Up to 125 virtual machines

125

VNX5300

Up to 250 virtual machines

250

VNX5500

Up to 500 virtual machines

500

VNX5700

* Includes the following VSPEX models:

6.



VSPEX Private Cloud for Microsoft



VSPEX Private Cloud for VMware

Refer to the appropriate VSPEX Proven Infrastructure and calculate the disk number required for the VSPEX private cloud pool by using the virtual infrastructure building-block methodology. In this example, EMC suggests you select a VSPEX Private Cloud for VMware up to 250 reference virtual machines as the minimum VSPEX Proven Infrastructure. After referring to the building block of the VSPEX private cloud pool, you get the total disks number required: TotalDisksForPrivateCloud = 5 SAS Disks + 2 Flash Disks = 7 Disks

7.

Aggregate the total disk numbers required, including those for the combined applications, VSPEX private cloud pool, and the hot spare. TotalDisks = TotalDisksNeededforAppsFinal + TotalDisksForPrivateCloud + HotSpare = 232 Disks + 7 Disks + 8 Disks = 247 Disks

8.

Compare with the values in Table 29 to make sure the VSPEX Proven Infrastructure supported array can support the total disk numbers required. If not, you may need to upgrade to the next model of VSPEX Proven Infrastructure.

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide

89

In this example, EMC suggests a VSPEX Private Cloud for VMware up to 250 reference virtual machines as the VSPEX Proven Infrastructure and VNX5500 as the storage array. VNX5500 can support up to 250 disks in total, which can meet the requirement of 247 disks. As a result, EMC recommends you consider the VSPEX Private Cloud for VMware up to 250 reference virtual machines for the final selection. Table 29.

90

Storage system and drives Storage system

Maximum number of drives

VNXe3150

100

VNXe3300

150

VNX5300

125

VNX5500

250

VNX5700

500

EMC VSPEX for Virtualized Microsoft Exchange 2010 Design Guide