enhancing the performance and protection of microsoft sql ...enhancing the performance and...

White Paper

EMC Solutions

Abstract

This white paper demonstrates how storage performance for Microsoft SQL Server can be significantly improved at low capital and operational cost on EMC® next-generation VNX® series storage arrays. It also describes how EMC AppSync™ with VNX Snapshots provides enterprise-grade protection for critical SQL Server databases with negligible performance impact to the busy OLTP workloads and enables rapid, orchestrated recovery of the databases.

December 2013

ENHANCING THE PERFORMANCE AND PROTECTION OF MICROSOFT SQL SERVER 2012 EMC Next-Generation VNX, EMC FAST Suite, EMC AppSync, EMC PowerPath/VE, VMware vSphere

• Boosting OLTP performance

• Optimizing storage efficiency

• Enabling fast recovery

Enhancing the Performance and Protection of Microsoft SQL Server 2012 EMC Next-Generation VNX, EMC FAST Suite, EMC AppSync, EMC PowerPath/VE,

VMware vSphere

2

Copyright © 2013 EMC Corporation. All Rights Reserved.

Published December 2013

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

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

EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.

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

Part Number H12003

3 Enhancing the Performance and Protection of Microsoft SQL Server 2012 EMC Next-Generation VNX, EMC FAST Suite, EMC AppSync, EMC PowerPath/VE,

VMware vSphere

Table of contents

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

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

Solution overview ............................................................................................................................ 7

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

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

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

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

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

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

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

Overview ........................................................................................................................................ 11

EMC next-generation VNX ............................................................................................................... 11

Multicore architecture ............................................................................................................... 11

Flash-optimized hybrid array ..................................................................................................... 12

Active/active array service processors ....................................................................................... 12

Unisphere Management Suite ................................................................................................... 13

EMC FAST Suite .............................................................................................................................. 13 EMC FAST VP ............................................................................................................................. 13

EMC FAST Cache ........................................................................................................................ 13

EMC AppSync ................................................................................................................................. 14

EMC PowerPath/VE ........................................................................................................................ 15

VMware vSphere 5.1 ...................................................................................................................... 16

Solution architecture and configuration ............................................................................................. 17

Overview ........................................................................................................................................ 17 Solution architecture...................................................................................................................... 17

Hardware resources ....................................................................................................................... 18

Software resources ........................................................................................................................ 18

Workload profile ............................................................................................................................ 19

Storage considerations .................................................................................................................. 19

Balancing storage processors .................................................................................................... 19

Balancing cores on storage processor ....................................................................................... 20

Balancing back-end ports .......................................................................................................... 20

SP cache settings ...................................................................................................................... 21 Cache size configuration ............................................................................................................ 21 Flushing ..................................................................................................................................... 21 SP cache page size ..................................................................................................................... 22


VMware vSphere

4

Thin provisioning ....................................................................................................................... 22

Hot spare settings ..................................................................................................................... 22

Balancing data through FAST VP ................................................................................................ 23

Balancing data through FAST Cache .......................................................................................... 23

Storage design ............................................................................................................................... 23

Disk layout ................................................................................................................................ 24

Storage pool configuration ........................................................................................................ 25

FAST VP design .......................................................................................................................... 25

FAST Cache design .................................................................................................................... 26

Data protection ......................................................................................................................... 26

VMware configuration .................................................................................................................... 26

Virtual machine configuration ................................................................................................... 26

Memory settings ........................................................................................................................ 29

Application design and configuration ............................................................................................. 30

SQL Server 2012 design and configuration ................................................................................ 30 Design and requirements ........................................................................................................... 30 LUN configuration ....................................................................................................................... 31

AppSync design and configuration ............................................................................................ 32 Adding storage ........................................................................................................................... 33 Adding VMware vCenter Server ................................................................................................... 33 Adding host ................................................................................................................................ 35 Discovering SQL Server instances and databases ....................................................................... 35 Creating service plan .................................................................................................................. 36 Subscribing a database to the plan ............................................................................................ 39

Validation ........................................................................................................................................... 40

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

Test objectives ............................................................................................................................... 40

Notes ........................................................................................................................................ 40

Testing methodology ...................................................................................................................... 40

Test scenarios ................................................................................................................................ 40

Performance test procedures ......................................................................................................... 41

Test results .................................................................................................................................... 41

Throughput testing .................................................................................................................... 41 Throughput in IOPS and TPS ....................................................................................................... 42 Host latency ............................................................................................................................... 43 Physical disk utilization .............................................................................................................. 44 Storage processor utilization ...................................................................................................... 45

Protection testing ...................................................................................................................... 46 Performance testing with snapshots ........................................................................................... 46 Restore testing ........................................................................................................................... 47


VMware vSphere

Conclusion ......................................................................................................................................... 49

Summary ....................................................................................................................................... 49

Findings ......................................................................................................................................... 49

References.......................................................................................................................................... 50

White papers ................................................................................................................................. 50

Product documentation .................................................................................................................. 50

Other resources ............................................................................................................................. 50

Appendix: Hot spare policy ................................................................................................................. 51


VMware vSphere

6

Executive summary

Never before has access to mission-critical data been more important to businesses competing in a rapidly changing global economy. Today, IT departments are challenged with an explosion of corporate data along with stagnant or shrinking budgets, fewer resources, and less infrastructure.

As the foundation of the cloud-ready information platform, Microsoft SQL Server 2012 provides high availability, breakthrough insight, credible and consistent data, and a productive development experience to customers. It can also quickly build solutions and extend data across on-premises and public clouds backed by mission-critical confidence.

EMC provides a set of unique and powerful storage and data management features optimized for SQL Server. Designed to work with the EMC® next-generation VNX® series of storage platforms, these advanced features dramatically improve efficiency by simplifying and automating many storage tasks.

Enabled with EMC MCx™ software, the new VNX storage arrays are designed to address the high-performance, low-latency requirements of virtualized applications and database systems such as SQL Server, which is the most common use case for midrange solutions. MCx software takes full advantage of the latest Intel multicore processing technology to optimize flash by distributing all VNX data services across all cores. This is a new approach for midrange arrays—enabling the next-generation VNX to deliver the performance of the earlier generation at only one-third of the price.

Data protection is among the most important aspects of managing SQL Server environments. Database administrators (DBAs) and storage administrators need a rapid, simple, and lower-cost process for protecting mission-critical SQL Server instances. Given those needs, more businesses are looking for advanced data protection technologies for SQL Server 2012 environments. EMC AppSync™ offers simple, service-level agreement (SLA)-driven, self-service protection for mission-critical SQL Server databases and VMware datastores on block and file storage on VNX series systems.

This solution provides a detailed SQL Server storage, compute, and protection design that addresses all the previously described challenges by using the following software suites:

• EMC Fully Automated Storage Tiering (FAST™) Suite—Automatic storage optimization for the highest OLTP performance and the lowest storage cost simultaneously

• EMC Application Protection Suite—SQL Server integrated data protection and repurposing

Business case


VMware vSphere

This solution demonstrates EMC’s latest supporting infrastructure for SQL Server 2012 with Windows Server 2012 and VMware ESXi on an efficient, scalable VNX storage platform using block connectivity. The solution shows simulated online transaction processing (OLTP) workloads with excellent storage performance characteristics, optimized with the latest EMC FAST Cache, EMC FAST for Virtual Pools (FAST VP), and Snapshot technologies within the VNX array.

This solution demonstrates the ability of a modestly configured EMC VNX5800™, as an example of a storage array within the next-generation VNX series, to support multiple OLTP workloads exceeding 50,000 inputs/outputs per second (IOPS) at low cost. The solution combines a pool of serial-attached SCSI (SAS) drives and a small number of flash drives into one powerful storage pool capable of reacting to dynamic workloads. It also shows the benefits of adding additional flash drives to the environment and enabling FAST Cache to further boost performance.

This solution also demonstrates the enhanced snapshot protection for SQL Server OLTP databases provided by AppSync and VNX Snapshots technology. It demonstrates that VNX Snapshots has minimal performance impact on the running SQL Server OLTP workload and provides for rapid recovery. In addition, the solution illustrates the functionality of AppSync data protection software, including its ease of deployment and self-service capabilities.

The key results of this solution are:

• The next-generation VNX series of storage arrays can easily service SQL Server OLTP workloads, even with significant performance demands, by maximizing the efficiency and effectiveness of EMC flash technology. In this solution, a midrange VNX series system, VNX5800, was used.

• The combination of FAST VP and FAST Cache allows VNX storage arrays to maxmize storage efficiency and service increased I/O. This solution shows a four times improvement in the ability to service I/O from the baseline of 13,148 IOPS to 52,303 IOPS, and the latency dropped from more than 20 ms to less than 8 ms with FAST Suite enabled.

• Thin LUNs provide good performance within a FAST VP enabled storage pool.

• AppSync with VNX Snapshots provides simple, fast, and self-service application protection with minimal impact to the running SQL Server OLTP workload.

• AppSync provides enabled, rapid data recovery. The AppSync server restores a 1 TB SQL Server database LUN in 8 minutes 37 seconds.

Figure 1 shows the key findings of this solution.

Solution overview

Key results


VMware vSphere

8

Figure 1. Key findings of this solution

Table 1 lists the time taken to restore the VNX Snapshots of a 1 TB SQL Server OLTP database LUN.

Table 1. Restore testing results

Item Recovery time Data changes (GB)

Snap 1 8 min 37 sec 55



Snap 4 6 min 48 sec 13.5


VMware vSphere

Introduction

This white paper showcases the ability of the VNX5800 storage array to easily support more than 50,000 Microsoft SQL Server OLTP IOPS at low cost by using a combination of SAS and a small number of flash drives. FAST VP and FAST Cache technologies provide significant performance improvement for Microsoft SQL Server in an automated, nondisruptive fashion.

This white paper also describes the ease of configuration of AppSync server and VNX Snapshots and their functionality to provide protection for Microsoft SQL Server instances.

The solution described in this white paper validates the minimal performance impact of VNX Snapshots on the running SQL Server OLTP workload and measures the recovery time from the snapshots.

The scope of this solution is to:

• Demonstrate the ability of the VNX5800 to easily service over 50,000 IOPS for multiple SQL Server instances at low cost

• Demonstrate the good performance of thin LUNs within a FAST VP enabled storage pool

• Demonstrate the function and configuration of AppSync with VNX Snapshots

• Measure the performance impact of VNX Snapshots on a running SQL Server OLTP workload

• Measure the recovery time from the snapshots for the SQL Server application

This white paper is intended for EMC employees, partners, and customers, including IT planners, storage architects, application administrators, and EMC field personnel who are tasked with deploying such a solution in a customer environment. It is assumed that the reader is familiar with the various components of the solution.

Table 2 defines terminology used in this white paper.

Table 2. Terminology

Term Definition

IOPS Input/output per second; a measure of disk performance in terms of I/O command-processing throughput per second

iSCSI Internet small computer system interface; an IP-based storage networking standard for linking data storage facilities

LUN Logical unit number; an identifier used to describe and identify logical storage objects of a storage subsystem

Purpose

Scope

Audience

Terminology


VMware vSphere

10

Term Definition

MCx EMC multicore optimized architecture that fully utilizes all available cores and includes three primary components: Multicore Cache, Multicore FAST Cache, and Multicore RAID

Memory balloon A memory reclamation technique in VMware

OLTP Online transaction processing (such as a workload from a trading or banking application)

RPO Recovery point objective; the maximum tolerable period in which data might be lost from an IT service due to a major incident

RTO Recovery time objective; the period of time within which systems, applications, or functions must be recovered after an outage; the amount of downtime that a business can endure

Skew A small percentage of overall capacity responsible for most I/O activities

SLIC Small I/O cards, also known as UltraFlex I/O modules

TLB Transaction look-aside buffer; a cache that memory management hardware uses to improve virtual address translation speed

TPS Transactions per second

VDM Virtual Data Mover

VMDK Virtual Machine Disk

Working set The percentage of the total utilized capacity that is responsible for most of the I/O activity

http://en.wikipedia.org/wiki/Cache_(computing)

http://en.wikipedia.org/wiki/Memory_management_unit

http://en.wikipedia.org/wiki/Memory_management_unit

http://en.wikipedia.org/wiki/Virtual_address_space


VMware vSphere

Technology overview

The following components are used in this solution:

• EMC next-generation VNX

• EMC FAST Suite

• EMC AppSync

• EMC PowerPath®/VE

• VMware vSphere 5.1

The EMC VNX series of storage systems is optimized for virtual applications and delivers innovation and enterprise capabilities for file, block, and object storage. The next-generation VNX series arrays include many features and enhancements built upon the first generation’s success including:

• More capacity with multicore optimization with MCx

• Greater efficiency with a flash-optimized hybrid array

• Better protection by increasing application availability with active/active

• Easier administration and deployment by increasing productivity with EMC Unisphere® Management Suite

The next-generation VNX is architected to deliver greater efficiency, performance, and scale than ever before.

Multicore architecture

The VNX architecture unleashes the power of MCx technology, as shown in Figure 2. The system is optimized to distribute all services such as RAID, I/O, FAST Cache, data, and management evenly across the cores in a uniform manner, delivering up to four times more performance than that of its predecessor.

Figure 2. MCx improves resource use across CPU cores

This multicore design means that VNX delivers FLASH 1st at scale, with more capacity, using the latest Intel multicore technology, along with the software to take advantage of the increased power. In addition to providing improved block performance, the VNX series with MCx has improved the file performance for transactional

Overview

EMC next-generation VNX


VMware vSphere

12

applications. It delivers three times the IOPs with less read and write latency to critical business applications in virtualization environments.

Flash-optimized hybrid array

The next-generation VNX is a flash-optimized hybrid array that provides automated tiering to deliver the utmost performance to the data that requires it the most while intelligently moving less frequently accessed data to lower-cost disks.

In this hybrid approach, a tiny percentage of flash drives in the overall system can provide a high percentage of the overall IOPS. The flash-optimized VNX takes full advantage of the low latency of flash and delivers progressively lower cost with performance at scale. The FAST Cache and FAST VP tiers both block and file data across heterogeneous drives and boost the most active data to cache, ensuring that customers never have to make concessions for cost or performance.

FAST Cache dynamically absorbs unpredicted spikes in system workloads. As that data ages and becomes less active over time, FAST VP automatically tiers the data from high-performance to high-capacity drives based on customer-defined policies. This functionality has been enhanced with four times better granularity and with FAST VP solid-state drives (SSDs) based on enterprise multilevel cell (MLC) technology to lower the cost per gigabyte.

Active/active array service processors

The VNX architecture provides active/active array service processors. As shown in Figure 3, active/active processors eliminate the application time-outs during path failover because both paths are actively serving I/O.

Figure 3. Active/active processors increase performance, resiliency, and efficiency

Load balancing is also improved and applications can achieve up to two times improvement in performance. Active/active for block is ideal for applications that require the highest levels of availability and performance but do not require tiering or efficiency services like compression, deduplication, or snapshot.

With this VNX release, EMC customers can use Virtual Data Movers (VDMs) and VNX Replicator to perform automated and high-speed file system migrations between


VMware vSphere

systems. This process migrates all snaps and settings automatically and allows the clients to continue operation during the migration.

Unisphere Management Suite

The next-generation VNX is delivered with Unisphere Management Suite, shown in Figure 4. Unisphere’s easy-to-use interface provides a task-based integrated management experience for VNX to manage, report, and monitor the storage. It offers greater insight into the utilization and workload patterns, enabling you to diagnose issues, and forecast and plan for future capacity needs.

Figure 4. Unisphere Management Suite

EMC FAST Suite is an advanced software feature providing greater flexibility to manage the increased performance and capacity requirements of the SQL Server environment. FAST Suite makes use of SSDs, SAS, and near-line SAS (NL-SAS) storage configuration to balance performance and storage needs. FAST Suite includes FAST VP and FAST Cache.

EMC FAST VP

FAST VP allows data to be automatically tiered in pools made up of more than one drive type. The separate tiers are each provisioned with a different type of drive.

FAST VP algorithmically promotes and demotes user data between the tiers based on how frequently the data is accessed. More frequently accessed data is moved to higher performance tiers. Infrequently accessed data is moved to modestly performing high-capacity tiers as needed. Over time, the most frequently accessed data resides on the fastest storage devices, and infrequently accessed data resides on economical and modestly performing bulk storage.

EMC FAST Cache

The VNX series supports an optional performance-enhancing feature called FAST Cache. FAST Cache increases the storage system cache by extending the functionality of DRAM cache, mapping frequently accessed data to SSDs. If the user application frequently accesses a particular chunk of data (64 KB), that chunk is automatically promoted into the FAST Cache by being copied from HDDs to flash drives. Subsequent access to the same chunk is serviced at flash-drive response time, boosting the performance of the storage system.

EMC FAST Suite


VMware vSphere

14

FAST Cache is most suitable for I/O-intensive, random workloads with small working sets. A typical OLTP database with this kind of profile can greatly benefit from FAST Cache to improve performance and response time.

EMC AppSync provides simple, self-service application protection with tiered protection options and proven recoverability. AppSync protects an application by creating copies of application data.

Subscribing a Microsoft SQL Server 2012 database (for example) to a service plan indicates to AppSync that you want to protect that database. When the service plan runs, one or more copies are created. The service plan can also mount the copy, validate it, and run user-created scripts. A service plan comprises multiple phases, including create copy, mount copy, validate copy, unmount copy, and phases that run optional user-provided scripts.

AppSync includes several application-specific plans (for Exchange, SQL Server, and so on) that work without modification. With the Subscribe to Plan and Run command, you apply the settings of a service plan to your data and protect it immediately. When you subscribe an object to a service plan, it joins any other objects that are already part of the plan. All objects in the service plan are subject to the workflows and settings defined in the service plan.

AppSync can generate reports that tell you whether your data is protected, recoverable, and compliant with SLAs. The reports included with AppSync work without modification. Alerts and reports can be easily viewed at the top level of the AppSync dashboard. Alerts can be sent by email, and reports can be exported to comma-separated values (CSV) files. Figure 5 shows that the plan was executed successfully.

Figure 5. Service Plan Completion Report

Figure 6 depicts the architecture of using AppSync to protect a Microsoft SQL Server 2012 standalone instance.

EMC AppSync


VMware vSphere

Figure 6. AppSync for SQL Server 2012

AppSync components include the AppSync server software, host plug-in software, user interface, and REST interface.

• AppSync server software

The AppSync server software resides on a supported Windows system. It controls the service plans and stores data about each copy it creates. The repository is stored in a SQL Server 2012 database on the AppSync server.

• Host plug-in

AppSync installs lightweight plug-in software on the production and mount hosts. AppSync pushes the plug-in software from the AppSync server to the host when you add the host as a resource. In an environment that prevents the AppSync server from accessing a host, you can install the plug-in manually.

• AppSync user interface

The AppSync console is web-based and supports Chrome, Internet Explorer, and Firefox browsers. Flash and Java Runtime Environment are required. The AppSync Support Matrix on EMC Online Support is the authoritative source of information on supported software and platforms.

• REST interface

AppSync has a REST interface that allows application programmers to access information controlled by AppSync. The API is described in the AppSync REST API Reference, which is available on EMC Online Support.

EMC PowerPath/VE provides intelligent, high-performance path management with path failover and load balancing optimized for EMC and selected third-party storage systems. PowerPath/VE supports multiple paths between a VMware vSphere host and an external storage device. Having multiple paths enables the vSphere host to access a storage device, even if a specific path is unavailable. Multiple paths can also share the I/O traffic to a storage device.

EMC PowerPath/VE


VMware vSphere

16

PowerPath/VE is particularly beneficial in highly available environments because it can prevent operational interruptions and downtime. The PowerPath/VE path failover capability avoids host failure by maintaining uninterrupted application support on the host in the event of a path failure (if another path is available).

PowerPath/VE works with VMware ESXi as a multipath plug-in (MPP) that provides path management to hosts. It is installed as a kernel module on the vSphere host. It plugs into the vSphere I/O stack framework to bring the advanced multipathing capabilities of PowerPath/VE, including dynamic load balancing and automatic failover, to the vSphere hosts.

VMware vSphere 5.1 transforms a computer’s physical resources by virtualizing the CPU, RAM, hard disk, and network controller. This transformation creates fully functional virtual machines that run isolated and encapsulated operating systems and applications just like physical computers.

VMware High Availability (HA) provides easy-to-use, cost-effective high availability for applications running in virtual machines. The VMware vSphere vMotion and VMware vSphere Storage vMotion features of vSphere 5.1 enable the seamless migration of virtual machines and stored files from one vSphere server to another, with minimal or no performance impact. Coupled with VMware vSphere Distributed Resource Scheduler (DRS) and VMware vSphere Storage DRS, virtual machines have access to the appropriate resources at any point in time through load balancing of compute and storage resources.

VMware vSphere 5.1


VMware vSphere

Solution architecture and configuration

The environment in this solution consists of two SQL Server 2012 instances. Each instance runs on a Windows Server 2012 virtual machine that is hosted on an ESXi 5.1 two-node cluster. Storage is provided on the VNX5800 array. For cost-effective purposes, we connect the ESXi hosts to the storage through iSCSI connections.

The solution design includes the following physical components:

• Two VMware ESXi hosts, each hosting a virtual machine with one SQL Server instance

• EMC VNX5800 SAN storage

Figure 7 displays the physical architecture of the solution.

Figure 7. Solution architecture

Overview

Solution architecture


VMware vSphere

18

Table 3 details the hardware resources used in this solution.

Table 3. Hardware resources

Equipment Quantity Configuration

EMC next-generation VNX5800

1 80 x 10K 900 GB SAS

20 x 200 GB SAS Flash

120 x 7.2K 3 TB NL SAS

FLARE OE 33 SP2

FAST enabler licensed

IP switches 2 60-port, 10 Gb Fibre Channel over Ethernet (FCoE)-capable switches

Servers 2 2-U servers, Intel Xeon E7-2870 2.4 GHz:

• Two sockets, 10 cores per socket

• 160 GB memory

• 2 x dual port 10 Gb iSCSI converged network adapter (CNA) cards

Table 4 details the software resources used in this solution.

Table 4. Software resources

Resource Quantity Version Purpose

EMC VNX5800 block operating environment

1 5.33.000.3.794 VNX operating environment

EMC PowerPath/VE 2 5.8 Advanced multipathing for host iSCSI connections

Windows Server 3 2012 Enterprise Edition, x64

Server operating system

VMware ESXi 2 5.1 update 1 Hypervisor

Microsoft SQL Server 2 2012 Enterprise Edition Service Pack 1

Database servers for OLTP workload

EMC AppSync 1 1.6 Data protection

Hardware resources

Software resources


VMware vSphere

Table 5 details the SQL Server workload profile used in validating this solution. To avoid resource contention among the databases, we separated the SQL Server OLTP databases on two SQL Server instances, each one hosting two databases.

Table 5. Microsoft SQL Server 2012 workload profile

Profile characteristic Quantity/Type/Size

SQL Server instance 01 100,000 users/1 TB

25,000 users/250 GB

SQL Server instance 02 50,000 users/500 GB

5,000 users/50 GB

Workload type OLTP-like (90:10 read/write ratio)

This section describes storage considerations for this solution.

Balancing storage processors

In this solution, two SQL Server OLTP instances are on separate ESXi hosts that share the same front-end ports on the VNX. The IP switches are redundant, with the second switch continuing to handle all the network traffic in the event of a hardware failure on the primary IP switch. Figure 8 shows the network diagram between the front-end ports and the hosts for the SQL Server applications.

Figure 8. Network diagram

In earlier VNX and EMC CLARiiON® CX® series platforms, each LUN has a single owning storage processor (SP). The host SCSI interface is active/active, with the array servicing I/O from both the owner and the non-owner. However, the non-owner has substantially worse performance. I/O from the non-owning SP is redirected to the owning SP, using the inter-SP CLARiiON Messaging Interface (CMI) interconnect.

The MCx infrastructure has no concept of owner, with no per LUN asymmetry of performance between ports on different SPs. Pool-based LUNs continue to have the concept of ownership, and incur the asymmetry of performance between the LUN

Workload profile

Storage considerations


VMware vSphere

20

owner and non-owner; therefore, the owning SP would be reported as active/optimized, and the non-owning SP as active/non-optimized to the multipath software on the host. An EMC FLARE® LUN has no concept of ownership, and MCx reports all paths as active/optimized to the multipath software on the host.

In this solution, we configured pool LUNs for the SQL Server applications, which follows the EMC best practice of balancing SP utilization to fully utilize the storage processing power by distributing the load and binding the LUN owner evenly to both SPs. Because the active/optimized paths are evenly distributed, the loads are pushed to the SPs evenly. Table 9 on page 31 lists the owner for each LUN.

Balancing cores on storage processor

In MCx, every front-end and back-end port has preferred and alternating core assignments. MCx keeps front-end host requests serviced on the same core on which they originated, avoiding the adverse performance impact of swapping context between CPU cores. On the back end, every core has access to every drive, and servicing requests to the drives do not require swapping between CPU cores.

MCx uses the CPU processing more effectively and enables scaling performance. As port usage grows and I/O load increases, MCx automatically distributes processing to all available cores within the same socket.

Each slot is affined to a specified socket, with the front-end ports of the SLIC in the slot are affined to the cores within the socket in a round robin manner. The EMC best practice is to distribute the SLICs across the sockets by selecting the slots, so that the user workloads can evenly utilize the sockets on the SP.

Balancing back-end ports

The next-generation VNX back-end ports are 6 Gb/s SAS. Table 6 shows the maximum back-end SAS ports supported in each next-generation VNX model.

Table 6. Maximum back-end SAS ports per SP

Model Maximum back-end SAS ports per SP

VNX5200 2

VNX5400 2

VNX5600 6

VNX5800 6

VNX7600 6

VNX8000 16

The next-generation VNX can support more back-end ports than the earlier VNX. VNX5800, for example, supports up to six ports, whereas VNX5700 supports a maximum of four ports.


VMware vSphere

To achieve better performance, you can balance back-end ports through both physical and logical layers as follows:

1. Spread each drive type across all available buses by physically distributing or relocating drives between DPEs and DAEs.

MCx has two features, Drive Mobility and DAE Re-cabling, which allow for physically moving drives and entire DAEs inside the same frame from their existing locations to other slots or buses.

In earlier VNX and CX platforms, FLARE identifies drives by their physical address, for example: Bus 0 Enclosure 1 Disk 5. When a drive is moved to another slot, FLARE does not recognize the movement; consequently, any data that is on the disk is lost.

In MCx, the drives are identified by their serial number instead of physical address, allowing online drive movement. RAID group data continues to be available after the drive is pulled out. When a drive becomes unavailable, MCx starts a 5-minute counter, and drive sparing is invoked after the 5-minute interval passes. However, some users like to rearrange the entire storage pool, which may be safer and faster to do when the array is shut down; DAE Re-cabling satisfies this requirement. Users can simply shut down the array, cable DAEs as needed, and power the array back up. Upon power up, the array will easily locate the drives, by surveying their serial numbers, validate all RAID group members, and then continue operations.

2. Create LUNs to distribute their I/O evenly across the back-end ports.

SP cache settings

Cache size configuration In earlier VNX and CX platforms, FLARE divides the SP cache into three regions: read cache, write cache, and peer SP-mirror write cache. If the needed data resides in the cache, host read requests can be satisfied from either read or write cache. Read misses result in data being loaded into the read cache. Host write requests are satisfied from write cache and then mirrored to the peer SP cache.

Unlike with FLARE cache, Multicore Cache does not split the memory between read and write functions. The cache is shared for writes and reads, and the dirty cache page is copied to disk rather than being discarded. This improves the performance by page rehits including re-read and overwrite.

Therefore, with earlier VNX and CX platforms, you had to consider adjusting the read/write cache ratio according to the workload characteristic. On next-generation VNX platforms, this configuration is no longer necessary.

Flushing In earlier VNX and CX platforms, FLARE has a condition called forced flushing. It occurs when the percent count of “dirty” cache pages crosses over the high watermark and reaches 100 percent. Then the cache starts forcefully flushing unsaved data to disk, suspending all host I/O. Forced flushing continues until the percent count of dirty pages recedes below the low watermark. It affects the entire array and all workloads served by the array, and significantly increases the host response time until the number of dirty cache pages falls below the low watermark.


VMware vSphere

22

Multicore Cache changes the cache-cleaning model, eliminating the pre-set dirty cache page watermarks. Multicore Cache keeps track of dirty cache pages and the incoming write requests to the underlying RAID group, and evaluates the difference between the rate of incoming host writes and the rate of RAID group page flushes, dynamically reacting to workload changes. Multicore Cache avoids overwhelming the cache by write throttling and satisfying the temporary short bursts.

With earlier VNX and CX platforms, you had to consider adjusting the high/low watermark based on the workload changes and impact from forced flushing. On next-generation VNX platforms, this configuration is no longer necessary.

SP cache page size The SP cache page size setting, which determines the minimum amount of SP memory to service a single I/O operation, has been removed from Multicore Cache. With earlier VNX and CX platforms, users can adjust the SP cache page size according to the predominant I/O size:

• Maintain the default 8 KB for the majority of workloads

• Increase the page size to the maximum 16 KB for predominant large-block I/O size

• Match the cache page size to the predominant I/O size for predominant small-block I/O sizes like 2 KB or 4 KB

In Multicore Cache, the page size setting has been removed. Multicore Cache has two separate page sizes: physical page and logical page. The physical page size is 8 KB, while one logical page contains from one to eight physical pages. Multicore Cache uses logical pages to handle I/O operations.

This solution uses the default SP cache setting with write cache enabled on the array.

Thin provisioning

Thin LUNs maximize ease of use and capacity utilization, and take advantage of enabling data services such as VNX Snapshots, deduplication, and compression.

Thin LUNs can provide moderate performance in most environments, typically having lower performance than thick LUNs because of the indirect addressing. Thin LUN metadata workload overhead adds cost, however. If thin LUN metadata cannot be satisfied by SP memory, you must add a flash tier to which thin LUN metadata is promoted to improve performance. Virtual Provisioning for the New VNX Series provides more information.

In this solution, we use thin LUNs to store SQL Server data to improve the storage efficiency and take advantage of VNX Snapshots technology. Based on thin provisioning, we can easily achieve 50,000 IOPS and more on the next-generation VNX by using flash technologies.

Hot spare settings

In earlier VNX and CX platforms, to protect the data disk, you must create the RAID groups as “hot spares” by selecting the specific disks. For each drive type, you must create separate hot spares so that flash drives are spares for flash drives, SAS drives are spares for SAS drives, and NL-SAS drives are spares for NL-SAS drives. The best


VMware vSphere

practice is to configure one hot spare disk for every 30 disks, and the hot spare capacity should be equal to or larger than the productive drives.

Multicore RAID changes the way hot sparing functions to that you no longer select specific drives as hot spares. You enable a hot spare policy on the array, and the array automatically selects an unconfigured disk as a spare as needed.

In this solution, we enabled the default hot spare policy on the array, which uses one drive per 30 drives for each drive type.

Balancing data through FAST VP

In next-generation VNX, FAST VP granularity is smaller than with earlier VNX platforms—256 MB per slice compared to 1 GB per slice in earlier VNX and CX platforms. That allows FAST VP to move more hot data to the highest tier and fully use the flash drives to boost performance more efficiently.

FAST VP and FAST Cache are suitable for workloads with high skew and small working sets. OLTP environments commonly yield working sets of 20 percent or less of their total capacity. In this solution, the typical workload we used during the verification test had the skew of 83/17, meaning that 83 percent of I/O operations accessed 17 percent of the total data capacity.

In this solution, to balance the best performance and total cost of ownership (TCO), we expanded the SAS-only pool storing SQL Server data with two flash drives and enabled FAST VP on the pool. With FAST VP enabled, the metadata of thin LUNs can be promoted to the flash tier, which improves overall performance.

Balancing data through FAST Cache

In earlier VNX and CX platforms, FAST Cache is located above the SP cache. In MCx, the Multicore FAST Cache is below the Multicore Cache. MCx is quicker to acknowledge a host read/write than was possible with earlier platforms because Multicore Cache handles host I/O before searching the FAST Cache memory map.

From a performance point of view, FAST Cache provides an immediate performance benefit to bursty data such as SQL Server checkpoint running. FAST Cache and FAST VP features can be used together to yield high performance and TCO from the storage system. From a TCO perspective, FAST Cache can service active data with fewer flash drives, while FAST VP optimizes disk utilization and efficiency for SAS and NL-SAS drives.

In this solution, we configured the FAST Cache with six flash drives in three pairs. Following the best practice to spread the flash drives across the buses, we placed two flash drives on Bus 0 and another four flash drives on Bus 2.

This section shows the disk layout and storage configurations used in VNX5800. Design considerations involve many aspects. Always check the latest best practice and design considerations before building your solution.

Storage design


VMware vSphere

24

Disk layout

Figure 9 shows the disk layout we designed in this solution with FAST VP and FAST Cache enabled.

Figure 9. Disk layout

We spread the drives in the SQL OLTP data pool, SQL Server tempdb and log pool, and FAST Cache evenly across two buses to balance the back-end ports.

Note: We enabled the default hot spare policy on the array, allowing for one hot spare drive per 30 drives for all three drive types. And we had enough unused disks available on different buses to be used by Multicore RAID for hot spares.


VMware vSphere

Storage pool configuration

Table 7 details the VNX storage-pool configuration for the solution. We separated the storage pools according to the I/O pattern and SQL Server best practices.

Table 7. EMC VNX5800 storage pool configuration

Pool RAID type Disk configuration

Purpose

SQL Server OLTP data pool

RAID5 (4+1) 60 x 900 GB 10K SAS

Performance tier for SQL Server OLTP database

RAID10 (4+4) 2 x 200 GB MLC flash

Extreme performance tier for SQL Server OLTP database

SQL Server tempdb and log pool

RAID10 (4+4) 8 x 900 GB 10K SAS

SQL Server tempdb database and logs for SQL Server OLTP database

Virtual machines OS pool

RAID10 (4+4) 4 x 3 TB NL-SAS Virtual machine OS pool including SQL Server virtual machine, AppSync server, and Domain Controller; also for SQL Server system databases

On the VNX5800, FAST Cache can be enabled online and with total transparency to the virtualization or application layers. During the test, we configured six 200 GB flash drives for FAST Cache and enabled FAST Cache on the SQL Server OLTP data pool.

FAST VP design

After completing the baseline test, we expanded the storage pool with two 200 GB flash drives. We set the tiering policy for the data LUNs inside the storage pool to Start High then Auto-Tier, which is the default and recommended setting.

During the FAST VP testing, to ensure that the hot data was moved to the highest tier as soon as possible, we manually started the data relocation with the relocation rate set to High, as shown in Figure 10.

Figure 10. FAST VP data relocation setting


VMware vSphere

26

FAST Cache design

As shown in Figure 11, we configured six 200 GB flash drives and enabled FAST Cache on the SQL Server OLTP data pool for the FAST Cache test.

Figure 11. FAST Cache configuration

Data protection

In this solution, to protect SQL Server OLTP databases, we took advantage of AppSync and VNX Snapshots. VNX Snapshots uses Redirect on Write (ROW) technology. ROW redirects new writes destined for the primary LUN to a new location in the storage pool. Because VNX Snapshots requires pool space, when we designed the pool capacity, we calculated the space required by snapshots based on the data changes of the running OLTP workloads and the number of snapshots we wanted to keep.

To control snapshot growth, we enabled VNX Snapshots Auto-Delete, which avoids having the snapshots take usable space away from pool LUNs. EMC VNX Snapshots provides more details about VNX Snapshot Auto-Delete.

When deploying SQL Server 2012 in a VMware environment, you should apply some VMware and Microsoft best practices related to CPU, memory, and storage to achieve optimal database performance.

Virtual machine configuration

We deployed SQL Server virtual machines with the configuration shown in Table 8.

VMware configuration


VMware vSphere

Table 8. SQL Server virtual machine configuration

Virtual machine name

vCPU Memory Disk vSCSI controller

SQL Server Virtual Machine 01

32 50 GB 100 GB VMDK for OS, paging file, and SQL Server Master database files

0:0 (LSI Logical SAS)

1,500 GB VMDK for 1 TB SQL Server data files

1:0 (Paravirtual)

400 GB VMDK for 250 GB SQL Server data files

2:0 (Paravirtual)

400 GB VMDK for tempdb data files

3:0 (Paravirtual)

200 GB VMDK for log files 3:1 (Paravirtual)

SQL Server Virtual Machine 02

32 50 GB 100 GB VMDK for OS, paging file, and SQL Server Master database files

0:0 (LSI Logical SAS)


1:0 (Paravirtual)


2:0 (Paravirtual)

400 GB VMDK for tempdb data files

3:0 (Paravirtual)

200 GB VMDK for log files 3:1 (Paravirtual)

Note: In this test environment, we enabled Intel Hyper-Threading Technology on both ESXi hosts running SQL Server instances. This enabled the hosts to use the processor resources more efficiently, and enable multiple threads to run on each core.

We evenly distributed the SQL Server database files across multiple SCSI controllers. When configuring the SCSI controller type, we set the SCSI controller type for the SQL Server data disks as Paravirtual. VMware Paravirtual SCSI (PVSCSI) adapters are high-performance storage drivers that can improve the throughput and reduce CPU usage.

As shown in Figure 12, we provisioned the Virtual Machine Disk (VMDK) files as Thick Provision Lazy Zeroed in vSphere, which corresponds to configuring all the pool LUNs as thin provisioning. When you use Thick Provision Lazy Zeroed, the configured capacity in the vSphere datastore is reserved for future use. However, the setting does not require you to fully allocate capacity from the array, and it does not take additional time to zero the disks, which accelerates the process of creating virtual disks.


VMware vSphere

28

Figure 12. Disk provisioning

In this solution, to avoid moving two critical SQL Server virtual machines to the same host, we affined the virtual machines on specified hosts separately by creating the anti-affinity rules shown in Figure 13.

Figure 13. Virtual machine affinity rule setting


VMware vSphere

Memory settings

In this solution, we followed the VMware and Microsoft best practices to configure the virtual machine memory for SQL Server virtual machines to guarantee the best performance.

In ESXi environments, when the system is under memory pressure, the hypervisor notifies the balloon driver running inside the guest OS to reclaim memory from any virtual machine including SQL Server virtual machines, which significantly impacts SQL Server performance. To avoid memory balloon, you should fully reserve memory for SQL Server virtual machines as shown in Figure 14.

Figure 14. Reserve guest memory

In ESXi environments, a guest memory access needs to be translated twice to access the physical memory address on the ESXi host. This translates the guest virtual memory address to the guest physical memory address and translates the guest physical memory address to the host physical memory address. The translation look-aside buffer (TLB) on the CPU has stored a map directly from the guest virtual memory address to the physical memory address; therefore, a TLB hit can improve memory access performance, but a TLB miss results in worse performance. To reduce TLB misses and make TLB cover a larger memory range, you can possibly reduce TLB misses by using large pages.

To enable large page allocation, configure from both the host and the guest. From the host, you can enable large page allocation by setting the Mem.AllocGuestLargePage option to 0, as shown in Figure 15. From the guest, you can enable it by adding trace flag 834 to the SQL Server startup parameters.

Note: Trace flag 834 applies only to 64-bit versions of SQL Server. You must have the correct Lock pages in memory user to turn on trace flag 834.


VMware vSphere

30

Figure 15. Large page allocation setting

The following sections provide the design and configuration guidelines for SQL Server 2012 and AppSync server to protect the SQL Server instances.

SQL Server 2012 design and configuration

Design and requirements The following list shows the Windows and SQL Server 2012 configuration of each virtual machine. Default values were used for all other settings:

• Use Large Pages for the SQL Server instance by enabling the 834 startup parameters.

• Use Lock Pages in Memory for the SQL Server service account.

• Use the 64K format unit for all data and log LUNs.

• Set Max Server Memory to limit SQL Server available memory.

• Pre-allocate data files for both SQL OLTP and tempdb databases to avoid autogrow during peak time, and enable instant file initialization for the SQL Server startup service account to accelerate the process of initializing database files.

Application design and configuration


VMware vSphere

• Use multiple files for data and tempdb.

• Place the tempdb data files and log files on separate LUNs from an RAID 10 SAS storage pool.

Note: Instant file initialization is available only if the SQL Server (MSSQLSERVER) service account has been granted SE_MANAGE_VOLUME_NAME. Members of the Windows Administrator group have this right and can grant it to other users by adding them to the Perform Volume Maintenance Tasks security policy.

SQL Server Best Practices provides more information about best practices for SQL Server configuration.

As shown in Table 5 on page 19, the SQL Server 2012 configuration consists of two SQL Server instances. Instance 01 hosts the 1 TB and 250 GB OLTP TPCE-like databases, while instance 02 hosts the 50 GB and 500 GB OLTP TPCE-like databases. We ran a heavy OLTP-like workload with a read/write ratio of approximately 90/10 against the databases with a total user count of 180,000.

Note: The read/write ratio is determined by the OLTP workload tool.

LUN configuration We configured the VNX5800 storage pool enabled by EMC FAST VP to host SQL Server data LUNs. The LUNs hosted virtual machine operating system files, along with SQL Server data, log, and tempdb files, for both SQL Server OLTP database instances, as shown in Table 9.

Table 9. VNX5800 LUN configuration with two-tier storage pool enabled by FAST VP

Item Component Storage pool

LUN capacity (GB)

LUN owner

FAST VP policy

SQL Server instance 01

tempdb SQL Server tempdb and log pool

500 SP B N/A

tempdb log SQL Server tempdb and log pool

300 SP B

1 TB OLTP database


2000 SP A Start High then Auto-Tier

250 GB OLTP database


500 SP A

1 TB OLTP database log


300 SP B N/A

250 GB OLTP database log


50 SP B


VMware vSphere

32

Item Component Storage pool

LUN capacity (GB)

LUN owner

FAST VP policy

Virtual machine operating system


100 SP B N/A

SQL Server instance 02

tempdb SQL Server tempdb and log pool

500 SP A N/A

tempdb log SQL Server tempdb and log pool

300 SP A

500 GB OLTP database


1000 SP B Start High then Auto-Tier

50 GB OLTP database


250 SP B



200 SP A N/A



50 SP A

Virtual machine operating system


100 SP B N/A

AppSync design and configuration

AppSync 1.6 supports protecting VMware datastores. In this solution, we configured all database and log LUNs as VMFS datastores to take advantage of Microsoft Volume Shadow Service (VSS) framework functionality for application recovery.

In our test environment, we used AppSync 1.6 to protect the 500 GB SQL Server database with running OLTP workload. Follow these steps to configure the AppSync server to create application-consistent copies of the SQL Server OLTP database to protect database corruption:


VMware vSphere

Adding storage We added the VNX5800 as a managed storage array in AppSync. We entered the IP addresses of SP A and SP B, as shown in Figure 16, and provided the user credentials to log in to the storage system.

Figure 16. Add storage to AppSync server

Adding VMware vCenter Server We added the vCenter Server that manages the ESXi hosts to the AppSync server as shown in Figure 17. This allows us to protect, mount, and restore SQL Server standalone and clustered databases residing on VMware virtual disks. For successful mapping to the virtual disks, the vCenter Server must be added to the AppSync server and discovery must be performed.


VMware vSphere

34

Figure 17. Add VMware vCenter Server to AppSync server


VMware vSphere

Adding host We added the SQL Server virtual machine to the AppSync server, as shown in Figure 18. The SQL Server application we want to protect is running on the host. AppSync server pushes the plug-in software from the AppSync server to the host when you add the host as a resource. You can also install the plug-in manually on the host, and then add the host to the AppSync server.

Figure 18. Add host to AppSync server

Discovering SQL Server instances and databases We discovered the SQL Server instances and the OLTP databases running on them, as shown in Figure 19.


VMware vSphere

36

Figure 19. Discover SQL Server databases

To keep AppSync up to date, you should discover SQL Server instances when you create or delete instances. This operation requires that you have the Data Administrator role in AppSync and know the credentials for the SQL Server instances.

After connecting to the SQL Server databases, AppSync shows the SQL Server User Databases folder, shown in Figure 20, which contains all the user databases that have been discovered and stored in the AppSync database.

Figure 20. User database in SQL Server instance

Creating service plan We created a service plan to protect the SQL Server OLTP database by creating snapshots, and executed the plan on schedule.


VMware vSphere

After establishing the connection with SQL server, you can start to configure the service plan. AppSync provides three default service plans:

• Gold—Creates Microsoft SQL Server full local and remote backup copies

• Silver—Creates Microsoft SQL Server full remote backup copies

• Bronze—Creates Microsoft SQL Server full local backup copies

You can also create a new service plan by using an existing plan as a template. The new service plan contains the same schedule and other settings as the template, but there are no objects subscribed to the new service plan. You can override the new service plan’s Plan Startup and Create Copy settings to specify separate configurations for individual objects that are subscribed to the plan.

Plan Startup

In this solution, we configured the recovery point objective (RPO) as one hour and ran the service plan on schedule to create snapshots.

In the Plan Startup phase of the service plan, you select a recurrence type based on when the service plan is triggered. This recurrence type is applicable for all application objects that are subscribed to a service plan. However, you can override the settings and specify separate settings for selected objects. A service plan's Startup Type (scheduled or on demand) determines whether the plan is run manually or configured to run on a schedule. Options for scheduling when a service plan starts are:

• Run every day at certain times

• Run at a certain time on selected days of the week

• Run at a certain time on selected days of the month

• Specify an RPO

AppSync support an RPO of 30 minutes or 1, 2, 3, 4, 6, 8, 12, or 24 hours. The default RPO in AppSync is 24 hours. In our testing environment, we set the Startup Type as Scheduled and RPO as 1 hour.


VMware vSphere

38

Figure 21 shows the Service Plans tab.

Figure 21. Service Plans tab

Create Copy

We created a full backup of the SQL Server OLTP database, chose VNX Snapshots as the replication technology, and kept the maximum number of VNX Snapshots copies at four, as shown in Figure 22.

Figure 22. Create Copy configuration


VMware vSphere

When the maximum snapshots number exceeds four, AppSync server requires VNX to create a new snapshot, and then expires the oldest snapshot, so that it keeps four snapshots for the database LUNs.

Subscribing a database to the plan We subscribed the SQL Server OLTP database to the service plan, as shown in Figure 23. AppSync server automatically executed the plan at the scheduled time to create a snapshot for the database LUNs per hour.

Figure 23. Subscribe to a service plan

To protect a SQL Server database, subscribe the database to an AppSync service plan. You can subscribe a database or the user databases folder to a service plan and run the service plan immediately, or schedule the service plan to run at a later time.

Table 10 shows different ways to protect databases.

Table 10. Database protection options in AppSync

Option Description

Subscribe to plan and run Subscribe the selected databases for protection and run the plan immediately.

Subscribe to plan Subscribe the selected databases for protection. Protection for all databases that are part of the service plan are executed at the scheduled time.

Create copy using plan Subscribe the selected databases for protection and run the plan immediately.

Run Run the plan immediately.


VMware vSphere

40

Validation

This solution validates the performance and functionality of enterprise-class SQL Server 2012 instances in a virtualized VMware environment on the next-generation VNX platform.

This solution showcases accelerated and offloaded protection for SQL Server 2012 OLTP databases through AppSync with VNX Snapshots technology.

The testing of this solution validated the ability of the next-generation VNX storage arrays to support multiple Microsoft SQL Server instances running OLTP-like workloads. Tests involved:

• Enabling FAST VP on the SQL Server data pool to boost performance

• Enabling FAST Cache on the SQL Server data pool to get best performance

• Showcasing the protection for SQL Server OLTP databases through EMC AppSync with EMC VNX Snapshot technology

Notes

Benchmark results are highly dependent on workload, specific application requirements, and system design and implementation. Relative system performance will vary as a result of these and other factors. Therefore, this workload should not be used as a substitute for a specific customer application benchmark when critical capacity planning and/or product evaluation decisions are contemplated.

All performance data contained in this report was obtained in a rigorously controlled environment. Results obtained in other operating environments may vary.

Testing methodology required TPC-E-like (OLTP) workloads to be run against four target databases on two SQL Server instances, with each SQL Server instance containing two target databases.

Multiple scenarios have been validated in this configuration. These include:

• Baseline testing on an SAS-only pool

Run multiple OLTP workloads on all four OLTP databases.

• Performance testing on a FAST VP enabled pool

Repeat the same performance test on the FAST VP enabled databases, and compare the performance before and after enabling FAST VP.

• Performance testing on a FAST VP pool with FAST Cache enabled

Repeat the same baseline performance test on the FAST VP enabled storage pool, and compare the performance before and after enabling FAST Cache.

Overview

Test objectives

Testing methodology

Test scenarios


VMware vSphere

• Performance testing on a SAS-only pool with snapshots enabled

Run the baseline performance test on the SAS-only pool, and create snapshots through AppSync and VNX Snapshots after the baseline test goes into steady state.

• Restore testing from the created snapshots

Restore the snapshots through AppSync and VNX Snapshots, and measure the recovery time objective (RTO).

We conducted a series of tests by running concurrent TPC-E-like (OLTP) workloads against the target databases on both SQL Server instances. The test procedure was as follows:

1. Ran the baseline performance test, reached a steady state, and measured and recorded the performance.

2. Introduced two flash drives to the pool and enabled FAST VP. Continued to apply workload, and manually started the data relocation using the High Relocation rate. Measured and recorded the performance throughout the test.

3. Enabled FAST Cache with load running and monitored the performance during the entire test, including the warm-up and steady-state phases.

Note: The workload profile parameters were not changed during testing. A profile was set to push the utilization of the SAS-only pool, showing the impact on performance with the introduction of flash drives and enabling of FAST VP and FAST Cache.

Metrics were taken using a combination of SQL Server performance counters, Unisphere NAR files, VMware esxtop output, and AppSync test output.

Test results are broken down into the following areas:

• Throughput testing with FAST Suite, including FAST VP and FAST Cache

• Protection testing, measuring the performance impact after VNX Snapshots was enabled, and recovery time during the restore testing

Throughput testing

The following are the key metrics for throughput testing:

• Throughput in IOPS (transfers per second)

• Throughput in TPS (transactions per second)

• Host latency (average disk seconds per transfer)

• Physical disk utilization (percent)

• Storage processor utilization (percent)

Performance test procedures

Test results


VMware vSphere

42

Throughput in IOPS and TPS Throughput was measured using the Microsoft Perfmon counters LogicalDisk—Disk Transfers/sec and Databases—Transactions/sec. Figure 24 shows the IOPS and TPS results.

Figure 24. IOPS and TPS for baseline, FAST VP, and FAST Cache

During baseline testing with 60 SAS disks in the storage pool, two SQL Server instances produced 13,000+ IOPS in total, and around 1,400 SQL Server TPS.

After the introduction of two flash drives to the storage pool with FAST VP enabled and a four-hour relocation window run, the total IOPs rose to more than 24,000 IOPS and the TPS rose to more than 2,600.

After enabling FAST Cache with six flash drives on the SQL Server data pool, IOPS rose to 52,303, and TPS rose to 5,095. As shown in Table 11, the test showed almost four times improvement in the ability to service I/O between a total baseline of 13,148 IOPs and 52,303 IOPs with FAST Suite enabled.

Table 11. Throughput in IOPS

Stage SQL Server 01 SQL Server 02

Baseline testing with 60 SAS disks 7,319 5,829

After adding two flash drives and a four-hour relocation window run

12,910 11,232

After enabling FAST Cache with six flash drives 27,590 24,713

As shown in Table 12, the test showed almost four times improvement in the ability to service TPS between 1,394 baseline TPS and 5,095 TPS with FAST Suite enabled.


VMware vSphere

Table 12. Throughput in TPS

Stage SQL Server 01 SQL Server 02

Baseline testing with 60 SAS disks 689 705

After adding two flash drives and a four-hour relocation window run

1,161 1,494

After enabling FAST Cache with six flash drives 2,267 2,828

After we introduced two flash drives to the pool and enabled FAST VP, results showed a significant improvement in the IOPS and TPS that the pool was able to service.

After we enabled FAST Cache with six flash drives, we saw further improvements. With only eight flash drives being used, we achieved a great performance with more than 50,000 IOPS, while keeping the cost low on the next-generation VNX platform.

Host latency We measured throughput using the Perfmon counter LogicalDisk—Avg. Disk sec/Transfer.

During baseline testing with 60 SAS disks in the storage pool, under a heavy workload, the latency on the two databases was higher than 20 ms.

After we introduced two flash drives to the storage pool with FAST VP enabled and a four-hour relocation window run, the latency dropped to less than 20 ms. The latency on the 1 TB database dropped significantly from around 30 ms to 19 ms.

After we enabled FAST Cache on the SQL Server data pool with FAST VP enabled, the latency on both databases dropped to less than 8 ms.

Figure 25 shows the latency results.

Figure 25. Host latency


VMware vSphere

44

After we introduced two flash drives to the pool and enabled FAST VP, we saw a significant improvement in the host latency. After we enabled FAST Cache with six flash drives, the I/O bottleneck was completely removed and the storage responded quickly.

Physical disk utilization We measured the physical disk utilization after analyzing the Unisphere NAR files. Figure 26 and Table 13 show the results.

Figure 26. Physical disk utilization for baseline, FAST VP, and FAST Cache

Table 13. Physical disk utilization (percent)

Stage SAS disks Flash drives

Baseline testing with 60 SAS disks 82 N/A

After adding two flash drives and a 4-hour relocation window run

78 45

After enabling FAST Cache with six flash drives 39 79

During baseline testing with 60 SAS disks in the SQL Server OLTP data pool, the pool showed a physical disk utilization of 82 percent.

After we introduced two flash drives to the storage pool with FAST VP enabled and a four-hour relocation window run, the utilization of the 60 SAS disks in the pool dropped to 78 percent. The utilization of the newly introduced flash drives rose to 45 percent in the SQL Server data pool.

After we enabled FAST Cache with only six flash drives on the SQL Server data pool, the SAS disk utilization dropped to 39 percent. The utilization of the flash drives in the pool rose to 79 percent.


VMware vSphere

After we introduced two flash drives to the SQL Server data pool and enabled FAST VP:

• Hot data relocated to the flash drives in the Extreme Performance tier to better service I/O.

• Disk utilization on the SAS tier dropped.

We saw additional improvements after we enabled FAST Cache on the storage pool. FAST Cache also further reduced the pressure from the SAS tier because frequently accessed data from the tier was placed in cache. With flash drives, the SAS tier could now be used for higher-capacity workloads.

Combining FAST VP with FAST Cache utilized the FAST VP flash drives more efficiently because the bottlenecks in I/O on the SAS tier were automatically removed. The flash drive utilization increased as the test workload ran faster and achieved more IOPS and TPS.

Storage processor utilization We measured SP utilization after analyzing the Unisphere NAR files.

• SP A was the default allocation owner for the OLTP data LUNs configured for SQL Server Instance 01.

• SP B was the default allocation owner for the OLTP data LUNs configured for SQL Server Instance 02.

Figure 27 and Table 14 show the storage processor utilization.

Figure 27. Storage processor utilization for baseline, FAST VP, and FAST Cache


VMware vSphere

46

Table 14. Storage processor utilization (percent)

Stage SP A SP B

Baseline testing with 60 SAS disks 26 18

After adding two flash drives and a 4 hours relocation window run

44 30

After enabling FAST Cache with six flash drives 76 71

During baseline testing with 60 SAS disk in the SQL Server data pool, SP A showed 26 percent utilization and SP B showed 18 percent utilization.

After we introduced two flash drives to the pool with FAST VP enabled and a four-hour relocation window run, SP A showed 44 percent steady-state utilization and SP B showed 30 percent utilization after relocation.

After we enabled FAST Cache on the pool, SP A steady-state disk utilization rose to 76 percent and SP B utilization rose to 71 percent.

After we introduced FAST VP and FAST Cache, with increasing workloads being handled by the storage array, we saw a corresponding rise on both SPs.

Protection testing

We ran baseline testing on the 500 GB database stored on a 1 TB LUN created from the same 60 SAS disks pool without enabling FAST Suite.

When the test entered the steady state, we used VNX Snapshots to create hourly snapshots on the LUNs storing the database, and set the maximum number of snapshots to four. We measured the performance throughout the testing.

Afterward, we performed the restoring test from the created snapshots and measured the recovery time required.

Performance testing with snapshots We measured the performance impact as follows:

• Throughput in IOPS

• Throughput in TPS

• Host latency

After we enabled VNX Snapshots, the IOPS dropped no more than 6.4 percent from 3,838 to 3,594. TPS dropped no more than 7.2 percent from 571 to 530. The read latency was maintained at the same level of 7 ms, while the write latency increased slightly, from 6 ms to an average of 7 ms with a peak at 10 ms. Overall the IOPS, TPS, and latency maintained the same performance as the baseline regardless of whether snapshots were being created or destroyed.


VMware vSphere

Figure 28 and Figure 29 show the results.

Figure 28. IOPS and TPS comparison

Figure 29. Latency comparison

The results show little performance impact to the running workloads after VNX Snapshots was enabled. Because the SQL Server workload is totally random, the fragment generated by snapshots has little impact on the performance.

Restore testing We measured the performance impact of restoring snapshots by using the RTO key metrics.


VMware vSphere

48

Table 15 shows the test result for restoring snapshots of SQL OLTP database LUNs.

Table 15. Restore testing results

Item Recovery time Data changes (GB)




Snap 4 6 min 48 sec 13.5

The results show that the AppSync server took only 8 minutes 37 seconds to recover a 1TB database LUN with 55 GB data changes. In this short period, the AppSync server unmounted the file systems storing SQL Server database files and then removed the virtual disks from the SQL Server virtual machine. VNX began to restore from the snapshot, hot-add the virtual disks back to the SQL Server virtual machine, and then remount the file systems.


VMware vSphere

Conclusion

EMC FAST Suite significantly boosts performance of the EMC next-generation VNX series storage array at a low cost by using a combination of SAS drives and a small number of flash drives. It also reduces the TCO for the Microsoft SQL Server Enterprise environment by removing the need for administrators to perform repetitive manual tasks to optimize application performance. FAST Suite enables optimal use of your investment in flash technology. Although FAST Suite can be used by any application, with various I/O patterns, it is especially well suited for highly transactional applications that access data with small random I/O patterns.

The next-generation VNX series storage systems provide more powerful and easily configurable functions. MCx provides CPU scaling, symmetric active/active capability, and adaptive Multicore Cache to react automatically to OLTP-workload I/O pattern changes. A flexible hot spare policy that finds the best-fit hot spare without user interference, permanent sparing, drive mobility, and DAE re-cabling provide users with more flexibility and optimized availability of back-end buses. Having Multicore FAST Cache below Multicore Cache, along with the optimized filter algorithm in Multicore Cache, provides more efficient I/O handling in flash drives and avoids data bouncing between HDDs and flash drives. Smaller slices (256 MB) make the FAST VP hot data relocation more accurate and utilize the flash drives more efficiently.

EMC AppSync with VNX Snapshots provides protection to SQL Server OLTP databases in a simple, easily configurable fashion. Enabling snapshots has little impact on production SQL Server workloads, and provides rapid data replication and recovery of SQL Server data.

The key findings of this solution are:

• The VNX series storage array can easily service over 50,000 Microsoft SQL Server OLTP IOPS at low cost by using only eight flash drives for FAST Suite.

• The combination of FAST VP and FAST Cache allows the VNX series storage arrays to optimize storage efficiency and service increased I/O.

• AppSync streamlines SQL Server data replication for protection and repurposing scenarios.

• VNX Snapshots has little impact to the running SQL Server TPC-E like transactional workloads. After VNX Snapshots was enabled, the performance dropped no more than about 7 percent.

• AppSync with VNX Snapshots enables fast recovery, with the AppSync server taking only 8 minutes 37 seconds to recover a 1 TB database LUN carrying 55 GB of data changes.

Summary

Findings


VMware vSphere

50

References

For additional information, see the following white papers:

• VNX MCx–Multicore Everything

• Introduction to the New EMC VNX Series—VNX5200, VNX5400, VNX5600, VNX5800, VNX7600, and VNX8000: A Detailed Review

• EMC VNX FAST VP—VNX5200, VNX5400, VNX5600, VNX5800, VNX7600, and VNX8000: A Detailed Review

• EMC VNX Snapshots

• Advanced Protection for Microsoft Exchange 2010 on EMC VNX Storage

• Performance Best Practices for VMware vSphere 5.0

• Large Page Performance

• Understanding Memory Resource Management in VMware vSphere 5.0

• Virtual Provisioning for the New VNX Series

For additional information, see the following product documents:

• AppSync Advanced VNX Data Protection & Storage Management Software

• Where to Learn More About EMC AppSync

• EMC AppSync–Simplified Application Protection for VNX

• VNX Series–Simple, Efficient, Powerful, Protected

For additional information, see the following Microsoft resources:

• Microsoft TechNet

• SQL Server Best Practices Article

White papers

Product documentation

Other resources


VMware vSphere

Appendix: Hot spare policy Multicore RAID considers every unconfigured drive available in the storage array as a spare. The unconfigured drives also can be used for pools and RAID groups. No special tags or configurations are required to allow the system to select a spare for a failed or failing drive. Sparing occurs as long as appropriate unconfigured drives are available. The only option you can set are the policies.

Multicore RAID also introduces permanent sparing, where a RAID group rebuilds a hot spare and then the new hot spare disk becomes a permanent member of the RAID group. Therefore, equalization back to the replaced disk does not occur.

Multicore RAID uses the following logic to select a suitable drive replacement:

1. Type—Look for all available drives of the same type (SSD, SAS, or NL-SAS)

2. Bus—From the drives of the same type found, select drives on the same bus

3. Size—From the drives found on the same bus, select drives of the same or larger capacity

4. Enclosure—From the drives found that are of the same or larger capacity, check whether any of them are in the same enclosure as the failed drive

The array then selects one drive from the final set of suitable drives.

As shown in Figure 30, you can choose from the following hot spare policies for each drive type:

• Recommended

• Custom

• No Hot Spares

Figure 30. Hot-spare policy settings

Note: Choosing a hot spare policy does not force MCx to abide by the rule, so it does not set aside any drives for hot spares. The policy simply sets a threshold for user notification. When a specified policy is violated, a message notifies the user of the violation.

enhancing the performance and protection of microsoft sql ...enhancing the performance and...

Documents