EMC VSPEX for Virtualized Microsoft Exchange 2013€¦ · Contents EMC VSPEX for Virtualized...

DESIGN GUIDE

EMC VSPEX FOR VIRTUALIZED MICROSOFT EXCHANGE 2013

EMC VSPEX

Abstract

This Design Guide describes how to design virtualized Microsoft Exchange Server 2013 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.

June 2013

2 EMC VSPEX for Virtualized Microsoft Exchange 2013 Design Guide

Copyright © 2013 EMC Corporation. All rights reserved. Published in the USA.

Published June 2013.

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

The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

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 listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

EMC VSPEX for Virtualized Microsoft Exchange 2013 Design Guide

Part Number H11766

http://www.emc.com/legal/emc-corporation-trademarks.htm

http://www.emc.com/legal/emc-corporation-trademarks.htm

Contents


Contents

Chapter 1 Introduction 7

Purpose of this guide .......................................................................................... 8

Business value ................................................................................................... 8

Scope ............................................................................................................... 9

Audience ........................................................................................................... 9

Terminology ..................................................................................................... 10

Chapter 2 Before You Start 11

Deployment workflow ....................................................................................... 12

Essential reading .............................................................................................. 12

VSPEX Solution Overviews ............................................................................ 12

VSPEX Implementation Guides ...................................................................... 12

VSPEX Proven Infrastructures ........................................................................ 13

Chapter 3 Solution Overview 15

Overview ......................................................................................................... 16

Solution architecture ........................................................................................ 16

Key components ............................................................................................... 17

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

Microsoft Exchange Server 2013 .................................................................... 17

EMC VSPEX Proven Infrastructures ................................................................. 18

EMC VNX and EMC VNXe series ...................................................................... 19

EMC Unisphere ............................................................................................ 21

VMware vSphere 5.1 .................................................................................... 22

Microsoft Windows Server 2012 with Hyper-V ................................................. 22

MPIO and MCS ............................................................................................. 23

EMC Virtual Storage Integrator for VMware vSphere ......................................... 23

EMC Storage Integrator ................................................................................. 23

EMC XtremSW Cache .................................................................................... 24

EMC PowerPath ............................................................................................ 24

Chapter 4 Choosing a VSPEX Proven Infrastructure 25

Overview ......................................................................................................... 26

Step 1: Evaluate the customer use case .............................................................. 26

Overview ..................................................................................................... 26

Contents


VSPEX for virtualized Exchange 2013 qualification worksheet ........................... 26

Step 2: Design the application architecture ......................................................... 28

Overview ..................................................................................................... 28

VSPEX Sizing Tool ........................................................................................ 28

Step 3: Choose the right VSPEX Proven Infrastructure ........................................... 30

Considerations ............................................................................................ 30

Examples .................................................................................................... 31

Chapter 5 Solution Design Considerations and Best Practices 39

Overview ......................................................................................................... 40

Network design considerations .......................................................................... 40

Overview ..................................................................................................... 40

Network design best practices ....................................................................... 40

Storage layout and design considerations ........................................................... 42

Overview ..................................................................................................... 42

Storage design best practices........................................................................ 45

Storage layout examples ............................................................................... 47

FAST Suite design best practices.................................................................... 49

XtremSW Cache design best practices ............................................................ 51

Virtualizing Exchange Server design considerations ............................................. 51

Overview ..................................................................................................... 51

Virtualization design best practices ............................................................... 51

Chapter 6 Solution Verification Methodologies 53

Overview ......................................................................................................... 54

Baseline hardware verification methodology ....................................................... 54

Application verification methodology ................................................................. 54

High-level steps for application verification .................................................... 54

Jetstress overview ........................................................................................ 55

Key metrics for Jetstress testing ..................................................................... 55

Determining the architecture for the Exchange Server solution .......................... 56

Building the infrastructure environment.......................................................... 56

Using the Jetstress tool ................................................................................. 56

Chapter 7 Reference Documentation 57

EMC documentation ......................................................................................... 58

Other documentation ........................................................................................ 58

Links ............................................................................................................... 58

Contents


Appendix A Qualification Worksheet 61

VSPEX for virtualized Exchange 2013 qualification worksheet ............................... 62

Appendix B Manually Sizing Exchange for VSPEX 63

Overview ......................................................................................................... 64

Manually sizing Exchange 2013 for VSPEX .......................................................... 64

Using the VSPEX for virtualized Exchange 2013 qualification worksheet ............ 64

Reference virtual machine sizing.................................................................... 65

Storage sizing for Exchange Mailbox server ..................................................... 68

Selecting the right VSPEX Proven Infrastructure ............................................... 72

Figures Figure 1. Architecture of the validated infrastructure ...................................... 16

Figure 2. VSPEX Proven Infrastructure ........................................................... 18

Figure 3. Required resources example: VSPEX Proven Infrastructure for small Exchange organization .......................................................... 34

Figure 4. Required resources example: VSPEX Proven Infrastructure for medium Exchange organization ...................................................... 37

Figure 5. Exchange 2013 storage elements for vSphere 5.1 and VNX platform .. 42

Figure 6. Exchange 2013 storage elements on Hyper-V and VNXe platform ....... 44

Figure 7. Storage layout example: Exchange small organization for VNXe ......... 48

Figure 8. Storage layout example: Exchange medium organization for VNX ....... 49

Figure 9. Printable qualification worksheet ................................................... 62

Tables Table 1. Terminology ................................................................................. 10

Table 2. VSPEX for virtualized Exchange Server 2013: Deployment workflow ... 12

Table 3. Exchange 2013 server roles ........................................................... 18

Table 4. Reference virtual machine: Characteristics....................................... 19

Table 5. VNX software suites ...................................................................... 20

Table 6. VNX software packs ....................................................................... 21

Table 7. VNXe software suites ..................................................................... 21

Table 8. VNXe software packs ..................................................................... 21

Table 9. VSPEX for virtualized Exchange Server: Design process ..................... 26

Table 10. VSPEX for virtualized Exchange 2013 qualification worksheet guidelines .................................................................................... 26

Table 11. VSPEX Sizing Tool output ............................................................... 28

Table 12. VSPEX Proven Infrastructure: Selection steps ................................... 31

Contents


Table 13. Example VSPEX for virtualized Exchange 2013 qualification worksheet: Small Exchange organization ......................................... 32

Table 14. Example of required resources: Small Exchange organization ............ 32

Table 15. Example of additional storage pools: Small Exchange organization .... 33

Table 16. Example VSPEX for virtualized Exchange 2013 qualification worksheet: Medium Exchange organization ..................................... 35

Table 17. Example of required resources: Medium Exchange organization ........ 35

Table 18. Example of additional storage pools: Medium Exchange organization ................................................................................. 36

Table 19. Exchange-related storage pools on VNX........................................... 43

Table 20. Exchange related storage pools on VNXe ......................................... 45

Table 21. Exchange data storage pools: Small Exchange organization .............. 47

Table 22. Exchange data storage pools: Medium Exchange organization ........... 48

Table 23. High-level steps for application verification ..................................... 54

Table 24. Key metrics for Jetstress verification ................................................ 55

Table 25. VSPEX for virtualized Exchange 2013 qualification worksheet ............ 62

Table 26. Example VSPEX for virtualized Exchange 2013 qualification worksheet .................................................................................... 64

Table 27. Exchange manual sizing procedure ................................................. 65

Table 28. Reference virtual machine: Characteristics....................................... 66

Table 29. Summary of reference virtual machine resources .............................. 67

Table 30. Number of disks required for IOPS and capacity ............................... 71

Table 31. Exchange data storage pool configuration ....................................... 71

Table 32. VSPEX storage model support matrix............................................... 73

Table 33. Storage system and drives ............................................................. 74

Chapter 1: Introduction


Chapter 1 Introduction

This chapter presents the following topics:

Purpose of this guide.......................................................................................... 8

Business value ................................................................................................... 8

Scope................................................................................................................ 9

Audience ........................................................................................................... 9

Terminology .................................................................................................... 10



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 2013 provides partners with an EMC Proven solution, capable of hosting virtualized Exchange at a consistent performance level. This solution has been tested, sized, and designed to be layered on an existing VSPEX Private Cloud using either a VMware vSphere or Microsoft Windows Server 2012 with Hyper-V virtualization platform and the highly available EMC VNX® family of storage systems. 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 2013 according to 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 communicating 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 companies struggle to keep pace with relentless data growth while working to overcome diminishing or stagnant budgets. Administering, auditing, protecting, and managing an Exchange environment for a modern geographically dispersed work force is a major challenge for most IT departments.

EMC has joined forces with the industry’s leading providers of IT infrastructure to create a complete virtualization solution that accelerates the deployment of private cloud and Microsoft Exchange.

VSPEX enables customers to accelerate their IT transformation with faster deployment, more simplicity, greater choice, higher efficiency, and lower risk, versus the challenges, complexity, and difficulties of building an IT infrastructure themselves. VSPEX validation by EMC ensures predictable performance and enables customers to select technology that uses their existing or newly-acquired IT infrastructure while eliminating the planning, sizing, and configuration burdens that are typically associated with deploying a new IT Infrastructure. VSPEX provides Exchange infrastructures for customers looking to simplify their system—a characteristic of truly converged infrastructures—while at the same time gaining more choice in individual stack components.



Scope

This Design Guide helps customers to deploy a simple, effective, and flexible Exchange Server 2013 solution on a VSPEX Proven Infrastructure in the most cost-effective and performance-oriented manner. It describes how to:

Size and design your Exchange 2013 solution

Allocate resources according to best practices

Choose the right VSPEX Proven Infrastucture on which to layer Exchange 2013

Use all the benefits that VSPEX offers

The guidance applies to VSPEX Proven Infrastructures virtualized with VMware vSphere or Microsoft Hyper-V and deployed on either the EMC VNX series or EMC VNXe® series of storage arrays.

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 for virtualized Exchange Server 2013 solution are:

Qualified by Microsoft to sell and implement Exchange solutions

Certified in Exchange 2013, ideally with one or both of the following Microsoft Certified Solutions Expert (MCSE)certifications:

Messaging – Core Solutions of Microsoft Exchange Server 2013 (Exam: 341)

Messaging – Advanced Solutions of Microsoft Exchange Server 2013 (Exam: 342)

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

Partners who plan to deploy the solution must also have the necessary technical training and background to install and configure:

Microsoft Windows Server 2012 operating systems (OS)

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

Microsoft Exchange Server 2013

This guide provides external references where applicable. EMC recommends that partners implementing this solution are familiar with these documents. For details, see Essential reading and Chapter 7: Reference Documentation.



Terminology

Table 1 lists the terminology used in this guide.

Table 1. Terminology

Term Definition

AD Active Directory

BDM Background Database Maintenance

Bursty Data that is transferred or transmitted in short, uneven spurts

CIFS Common Internet File System

CSV Cluster shared volume. A Windows Server clustering feature that enables multiple clustered virtual machines to use the same LUN.

DAG Database Availability Group

FAST VP™ Fully Automated Storage Tiering for Virtual Pools

IOPS Input/output operations per second

MAPI Messaging Application Programming Interface

MCS Multiple Connections per Session

MPIO Microsoft Multipath I/O

NIC Network interface card

NFS Network File System

NLB Network Load Balancing

NL-SAS Near-line serial-attached SCSI

NMP VMware Native Multipathing Plug-in

PCIe Peripheral Component Interconnect Express

Reference virtual machine

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

rpm Revolutions per minute

SAS Serial-attached SCSI

SP Storage processor

VHD Virtual hard disk

VHDX Hyper-V virtual hard disk format

XtremSW™ EMC software for server-side caching on PCIe Flash cards

XtremSW Cache EMC server Flash-caching software as part of the XtremSW software suite

Chapter 2: Before You Start


Chapter 2 Before You Start


Deployment workflow ....................................................................................... 12

Essential reading ............................................................................................. 12



Deployment workflow

To design and implement your VSPEX for virtualized Exchange Server 2013 solution, refer to the process flow in Table 2.

Table 2. VSPEX for virtualized Exchange Server 2013: Deployment workflow

Step Action

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

2 Use the EMC VSPEX Sizing Tool to determine the recommended VSPEX Proven Infrastructure for your Exchange Server 2013 solution, based on the user requirements collected in Step 1.

For more information about the Sizing Tool, refer to the EMC VSPEX Sizing Tool portal.

Note: If the Sizing Tool is not available, you can manually size the application using the guidelines in Manually Sizing Exchange for VSPEX: Appendix B.

3 Use this Design Guide to determine the final design for your VSPEX solution.

Note: Ensure that all application requirements are considered, not just the requirements for virtualized Exchange.

4 Select and order the right VSPEX Proven Infrastructure. Refer to the appropriate VSPEX Proven Infrastructure document in Essential reading for guidance.

5 Deploy and test your VSPEX solution. Refer to the appropriate VSPEX Implementation Guide in Essential reading for guidance.

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.

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 2013 with Microsoft Hyper-V Implementation Guide

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

VSPEX Solution Overviews

VSPEX Implementation Guides

https://express.salire.com/signin.aspx?t=emc&atid=224a9bcc-caa3-48f4-8ff8-33051513c410

https://express.salire.com/signin.aspx?t=emc&atid=224a9bcc-caa3-48f4-8ff8-33051513c410

https://community.emc.com/community/partner/vspex?view=overview

http://www.emc.com/resource-library/resource-library.htm

http://www.emc.com/platform/virtualizing-information-infrastructure/vspex.htm




Refer to the following VSPEX Proven Infrastructure documents:

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


VSPEX Proven Infrastructures

Chapter 3: Solution Overview


Chapter 3 Solution Overview


Overview ......................................................................................................... 16

Solution architecture ........................................................................................ 16

Key components .............................................................................................. 17



Overview

This chapter provides an overview of the VSPEX Proven Infrastructure for virtualized Microsoft Exchange Server 2013 and the key technologies used in this solution. The solution has been designed and proven by EMC to be layered on a VSPEX Private Cloud, which provides storage, compute, and network resources.

The solution enables customers to quickly and consistently deploy a virtualized Exchange organization in the VSPEX Proven Infrastructure The solution enables customers to quickly and consistently deploy a virtualized Exchange organization in the VSPEX Proven Infrastructure. VMware or Microsoft Hyper-V virtualization and the VNX family of storage systems provide storage and server hardware consolidation.

Solution architecture

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

Figure 1. Architecture of the validated infrastructure



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

Key components

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


EMC VSPEX Proven Infrastructures

EMC VNX and EMC VNXe series

EMC Unisphere®

VMware vSphere 5.1

VMware Native Multipathing Plug-in (NMP)

EMC VNX VMware vStorage APIs for Array Integration Support

Microsoft Windows Server 2012 with Hyper-V

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

EMC Virtual Storage Integrator for VMware vSphere

EMC Storage Integrator

EMC XtremSW Cache

EMC PowerPath®

Microsoft Exchange Server 2013 is an enterprise email and communication system that enables businesses and customers to collaborate and share information. EMC enhances Exchange Server 2013 with a selection of storage platforms, software, and services.

Exchange 2013 builds upon the Exchange Server 2010 architecture and has been redesigned for simplicity of scale, hardware utilization, and failure isolation. Exchange 2013 uses Database Availability Groups (DAGs) and mailbox database copies, along with other features such as single item recovery, retention policies, and lagged database copies, to provide high availability, site resilience, and Exchange native data protection. The high availability platform, the Exchange Information Store, and the Extensible Storage Engine (ESE) have all been enhanced to provide greater availability and easier management, and to reduce costs.

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.

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

Introduction




Exchange 2013 reduces the number of server roles to two, the Client Access server role and the Mailbox server role, as described in Table 3.

Table 3. Exchange 2013 server roles

Role Function

Mailbox server The Mailbox server role handles all activities for active mailboxes on the server. It provides:

Client Access protocols

Transport service

Mailbox databases

Unified Messaging (except SIP redirection)

Client Access server The Client Access server, a thin and stateless server, provides:

Authentication

Redirection (limited)

Proxy services for HTTP, POP, IMAP, and SMTP

The server does not do any data rendering and nothing is queued or stored here (except diagnostic logging).

At the time of publication, an Exchange 2013 version of the Edge Transport server is not available. Customers requiring an Edge Transport server can install an Exchange 2007 or Exchange 2010 Edge Transport server in the perimeter network.

VSPEX Proven Infrastructures, as shown in Figure 2, are modular, virtualized infrastructures validated by EMC and delivered by EMC partners. VSPEX includes virtualization, compute, and network layers, and EMC storage and next-generation backup, designed by EMC to deliver reliable and predictable performance.

Figure 2. VSPEX Proven Infrastructure

EMC VSPEX Proven Infrastructures



VSPEX provides the flexibility to create a complete virtualization solution using the network, server, and virtualization technologies that best fit a customer’s environment. 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, VSPEX defines a reference virtual machine to represent a unit of measure for quantifying the compute resources in the VSPEX virtual infrastructure. By comparing the customer’s actual usage to this reference workload, you can extrapolate which reference architecture to choose. The reference virtual machine is defined as a single virtual machine with the characteristics shown in Table 4.

Table 4. 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 VSPEX Proven Infrastructures and reference virtual machines, refer to the VSPEX Proven Infrastructure documents in Essential reading.

The EMC VNX family, including VNXe, 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 family is powered by Intel® Xeon® processors for intelligent storage that automatically and efficiently scales in performance, while ensuring data integrity and security.

The VNX series is designed to meet the high-performance, high-scalability requirements of midsize and large enterprises. The VNXe series is purpose-built for the IT manager in smaller environments.

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

EMC VNX and EMC VNXe series



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

Multiprotocol support for file, block, and object with object access through EMC Atmos® Virtual Edition (Atmos VE)

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

Table 5 lists the software suites available with VNX.

Table 5. VNX software suites

Suite Features

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



VNX software packs

Table 6 lists the software packs available with VNX.

Table 6. VNX software packs

Software pack Features

Total Efficiency Pack Includes all five software suites

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

VNXe software suites

Table 7 lists the software suites available with VNXe.

Table 7. VNXe software suites

Software suite Features

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

Table 8 lists the software packs available with VNXe.

Table 8. VNXe software packs

Software pack Features

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 Windows Hyper-V, VMware, and shared folder storage.

EMC Unisphere



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 vSphere High Availability

VMware vSphere High Availability (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 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 the 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 specific 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.

VMware vStorage APIs for Array Integration

Hardware acceleration with VMware vStorage APIs 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 family. With storage hardware assistance, vSphere performs these operations faster and consumes less CPU, memory, and storage fabric bandwidth.

Microsoft Windows Server 2012 with Hyper-V provides a complete virtualization platform, which offers increased scalability and performance with a flexible solution from the data center to the cloud. It makes it easier for organizations to realize the 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

Inbox network interface card (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.

VMware vSphere 5.1

Microsoft Windows Server 2012 with Hyper-V



Multipathing solutions use redundant physical path components, such as 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. If 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 NIC (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.

Note: 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 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 data center 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.

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. ESI enables administrators to easily provision block and file storage for Windows using wizards.

MPIO and MCS

EMC Virtual Storage Integrator for VMware vSphere

EMC Storage Integrator

https://support.emc.com/



ESI supports the following capabilities:

Provisioning, formatting, and presenting drives to Windows servers

Provisioning new cluster disks and automatically adding them to the cluster

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 improvement. XtremSW Cache accelerates read operations and protects data by using a write-through 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 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 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 XtremSW Cache

EMC PowerPath

Chapter 4: Choosing a VSPEX Proven Infrastructure


Chapter 4 Choosing a VSPEX Proven Infrastructure


Overview ......................................................................................................... 26

Step 1: Evaluate the customer use case .............................................................. 26

Step 2: Design the application architecture ........................................................ 28

Step 3: Choose the right VSPEX Proven Infrastructure ......................................... 30



Overview

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

Table 9. VSPEX for virtualized Exchange Server: Design process

Step Action

1 Evaluate the customer’s Exchange workload by using the VSPEX for virtualized Exchange 2013 qualification worksheet. 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 architecture.

Note: If the Sizing Tool is not available, you can manually size the application using the guidelines in Manually Sizing Exchange for VSPEX: 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

Before deploying VSPEX for virtualized Exchange Server, it is important to gather information about the customer’s business, infrastructure, and workload requirements, in order 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 2013 qualification worksheet when evaluating the workload requirements for the VSPEX solution.

The VSPEX for virtualized Exchange 2013 qualification worksheet in Appendix A presents a list of simple questions to help identify customer requirements, usage characteristics, and datasets. Table 10 provides a detailed explanation of the qualification worksheet and general guidance on how to determine input values.

Table 10. VSPEX for virtualized Exchange 2013 qualification worksheet guidelines

Question Description

Number of mailboxes? 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)? Determine the size of each user’s mailbox. This is an important element for sizing disk capacity.

Overview

VSPEX for virtualized Exchange 2013 qualification worksheet



Question Description

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

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 Sizing Exchange 2013 Deployments for detailed information about the IOPS profile definition.

DAG copies (including active copy)?

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

Specify 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 2013, this element is 14 days by default.

Backup/Truncation Failure Tolerance (days)?

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

Included number of years’ growth?

Future growth is a key characteristic of the VSPEX solution.

Use this element to define the number of years’ growth that will be calculated in the VSPEX Sizing Tool. 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, %)?

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.

http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx




Step 2: Design the application architecture

After you evaluate the workload and requirements of your customer’s Exchange Server environment, use the VSPEX Sizing Tool for Microsoft Exchange Server to design your VSPEX for virtualized Exchange Server solution.

Principles and guidelines

In this 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 listed in Table 4. For more information about a reference virtual machine and its characteristics, refer to the VSPEX Proven Infrastructure documents listed in Essential reading.

VSPEX Sizing Tool output: Requirements and recommendations

The VSPEX Sizing Tool enables you to input your Exchange configuration 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 11.

Table 11. VSPEX Sizing Tool output

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 Summarizes the reference virtual machines consumed by the Exchange organization.

Additional storage pools Recommends additional storage pools for Exchange data including Exchange databases and transaction logs.

In this solution, customers may need to add more disks and storage pools to the infrastructure layer to meet their 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.

Overview

VSPEX Sizing Tool



Reference virtual machine best practices for Exchange Server 2013

The VSPEX Sizing Tool provides detailed recommendations for sizing the reference virtual machine resouces required for your customer’s Exchange environment, based on the following basic resource types for each Exchange Server role:

Exchange server role

vCPU

Memory

OS capacity

OS IOPS

Exchange 2013 brings fundamental changes in the search and store components and the protocol responsible for servicing client users’ requests. As a result, the Exchange 2013 Mailbox server role performs more work and needs more CPU and memory resourses compared to its Exchange 2010 counterpart. EMC recommends that you follow the best practices described here when using the VSPEX Sizing Tool to design your customer’s environment.

Exchange server role deployment best practices

In Exchange Server 2013, you can configure the Database Availability Group (DAG) feature for mailbox database high availability and you can enable Windows Network Load Balancing (NLB) to balance the load of the Client Access servers. However, do not combine the Mailbox server and Client Access server roles in the same virtual machine if you want to use both DAGs and Windows NLB. DAGs require Microsoft Cluster Service (MSCS), but Microsoft does not support installing both the Cluster service and NLB on the same computer. For more information, refer to the Microsoft Knowledge Base article Interoperability between MSCS and NLB.

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 the CPU requirements for hypervisor overhead.

The VSPEX Sizing Tool 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 VSPEX Proven Infrastructure documents in Essential reading. We validated this Exchange Server solution with a statically assigned processor and no virtual-to-physical CPU oversubscription.

From the Client Access server’s perspective, it has a 1:4 CPU core ratio to the Mailbox server. For more information about vCPU considerations for Exchange 2013, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

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

http://support.microsoft.com/kb/235305




or ballooning. The memory values provided by the tool are not hard limits but represent the value tested in the VSPEX solution.

In general, Mailbox server memory requirements are highly dependent on the number of mailboxes on the server and the mailbox IOPS profile. For detailed information, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

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 private cloud pool in this solution. For more information about the VSPEX private cloud pool, refer to the VXPEX Proven Infrastructure documents in Essential reading.

In medium and small Exchange organizations, EMC recommends that you calculate the transport storage requirements on the Mailbox server. For detailed information, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

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 private cloud pool. In this solution, we considered more performance characteristics from the application perspective than from the OS perspective.

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 VSPEX for virtualized Exchange 2013 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

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. After you confirm the application architecture using the VSPEX Sizing Tool, you can choose the right VSPEX Proven Infrastructure based on the calculated results.

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

Considerations







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 in Table 12 when choosing a VSPEX Proven Infrastructure.

Table 12. VSPEX Proven Infrastructure: Selection steps

Step Action

1 Use the VSPEX Sizing Tool to calculate the total number of reference virtual machines and recommend any additional storage layout requirements for Exchange Server.

2 Use the VSPEX Sizing Tool to design the customer’s 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 for 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 the VSPEX Proven Infrastructure documents listed in Essential reading.

Overview

This section describes two examples of Exchange Server 2013 organizations—one small, one medium—and demonstrates how you would select the right VSPEX Proven Infrastructure for each one.

Example 1: Small Exchange organization

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 an 11 percent growth in the number of mailboxes in one year. 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.101 (that is, 150 messages sent/received per mailbox per day). Deleted email messages will be kept on the Exchange store for 14 days and the required backup failure tolerance is three days. There are no other applications to be deployed.

After talking to the customer, complete the VSPEX for virtualized Exchange 2013 qualification worksheet for the production Exchange 2013 organization, as shown in Table 13.

Examples

http://www.emc.com/platform/vspex-proven-infrastructure/index.htm



Table 13. Example VSPEX for virtualized Exchange 2013 qualification worksheet: Small Exchange organization

Question Example answer

Number of mailboxes? 900

Maximum mailbox size (GB)? 1.5 GB


0.101 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

Included number of years’ growth? 1

Annual growth rate (number of mailboxes, %)? 11%

After you input 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 14.

In this example, you need to set up two Exchange Mailbox servers and two Client Access servers to support the Exchange requirements from the qualification worksheet in Table 13. To determine the total number of reference virtual machines required for each Exchange server role, select the largest of the individual resource (CPU, memory, capacity, or IOPS) requirements and multiply by the recommended number of virtual machines.

Table 14. Example of required resources: Small Exchange organization

Exchange Server role vCPU Memory OS volume capacity

OS volume IOPS

No. of virtual machines

Total reference virtual machines

Mailbox server

Resource requirements 4 36 GB 200 GB Less than

25 2 36

Equivalent reference virtual machines 4 18 2 1

Client Access server

Resource requirements 4 12 GB 100 GB

Less than 25

2 12 Equivalent reference virtual machines 4 6 1 1

Total equivalent reference virtual machines 48



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

Four reference virtual machines for the CPU requirement

Eighteen reference virtual machines for the memory requirement

Two reference virtual machines for the capacity requirement

One reference virtual machine for the IOPS requirement

Therefore, each Mailbox server needs the resources of 18 reference virtual machines. When you multiply this number by the number of virtual machines (two in this example), the result is 36, which is the total number of reference virtual machines required for the Mailbox server role:

18 reference virtual machines x 2 virtual machines = 36 total

reference virtual machines

For more details on how to determine equivalent reference virtual machines, refer to the relevant VSPEX Proven Infrastructure documents 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 Table 15. The suggested storage layout for Exchange data is in addition to the VSPEX private cloud pool.

Table 15. 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


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



Implementing this small Exchange organization on a pool for 50 reference virtual machines consumes the resources of 48 reference virtual machines and leaves the resources of two 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 EMC VSPEX for Virtualized Microsoft Exchange 2013 with VMware vSphere Implementation Guide, we used 50 VMware vSphere virtual machines as a VSPEX solution example.

Note: This small Exchange 2013 organization deployment uses 96 percent of the selected VSPEX Proven Infrastructure’s resources (48 reference virtual machines from a total of 50). This leaves few resources (two reference virtual machines) for additional growth or other application requirements. When you design a similar solution for a customer, we recommend that you consider a higher VSPEX Proven Infrastructure model to support potential growth requirements.

Example 2: Medium Exchange 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 an 11 percent growth in the number of mailboxes in one year. 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.101 (that is, 150 messages sent/received per mailbox per day). Deleted email messages will be kept on the Exchange store for 14 days and the required backup failure tolerance is three days.

The customer also plans to deploy other applications, such as Microsoft SharePoint and SQL Server, in the VSPEX Proven Infrastructure. The customer would like to use at most 90 percent of the VSPEX Proven Infrastructure for the combined applications.

After talking to the customer, complete the VSPEX for virtualized Exchange 2013 qualification worksheet for the production Exchange Server 2013 organization, as shown in Table 16.



Table 16. Example VSPEX for virtualized Exchange 2013 qualification worksheet: Medium Exchange organization


Number of mailboxes? 9,000








Annual growth rate (number of mailboxes, %)? 11%

After you input 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 Table 17.

In this example, you need to set up eight Exchange Mailbox servers and four Client Access servers to support the Exchange requirements from the qualification worksheet in Table 16. To determine the total number of reference virtual machines required for each Exchange server role, select the largest of the individual resource (CPU, memory, capacity, or IOPS) requirements and multiply by the recommended number of virtual machines.

Table 17. Example of required resources: Medium Exchange organization

Exchange server role vCPU Memory (GB)

OS volume capacity

OS volume IOPS



Mailbox server


Less than 25



Resource requirments 8 20 GB 100 GB

Less than 25





For example, each Mailbox server requires 12 vCPUs, 68 GB of memory, 300 GB of storage, and 25 IOPS. This translates to:

Twelve reference virtual machines for the CPU requirement

Thirty-four reference virtual machines for the memory requirement

Three reference virtual machines for the capacity requirement

One reference virtual machine for the IOPS requirement

Therefore, each Mailbox server needs the resources of 34 reference virtual machines. When you multiply this number by the number of virtual machines (eight in this example), the result is 272, which is the total number of reference virtual machines required for the Mailbox server role:



For more details on how to determine the equivalent reference virtual machines, refer to the relevant VSPEX Proven Infrastructure documents 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 Table 18. The suggested storage layout for Exchange data is in addition to the VSPEX private cloud pool.

Table 18. Example of additional storage pools: Medium Exchange organization



Exchange database pool 1 RAID 1/0 (16+16) 7,200 rpm NL-SAS disks 3 TB 32


Exchange log pool 1 RAID 1/0 (2+2) 7,200 rpm NL-SAS disks 3 TB 4


As Exchange Server is not the only application that the customer needs to plan for, EMC recommends that you use the VSPEX Sizing Tool to calulate the resource requirements for the combined application workload and recommend the VSPEX Proven Infrastructure offering that has the best fit with those requirements.

For example, if the total combined applications require 430 reference virtual machines and the customer requests at most 90 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:





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

Figure 4. Required resources example: VSPEX Proven Infrastructure for medium Exchange organization

In the EMC VSPEX for Virtualized Microsoft Exchange 2013 with VMware vSphere Implementation Guide, we used 500 VMware vSphere virtual machines as a VSPEX solution example.

Chapter 5: Solution Design Considerations and Best Practices


Chapter 5 Solution Design Considerations and Best Practices


Overview ......................................................................................................... 40

Network design considerations ......................................................................... 40

Storage layout and design considerations .......................................................... 42

Virtualizing Exchange Server design considerations ............................................ 51



Overview

This chapter describes best practices and considerations for designing the VSPEX for virtualized Exchange Server 2013 solution. It covers the following VSPEX infrastructure layers and components:

Network

Storage layout

Virtualization

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. You should spread these connections across multiple Ethernet switches to guard against component failure in the network. For more information, refer to the VSPEX Proven Infrastructure documents listed in Essential reading.

For this solution, 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.

Overview

Network design best practices



When specifying the NIC teaming settings, it is 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 Exchange 2013 Client Access server, provides these benefits:

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

Helps distribute the load evenly across the Client Access servers

For more information on creating a Windows NLB cluster and setting up Client Access servers, refer to the VSPEX Implementation Guides listed in Essential reading.

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 Delayed Acknowledgement (ACK), which may cause slow iSCSI performance issues. For more information, refer to the VMware Knowledge Base article ESX/ESXi hosts might experience read/write performance issues with certain storage arrays.

Set up Replication network for Exchange DAGs

When deploying DAGs in your environment, although a single network is supported, EMC recommends 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 2013 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.




http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&externalID=1002598


http://technet.microsoft.com/en-us/library/dd638129(v=exchg.150).aspx




For other best practices in network design for the VSPEX Proven Infrastructure, refer to the VSPEX Proven Infrastructure documents listed in Essential reading.

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 2013 environments. EMC VNX FAST Suite and XtremSW Cache design considerations are also covered in this section.

Example architecture with vSphere and VNX

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 2013 on a vSphere virtualization platform and VNX storage array. In this example, all the Exchange Server database and log volumes are stored in RDM.

Figure 5. Exchange 2013 storage elements for vSphere 5.1 and VNX platform

Overview



Note: Microsoft has support policies on the types of storage (file or block protocols) that Exchange virtual machines can use for Exchange data. For detailed information, refer to the Microsoft TechNet topic Exchange 2013 Virtualization.

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 2013, you can use different models—for example, one storage pool per Exchange Mailbox server, or one storage pool per database copy.

In this example, a DAG is configured on Exchange Server 2013 and each database has two copies. We configured dedicated storage pools for each database copy. This 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.

Table 19 details the storage pool design for this example.

Table 19. Exchange-related storage pools 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 VSPEX Proven Infrastructure documents in Essential reading.

RAID 5 with SAS disks

Exchange database pool 1

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

RAID 1/0 with NL-SAS disks

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.

Example architecture with Hyper-V and VNXe

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 the example, a DAG is configured on Exchange Server 2013 and each database has two copies.

http://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx



Figure 6. Exchange 2013 storage elements on Hyper-V and VNXe platform

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. For small Exchange organizations in a mailbox resiliency deployment, you can store the Exchange database and log files from one DAG copy in the same storage pool on VNXe—this minimizes the number of pools needed for deployment.



Table 20 details the storage pool design for this example.

Table 20. Exchange related storage pools on VNXe

Pool name Purpose RAID recommendation

VSPEX private cloud pool

The infrastructure pool where all the virtual machines reside. For details, refer to the VSPEX Proven Infrastructure documents in Essential reading.

RAID 5 with SAS disks 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.

VNXe provides user-friendly wizards for storage provisioning. For detailed steps on VNXe storage provisioning for Microsoft Exchange environments, refer to the VSPEX Implementation Guides listed in Essential reading.

In this VSPEX Proven Infrastructure for virtualized Exchange Server 2013, consider the best practices in the following sections for storage layout and design.

Disk and RAID type selection for Exchange database and log files

On VNXe storage platforms, SAS disks provide high capacity with moderate I/O speed, which makes them highly suitable for Exchange Server 2013 environments. Use RAID 5 for the Exchange data storage pool where the 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 VNX storage platforms, NL-SAS disks are a good fit due to the less demanding I/O requirements of Exchange Server 2013 compared to previous versions of Exchange Server. These disks support large mailboxes at a relatively low cost. Using NL-SAS disks in a 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 2013

When designing the disk layout for Exchange Server 2013:

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 using DAGs, 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 design best practices



Storage pool or RAID group selection for Exchange Server 2013

Storage pools or RAID groups work well with Exchange Server 2013. 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

VNX for block

It is a best practice to let the system balance the pool LUNs across both storage processors (SPs) when you create the pool LUNs, which it does by default; if you must manually change the setting, EMC recommends you manually ensure the balance between the SPs.

Do not change the default owner of a pool LUN after you provision it. This can adversely affect performance. It changes the underlying private structures for pool LUNs that the original storage processor (SP) still controls. If you must change the SP ownership after you create a LUN, use LUN migration to migrate the LUN to a new LUN with the desired SP owner. Next, perform a trespass operation for the LUN from its previous owner to the new owner.

VNX for file

When creating LUNs on VNX for NFS datastores to hold virtual machine boot volumes, consider the following best practices (in this solution we do not use file storage for Exchange data):

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

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.

Make all the LUNs the same size.

Balance LUN ownership across SPA and SPB.

For more information, refer to EMC VNX Unified Best Practices for Performance and the Microsoft TechNet topic Exchange 2013 Virtualization.

VMware VMDK or RDM disk selection for Exchange Server 2013

In VMware environments, you can configure either VMDK (Virtual Machine Disk format) or RDM to house Exchange Server 2013 data. However, if you use hardware snapshots 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.




EMC SOAP Tool

The EMC SOAP Tool is a utility that optimizes the thick LUNs in a 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. To obtain the EMC SOAP Tool, contact your EMC representative.

File allocation unit size for 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.

This section describes two example storage layouts in this VSPEX Proven Infrastructure for virtualized Exchange Server 2013—one small organization for VNXe and one medium organization for VNX, both based on VSPEX Private Cloud. Both of these examples follow the best practices and design considerations previously discussed.

Note: 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.

Small Exchange organization on VNXe

Table 21 shows an example of a storage layout to store Exchange data for a small Exchange organization—this is in addition to the VSPEX private cloud pool. For more information about the user profile in this example, refer to Example 1: Small Exchange organization.

Table 21. Exchange data storage pools: Small Exchange organization





Storage layout examples



Figure 7 shows an example of the storage layout for a small Exchange organization on 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 Infrastructure documents listed in Essential reading.

Figure 7. Storage layout example: Exchange small organization for VNXe

Medium Exchange organization on VNX

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

Table 22. Exchange data storage pools: Medium Exchange organization









Figure 8 shows an example of the storage layout for a medium size Exchange organization on 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 Infrastructure documents listed in Essential reading.

Figure 8. Storage layout example: Exchange medium organization for VNX

Overview

The EMC FAST Suite provides two key technologies—FAST VP and FAST Cache—that enable extreme performance in an automated fashion, when and where needed. These technologies are available with the VNX series.

You can use FAST Cache and FAST VP to achieve high performance and lower the total cost of ownership (TCO) of 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 Suite design best practices



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 the FAST Suite for VSPEX Proven Infrastructures, refer to VSPEX Proven Infrastructure documents in Essential reading.

Due to the changes in the Exchange 2013 storage architecture, which result in lower I/O to storage devices and the trend to deploy larger mailboxes, many Exchange designs are capable of utilizing high-capacity, low 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 Flash drives and enabling FAST VP or FAST Cache.

FAST Cache

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.

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.

FAST VP

Customer requirements determine whether to use FAST VP with Exchange Server 2013 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 2013 on VNX:

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.

Do not place DAG copies of the same database in the same storage pool on the same disks.

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.



When you enable XtremSW Cache, you have complete and flexible control over the scope and granularity of the cache. 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. You can then configure the allocated cache capacity inside the virtual machine at the virtual disk level.

To learn more about EMC XtremSW Cache, refer to the EMC VFCache–Data Sheet.

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

Exchange Server 2013 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 2013, refer to the Microsoft TechNet topic Exchange 2013 Virtualization.

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

Distribute the same Exchange server role across different physical hosts. For example, you may have several Exchange Client Access servers in your environment. In this scenario, for redundancy considerations, EMC recommends that you distribute these servers across different physical hosts.

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

XtremSW Cache design best practices

Overview

Virtualization design best practices




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

For Exchange 2013 deployments, 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 the dynamic memory feature on Exchange Server virtual machines.

Regularly monitor the performance of your entire VSPEX Proven infrastructure.

You can monitor performance at the virtual machine level and 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 tools, refer to the VSPEX Implementation Guides listed in Essential reading.

Chapter 6: Solution Verification Methodologies


Chapter 6 Solution Verification Methodologies


Overview ......................................................................................................... 54

Baseline hardware verification methodology ...................................................... 54

Application verification methodology................................................................. 54



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 the solution and its components, 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 solution and by verifying the redundancy of the solution components before deploying to production.

For detailed steps on verifying the redundancy of the solution components, refer to the VXPEX Proven Infrastructure documents in Essential reading.

Application verification methodology

After you have verified the hardware and the redundancy of the solution components, the next stage is to test and optimize the Exchange application—this is a critical step of the 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 negatively impact users in a live deployment.

Table 23 describes the high-level steps to complete before you put the Exchange environment into production.

Table 23. High-level steps for application verification

Step Description Reference

1 Understand the testing tools: Microsoft Jetstress and Load Generator2 (LoadGen).

Jetstress overview

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

Key metrics for Jetstress testing

2 At the time of publication of this Design Guide, Microsoft has not released LoadGen for Exchange 2013. When LoadGen for Exchange 2013 is available, this Design Guide will be updated to provide further guidance on using the tool for application verification.

High-level steps for application verification



Step Description Reference

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

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

EMC VSPEX Proven Infrastructure website

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

VSPEX Implementation Guides

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 2013 Tool

It is important to to verify the Exchange 2013 storage design for expected transactional IOPS before placing it in a production environment. To ensure that the environment functions appropriately, EMC recommends you use the Microsoft Exchange Server Jetstress 2013 tool to verify the Exchange storage design.

Jetstress 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 uses the same ESE.dll file that Exchange uses in production.

You can configure Jetstress to test the maximum I/O throughput available to the disk subsystem within the required performance constraints of Exchange. Jetstress can accept a simulated profile of specific user counts and IOPS per user to 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 Jetstress 2013 from Microsoft Exchange Server Jetstress 2013 Tool on the Microsoft website.

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

Table 24. Key metrics for Jetstress verification

Performance counters Target values

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

Number of mailboxes * Exchange 2013 user IOPS profile

I/O database reads/sec N/A (for analysis purpose)

I/O database writes/sec N/A (for analysis purpose)

Jetstress overview

Key metrics for Jetstress testing



http://www.microsoft.com/en-hk/download/details.aspx?id=36849






Performance counters Target values

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

To design the virtualized Exchange Server solution on the VSPEX Proven Infrastructure, consider all the factors described previously in this Design Guide—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 the business needs.

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

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

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.

For 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. Although this white paper focuses on Jetstress 2010, the concepts also apply to Jetstress 2013.

Determining the architecture for the Exchange Server solution

Building the infrastructure environment

Using the Jetstress tool

http://gallery.technet.microsoft.com/office/Jetstress-Field-Guide-1602d64c

Chapter 7: Reference Documentation


Chapter 7 Reference Documentation


EMC documentation ......................................................................................... 58

Other documentation ....................................................................................... 58

Links ............................................................................................................... 58



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.

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 an EMC VNXe System with VMware

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

EMC VNX Unified Best Practices for Performance

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 VSI for VMware vSphere: Storage Viewer—Product Guide

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

EMC VFCache—Data Sheet

Other documentation

For documentation on Microsoft Hyper-V and Microsoft Exchange, refer to the Microsoft website. For documentation on VMware vSphere and vCenter, refer to the VMware website.

Links

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

https://support.emc.com/

http://www.emc.com/resource-library/resource-library.htm

http://www.microsoft.com/

http://www.vmware.com/

http://support.microsoft.com/







Microsoft TechNet

Refer to the following topics on the Microsoft TechNet website:

Add a Mailbox Database Copy

Deploy a Hyper-V Cluster

Deploying High Availability and Site Resilience

Exchange 2013 Prerequisites

Install the Hyper-V Role and Configure a Virtual Machine

Jetstress Field Guide

Managing Database Availability Groups

Managing Mailbox Database Copies

Microsoft Exchange Server Jetstress 2013 Tool

Sizing Exchange 2013 Deployments

Network Load Balancing Deployment Guide

Exchange 2013 Virtualization

Install Exchange 2013 Using the Setup Wizard

Client Access Server

VMware Knowledge Base

Refer to the following topic on the VMware Knowledge Base website:

ESX/ESXi hosts might experience read/write performance issues with certain storage arrays.

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


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


http://technet.microsoft.com/en-us/library/bb691354(v=exchg.150).aspx

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

http://gallery.technet.microsoft.com/office/Jetstress-Field-Guide-1602d64c





http://technet.microsoft.com/en-us/library/cc754833(v=ws.10).aspx


http://technet.microsoft.com/en-us/library/bb124778(v=exchg.150).aspx




Appendix A: Qualification Worksheet


Appendix A Qualification Worksheet

This appendix presents the following topic:

VSPEX for virtualized Exchange 2013 qualification worksheet .............................. 62

Appendix A: Qualification Worksheet


VSPEX for virtualized Exchange 2013 qualification worksheet

Before sizing the VSPEX solution, use the qualification worksheet to gather information about the customer’s business requirements. Table 25 shows the qualification worksheet for an Exchange organization.

Table 25. VSPEX for virtualized Exchange 2013 qualification worksheet

Question Answer

Number of mailboxes?

Maximum mailbox size (GB)?







A standalone copy of the qualification worksheet is attached to this document in PDF format. To view and print the worksheet:

1. In Adobe Reader, open the Attachments panel as follows:

Select View > Show/Hide > Navigation Panes > Attachments. or

Click the Attachments icon as shown in Figure 9.

Figure 9. Printable qualification worksheet

2. In the Attachments panel, double-click the attached file to open and print the qualification worksheet.

Appendix B: Manually Sizing Exchange for VSPEX


Appendix B Manually Sizing Exchange for VSPEX

This appendix presents the following topics:

Overview ......................................................................................................... 64

Manually sizing Exchange 2013 for VSPEX ......................................................... 64



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 2013 for VSPEX, including how to calculate reference virtual machine and storage resources to support a specific number of Exchange Server 2013 users. The amount of required resources is derived from your customer’s detailed requirements.

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

Manually sizing Exchange 2013 for VSPEX

Before sizing Exchange Server 2013, it is important to gather and understand the infrastructure requirements and limitations, and the estimated workload. The VSPEX for virtualized Exchange 2013 qualification worksheet in Appendix A presents a list of simple questions to help identify customer requirements, usage characteristics, and datasets. Table 10 on page 26 provides a detailed explanation of the questionnaire and general guidance on how to determine input values.

Table 26 shows a qualification worksheet populated with customer requirements. This is the example used to introduce the Exchange manual sizing methodology described in the following sections. To meet a customer requirement of 9,000 mailboxes with an 11 percent growth rate in the number of mailboxes in one year, size the environment for 10,000 mailboxes.

Table 26. Example VSPEX for virtualized Exchange 2013 qualification worksheet


Number of mailboxes? 9,000








Annual growth rate (number of mailboxes %)? 11%

After you determine the customer’s requirements, refer to the process flow in Table 27 to manually size Exchange 2013 for VSPEX.

Using the VSPEX for virtualized Exchange 2013 qualification worksheet



Table 27. Exchange manual sizing procedure

Step Action

1 Determine the number of Mailbox and Client Access server roles for your customer’s environment, and calculate the 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 requirements.

vCPU sizing

When sizing the Exchange Server virtual machines, follow the same rules for sizing Exchange on 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:

If there is only one copy of each mailbox database (DAG is not configured), we recommend that each Exchange Mailbox server host up to 2,000 mailboxes.

If there are two copies of each mailbox database (DAG is configured), we recommend that each Exchange Mailbox server host up to 1,250 active mailboxes and 1,250 passive ones.

Therefore, in the example environment, 10,000 active mailboxes and 10,000 passive ones (two copies of each mailbox database) require eight Exchange Mailbox servers in total.

The second step is to calculate the vCPU requirement for each Exchange Mailbox server and Client Access server virtual machine. Use the following steps:

1. Calculate the number of active and passive mailboxes to be hosted on each Exchange Mailbox server. Consider that, in a server failure situation, if a certain number of Exchange Mailbox servers fail, the surviving Mailbox servers must support all the active mailboxes in the environment.

2. Estimate the CPU megacycle requirements for each mailbox, based on the mailbox IOPS profile and the DAG configuration. For detailed information about CPU estimates for different mailbox IOPS profiles, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

3. Calculate the total CPU megacycle requirements 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.

In the example environment, if we choose Intel Xeon E5-2650, 2 GHz as the server processor, we will need 12 vCPUs for each Exchange Mailbox server virtual machine.

Reference virtual machine sizing




4. From the Client Access server’s perspective, it has a 1:4 CPU core ratio to the Mailbox server. In the example, we will deploy four Exchange Client Access servers and eight vCPUs for each Client Access server.

For detailed steps on calculating CPU megacycles, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

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 sizing the Exchange Mailbox server and Client Access server:

1. Calculate the number of active and passive mailboxes to be hosted on each Exchange Mailbox server. Again, consider that, in a server failure situation, if a certain number of Exchange Mailbox servers fails, the surviving Mailbox servers must support all the active mailboxes in the environment.

2. Estimate the memory requirement for each mailbox based on the mailbox IOPS profile and the DAG configuration, and calculate the total memory requirement for each Exchange Mailbox server. Then calculate the memory requirement for the Exchange Client Access server. For detailed steps, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

In the example environment, we need 68 GB of memory for each Exchange Mailbox server and 20 GB of memory for each Exchange Client Access server.

OS capacity sizing

As the transport components (with the exception of the front-end transport component on the Client Access server role) are now part of the Exchange 2013 Mailbox server, you need to calculate the transport storage requirements for the OS capacity. In the example, we need 300 GB for the OS capacity of the Mailbox server. For the Client Access server, the OS capacity is fixed at 100 GB. For detailed information, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

OS IOPS sizing

The OS IOPS is fixed at 25 IOPS per OS volume on each Exchange virtual machine. The example has 12 Exchange virtual machines in total. For detailed information, refer to the VSPEX Proven Infrastructure documents listed in Essential reading.

Reference virtual machine summary

After you have calculated the vCPU, memory, OS capacity, and OS IOPS requirements, you can determine the reference virtual machine resources needed for Exchange deployment. The reference virtual machine in VSPEX solutions is defined as a single virtual machine with the characteristics shown in Table 28.

Table 28. Reference virtual machine: Characteristics


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

In the example environment, we need eight Exchange Mailbox server and four Exchange Client Access server virtual machines. To determine the equivalent number of reference virtual machines required for each Exchange server role, we select the largest of the individual resource (CPU, memory, capacity, or IOPS) requirements and multiply by the recommended number of virtual machines, as shown in Table 29.

Table 29. Summary of reference virtual machine resources

Exchange Server role vCPU Memory OS volume capacity

OS volume IOPS



Mailbox server

Resource requirements 12 68 GB 300 GB Less than

25 8 272

Equivalent reference virtual machines

12 34 3 1



Less than 25



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

Twelve reference virtual machines of CPU

Thirty-four reference virtual machines of memory

Three reference virtual machines of capacity

One reference virtual machine of IOPS

Therefore, each Mailbox server needs the resources of 34 reference virtual machines. When we multiply this number by the number of virtual machines (eight in this case), the result is 272, which is the total number of reference virtual machines required for the Mailbox server role:



For more details about how to determine the equivalent reference virtual machines, refer to the VSPEX Proven Infrastructure documents listed in Essential reading.



Overview

To size the storage requirements, calculate the IOPS requirement first, and then calculate the capacity requirement. Determine the total number of disks required by consolidating the results from the IOPS and capacity requirement calculations.

As a best practice, EMC recommends using 7.2 k rpm 3 TB NL-SAS drives in a RAID 1/0 configuration on the VNX series to house the Exchange database and log files, or 15 k rpm SAS drives in a RAID 5 configuration on the VNXe series.

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.

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 to adequately size your storage. To determine the IOPS for different mailbox profiles, refer to the Microsoft TechNet topic Sizing Exchange 2013 Deployments.

To size the Exchange storage IOPS, use the following steps:

1. Calculate the total database IOPS required to support all mailbox users by using the following building block calculation:

Total transactional IOPS = IOPS per mailbox * mailboxes per

server * (1 + I/O overhead factor)

Add 20 percent overhead, as 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 EMC 20 percent overhead requirement, with the Microsoft-suggested 20 percent overhead, which your customer may or may not choose to add.

In the example, the calculation is:

0.101 * 2500 * (1 + 20% + 20%) = 354 IOPS

In the step above, we determined the IOPS requirement to support one Exchange Mailbox server of 2,500 mailboxes (both active and passive). The total IOPS required for 20,000 users mailboxes (both active and passive) is 2,832 (354 IOPS * 8).

2. Calculate the number of disks required to provide the desired user performance for the Exchange database, based on the IOPS requirements, by 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

Storage sizing for Exchange Mailbox server




Where: Is:

Total transactional IOPS The IOPS calculated in Step 1.

Read Ratio The percentage of I/Os that are reads (68.75 % for Exchange 2013). This number is based on the Jetstress 2013 reports from the validation testing in this solution.

Write Ratio The percentage of I/Os that are writes (31.25% for Exchange 2013). This number is based on the Jetstress 2013 reports from the validation testing in this solution.

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

Physical Disk Speed 60 Exchange 2013 database IOPS for 7,200 rpm NL-SAS drives.

In the example, to support an Exchange database IOPS requirement for 20,000 mailboxes using 7,200 rpm NL-SAS drives, we need:

(2832 * 0.6875) + 2 * (2832 * 0.3125) / 60 = 3717 / 60 =

61.95 (round up to 64 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:

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 2013 sequential log IOPS as Physical Disk Speed for sequential log I/O.

In the example, to support an Exchange log IOPS requirement for 20,000 mailboxes using 7,200 rpm NL-SAS drives, we need:

0.5 * 3360 / 180 = 885 / 180 = 4.88 (round up to 8 disks)

Exchange storage capacity calculation

After calculating the IOPS requirement, you need to calculate the number of disks needed to meet the Exchange capacity requirement. It is important to determine what 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 must accommodate the maximum mailbox size and the deleted item retention window (including calendar version logging and single item recovery, if enabled).



To calculate the Exchange storage capacity requirement, use the following steps:

1. To determine the mailbox size on disk, use the following formula:

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 the example, a mailbox in 0.101 IOPS profile sends and receives a total of 150 email messages per day on average, so the whitespace is 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 the example, it is 150 * 75 * 14 / 1024 + 1536 * 0.012 + 1536 * 0.03 = 218 MB.

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

2. To determine the total database LUN size, use the following formula:

Total database LUN size = Number of mailboxes * Mailbox size

on disk * (1 + Index space + additional Index space for

maintenance) / (1 + LUN free space)

In the example, considering 20 percent for the Index, 20 percent for the additional Index space for maintenance, and 20 percent for LUN-free protection, the database size will be 20,000 * 1,765 MB * (1 + 0.2 + 0.2) / (1 - 0.2) / 1,024 = 60,327 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, 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, allocate enough log capacity to accommodate any backup or truncation failure (for example, a failed database copy prevents log truncation from occurring). For the example, the backup/truncation failure tolerance window is three days.

A mailbox with a 0.101 IOPS profile generates 30 transaction logs per day on average. So, for the example, the total log LUN size = (30 logs * 1 MB) * 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 the example, each 3 TB NL-SAS disk provides 2,794.5 GB of raw capacity. The RAID penalty is 2 due to the RAID 1/0 configuration, so the number of disks required for Exchange database capacity is 60,327 / 2,794.5 * 2 = 43.2 (round up to 44).

The number of disks required for Exchange log capacity is 2,197 / 2,794.5 * 2 = 1.6 (round up to 2).

Final storage calculation results

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

Table 30. Number of disks required for IOPS and capacity

Data Calculation results Final results Disk type Disk capacity

Exchange database 64 disks to meet IOPS requirement 64 disks

7,200 rpm NL-SAS disks

3 TB 44 disks to meet capacity requirement

Exchange log 8 disks to meet IOPS requirement 8 disks

2 disks to meet capacity requirement

As a best practice, separate the DAG copies for each database into different physical disks. In the example, we configured dedicated storage pools for each database copy, and separated the Exchange database and log files into different storage pools. Table 31 shows the final storage layout for the example, based on the final number of disks determined in Table 30.

Table 31. Exchange data storage pool configuration

Recommended Exchange data storage layout


Exchange database pool 1 RAID 1/0 (16+16)

7,200 rpm NL-SAS disks 3 TB

32

Exchange database pool 2 32

Exchange log pool 1 RAID 1/0 (2+2)

4

Exchange log pool 2 4



After sizing the application and determining the number of reference virtual machines and the suggested disk storage layouts, use 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 (RVMs) and suggested Exchange data storage layout. In the example:

ExchangeRVM = Total reference virtual machine required for

Exchange = 312 RVMs

ExchangeDisks = Total disk numbers required for Exchange =

72 Disks

2. If customers wants to deploy other applications in the same VSPEX Proven Infrastructure, refer to the appropriate VSPEX Design Guides for the applications and size the total number of reference virtual machines and storage layouts for the combined workload.

For example, if the customer wants 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. 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 the example:

TotalRVMforApps = SQLRVM + ExchangeRVM + OracleRVM = 12 RVMs

+ 312 RVMs + 16 RVMs = 340 RVMs

TotalDisksforApps = SQLDisks + ExchangeDisks + OracleDisks =

7 Disks + 72 Disks + 55 Disks = 134 Disks

4. Discuss with your customer 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 number of disks and reference virtual machines suggested for the combined applications.

In the 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 90 percent utilization for the combined applications, the calculation would be:

TotalRVMNeededforAppsFinal = TotalRVMforApps / Maximum

Utilization = 340 RVMs / 90% = 378 RVMs

TotalDisksNeededforAppsFinal = TotalDisksforApps / Maximum

Utilization = 134 Disks / 90% = 149 Disks

Selecting the right VSPEX Proven Infrastructure



5. Use the details in Table 32 and the total number of reference virtual machines to select the minimum recommended VSPEX Proven Infrastructure.

For the example, EMC recommends the VSPEX Private Cloud for VMware for up to 500 reference virtual machines as the minimum VSPEX Proven Infrastructure for the combined workload.

Table 32. 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



* Includes the following VSPEX models: VSPEX Private Cloud for Microsoft and VSPEX Private Cloud for VMware

6. Refer to the appropriate VSPEX Proven Infrastructure and calculate the number of disks required for the VSPEX private cloud pool by using the virtual infrastructure building-block methodology.

For the example, EMC suggests a VSPEX Private Cloud for VMware for up to 500 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 number of disks required:

TotalDisksForPrivateCloud = 10 SAS Disks + 2 Flash Disks =

12 Disks

7. Aggregate the total number of disks required, including those for the combined applications, VSPEX private cloud pool, and the hot spare:

TotalDisks = TotalDisksNeededforAppsFinal +

TotalDisksForPrivateCloud + HotSpare = 149 Disks + 12 Disks

+ 5 Disks = 166 Disks

8. Compare this with the values in Table 33 to make sure the VSPEX Proven Infrastructure supported array can support the total number of disks required. If not, you may need to upgrade to the next VSPEX Proven Infrastructure model.



For the example, EMC suggests a VSPEX Private Cloud for VMware for up to 500 reference virtual machines as the VSPEX Proven Infrastructure and VNX5700 as the storage array. VNX7500 supports up to 500 disks in total, which meets the requirement of 166 disks. As a result, EMC recommends you consider the VSPEX Private Cloud for VMware for up to 500 reference virtual machines for the final selection.

Table 33. 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 2013 Qualification Worksheet

Question Answer

Number of mailboxes?

Maximum mailbox size (GB)?







EMC VSPEX for Virtualized Microsoft Exchange 2013€¦ · Contents EMC VSPEX for Virtualized...

Documents

Transcript of EMC VSPEX for Virtualized Microsoft Exchange 2013€¦ · Contents EMC VSPEX for Virtualized...