3PAR Utility Storage in a Microsoft SQL Server Environment · Manageability and Performance...

Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment

3PAR AND MICROSOFT WHITE PAPER2009


2

Table of ContentsSummary 3

Introduction 3

Challenges Configuring a Database Application 3

Database Application Performance 4

Resource Utilization 4

Storage Provisioning 4

Customer Scenario and Solutions Used 4

Test Objective 5

Creation of the OLTP Test Database 6

SQL Server and 3PAR Storage Test Results 7

Introduction 7

Test 1 Results — Massive Parallelization through Wide Striping 7

Test 2 Results — RAID 1 Performance with Variable Volumes and Files 8

Test 3 Results — RAID 5 versus RAID 1 10

Test 4 Results — Thin Provisioning Performance and SQL Server 14

Test 5 Results — Mixed Workload 16

Test 5a: Mixed-Workload Only 16

Test 5b: Mixed-Workload and Massive-Parallelization 18

Conclusion 19

High Performance 19

High Resource Utilization 19

Reduced Storage Provisioning and Management Costs 20

About 3PAR 20

Appendix A 21

Test Configuration Details 21


3

Summary

Information technology specialists are increasingly challenged to provide high performing, complex

database systems while simultaneously managing the costs of ever-growing storage demands. A

storage management system that provides optimal and highly predictable performance of OLTP

and mixed workload environments while liberating the organization from complex configuration

changes is the ultimate goal. This paper summarizes tests performed for a joint Microsoft and

3PAR customer who wanted to better understand the benefits of new storage technologies in its

environment. 3PAR and Microsoft worked collaboratively to assist the customer with reducing

capital and administrative costs while maintaining optimal performance running an OLTP workload

on Microsoft SQL Server 2008® Enterprise Edition and a 3PAR® InServ Storage Server.

IntroductIon

This white paper examines the challenges of managing complex data systems and investigates

ways to optimize those configurations for both performance and simplicity. A SQL Server 2008

customer requested that tests be performed on Microsoft SQL Server and 3PAR Utility Storage

to explore the ability to manage complex data systems while maintaining high performance with

minimal administrative costs. This white paper documents the results of these tests and provides

several examples for optimizing configurations for SQL Server® OLTP applications running on the

3PAR InServ® Storage Server.

The increasing challenges to managing and maintaining storage are intrinsic to the growing size

and complexity of SQL Server database applications. The test results discussed in this paper

help to demonstrate the strong performance, high storage efficiency and simple management

achievable when combining features from SQL Server 2008 and 3PAR Utility Storage for a given

customer environment.

The tests presented throughout this paper were performed by Microsoft at the customer’s request, in

consultation with 3PAR, to assist with determining a configuration that would help the customer to

reduce costs—both in terms of manageability and resource utilization—as well as helping maintain

a high level of predictable performance while handling large SQL Server workloads.

challengeS confIgurIng a databaSe applIcatIon

The advent of more demanding database applications combined with requirements to retain data

for longer periods of time has contributed to the growth of large, complex database application

systems. Database and system administrators are challenged to maintain high-performing

databases efficiently and cost effectively, even as the data grows and matures. Meanwhile, storage

administrators must manage the corresponding ever-growing storage environment in which

they are asked to quickly respond to business demands and to optimize the utilization of their

storage resources.

The concepts associated with managing a dynamic and high performing database system are well

known. Examples of the decisions that must be made when deploying a database include the

number and placement of database files, the isolation of database files on the backend storage

system, and the size of the storage volumes. Each of these decisions has an associated cost, whether


4

it is adding administrative overhead to accelerate new deployments or optimizing the data layout

on the underlying storage to improve performance.

When deploying a SQL Server database application and an enterprise-class storage system, IT

administrators must find a way to overcome the following common challenges of database tuning,

storage provisioning and resource utilization:

database application performance

Tuning a database application to scale with predictable levels of performance is not a trivial exercise

when the storage subsystem must respond to a multitude of differing workloads. Application

performance can suffer when poor decisions are made about data placement or when data growth

results in files with differing workloads competing for the same computing resources. Planning

miscalculations can result in inconsistent performance when data volumes are overutilized or

underutilized. As a result of these complexities, the time and money spent tracking and managing

the performance across the datacenter can escalate unless an easier process is introduced.

resource utilization

When building a database application, the database administrator (DBA) must estimate a database’s

growth rate and predict its final size in a year or more. As a result, storage is often purchased up-

front to satisfy the projected growth, even though most of the storage capacity is not used initially.

These practices often lead to the underutilization of purchased storage resources. Poor utilization

forces companies to unnecessarily spend resources powering, cooling, and administering unused

storage resources. A more desirable outcome is to postpone the purchase of storage required for

future data growth until it is actually needed to store new, written data.

Storage provisioning

Complex database applications are frequently comprised of tens of database files that must be

mapped to multiple volumes on a large storage system. The DBA must decide which storage volumes

to place the database files onto while keeping both performance and future growth in mind. To

make these decisions, administrators usually follow a complex process in order to map the disks to

the individual volumes and assign them to specific files, a process which often leads to human error.

File growth or the inclusion of additional database files can introduce further complexity. If not

managed correctly, ongoing growth can result in misbalanced IO and performance degradation, or

the growth may require the movement of large chunks of data.

cuStomer ScenarIo and SolutIonS uSed

The customer scenario reviewed in this paper is a SQL Server OLTP application deployed on a

3PAR InServ Storage Server.

Microsoft SQL Server 2008.• Microsoft SQL Server 2008 is an intelligent data platform

that enables you to run your most demanding mission-critical applications, reduce time

and cost of development and management of applications, and deliver actionable insight to

your entire organization. Microsoft SQL Server leverages the capabilities of enterprise SAN


5

storage such as 3PAR to help reduce the management requirements of an organization’s

database storage as well as reduced capital costs.

3PAR InServ Storage Servers.• 3PAR Utility Storage is a category of next-generation

storage arrays built for utility computing. 3PAR offers a virtualized, tiered-storage array

designed to help customers reduce the costs of allocated capacity, administration, and

SAN infrastructure while increasing adaptability and resiliency. 3PAR’s autonomic and

simplified storage provisioning eliminates the hassles and errors of preplanning by striping

data widely across all of the array’s physical spindles, resulting in the massive parallelization

of resources.

teSt objectIve

The recent tests performed by Microsoft, in consultation with 3PAR, are aimed at providing

guidance on the optimized configurations for a SQL Server application with a typical enterprise-

class OLTP workload that has been deployed on 3PAR Utility Storage. The goal of the test cases

was to demonstrate the potential benefits that a SQL Server workload could gain from the 3PAR

InSpire® Architecture.

The following five tests were run during the course of this investigation, and the results are analyzed

in greater detail in subsequent sections:

Massive Parallelization through Wide Striping. 1. The objective of this test was to

determine whether 3PAR’s wide striping capabilities provided SQL Server with sufficiently

higher performance and lower administrative complexity as compared to the performance

measured when SQL Server is run on a subset of the physical spindles that are manually

carved out but dedicated to our SQL Server database.

RAID 1 Performance with Variable Volume and Database Files. 2. The objective of this

test was to identify the optimal number of RAID 1 data volumes in combination with the

optimal number of database files that yield the best SQL Server performance. These tests

provided a baseline performance result that was used for comparisons with the other tests.

RAID 5 versus RAID 1 Performance and Capacity Benefits.3. The objective of these tests

was to compare the SQL Server performance when deployed with RAID 5 volumes, with

varying parity set configurations, versus the RAID 1 performance results from Test Case 2.

The test analyzed RAID 5 configurations with parity sets of 3+1, 5+1 and 7+1. In addition,

we analyzed the capacity savings of RAID 5 versus that of RAID 1.

Thin Provisioning and SQL Server.4. The objective of this test was to identify the resource

savings that can result from implementing thin provisioning—a storage technology that

addresses storage underutilization—along with any performance impact that results from

leveraging thin provisioned volumes.

Mixed Workload.5. The objective of this test was to determine whether an OLTP workload

needs to be segregated from other workloads running on the 3PAR InServ to optimize

performance. The performance of SQL Server with an OLTP workload running alone on


6

the 3PAR array was compared against the performance of the same OLTP workload running

concurrently with a bandwidth-intensive sequential workload.

creation of the oltp test database

The OLTP database used throughout the tests was made up of three filegroups that provided the

logical grouping of the associated data which consisted of order, broker and customer information.

The OLTP database files were grouped together in filegroups to simplify administration and provide

optimal allocation across multiple volumes. For example, all data associated with orders was stored

on a number of order database files which were contained in the order filegroup. By associating like

functions into specific filegroups and placing them in specific volumes, the administrative overhead

of creating a database with multiple files and the placement of these files upon multiple volumes

was greatly simplified.

In order to measure the impact of the number of database volumes files in Test Case 1, four

databases were created with the exact same data. For the first database, one file was allocated

per filegroup. For the second database, two files were allocated per filegroup and so on until

the fourth database was created with eight files allocated per filegroup. The end result was four

identical databases consisting of three file groups with 1, 2, 4 or 8 files per filegroup, respectively.

A client data generation program populated the OLTP databases with data until it reached a size

of approximately 1.5 TB.

The database was run on a 16-core X64 server with 64 GB of RAM. The client workload was tuned

to sufficiently stress the 3PAR IO subsystem with an 80/20 ratio between reads and writes. The test

system was also tuned to ensure that the server CPU remained at approximately 60% utilization,

that the SQL Server buffer cache hit ratio was 95%, and that the page life expectancy was about

100 seconds. The workload was tuned to be a demanding workload that would sufficiently stress

our specific 3PAR storage configuration (see Appendix A for details).

The number of IOPS measured during the initial test warm-up period was approximately 27,000

IOPS. This result can be attributed to SQL Server performing larger 64-KB reads while filling

its data cache. The average number of IOPS achieved during the steady state of the tests was

approximately 21,000 while spikes upward to 23,000 were noted during periods when a SQL

Server checkpoint occurred. The primary IO pattern was random 8-KB reads. The tests were run

for an hour; no bottlenecks were observed in the network, memory or CPU resources. As a result,

the relative performance variations and results that were observed through the various test cases

are due to the changes made to the underlying storage and data placement.

Table 1 summarizes the throughput targets for the test cases, represented in both IOPS and MB/

second. The steady state condition is defined as the period of time after initial database warm up

when the system exhibits consistent behavior. The checkpoint condition is defined as a period of

time when a database checkpoint is occurring. During a checkpoint period, the number of writes

increases as the dirty database pages are written from memory to disk.


7

IOPS Megabytes/Sec

Total Steady State 21K 170

Total Checkpoint 23K 210

Write Steady State 3K 31

Write During Checkpoint 8K 85

Table 1: Average throughput targets for the test cases

The test client was run on an 8-core server with 64 GB of RAM and no measurable bottlenecks.

The test harness parameters were tuned to ensure random 8 K read activity across the entire

database with enough load on the storage to show IO waits from the SQL Server perspective.

The test harness was able to provide an average transaction per second measurement across all

logical functions of the OLTP workload as an output. This measurement was used to compare the

associated test runs for relative performance.

SQl Server and 3par Storage teSt reSultS

Introduction

The primary intention of the tests was to emulate a real-word OLTP scenario with a demanding

load that would sufficiently stress the backend 3PAR storage so that accurate comparisons could

be made between the different permutations and configurations of the test cases. The following

sections summarize the results of the five tests conducted on SQL Server and 3PAR Storage and

discuss what these results mean to an end-user.

test 1 results — massive parallelization through Wide Striping

The purpose of this test was to determine whether the automatic wide striping capabilities of

the 3PAR InSpire Architecture provided sufficiently higher performance and lower administrative

complexities over manually carving up a subset of the physical spindles and assigning them to a

specific SQL Server database.

3PAR storage uses a clustered architecture that implements fine-grained striping of data across

all of the physical resources in the system. The 3PAR InServ Storage Server breaks each disk into

256-MB slices called chunklets and, unless manually configured otherwise, data is automatically

written to chunklets located on all of the physical drives that share the same performance and

availability characteristics. The massive parallelism can help a DBA achieve very predictable

levels of performance and can help eliminate the problems often associated with “hot spots” on a

storage array.

The OLTP database consisted of four database files per filegroup provisioned from four RAID 1

database volumes. The test was performed on two different configurations of the 3PAR storage.

First, an isolated configuration was used where two OLTP workloads were each limited to just 120

disks in the array. To examine the performance of 3PAR’s wide striping, a second configuration

was tested where the 3PAR InServ automatically striped all SQL Server database volumes across

all 240 disks available within the array.


8

The performance results of the two configurations are illustrated in Figure 1. The figure shows

that the wide striping of data by the 3PAR InServ results in a 27% performance increase over the

configuration that was manually isolated to a subset of half of the total drives. This test showed

that the InServ’s default behavior of leveraging all of the physical spindles in the storage array led

to a higher overall application performance versus manually deploying SQL Server on an isolated,

dedicated set of physical drives.

80

90

100

110

120

130

140

240 Drives120 Drives

Massive Parallelization Test (Wide Striping)

Rel

ativ

e Tr

ansa

ctio

ns/

Sec

100.0

127.3

Fig. 01: Massive parallelization test comparing SQL Server performance on

isolated drives versus all of the drives.

3PAR’s simple approach to storage provisioning enables massive parallelization to occur

automatically through wide striping. This approach enables each SQL Server deployment to leverage

the cumulative IOPS of all of the spindles in the array. The results show that high performance

SQL Server databases can be deployed without the administrative complexities often associated

with configuring and tuning larger traditional storage arrays. Benefits of massive parallelization

can be seen in the rest of the tests, and, in particular, Test 5 looks at how massive parallelization

can help SQL Server when deployed in mixed workload environments.

test 2 results — raId 1 performance with variable volumes and files

The purpose of this test was to identify the optimal number of data volumes and database files

needed to achieve acceptable performance while minimizing the cost of maintaining, upgrading

and tuning a SQL Server database application. As a database grows in size and user demand, the

database administrator is presented with a number of decision points to effectively manage this

growth. The number of file system volumes and the number of database files are two important

factors that can affect the database’s performance and manageability costs.

The variable volume tests were performed on the OLTP data base consisting of four files per database

filegroup and were provisioned from a variable number of RAID 1 volumes. The 3PAR RAID 1

volumes are always RAID 1+0 volumes because data is striped across all of the system’s internal

resources, including disks, controllers and Fibre Channel loops. Similarly, RAID 5—discussed in

more detail in the following section—is implemented as RAID 5+0 on an InServ array.


9

The massive parallelism discussed in the previous section ensures that all of the capabilities of the

storage system’s resources are used and assures a high level of performance for all of the volumes

used by SQL Server. In addition, our results show that 3PAR Utility Storage provided a consistent

and predictable level of performance from the volumes, regardless of the number used.

Figure 2 illustrates the relative performance of the workload run against the database with a

variable number of volumes. The results are statistically equivalent and show that the number of

volumes does not impact the performance of the SQL Server database OLTP workload. This result

provides the DBA with flexibility in deciding how to configure the database without having to

worry about how the number of volumes will impact the underlying storage system’s performance.

These results are used as our baseline when analyzing the performance of the other tests.

Rel

ativ

e Tr

ansa

ctio

ns/

Sec

90

91

92

93

94

95

96

97

98

99

100

4 Volumes2 Volumes1 Volume

RAID 1 Performance vs. Number of Volumes

OLTP Workload (4 Files per Database)

100.0099.59

99.97

Fig. 02: Relative performance of an OLTP workload across multiple RAID 1

volume sets

The next test focused on measuring the impact of changing the number of database files while

holding the number of volumes fixed. The variable file tests were performed on the OLTP database

consisting of 1, 4 and 8 database files per filegroup provisioned from a single RAID 1 volume.

Figure 3 shows the relative performance of these three tests. From the test results we can observe

a small degradation—a 4% decrease in performance when moving from one file to eight files—in

the database’s performance as the number of files increased.


10

50

60

70

80

90

100

110

8 Files4 Files1 File

RAID 1 Performance vs. Number of Files

Rel

ativ

e Tr

ansa

ctio

ns/

Sec

OLTP Workload (Single RAID 1 Volume)

10098

96

Fig. 03: Relative performance of an OLTP workload with one RAID 1 volume and

a variable number of database files

These tests illustrate that the number of volumes selected has no measurable impact on the

performance of SQL Server running on 3PAR Utility Storage. The second result shows that the

number of database files has minimal impact on performance as well.

This demonstrates that high performance can be achieved without having to create and manage

a large number of volumes and files. IT administrators can achieve their desired performance

with a simplistic data layout, which results in quicker implementations, faster response to new

requirements, and lower overall cost of administration.

test 3 results — raId 5 versus raId 1

The purpose of this test was to test the performance of 3PAR’s RAID 5 implementation and compare

the results with the RAID 1 baseline to determine if the improved resource efficiencies associated

with RAID 5 could be achieved without sacrificing database performance.

With traditional storage, RAID 1 is usually associated with providing noticeably higher performance

than RAID 5 since no parity calculation is required; RAID 5 is viewed as offering lower performance

but is advantageous because fewer spindles are required to store the same amount of data. IT

administrators have traditionally had to weigh the tradeoffs between higher performance and

greater capacity utilization when deciding on the optimal RAID configuration.

To understand the space savings offered by RAID 5, consider the following example: If RAID 1

is implemented on data that fills three physical disks, then 6 total disks are required—three for the

actual data and three for the mirrored data. If RAID 5 with a parity set of 3+1 is used, then only

four total disks are required—three for the actual data and one additional disk to store the parity


11

information. This means that, for every two disks required in a RAID 1 implementation, only

1.33 are required for RAID 5. If a parity set of 5+1 is used, then the number of disks required for

RAID 5 (5+1) is further reduced to just 1.2 disks for every 2 needed with RAID 1. These examples

show that RAID 5 can offer significant capacity savings as compared to RAID 1. Unfortunately,

traditional array users concerned with database performance often sacrifice the capacity savings

offered by RAID 5 in favor of RAID 1’s higher performance.

To determine the actual performance difference between RAID 1 and RAID 5 on new storage

architectures, this test measured the performance of the SQL Server database while running on

four different RAID 5 configurations of the 3PAR array. The RAID 5 tests were performed on

an OLTP database consisting of four database files per database that were provisioned on four

RAID 5 volumes. The results were compared against the RAID 1 baseline results consisting of four

database files and four volumes. Additionally, to test the impact of the parity sets on SQL Server’s

performance, the RAID 5 parity ratio was tested at 3+1, 5+1 and 7+1.

Figure 4 illustrates the result of the three RAID 5 tests and how they compared against the RAID 1

baseline measured in Test 2. When compared to the RAID 1 baseline, the tests revealed only a 3%

reduction in performance when RAID 5 (7+1) was used. The performance between the different

RAID 5 parity levels was minimal—approximately 4% different between RAID 5 with 3+1 and

7+1 parity.

Rel

ativ

e Tr

ansa

ctio

ns/

Sec

0

20

40

60

80

100

120

R5 (7+1)R5 (5+1)R5 (3+1)RAID 1

RAID 5 Performance vs. RAID 1 Baseline Performance

OLTP Workload (4 Volumes / 4 Files)

10093 96 97

Fig. 04: Performance of different RAID 5 parity levels normalized to the

RAID 1 baseline performance

For this specific test, we noted a slight increase in performance as the parity set size increased. One

reason for this change in performance can be attributed to the large number of reads used in our

OLTP workload compared to the number of writes. Because the number of spindles in our test

remained constant, the higher parity set size reduced the amount of overall data per spindle, which

results in slighter faster access times for read-intensive workloads.


12

On top of the near-equivalent performance, the usable storage space increases from 50% in RAID 1

to 87.5% in RAID 5 (7+1). To illustrate this benefit, Figure 5 shows the percentage of the disk space

available for actual written data, not mirrored or parity information, for the four RAID settings

analyzed in this test. Simple math shows that RAID 5 (3+1) results in a 33.3% reduction in total

storage needs over RAID 1 while RAID (7+1) can save 43%. The results of these specific tests

show that 3PAR’s RAID 5 implementation offers the customer running SQL Server nearly identical

performance to that of RAID 1 but with dramatic capacity savings. These results can be attributed

to the fact that 3PAR offers hardware-accelerated, fast RAID 5 calculations.

Dis

k U

tiliz

atio

n (

%)

0

10

20

30

40

50

60

70

80

90

100

R5 (7+1)R5 (5+1)R5 (3+1)RAID 1

Usable Disk Space per RAID Type

OLTP Workload (4 Volumes / 4 Files)

50.0

75.0

83.387.5

Fig. 05: Comparison of the disk space used per RAID type for actual data rather

than for mirrored or parity information

Deeper analysis of the RAID 1 and RAID 5 tests show a number of interesting observations.

Figure 6 shows a 15-minute sample of the total average disk transfer time for both the RAID 1

and RAID 5 runs. The RAID 5 transfer time is higher than that of the RAID 1, which is to be

expected since SQL Server is waiting on disk IO even during the RAID 1 tests and RAID 5 requires

the overhead of an additional read for parity calculations. This fact is confirmed by examining the

average bytes per second from both the RAID 5 and RAID 1 configurations as shown in Figure 7.

The spike of activity at both 2 minutes and 11 minutes in the figure correspond to the time when

the SQL Server checkpoint process is flushing dirty pages to disk. Examining Figures 6 and 7, in

the RAID 1 case we observe little if any increase in the transfer time but with a significant increase

in disk throughput. In the RAID 5 case, we detect the opposite; an increase in writes has a slight

negative impact on both the transfer time and the RAID 5 disk throughput. Altogether, the figures

below along with Figure 4 show RAID 5 results in only a 3% reduction in performance relative to

RAID 1 as observed by the client.


13

6

7

8

9

10

11

12

RAID 5RAID 1

Ave

rag

e M

S/Tr

ansf

er

OLTP Workload Average MS/Transfer vs. RAID Level

0:00

0:15

0:14

0:13

0:12

0:11

0:10

0:09

0:08

0:07

0:06

0:05

0:04

0:03

0:02

0:01

0:16

Fig. 06: RAID 1 and RAID 5 Average Disk Transfer Time

110

120

130

140

150

160

170

180

190

200

210

RAID 5RAID 1

Meg

abyt

es/S

ec

OLTP Workload Megabytes/Sec vs. RAID Level

0:00

0:15

0:14

0:13

0:12

0:11

0:10

0:09

0:08

0:07

0:06

0:05

0:04

0:03

0:02

0:01

0:16

Fig. 07: RAID 1 and RAID 5 Average Bytes per Second


14

Based on these results, it is clear that 3PAR’s RAID 5 implementation offers near RAID 1 performance

and can provide significant savings on the amount of storage required. Given the near-identical

performance to RAID 1, database administrators should give strong consideration to implementing

RAID 5 more often when deploying SQL Server with 3PAR Utility Storage.

test 4 results — thin provisioning performance and SQl Server

The intention of this test was to measure the impact of thin provisioning in concert with SQL Server

and its SQL Server Instant File Initialization feature during a typical OLTP workload scenario.

The SQL Server Instant File Initialization feature enables data files to be initialized instantaneously

when a database is created or the data files are added or changed. Traditionally, whenever a

database file is created or changed, the file was initialized by filling it completely with zeros to

remove any data left on the disk from deleted files. With Instant File Initialization, SQL Server

no longer writes zeros across the entire file to initialize it. This feature is critical to achieving the

maximum benefit of thin provisioning on the storage array, which can help eliminate the problem

of allocated but unused storage since SQL Server with Instant File Initialization no longer writes

zeros across the entire file up front.

Thin provisioning is a storage solution with which IT departments are allowed to safely provision

as much logical capacity as is needed to meet the needs of a database application over the lifetime

of the system; meanwhile, physical capacity is only allocated when a SQL Server write is initiated

that actually requires additional physical storage. This “dedicate-on-write” software technology

allows users to purchase disk capacity based on their actual written data and then non-disruptively

add additional capacity when the application grows and requires additional storage. 3PAR Thin

Provisioning with SQL Server Instant File Initialization can provide significant cost savings by

eliminating the need to purchase and allocate the storage at the time of the database deployment. All

of these capacity benefits can be achieved while maintaining strong performance, as demonstrated

by the following results.

Note that Instant File Initialization is not used with log files because they must be fully initialized with

zeros to maximize performance and guarantee database recovery. The data files, which represent the

majority of the database’s data, are dynamically created with Instant File Initialization to reduce the

storage requirements and thus can benefit from thin provisioning. These tests focus on measuring

the performance and benefits of using thin provisioning with SQL Server’s database files.

The thin provisioning tests were performed on the OLTP database consisting of four database

files per filegroup provisioned from four thinly provisioned RAID 1 volumes widely striped across

all disks in the system. The database was created with Instant File Initialization. The thinly

provisioned database was populated in a way that mimicked a real-world scenario where an OLTP

database would grow over a period of time.

Our real-world scenario of creating a SQL Server database, illustrated in Figure 8, begins with

the quick provisioning of a 2-TB thin provisioned volume on the 3PAR InServ. At the start of

Year 1, the server sees a standard, 2-TB volume, but because no data has been written to the thin

provisioned volume, no physical storage has been allocated or used yet. Early in Year 1, the SQL


15

Server database file is initialed to a size of 200 GB, but, as a result of Instant File Initialization, no

physical storage is allocated from disk yet. A 20-GB log is initialized at this time and consumes the

first meaningful amount of disk space. In our example, the database has a projected data growth

of 500 GB per year.

DATABASEINITIALIZED

THIN VOLUMES ALLOCATED TO

SQL SERVER

DATABASEFILE GROWTH

FINAL SQLSERVER

DATABASE SIZE

2 TB

0 GB

2 TB

20 GB (Log)

2 TB

500 GB

2 TB

1.5 TB

STORAGESAVINGS

2 TB 1.98 TB 1.5 TB 500 GB

ACTUAL DATA WRITTEN TO PHYSICAL STORAGE

THIN PROVISIONED VOLUME’S UNALLOCATED STORAGE

START OF YEAR 1 EARLY YEAR 1 END OF YEAR 1 END OF YEAR 3

Fig. 08: Storage capacity savings of SQL Server with 3PAR Thin Provisioning

To simulate three years of growth, the database was set to autogrow at rate that resulted in

approximately 500 GB of new written data per year. As the data is steadily inserted by the data

generation client, the database files grow to accommodate the written data and consume only

enough physical storage to store the new writes. At the end of Year 1, 500 GB of data was written

to the database and consumed only 500 GB of disk space from the overall 2 TB of logical disk space

available to SQL Server. This means that only a quarter of the originally allocated logical space

had to be purchased in Year 1, resulting in significant cost savings. The database in this example

will reach its target size of 1.5 TB after three years of production. As illustrated in Figure 8, the

database effectively used thin provisioning to both delay and reduce the need for physical storage.

The performance of this database with thin provisioned volumes was measured and compared

against our baseline results from Test 1 that used “standard” non-thin provisioned volumes on

the 3PAR InServ. Figure 9 shows the comparative results of the OLTP workload run against a

set of fully provisioned volumes (i.e. standard provisioning) versus the performance results of the

thinly provisioned volumes. The results of the test show that only a 4% reduction in SQL Server

performance occurred when using thin provisioned volumes, while much less storage was required

for the database over time. This example shows that 3PAR Thin Provisioning could reduce the

total storage required while maintaining high performance, enabling the physical storage to be

purchased as needed over the three year time period rather than being purchased all upfront.


16

50

60

70

80

90

100

Full Provisioning vs. Thin Provisioning Performance

Rel

ativ

e Tr

ansa

ctio

ns/

Sec

100

96

OLTP Workload (RAID 1)

Full Provisioned Thin Provisioned

Fig. 09: Relative performance of an OLTP workload with fully provisioned and

thinly provisioned volumes

For DBAs and IT administrators, these results confirm that SQL Server behaves very well with thin

provisioned volumes with a minimal impact on performance. For environments where the database

has consistent or predictable growth, thin provisioning can drastically reduce the up-front storage

costs and enable users to only purchase additional storage when and if it is required for data growth.

In addition, higher utilization rates mean less physical resources must be purchased, managed and

maintained by IT administrators, resulting in noticeably lower operational expenses.

test 5 results — mixed Workload

The purpose of the following two mixed workload tests was to determine whether an application

environment consisting of both random (OLTP) and sequential database disk activity can coexist

on the same underlying physical spindles and still achieve satisfactory performance.

test 5a: mixed-Workload only

On traditional storage, IT administrators must pay careful attention to how they lay out data on

the storage so that applications with different workload characteristics do not adversely impact the

performance of other applications. The typical solution is to provide physical separation of mixed

workloads by allocating separate controller, cache and disk resources for sequential workloads

and random workloads. In many cases, storage vendors may advise separating these workloads

onto completely different arrays. This process can be quite time consuming and complex, as the

IO characteristics of an application are often difficult to ascertain and predict, and the separation

often drives increased storage costs due to poorer storage utilization.

3PAR Utility Storage helps eliminate these problems through its automatic wide striping capabilities

(demonstrated in Test 1) and its unique architecture, which separates the processing of I/O control

commands from the data movement. Unlike legacy architectures that process I/O commands and

move data using the same processor, 3PAR’s processing separation helps eliminate the performance

bottlenecks of traditional systems when simultaneously serving competing workloads.


17

To measure the impact of 3PAR’s mixed-workload architecture on a shared SQL Server environment,

a set of tests were conducted to measure and compare the performance of the SQL Server database

running alone versus running simultaneously with a large, sequential workload stored on the same

physical drives. The second test composed of the two workloads running together is referred to

later as the “mixed-workload.” The workloads were automatically striped across all 240 drives

for both tests. By keeping the benefits of massive parallelization constant in both tests, the unique

mixed-workload architecture of 3PAR Utility Storage can be examined.

The mixed workload used was a combination of the OLTP workload discussed in the previous

test cases and a new sequential workload. The OLTP database consisted of four database files per

filegroup provisioned from four RAID 1 database volumes. The sequential workload was run on a

second server that generated a constant and relatively heavy stream of data at a rate of 100 MB/Sec

in a series of reads and writes with a transfer size of 64 KB. The sequential and OLTP workloads

were run simultaneously with measurements taken to compare the average transactions per second

achieved for only the OLTP workload.

The results of this test are illustrated in Figure 10. The results show that the OLTP performance

on the 3PAR array decreased by only 16% when run simultaneously with a heavy, sequential

workload, whose performance is not included in Figure 10. The 3PAR InSpire Architecture enables

both of these workloads to coexist on the same physical drives with minimal impact on their

individual performance. In addition to completing 106.9 transactions per second, relative to the

other measurements, for the OLTP workload the 3PAR array also completed the I/Os of the heavy

sequential workload running simultaneously. Since such a combination of workloads generally

uses two separate arrays, the simplicity and cost savings of the 3PAR array is self-evident.

60

70

80

90

100

110

120

130

140

Rel

ativ

e Tr

ansa

ctio

ns/

Sec

127.3

106.9

OLTP Performance with OLTP Only Workload

(240 Drives)

OLTP Performance with Mixed Workload

(240 Drives)

Mixed Workload Impact on OLTP Performance

Fig. 10: OLTP Performance when run alone and when run simultaneously with a

sequential workload


18

test 5b: mixed-Workload and massive-parallelization

Finally, an additional set of tests were conducted to illustrate the combined benefits of 3PAR’s

massive-parallelization and mixed-workload architecture. For this final test case, the mixed

workload was run and measured on two different storage configurations: an isolated configuration

and a shared configuration. In the isolated test case, the 3PAR InServ was configured into

two separate pools of 120 disks with the first pool dedicated to the OLTP workload and the

second pool dedicated to the sequential workload. The shared disk case is the same test

discussed previously where the OLTP performance was measured when the mixed workload was

loaded on a shared pool of 240 disks. Figure 11 illustrates these two storage configurations.

SHARED DISKSSHARED DISKS

OLTP AND SEQUENTIALWORKLOADS(240 DISKS)

ISOLATED DISKSISOLATED DISKS

SEQUENTIALWORKLOAD(120 DISKS)

OLTPWORKLOAD(120 DISKS)

Fig. 11: Storage configuration for results in OLTP mixed workload

performance tests

The results from this test of the mixed-workload run in an isolated storage configuration and then

a shared configuration is illustrated in Figure 12. The results show that the OLTP performance

within the shared storage configuration proved to have an 11% advantage in performance over the

isolated disk configuration. By allowing the 3PAR array to automatically stripe both workloads

together across all 240 disks (versus isolating each workload to a different group of 120 drives for

the isolated configuration), the OLTP workload saw a noticeable increase in performance over the

traditional method of carving out isolated disks to store only the OLTP data (note that segregating

workloads is the standard practice on legacy storage arrays).


19

106.9

60

65

70

75

80

85

90

95

100

105

110

Rel

ativ

e Tr

ansa

ctio

ns/

Sec

96.3

OLTP Performance with Mixed Workload(Isolated - 120 Drives)

OLTP Performance with Mixed Workload(Shared - 240 Drives)

Mixed Workload and Massive Parallellization Performance

Fig. 12: OLTP performance in a mixed-workload environment using isolated versus

shared storage configurations

The results of this second test illustrate that the wide striping and mixed-workload architecture

offered by 3PAR Utility Storage help OLTP workloads perform better when deployed in a shared

environment versus using isolated storage configurations, even when the shared drives are also being

used by an active, sequential workload. In addition to the performance benefit, the shared storage

can help reduce the time spent planning data layouts and can simplify the storage provisioning

and management.

concluSIon

Based on the results of these tests performed for a joint customer, Microsoft and 3PAR were able

to demonstrate configuration optimizations that yielded high SQL Server performance, low storage

costs, and simple management. The tests were able to demonstrate:

high performance

3PAR’s parallelized architecture widely stripes data, leveraging the cumulative IOPS of all of •

the system’s drives rather than allocating a limited number of drives to a given application

high resource utilization

When combined with thin provisioning, SQL Server Instant File Initialization can help •

maximize resource utilization and lower costs with a minimal impact on performance.

Fast RAID 5 implementations on 3PAR InServ arrays can significantly reduce storage costs •

while maintaining performance levels comparable with RAID 1.


20

reduced Storage provisioning and management costs

Database administration costs and simplified database layouts are made possible by using •

few storage volumes and database files.

Reduced time and effort to provision volumes resulted from leveraging 3PAR’s •

massive parallelization.

Straightforward and uncomplicated performance tuning of storage was achieved by •

automatically striping mixed workloads across the entire InServ array.

about 3par

3PAR® (NYSE: PAR) is the leading global provider of utility storage, a category of highly virtualized

and dynamically tiered storage arrays built for public and private cloud computing. Our virtualized

storage platform was built from the ground up to be agile and efficient to address the limitations

of traditional storage arrays for utility infrastructures. As a pioneer of thin provisioning and other

storage virtualization technologies, we design our products to reduce power consumption to help

companies meet their green computing initiatives and to cut storage total cost of ownership. 3PAR

customers have used our self-managing, efficient, and adaptable utility storage systems to reduce

administration time and provisioning complexity, to improve server and storage utilization, and to

scale and adapt flexibly in response to continuous growth and changing business needs. For more

information, visit the 3PAR Website at: www.3PAR.com.

© 2009 3PAR Inc. All rights reserved. 3PAR, the 3PAR logo, Serving Information, InServ, InForm, InSpire, and Thin Built In are all trademarks or registered trademarks of 3PAR Inc. Microsoft, SQL Server 2008, SQL Server are trademarks of the Microsoft group of companies. All other trademarks and registered trademarks are the property of their respective owners.


21

appendIx a

test configuration details

The host-side of the test system was composed of a database server, a client load server and a mixed

IO workload server. The volumes presented to the database and mixed IO workload servers were

connected through two 4Gb/sec HBAs, each of which was load balanced in a round robin fashion

with the Microsoft MPIO and Device Specific Module.

Server Specifics RAM OS

Database Server Dell PowerEdge R9000 64 GB Windows 2008

Client Dell PowerEdge 6950 64 GB Windows 2008

Sequential IO Workload Dell PowerEdge R9000 64 GB Windows 2008

The storage system used was a 3PAR S400 InServ Storage Server with 240 fibre channel drives. The

specifics of the storage system used for the tests are summarized in the following table:

3PAR S400 FeaturesSQL Server Lab Configuration

Maximum Supported

3PAR InForm OS Version 2.2.4 -

Number of Controller Nodes 2 Nodes 4 Nodes

Control Cache 4 GB 16 GB

Data Cache 16 GB 32 GB

FC Ports to Hosts 12 ports 64 ports

iSCSI Ports to Hosts 4 ports 16 ports

FC Ports to Drives 16 ports 32 ports

Number of Drive Chassis 6 chassis 16 chassis

Number of Drive Magazines 60 mags 160 mags

Number of Drives 240 drives 640 drives

Drive Size 147 GB, 10K RPM 147 GB – 1 TB

Total Raw Storage 34.45 TB 300 TB

Total Available Raw Storage 31.07 TB -

u.S. corporate headQuarterS

3PAR Inc.4209 Technology Drive

Fremont, CA 94538

Phone: 510-413-5999

Fax: 510-413-5699

Email: [email protected]

sqlserver-wp-09.0

3PAR Utility Storage in a Microsoft SQL Server Environment · Manageability and Performance...

Documents

Transcript of 3PAR Utility Storage in a Microsoft SQL Server Environment · Manageability and Performance...