Business Continuity for Microsoft Exchange 2010 Enabled by EMC ...

3 downloads 180 Views 2MB Size Report
Identifying virtual processor allocation for VMs running Exchange server roles . ..... Test 2 – Within a site switchov
Chapte 1:

Introduction

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V A Detailed Review

EMC Information Infrastructure Solutions Abstract

The solution described in this white paper was designed, built, and tested by EMC in partnership with Microsoft® and Cisco®. This white paper highlights the benefits of a fully virtualized Exchange 2010 environment built on the Microsoft Hyper-V platform with EMC® CLARiiON® Unified Storage, leveraging Virtual Provisioning™, to provide larger mailbox capacity during initial deployment, and Cisco UCS B-Series servers to provide a full base for the entire Exchange Server and networking infrastructure. Testing was conducted at the Enterprise Engineering Center (EEC), Microsoft’s state-of-the-art enterprise solution validation laboratory on their main campus in Redmond, Washington. November 2010

Copyright © 2010 EMC Corporation. All rights reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com All other trademarks used herein are the property of their respective owners. Part number: H7337.2 Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

2

Table of Contents

Table of Contents Chapter 1: Introduction ............................................................................................ 9 Overview ........................................................................................................................................... 9 Exchange 2010 Tested Solutions ..................................................................................................... 9 Partnership .................................................................................................................................... 9 Virtualized Exchange 2010 solutions ............................................................................................ 9 Supported virtualization platforms ............................................................................................... 10 Executive summary ......................................................................................................................... 10 Overview ..................................................................................................................................... 10 Business case ............................................................................................................................. 10 Key results ................................................................................................................................... 12 Solution overview ............................................................................................................................ 12 Purpose ....................................................................................................................................... 12 Scope .......................................................................................................................................... 13 Audience ..................................................................................................................................... 13

Chapter 2: Technology and key components ....................................................... 14 Overview ......................................................................................................................................... 14 Exchange Server 2010 with native DAG mailbox resiliency configuration ..................................... 14 Windows 2008 R2 Hyper-V ............................................................................................................. 15 Technology .................................................................................................................................. 15 Microsoft Hyper-V........................................................................................................................ 15 EMC Unified Storage with Virtual Provisioning ............................................................................... 15 EMC CLARiiON overview ........................................................................................................... 15 Why use EMC Unified Storage with Microsoft Hyper-V? ............................................................ 17 Advanced CLARiiON CX4-480 capabilities ................................................................................ 17 Cisco Unified Systems B-series servers ......................................................................................... 18 Platform ....................................................................................................................................... 18 Components ................................................................................................................................ 18 Hardware used in this solution ........................................................................................................ 20 EMC Unified Storage CX4-480 ................................................................................................... 20 Cisco Unified Compute System .................................................................................................. 20 LAN and SAN switches ............................................................................................................... 21 Software used in this solution ......................................................................................................... 22

Chapter 3: Solution Design .................................................................................... 23 Overview ......................................................................................................................................... 23

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

3

Table of Contents

Solution design methodology .......................................................................................................... 23 Overview ..................................................................................................................................... 23 Key requirements ........................................................................................................................ 24 Multi-site design architecture .......................................................................................................... 25 Mailbox server high availability ................................................................................................... 25 Site resiliency considerations and design architecture ............................................................... 25 Virtualizing Exchange server roles .............................................................................................. 27 Exchange deployment building block .......................................................................................... 27 Identifying CPU and memory requirements .................................................................................... 28 Identifying the Exchange user profile type .................................................................................. 28 Identifying CPU requirements for Mailbox server failure contingency ........................................ 29 Identifying virtual processor allocation for VMs running Exchange server roles ........................ 29 Validating CPU capacity of Mailbox server for site failure contingency ...................................... 31 Summarizing CPU and memory requirements for the Mailbox server VMs ............................... 31 Identifying memory requirements for Mailbox server .................................................................. 32 CPU and memory requirements for Mailbox server summary .................................................... 32 Hub Transport and Client Access server role requirements ........................................................... 33 Hub/CAS server role requirements ............................................................................................. 33 CPU memory requirements for Exchange Hub/CAS roles ......................................................... 33 DAG Members and Hub/CAS server allocation .......................................................................... 33 Active Directory Domain Controller requirements ........................................................................... 34 Active Directory requirements ..................................................................................................... 34 Server selection........................................................................................................................... 34 Database availability design (DAG) design ..................................................................................... 35 What is a DAG?........................................................................................................................... 35 Planning your DAG deployment .................................................................................................. 35 Three DAGs design ..................................................................................................................... 35 Placement of the file share witness............................................................................................. 37

Chapter 4: Storage Design ..................................................................................... 38 Overview ......................................................................................................................................... 38 Exchange Mailbox server storage design with thin provisioning .................................................... 38 Methodology for sizing Exchange storage ...................................................................................... 39 Exchange storage design using building block methodology ......................................................... 39 What is a building block? ............................................................................................................ 39 Step 1. Identify user requirements .............................................................................................. 40 Step 2. Identify Exchange VM requirements ............................................................................... 41 Step 3. Identify and calculate storage requirements based on IOPS and capacity .................... 41 Step 4. Finalize the Exchange VM building-block ....................................................................... 46 Storage design summary ................................................................................................................ 47 Building block summary .............................................................................................................. 47 Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

4

Table of Contents

Capacity requirements summary ................................................................................................ 47 Total storage requirements summary ......................................................................................... 47 Determine the thin pool strategy ................................................................................................. 48 Mailbox server configuration summary ....................................................................................... 50

Chapter 5: LAN and SAN Architecture .................................................................. 51 Overview ......................................................................................................................................... 51 UCS server architecture .................................................................................................................. 51 Fabric Interconnects ........................................................................................................................ 51 SAN zoning and LAN connectivity .................................................................................................. 52 WAN for database replication ......................................................................................................... 52 Network load balancing and namespace planning ......................................................................... 54 Overview ..................................................................................................................................... 54 Exchange RPC Client Access and Address Book services ........................................................ 54 Regional namespace model........................................................................................................ 55 Network traffic ............................................................................................................................. 55 Monitoring the Outlook client network ports ................................................................................ 55

Chapter 6: Best Practices Planning ...................................................................... 57 Overview ......................................................................................................................................... 57 Exchange 2010 best practices ........................................................................................................ 57 Optimizing SAN best practices ....................................................................................................... 57 Mailbox server optimization for EMC storage ................................................................................. 58 Unified Computing System best practices and optimization ........................................................... 59

Chapter 7: Solution Validation ............................................................................... 60 Overview ......................................................................................................................................... 60 Introduction .................................................................................................................................. 60 Contents ...................................................................................................................................... 60 Methodology and tools .................................................................................................................... 61 Overview ..................................................................................................................................... 61 Jetstress 2010 ............................................................................................................................. 61 Loadgen ...................................................................................................................................... 62 EMC Unisphere ........................................................................................................................... 62 Exchange storage validation with Jetstress .................................................................................... 64 Overview ..................................................................................................................................... 64 Test configuration ........................................................................................................................ 64 Jetstress test results and CX4-480 performance ........................................................................ 64 Jetstress performance metrics and test results summary........................................................... 66 Database seeding performance ...................................................................................................... 67 Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

5

Table of Contents

Overview ..................................................................................................................................... 67 Database seeding considerations ............................................................................................... 67 Performing a seed operation ....................................................................................................... 68 Seeding performance .................................................................................................................. 68 Environment validation with Loadgen ............................................................................................. 68 Overview ..................................................................................................................................... 68 Test 1 – Normal operating condition – peak load ........................................................................... 70 Test 1 objectives ......................................................................................................................... 70 Test 1 configuration ..................................................................................................................... 70 Test 1 performance results and analysis .................................................................................... 71 Test 2 – Within a site switchover and host failure – peak load ....................................................... 72 Test 2 objectives ......................................................................................................................... 72 Test 2 configuration ..................................................................................................................... 72 Test 2 performance results and analysis .................................................................................... 72 Test 3 – Site failure simulation ........................................................................................................ 74 Test 3 objectives ......................................................................................................................... 74 Test 3 configuration ..................................................................................................................... 74 Test 3 performance results and analysis .................................................................................... 74 Datacenter switchover validation .................................................................................................... 76 Datacenter switchover process ................................................................................................... 76 Step 1. Terminating a partially failed datacenter (DAG is in DAC mode) ................................... 76 Step 2. Validate and confirm the prerequisites for the second datacenter ................................. 77 Step 3. Activating Mailbox servers (DAG is in DAC mode)......................................................... 77 Validating primary datacenter service restoration (failback) ........................................................... 78 Overview ..................................................................................................................................... 78 Mailbox server role failback ......................................................................................................... 78

Chapter 8: Conclusion ............................................................................................ 80 Appendixes ............................................................................................................... 81 Appendix A: References ................................................................................................................. 81 White papers ............................................................................................................................... 81 Product documentation ............................................................................................................... 81 Other documentation ................................................................................................................... 81 Appendix B: Terminology ................................................................................................................ 82

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

6

Table of Contents

List of figures Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. Figure 6. Figure 7. Figure 8. Figure 9.

Dynamic capacity management using EMC Virtual Provisioning functionality ....................... 11 Solution logical DAG design diagram ..................................................................................... 26 Exchange deployment building block ...................................................................................... 27 Database distribution per Exchange Mailbox role VMs .......................................................... 49 Bandwidth requirements from Microsoft‘s mailbox role calculator .......................................... 53 CAS array configuration .......................................................................................................... 54 Physical architecture for this solution ...................................................................................... 56 Unisphere summary page ....................................................................................................... 63 Exchange 2010 performance on CX4-480 with thin LUNs. .................................................... 65

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

CLARiiON CX4 storage systems features .............................................................................. 16 Cisco Unified Computing System components ....................................................................... 18 EMC Unified Storage CX4-480 ............................................................................................... 20 Cisco Unified Compute System .............................................................................................. 20 LAN and SAN switches ........................................................................................................... 21 Software used in this solution ................................................................................................. 22 Key customer requirements .................................................................................................... 24 Message mailbox requirements .............................................................................................. 28 CPU requirements ................................................................................................................... 29 CAS and Hub vCPU requirements .......................................................................................... 30 Megacycles requirements per VM ........................................................................................... 30 Exchange server block megacycle requirements ................................................................... 30 Mailbox server CPU requirements .......................................................................................... 31 Server memory requirements .................................................................................................. 32 Summary of CPU and memory requirements for mailbox role VM ......................................... 32 CPU and memory requirements by Exchange role ................................................................. 33 DAG implementation ............................................................................................................... 36 Exchange environment requirements ..................................................................................... 40 Exchange VM requirements .................................................................................................... 41 Mailbox size on disk summary ................................................................................................ 43 Database capacity requirements............................................................................................. 44 Database LUN sizes summary................................................................................................ 44 Log size requirements ............................................................................................................. 45 Building-block summary (based on 600 MB initial capacity) ................................................... 47 Capacity requirements summary(based on 600 MB initial mailbox capacity)......................... 47 Thin provisioning storage savings ........................................................................................... 47 Exchange server configurations for this solution .................................................................... 50 Jetstress test results summary................................................................................................ 66

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

7

Table of Contents

Table 30. Table 31. Table 32. Table 33. Table 34. Table 35. Table 36. Table 37. Table 38.

Seeding performance information ........................................................................................... 68 Primary counters and validation criteria .................................................................................. 70 Environment validation tests with Loadgen ............................................................................. 70 Validation of expected load for Test 1 ..................................................................................... 71 Performance results for Loadgen Test 1 ................................................................................. 71 Validation of expected load for Test 2 ..................................................................................... 72 Performance results for Loadgen Test 2 ................................................................................. 73 Validation of expected load for Test 3 ..................................................................................... 74 Performance results for Loadgen Test 3 ................................................................................. 75

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

8

Chapter 1: Introduction

Chapter 1: Introduction Overview This chapter introduces the contents of this white paper. It includes the following topics. Topic

See Page

Exchange 2010 Tested Solutions

9

Executive summary

10

Solution overview

12

Exchange 2010 Tested Solutions Partnership

This paper provides a solution designed by EMC in partnership with Microsoft and Cisco as part of the Exchange 2010 Tested Solutions venture. Exchange 2010 Tested Solutions is a joint venture between Microsoft and participating server, storage, and network infrastructure partners to examine common customer scenarios and key design decision points facing customers who are planning to deploy Exchange 2010. Through a series of solution white papers, this initiative provides examples of well-designed, cost effective, Exchange 2010 solutions deployed on the latest and greatest available hardware configurations offered by server and storage partners.

Virtualized Exchange 2010 solutions

As part of this new venture, EMC in partnership with Microsoft and Cisco have designed, built, and validated Exchange 2010 solutions that can help customers make decisions about deploying virtualized Exchange 2010 in their environment. The solution described in this white paper demonstrates how deploying Exchange in a virtualized environment can help customers realize the long-term benefits of their server and storage infrastructure investments.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

9

Chapter 1: Introduction

Supported virtualization platforms

Leveraging a Hyper-V virtualization platform with high-performance UCS servers and shared SAN resources provides greater user resource consolidation with more flexible disaster recovery choices. Today, Microsoft fully supports Exchange on both the Hyper-V platform and VMware technology, as well as on all virtualization products that comply with the Microsoft Server Virtualization Validation Program (SVVP). For Exchange Server 2010, Microsoft supports all server roles in virtualized environments, except for the Unified Messaging role. For more details about the: 

SVVP program, visit Microsoft at http://www.windowsservercatalog.com/svvp.aspx



Exchange 2010 requirements in virtualization deployments, visit http://technet.microsoft.com/en-us/library/aa996719.aspx

Executive summary Overview

In recent years, many IT organizations have been looking for effective cost savings measures for running their IT infrastructure. One of the technologies that allows enterprises to accomplish this goal is virtualization. Virtualization allows companies to lower IT costs, increase service levels, and add flexibility and agility to their application environment. This document presents a solution that validates a fully virtualized Exchange 2010 environment built with Microsoft Hyper-V with Cisco UCS B-Series Blade servers with Cisco Nexus 5000 Unified Fabric switches and MDS 9134 Fibre Channel switches connected to EMC‘s Unified Storage CX4-480 array. This solution showcases the new Exchange native data protection feature. The solution team (EMC, Cisco, and Microsoft) used comprehensive validation with tools, including Jetstress and Loadgen, to determine the performance boundaries and limits of the entire infrastructure. The team used and documented general best practices to provide information on how to deploy Exchange 2010 across multiple sites. These guidelines describe how to leverage thin provisioning with EMC storage to provide users with large mailboxes, allowing those mailboxes to grow in size over time without worrying about storage capacity limitations.

Business case

As customers transition from older Exchange Server versions to Exchange Server 2010, they are looking to take advantage of compelling new Exchange features and to improve resource utilization and operational efficiencies. Server virtualization, combined with innovations in server architecture and efficient storage arrays, are among the best methods to achieve the goals of modern IT groups. Innovations in server architectures enable unprecedented levels of host application resource consolidation enabled by:

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

10

Chapter 1: Introduction



Increased processor speeds



Greater network and storage capacity



A reduction in datacenter space, cabling, power, and cooling resources

Along with the server and application consolidation challenges, many organizations see a business need to improve user work efficiency by allowing them to keep older e-mail in their mailboxes for fast retrieval. This presents a challenge because having more e-mails in the messaging environment means that each user needs a much larger mailbox. Larger mailboxes mean that administrators need to allocate more storage to the users in order satisfy these new business requirements. Some studies conclude that 31 to 50 percent of allocated storage for messaging infrastructure is unused. Moreover, for moderate Exchange users, it could take years before all these large mailboxes fill to their capacity. During this time, the storage will become cheaper; allowing companies to purchase it at a much lower price than it would be at the time of deployment. Technology advances like Virtual Provisioning™ (also known as ― thin provisioning‖) can provide a solution for this challenge. With thin provisioning, companies can provide large mailboxes to their users at the time of deployment, while purchasing the storage necessary to satisfy only the initial capacity requirements as illustrated in Figure 1.

Figure 1. Dynamic capacity management using EMC Virtual Provisioning functionality ®

Specifically, EMC storage arrays, like EMC Unified Storage and Symmetrix with Virtual Provisioning technologies, provide additional benefits beyond traditional ― thin provisioning‖ including simplified storage management and improved capacity utilization. Virtual Provisioning enables customers to present a large amount of storage capacity to a host, and then consume only the needed space from a shared pool. When more capacity is required, customers can add it without having to add new databases, modify database copy layouts, or redistribute mailboxes to newly added databases. This lowers total cost of ownership (TCO) by reducing the initial over allocation of storage capacity and simplifies management by reducing the steps required to support growth.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

11

Chapter 1: Introduction

Key results

The solution described in this white paper shows the value of deploying Exchange 2010 on a virtualized environment by consolidating more than 30,000 users onto 12 Cisco UCS B-Series servers across three physical sites. Virtualization in this scenario provides a three to one consolidation ratio that could require up to 36 servers in a physical Exchange deployment. The tests used in this solution reveal that by using thin provisioning provided by EMC Unified Storage platforms, customers can save up to 243 TB of storage at the time of their Exchange 2010 deployment. EMC thin provisioning allows customers to plan for larger mailboxes for each user during the initial solution deployment. When more storage is required in the future, customers can simply add more disks to the storage pools and grow their database volumes. This procedure does not require downtime and does not affect performance.

Solution overview Purpose

The purpose of this white paper is to provide customers with information about how to deploy, test, and validate a virtualized Exchange 2010 solution on Microsoft‘s Hyper-V platform, Cisco‘s UCS systems, and EMC Unified Storage. The paper includes details about the solution‘s design and provides performance results recorded during the validation phase. This white paper describes how to simplify Exchange virtual deployment by leveraging the EMC building-block approach, which helps to deploy virtualized Exchange solutions more easily and effectively. It also describes how to leverage Unified Storage thin provisioning when deploying larger mailboxes in your Exchange Server 2010 environment. This document‘s objectives are to: 

Provide guidance and best practice methodologies for designing virtualized multi-site Exchange 2010 solutions.



Explain how to design an EMC Unified Storage CX4-480 storage array to support thin provisioning for Exchange 2010 mailbox storage.



Describe how to design and configure Exchange 2010 database availability groups (DAGs) across multiple sites.



Demonstrate how to design and configure Cisco UCS B-series servers and SAN infrastructures to support a multisite Exchange 2010 deployment.



Validate the solution using Microsoft tools such as Jetstress and Loadgen.



List the steps and procedures for performing a switchover and failover.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

12

Chapter 1: Introduction

Scope

The scope of this paper encompasses the following: 

The steps outlined during each stage are high-level in nature. You should read this information in conjunction with the Exchange 2010 documentation referenced at the Microsoft Technet website.



The setup of this environment simulates an enterprise Exchange 2010 environment. Actual customer configurations will be different. Use the information contained in this white paper only as a part of a rigorous analysis and design exercise.



Before implementing a solution in a production environment, consider the size and complexity of the environment. EMC recommends that you consult with the EMC Consulting or Microsoft Solutions consultants (MSCs) for onsite assistance with planning, installation, and integration requirements.

The information contained in this document is not intended to replace existing, detailed product implementation guides for deploying UCS servers, SANs, Exchange, or storage infrastructures.

Audience

This white paper is intended for information technology professionals who are involved in the evaluation, architecture, deployment, and data management of data center computer systems, storage systems, and Microsoft Exchange infrastructures.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

13

Chapter 2: Technology and key components

Chapter 2: Technology and key components Overview This chapter identifies and briefly describes the technologies and components used in this solution. It contains the following topics. Topic

See Page

Exchange Server 2010 with native DAG mailbox resiliency configuration

14

Windows 2008 R2 Hyper-V

15

EMC Unified Storage with Virtual Provisioning

15

Cisco Unified Systems B-series servers

18

Hardware used in this solution

20

Software used in this solution

22

Exchange Server 2010 with native DAG mailbox resiliency configuration Microsoft Exchange Server 2010 is an enterprise e-mail and communication system that allows businesses and customers to collaborate and share information. EMC enhances Exchange Server 2010 with the industry‘s broadest choice of storage platforms, software, and services. With the new version of Exchange 2010, Microsoft presents a new, unified approach to high availability (HA) and disaster recovery (DR) by introducing features such as DAGs, and online mailbox moves. Customers can now implement mailbox servers in mailbox resiliency configurations with database-level replication and switchover. Major improvements with the application database structure and I/O reduction include support for a larger variety of disk and RAID configurations including: 

High-performance Enterprise Flash Drives (EFDs)



Fibre Channel (FC) drives



Slower performing serial advanced technology attachment (SATA) drives



Serial attached SCSI (SAS) drives

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

14

Chapter 2: Technology and key components

Windows 2008 R2 Hyper-V Technology

Hyper-V is Microsoft‘s hypervisor-based virtualization technology that is integrated into most Windows Server 2008 x64 operating systems (Hyper-V is not available in the Web or Foundation editions of Windows Server 2008). As a virtualization solution, Hyper-V enables users to take maximum advantage of the server hardware by providing the capability to run multiple operating systems (on virtual machines) on a single physical server.

Microsoft Hyper-V

Microsoft Hyper-V is virtualization software that allows you to consolidate your servers by running (as virtual machines) several instances of similar and dissimilar operating systems on one physical machine. This cost-effective, highly scalable, virtual machine (VM) platform offers advanced resource management capabilities. Hyper-V minimizes TCO for your environment by: 

Increasing resource utilization



Decreasing the number of servers and all associated costs



Maximizing server manageability

For more details see the following websites: 

Microsoft Hyper-V visit Microsoft technical library at http://www.microsoft.com/windowsserver2008/en/us/hyperv.aspx.



Microsoft‘s Exchange 2010 Systems requirements for hardware virtualization visit Microsoft at http://technet.microsoft.com/en-us/library/aa996719.aspx.

EMC Unified Storage with Virtual Provisioning EMC CLARiiON overview

The EMC CLARiiON family of networked storage systems brings high performance to the mid-tier market with a wide range of storage solutions—all based on the powerful, proven, eight generations of CLARiiON architecture. CLARiiON provides multiple tiers of storage (enterprise Flash drives (EFDs), FC (FC), and SATA) in a single storage system. This system significantly reduces acquisition costs and management costs by allowing users to manage multiple storage tiers with a single management interface. ®

The next-generation CLARiiON systems, called the CX4 series with UltraFlex™ technology, deliver storage systems that you can easily customize by populating your I/O slots with either FC or iSCSI I/O modules. Products with multiple back ends such as the CX4-240, CX4-480, and CX4-960 can support disks operating at both two Gb/s and four Gb/s simultaneously. CLARiiON storage systems address a wide range of storage requirements by providing flexible levels of capacity, functionality, and performance. The CX4-120 supports up to 120 drives and connectivity for up to 128 HA hosts. The CX4-240 storage system expands the family, supporting up to 256 HA hosts and up to 240 Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

15

Chapter 2: Technology and key components

drives. The CX4-480 further expands the CX4 family by supporting 256 HA hosts and 480 drives. The high-end CX4-960 adds even more capability, supporting up to 512 HA hosts and up to 960 drives. Table 1 summarizes the basic features for the CLARiiON CX4 storage system. Table 1.

CLARiiON CX4 storage systems features

Feature

CX4-120

CX4-240

CX4-480

CX4-960

Maximum disks

120

240

480

960

Storage processors (SP)

2

2

2

2

Physical memory per SP

3 GB

4 GB

8 GB

16 GB

Max write cache

600 MB

1.264 GB

4.5 GB

10.764 GB

Max initiators per system

256

512

512

1024

High-availability hosts

128

256

256

512

Minimum form factor size

6U

6U

6U

9U

Maximum standard LUNs

1024

1024

4096

4096

SnapView™ snapshots

Yes

Yes

Yes

Yes

SnapView clones

Yes

Yes

Yes

Yes

SAN Copy™

Yes

Yes

Yes

Yes

MirrorView™/S

Yes

Yes

Yes

Yes

MirrorView/A

Yes

Yes

Yes

Yes

RecoverPoint/S

Yes

Yes

Yes

Yes

RecoverPoint/A

Yes

Yes

Yes

Yes

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

16

Chapter 2: Technology and key components

Why use EMC Unified Storage with Microsoft Hyper-V?

CLARiiON and Hyper-V work well together. Some of the reasons CLARiiON is an ideal fit for Hyper-V in the midrange storage market include: 

CLARiiON storage systems provide several flexible levels of models with FC and iSCSI interfaces. This allows the user to make the optimal choice of a storage system based on capacity, performance, and cost.



CLARiiON storage systems can scale quickly to manage anticipated data growth, especially as the storage needed for VMs increases on Microsoft Hyper-V Server.



CLARiiON Virtual Provisioning (thin provisioning) improves storage capacity utilization and simplifies storage management by presenting a VM with sufficient capacity for an extended period of time. With CLARiiON Virtual Provisioning, customers can provision less storage. Rather than buying additional capacity up front, customers can reduce or defer initial capacity requirements. Furthermore, customers can save on acquisition and energy costs by running their systems at higher utilization rates and adding capacity as needed without disrupting applications.



CLARiiON storage can be shared across multiple Microsoft Hyper-V Servers, allowing storage consolidation to provide efficient use of storage resources. This storage consolidation is valuable for clustering and quick migration.



VM applications and data on CLARiiON storage systems enhance performance and therefore maximize functionality, reliability, and efficiency of Microsoft Hyper-V Server as opposed to internal server storage.



The Unisphere™ Manager suite provides web-based centralized control of global disk space, availability, security, quality of service, and replication for VMs provisioned by the CLARiiON storage system.



The redundant architecture of the CLARiiON storage system provides no single point of failure, thereby reducing application downtime and minimizing business impact for storage upgrades.



The CLARiiON storage system‘s modular architecture allows a mixture of EFDs, FC, and SATA drives.

Advanced Advanced capabilities start with the scalability to meet both the needs of today and CLARiiON CX4- the requirements of tomorrow. EMC CLARiiON CX4-480 models are a low-cost 480 capabilities approach to deploying external storage. They provide an economical storage platform for applications such as replication, backup-to-disk, and a variety of data archiving tasks. This model‘s features include: 

15 drives per enclosure



Scaling up to 480 drives through additional expansion enclosures



Four FC front-end and four FC back-end buses per system



Choice of additional I/O connectivity with UltraFlex I/O modules (FC or iSCSI)



Storage for up to 256 hosts

With support for both iSCSI and FC connectivity, the EMC CLARiiON CX4-480 enables organizations to use the appropriate network interconnection for their Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

17

Chapter 2: Technology and key components

environments on the same system. In addition, users also have the option to expand their storage in the future. The EMC CLARiiON CX4-480 arrays support costeffective, shared storage by using iSCSI interconnection with widely available IP networking components for direct-attach to a network, using conventional Ethernet switches. EMC CLARiiON CX4-480 arrays, using four Gb/s and one Gb/s iSCSI connections, use modularity with I/O connectivity through UltraFlex to provide cost-effective, direct-attach configurations with a wide range of SAN switch options to create SANs for up to 64 high-availability servers. Each controller supports up to 12 x 4 Gb/s FC front-end ports or 16 x 1 Gb/s iSCSI. The EMC CLARiiON CX4-480 series delivers functionality that releases the benefits of tiered storage. It is the answer to storage consolidation for heterogeneous environments supporting Windows, Linux, AIX, HP-UX, Solaris, and VMware. The EMC CLARiiON CX4-480 supports FC, SATA II, low-power SATA II, and Flash drives.

Cisco Unified Systems B-series servers Platform

The Cisco Unified Computing System is a next-generation data center platform that unites compute, network, storage access, and virtualization into a cohesive system designed to reduce TCO and increase business agility. The system integrates a lowlatency; lossless 10 Gigabit Ethernet unified network fabric with enterprise-class, x86-architecture servers. The system is an integrated, scalable, multi-chassis platform in which all resources participate in a unified management domain.

Components

Table 2 describes the main system components of the Cisco Unified Computing System (UCS). Working as a single, cohesive system, these components unify technology in the data center. They represent a radical simplification in comparison to traditional systems, helping to simplify data center operations while reducing power and cooling requirements. The system amplifies IT agility for improved business outcomes. Table 2.

Cisco Unified Computing System components

Component

Description

Compute

The system is based on an entirely new class of computing system that incorporates blade servers based on Intel Xeon 5500, 5600, and 7500 series processors. The blade servers offer patented Cisco Extended Memory Technology to support applications with large datasets and allow more VMs per server.

Network

The system is integrated onto a low-latency, lossless, 10 Gbps unified network fabric. This network foundation consolidates what today are three separate networks: LANs, SANs, and high-performance computing networks. The unified fabric lowers costs by reducing the number of network adapters, switches, and cables, and by decreasing the power and cooling requirements.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

18

Chapter 2: Technology and key components

Virtualization

The system unleashes the full potential of virtualization by enhancing the scalability, performance, and operational control of virtual environments. Cisco security, policy enforcement, and diagnostic features are now extended into virtualized environments to better support changing business and IT requirements.

Storage access

The system provides consolidated access to both SAN storage and network attached storage (NAS) over the unified fabric. Unifying storage access means that the Cisco Unified Computing System can access storage over Ethernet, FC, FC over Ethernet (FCoE), and iSCSI, providing customers with choice and investment protection. In addition, administrators can pre-assign storage-access policies for system connectivity to storage resources, simplifying storage connectivity and management while helping to increase productivity.

Management

The system uniquely integrates all the system components, so that users are able to manage the entire solution as a single entity through Cisco UCS Manager software. Cisco UCS Manager provides an intuitive graphical user interface (GUI), a command-line interface (CLI), and a robust applicationprogramming interface (API) to manage all system configuration and operations. Cisco UCS Manager helps increase IT staff productivity, enabling storage, network, and server administrators to collaborate on defining service profiles for applications. Service profiles are logical representations of desired physical configurations and infrastructure policies. They help automate provisioning and increase business agility, allowing data center managers to provision resources in minutes instead of days.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

19

Chapter 2: Technology and key components

Hardware used in this solution EMC Unified Storage CX4480

Cisco Unified Compute System

Table 3 provides information about the EMC hardware used in this solution. Table 3.

EMC Unified Storage CX4-480

Item

Description

Storage

3 EMC Unified Storage CX4-480s – 1 per site

Storage connectivity to host(FC or iSCSI)

FC

Storage cache

16 GB

Number of storage controllers

2 per storage frame

Number of storage ports available/used

8 (4 per system processor (SP)) available per storage frame, 4 used (2 per SP)

Maximum bandwidth of storage connectivity to host

8 * 4 Gb/s

Disk type used in this solution

450 GB 15k rpm, FC

Total number of disks tested in solution

432 (360 for DBs and 72 for logs across 3 sites,144 per site)

Maximum number of spindles that can be hosted in the storage

480 in a single storage array

Table 4 provides information about the Cisco hardware used in this solution. Table 4.

Cisco Unified Compute System

Item

Description

Blade Server

4 x B200 M1 per site

Processors

2 x Intel Xeon x5570 (2.93GHz) per site

Memory

96 GB RAM (12 x 8GB DIMM) per server

Converged Network Adapter

M71KR-Q ( 2 x 10 Gigabit Ethernet and 2 x 4 Gbps FC) per server

Internal Blade Storage

2 x 146 GB SAS 10k rpm disk (RAID1) per server

Chassis

5108 (6RU) one per site

Fabric Extender

2 x 2104XP per site

Fabric Interconnect

2 x 6120XP per site

Fabric Interconnect Expansion Module

2 x 8-port 4 Gb/s FC per site

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

20

Chapter 2: Technology and key components

LAN and SAN switches

Table 5 provides information about the LAN and SAN switches used in this solution. Table 5.

LAN and SAN switches

Item

Description

10 Gigabit Ethernet switch

2 x Nexus 5010 (8 fixed 1GbE/10GbE ports, 12 fixed 10GbE ports, Datacenter Bridging) per site

FC switch

2 x MDS 9134 ( 32 fixed 4 Gbps ports) per site

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

21

Chapter 2: Technology and key components

Software used in this solution Table 6 provides information about software used in this solution. Table 6.

Software used in this solution

Item

Description

Hypervisor host servers

Windows 2008 R2 Hyper-V Enterprise

Exchange Server VMs

Windows 2008 R2 Enterprise

Exchange Server 2010 Mailbox server role

Enterprise Edition RU3 or later

Exchange Server 2010 Hub Transport and Client Access Server Role

Standard Edition RU3 or later

Multipath and I/O Balancing

EMC PowerPath

Antivirus Software (on Hub Transport servers)

ForeFront Protection 2010 for Exchange Server (v11)

®

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

22

Chapter 3: Solution Design

Chapter 3: Solution Design Overview This chapter describes the solution‘s design and contains the following topics: Topic

See Page

Solution design methodology

23

Multi-site design architecture

25

Identifying CPU and memory requirements

28

Hub Transport and Client Access server role requirements

33

Active Directory Domain Controller requirements

34

Database availability design (DAG) design

35

Solution design methodology Overview

The following section describes the methodology used to design this solution. The solution team used customer requirements and design assumptions as the key decision points during the Exchange 2010 environment implementation phase. The following questions represent some of the information the solution team considered during the design phase: 

What is the high-availability strategy for Exchange deployment?



Is there a business requirement for datacenter and application virtualization?



Is the current network and storage infrastructure sufficient to support the new Exchange 2010 features for high availability?



Are the network bandwidth between sites and network latencies within the recommended guidelines to support database seeding and log shipping over the long distance?

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

23

Chapter 3: Solution Design

Key requirements

Table 7 summarizes the key customer requirements and assumptions upon which the solution team designed, built, and validated this Exchange solution. Table 7.

Key customer requirements

Requirement

Description

32,400 users across three active sites

 10,800 active Exchange users per site  100% user concurrency during normal operation

Exchange User Profile Requirements

 2 GB mailbox quota (initial planned capacity of 600 MB per mailbox)  100 messages sent or received per day for each user profile  100% Outlook MAPI clients (cached mode)

Virtualization and consolidation for any new server and application in the datacenter

 Consolidation of all server roles by leveraging virtualization  Virtualization of all Exchange roles

HA requirements

 The HA must be able to tolerate an individual server failure or undergo maintenance without inducing service degradation or requiring site failover  The HA must be able to tolerate a single site failure without incurring service degradation  In site local recovery time objectives (RTO) and recovery point objective (RPO) requirements—5 minute RTO and 1 MB RPO (1 log file)  Site failure RTO and RPO—1 hour RTO and 5 MB RPO (5 log files)

Storage requirements

 Existing SAN infrastructure must be leveraged Customer already leveraging SAN with an EMC Unified Storage CX4-480 with 450 GB 15k rpm drives  Storage must support additional I/O overhead of 50% to support future user load. This additional IOPS overhead is required to support future Exchange acquisitions and to share CX4-480 with other applications.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

24

Chapter 3: Solution Design

Multi-site design architecture Mailbox server high availability

In order to address the server high-availability requirement, two copies of every mailbox database must be available. One copy is active and the other is passive. Both the active and passive copies of each mailbox database must be hosted on separate mailbox servers. If the Mailbox server that hosts the active database fails, or if an active mailbox database becomes inaccessible, the passive mailbox database becomes active on a different server in the same site.

Site resiliency considerations and design architecture

The DAG feature provides high availability and site resiliency for Exchange 2010 Mailbox servers. It manages database replication and activation. You can add and manage up to 16 Mailbox servers in the same DAG. DAGs provide server high availability within a site and can span geographical sites to provide site resiliency. Site resiliency requires an additional passive copy of every mailbox database hosted on a remote site‘s Mailbox server. When a site failure occurs, the passive mailbox databases at the remote site become active, providing client access to the mailbox content. When planning a site resiliency strategy for Exchange mailbox databases, you need to consider several conditions to create an effective DAG design, including network bandwidth/latency between sites and desired failover behavior. This solution has active mailbox users in all three locations and therefore the solution should include three separate DAGs with each DAG spanning two sites. Figure 2 illustrates how this solution distributes the DAGs across the three sites. In a solution where active mailbox users exist in all three sites, it is a best practice not to deploy a single DAG. With active mailboxes in more than one site, we cannot use the database activation coordination (DAC) mode to prevent unwanted database activations in an alternate site. This means that something as simple as a small, short-lived, network connectivity loss could result in an unnecessary database switchover or a quorum loss between DAG members. Deploying three active/passive DAGs will prevent this scenario. Each DAG has its primary member servers in one site. These primary member servers host the active and passive mailbox database copies for that site. The same DAG also has member servers in one of the other two sites. These additional members host a third (passive) mailbox database copy. The DAGs operate in an active/passive mode from the perspective of site resiliency. The DAG member servers in one site have all of the active mailbox database copies while member servers of the same DAG have the passive mailbox database copies. DAG design is discussed in more detail later in the paper.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

25

Chapter 3: Solution Design

Figure 2.

Solution logical DAG design diagram

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

26

Chapter 3: Solution Design

Virtualizing Exchange server roles

A Mailbox server role running on a physical server can be a member of only one DAG. However, running the Mailbox server in a VM enables a physical server to host mailboxes that belong to different DAGs. The Mailbox server in each VM can be a member of a different DAG. An individual physical server is a single point of failure. Though the servers have many redundant components, if the physical server experiences a catastrophic failure, all VMs that run on that server will also fail. By placing Mailbox servers with active and passive mailbox databases replicated from another server local site and a second Mailbox server with passive mailboxes replicated from a remote site, none of your users will lose Exchange access if an individual server failure occurs. The goal is to create a configuration that does not result in users losing access to their Exchange mailbox data. This can be achieved by designing Mailbox servers so that they host both active and passive database copies.

Exchange deployment building block

Exchange 2010 requires three Exchange Server roles in order to deliver functional messaging and collaboration services: 

Mailbox server role



Client Access server role



Hub Transport server role

The focus thus far has been on the Mailbox server role because it is the core Exchange role. We have discussed hosting two VMs running the Mailbox server role on the same hypervisor host. Each of the two Mailbox servers is a member of a different DAG. By adding a third VM that runs the Hub and CAS roles, we have the basis of an Exchange building block that can scale up the deployment by implementing multiple instances to support the required number of mailboxes.

Figure 3.

Exchange deployment building block

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

27

Chapter 3: Solution Design

Identifying CPU and memory requirements Identifying the Exchange user profile type

To start identifying CPU and memory requirements for this solution we need to know the Exchange user profile type. Customer requirements direct us to size for a 100message profile. The 100-message mailbox user action profile has the following characteristics and requirements: Table 8.

Message mailbox requirements

Parameter

Value

Messages sent per 8-hour day

20

Messages received per 8-hour day

80

Required megacycles per active mailbox

2

Required megacycles per passive mailbox

0.3

Mailbox replication megacycles factor per database copy

0.1

Required database cache memory per mailbox (MB)

6

The DAG design specifies two Exchange Mailbox server role VMs and one HUB/CAS VM per physical Hyper-V host with eight logical processors. In this design, one Exchange Mailbox server role VM hosts active and passive copies at the local site and the other VM hosts a third passive copy from a remote site. CPU and memory requirements must support server and site failure contingencies. The servers must be sized to handle the following conditions: 

A single server failure. If a single server fails, you need to make sure that there is no service degradation or failover requirements to another site. The failed server can be a Mailbox server, Client Access server, or a Hub Transport server.



A site failure. Accommodating a site failure requires that the surviving site support the failed site‘s entire workload.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

28

Chapter 3: Solution Design

Identifying CPU requirements for Mailbox server failure contingency

CPU and memory requirement calculations start with the Mailbox server role. During a server failure, the surviving servers at a site must support 10,800 mailboxes with a maximum of 100 percent mailbox access concurrency. Additionally, we need to provision sufficient megacycles so that CPU utilization does not exceed 80 percent. The following table lists the Mailbox server megacycle and memory requirement calculations. Table 9.

CPU requirements

Parameter

Value

Active megacycles

10,800 mailboxes x 2 megacycles per mailbox = 21600

Passive megacycles

0 (No passive mailboxes in this situation)

Replication megacycles

0.2 X 21600 active megacycles = 4320

Maximum mailbox access concurrency

1.00 (100%)

Total required megacycles during Mailbox server failure

(21600 + 4320) X 1.00 = 25920

Minimum required server megacycles

25920 / 0.80 = 32400

Cisco UCS B200 M1 servers with two Intel Xeon x5570 CPUs, and 96 GB memory deliver 5,500 new platform mailbox megacycles per CPU core and has a total of eight cores. Cisco obtains this value with Hyper Threading disabled in the testing environment. The total new platform mailbox megacycle capacity for this is server is 51,200 (6400 x 8). Based on the version of Windows 2008 R2 with Hyper-V used in this deployment, we can allocate a maximum of four virtual CPUs per guest VM. Hypervisor overhead is estimated at 10 percent for typical deployments. The following formula identifies the number of net megacycles per CPU core available to the VM. Net New Platform Mailbox Megacycles per Logical Processor Core (LP) = 6400 X (1 – 0.1) = 5500

Identifying virtual processor allocation for VMs running Exchange server roles

The design used for this solution includes three VMs per Hyper-V host. Two of the VMs will run the Mailbox server role and the third VM will run the Hub and CAS role. We also need to determine the number of Exchange Server blocks needed to support the mailboxes in each site to satisfy the site resiliency requirements. The Mailbox servers that host active mailboxes during normal runtime are paired together to address the server failure and server maintenance requirements. There is one pair of these Mailbox servers in our Exchange Server block design. The second pair of Mailbox servers in our Exchange Server block hosts mailboxes that are replicated from a remote site and are activated when a remote site fails. These Mailbox servers (hosting mailboxes replicated from a remote site) need 50 percent of the capacity that is required by the Mailbox server that hosts local mailboxes because they are not designed to tolerate a concurrent local server failure and remote site failure. Based on these parameters, we allocate the maximum number of virtual processors to the VMs that host the local mailbox copies. Each of these VMs is allocated four

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

29

Chapter 3: Solution Design

virtual processors. The VMs that host copies of remote mailboxes are allocated two virtual processors. The CAS and Hub server combination is typically allocated the same number of virtual processors that are required by the active Mailbox servers in the site. However, we expect the CAS/Hub role to require fewer compute resources than the Mailbox server role. For this reason, we allocate three virtual processors to the CAS/Hub Server role. Table 10.

CAS and Hub vCPU requirements

Virtual machine role

Virtual processors per VMs

Mailbox server (local mailboxes)

4

Mailbox server (replicated mailboxes from the remote site)

2

CAS and Hub combination

3

The next step is to determine if one Exchange Server block is sufficient to support the active mailboxes in a site during various failure and maintenance conditions. The first calculation identifies the available megacycles for each virtual processor, as shown in Table 11. Table 11.

Megacycles requirements per VM

Parameter

Value

Virtual processor megacycles

Net new platform mailbox megacycles per core times the total number of logical processors divided by the total number of virtual processors: 4950 X (8 / 9) = 4400

To determine the capacity of the Exchange Server Block, multiply the number of virtual processors in each VM running the mailbox role by the virtual processor‘s megacycle value, as shown in Table 12. Table 12.

Exchange server block megacycle requirements

Parameter

Value

Megacycles per mailbox VM with 4 virtual processors

4400 X 4 = 17600

Megacycles per mailbox VM with 2 virtual processors

4400 X 2 = 8800

The number of deployed Exchange Server blocks must support all of the mailboxes that are local to a site as well as the mailboxes that are replicated from a remote site and activated during a site failure. The following formula determines the number Exchange Server blocks required to support the minimum number of Mailbox server megacycles for the local site. Number of Exchange Server Bocks = 32400 / 20480 = 1.84

Since more than one Exchange Server block is required, and we cannot have a fraction of an Exchange block, we need two Exchange Server blocks to support the mailboxes. This means we need two VMs to support the mailbox roles.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

30

Chapter 3: Solution Design

Validating CPU capacity of Mailbox server for site failure contingency

We now need to validate that the VM in our Exchange Server block meets the site resiliency requirements for our deployment. To meet this requirement, each site needs the capacity to support an additional 10,800 active mailboxes in case its partner site fails. We have already computed the megacycle requirements for 10,800 mailboxes to be 32,400. Additionally, we have already estimated that each of our two logical processor VMs delivers 10,240 megacycles. The following calculation validates that the number of Exchange Server blocks with two logical processor VMs are required for supporting the additional 10,800 mailboxes that will become active during a site failure. Number of Exchange Server blocks = 32400 / (2 X 8800) = 1.84

Since the result of this equation is less than two, we can conclude that two Exchange Server blocks are sufficient for hosting the mailbox serves with the database copies that are replicated from a remote site and activated during a site failure.

Summarizing CPU and memory requirements for the Mailbox server VMs

We have identified the virtual processor requirements for each VM running the Exchange server roles. Based on the number of mailboxes at each site, we see that the VMs with four virtual processors have a megacycle capacity for supporting 5,400 local mailboxes, while the VMs with two virtual processors support 2,700 mailboxes that are replicated from a remote site and activated during a site failure. Table 13 summarizes this data. Table 13.

Mailbox server CPU requirements

VM Role

CPUs per VM

Mailbox (5,400 Mbx)

4

Mailbox (2,700 Mbx)

2

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

31

Chapter 3: Solution Design

Identifying memory requirements for Mailbox server

Table 14 shows the mailbox database cache and operating system memory requirement calculations. Table 14.

Server memory requirements VM hosting 5400 mailboxes

Parameter

Value

Minimum required mailbox database cache

6 MB x 5400 mailboxes x 1.00 = 31.6 GB

Minimum operating system memory requirement

(Minimum required mailbox database cache x 0.1) + 4 GB = 7.2 GB

Total minimum required memory during Mailbox server failure

31.6 GB + 7.2 GB = 38.8 GB

VM hosting 2700 mailboxes

CPU and memory requirements for Mailbox server summary

Parameter

Value

Minimum required mailbox database cache

6 MB x 2700 mailboxes x 1.00 = 15.8 GB

Minimum operating system memory requirement

(Minimum required mailbox database cache x 0.1) + 4 GB = 5.6 GB

Total minimum required

21.4 GB

Based on these calculations, we make the following vCPU and memory allocations to the VMs used to run the mailbox roles: Table 15. Summary of CPU and memory requirements for mailbox role VM VM Role

vCPUs per VM

Memory per VM

Mailbox (5400 Mbx)

4

39 GB

Mailbox (2700 Mbx)

2

22 GB

Note: For more details about Exchange 2010 memory and CPU requirements, visit ― Understanding Memory Configurations and Exchange Performance‖ at http://technet.microsoft.com/en-us/library/dd346700.aspx.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

32

Chapter 3: Solution Design

Hub Transport and Client Access server role requirements Hub/CAS server role requirements

Now that we have identified the Mailbox role CPU and memory requirements, we can calculate the Hub Transport and Client Access server role (HUB/CAS) requirements. The combined HUB and CAS role has a 1:1 CPU core ratio to the Mailbox server. The Hub/CAS servers must be designed to address the heaviest planned load condition, which is 20,800 active mailboxes during a site failover. Since four vCPUs are allocated to support 5,400 active mailboxes, four vCPUs are allocated to each VM running the Hub/CAS combined role. Note: This solution uses Microsoft ForeFront Protection 2010 for Exchange Server software to protect its data. For more information on this product, visit http://www.microsoft.com/forefront/protection-for-exchange/en/us/.

CPU memory requirements for Exchange Hub/CAS roles

Memory for the Hub/CAS role is also allocated based on the allocated Mailbox server role CPU core number. Two GB of RAM are allocated for every CPU core. Eight GB of RAM are allocated to the three-vCPU VM that is hosting the Hub/CAS role. Table 16.

DAG Members and Hub/CAS server allocation

CPU and memory requirements by Exchange role

Virtual machine role

vCPU per VM

Memory

Hub/CAS

3

8 GB

These calculations show that each blade server can host two VMs running the Mailbox server role and a third VM that runs the Hub/CAS server role. Placing two B200 blade servers into a local site and a remote site provides a building block that supports 2,700 mailboxes at two sites. Placing eight B200 blades servers into each site provides support for 10,800 mailboxes in each of the three sites for 32,400 mailboxes.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

33

Chapter 3: Solution Design

Active Directory Domain Controller requirements Active Directory requirements

Active Directory server CPU requirements for supporting the Exchange deployment are also calculated as a ratio of Mailbox server role cores to Active Directory cores. The ratio of equivalent CPU cores is 8:1 (Mailbox server role CPU cores to Active Directory server CPU cores). Note: An 8:1 ratio assumes 64-bit DC/GC server. For a 32-bit DC/GC server the ratio is 4:1. For additional references visit http://technet.microsoft.com/enus/library/dd346701.aspx. It is a best practice to accommodate the entire Active Directory database into memory at one time. Four GB to eight GB RAM on a 64-bit Active Directory server enables the caching of extremely large active directory deployments. For this deployment, the Active Directory services are provided outside the Exchange deployment. The Active Directory team worked closely with the Exchange design team to ensure that the Exchange Active Directory requirements are met for this Exchange deployment. Redundant Active Directory servers, as well as DNS servers, are provisioned in all three sites.

Server selection

A B200 Blade Server with dual Xeon x5570 processors has eight CPU cores, and can support up to 96 GB RAM, using 8 GB DIMMs. This server blade configuration meets the identified requirements for the Hyper-V root server and is chosen for our deployments.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

34

Chapter 3: Solution Design

Database availability design (DAG) design What is a DAG?

As discussed previously, a DAG is the base component of the HA and site resilience framework built into Microsoft Exchange Server 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. A DAG is a boundary for mailbox database replication, database and server switchovers and failovers, and for an internal component called Active Manager. Active Manager is an Exchange 2010 component that manages switchovers and failovers that runs on every server in a DAG.

Planning your DAG deployment

From a planning perspective, you should try to minimize the number of DAGs deployed. You should consider going with more than one DAG if you: 

Deploy more than 16 Mailbox servers



Have active mailbox users in multiple sites (Active/Active site configuration)



Require separate DAG-level administrative boundaries



Have Mailbox servers in separate domains (DAG is domain bound)

As required by the customer, each site will have active users. Our design accommodates this requirement by deploying the active/active database distribution model. In the active/active distribution model, active Mailbox database copies are dispersed across both datacenters. Each Mailbox server becomes a primary datacenter for its specific mailbox user population. Passive database copies may exist in alternate data centers for site resiliency. When service for the users of one datacenter fails, the mailboxes containing those users are activated in the other data center.

Three DAGs design

Based on this model, customers can deploy a single DAG that has active mailbox users at each site. However, in the event that the servers in one site temporarily lose connectively with the other servers in the DAG, the cluster in that site will lose quorum and cease to function correctly. For this reason, this solution deploys three DAGs, with each DAG containing member servers from the primary datacenter that host the primary and secondary database copies. Each DAG also contains servers in one of the alternate datacenters that host the third database copy. The new design has three active/passive DAGs with each datacenter hosting the primary and secondary copies from one DAG, as well as the third copy from another DAG. The two local database copies are balanced between four Exchange VMs to accommodate an Exchange VM or physical host maintenance/failure scenario. Table 17, for example, shows that if the Exchange –VM MBX1 on Host 1 fails, its database copies will automatically become activate on MBX2 on Host 2. The same is true if the opposite happens. If the Exchange VM on MBX2 on Host 2 fails, its database copies automatically become active on MBX1 on Host 1.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

35

Chapter 3: Solution Design

The same process would occur for a physical server failure. This design provides for the best utilization of the physical hardware and allows for mailbox resiliency within each physical site. Table 17 provides more details about DAG deployment and the distribution of the database copies among Exchange VMs. In this table, databases are labeled as follows: 

C1 = Active database copy during normal operations



C2 = Local passive database copy during normal operations



C3 = Remote passive database copy during normal operations

Table 17.

DAG implementation

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

36

Chapter 3: Solution Design

Placement of the file share witness

The Exchange 2010 DAG feature is built on top of Windows Failover Clustering. A DAG has a quorum when the majority of its members is online and can communicate with the other online members of the DAG. Quorum for the DAG is maintained at the cluster level. It is critical that each DAG member have a consistent view of the DAG's underlying cluster configuration. The quorum acts as the definitive repository for all configuration information relating to the cluster. The quorum is also used as a tiebreaker to avoid ―s plit-brain‖ syndrome. Split-brain syndrome is a condition that occurs when DAG members cannot communicate with each other even though they are up and running. You can prevent split-brain syndrome by ensuring that a majority of the DAG members (and in the case of DAGs with an even number of members, where the file share witness is located on a witness server outside of the DAG) are available and interacting. The witness server can be any server running the Windows Server operating system, but Microsoft recommends placing it on a highly available server that is handled by the team responsible for managing Exchange. By default, when a DAG is created with an even number of nodes, the file share witness is automatically placed on a Hub Transport server. When deploying a virtualized Exchange environment, it is common to locate VMs running the Mailbox server role and VMs running the Hub transport role on the same physical Hyper-V root server. Therefore, for all virtualized environments, it is a best practice to locate the file share witness on another highly available server. Note: If the witness server you specify is not an Exchange 2010 server, then you must add the Exchange Trusted subsystem universal security group to the local administrators group on the witness server. In this test environment, file share witness for each DAG is configured on a local domain controller. An alternate file share witness on a domain controller in the remote site is also configured. In a production environment, we do not recommend placing the file share witness on a domain controller due to security implications. You should only use this location as a last resort.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

37

Chapter 4: Storage Design

Chapter 4: Storage Design Overview This chapter contains the following topics: Topic

See Page

Exchange Mailbox server storage design with thin provisioning

38

Methodology for sizing Exchange storage

39

Exchange storage design using building block methodology

39

Storage design

47

Exchange Mailbox server storage design with thin provisioning EMC CLARiiON‗s thin provisioning feature provides a great benefit for customers deploying large Exchange mailboxes. Physical space is only assigned from a thin pool to the thin LUNs, as needed, using 1 GB increments, up to the logical size specified for each LUN. You can also dynamically expand a thin pool by adding more disks without disruption or requiring downtime. Upon expansion, a thin pool can easily be rebalanced so that the data and workload are wide-striped evenly across the current and newly added disks that make up the pool. Thin LUN technology works with CLARiiON‘s metaLUN feature and traditional LUNs to provide powerful, cost-effective, flexible solutions. CLARiiON thin LUNs present more storage to an application than is physically available. Storage administrators are free from the time-consuming administrative work of deciding how to allocate disk drive capacity. Instead, an array-based mapping service builds and maintains all of the storage structures based on a few high-level user inputs. Disk drives are grouped into storage pools that form the basis for provisioning actions. Physical storage is automatically allocated only when writing new data blocks. With thin provisioning, administrators can provision the minimum amount of required storage to the host while allowing the host to see fully allocate storage. For example, you can provision a 1.2 TB LUN to an Exchange host to satisfy the capacity requirements for 450 users with 2 GB mailbox. After creating a file system on this LUN, and populating mailboxes to 600 MB, only one-third of the LUN (400 GB) is used. At that point, the CLARiiON array intelligence figures out that the remaining 800 GB is not being used and keeps it in reserve. Yet the host continues to think it has access to the remaining 800 GB.

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

38

Chapter 4: Storage Design

Methodology for sizing Exchange storage Sizing and configuring storage for use with Microsoft Exchange Server 2010 can be a complicated process, driven by many factors, which vary from organization to organization. Properly configured Exchange storage, combined with a properly sized server and network infrastructure, can guarantee smooth Exchange operations and an excellent user experience. This solution uses the building-block approach to simplify sizing and configurations of storage used with Microsoft Exchange Server 2010. This approach helps exchange storage administrators to deploy large amount of Exchange storage on EMC Unified Storage more easily and efficiently. Microsoft and EMC provide tools to help you properly size your Exchange Mailbox server. The Exchange 2010 Mailbox server Role Requirements Calculator tool from Microsoft provides CPU and memory guidance‘s in addition to storage recommendations. EMC‘s Exchange 2010 storage calculator tool is specifically designed and tailored to provide more in-depth details and accurate recommendations for deploying Exchange on EMC storage. Specifically, the EMC calculator includes thin provisioning features for sizing Exchange storage. Make sure to consult with a server and storage vendor for additional guidelines during the design and deployment phases. You can download these tools from the following locations: 

For access to the Exchange 2010 Mailbox server Role Requirements Calculator from Microsoft, visit the Microsoft Exchange Team Blog at http://msexchangeteam.com/archive/2009/11/09/453117.aspx.



For the EMC Exchange 2010 storage calculator visit Powerlink at http://powerlink.emc.com.

Exchange storage design using building block methodology What is a building block?

A building block represents the required amount of resources required to support a specific number of Exchange 2010 users on a single VM. You derive the number of required resources from a specific user profile type, mailbox size, and disk requirement. Using the building-block approach removes the guesswork and simplifies the implementation of Exchange VMs. After designing the initial Exchange Mailbox server VM building block, you can easily reproduce it to support all of the users in your organization that share similar user profile characteristics. By using this approach, Exchange administrators can create their own building blocks based on their company‘s Exchange environment requirements. This approach is very helpful when a customer expects future growth, as it makes Exchange environment additions easy and straightforward. You can apply this methodology when Exchange is deployed in a either physical or virtual environments and when storage is fully provisioned or thin provisioned (such as in this solution). EMC‘s best practices involving the building block approach for an Exchange Server

Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

39

Chapter 4: Storage Design

design has been very successful for many customer implementations. To Create a building-block for a Mailbox server role VM, you need to: 1. Identify user requirements 2. Identify Exchange VM requirements 3. Identify and calculate storage requirements based on both IOPS and capacity 4. Finalize the Exchange VM building block The following sections detail these four steps.

Step 1. Identify user requirements

Exchange administrators can create building blocks based on the user requirements in their organizations. To obtain user profile information for your existing Exchange environment use Microsoft Exchange Server Profile Analyzer tool available at http://www.microsoft.com/downloads/details.aspx?familyid=C009C049-9F4C-4519A389-69C281B2ABDA&displaylang=en. Table 18 summarizes key customer requirements for this solution. This information is required to perform the Exchange storage design. Table 18.

Exchange environment requirements

Parameter

Value

Target message profile ( messages sent/received/ user/day)

100 messages (0.10 IOPS)

Additional IOPS overhead (per customer requirements)

50%

Target average message size (KB)

75 KB

Outlook mode

100% MAPI

Initial average mailbox size (MB)

Up to 600 MB

Target maximum mailbox size (MB)

2 GB

Total number of mailboxes in the environment

32,400

Total number of users per site

10,800

Number of active users per Mailbox server

2,700

Number of sites

3

Deleted items retention window (―d umpster‖) (days)

14

Logs protection buffer

5 days

Drive type, speed and capacity

450 GB FC, 15k rpm drive

Database read/write ratio

3:2 in mailbox resiliency configurations

One of the customer requirements for this Exchange 2010 solution is to provide a Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

40

Chapter 4: Storage Design

two GB mailbox capacity for each of the 32,400 users (10,800 users per site) with the initial mailbox capacity of up to 600 MB. Therefore, our design should incorporate performance and space requirements based on a 2 GB mailbox per user. Make sure to calculate the initial storage capacity requirements so that you purchase only the capacity required at implementation.

Step 2. Identify Exchange VM requirements

Based on the DAG design and the allocation of Exchange Mailbox role VMs per Hyper-V host, four Exchange VMs per site will host 5,400 users with two database copies (2,700 active and 2,700 passive) and the other four VMs will host only 2,700 passive users. Earlier in the design process, we identified CPU and memory requirements for Exchange Mailbox role VMs. Table 19 summarizes these requirements. Table 19.

Exchange VM requirements

VM Role

vCPUs per VM

Memory

Mailbox (5400 Mbx)

4

43 GB

Mailbox (2700 Mbx)

2

24 GB

For this solution, we have eight Exchange Mailbox role VMs per site (24 VMs for a three-site deployment).

Step 3. Identify and calculate storage requirements based on IOPS and capacity

As a best practice for calculating Exchange storage, always calculate both IOPS, and then capacity requirements. The procedures described here show the basic calculations for a targeted user profile. The customer requires that their current infrastructure, which includes an EMC Unified CX4-480 array with 450 GB 15k rpm drives, be incorporated into the design. Based on the DAG design in this solution, each database supports 450 active mailboxes. Each mailbox server supports six databases or 2,700 active mailboxes on six DB LUNs and six Log LUNs. Therefore, we will use 12 LUN building block supporting increments of 2,700 mailboxes. Based on this methodology, each Exchange site requires 12 building blocks: 

Four VMs with 5,400 users, with two building blocks each, totaling eight building blocks



Four VMs with 2,400 users, with one building block each totaling four building blocks

Calculate the mailbox I/O requirements It is important to understand the amount of database I/O per second (IOPS) consumed by each mailbox user because it is one of the key transactional I/O metrics needed to adequately size your storage. Pure sequential I/O operations are not factored in the IOPS per Mailbox server calculation because storage subsystems can handle sequential I/O much more efficiently than random I/O. These operations include background database maintenance, log transactional I/O, and log replication I/O. This step describes how to calculate the total IOPS required to support all mailbox Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

41

Chapter 4: Storage Design

users using the building block methodology. Note: To determine the IOPS for different message profiles, refer to the table provided at the following Microsoft TechNet location: Understanding Database and Log Performance Factors The total transactional required IOPS = IOPS per mailbox user * number of mailboxes * I/O overhead factor: 0.10 * 2700 * 20% = 324 IOPS per Exchange VM with 2700 users

Note: Twenty percent overhead includes log IOPS and BDM IOPS. In the above procedure, we determined the IOPS requirements to support one building block of 2,700 users. To support 10,800 users per site, we need four of these building blocks. Moreover, to support three database copies per site, we need 12 building blocks. Therefore, the total IOPS required per site is 3,888 (324 IOPS * 12 building blocks) and the all three sites together require 11,664 IOPS. Calculate the IOPS disk requirements You calculate the number of disks required to provide the desired user performance, based on the IOPS requirements by using the formula shown below. (User IOPS x Read Ratio) + Write Penalty (User IOPS x Write Ratio)/IOPS capability of disk type chosen (324* .6) + 4(324.5 * .4) / 155 = 4.6 (round-up 5 disks for RAID 5)

Note: IOPS capacity per disk type can vary depending on the disk type, storage array model, and cache capacity available. Contact your EMC representative to obtain the latest guidelines for disk types and speeds. Our IOPS calculations concluded that: 

To support 2,700 users with 324 IOPS, five disks are required.



To support 10,800 users per site with 1,296 IOPS, 20 disks are required.



To support 32,400 IOPS per site with 3,888, 60 disks are required.

Calculate the mailbox size on disk It is important to determine the mailbox size on disk before attempting to determine your total storage requirements. A full mailbox with a 2 GB quota requires more than 2 GB of disk space because we have to account for the: 

Prohibit send/receive limit



Number of messages the user sends/receives per day



Deleted item retention window (with or without calendar version logging and single item recovery enabled)



Average database daily variations per mailbox

You can use the Microsoft Mailbox Server Role Requirements Calculator to calculate this number, but we have provided the raw calculations below if you prefer to do Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

42

Chapter 4: Storage Design

them manually. Use the following calculations to determine the mailbox size on disk for this solution based on an initial mailbox size of 600 MB and a fully provisioned mailbox quota of 2 GB: Mailbox Size On Disk = Mailbox Limit + Whitespace + Dumpster Whitespace = 100 messages / day x 75/1024 MB = 7.3 MB Dumpster for 600 MB mailbox = (100 messages / day x 75/1024 MB * 14 days) + (600 MB x 0.012) + (600 MB x 0.058) = 144.2 MB Dumpster for 2 GB mailbox = (100 messages / day x 75/1024 MB * 14 days) + (2048 MB x 0.012) + (2048 MB x 0.058) = 246 MB

Table 20 details the summary of the Mailbox size on disk requirements. Table 20.

Mailbox size on disk summary

Mailbox quota

Dumpster size (2 weeks)

White space

Total size on disk

600 MB

7.3 MB

144.2

752 MB

2 GB

7.3 MB

246 MB

2,301 MB (2.25 GB)

Calculate the capacity requirements and LUN sizes There are two sets of calculations used for determining the capacity requirements when using thin provisioning: 

Calculations based on the initial capacity requirements. This is necessary to identify the storage requirements to support the initial mailbox capacity. You base the storage capacity purchase on these calculations.



Calculations based on thin provisioned capacity requirements—This is necessary to properly configure the size of the database and log LUNs, to be presented to the host. This is also necessary for provisioning the required storage for a fully provisioned mailbox future.

When leveraging thin provisioning on a EMC Unified Storage, it is a best practice to separate the Exchange logs from the database thin pools. Since log volumes do not have the same growth pattern as the database volumes, it makes sense to separate them. This also provides the flexibility to put log volumes on different disk types or different RAID levels than the database volumes. Following this best practice, we separate the DBs and logs onto different LUNs. This allows the log volumes to be located on RAID 1/0 LUNs for better performance. Unless the user profile changes significantly in the future, customer do not anticipate any increased capacity for the logs. Therefore the log LUNs are not thin provisioned. More details are provided in Table 14 describes the logs and database capacity requirement calculations. Database capacity requirements To determine the actual database size, use the following formula: Database Size = x x Business Continuity for Microsoft Exchange 2010 Enabled by EMC Unified Storage, Cisco Unified Computing System, and Microsoft Hyper-V—A Detailed Review

43

Chapter 4: Storage Design

Based on the number of mailboxes, the actual size of the mailboxes, and the database growth overhead factor of 20 percent, the database size is 2,379 GB for initial capacity and 7,290 GB for fully provisioned capacity as shown in the following table. Table 21.

Database capacity requirements

Mailboxes per server

Database size requirements (initial capacity for 600 MB mailbox)

Database size requirements (fully provisioned capacity for 2 GB mailbox)

2,700

2,379 GB

7,290 GB

(2,700 users * 752 MB + 20%)

(2,700 users * 2.25 + 20%)

Database LUN sizes To determine the total database LUN size requirements for 2,700 users, use the following: Database LUN size = +