EMC Extreme Performance and Efficiency for Microsoft SQL Server ...

Solution Guide

EMC EXTREME PERFORMANCE AND EFFICIENCY FOR MICROSOFT SQL SERVER EMC XtremIO, VMware vSphere, and Microsoft SQL Server 2014  Optimize very high throughput for SQL Server workloads  Virtualize and consolidate database instances  Minimize storage footprint for multiple database copies

EMC Solutions Abstract This solution guide describes the operational advantages of virtualized Microsoft SQL Server 2014 databases deployed on an EMC® XtremIO™ all-flash array, and how the solution enhances the capabilities of SQL Server databasedependent environments. April 2015

Copyright © 2015 EMC Corporation. All rights reserved. Published in the USA. Published April 2015 EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice. The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. EMC Extreme Performance and Efficiency for Microsoft SQL Server Solution Guide Part Number H13870

2

EMC Extreme Performance and Efficiency for Microsoft SQL Server EMC XtremIO, VMware vSphere, and SQL Server 2014 Solution Guide

Contents

Contents Chapter 1

Executive Summary

7

Document purpose ..................................................................................................... 8 Audience .................................................................................................................... 8 Business case ............................................................................................................ 8 Solution purpose ........................................................................................................ 9 Key results................................................................................................................ 10 Terminology.............................................................................................................. 10

Chapter 2

Solution Overview

11

Introduction ............................................................................................................. 12 EMC XtremIO ............................................................................................................ 12 Key advantages ................................................................................................... 12 VMware vSphere ...................................................................................................... 13 Microsoft SQL Server 2014 ....................................................................................... 14 SQL Server clustering storage considerations ...................................................... 14 SQL Server Data Compression.............................................................................. 15

Chapter 3

Solution Architecture

16

Overview .................................................................................................................. 17 Architecture diagram ................................................................................................ 17 Hardware resources.................................................................................................. 18 Software resources ................................................................................................... 19

Chapter 4

Storage Layer: EMC XtremIO

20

Storage design overview ........................................................................................... 21 Database considerations .......................................................................................... 21 Storage design details .............................................................................................. 22

Chapter 5

Microsoft SQL Server Solution Design

24

Overview .................................................................................................................. 25 SQL Server database solution storage design ........................................................... 25 SQL Server database solution profile ........................................................................ 25 SQL Server database solution LUN design ................................................................ 26

Chapter 6

Network Layer Best Practices

27

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


3

Contents

SAN network ............................................................................................................. 28 IP network ................................................................................................................ 28 VMware vSphere network ......................................................................................... 28

Chapter 7

Physical Servers and Virtualization Layer

30

Overview .................................................................................................................. 31 Compute and storage resources ............................................................................... 31 Network virtualization .............................................................................................. 32 Storage management with ESI .................................................................................. 32

Chapter 8

Design Considerations

33

Overview .................................................................................................................. 34 XtremIO configuration best practices ........................................................................ 34 Configuring Fibre Channel switches ..................................................................... 34 Configuring servers .............................................................................................. 34 Configuring vSphere Native Multipathing ............................................................. 36 Placing XtremIO devices under PowerPath’s control ............................................. 38 Configuring XtremIO storage for SQL Server using ESI ............................................... 38 Provisioning XtremIO ........................................................................................... 39 Creating and mounting a snapshot using AppSync ................................................... 42 Creating a snapshot of an existing SQL Server database with AppSync ................ 42 Mounting a snapshot of a SQL Server database with AppSync ............................. 45

Chapter 9

Performance Testing and Validation

47

Overview .................................................................................................................. 48 Notes on results................................................................................................... 48 Test objectives..................................................................................................... 48 Test scenarios...................................................................................................... 48 OLTP workload performance and scale test .............................................................. 49 Test methodology ................................................................................................ 49 Test procedure ..................................................................................................... 49 Test results .......................................................................................................... 50 XtremIO system performance ............................................................................... 51 XtremIO and SQL Server OLTP read/write workloads ............................................ 52 VMDK and RDM performance comparison ............................................................ 52 Test methodology ................................................................................................ 52 Test procedure ..................................................................................................... 53 Test results .......................................................................................................... 53 XtremIO data reduction analysis ............................................................................... 54 Snapshot data reduction ..................................................................................... 54

4


Contents

Production database data reduction rate ............................................................. 55 XtremIO Data reduction with SQL Server AlwaysOn Availability Groups ................ 55 SQL Server row and page compression on XtremIO .............................................. 57 Test methodology ................................................................................................ 58 Test procedure ..................................................................................................... 58 Test results .......................................................................................................... 58 SQL Server Failover Clustering on VMware setup and analysis .................................. 59 LUN setup ............................................................................................................ 59 Cluster setup validation ....................................................................................... 61

Chapter 10 Conclusion

62

Summary .................................................................................................................. 63 Findings ................................................................................................................... 63

Chapter 11 References

64

EMC documentation ................................................................................................. 65 VMware documentation............................................................................................ 65 Microsoft SQL Server documentation ........................................................................ 65

Figures Figure 1.

XtremIO Storage Management Application dashboard ......................... 12

Figure 2.

XtremIO all-flash array family ............................................................... 13

Figure 3.

AlwaysOn FCI versus AAG .................................................................... 14

Figure 4.

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

Figure 5.

XtremIO storage capacity consumption planning ................................. 22

Figure 6.

XtremIO Management Application dashboard storage panel ............... 22

Figure 7.

XtremIO dual X-Brick FC switch configuration ....................................... 34

Figure 8.

Changing the I/O Throttle Count setting for Cisco UCS Server .............. 35

Figure 9.

Storage device path management configuration .................................. 37

Figure 10.

XtremIO SSD LUN under PowerPath management ................................ 38

Figure 11.

Setting up XtremIO in ESI ..................................................................... 39

Figure 12.

Creating a new XtremIO volume in ESI ................................................. 40

Figure 13.

Viewing XtremIO storage capacity in ESI .............................................. 40

Figure 14.

Viewing XtremIO storage groups in ESI ................................................ 41

Figure 15.

XtremIO volume mappings in ESI ......................................................... 41

Figure 16.

Assigning an RDM to SQL Server for database storage in ESI ............... 42

Figure 17.

Adding XtremIO to AppSync ................................................................. 43

Figure 18.

Configuring SQL Server in AppSync ...................................................... 43

Figure 19.

Selecting the database and the protection plan for the snapshot ........ 44


5

Contents

Figure 20.

XtremIO snapshots created with AppSync ........................................... 44

Figure 21.

Selecting SQL Server mount copy options............................................ 45

Figure 22.

Mounted snapshot ready for read/write operation on the recovered database copy ..................................................................................... 45

Figure 23.

Mounted database recovered as a read/write copy ready for database operations ........................................................................................... 46

Figure 24.

SQL Server and XtremIO scalability test ............................................... 50

Figure 25.

XtremIO Performance with full OLTP work load on SQL Server 2014 ..... 51

Figure 26.

SQL Server 2014 disk I/O performance ................................................ 51

Figure 27.

SQL Server 2014 database transactional performance ........................ 52

Figure 28.

IOPS for the same workload against RDM and VMDK ........................... 53

Figure 29.

SQL Server and XtremIO latency with RDM and VMDK .......................... 53

Figure 30.

XtremIO snapshot data efficiency ........................................................ 55

Figure 31.

Deduplication ratio and physical space used before and after creating the AAG ............................................................................................... 56

Figure 32.

Volume and physical space used for SQL Server AAG instance ............ 56

Figure 33.

XtremIO physical storage usage during a bulk insert............................ 57

Figure 34.

Space savings from SQL Server native compression ............................ 58

Figure 35.

Performance improvement from SQL Server compression and CPU usage change ................................................................................................ 59

Figure 36.

VMware virtual machine disk configuration for an AlwaysOn FCI .......... 60

Figure 37.

XtremIO and SQL Server OLTP performance with an AlwaysOn FCI on vSphere 5.5 ......................................................................................... 61

Tables

6

Table 1.

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

Table 2.

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

Table 3.

Software resources .............................................................................. 19

Table 4.

Microsoft SQL Server storage design on XtremIO ................................. 23

Table 5.

Volume assignments for OLTP Databases ............................................ 23

Table 6.

SQL Server 2014 OLTP database profiles ............................................ 25

Table 7.

LUN design details for the SQL Server 2014 OLTP databases .............. 26

Table 8.

vSwitch configuration .......................................................................... 32

Table 9.

Test workload sequence ...................................................................... 49

Table 10.

VMware support for failover clusters.................................................... 59


Chapter 1: Executive Summary

Chapter 1

Executive Summary

This chapter presents the following topics: Document purpose ..................................................................................................... 8 Audience .................................................................................................................... 8 Business case ............................................................................................................ 8 Solution purpose........................................................................................................ 9 Key results ...............................................................................................................10 Terminology .............................................................................................................10


7


Document purpose This solution guide: 

Describes a highly available and scalable solution for Microsoft SQL Server deployed in a virtualized VMware vSphere environment with EMC® XtremIO™ all-flash storage.



Describes how the solution improves and enhances the performance of SQL Server 2014 by providing new capabilities and simplifying configuration.



Demonstrates how XtremIO read and write snapshots enable highly effective reporting and development environments with no performance impact to the consolidated production server.

Audience The solution guide is intended for SQL Server database administrators, VMware administrators, storage administrators, IT architects, and technical managers who are responsible for designing, creating, and managing SQL Server databases, infrastructure, and datacenters.

Business case Increasing demands on today’s business environments are driving enterprises to optimize processes and improve service. Fueling the demands on IT infrastructure performance and data availability are: 

High-transaction workloads



Time-critical applications and escalating service-level agreements



Turn-key and third-party applications with high sensitivity for I/O responsiveness



Replication of application databases for use by supporting business processes such as business intelligence (BI) reporting, testing, and development



The need for highly available architectures

In most environments, enterprises need to create copies of production data with minimal impact to the system, and safely repurpose those copies so that business teams within their organization can use the data. Typically, they must wait hours or days to get access to copies of production data. This delay reduces their effectiveness for tasks, such as BI insight, data integrity, validation, and auditing. As enterprises attempt to improve data availability, issues such as the following occur when the environment cannot meet expectations:

8



The configurations are too complex for SQL Server environments that include production, test, development, and analytics.



The existing technology solution has limited capabilities to maintain multiple copies of databases for read and write purposes, without affecting production



performance. In many cases, the enterprise requires duplicated highperformance environments, which can be very costly. 

Maintaining the complex systems puts high demands on operations staff.



The environment might need expensive third-party tools to manage unwieldy backup and recovery methods

Enterprises that rely on SQL Server must consider new approaches to meet continuing operational performance and capacity management challenges. Solutions that provide high performance levels while minimizing operational costs and complexity are important.

Solution purpose Working together, Microsoft and EMC supply the critical components that deliver high-performance, enterprise-class solutions for SQL Server environments. EMC XtremIO provides an optimized storage solution for high demand online transaction processing (OLTP) database performance for SQL Server. It ensures that you can maximize the efficiencies of other system resources, such as CPU and memory. The XtremIO all-flash array responds to changing conditions such as transaction processing spikes and complex queries, and supports test and development environments with up-to-date copies of production databases. Through XtremIO array-based snapshots, this solution enables near-instant data recovery to minimize downtime after a database issue (data loss, logical corruption, and so on) occurs. XtremIO snapshot technology also enables faster, easier, and more cost-effective data accessibility, which improves BI and analytics. XtremIO all-flash arrays resolve database storage challenges by: 

Enabling you to create a volume with just a few clicks



Enabling storage of the entire database structure with no need for complicated planning, provisioning, or tuning



Automatically employing all storage-system resources—solid-state drives (SSDs) and controllers—all the time



Scaling out the XtremIO system to increase performance if your requirements exceed what a single XtremIO X-Brick delivers



Eliminating complexities by using XtremIO snapshots to manage multiple instances and databases copies


9


Key results This solution shows that the XtremIO all-flash storage array delivers: 

Fast and simple setup without storage tuning. XtremIO works as seamlessly in virtualized SQL Server environments as in physical ones. With EMC Storage Integrator (ESI), the configuration for XtremIO is further simplified and is easy to manage and monitor in a single user interface.



Support for the most demanding transactional SQL Server 2014 OLTP workloads, with throughput that can easily exceed 300,000 IOPS for a two X-Brick configuration while maintaining near average sub-millisecond latencies



XtremIO inline compression works with or without SQL Server native compression to save physical storage while still offering the best performance with substantial storage savings.



Substantial storage footprint savings by using XtremIO inline data reduction and snapshots



Close to real-time, high-performance copies of data with XtremIO snapshot technology at no immediate measurable cost, while providing near-instant recovery of production data, even with Big Data



XtremIO supports SQL Server features such as AlwaysOn Failover Cluster Instances (FCI) and AlwaysOn Availability Group (AAG).

Terminology Table 1 provides definitions of terminology used in this guide. Table 1.

10

Terminology

Term

Definition

Data synchronization

The process that reproduces changes to a primary database on a secondary database.

Online transaction processing (OLTP)

Transaction-oriented processes such as data entry and retrieval transaction processing.

Round robin

An automatic and performance-effective path-selection policy. Round-robin policy rotates through all available paths, enabling the distribution of load across the configured paths and selecting the next available I/O path in the list without any determining factor. For example, if you have six I/O requests in the queue for storage, a roundrobin policy dictates the use of paths 1 to 6 in order.

Virtual Machine Disk (VMDK)

A file format for virtual machines.


Chapter 2: Solution Overview

Chapter 2

Solution Overview

This chapter presents the following topics: Introduction .............................................................................................................12 EMC XtremIO ............................................................................................................12 VMware vSphere ......................................................................................................13 Microsoft SQL Server 2014 ...................................................................................... 14


11


Introduction This solution includes the following key technology components: 

EMC XtremIO



VMware vSphere



Microsoft SQL Server 2014

EMC XtremIO The EMC XtremIO storage array is an all-flash system with a scale-out architecture. The system uses building blocks, called X-Bricks, that you can cluster together to increase performance and capacity as required. This solution uses two X-Bricks clustered together as a single logical storage system. Key advantages

XtremIO uses flash storage to deliver value across the following main dimensions: 

Performance—Regardless of how busy the system is, and regardless of storage capacity utilization, latency and throughput remain consistent, predictable, and constant. Latency within the array for an I/O request is typically far less than one millisecond (ms). Figure 1 shows an example of the XtremIO dashboard used to monitor performance.

Figure 1.



12

XtremIO Storage Management Application dashboard

Scalability—A single X-Brick is the building block of the XtremIO scale-out architecture. You can cluster multiple X-Bricks together to provide increased performance and capacity. Performance scales linearly to ensure that two X-Bricks supply twice the IOPS and four X-Bricks supply four times the IOPS of the single X-Brick configuration. At the same time, the latency remains consistently low as the system scales out. XtremIO arrays can scale out for any required performance or capacity level, as shown in Figure 2.



Figure 2.

XtremIO all-flash array family



Inline data reduction—The core XtremIO engine implements content-based inline data reduction. XtremIO automatically reduces (deduplicates and compresses) data as the system processes it. This reduces the amount of data written to flash, improving longevity of the media and reducing cost. Volumes are always thin-provisioned without any loss of performance.



Data protection—XtremIO uses a proprietary flash-optimized data protection algorithm, XtremIO Data Protection (XDP), which provides superior data protection while enabling performance that surpasses any existing RAID algorithms. Optimizations in XDP also result in fewer writes to flash media and help increase flash endurance in the array.



Functionality—XtremIO supports high-performance and space-efficient snapshots, inline data reduction, thin provisioning, Data-at-Rest Encryption (D@RE), and full vSphere VAAI integration with support for Fibre Channel (FC) and iSCSI protocols. All of these features were specifically designed for the flash array.



Simplicity—Provisioning storage with XtremIO is as simple as deciding how large a LUN you want to create. You no longer need to select the RAID type, create a RAID group, or decide whether or not to enable thin provisioning, deduplication, or any other data service. These functions are already built into XtremIO.

VMware vSphere XtremIO offers efficient enterprise storage with VMware vSphere cloud infrastructures. vSphere provides complete and robust virtualization. For example, vSphere: 

Virtualizes business-critical applications with dynamic resource pools for unprecedented flexibility and reliability



Transforms the physical resources of a computer by virtualizing the CPU, RAM, hard disk, and network controller. This transformation creates a fully functional virtual machine that runs isolated and encapsulated operating systems and applications. EMC Extreme Performance and Efficiency for Microsoft SQL Server EMC XtremIO, VMware vSphere, and SQL Server 2014 Solution Guide

13


Microsoft SQL Server 2014 Microsoft SQL Server 2014 is the next generation of Microsoft’s information platform, with features that deliver faster performance, expand capabilities both on premises and in the cloud, and provide powerful business insights. SQL Server 2014 offers to organizations the opportunity to efficiently protect, unlock, and scale data across desktops, mobile devices, data centers, and a private, public, or hybrid cloud. SQL Server product groups made sizable investments to improve scalability and performance of the SQL Server database engine component. SQL Server 2014 is used to build mission-critical applications using highperformance, in-memory security technology across OLTP and data warehousing for decision-support systems, business intelligence, analytics services, and so on. You must fully understand these factors and plan accordingly when deploying SQL Server. Note: While SQL Server 2014 was the version used in this solution, the technology supports all versions of SQL Server from 2008 R2 onwards.

SQL Server clustering storage considerations

AlwaysOn Availability Groups (AAGs) is a high availability and disaster recovery feature introduced in SQL Server 2012. This feature requires Windows Server Failover Clustering (WSFC). AAGs are not dependent on SQL Server AlwaysOn FCI. In SQL Server AlwaysOn FCI, the SQL Server database and log files are shared among all the nodes in the cluster, so the storage LUNs hosting these files need to be accessible from all nodes. This means that all LUNs need to be configured and zoned to the nodes in the cluster simultaneously. The specific database and log LUNs can be accessed only from the node actively running the SQL Server instance. While primary and secondary copies of databases do not share storage in AAGs, each node in the cluster needs to have its own storage configured and zoned. The database copy on the secondary node of an AAG can be accessed if it is configured as a “readable copy,” which is independent of the primary copy. This can be used to enable reporting capability on the secondary copy to offload from the primary copy. Figure 3 shows the difference between the AAG and AlwaysOn FCI features.

Figure 3.

14

AlwaysOn FCI versus AAG



SQL Server Data Compression

SQL Server 2014 supports row and page compression for rowstore tables and indexes. In addition to capacity savings, data compression can improve the performance of I/O intensive workloads. This is because as data is compressed, queries require fewer pages to be read from disk. However, extra CPU resources are required on the database server to compress and decompress data.


15

Chapter 3: Solution Architecture

Chapter 3

Solution Architecture

This chapter presents the following topics: Overview ..................................................................................................................17 Architecture diagram ............................................................................................... 17 Hardware resources .................................................................................................18 Software resources ..................................................................................................19

16



Overview The solution provides an optimal cost-to-performance ratio for Microsoft SQL Server mission-critical application environments. The SQL Server 2014 databases are deployed as virtualized databases on an XtremIO storage array consisting of two X-Bricks. The virtualized test/development SQL Server instances in the environment access the XtremIO snapshots of the production database for testing and development purposes.

Architecture diagram Figure 4 shows the logical architecture of this solution.

Figure 4.

Solution architecture


17


The solution architecture includes the following: 

Storage layer—Two X-Bricks in a single XtremIO cluster.



SQL Server database layer—Standalone SQL Server 2014 with five databases and their snapshots that can be mounted to any of the mount hosts at any time, as necessary. We also configured a SQL Server AlwaysOn FCI and an AlwaysOn Availability Group instance in this environment to demonstrate the ease of configuration in the XtremIO environment.



Network layer—108 GB/s of active bandwidth with SAN switches that support virtualized data centers and enterprise clouds.



Physical servers and virtualization layer—A three-server rack that enables a high-performing, consolidated, virtualized SQL Server infrastructure for deployment flexibility without the need to modify the application. The ESXi servers are configured as a VMware vSphere High Availability (HA) cluster.

Our performance tests ran OLTP workloads against the SQL Server databases on these servers.

Hardware resources Table 2 lists the hardware resources used in the solution. Table 2.

Hardware resources

Hardware

Quantity

Configuration

Storage array

1

XtremIO with two X-Bricks as one cluster with a total of 30.4 TB of usable physical capacity

Servers

3

20 Intel E7 2.9 GHz processor cores with 512 GB of RAM, including:  2 x 1 Gb quad Ethernet (GbE) NIC  2 x 10 GbE NICs  2 x 8 GB FC dual-port host bus adapters (HBAs)

18

LAN switches

2

10 GbE, 32-port non-blocking

SAN switches

2

EMC Connectrix DS-6510B enterprise class SAN switch



Software resources Table 3 lists the software resources used in this solution. Table 3.

Software resources

Software

Version

Notes

XtremIO

3.0.1

All-flash storage

VMware vSphere

5.5

Hypervisor that hosts:  Two enterprise-class production virtual machines  Three stand-alone SQL Server virtual machines Each virtual machine is configured with 16 vCPUs and 32 GB of RAM.

VMware vCenter

5.5

vSphere management

Microsoft Windows 2012 R2

SP1

OS for database servers

Microsoft SQL Server 2014

Enterprise Edition CU 4

Database software

EMC AppSync

2.1.0.0

SQL Server VSS integrated, SLA driven snapshot management tool. This tool provides snapshot with database consistency, automated XtremIO snapshot creation, and mounting with multiple recovery options for the snapshot.

EMC Storage Integrator (ESI)

3.6

ESI provides the ability to view, provision, and manage EMC block and file storage in a Windows environment.

PowerPath/VE

5.9.1

EMC storage multipath management

Microsoft OLTP Toolkit

n/a

This toolkit simulates an OLTP workload.


19

Chapter 4: Storage Layer: EMC XtremIO

Chapter 4

Storage Layer: EMC XtremIO

This chapter presents the following topics: Storage design overview .......................................................................................... 21 Database considerations.......................................................................................... 21 Storage design details ............................................................................................. 22

20



Storage design overview XtremIO uses its multi-controller scale-out design and Remote Direct Memory Access (RDMA) fabric to maintain all metadata in memory. This feature makes XtremIO arrays resistant to changes in workload—no matter what LUN sizes you use, whether you use random or sequential access patterns, or whether you use locality of reference—the performance is always consistent and predictable. Database administrators no longer need to worry about hot spots on the array. The need for a careful, painstaking storage design for optimized performance is no longer necessary. For example, disruptive tempdb workloads can co-exist in the same LUN with its write-intensive transaction logs and still provide excellent performance. With built-in thin provisioning, storage is allocated only when it is needed. This enables DBAs to create larger LUNs to accommodate future or unexpected growth for databases, without wasting any physical space on storage. Best of all, heavy metadata operations, such as inline data reduction, thin provisioning allocations, and internal array copy operations, are conducted entirely in memory without impacting I/O operations.

Database considerations Database storage design typically requires free space at all levels of the storage stack, from actual data in databases, to space allocated to data files and log files. If an SQL Server database runs out of data file space, the database instance stops committing any new transactions, and an immediate manual remediation is required to avoid crashing the database and losing data. It is critical that the line of business is not affected. If database file auto growth is enabled, SQL Server automatically allocates additional chunks of disk storage to avoid this database file-full situation. However, that operation usually affects database performance and, if used indiscriminately, can cause repeat fragmentation of data files across disks, which can further impact performance. EMC and SQL Server traditional best practices recommend that you configure SQL Server data file sizes to be 10 to 20 percent larger than the current or intended database size. This configuration requires free space at the New Technology File System (NTFS) volume level, which results in the underlying storage space being locked out without perceivable value until the space is needed. A maintenance window and manual intervention is required if the NTFS volume needs expansion. It is difficult to balance how much free disk space to allocate for the database at the design stage, which will not have an immediate use, as compared to the amount of readily available free space for growth. Figure 5 shows an example of a 1 TB database. The cost and management complexity is compounded multiple times in database environments with multiple database and log files in use across many SQL Server instances. In this example, you have 1 TB of data, but need at least 1.58 TB of allocated storage space to adhere to traditional


21


storage planning best practices. This represents about a 58 percent waste of physical storage allocation for free space. Figure 5 also shows how a 1 TB database can easily use less than 1 TB of physical storage allocation on XtremIO and still satisfy the logical free space required for storage planning.

Figure 5.

XtremIO storage capacity consumption planning

By using thin provisioning (allocation-on-demand) and deduplication/compression with XtremIO, a 1 TB database requires less than 1 TB of allocated physical space. This example assumes 2:1 overall data reduction in XtremIO for a typical OLTP database environment. This eliminates the operational complexities by allocating as much LUN space, virtual file system space and, therefore, NTFS volume space, as required from the start because storage is only allocated on demand.

Storage design details For this solution, we deployed XtremIO in a two X-Brick cluster with XtremIO XDP to provide a physical capacity of 30.4 TB, as shown in Figure 6.

Figure 6.

22

XtremIO Management Application dashboard storage panel



XtremIO processes both random and sequential I/O generated from the database in an equally balanced way across the array. This simplifies the storage design for SQL Server databases compared to traditional provisioning techniques. For this solution, we standardized the volume size for easy deployment, as shown in Table 4. We took advantage of thin provisioning to prevent large volume allocations from wasting physical storage in advance of need, while still providing room for growth when required. Table 4.

Microsoft SQL Server storage design on XtremIO

Volume name

Volume purpose

LUN size

SQL_OS

Microsoft Windows 2012 R2 OS and SQL Server software installation volume, which is used for multiple virtual machines such as VMDK on the same datastore

1 TB

SQL_DB

Microsoft SQL Server database data-file volumes

2 TB

SQL_log

Microsoft SQL Server database log file volumes

500 GB

Tempdb

Microsoft SQL Server tempdb volumes

1 TB

For the production databases, we created and presented volumes for use with the SQL Server virtual machines, as shown in Table 5. Table 5.

Volume assignments for OLTP Databases

Volume

Volume size

Volume type

OS

120 GB

VMDK on OS LUN or VMFS volumes

SQL Server installation and systems databases

120 GB

VMDK on OS LUN or VMFS volumes

SQL Server data

2 TB

Raw device mapping (RDM) or VMDK

SQL Server log

500 GB

RDM or VMDK

Tempdb

1 TB

RDM or VMDK

Note: Performance and availability of either RDM or VMDK volumes are very similar, so either choice is reasonable depending on individual design requirements. Certain technologies, such as WSFC, require RDMs when running in virtual machine clustering (to support SCSI-3 reservations).


23

Chapter 5: Microsoft SQL Server Solution Design

Chapter 5

Microsoft SQL Server Solution Design

This chapter presents the following topics: Overview ..................................................................................................................25 SQL Server database solution storage design .......................................................... 25 SQL Server database solution profile .......................................................................25 SQL Server database solution LUN design................................................................ 26

24



Overview In this solution, we created two virtualized SQL Server 2014 instances with transactional (OLTP) databases on a vSphere HA cluster. This section describes our storage, database profile, and database design.

SQL Server database solution storage design As Table 5 on page 23 shows, we used different database volumes to store the relevant database files, including data files, transaction log files, and tempdb files for the SQL Server 2014 databases. In general, four database LUNs and one log LUN are sufficient for most databases that require high disk performance. Note: With XtremIO, putting all database files for a single SQL Server database into one LUN easily provides over 20,000 IOPS for OLTP workloads with sub-millisecond performance. For maximum performance on a high-workload database, evenly distribute the data files across four XtremIO data volumes. This configuration is sufficient to support a single database with more than 160,000 IOPS in an OLTP environment.

SQL Server database solution profile Table 6 lists transactional (OLTP) database profiles for the solution. Table 6.

SQL Server 2014 OLTP database profiles

Detail

OLTP databases

Database sizes

250 GB- 1TB

Microsoft SQL Server databases

2 x 1 TB, 1 x 250 GB, and 1 x 500 GB, 1x 750 GB

Memory for SQL Server

32 - 320 GB

Workload profiles

 OLTP workload simulated by Microsoft OLTP Toolkit  Read/write ratio of 90/10, 70/30, 60/40

Average data block sizes

8 KB


25


SQL Server database solution LUN design Table 7 lists the database design details in the solution. Table 7.

LUN design details for the SQL Server 2014 OLTP databases

Detail

Instance 1

Instance 2

Database names

DB_01

DB_02

DB_03

Tempdb

DB_04

DB_05

Tempdb

Database file size

250 GB

500 GB

1 TB

400 GB

750 GB

1 TB

400 GB

LUN sizes

4X 500 GB

4X 1 TB

4X 1 TB

1 TB

4X 1 TB

4X 1 TB

1 TB

Log file size

350 GB

250 GB

320 GB

100 GB

250 GB

320 GB

100 GB

Log LUN size

500 GB

500 GB

500 GB

1TB

500GB

500 GB

1TB

Total data and log size

6 TB

Total LUN size

20.5 TB (exclude tempdb)

24.5 TB ( including tempdb)

We also used AppSync to create multiple snapshots of various databases, as shown in Figure 4. These snapshots can be mounted on the SQL Server mount host and be enabled for workloads as well. Note: This design is based on our test workload. In a production environment, database size, especially log file and tempdb sizes, can vary depending on the type of transactions and queries that are running on those databases. All snapshots for databases are indicated as DB_x’ in this document. For example, DB_01’ is a snapshot of database DB_01 that is mounted on the mount host.

26


Chapter 6: Network Layer Best Practices

Chapter 6

Network Layer Best Practices

This chapter presents the following topics: Overview ..................................................................................................................28 SAN network ............................................................................................................28 IP network ................................................................................................................28 VMware vSphere network......................................................................................... 28


27


Overview This section describes the network layer used in this solution for SAN, IP, and ESXi Server network configurations. When deploying a virtualized database solution, such as Microsoft SQL Server, EMC recommends that you ensure both compute and network redundancy at all levels for fault tolerance.

SAN network EMC recommends the following SAN network best practices: 

Use 8 Gb/s FC switches and HBA ports.



Use multiple HBAs on the ESXi servers and at least two SAN switches to provide multiple redundant paths between the server and the XtremIO cluster.



Zone each FC port from the database servers to all ports on the XtremIO X-Bricks for high availability and performance.

IP network EMC recommends the following IP network best practices: 

Use multiple network cards and switches for network redundancy.



Use 10 GbE for network connection, if available.



Use virtual local area networks (VLANs) to logically group devices that are on different network segments or sub-networks.



Enable and configure jumbo frames1 throughout the physical or virtual stack for 10 GbE networks.

VMware vSphere network Networking in virtual environments requires more consideration for traffic segmentation, availability, and throughput, in addition to the best practices recommended in a physical environment. We designed this solution to efficiently manage multiple networks and network adapter redundancy on the ESXi hosts. EMC recommends that you: 

Separate infrastructure traffic from virtual machine traffic for security and isolation



Use the VMXNET3 family of virtual network adapters

1

Maximum Transmission Unit (MTU) sizes of greater than 1,500 bytes are referred to as jumbo frames. Jumbo frames require Gigabit Ethernet across the entire network infrastructure, including servers, switches, and database servers.

28





Aggregate physical network cards for network redundancy and performance. For example, use pairs of physical NICs per server/vSwitches, and uplink each physical NIC to separate physical switches.

For more information on networking with vSphere, refer to the instructions in VMware vSphere Networking.


29

Chapter 7: Physical Servers and Virtualization Layer

Chapter 7

Physical Servers and Virtualization Layer

This chapter presents the following topics: Overview ..................................................................................................................31 Compute and storage resources ...............................................................................31 Network virtualization .............................................................................................. 32 Storage management with ESI .................................................................................32

30



Overview Choosing which server platform to use for your virtualized infrastructure depends on how that platform supports your environment’s technical requirements. In production environments, it is essential that the servers have sufficient: 

Processors and memory to support the required virtual machines and the SQL Server workloads



Ethernet and FC connectivity to enable redundant connectivity to the IP and storage network switches



Capacity to withstand a server failure and support failover of the virtual machines

In this test environment, we configured three physical servers running vSphere ESXi 5.5 as a vSphere HA cluster with five virtual machines: 

Two for virtualized production Microsoft SQL Server databases



Three for test/development instances used to mount various snapshots for repurposing

Compute and storage resources EMC recommends that you implement the following VMware compute resource best practices, as explained in the Microsoft SQL Server Databases on VMware Best Practices Guide: 

Use Non-Uniform Memory Access (NUMA) on the ESXi servers, a computer architecture in which memory located closer to a particular processor is accessed with less delay than memory located farther from that processor.



Allocate virtual machine memory (vRAM) in a virtual machine to be less than or equal to the local memory accessed by the NUMA node (processor).



Install VMware Tools, including several utilities that enhance the performance of the virtual machine's guest operating system and improve management of the virtual machine.



Configure the virtual machine memory reservations to be, at a minimum, the size of the SQL Server and operating system overhead.



SQL Server only supports RDM for clustering, so use RDM in ESXi virtual machines for database and log files that must fail over in an MSCS clustering environment.



Configure multiple paravirtualized SCSI (PVSCSI) controllers for the database volumes. Using multiple virtual SCSI controllers enables the execution of several parallel I/O operations within the guest operating system.


31


Network virtualization On each ESXi server, we created two standard vSwitches with a common configuration, as described in Table 8. Table 8.

vSwitch configuration

Name

Purpose

vSwitch0

Manages public virtual machine traffic

vSwitch1

Enables fault-tolerant configuration for Microsoft SQL Server Cluster interconnect traffic

We assigned each virtual machine two vNICs (1 GbE and 10 GbE) using the high performance VMXNET3 driver. We mapped the 1 GbE vNIC to vSwitch0 for public traffic and the 10 GbE vNIC to vSwitch1 for SQL Server interconnect traffic.

Storage management with ESI EMC Storage Integrator (ESI) provides a graphical user interface (GUI), allowing you to manage EMC storage through a single management interface. With ESI, you can perform daily management tasks with fewer clicks and higher productivity. For more information about ESI, refer to the EMC ESI documentation on support.EMC.com.

32


Chapter 8: Design Considerations

Chapter 8

Design Considerations

This chapter presents the following topics: Overview ..................................................................................................... 34 XtremIO configuration best practices............................................................... 34 Configuring XtremIO storage for SQL Server ..................................................... 38 Creating and mounting a snapshot using AppSync ............................................ 42


33


Overview XtremIO makes it possible to run extremely high I/O loads on a single storage system. With the XtremIO balanced architecture combined with performance, inline data reduction, and virtually provisioned storage, many of the fine-tuning and configuration practices for traditional storage arrays are no longer required. To take full advantage of the high throughput that XtremIO storage provides, you must design the entire connectivity stack to reach extreme performance. From optimizing queue depths on hosts to the number of available FC paths, your configuration must enable the system to deliver the I/O enabled by XtremIO. You can also use EMC AppSync to create and manage application-consistent copies of SQL Server databases. This section describes how to create and mount a snapshot using AppSync.

XtremIO configuration best practices Configuring Fibre Channel switches

For an XtremIO dual X-Brick cluster, a host can have up to eight paths for each device. Figure 6 shows the logical connection schemes for eight paths.

Figure 7.

XtremIO dual X-Brick FC switch configuration

Note: You can use EMC Virtual Storage Integrator (VSI) Path Management to configure path management across EMC systems, including XtremIO. Refer to the EMC VSI Path Management Product Guide for more information on using this VMware vSphere client plugin.

Configuring servers

To optimize performance to extreme levels, you must configure the hosts accessing the XtremIO storage array to enable higher I/O throughout instead of using the default settings. Cisco UCS server configuration Most server default HBA throttle settings are not optimized for the high throughput that a flash array provides. To avoid limiting the I/O throttle, you must choose the highest throttle setting for the server.

34



To adjust the HBA I/O throttle setting for the Cisco UCS HBA using Cisco’s UCSM navigation tool: 1.

Select Server > Inventory.

2.

Select Cisco VIC Adapters.

3.

Select vHBAs > Properties.

4.

Set I/O Throttle Count to 1024, as shown in Figure 8.

Figure 8.

Changing the I/O Throttle Count setting for Cisco UCS Server

ESXi Server configuration You can use ESI to automatically configure an ESXi Server for XtremIO storage, or you can use vSphere 5.5 to manually configure the ESXi host for XtremIO storage using the following steps: 1.

Use the ESXi command-line interface to adjust the HBA queue depth. The queue depth setting controls the amount of outstanding I/O requests for each path. To optimize XtremIO storage, consult the HBA and server vendor recommendations. As a rule, set the queue depth to the highest value allowed by the HBA manufacturer (for example, 256). Note: For more information about adjusting HBA queue depth with ESXi, refer to VMware KB article 1267 on the VMware website.

2.

Set SchedQuantum to 64 and DiskMaxIOSize to 4096: esxcfg-advcfg -s 64 /Disk/SchedQuantum esxcfg-advcfg -s 4096 /Disk/DiskMaxIOSize


35


3.

Locate the Network Address Authority (NAA) for the XtremIO LUNs that are presented to the ESXi host and the NAA of the XtremIO volume using the following command: esxcli storage nmp path list | grep XtremIO -B1

4.

Set SchedNumReqOutstanding for the device to its maximum value (256) using the following command: esxcli storage core device set -d naa.xxx -O 256

Configuring vSphere Native Multipathing

XtremIO supports VMware vSphere’s Native Multipathing (NMP) technology. For best performance, EMC recommends that you automatically configure native vSphere multipathing for XtremIO volumes with ESI, or manually as follows: 1.

Set the native round-robin path selection policy on XtremIO volumes that are presented to the ESXi host.

2.

Use the ESXi command line interface (CLI) to set the vSphere NMP roundrobin path switching frequency for XtremIO volumes from the default value (1,000 I/O packets) to 1.

These settings ensure optimal distribution and availability of load between I/O paths to XtremIO storage. EMC PowerPath®/VE for ESXi manages XtremIO devices as generic. You must enable generic loadable array module (LAM) support for PowerPath/VE to recognize and manage XtremIO devices. You can also use EMC VSI for XtremIO for the NMP roundrobin configuration. Native path management with the vCenter GUI On each virtual machine, you can add the LUNs for database storage from the XtremIO array as RDM disks and spread them across four PVSCSI controllers to balance I/O. You can also configure the LUNs for the OS and SQL Server software installations as VMDK to enable low I/O storage LUNs to share the same volume on XtremIO. If they are not managed by PowerPath, you must configure the I/O intensive database LUNs as Round Robin (VMware) in Path Management, as shown in Figure 9.

36



Figure 9.

Storage device path management configuration

PowerPath/VE installation You can install PowerPath/VE using the VMware remote vCLI, VMware vSphere Update Manager, or VMware vSphere Auto Deploy. To install PowerPath/VE, use remote vCLI to complete the following steps: 1.

Download the PowerPath/VE software from support.emc.com.

2.

Use the scp (secure copy) command to copy the PowerPath/VE offline package to the vSphere host.

3.

At the ESXi command line prompt, enter the following command: # esxcli -s software vib install -d

4.

Change the vSphere host to Maintenance mode and restart the vSphere host.

5.

Verify that PowerPath/VE is installed using the following command: # esxcli -s software vib list

6.

Confirm that PowerPath is managing the XtremIO devices. In the vCenter host, select Configuration > Storage, as shown in Figure 10. The Owner column shows that the devices have a PowerPath owner.


37


Figure 10. XtremIO SSD LUN under PowerPath management

Placing XtremIO devices under PowerPath’s control

Figure 10 shows LUNs that are not PowerPath LUNs. You can enable PowerPath by entering the following commands and then rebooting: 1.

esxcli storage core claimrule add —rule 340 —plugin PowerPath –-type vendor --vendor XtremIO --model XtremApp

2.

esxcli storage core claimrule load

3.

esxcli storage core claimrule run

PowerPath/VE 5.9 SP1 provides native LAM support for XtremIO flash array devices. Note: For PowerPath/VE installation and configuration for vSphere, refer to EMC PowerPath/VE Installation and Administration Guide. For FC multipathing configuration, refer to vSphere Storage ESXi 5.5 documentation.

Configuring XtremIO storage for SQL Server using ESI You can use ESI to create and manage storage LUNs for XtremIO with SQL Server databases in both physical and virtual environments. For vSphere and vCenter virtual machines, you can create VMDK files and RDM disks with or without virtual compatibility mode. You can also create SCSI disks and view datastores. SCSI disks require the use of existing SCSI controllers. The ESI SQL Server Adapter enables you to view local and remote SQL Server instances and databases and map the databases to EMC storage. ESI supports the AlwaysOn feature in SQL Server 2012 and SQL Server 2014, which enables you to

38



view the primary SQL Server replica and up to four secondary replicas. You can use SQL Scripts to create and configure SQL Server databases from an ESI host. Provisioning XtremIO

To add XtremIO storage system(s) using ESI: 1.

Create a storage device for the virtual machine with an RDM or a VMDK.

2.

Add and define your XtremIO storage array, as shown in Figure 11, and click Add.

Figure 11. Setting up XtremIO in ESI


39


3.

Click Create Volumes, as shown in Figure 12, and provide your LUN information.

Figure 12. Creating a new XtremIO volume in ESI

4.

Click Storage Pools to view the total capacity for an XtremIO array, as shown in Figure 13. Because XtremIO does not use storage pools, all XtremIO devices appear as thin-provisioned devices.

Figure 13. Viewing XtremIO storage capacity in ESI

5.

40

Click Initiator Groups to view the initiators from the host, which are mapped to volumes, as shown in Figure 14. XtremIO Initiator Groups are similar to storage groups.



Figure 14. Viewing XtremIO storage groups in ESI

6.

Click Masking Views to view the XtremIO volume mappings, as shown in Figure 15.

Figure 15. XtremIO volume mappings in ESI

7.

Click Connect Disk to create and connect an RDM disk to a specific SQL Server virtual machine for database storage, as shown in Figure 16.


41


Figure 16. Assigning an RDM to SQL Server for database storage in ESI

You can now format XtremIO storage in the virtual machine and use it for SQL Server storage. ESI automatically configures multipathing during the ESXi server configuration process.

Creating and mounting a snapshot using AppSync You can use AppSync to create and manage application-consistent copies of Microsoft SQL Server databases. AppSync supports the following features for SQL Server: 

AlwaysOn Availability Groups (AAGs)



Dynamic discovery of user databases during the service plan run



SQL Server databases on physical hosts, RDMs in physical compatibility mode, and virtual disks on virtual hosts Note: AppSync does not support RDM disks in virtual mode.

Creating a snapshot of an existing SQL Server database with AppSync

42



Data protection of stand-alone and clustered production SQL Server instances



Mounting on stand-alone servers or cluster nodes of alternate clusters, production clusters as non-clustered resources, and mounting with recoveries on non-clustered instances

To configure XtremIO with AppSync, first install and start AppSync, and then complete the following steps: 1.

Add the XtremIO Management Server and type your administrator credentials, as shown in Figure 17.



Figure 17.

2.

Adding XtremIO to AppSync

Configure the SQL Server virtual machine as the Windows host server, as shown in Figure 18.

Figure 18. Configuring SQL Server in AppSync

3.

Add the vCenter Server.

4.

Choose the database and select the applicable protection plan to create the snapshot for the database, as shown in Figure 19.


43


Figure 19. Selecting the database and the protection plan for the snapshot

5.

Confirm that you have successfully created the snapshots, as shown in Figure 20.

Figure 20. XtremIO snapshots created with AppSync

44



Mounting a snapshot of a SQL Server database with AppSync

To mount a SQL Server database snapshot using AppSync: 1.

In the Select Mount Options, select Mount and recover copy, as shown in Figure 21.

Figure 21. Selecting SQL Server mount copy options

This step enables AppSync to use snapshots to run read/write workloads on the mount host. Figure 22 shows a mounted snapshot that is ready for read/write operations for a recovered database copy.

Figure 22. Mounted snapshot ready for read/write operation on the recovered database copy

2.

Recover the database copy with the mount snapshot from step 1 and use it on the mount host for database read/write operations to support the AlwaysOn SQL Server feature, as shown in Figure 23.


45


Figure 23. Mounted database recovered as a read/write copy ready for database operations

You can now use the snapshot for read and write operations.

46


Chapter 9: Performance Testing and Validation

Chapter 9

Performance Testing and Validation

This chapter presents the following topics: Overview ..................................................................................................................48 OLTP workload performance and scale test .............................................................. 49 XtremIO data reduction analysis ..............................................................................54 SQL Server Failover Clustering on VMware setup and analysis.................................59


47


Overview The performance and scalability tests in this section highlight how XtremIO easily services enterprise workloads while all elements, including storage, stay within the “green zone,” which is an area of utilization and latency that is healthy and sustainable for production workloads. For these tests, we:

Notes on results



Generated the OLTP workloads using a Microsoft Toolkit application, which simulates realistic OLTP workloads



Collected the system I/O performance metrics, including IOPS, transactions per second (TPS), and latency, at the server/database and storage levels.



Ran all tests on a dual-brick XtremIO system configured according to best practices

Test results are highly dependent on workload, specific application requirements, and system design and implementation. Relative system performance will vary because of these and other factors. Therefore, you should not use this workload as a substitute for a specific customer application benchmarks for critical capacity planning and product evaluation decisions. We obtained all performance data contained in this report in a rigorously controlled environment. Results obtained in other operating environments may vary significantly. EMC does not warrant or represent that a user can or will achieve similar performance expressed in transactions per second.

Test objectives

The test objectives demonstrate: 

Performance and Scale In these series of tests, we measured SQL Server 2014 overall performance and scalability servicing common OLTP workloads with varying degrees of I/O profiles. We also compared two common storage configuration options available in a VMware environment and its performance impact on SQL server transactions.



Data Reduction One of the most impressive capabilities of XtremIO storage is its inline data reduction features. While very compelling in many cases, we address several aspects of data reduction as it applies to SQL Server environments.



SQL Server AlwaysOn FCI support XtremIO is able to support environments that require the protection of SQL Server AlwaysOn FCI.

Test scenarios

48

We tested the following use cases: 

OLTP workload performance test



VMDK vs RDM performance for SQL Server





System with XtremIO snapshot performance test



An XtremIO data reduction analysis in this solution’s SQL Server environment

The following sections describe these use cases.

OLTP workload performance and scale test The objective of this test was to measure SQL Server 2014 overall performance and scalability servicing common OLTP workloads with varying I/O profiles. This simulates a wide spectrum of high-volume, online transactional workloads observed with financial services systems, online gaming, e-commerce solutions, and more. The main metrics measured were read and write I/O latencies, aggregated throughput in IOPS, and SQL Service transactions per second. We used an OLTP workload performance test to measure the performance of the whole environment with SQL Server 2014 database workloads. This test also demonstrated how an XtremIO system can accommodate growing database workloads and continue to provide stable performance. Test methodology

We used the Microsoft OLTP Toolkit to generate an OLTP workload to drive high physical random I/O to the databases. To measure performance statistics, we ran a fixed number of concurrent users for each database with the same set of OLTP queries simultaneously against all SQL Server databases in the environment. Controlling the number of concurrent users ensured that we generated a specific level of IOPS.

Test procedure

We ran an OLTP workload for the first database and recorded the system performance after the workload stabilized. We then added a workload to a second database while the previous workload was still running, recording system performance after the workload stabilized. We continued adding workloads until all databases were running with a stabilized workload and the overall system performance was recorded. Table 9 shows the test load sequence. For details about the database profile and configuration, refer to Table 5. Table 9.

Test workload sequence

Workload sequence

Database name

Database size

Workload (no. of users/maximum transaction rate)

Read/write ratio

1

DB_01

250 GB

10/200

90/10

2

DB_02

500 GB

10/200

90/10

3

DB_03

1 TB

20/200

90/10

4

DB_04

750 GB

20/200

90/10

5

DB_05

1 TB

20/200

90/10

6

DB_01’

250 GB

10/200

90/10


49


Test results

Workload sequence

Database name

Database size

Workload (no. of users/maximum transaction rate)

Read/write ratio

7

DB_04’

1 TB

20/200

90/10

Overall, the average latency remained low for the XtremIO array, while the added SQL Server database workloads generated more I/O. The entire system generated over 135,000 TPS with an average of 300,000 IOPS when all database workloads were added and stabilized. The array latency remained at approximately 1 ms for the XtremIO system and the host’s average disk latency ranged from less than 1 ms up to 1.5 ms.

Figure 24.

50

SQL Server and XtremIO scalability test



XtremIO system performance

XtremIO provided extremely high IOPS and throughput with very low latency and a high overall SQL Server transaction rate, as shown in Figure 25.

Figure 25.

XtremIO Performance with full OLTP work load on SQL Server 2014

SQL Server 2014 disk I/O performance By following best practices for SQL Server data and log file response times, the test results easily proved better than the standard data-file disk latency of 4 to 20 ms for database data files (ideal is less than 10 ms) and 1 to 5 ms for log files (ideal is less than 1 ms). These tests achieved latency much less than or around 1 ms, which is considered ideal based on industry standards. As shown in Figure 26, the production SQL Server databases running on XtremIO and VMware vSphere reached an IOPS of 200,000 while both SQL Server 2014 data and log files continued to maintain close to 1 ms response times with a maximum response time of 1.5 ms.

Figure 26. SQL Server 2014 disk I/O performance

Figure 26 shows very low latency for database data and log files as we scale up the workload.


51


XtremIO and SQL Server OLTP read/write workloads

In addition, we tested SQL Server 2014 database DB_01 (250 GB), varying the read/write ratio of the workload. As shown in Figure 27, we started with a 60/40 read/write ratio OLTP workload. This workload achieved over 65,000 TPS with 25,000 IOPS. We varied the workload profile to produce two additional test steps, including a 70/30 and 90/10 read/write ratio OLTP workload. For all steps, the average SQL Server data read and write latencies were kept to less than 1 ms.

Figure 27.

SQL Server 2014 database transactional performance

Overall, XtremIO and SQL Server 2014 maintained excellent performance with sub millisecond latency and high transaction rates for all three read/write test scenarios. VMDK and RDM performance comparison

Storage is one of the most important components when building an infrastructure for business critical applications and for databases in particular. Since this is a virtualized environment, a performance comparison has been conducted to compare two common storage presentation types in VMware: VMFS disk (VMDK) and Physical Raw Device Mapping (RDM). This test measured the performance difference between the SQL Server 2014 database OLTP workloads on VMDK and the RDM LUNs from XtremIO. This test showed that an XtremIO system delivers sustained workloads for both LUN types with similar performance on both.

Test methodology

We used the Microsoft OLTP Toolkit to generate an OLTP workload to drive high physical random I/O to a database. We ran a fixed number of concurrent users for each database with the same set of OLTP queries for each database and then measured the performance statistics. Controlling the number of concurrent users and transactions ensured that we generated a specific level of workload.

52



Test procedure

The test ran with a single 250 GB database workload. We ran the test for an hour to stabilize the workload. VMDK can only be used in stand-alone SQL Server instances, while RDM can support both stand-alone and clustered SQL server instances.

Test results

The XtremIO array can sufficiently support both VMDK and RDM LUNs in a vSphere environment. As shown in Figure 28, the IOPS is similar for the same workload on both VMDK and RDM.

Figure 28. IOPS for the same workload against RDM and VMDK

The system latency is similar for the two different disk types, with RDM showing a slightly higher latency on the SQL Server. The difference is within a normal test deviation and is not significant, as shown in Figure 29.

Figure 29. SQL Server and XtremIO latency with RDM and VMDK


53


XtremIO data reduction analysis XtremIO's data deduplication and data compression methods complement each other. Data deduplication reduces physical data by eliminating redundant data blocks, and data compression further reduces the data footprint by eliminating data redundancy within the binary level of each data block. A series of tests were performed to determine the average compression ratio of SQL Server in our environment and its impact on throughput and latency of the production instance. In this test, we observed the data reduction resulting from deduplication and snapshots with XtremIO on the SQL Server OLTP database. Snapshot data reduction

There are many use cases for creating multiple copies of SQL Server databases, such as developing/testing, recovering from data corruption, or off-load processing. In this test, we used AppSync to automatically create multiple snapshot copies of the production databases, mount to the mount host, and recover them. We measured the performance impact and overall data reduction. XtremIO Snapshot storage data reduction With XtremIO, you can sustain a logical capacity that exceeds, by a large margin, the physical flash capacity in the system, as shown in Figure 30. In this test, the effective space of the volumes created on XtremIO for production database and log files is 20.5 TB, as detailed in Table 5. After we created five snapshots for each database, the addressable logical volume capacity increased by 102.5 TB. This 102.5 TB is composed of snapshots that can be accessed for primarily read intense workloads, operational recovery, and destructive data repurposing such as test/dev. The SQL Server database data reduction rate as per the XtremIO GUI refers to production volumes only (not snapshots), so the ratio remained 1.8:1. The initial amount of physical storage required for snapshots in an XtremIO array is negligible (about 1 percent of the parent volume), as shown in Figure 30.

54



Figure 30.

Production database data reduction rate

XtremIO snapshot data efficiency

With data reduction, the XtremIO effective system capacity can expand beyond the physical capacity. In environments that contain data with a significant amount of duplication, the effective logical capacity of XtremIO can be much higher than its physical flash capacity. The SQL Server production database (not counting replications, such as databases or snapshots, or a restored database to the same array) would not typically benefit from deduplication. The compression ratio witnessed in the tests ranged from 1.4:1 to 2:1, depending on the data in the SQL Server data mix. The average data reduction ratio observed in SQL Server environments is around 2:1, not counting the snapshot data reduction effect.

SQL Server AAGs provide a powerful capability called active secondary replicas. XtremIO Data reduction with SQL Directing read-only connections to readable secondary replicas provides: Server AlwaysOn  Offloading of various workloads from primary database-like real-time analytics Availability Groups  Live reporting 

Scaling out transactions

In this test, we created a secondary AlwaysOn replica to measure the potential space savings of managing multiple live copies of the production instance with the capability to identify redundant blocks replicated by AlwaysOn on the same system. When we created SQL Server AlwaysOn AAG secondary copies on the same array as the production database, we observed minimal impact on the XtremIO physical storage. We created the AAG secondary copy of a 1 TB database by restoring to a


55


different volume on the same array. Figure 31shows the deduplication ratio and physical space used before and after creating the AAG.

Figure 31.

Deduplication ratio and physical space used before and after creating the AAG

There was no additional physical space required for the initial AAG creation, as shown in Figure 31. The deduplication ratio reflects the full AAG environment. As shown in Figure 32, we simulated 24 hours of OLTP activity on the SQL Server database to determine the physical space requirements over time for a newly created AAG.

Figure 32. Volume and physical space used for SQL Server AAG instance

56



We used SQL Server bulk insert to introduce 250 GB of data into the production database. This changed the production database, which allowed us to observe the impact of secondary database storage needs. Figure 33 shows the space savings from a bulk insert data loading test on a standalone database as compared to the same test on an AAG instance. For both tests, we shrunk the data files to maximize the volume capacity.

450

27% space savings

400 350

13% space savings

GB

300 250 200 150 100 50 0 AAG select insert XtremIO volume capacity increase delta~

Bulk insert select (no AAG) XtremIO physical capacity increase delta~

Figure 33. XtremIO physical storage usage during a bulk insert

Overall, the SQL Server 2014 AAG on XtremIO test demonstrated excellent capacity and efficiency with no additional physical space required for initial AAG creation. Depending on workload characteristics, careful planning should be carried out to determine physical space requirements over time. SQL Server row and page compression on XtremIO

This test measured the space savings benefits and overall performance impact of using the native capabilities of SQL Server row and page compression for rowstore tables and indexes and its impact on the host CPU utilization and the impact, if any, on the volume managed by XtremIO. XtremIO compression and deduplication is always on with no impact to database performance. SQL Server compression needs to be explicitly enabled. Before enabling SQL Server compression, it is important to evaluate the impact on database performance. The database server requires additional CPU resources, as pages are compressed and decompressed in memory. SQL Server compression aims to efficiently store data by compressing it and performing deduplication on rows within a single page. XtremIO compression and deduplication work across all database pages for the entire array. Both methods might offer gains and complement each other on the data in your environment.


57


Test methodology

All of the tests were performed in the same single, 250 GB database. For each step, we used a fixed number of concurrent users and transaction rates to generate a controlled specific level of workload for the OLTP database.

Test procedure

We ran an SQL Server workload to generate a baseline. Next, we implemented SQL Server row compression and page compression and ran a workload. Finally, we ran an SQL Server shrink file to reclaim space on the server side and run a workload to test performance with the SQL Server database indexes heavily fragmented. For each step, we measured the database size and collected performance data.

Figure 34. Space savings from SQL Server native compression

Test results

In each case, XtremIO’s inline compression and deduplication is always on. In addition, the XtremIO array maintains consistent sub millisecond latency regardless of the type of compression used by SQL Server. Even after running the SQL Server shrink file operation, we experienced no performance degradation on the XtremIO AllFlash array, as shown in Figure 34. In this test, implementing SQL Server compression complemented XtremIO’s efficiency and performance, resulting in improved overall database transaction rates. However, unlike XtremIO, SQL Server compression and decompression operations increase CPU utilization at the host level, as shown in Figure 35.

58



Figure 35. Performance improvement from SQL Server compression and CPU usage change

SQL Server Failover Clustering on VMware setup and analysis To validate SQL Server AlwaysOn FCI on XtremIO with vSphere 5.5, we set up a cluster across two physical machines. We then tested the cluster using a workload derived from an industry standard modern OLTP benchmark. LUN setup

vSphere 5.5 support for failover clusters configured across physical machines requires that you set up LUNs with the LSI Logic SAS Virtual SCSI Adapter and as pass-through RDM disks (physical compatibility mode). Supported configurations depend on the cluster implementation. Table 10 provides the supported configurations for this solution. For setup details, refer to the VMware document entitled Setup for Failover Clustering and Microsoft Cluster Service ESXi 5.5. Table 10.

VMware support for failover clusters

Storage type

Clusters on one physical machine (cluster in a box)

Clusters across physical machines (cluster across boxes)

Clusters of physical and virtual machines (standby host clustering)

Virtual disks

Yes (recommended)

No

No

Pass-through RDM (physical compatibility mode)

No

Yes (recommended)

Yes

No pass-through RDM (virtual compatibility mode)

Yes

Yes

No


59


To add a LUN to an FCI in vSphere: 1.

2.

Configure the XtremIO LUN as an RDM disk for the first node in the cluster: a.

Add a hard disk. Save the LUN mapping on the virtual machine’s datastore and on XtremIO.

b.

Choose physical compatibility mode, as shown in Figure 36.

c.

Configure the SCSI driver used as an LSI Logic controller (default); do not use SCSI 0, as shown in Figure 36. Change the LSI Logic controller’s SCSI bus sharing to physical.

d.

Note the SCSCI node ID, which is required when provisioning the second node.

Configure the same LUN to the second node in the cluster, as shown in Figure 36: a.

Add a hard disk using an existing virtual disk. Browse to select the location of the disk created on the first node.

b.

Choose the virtual device node based on the same SCSI node ID as the first node in the cluster.

c.

Confirm that the SCSI driver type is LSI Logic and change the SCSI bus sharing to physical.

Figure 36. VMware virtual machine disk configuration for an AlwaysOn FCI

60



3.

Cluster setup validation

Add all SQL Server disks to the cluster, so that they are available to the SQL Server cluster.

Once we completed the SQL Server cluster installation, we validated failover and failback between the nodes. Finally, we used the Microsoft Toolkit to generate an OLTP workload to drive high physical random I/O from a database platform. As shown in Figure 37, the workload achieved over 18,000 IOPS with a CPU utilization average of 55 percent.

Figure 37. XtremIO and SQL Server OLTP performance with an AlwaysOn FCI on vSphere 5.5


61

Chapter 10: Conclusion

Chapter 10 Conclusion

This chapter presents the following topics: Summary..................................................................................................................63 Findings ...................................................................................................................63

62


Chapter 10: Conclusion

Summary This solution demonstrates the tremendous value of XtremIO shared storage for SQL Server. XtremIO offers a scalable, extremely efficient storage solution for a consolidated SQL Server environment that customers can use for various OLTP workloads. XtremIO storage can keep pace with linear scaling on the host. XtremIO N-way, active/active, scale-out architecture linearly scales capacity, creates extremely high IOPS or throughput, and maintains extremely low latency. When you add additional compute resources, including CPU, memory, HBA ports, and front-end port resources to the servers, the system can provide higher IOPS for OLTP environments. This solution achieves efficient resource utilization through virtualization while providing high database performance. You can easily increase the capacity and processing capability as necessary. As business needs change, this solution stack can align with the shifting demands from any level—from applications, database software, and non-database software. In turn, multiple new workload approaches, such as real time analytics, are easily possible, with the consolidation of production and reporting instances. Best of all, snapshots are created instantly and can be used for any purpose. Adding or removing a snapshot is cost-efficient.

Findings This solution provides the following advantages: 

This solution is fast and simple to implement with little to no storage tuning. XtremIO works as seamlessly in virtualized SQL Server environments as in physical ones. With ESI, the configuration for XtremIO is further simplified and is easy to manage and monitor in a single user interface.



XtremIO supports the most demanding transactional SQL Server 2014 workloads, with throughput that can easily exceed 300,000 IOPS for a dual X-Brick system while maintaining near average sub-millisecond latencies.



XtremIO inline compression works with or without SQL Server native compression to save physical storage while still offering the best performance with substantial storage savings.



This solution reduces the storage footprint by using XtremIO inline data reduction and snapshots.



This solution provides close to real-time, high-performance copies of data using XtremIO snapshot technology at no measurable initial cost, while providing near-instant recovery of production data, even in TBs of data scale.



XtremIO supports both SQL Server AlwaysOn FCI and AlwaysOn AAGs.


63

Chapter 11: References

Chapter 11 References

This chapter presents the following topics: EMC documentation .................................................................................................65 VMware documentation ........................................................................................... 65 Microsoft SQL Server documentation .......................................................................65

64


Chapter 11: References

EMC documentation The following documents are available on EMC.com or EMC Online Support. Access to EMC Online Support depends on your login credentials. If you do not have access to a document, contact your EMC representative. 

Introduction to the EMC XtremIO All-Flash Array White Paper



EMC VSI Path Management Product Guide



EMC XtremIO Storage Array User Guide



EMC XtremIO System Specifications



EMC Storage Integrator 3.6 for Windows Suite Release Notes



XtremIO Data at Rest Encryption White Paper



Introduction to XtremIO Snapshots White Paper

VMware documentation The following documents, available on the VMware website, provide more information: 

Microsoft SQL Server Databases on VMware Best Practices Guide



VMware vSphere Networking



VMware ESXi Scalable Storage Performance

Microsoft SQL Server documentation The following documents, available on the Microsoft website, provide more information: 

Pre-Configuration Database Optimizations



Microsoft SQL Server Best Practices


65