VIRTUALIZING MICROSOFT APPLICATIONS IN A … Vblock 1 ... • Application protection using Microsoft...

White Paper

EMC SOLUTIONS GROUP

Abstract

This white paper presents a solution that can help a service provider or IT department segregate information, without the need for separate physical infrastructures or implementations. It uses VCE Vblock™ 1 to consolidate Tier 1 Microsoft applications and VMware® vCloud™ Director with VMware vCenter™ Chargeback to enable a chargeback model for a multi-tenancy environment.

February 2012

VIRTUALIZING MICROSOFT APPLICATIONS IN A MULTI-TENANCY ENVIRONMENT WITH VCE VBLOCK 1 A Detailed Review

Virtualizing Microsoft Applications in a Multi-tenancy Environment with VCE Vblock 1 – A Detailed Review

2

Copyright © 2012 EMC Corporation. All Rights Reserved.

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

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

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

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

Vblock is a trademark of EMC Corporation in the United States.

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

Intel and Xeon are trademarks of Intel Corporation in the U.S. and/or other countries.

Part Number H8798.2

3 Virtualizing Microsoft Applications in a Multi-tenancy Environment with VCE Vblock 1 – A Detailed Review

Table of contents

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

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

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

Key benefits and considerations ...................................................................................................... 7

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

Purpose ........................................................................................................................................... 9

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

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

Terminology ..................................................................................................................................... 9

Technology overview ........................................................................................................... 11

Introduction to the components ..................................................................................................... 11

VCE Vblock 1 .................................................................................................................................. 11

EMC CLARiiON CX4-960 ............................................................................................................. 12

EMC Ionix Unified Infrastructure Manager .................................................................................. 12

Cisco Unified Computing System Manager ................................................................................ 12

VMware vCenter Server .............................................................................................................. 12

EMC Replication Manager .............................................................................................................. 12

VMware vCloud Director ................................................................................................................. 13

VMware vShield ............................................................................................................................. 13

VMware vCenter Chargeback .......................................................................................................... 13

Microsoft Systems Center Operations Manager .............................................................................. 13

Microsoft Forefront Endpoint Protection 2010 ................................................................................ 13

Configuration ...................................................................................................................... 14

Overview ........................................................................................................................................ 14

Design considerations ................................................................................................................... 14

Physical environment ..................................................................................................................... 15

Hardware resources ....................................................................................................................... 16

Software resources ........................................................................................................................ 16

Environment profile ........................................................................................................................ 17

Deployment ........................................................................................................................ 18

Overview ........................................................................................................................................ 18

Vblock 1 ......................................................................................................................................... 18

Authentication ............................................................................................................................... 18

Advanced Management Pod ........................................................................................................... 19

UCS Manager ................................................................................................................................. 19

Ionix UIM ....................................................................................................................................... 20


4

vCenter Server ................................................................................................................................ 21

vShield .......................................................................................................................................... 22

vCloud Director .............................................................................................................................. 24

SCOM............................................................................................................................................. 25

Forefront ........................................................................................................................................ 26

Replication Manager ...................................................................................................................... 27

vCenter Chargeback ....................................................................................................................... 27

Microsoft Exchange Server 2010.......................................................................................... 28

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

Design ........................................................................................................................................... 28

Configuration ................................................................................................................................. 30

Jetstress validation ........................................................................................................................ 31

Microsoft SQL Server ........................................................................................................... 33

Overview ........................................................................................................................................ 33

Design ........................................................................................................................................... 33

Configuration ................................................................................................................................. 33

Microsoft SharePoint Server 2010 ....................................................................................... 36

Overview ........................................................................................................................................ 36

Design ........................................................................................................................................... 36

Test methodology .......................................................................................................................... 36

Configuration ................................................................................................................................. 37

Combined testing ................................................................................................................ 39

Overview ........................................................................................................................................ 39

Exchange 2010 Server ................................................................................................................... 39

Performance .............................................................................................................................. 39

Test results ................................................................................................................................ 39

SQL Server ..................................................................................................................................... 44

Performance .............................................................................................................................. 44

Test results ................................................................................................................................ 44

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

Performance .............................................................................................................................. 46

Test results ................................................................................................................................ 47

Failure testing ..................................................................................................................... 49

Overview ........................................................................................................................................ 49

Design ........................................................................................................................................... 49

Blade failure test scenario ......................................................................................................... 49

Switch failure test scenario ....................................................................................................... 49


Test results .................................................................................................................................... 49

Blade failure test scenario ......................................................................................................... 49

Impact on Exchange .................................................................................................................. 49

Impact on the SQL Server .......................................................................................................... 50

Impact on the SharePoint Server ............................................................................................... 50

Switch failure test scenario ....................................................................................................... 51

Replication Manager testing ................................................................................................ 52

Overview ........................................................................................................................................ 52

Design ........................................................................................................................................... 52

Configuration ................................................................................................................................. 52

Test results .................................................................................................................................... 56

vCenter Chargeback ............................................................................................................ 60

Overview ........................................................................................................................................ 60

Configuration ................................................................................................................................. 60

Test results .................................................................................................................................... 60

Conclusion ......................................................................................................................... 67

Summary ....................................................................................................................................... 67

Findings ......................................................................................................................................... 67

References .......................................................................................................................... 69

White papers ................................................................................................................................. 69

Product documentation .................................................................................................................. 69

Other documentation ..................................................................................................................... 69


6

Executive summary This solution provides a simplified architecture to host the infrastructure of two individual companies, ensuring that each company’s information is fully separated from that of the other and cannot be accessed. The Virtual Computing Environment Company (VCE) Vblock™ 1 (Vblock) powered by the Intel® Xeon® processor is leveraged as the infrastructure, greatly simplifying the overall environment and reducing operational and management costs. For example, with added software products from EMC and VMware, usage of the environment can easily be tracked, simplifying chargeback as a result.

The solution is designed in accordance with Microsoft application best practices and with customer service-level agreements (SLAs) in mind. From the service provider’s perspective, allocated resources are based on the customer need and, if required, can be expanded. All customer applications are fully protected with EMC® Replication Manager snapshots.

As part of a multi-tenant environment, service providers need to provide secure separation between tenants. Secure separation involves the provisioning of a pool of shared resources so they are dedicated and available to a tenant for consumption. As additional tenants are added to the environment, the resources of existing tenants are untouched and the integrity of the applications, workloads, and data is uncompromised. Resources in the converged stack are presented to the tenant as a dedicated stack. Each tenant can have different amounts of processing capacity, storage allotment, and dedicated network resources.

The design guidance and example solution provided in this white paper can be leveraged by service providers who are servicing separate customers or by companies whose IT organizations service different departments. For example, human resources (HR) and financial information is highly confidential within any organization and only available to members of those respective departments. The methodology provided can help a company to achieve this information separation without burdening its IT department with separate infrastructures, which means the environments remain simplified and overall costs are reduced.

This solution demonstrates the delivery of virtualized Microsoft applications in a multi-tenant environment, each with separate requirements for user profile and size where the physical infrastructures are shared across the Vblock. This solution outlines how to segregate companies or departments, such as HR and Finance, that handle sensitive or confidential information from other teams. There is a distinct need to isolate workloads and information to ensure they cannot be compromised or viewed by another company or another department within a company. This solution showcases a comprehensive design methodology that service providers or customers can use to create a scalable building block for their environments.

In this case, the environment includes Microsoft Exchange Server, SharePoint Server, and SQL Server. The architecture includes cloud management elements, such as chargeback, and management to show how the Vblock platform can enable the consolidation of several Tier 1 Microsoft-based workloads. EMC Ionix™ Unified Infrastructure Manager (UIM) 2.0 is utilized for overall Vblock management. VMware® vCloud™ Director, for virtual data center provisioning, integrated with VMware

Business case

Solution overview


vCenter™ Chargeback, is used to demonstrate granular usage reporting to enable a chargeback model for a multi-tenant deployment scenario.

In the new cloud infrastructure, a service provider must support multi-tenant environments for customers while assuring the service levels agreed with the customer. Vblock 1 is a perfect solution for this type of situation because it allows virtual machines to be automatically allocated to the blades in a balanced way, using a distributed resource scheduler (DRS), while at the same time allowing complete separation of each organization’s network and security infrastructure. Because vCenter Server is used with vCloud Director, the underlying hardware is invisible to the organization and vApps and virtual machines can be created on demand by each organization. VMware vShield™ then ensures that the networks used by the organization, and even between separate vApps, are inaccessible by any other networks. This separation guarantees complete network security even though the same hardware is being used.

The service provider, therefore, only has to allocate resources to organizations who can then create their own infrastructure (vApps, virtual machines, and networks) without much intervention from the service provider. The service provider can use vCenter Chargeback to monitor and cost the organization’s deployment, based on several cost models, and charge accordingly.

Organizations can decide to move their applications to the service provider’s cloud at the pace that they are comfortable with, be that one virtual machine at a time, or all applications at once. This simplifies the deployment of private, public, and hybrid clouds for any organization and simplifies management of the system by the service provider.

• Excellent performance levels achieved during the combined testing of a two-customer (medium and large) Microsoft application workload

• Easy-to-use, simple cloud management interface that service providers, IT departments, and their customers can utilize in a multi-tenancy environment using vCloud Director

• Sizing and performance for medium and large Exchange Server, SharePoint Server, and SQL Server virtual environments

• Minimal impact and no downtime during Vblock hardware failure simulation

• Results from two cost models—allocation-based and utilization-based costing

• Protection of all three Microsoft applications within the two organizations through Replication Manager snapshots with minimal impact

Table 1 describes some additional points for consideration.

Key benefits and considerations


8

Table 1. Considerations

Multi-tenancy Using Vblock 1 with Ionix UIM, vShield, and vCloud Director enables multi-tenant environments that are simple to deploy and use.

vCloud Director

• A service provider must be aware of the order and necessity of allocating resources for the organization to be able to create vApps and virtual machines.

• Raw device mappings (RDMs) need to be created in vCenter Server because they cannot be added in vCloud Director.

Authentication Domain controllers (DCs) for the organization’s network must be outside the Vblock if network address translation (NAT) is used.

EMC Replication Manager

Replication Manager does not support NAT so must be located in the organization’s vApp.

Combined testing All applications performed well within both organizations and were run concurrently without performance degradation.

Hardware failure The Vblock and VMware High Availability (HA) enables a quick recovery from blade failure without a major impact on the applications. Switch failure did not have any impact.

Vblock For Cisco Unified Computing System (UCS), trunk VLANs must be added for each blade to be able to allow communication inside an organization network when using more than the external network.

UIM • No more than eight blades can be provisioned at a time. Create a

script to ensure that the HLUs are identical in all storage groups.

• Thick storage pools are not supported.


Introduction

This white paper presents a solution that explores aspects of scalability and performance with a focus on cloud management with vCloud Director and vCenter Chargeback. It uses the Vblock 1 infrastructure package, which appeals to both the internal and external service provider and system integrator markets.

The scope of this paper is to document:

• The deployment of Microsoft applications on Vblock 1

• Performance and test results

• Multi-tenancy on Vblock 1

• Application protection using Microsoft Forefront and Systems Center Operation Manager

• The protection of a multi-tenancy environment using EMC Replication Manager

• The impact of hardware failure on Vblock 1 and Microsoft applications

• The use of vCenter Chargeback to illustrate different usage costing models

The intended audience for the white paper is:

• Customers

• EMC partners

• Internal EMC personnel

This paper includes the following terminology.

Table 2. Terminology

Term Description

AMP VCE Advanced Management Pod.

DAG Database availability group.

DC Domain controller.

Disk transfers/sec Disk transfers/sec is the rate of read and write operations on the disk.

DRS Distributed resource scheduler.

LUN Logical unit number. A unique identifier used to identify logical storage objects in a storage system.

NAT Network address translation.

RAID Redundant array of independent disks.

RDM Raw device mapping.

Purpose

Scope

Audience

Terminology


10

Term Description

Throughput The number of individual I/Os the storage system can process over time, which is measured in I/Os per second (IOPS).

vApp A logical entity composed of virtual machines and software applications that can be installed and managed as a unit. A vApp uses the industry standard Open Virtualization Format (OVF) to encapsulate the components of a multitier application, along with the operational policies and service levels associated with it.

VMDK Virtual Machine Disk format. A VMDK file stores the contents of a virtual machine's hard disk drive. The file can be accessed in the same way as a physical hard disk.

VMFS VMware virtual machine file system.


Technology overview

This solution provides a comprehensive design methodology aimed at helping service providers to create a scalable building block for their customers, including Microsoft Exchange Server 2010, SharePoint Server 2010, and SQL Server. The solution simulates a multi-tenant scenario by demonstrating two distinct customer environments—ACME (large) and OMZE (medium)—each with separate requirements for user profile and size, where the physical infrastructures are shared across the Vblock.

The following components are used in this solution:

• VCE Vblock 1

EMC CLARiiON® CX4-960

EMC Ionix Unified Infrastructure Manager

Cisco Unified Computing System

VMware vCenter Server

• EMC Replication Manager

• VMware vCloud Director

• VMware vShield

• VMware vCenter Chargeback

• Microsoft Systems Center Operation Manager

• Microsoft Forefront Endpoint Protection 2010

With Vblock Infrastructure Platforms, VCE delivered the industry’s first completely integrated IT offering that combines best-in-class virtualization, networking, computing, storage, security, and management technologies with end-to-end vendor accountability. This converged infrastructure enables rapid virtualization deployment, so customers quickly see a return on investment (ROI). Vblock Infrastructure Packages offer varying storage capacities and processing and network performance, and they support such incremental capabilities as enhanced security and business continuity.

Three Vblock Infrastructure Platforms are offered: Vblock 1 is used in this solution. Vblock 1:

• Is designed for large sizes and numbers of virtual machines in a compact footprint, supporting midsized configurations that deliver a broad range of IT capabilities to organizations of all sizes

• Consists of the Cisco Unified Computing System, EMC CLARiiON CX4 or EMC Celerra® unified storage, and VMware vSphere™

• Delivers performance and virtualization for large or mid-sized companies and is suitable for data centers of any size, including remote-office locations

For more information about Vblock 1, visit the VCE website: http://www.vce.com/solutions/vblock/

Introduction to the components

VCE Vblock 1

http://www.vce.com/solutions/vblock/�


12

EMC CLARiiON CX4-960 EMC CLARiiON CX4-960 provides premium-performance, maximum-capacity networked storage. It enables you to handle the most data intensive workloads and large consolidation projects, while reducing energy consumption. CLARiiON CX4-960 combines CLARiiON five 9s availability with innovative technologies—Fully Automated Storage Tiering (FAST), FAST Cache, Flash drives, compression, Virtual Provisioning™, 64-bit operating system, and multicore processors. It also supports up to 512 highly available, dual-connected hosts and scales up to 960 disk drives for a maximum capacity of 1,899 TB. UltraFlex™ technology gives you dual-protocol, online-expandable connectivity options, and the ability to integrate future technologies.

EMC Ionix Unified Infrastructure Manager EMC Ionix Unified Infrastructure Manager (UIM) provides simplified management for Vblock Infrastructure Packages, including provisioning, configuration, change, and compliance management. By managing Vblocks as a single entity, operational expenses and integrated management for Vblock network, compute, and storage resources can be dramatically reduced.

With a consolidated dashboard view, policy-based management, automated deployment, and deep visibility across the Vblock environment, Ionix UIM is integral and essential to effectively and efficiently manage Vblock Infrastructure Packages.

Cisco Unified Computing System Manager Cisco Unified Computing System (UCS) Manager provides centralized management capabilities, creates a unified management domain, and serves as the main processing center of the Cisco UCS. This embedded device-management software manages the entire system as a single logical entity through an intuitive GUI, a command line interface (CLI), or an XML API. Role and policy-based management is performed using service profiles and templates. This construct improves IT productivity and business agility. Now infrastructure can be provisioned in minutes instead of days, shifting IT's focus from maintenance to strategic initiatives.

VMware vCenter Server VMware vCenter Server is the simplest, most efficient way to manage VMware VSphere whether you have ten or tens of thousands of virtual machines. It provides unified management of all the hosts and virtual machines in the data center, from a single console with an aggregate performance monitoring of clusters, hosts and virtual machines. VMware vCenter Server gives administrators deep insight into the status and configuration of clusters, hosts, virtual machines, storage, the guest OS, and other critical components of a virtual infrastructure all from one place.

EMC Replication Manager manages EMC point-in-time replication technologies through a centralized management console. Replication Manager coordinates the entire data replication process—from discovery and configuration to the management of multiple application-consistent, disk-based replicas. Auto-discover your replication environment and enable streamlined management by scheduling, recording, and cataloging replica information including auto-expiration. With Replication Manager, you can put the right data in the right place at the right time—on-demand or based on schedules and policies that you define. This application-centric product allows you to simplify replica management with application consistency.

EMC Replication Manager


VMware vCloud Director enables you to deliver resources to organizations as virtual data centers. By logically pooling compute, storage and networking capacity into virtual data centers, IT can manage a more efficient data center with complete separation between the consumption and delivery of infrastructure and IT services.

VMware vCloud Director builds on VMware vSphere to provide a complete, out-of-the-box solution that enables IT organizations to act as true service providers for the businesses they support. Companies can leverage their existing investments to build elastic, secure, multi-tenant clouds that are compatible with their existing applications. VMware vCloud Director integrates with management and service desk solutions to enable the move to cloud computing with minimal disruption.

VMware vShield provides comprehensive perimeter network security for virtual data centers with VMware vShield Edge, part of the VMware vShield family. vShield Edge integrates seamlessly with VMware VSphere and includes essential network gateway services so you can quickly and securely scale your cloud infrastructures.

VMware vCenter Chargeback improves the utilization of virtual infrastructure with accurate visibility into the true costs of virtualized workloads. It enables line-of-business owners to have full cost transparency and accountability for self-service resource requests.

Microsoft System Center Operations Manager (SCOM) 2007 R2 enables organizations to reduce the cost of data center management across server operating systems and hypervisors through a single, familiar, and easy-to-use interface. It provides numerous views that show state, health, and performance information, as well as alerts generated according to some availability, performance, configuration, or security situation being identified. In this way, operators can gain a rapid insight into the state of the IT environment, and the IT services running across different systems and workloads.

Forefront Endpoint Protection 2010 enables businesses to align security and management to improve endpoint protection, while greatly reducing operational costs. It builds on System Center Configuration Manager 2007 R2 and R3, allowing customers to use their existing client management infrastructure to deploy and manage endpoint protection. This shared infrastructure helps reduce ownership costs while providing improved visibility and control over endpoint management and security.

VMware vCloud Director

VMware vShield

VMware vCenter Chargeback

Microsoft Systems Center Operations Manager

Microsoft Forefront Endpoint Protection 2010


14

Configuration This solution simulates the role of a service provider using Vblock 1 to host a multi-tenancy cloud environment for two organizations. The first organization, ACME, hosts a large Microsoft application infrastructure and the second, OMZE, hosts a medium-sized Microsoft application infrastructure.

The solution is configured as follows:

• Each organization can deploy vApps for its own applications (Microsoft Exchange, SharePoint, and SQL) and the virtual machines inside the separate vApps. The service provider allocates the resources necessary for each organization to be able to deploy their vApps and virtual machines in vCloud Director, using separate logins. Each organization uses a completely separate virtual network and has no access to the other organization’s resources.

• All the virtual machines are hosted using a CLARiiON CX4-960 for disk storage and management. The virtual machines co-exist on the ESX® servers on Vblock 1 and are automatically distributed among the physical hosts by VMware DRS.

• UCS Manager and Fibre Channel over Ethernet (FCoE) technologies are the backbone of the virtual infrastructure, providing a data center architecture for administrators that is easy to use and manage. The platform, optimized for virtual environments, is designed within open industry-standard technologies and aims to reduce the total cost of ownership (TCO) and increase business agility. The system integrates a low-latency, lossless 10 gigabit Ethernet (GbE) unified network fabric with enterprise-class, x86-architecture servers. The system is an integrated, scalable, multi-chassis platform in which all resources participate in a unified management domain.

• Vblock 1 and VMware High Availability (HA) allow for full redundancy in case of hardware failure.

• SCOM is used for application monitoring and Forefront Endpoint Protection is used for application security for each organization.

• Replication Manager is used to manage multiple-application, consistent, disk-based replicas.

• vCenter Chargeback is used to accurately generate resource allocation or usage, with the actual cost calculated according to a defined cost model. This cost can then be charged back to the customer at a chosen rate.

This solution includes the following design considerations:

• RDMs were used because the replication technology (Replication Manager) requires them.

• Separate LUNs were used as boot disks for the virtual machines for Replication Manager. A service provider can use one large LUN to simplify the creation of virtual machines but a different replication or backup technology would have to be used in that case.

• External networks can be used for the virtual machines and firewalled to get around NAT issues with authentication and Replication Manager, but the service provider is limited by the amount of IP addresses and vShield would

Overview

Design considerations


only be used for firewalling. This has security implications—for example, only one level of security would be available, and the separation of organization networks would be compromised.

• Best practice LUN layouts were used for each application instead of using tiered pools to maximize application I/O performance.

Figure 1 illustrates the overall physical architecture of the environment.

Figure 1. Environment overview

Physical environment


16

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

Table 3. Hardware requirements

Equipment Used for Quantity Configuration

Vblock 1 Exchange, SharePoint, SQL, Replication Manager, SCOM, Forefront Security

1 Each UCS contains 8 B-200 blades. The blades are split 50/50.

• 2 x blades with 96 GB of RAM with 2 sockets—quad CPUs each

• 14 x blades with 48 GB of RAM with 2 sockets—quad CPUs

73 x 2 TB SATA drives

41 x 600 GB 10 k FC drives

10 x 450 GB 15 k FC drives

Management servers

Advanced Management Pod module and authentication

2 16-core 64 GB RAM

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

Table 4. Software resources

Software Version

Vblock 1:

• Ionix UIM 2.0.986

• UCS Manager 1.3(1c)

• vCloud Director 1.0

• vCenter Chargeback 1.5.0

• vSphere with VMware vCenter 4.1

• vShield Edge 1.0, Update 1

Replication Manager 5.3.2

SCOM 2007 R2

Windows Server 2008 R2 Enterprise Edition

Windows Server 2008 R2 Standard

Exchange Server 2010 SP1 Enterprise Edition

SharePoint Server 2010 Enterprise Edition

SQL Server 2008 R2 Enterprise Edition

Forefront Protection for Exchange Server 2010

Forefront Protection for SharePoint 2010

Hardware resources

Software resources


The environment profile is detailed in Table 5.

Table 5. Simulated configuration

Application Requirements Customer “OMZE” (Medium) Quantity/Type/Size

Customer “ACME” (Large) Quantity/Type/Size

Exchange

Server

Exchange mailbox count total 500 5,000

Exchange mailbox size 2 GB 2 GB

Exchange IOPS (per mailbox) 0.15 IOPS 0.15 IOPS

Exchange—DAG used? Yes, 2 HA copies Yes, 2 HA copies

Exchange—number of messages per user 150 150

SharePoint

Server

SharePoint—total user count 7,000 16,000

SharePoint—total data ~1 TB ~2 TB

SharePoint—max content database size ~200 GB ~100 GB

SharePoint—document size range 75 k to 2 MB 75 k to 2 MB

SharePoint—total site collection count 10 (2 per content database)

20 (1 per content database)

SharePoint—size per site 10 GB 10 GB

SharePoint—sites per site collection 10 10

SharePoint—total site count 100 200

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

50%/20%/30% 80%/10%/10%

SharePoint—user concurrency 10% 10%

SQL Server

SQL—TPC-E user count 20,000 users 75,000 users

SQL—read response times - data/logs <20 / N/A milliseconds (ms)

<10 / N/A ms

SQL—write response times - data/logs < 20 / 5 ms < 20 /5 ms

SQL workloads TPC-E TPC-E

SQL workload profile - size 250 GB 800 GB

Environment profile


18

Deployment

This section describes the deployment of the hardware and software used in this solution.

• Vblock 1

• Authentication

• Advanced Management Pod

• UCS Manager

• Ionix UIM

• vCenter Server

• vShield

• vCloud Director

• SCOM

• Forefront

• Replication Manager

• vCenter Chargeback

For processing power, the Vblock 1 servers consisted of 16 Cisco UCS B200 M2 blade servers, each with two quad-core Intel Westmere CPUs. Each chassis in a Vblock 1 system had eight UCS B200 blades. The first blades in each chassis had 96 GB of RAM, while the remaining blades had 48 GB of RAM. Two Cisco 6120 switches were used as Fabric Interconnects.

Cisco UCS 6120 Fabric Interconnects provided both network connectivity and management capabilities to all attached blades and chassis. The 6120 series offered line-rate, low-latency, lossless 10 GbE and FCoE functions. In addition, by supporting unified fabric, the 6120 series provided both LAN and SAN connectivity for all blades within its domain.

The uplink switches were two Cisco MDS 9506 switches. Cisco MDS 9500 Series Multilayer Switches integrated the high-performance Fibre Channel (FC) and IP into a single module, connecting the 10 GbE and CLARiiON FC storage. Disk storage was provided by a CLARiiON CX4-960 with 450 and 600 GB FC disks and 2 TB SATA disks. Each UCS blade was running VMware ESX Server 4.1. Each blade had two 10 GB converged network adapters to carry network and storage data. The 16 blades in the two chassis were configured as a VMware HA cluster managed by a single VMware vCenter 4.1 server.

Two DC virtual machines were built for each of the three distinct organizations—the service provider, ACME, and OMZE.

The service provider’s DCs were used for authenticating the Advanced Management Pod (AMP) servers and the vCenter Chargeback server. These DCs were located on the AMP servers.

Overview

Vblock 1

Authentication


The ACME and OMZE DCs were also located on the AMP servers because the active directory (AD) does not work with NAT. The DCs are only allowed to have real IP addresses and NAT produces authentication issues as a result. Since these are DCs, it is assumed that organizations would prefer not to have them in the cloud so as to have complete control over their authentication security. Also, a prerequisite for Exchange Server 2010 installation is that Exchange must contact the DC with the flexible single master operations (FMSO) role, so the option of using a read-only DC does not work. The DCs with the FMSO role were given four CPUs and 4 GB of RAM each and the secondary DCs were given two CPUs and 4 GB of RAM. This was more than enough to deal with all of the Vblock application authentications.

The VCE Advanced Management Pod (AMP), which was external to Vblock 1 and hosted on two ESX servers, consisted of Ionix UIM, vCenter Server, vShield Manager, vCloud Director, vCloud Director database, and vCenter Chargeback. The IOPS were low and SATA II thin pools were sufficient to support the AMP servers.

The configurations for the AMP server and ACME LUN are detailed in Table 6 and Table 7.

Table 6. AMP server configuration

Virtual machine Quantity CPUs RAM (GB)

UIM 1 2 8

vCenter 1 2 6

vCloud Director database 1 4 8

vCloud Director 1 1 2

vShield 1 1 3

vCenter Chargeback 1 4 4

Table 7. AMP LUN configuration

Virtual machine Role Quantity LUN sizes Storage pool

UIM Boot 1 200

1 TB SATA II R1 Thin

vCenter Boot 1 50

vCloud Director database Boot 1 200

vCloud Director Boot 1 50

vShield Boot 1 8

vCenter Chargeback Boot 1 200

The Vblock consisted of dual Cisco UCS 5108 chassis, 16 Cisco B200-M1 blades interconnected through the Cisco 6120 Fabric Interconnects. Once the Fabric Interconnects were configured according to the Cisco UCS 6100 Series Fabric Interconnect Hardware Installation Guide, access to the UCS and Vblock networks

Advanced Management Pod

UCS Manager


20

were set up using Cisco UCS Manager, a Java application that provides a user interface for Cisco UCS management, as shown in Figure 2.

Before provisioning was started, the Protect Configuration check box in the local disk configuration policy was cleared in the UCS Manager. If Protect Configuration is enabled and the local disk configuration policy encounters mismatches between the previous service profile and the new service profile, all subsequent service profile associations with the server are blocked.

After the VLAN was set up, Ionix UIM was used to fully provision the rest of the Vblock. UCS Manager was used to monitor hardware or gain direct KVM console access. Each blade had to be configured to use VLAN trunking for multiple VLANs within the Vblock for both organizations.

Figure 2. UCS Manager

A Red Hat Enterprise Linux (RHEL) virtual machine was installed with all the appropriate RHEL Package Groups for use with Ionix UIM, with two CPUs, 8 GB of RAM, and 200 GB virtual machine disk format (VMDK) to accommodate the PostgreSQL database that is required. Figure 3 illustrates the Ionix UIM. For installation information, refer to the EMC Ionix Unified Infrastructure Manager Version 2.0 Service Pack 1 Installation Guide.

Ionix UIM


When deploying Vblock 1, a maximum of eight blades was provisioned per service offering, leading to multiple service offerings, despite no hard limit in Ionix UIM. Because of the multiple provisioning of service offerings, the host LUN numbers were not the same across all the blades, which led to the virtual machines being unable to move to blades in different services.

Ionix UIM 2.0 does not support thick storage pools for ESX boot LUNs but does support thin storage pools and RAID groups. The blades were provisioned in a RAID group for better I/O performance over a pool.

Figure 3. Ionix UIM

vCenter Server was installed on the AMP servers and all 16 Vblock blades were added as ESX servers. Once all the servers were added, vCloud Director was able to connect to the vCenter Server for further configuration. RDMs must be added in vCenter Server because they cannot be added in vCloud Director. VMware virtual machine file system (VMFS) volumes must also be added in vCenter Server before they can be added as datastores in vCloud Director. Resources were virtualized by creating the DRS clusters, datastore, and virtual network switches using vSphere, and then creating a provider data center in vCloud Director.

For high availability and even distribution of the virtual machines across the ESX servers, VMware HA, DRS, and vMotion were configured and enabled in vCenter Server. A separate vCenter Server was created for the AMP servers and the DCs.

vCenter Server


22

All blades were configured to use distributed switches. This solution had one distributed switch for the external ESX network. Internal networks were added through vCloud Director, which created network port-groups in the distributed switch.

Figure 4 provides a view of the vCenter Server showing the 16 blades and an expanded OMZE organization.

Figure 4. vCenter Server

vShield deployed one vShield Edge device for each organization. The Edge devices were virtual machines (one CPU, 256 MB RAM) that were assigned to each organization’s resource pool. The Edge devices created the internal networks and performed the NAT for the virtual machines. For vCloud Director, inbound NAT was one-to-one and outbound NAT was many-to-one only. This is the only NAT configuration supported by vCloud Director. The vShield Edge devices were virtual machines and were protected by VMware HA in this solution.

Each vShield Edge device was assigned to one organization so there was complete separation of networks between the organizations as shown in Figure 5. Each organization had its own internal network for communication between the virtual machines. The vShield firewall was configured to allow an organization's IP addresses to connect only to that organization's vApps. In this way, only authorized users within an organization can connect to the applications hosted inside the Vblock.

vShield


Figure 5. Separate customer networks

vShield also has a firewall for each Edge device that can be configured to allow only certain IP addresses or subnets to connect to hosts on the internal networks for added security. Figure 6 shows the vCloud Director interface to vShield.

Figure 6. vCloud Director interface to vShield


24

vCloud Director requires an Oracle database server to be installed and to hold all the configuration information. The service provider uses the web interface to create the organizations, configure each organization’s resources and resource limits, add datastores, configure networking and NAT, and add organization users.

Each organization can use the web interface to create their vApps, and then create virtual machines in their vApps. In this solution, each organization had four vApps: SQL, SharePoint, Exchange, and Infrastructure. The Infrastructure vApp contains the virtual machines for infrastructure servers like Replication Manager, SCOM, and Forefront. Only an organization’s vApps, virtual machines, and networks are visible to that organization.

The organization’s virtual data centers (vDCs) should be created from the service provider’s vDC to allocate resources for the vApps. Service providers must add datastores to the organization so that the virtual machines can be created on them. For each virtual machine, the service provider should enable the correct datastore, and disable the other datastores, to ensure that the correct virtual machine uses the correct datastore. Otherwise, vCloud Director uses the next available datastore automatically.

Note After adding a datastore, the storage resource pool for the organization must be expanded before it can be used.

As RDMs cannot be added in vCloud Director, they must be added in vCenter Server to each virtual machine before they are visible in vCloud Director.

Enough disk space must be allocated to the vCloud Director server to store all the media (ISOs) that are uploaded to the catalogs for use in installing virtual machines or installing software on the virtual machines. Catalogs that contain the vApp templates and media can be shared between organizations. In this solution, an OS template was used to install the organizations’ virtual machines. The template was created in vCenter Server and imported into an organization’s catalog and then the catalog was shared between both organizations.

A service provider allows for the creation of a virtual machine using vCloud Director by:

• Adding a disk for the new virtual machine in the organization’s storage

• Expanding the size of the storage resource pool to include the new disk

• Disabling all other disks in the organization so that the new disk is used for the new virtual machine

Note Alternatively, the service provider can create a large datastore to enable the customer to create multiple virtual machines.

An organization’s administrator can create a virtual machine using vCloud Director by:

• Creating a vApp

• Adding a virtual machine to vApp

• Choosing a template from the catalog (either the organization’s or a public catalog)

vCloud Director


• Changing the virtual machine name and network—the network choice can be a static IP, automatically allocated from a network pool, or a dynamic host configuration protocol (DHCP)

• Deploying the virtual machine

• Editing the properties of the virtual machine to perform Guest OS Customization (password and Sysprep, for example)

• Starting the virtual machine

Figure 7 illustrates a vApp in vCloud Director.

Figure 7. A vApp in vCloud Director

SCOM provides an easy-to-use monitoring environment that can monitor all servers, applications, and clients to provide a comprehensive view of the health of an organization’s IT environment. Management packs (MPs) are available for Microsoft products and third-party products to extend SCOM management capabilities to operating systems, applications, and other technology components. MPs contain best practice knowledge to discover, monitor, troubleshoot, report on, and resolve problems for a specific technology component.

Figure 8 shows the servers that are being monitored in the example organization, ACME.

SCOM


26

Figure 8. Administration with SCOM

To ensure comprehensive protection, Forefront Protection 2010 for Exchange Server (FPE) was deployed on both the Exchange hub transport and mailbox server roles. This multi-layered approach to server protection provides improved security. As a first line of defense, FPE can be installed on the Edge transport and hub transport servers to provide anti-malware and anti-spam scanning of messages as they enter or exit the messaging domain. FPE can also be installed on mailbox servers to provide scanning for messages that are not scanned in transport and to provide additional scanning during malware outbreaks.

Microsoft Forefront Protection 2010 for SharePoint (FPSP) was deployed on the SharePoint front-end servers to prevent users from uploading or downloading documents containing malware, out-of-policy content, or sensitive information to SharePoint libraries.

Microsoft Forefront Protection Server Management Console (FPSMC) 2010 provides multi-server management for FPE and FPSP in the same organization. The management console delivers an easy-to-use graphical interface for server discovery, configuration deployment, reporting, quarantine management, and engine and definition updates, as shown in Figure 9.

Forefront


Figure 9. Forefront Protection Server Management Console

Replication Manager 5.3.2 was used in this solution. Because Replication Manager does not support NAT, the Replication Manager virtual machines were deployed in each organization’s Infrastructure vApp. Each Replication Manager virtual machine was allocated two CPUs with 6 GB RAM and had a 100 GB boot drive. EMC Solutions Enabler, EMC Navisphere® command line interface (CLI), and the EMC SnapView™ admsnap utility were installed as prerequisites for Replication Manager. The Replication Manager server was not used as a mount host as the mount host for each organization was a virtual machine in another vApp.

vCenter Chargeback requires an Oracle or a SQL database server to be installed to hold application-specific data such as cost models, chargeback hierarchies, users, and roles. A web interface enables the service provider to create the cost models, chargeback hierarchies, users, roles and, most importantly, to generate cost and usage reports for the hosted organizations.

vCenter Chargeback has data collectors that interact with the vCenter Server and vCenter Server database and with the vCloud Director database and vShield. The data collectors synchronize the information between the vCenter Chargeback database and the various other vCenter application databases of vCenter Server or vCloud Director, for example. The following cost models were used for ACME and OMZE respectively: fixed cost and actual usage, and fixed cost and allocation.

Replication Manager

vCenter Chargeback


28

Microsoft Exchange Server 2010 In this solution, the ACME Exchange organization consists of two mailbox servers and two client access and hub transport servers. The OMZE Exchange organization consists of two servers with mailbox server, client access server, and hub transport server roles installed on each of them.

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

The Exchange Server 2010 client access array and network load balancer are implemented to provide load balancing between the client access servers.

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

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

• Specific user profile type

• Mailbox size

• Disk requirements

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

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

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

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

Table 8 and Table 9 show the user profile and building block used in this solution’s ACME organization.

Overview

Design


Table 8. ACME user profile

ACME profile characteristic Value

Number of users supported 5,000 users

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

Read/write ratio 3:2

Number of mailbox servers 2

Number of DAG copies 2

Mailbox size 2 GB

Table 9. ACME building block

ACME building block Value

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

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

User count per database 500

Database LUN size 2 TB

Log LUN size 100 GB

Disk size and type 2 TB 7.2k rpm SATA drives

RAID type and disks required RAID 1_0 (24 x 2 TB SATA drives)

Table 10 and Table 11 show the user profile and building block used in this solution’s OMZE organization.

Table 10. OMZE user profile

OMZE profile characteristic Value

Number of users supported 500 users

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

Read/write ratio 3:2

Number of mailbox servers 2

Number of DAG copies 2

Mailbox size 2 GB


30

Table 11. OMZE building block

OMZE building block Value

User count per server 500 (250 active users, 250 passive users)

Number of databases per server 2 (1 active, 1 passive)

User count per database 250

Database LUN size 1 TB

Log LUN size 50 GB

Disk size and type 2 TB 7.2k rpm SATA drives

RAID type and disks required RAID 1_0 (4 x 2 TB SATA drives)

In the ACME organization, the first client access server also acts as the file share witness. To remove single point of failure, the virtual machines of the two mailbox servers and the two client access and hub transport servers are hosted on different UCS blades.

The virtual machine and LUN configurations for the ACME organization are shown in Table 12 and Table 13.

Table 12. ACME virtual machine configuration

Virtual machine Quantity CPU RAM (GB)

Mailbox server 2 6 36

Hub/client access servers combination 2 4 16

Table 13. ACME LUN configuration

Virtual machine Role Quantity LUN size Storage pools

Mailbox server

Boot

Mount point

1

1

100

10 FC 450 GB RAID 5 4+1

Database

Log

10

10

2048

100 SATA 24 x 2 TB RAID 1_0

Hub/client access servers combination

Boot 1 100 FC 450 GB RAID 5 4+1

In the OMZE organization, the file share witness is configured on a domain controller. To remove single point of failure, the virtual machines of the two Exchange servers and this domain controller are also hosted on different UCS blades.

The virtual machine and LUN configurations for the OMZE organization are shown in Table 14 and Table 15.

Configuration


Table 14. OMZE virtual machine configuration

Virtual machine Quantity CPU RAM (GB)

Mailbox, hub, and client access servers combination

2 2 16

Table 15. OMZE LUN configuration

Virtual machine Role Quantity LUN size Storage pools

Mailbox, hub, and client access servers combination

Boot

Mount point

1

1

100

10

FC 450 GB RAID 5 4+1

Database

Log

2

2

1024

50

SATA 4 x 2 TB RAID 1_0

The Exchange 2010 storage design should be validated for expected transactional IOPS before it is placed in a production environment. To ensure that the environment functions appropriately, EMC recommends that the Microsoft Jetstress tool is used to validate the Exchange storage design.

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

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

The 64-bit version of Jetstress 2010 can be downloaded from: http://www.microsoft.com/download/en/details.aspx?id=4167

In this solution, Jetstress version 14.01.0225.017 was used to simulate an I/O profile of 0.15 IOPS per user. The building blocks were validated using a two-hour performance test. Table 16 and Table 17 show the average I/O and the average latency on the mailbox servers. As can be seen, the performance of both organizations meets the design target.

Jetstress validation

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


32

Table 16. ACME - average I/O and latency on mailbox servers

Database I/O Target values ACME mailbox server

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

375 396

I/O database reads/sec N/A 244

I/O database writes/sec N/A 152

I/O database reads average latency (ms)

< 20 ms 13

I/O database writes average latency (ms)

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

4

Transaction log I/O Target values ACME mailbox server

I/O log writes/sec N/A 137

I/O log writes average latency (ms) < 10 ms 1

Total I/O Target values ACME mailbox server

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

Table 17. OMZE - average I/O and latency on mailbox servers

Database I/O Target values OMZE mailbox server

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

38 99

I/O database reads/sec N/A 58

I/O database writes/sec N/A 41

I/O database reads average latency (ms)

< 20ms 14

I/O database writes average latency (ms)

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

3

Transaction log I/O Target values OMZE mailbox server

I/O log writes/sec N/A 37

I/O log writes average latency (ms) < 10ms 1

Total I/O Target values OMZE mailbox server

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


Microsoft SQL Server Both the ACME and OMZE organizations required a SQL Server back-end database, servicing a medium TPC-E-like OLTP workload with a certain set of requirements and service-level agreements (SLAs). The selected platform was SQL Server 2008 R2 Enterprise Edition.

The SQL Server instance in both organizations was designed for a given number of users, with the design based on SQL Server best practices to meet medium transaction per second requirements. Each organization used a single CLARiiON storage pool—instead of traditional RAID groups—for all LUNs, as storage pools enable the customer to introduce Fully Automated Storage Tiering (FAST) technology to the design at any stage and also to simplify the back-end storage design.

• For ACME, the customer requirement was 1 TB of RAID 1/0 storage capacity to support 400 host-based IOPS. Based on this figure, it was calculated that CLARiiON 600 GB FC disks in a RAID 1/0 8+8 configuration would meet this host-based IOPS demand.

• For OMZE, the customer requirement was 500 GB of RAID 1/0 storage capacity to support 800 host based IOPS. Based on this figure, it was calculated that a CLARiiON 600 GB with FC disks in a RAID 1/0 4+4 configuration would meet this host-based IOPS demand.

For more information about SQL Server best practices, refer to EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update—Applied Best Practices.

For Microsoft storage best practice guidelines, visit: http://technet.microsoft.com/en-us/library/cc966534.aspx

The ACME virtual machine was booted from a single RAID 5 4+1 group on 450 GB FC disks. The simulated client load was generated with the BenchCraft TPC-E toolkit, configured with a maximum transaction per user rate of 100 per second as a pacing factor and a user emulator engine of two users against the database.

The virtual machine specifications for the ACME organization are shown in Table 18 and the LUN configuration is shown in Table 19.



SQL Server 1 4 32

Overview

Design

Configuration

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


34


Virtual machine

Role Quantity Drive letter LUN sizes

Storage pools

SQL Server

Boot 1 C:\ 85 FC 450 GB RAID 5 4+1

Test database

Test database logs

SQL Internal

Temp database

Temp database logs

4

1

1

1

1

E:\, F:\, G:\ & H:\

L:\

I:\

J:\

K:\

250

100

10

100

40

FC 600 GB RAID 1_0 8+8

The OMZE SQL Server consisted of a single SQL instance servicing an OLTP (TPC-E like) database supporting 20,000 users. The load was generated with BenchCraft’s TPC-E toolkit configured with a maximum transaction per user rate of 200 transactions per second as a pacing factor, and a user emulator engine of six users against the database.

The virtual machine specifications for the OMZE organization are shown in Table 20 and the LUN configuration is shown in Table 21.



SQL Server 1 4 32


Virtual machine

Role Quantity Drive letter LUN sizes

Storage pools

SQL Server

Boot 1 C:\ 85 FC 450 GB RAID 5 4+1

Test database

Test database logs

SQL Internal

Temp database

Temp database logs

2

1

1

1

1

E:\ & F:\

L:\

I:\

J:\

K:\

200

40

10

40

20

FC 600 GB RAID 1_0 4+4

The SQL TPC-E database filegroup and associated data and log files were located on RDMs contained in a single CLARiiON pool. Storage pool usage enables the customer to introduce FAST technology to the design at any stage and also simplifies the back-end storage design.

Figure 10 shows how the database files were mounted on separate drive letters and filegroups were used to distribute the databases evenly across the drives, and therefore across the LUNs. This design methodology was applied to both organizations.


Figure 10. Allocation of the database filegroups


36

Microsoft SharePoint Server 2010 In this solution, the ACME organization’s SharePoint farm consisted of a SQL database server, an application server for central administration, six Web front-ends (WFEs), two crawl servers, and two query servers. For the OMZE organization, the SharePoint farm consisted of a SQL database server, an application server for central administration, two WFEs, and two crawl and query servers.

Both SharePoint farms were designed to support a specific number of users at a certain concurrency. They were designed with SharePoint best practices in mind, the only change being the use of SATA storage pools for SharePoint components that had lower IOPS needs. Storage pools were used instead of RAID groups for all LUNs.

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

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

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

The maximum user capacity is derived from the following formula:

# = seconds per hour / RPH / Concurrency% * RPS

Example: 3600 / 60 / 1% * 34.15 = 204,900

Example: 3600 / 60 / 10% * 34.15 = 20,490 (supported user capacity for 10 percent concurrency)

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

Table 22. Response times

Test type Action ACME % OMZE % Response time

Browse User browse 80 50 < 3 seconds

Search Unique value search

10 20 < 3 seconds

Modify Browse and metadata modify

10 30 < 3 seconds

Overview

Design

Test methodology


The ACME SharePoint farm consisted of 20 site collections with 10 sites each for a total of 200 sites. Each site contained 10 GB of documents for a total of 2 TB of documents for all sites combined.




SQL Server 1 8 16

WFE 6 4 8

Crawl 2 4 8

Query 2 4 8

Application 1 2 6


Virtual machine

Role Quantity LUN sizes

Storage pools

SQL Server

Boot 1 60 FC 450 GB RAID 5 4+1

ContentDBs

CDB Logs

SP Config

SQL Internal

10

1

1

1

250

250

100

10

SATA 2 TB RAID 5 8+1

TempDB Data

TempDB Log

SearchDB

SearchDB Log

2

2

1

1

200

20

350

35


WFE Boot 6 50 FC 450 GB RAID 5 4+1

Crawl Boot

Index

2

2

50

60



Query Boot

Query

2

2

50

100



Application Boot 1 50 FC 450 GB RAID 5 4+1

The OMZE SharePoint farm consisted of 10 site collections with 10 sites each for a total of 100 sites. Each site contained 10 GB of documents for a total of 1 TB of documents for all sites combined.


Configuration


38



SQL Server 1 8 16

WFE 2 4 6

Crawl/Query 2 4 8

Application 1 2 6


Virtual machine

Role Quantity LUN sizes

Storage pools

SQL Server

Boot 1 60 FC 450 GB RAID 5 4+1

ContentDBs

CDB Logs

SP Config

SQL Internal

5

1

1

1

250

125

100

10

SATA 2 TB RAID 5 4+1

TempDB Data

TempDB Log

SearchDB

SearchDB Log

2

2

1

1

200

20

350

35


WFE Boot 6 50 FC 450 GB RAID 5 4+1

Crawl/Query Boot

Index

2

2

50

100



Application Boot 1 50 FC 450 GB RAID 5 4+1


Combined testing

The goal of this test was to show all the applications for both organizations running under load. The load profiles are explained in each of the following application sections. The tests were run for all applications in both organizations at the same time. CPU load on the ESX servers (blades) averaged 30 percent during the test. All the tests were run for a minimum of eight hours concurrently to simulate a normal working day for both organizations.

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

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

LoadGen:

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

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

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

The 64-bit version of LoadGen 2010 can be downloaded from: http://www.microsoft.com/download/en/details.aspx?id=20322

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

• The action profile was 150 messages per mailbox per day

• Each mailbox was 2 GB in size

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

For additional information about monitoring Exchange 2010 performance and other key performance counters, visit: http://technet.microsoft.com/en-us/library/dd335215.aspx

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

Overview

Exchange 2010 Server

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

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


40

Table 27. LoadGen test profile

Test Description

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

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

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


Table 28. ACME – Exchange virtual machines

ACME

Performance counter

Target

Normal situation (2,500 users per server)

Server failure situation (5,000 users on single server)

Mailbox server

Processor\%Processor time <80% 19% 25%

MSExchange database\I/O database reads (attached) average latency <20 ms 6 9

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

<20 ms

<reads avg. 3 3

MSExchange database\I/O database reads (recovery) average latency <200 ms 7 0

MSExchange database\I/O database writes (recovery) average latency <200 ms 3 0

MSExchange database\IO log read average latency <20 ms 3 0

MSExchange database\IO log writes average latency <20 ms 5 1

MSExchangeReplication(*)\ReplayQueueLength <2 0 0

MSExchangeIS\RPC requests <70 1 2

MSExchangeIS\RPC averaged latency <10 ms 1 1

Client access/hub servers


MSExchange RpcClientAccess\RPC Requests <40 1 2

MSExchange RpcClientAccess\RPC Averaged Latency <250 ms 4 4

MSExchangeTransportQueues(_total)\Aggregate Delivery Queue Length (All Queues) <3,000 1 3

MSExchangeTransportQueues(_total)\Active Remote Delivery Queue Length <250 0 0

MSExchangeTransportQueues(_total)\Active Mailbox Delivery Queue Length <250 1 3


42

Table 29. OMZE – Exchange virtual machines

OMZE

Performance counter

Target

Normal situation (250 users per server)

Server failure situation (500 users on single server)

Mailbox/ client access/hub servers


MSExchange database\I/O database reads (attached) average latency <20 ms 12 8

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

<20 ms

<reads avg. 2 3

MSExchange database\I/O database reads (recovery) average latency <200 ms 7 0

MSExchange database\I/O database writes (recovery) average latency <200 ms 1 0

MSExchange database\IO log read average latency <20 ms 5 0

MSExchange database\IO log writes average latency <20 ms 4 1

MSExchange Replication(*)\ReplayQueueLength <2 0 0

MSExchangeIS\RPC requests <70 0 0

MSExchangeIS\RPC averaged latency <10 ms 1 1

MSExchange RpcClientAccess\RPC Requests <40 0 0

MSExchange RpcClientAccess\RPC Averaged Latency <250 ms 2 2

MSExchangeTransport Queues(_total)\Aggregate Delivery Queue Length (All Queues) <3,000 0 0

MSExchangeTransport Queues(_total)\Active Remote Delivery Queue Length <250 0 0

MSExchangeTransport Queues(_total)\Active Mailbox Delivery Queue Length <250 0 0


The Exchange IOPS for both customer environments are shown in Figure 11 and Figure 12.

Figure 11. ACME Exchange IOPS

Note Since this is a RAID 1/0 disk configuration, all the disks’ IOPS were the same so only a single disk is shown.

Figure 12. OMZE Exchange IOPS

In the ACME organization, the average IOPS per Exchange database is 38.54, and the average IOPS per disk is 33.30. In the OMZE organization, the average IOPS per

0

20

40

60

80

100

120

140

160

180

200

04:

01:5

6 0

4:15

:56

04:

29:5

6 0

4:43

:56

04:

57:5

6 0

5:11

:56

05:

25:5

6 0

5:39

:56

05:

53:5

6 0

6:07

:56

06:

21:5

6 0

6:35

:56

06:

49:5

6 0

7:03

:56

07:

17:5

6 0

7:31

:56

07:

45:5

6

Total Throughput (IO/s)

ACME Exch DB_1

ACME Exch DB_2

ACME Exch DB_3

ACME Exch DB_4

ACME Exch DB_5

ACME Exch DB_6

ACME Exch DB_7

ACME Exch DB_8

ACME Exch DB_9

ACME Exch DB_10

Bus 3 Enclosure 1 Disk 0

0

50

100

150

200

250

300

04:0

1:56

04

:15:

56

04:2

9:56

04

:43:

56

04:5

7:56

05

:11:

56

05:2

5:56

05

:39:

56

05:5

3:56

06

:07:

56

06:2

1:56

06

:35:

56

06:4

9:56

07

:03:

56

07:1

7:56

07

:31:

56

07:4

5:56




OMZE Exch DB 2

OMZE Exch DB 1


44

Exchange database is 20.08, and the average IOPS per disk is 9.97. The spikes in the graph are triggered by Forefront when its scanner threads are busy.

Performance The ACME SQL Server had an average disk read latency of 13 milliseconds (ms) and an average disk write latency of 18 ms for the TPC-E database LUNs, and a disk write latency of 1.4 ms for the log LUN. The ACME SQL Server returned 168 transactions per second.

The OMZE SQL Server had a disk read latency of 10 ms and a disk write latency of 5 ms for the TPC-E database LUNs, and a disk write latency of 1.4 ms for the log LUN. The ACME SQL Server returned 186 transactions per second.

Test results Figure 13 and Figure 14 show the average disk per second transfer rate (latency) for both customers respectively.

Figure 13. AMCE SQL Server - combined testing, read/write disk latency results

Figure 13 shows the average disk per second transfer rate (latency) for AMCE, which is below 20 ms. The write spikes, which can be seen at intervals of 450 seconds (7.5 minutes), are database checkpoints—that is, a database memory flush to disk.

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

03:5

7:10

04

:10:

40

04:2

4:10

04

:37:

40

04:5

1:10

05

:04:

40

05:1

8:10

05

:31:

40

05:4

5:10

05

:58:

40

06:1

2:10

06

:25:

40

06:3

9:10

06

:52:

40

07:0

6:10

07

:19:

40

07:3

3:10

07

:43:

10

07:5

0:40

ms

ACME Average Disk sec/Read and Write

Avg Disk Write

Avg Disk Read

SQL Server


Figure 14. OMZE SQL Server - combined testing, read/write disk latency results

Figure 14 shows the average disk per second transfer rate (latency) for OMZE, which is well below 20 ms. The write spikes, which can be seen at intervals of 450 seconds (7.5 minutes), are database checkpoints—that is, database memory flush to disk.

Figure 15 shows the SQL database LUN and disk utilization test results for ACME. The SQL Server design was defined by the storage pool configuration and the RAID 1/0 8+8 pool allowed for a low to medium load against a 75,000 user database.

Figure 15. ACME SQL DB IOPS (average 98.55 DB, 12.89 disk)

0

0.05

0.1

0.15

0.2

0.25

03:5

7:15

04

:11:

00

04:2

4:45

04

:38:

30

04:5

2:15

05

:06:

00

05:1

9:45

05

:33:

30

05:4

7:15

06

:01:

00

06:1

4:45

06

:28:

30

06:4

2:15

06

:56:

00

07:0

8:15

07

:22:

00

07:3

5:45

07

:49:

30

ms

OMZE Avg Disk sec/Read and Write

Avg Disk Write

Avg Disk sec/Read

0 20 40 60 80

100 120 140 160 180

04:0

1:56

04

:15:

56

04:2

9:56

04

:43:

56

04:5

7:56

05

:11:

56

05:2

5:56

05

:39:

56

05:5

3:56

06

:07:

56

06:2

1:56

06

:35:

56

06:4

9:56

07

:03:

56

07:1

7:56

07

:31:

56

07:4

5:56




ACME SQL OLTP DB 1

ACME SQL OLTP DB 2

ACME SQL OLTP DB 3

ACME SQL OLTP DB 4


46

Figure 16 shows the SQL database LUN and disk utilization test results for OMZE. The storage pool configuration of RAID 1/0 4+4 allowed for a high load against the 20,000 user database and, even though the IOPS were high, the disk latency at the host was still well below 20 ms.

Figure 16. OMZE SQL DB IOPS (average 415.8 DB, 87.32 disk)

Performance The ACME SharePoint farm averaged 28.64 passed tests per second. This is equivalent to 17,186 users at 10 percent concurrency. The load profile was 80 percent browse, 10 percent search and 10 percent modify. Browse averaged 2.30 seconds, search averaged 0.76 seconds, and modify averaged 1.51 seconds. The recommended Microsoft limit for common operations is three seconds and these times were well within that limit.

The OMZE SharePoint farm averaged 13.88 passed tests per second. This is equivalent to 8,327 users at 10 percent concurrency. The load profile was 50 percent browse, 20 percent search, and 30 percent modify. Browse averaged 1.30 seconds, search averaged 0.37 seconds, and modify averaged 2.04 seconds.

0

100

200

300

400

500

600

700

800

900

04:0

1:56

04

:15:

56

04:2

9:56

04

:43:

56

04:5

7:56

05

:11:

56

05:2

5:56

05

:39:

56

05:5

3:56

06

:07:

56

06:2

1:56

06

:35:

56

06:4

9:56

07

:03:

56

07:1

7:56

07

:31:

56

07:4

5:56


OMZE SQL OLTP DB 1

OMZE SQL OLTP DB 2



SharePoint Server


Test results Figure 17 shows the combined SharePoint passed tests per second rate for both customer environments.

Figure 17. Combined SharePoint passed tests/sec

Figure 18 and Figure 19 show the ContentDB utilization test results for both customer environments. ACME ContentDB LUNs averaged 27 percent utilization and the SATA II disk utilization averaged 42.59 percent. OMZE ContentDB LUNs averaged 58.58 percent utilization and the SATA II disk utilization averaged 64.06 percent. This shows that under a full load SATA II disks are capable of supporting the IOPS needed by SharePoint farm’s ContentDBs.

ACME was running an 80/10/10 load profile so had only 10 percent modifies, whereas OMZE was running a 50/20/30 load profile with 30 percent modifies. This meant that OMZE had more IOPS than ACME as can be seen in Figure 18 and Figure 19. OMZE’s SATA II disks were close to 95 percent utilized during testing.

The ACME average throughput per ContentDB was 40.58 IOPS with a total average of 405.80 IOPS. The ACME throughput averaged 84.88 per disk with a total average of 763.92.

The OMZE average throughput per ContentDB was 90.11 IOPS with a total average of 405.55 IOPS. The OMZE disk throughput averaged 138.37 per disk with a total average of 691.85.

0 10 20 30 40 50 60 70 80 90

100

02:3

0:15

02

:43:

00

02:5

8:45

03

:12:

15

03:2

6:45

03

:43:

15

03:5

7:15

04

:10:

15

04:2

2:30

04

:34:

45

04:4

7:30

04

:59:

45

05:1

3:30

05

:25:

45

05:3

8:45

05

:53:

00

06:0

7:15

06

:20:

15

Passed tests/sec

ACME Passed Tests/Sec

OMZE Passed Tests/Sec


48

Figure 18. ACME ContentDB Throughput (IOPS)

Figure 19. OMZE ContentDB Throughput (IOPS)

0

50

100

150

200

250

04:0

1:56

04

:15:

56

04:2

9:56

04

:43:

56

04:5

7:56

05

:11:

56

05:2

5:56

05

:39:

56

05:5

3:56

06

:07:

56

06:2

1:56

06

:35:

56

06:4

9:56

07

:03:

56

07:1

7:56

07

:31:

56

07:4

5:56


ACME SP CDB 1

ACME SP CDB 2

ACME SP CDB 3

ACME SP CDB 4

ACME SP CDB 5

ACME SP CDB 6

ACME SP CDB 7

ACME SP CDB 8

ACME SP CDB 9

ACME SP CDB 10

0

20

40

60

80

100

120

140

160

180

04:0

1:56

04

:15:

56

04:2

9:56

04

:43:

56

04:5

7:56

05

:11:

56

05:2

5:56

05

:39:

56

05:5

3:56

06

:07:

56

06:2

1:56

06

:35:

56

06:4

9:56

07

:03:

56

07:1

7:56

07

:31:

56

07:4

5:56


OMZE SP CDB 1

OMZE SP CDB 2

OMZE SP CDB 3

OMZE SP CDB 4

OMZE SP CDB 5



Failure testing

The objective of the hardware failure test was to validate the high availability level this solution provides when a blade fails or when a switch fails in Vblock 1.

The test scenario was designed to show the impact of hardware failures on the Vblock and the applications running on it.

Blade failure test scenario In the blade failure test scenario, the blade that hosted the Exchange Server 2010 mailbox virtual machine and a SharePoint Server 2010 WFE virtual machine in the ACME organization was unplugged. The Exchange 2010 DAG was expected to handle the failure of the Exchange 2010 mailbox server. VMware DRS affinity rules were set for the mailbox servers so that they would not move to another blade in the event of a blade failure. The SharePoint Server 2010 WFE server automatically moved to another blade as expected. All testing tools were running to generate the designed workload in both the ACME and OMZE organization.

Note For the purpose of this test, hypervisor-based high availability on the Exchange Server 2010 virtual machine was disabled. Technically, it is possible to combine an Exchange Server 2010 high availability solution (DAG) with hypervisor-based high availability. For more information, visit: http://technet.microsoft.com/en-us/library/aa996719.aspx

Switch failure test scenario In the switch failure test scenario, one of the Fabric Interconnect switches was rebooted to simulate a switch failure. This caused no impact on the applications as the Fabric Interconnects are redundant.

Blade failure test scenario Impact on Exchange As can be seen from Figure 20, the blade was unplugged at around 23:02 (4:02 GMT). The Exchange Server 2010 mailbox server failure was detected by the Exchange Server 2010 DAG and all affected mailbox database were activated on the other DAG member within 20 seconds. The failover process triggered the first CPU spike. After failover completed, the average CPU utilization increased because all databases were then on a single node.

The LoadGen clients, which simulated these affected mailboxes, automatically reconnected after the databases were activated, and so the simulation continued successfully. Other LoadGen clients were unaffected.

After waiting for an interval of 1.5 hours, the failed blade was recovered. At around 0:40 (5:40 GMT), DAG detected that the failed Exchange virtual machine came online. CPU utilization increased because DAG seeding started automatically. From the trace log, the replay queue length dropped to one (or less) in 21 minutes, which means the recovered node was almost synchronized with the active node. The LoadGen clients were unaffected during the whole process.

Overview

Design

Test results

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


50

The hardware failure in the ACME organization did not have a direct impact on the OMZE organization. The CPU utilization in the OMZE organization was at a consistent level all the time.

Figure 20. CPU utilization on OMZE and ACME

Impact on the SQL Server Since the SQL servers were not on the Cisco blade that was powered down during the blade failure testing, there was no impact on the SQL Server and no degradation of SQL performance.

Impact on the SharePoint Server As can be seen from the passed tests per second (passed tests/sec) shown in Figure 21, when the blade was pulled about two hours into the test, the passed tests drop for a few minutes and about three and a half hours into the test the blade insert causes a spike in passed tests. Switch failure is not graphed because there was no impact to SharePoint.


Figure 21. OMZE passed tests/sec

The ACME test was started about 10 minutes before the OMZE test. As Figure 22 illustrates, there was a drop in passed tests as the blade was pulled, and a spike when the blade was inserted.

Figure 22. ACME passed tests/sec (test started 10 minutes earlier than OMZE)

Switch failure test scenario After the switch was unplugged, all the Exchange servers and LoadGen clients continued successfully. None of the services and functions failed. The same applied to the SQL Server and SharePoint Server.


52

Replication Manager testing

The Replication Manager test was done under full load from all the applications in both organizations. The objective was to protect all the applications with Replication Manager snapshots and mount one of the snapshots to the mount host. This was achieved successfully

In this solution, CLARiiON SnapView snapshot technology was used for the Replication Manager replica. CLARiiON SnapView can create or remove a snapshot in seconds, regardless of the LUN size, because it does not copy all of the data, since it is a point-in-time copy. It significantly reduced the replication time when compared with CLARiiON SnapView clones.

For Exchange Server 2010, Replication Manager supports both the standalone servers and DAG. For the DAG copies used in this solution, Replication Manager can replicate data from native Exchange DAGs with both active and passive copies. The Replication Manager agent on the Exchange Server communicates with the Microsoft Exchange Information Store service and Exchange Volume Shadow Copy Service (VSS) writer to discover the mailbox database information and create application-consistent replicas using VSS.

For SharePoint Server 2010 and SQL Server, Replication Manager can protect the SQL Server databases by creating and managing application sets that contain either entire SQL Server databases or partial databases at the filegroup level. Specifically for the SharePoint integration with Replication Manager, the Replication Manager uses the following interfaces when replicating the SharePoint farm:

• Windows VSS Framework to obtain the SharePoint farm layout from the SharePoint VSS Writer when creating an application set. VSS coordinates the various components to create consistent point-in-time copies of data shadow copies.

• SQL Server Virtual Device Interface (VDI) to create the SQL Server database replicas in the SharePoint farm. Replication Manager prepares the target storage for replication by synchronizing the production with the target storage, and then uses VDI to freeze the database I/O. After the target storage is split from the production, VDI is used again to thaw the I/Os.

Replication Manager Agent software was installed on each host that participated in the replication process, including hosts that managed production data and hosts that were used to mount replicas. It enabled the integration of Replication Manager Agents with applications such as Exchange Server 2010, SQL Server, and SharePoint Server 2010, which were used in this solution.

Replication Manager protection for both organizations required a point-in-time copy to be taken every hour for each application. To satisfy this requirement, a schedule was set up for the jobs that staggered them over each hour. Instead of starting a job just after another completed, a fixed schedule was used because the jobs completed successfully even though they overlapped. In this way, it was possible to know exactly when each application snapshot was starting.

Overview

Design

Configuration


To configure CLARiiON SnapView snapshots, a reserved LUN pool with the proper number and size of LUNs (also known as a snapshot cache) should be allocated for the snapshot function. In this solution, all three applications in the two organizations used a snapshot pool consisting of 98* 43 GB LUNs on two RAID 5 4+1 groups. To ensure minimum disruption to the production environment during snapshot operations, FC 600 GB disks were used for the reserved LUN pool.

The EMC Replication Manager Product Guide provides detailed configuration information for these application integrations.

With Replication Manager 5.3.2, a virtual machine can act as a mount host for the CLARiiON system. In this solution, a static mount was used, with which replication LUNs were manually placed into the ESX storage group. The LUNs were then made visible to the virtual machine as RDM devices before replication began. Before running Replication Manager, it was necessary to manually expose the snapshot LUNs to the mount host. During the replication, Replication Manager temporarily created a snapshot. When Replication Manager got to the mount phase, it detected the pre-exposed snapshot LUNs to continue the job.

For information on pre-exposing LUNs to the mount host, refer to the EMC Replication Manager Administration Guide.

Replication Manager cannot work with a NAT host because it requires a connection to the real host’s IP address. This is because Replication Manager connects to the host using the external NAT address and then requests the host’s real IP address. Since these do not match in a NAT environment, Replication Manager does not recognize the IP address and rejects the server. For this reason, the Replication Manager servers were installed in the Infrastructure vApps, which are internal to both organizations.

Note EMC recommends that you stagger the Replication Manager jobs to ensure successful completion.

For Replication Manger to replicate the Exchange Server mailbox database, the following settings should be preconfigured:

• Configure hosts and permissions

• Configure PowerShell authentication method

• Disable circular logging

Refer to the EMC Replication Manager Product Guide for configuration information.

In both the ACME and OMZE organizations, Replication Manager was configured to back up the passive database copies to reduce the performance impact on user access, as shown in Figure 23.


54

Figure 23. Replicate the Exchange Server 2010 passive database

For SharePoint Server 2010, the Windows SharePoint Services VSS writer was enabled on the application-server in the SharePoint farm as follows:

%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\bin\ stsadm.exe -o registerwsswriter

This made it easy to check and replicate the full farm from the application server where the SharePoint Integration Replication Manager Agent was installed, as shown in Figure 24.


Figure 24. Replicate the SharePoint farm database

For the SQL Server in this solution, the Replication Manager SQL agent was installed on the production server and Replication Manager jobs were created with administrative privilege account granted, as shown in Figure 25.


56

Figure 25. Replicate the SQL Server database

The Replication Manager jobs were scheduled to run every hour according to the schedule shown in Table 30.

Table 30. Replication Manager jobs schedule

Organization Time (minutes) Application

ACME

00 Exchange 1

15 Exchange 2

30 SQL

45 SharePoint

OMZE

10 Exchange 1

25 Exchange 2

40 SQL

55 SharePoint

Figure 26 shows the Replication Manager snapshot LUNs (four of 98) and RAID 5 FC 600 disk utilization. The time was GMT. As illustrated, the snapshot LUN spikes as the Replication Manager jobs were run. Consequently, the snapshot disks were busy as data is changed by the full application load.

Test results


Figure 26. Replication Manager snapshot LUNs and RAID 5 FC600 disk utilization

Figure 27 shows the passed tests per second for ACME and OMZE. Because the ContentDBs were on SATA II disks, the impact of the Replication Manager snapshots is quite significant. ACME performance improved marginally, while OMZE performance degraded by 28.88 percent. The OMZE disks were much busier because of the high percentage of data modifications and therefore were more susceptible to impact from the Replication Manager snapshots. This test was done on RAID 5 SATA II storage pools so, to minimize the impact, EMC recommends at least RAID 1/0 SATA II storage pools to deal with the additional IOPS from snapshots.

OMZE modify average test times increased to 3.87 seconds because of the overhead. This is caused by high disk latency because the disks cannot process all the IOPS being sent to them in a timely manner.

0

20

40

60

80

100

120

140

160

180

09:0

6:08

09:2

0:22

09:3

4:14

09:4

7:39

09:5

7:26

10:0

1:26

10:1

1:09

10:1

8:56

10:3

0:51

10:4

4:04

10:5

7:17




LUN 4056 [4056; RAID 5]

LUN 4055 [4055; RAID 5]

LUN 4006 [4006; RAID 5]

LUN 4012 [4012; RAID 5]


58

Figure 27. SharePoint impact of snapshots

Table 31 and Table 32 show the test results for both organizations.

Table 31. ACME test result impact - SharePoint

Browse Search Modify Passed tests/sec Number of users

Combined testing 2.30 0.76 1.51 28.64 17,184

Combined testing with Replication Manager snapshots

2.13 0.76 1.95 30.33 18,198

Table 32. OMZE test result impact - SharePoint

Browse Search Modify Passed tests/sec Number of users

Combined testing 1.30 0.37 2.04 13.88 8,328


1.17 0.34 3.87 10.77 6,462

Both the ACME and OMZE SQL servers experienced marginal impact while the Replication Manager snapshots were running, as illustrated in Table 33 and Table 34.

0 10 20 30 40 50 60 70 80 90

100

02:0

0:15

02

:13:

00

02:2

6:15

02

:40:

30

02:5

2:45

03

:05:

30

03:1

9:45

03

:33:

15

03:4

7:45

04

:00:

45

04:1

4:15

04

:27:

30

04:4

0:45

04

:53:

15

05:0

7:00

05

:20:

15

05:3

4:00

05

:49:

15

Passed test/sec

ACME Passed Tests/Sec

OMZE Passed Tests/Sec


Table 33. ACME test result impact - SQL

Avg. Disk sec/Read - db

Avg. Disk sec/Write - db

Avg. Disk sec/Write - log

TPS

Combined testing 13 ms 18 ms 1.4 ms 168


14.6 ms 20 ms 2.1 ms 161

Table 34. OMZE test result impact - SQL

Avg. Disk sec/Read - db

Avg. Disk sec/Write - db

Avg. Disk sec/Write - log

TPS

Combined testing 9.75 ms 5,34 ms 1.6 ms 186


10.3 ms 9.17 ms 2.4 ms 153

Figure 28 shows the average disk per second read and write for both ACME and OMZE while Replication Manager is running.

Figure 28. Average disk per second/Read and Write with Replication Manager running

0 0.05

0.1 0.15

0.2 0.25

0.3 0.35

0.4 0.45

0.5

06:

00:0

0 0

6:08

:30

06:

15:0

0 0

6:20

:00

06:

26:4

5 0

6:35

:15

06:

43:4

5 0

6:52

:15

07:

00:4

5 0

7:09

:15

07:

17:4

5 0

7:26

:15

07:

34:4

5 0

7:43

:15

07:

51:4

5

ms

ACME and OMZE Avg. Disk sec/Read and Write

ACME Avg. Disk sec/Write

ACME Avg. Disk sec/Read

OMZE Avg. Disk sec/Write

OMZEAvg. Disk sec/Read


60

vCenter Chargeback

Service providers and IT departments need to be able to cost and charge for the services they provide. The vCenter Chargeback feature enables them to do this by using several different chargeback methods. This simplifies and automates the collection of usage data with granularity down to the virtual machine level. Reports can then be generated historically for a defined period of time—down to a single day, if necessary.

vCenter Chargeback enables service providers or IT departments to easily and accurately retrieve cost and charge information automatically and generate historical reports as necessary.

A vCenter Chargeback server was provisioned as a 4 vCPU, 4 GB RAM virtual machine with 200 GB of disk space. SQL Server 2008 R2 was installed to host the vCenter Chargeback database.

vCenter Chargeback was installed as detailed in the vCenter Chargeback User’s Guide and the application was accessed though a web interface. After starting the chargeback services, the VMware vCloud Director and vShield Manager Data Collectors were installed. After the various data collectors’ services started, the two vCenter Server databases, from which vCenter Chargeback draws information to generate usage against, were attached.

• For ACME, the objective was to generate a cost report to indicate utilization-based costing per virtual machine, based on the actual resources used.

• For OMZE, the objective was to generate a cost report to indicate cost, based on the allocation of resource.

After the AMCE and OMZE organizations’ virtual infrastructures were imported into vCenter Chargeback (against which cost reporting was generated), the Base Rate Calculator was run to define the fixed costs to be recovered over a user-specified time, as shown in Figure 29.

Overview

Configuration

Test results


Figure 29. Base Rate Calculator

The Base Rate Calculator, as illustrated in Figure 30, is used to specify costs within a hierarchy that is part of a Vblock, for example. Hardware and software costs are entered and a cost recovery term is specified. The calculator works out a base rate for these various entities in the hierarchy. This base rate is then used to calculate actual recovery costs within a selected cost model.


62

Figure 30. Cost model

After running the Base Rate Calculator, the values generated can be populated into the cost model templates for use. A cost model is then selected and the base rate values that were generated are reflected, and various other base rates can be defined in the cost model against which costing is based. These rates can be configured to charge hourly, daily, monthly, or yearly.

For ACME, the cost model selected was VMware Cloud Director Pay As You Go – Resource Based Charging Cost Model and the billing policy was defined as fixed cost and actual usage. For OMZE the cost model selected was Fixed Cost and Allocation.

The Resource Based Charging Cost Model calculates cost based on the actual usage of the virtual machines. For example, if four CPUs are allocated to a virtual machine but only 20 percent of those CPUs are actually used, then the cost is based on the 20 percent only.


The Fixed Cost and Allocation cost model is based on the allocation of resources. For example, if four CPUs are allocated to a virtual machine then the cost is based on four CPUs, regardless of the actual usage.

It is also possible to apply rate factors to each base rate. The rate factor is the difference between the actual cost and the amount to be charged to the customer. Therefore, a rate factor of 1.1 means that the charge is 10 percent more than the actual cost (base rate).

Figure 31 shows the broad range of billing policies available that organizations can tailor to various billing scenarios.

Figure 31. Cost model – billing policies

Once the cost models are defined, cost reports can be generated manually or according to a schedule.

After the cost models were defined for ACME and OMZE, reports were generated for the month of the test run. The reports generated for ACME and OMZE are illustrated. Figure 32 shows the utilization cost for ACME based on Fixed Cost and Actual Usage with the Exchange vApp expanded. In the Fixed Cost column there is a charge of $54.99. This was a fixed cost that was defined for high availability for each virtual machine.


64

Figure 32. Utilization cost for ACME with Exchange vApp expanded

Figure 33 shows the AMCE SharePoint virtual machines’ costs, based on fixed cost and actual usage. Note that there are costs against the reservation pool. This is because the report generation was run against the whole ACME organization at a high level.


Figure 33. ACME cost report

Figure 34 shows the cost report generated for OMZE against a defined cost model: Fixed Cost and Allocation. As can be seen, the granularity for costing extends all the way down to the individual virtual machines.


66

Figure 34. OMZE allocation cost


Conclusion

The solution presented in this white paper can help service providers or IT departments to segregate confidential or sensitive information, without the need for separate physical infrastructures or implementations. This solution uses Vblock 1 powered by the Intel Xeon processor to consolidate Tier 1 Microsoft applications and vCloud Director with vCenter Chargeback to enable a chargeback model for a multi-tenant environment.

This white paper shows how a working configuration for multi-tenancy can be designed and built. Combined testing of all applications, run concurrently in both organizations over eight hours, verified the solution design and showed good performance levels for all the applications. Failure testing demonstrated the minimal impact of blade and switch failures on the application performance and the failover capabilities of the Vblock and Exchange DAG. Replication Manager testing illustrated how all the organization’s applications were protected using CLARiiON SnapView snapshots, and the impact of an hourly schedule of snapshots on the applications.

In this solution, vCenter Chargeback showed how a service provider can use cost models to calculate the running cost of the hardware, software, and other fixed costs and use this as a basis for charging customers. The results of an allocation-based model and a resource-usage model were provided as examples of how this can be achieved.

Table 35 summarizes the objectives of this solution and the results achieved.

Table 35. Objectives and results

Objective Result

Create a reference architecture for Tier 1 Microsoft applications on Vblock1 in a multi-tenant environment

Demonstrated good performance levels during combined testing of a two-customer (medium and large) Microsoft application workload:

• The Exchange Server mailbox count was 5,000 building blocks for ACME and 500 building blocks for OMZE at 0.15 IOPS per mailbox

• The SharePoint Server total user count was 7,000 for OMZE and 16,000 for ACME

• The TPC-E user count for SQL Server was 20,000 users for OMZE and 75,000 users for ACME

Show a management interface for emerging cloud data centers

Showed that vCloud Director is an easy to use, simple cloud management interface that service providers, IT departments, and their customers can use in a multi-tenancy environment. Customers can easily provision their own virtual machines in 10 minutes.

Provide sizing guidance and validation to determine the appropriate building block and sizing

Provided sizing and performance for medium and large Exchange, SharePoint, and SQL virtual environments, as shown in Table 5 and the test results detailed in the Combined testing section.

Summary

Findings


68

Objective Result

Define planning and guidance best practices for local HA for all Tier 1 Microsoft applications (Exchange, SharePoint, SQL servers)

Minimal impact and no downtime was experienced during Vblock hardware failure simulation due to the Vblock design, VMware HA, and the Microsoft Exchange DAG.

Demonstrate the chargeback functionality provided by vCenter Chargeback

In the vCenter Chargeback section, presented the results from the two following cost models:

• Allocation-based costing–costs per virtual machine based on CPU, RAM, and storage allocated, as well as fixed costs such as HA.

• Utilization-based costing–variable costs per virtual machine based on the actual resources used, as well as fixed costs such as HA.

Measure the impact and usability of protecting the environment using array-based replication managed by Replication Manager for all three applications

Used Replication Manager to protect all three applications within the two organizations. In the Replication Manager testing section, showed:

• That the impact of snapshots on these applications was negligible.

• The I/O impact was marginal except for the medium SharePoint farm (due to the configuration of the SAT A disks).

• A working schedule for Replication Manager.

Demonstrate the management and monitoring of Microsoft applications using SCOM

Showed how SCOM monitored Microsoft applications in this solution environment with no impact on performance.

Demonstrate the security and protection of SharePoint and Exchange environments against virus, malware, and spam using Forefront Server Security

Showed how Forefront protected Microsoft applications in this solution environment with minimal impact on performance.

Demonstrate the performance of SharePoint farms on SATA II RAID 5 4+1 groups

Both medium (7,000 user) and large (16, 000 user) farms performed well on SATA disks. Refer to the SharePoint Server Test results in the Combined testing section. The impact of Replication Manager snapshots on the medium farm was significant and EMC recommends using RAID 1/0 SATA for this.


References

For additional information, see the EMC white papers listed below.

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

• EMC Virtual Infrastructure for Microsoft SharePoint Server 2010 Enabled by EMC CLARiiON and VMware vSphere 4—A Detailed Review

For additional information, see the EMC product documents listed below.

• EMC Ionix Unified Infrastructure Manager Installation Guide

• EMC Replication Manager Administration Guide

• EMC Replication Manager Product Guide

• EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update—Applied Best Practices

For additional information, see the documents listed below.

• vCenter Chargeback User’s Guide

• Cisco UCS 6100 Series Fabric Interconnect Hardware Installation Guide

White papers

Product documentation

Other documentation

VIRTUALIZING MICROSOFT APPLICATIONS IN A … Vblock 1 ... • Application protection using Microsoft...

Documents

Transcript of VIRTUALIZING MICROSOFT APPLICATIONS IN A … Vblock 1 ... • Application protection using Microsoft...