3par sqlserver wp 09.0

7/27/2019 3PAR Sqlserver Wp 09.0

1/22

Manageability andPer ormanceBenefts o3PAR Utility Storage in aMicroso t SQLServer Environment

3PAR AND MICROSOFT WHITE PAPER2009


2/22

Manageability and Per ormance Benefts o 3PAR Utility Storage in a Microso t SQL Server Environment

Table o ContentsSummary 3Introduction 3Challenges Confguring a Database Application 3

Database Application Per ormance 4Resource Utilization 4Storage Provisioning 4

Customer Scenario and Solutions Used 4Test Objective 5

Creation o the OLTP Test Database 6SQL Server and 3PAR Storage Test Results 7

Introduction 7Test 1 Results Massive Parallelization through Wide Striping 7Test 2 Results RAID 1 Per ormance with Variable Volumes and Files 8Test 3 Results RAID 5 versus RAID 1 10

Test 4 Results Thin Provisioning Per ormance and SQL Server 14Test 5 Results Mixed Workload 16

Test 5a: Mixed-Workload Only 16Test 5b: Mixed-Workload and Massive-Parallelization 18

Conclusion 19High Per ormance 19High Resource Utilization 19Reduced Storage Provisioning and Management Costs 20

About 3PAR 20Appendix A 21

Test Confguration Details 21


3/22


Summary

In ormation technology specialists are increasingly challenged to provide high per orming, complexdatabase systems while simultaneously managing the costs o ever-growing storage demands. Astorage management system that provides optimal and highly predictable per ormance o OLTPand mixed workload environments while liberating the organization rom complex con gurationchanges is the ultimate goal. This paper summarizes tests per ormed or a joint Microso t and3PAR customer who wanted to better understand the bene ts o new storage technologies in itsenvironment. 3PAR and Microso t worked collaboratively to assist the customer with reducingcapital and administrative costs while maintaining optimal per ormance running an OLTP workloadon Microso t SQL Server 2008 Enterprise Edition and a 3PAR InServ Storage Server.

IntroductIon

This white paper examines the challenges o managing complex data systems and investigatesways to optimize those con gurations or both per ormance and simplicity. A SQL Server 2008customer requested that tests be per ormed on Microso t SQL Server and 3PAR Utility Storageto explore the ability to manage complex data systems while maintaining high per ormance withminimal administrative costs. This white paper documents the results o these tests and providesseveral examples or optimizing con gurations or SQL Server OLTP applications running on the3PAR InServ Storage Server.

The increasing challenges to managing and maintaining storage are intrinsic to the growing sizeand complexity o SQL Server database applications. The test results discussed in this paper helpto demonstrate the strong per ormance, high storage e ciency and simple management achievablewhen combining eatures rom SQL Server 2008 and 3PAR Utility Storage or a given customerenvironment.

The tests presented throughout this paper were per ormed by Microso t at the customers request, inconsultation with 3PAR, to assist with determining a con guration that would help the customer toreduce costsboth in terms o manageability and resource utilizationas well as helping maintaina high level o predictable per ormance while handling large SQL Server workloads.

challengeS confIgurIng a databaSe applIcatIon

The advent o more demanding database applications combined with requirements to retain dataor longer periods o time has contributed to the growth o large, complex database application

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

databases e ciently and cost e ectively, even as the data grows and matures. Meanwhile, storageadministrators must manage the corresponding ever-growing storage environment in which theyare asked to quickly respond to business demands and to optimize the utilization o their storageresources.

The concepts associated with managing a dynamic and high per orming database system are wellknown. Examples o the decisions that must be made when deploying a database include thenumber and placement o database les, the isolation o database les on the backend storagesystem, and the size o the storage volumes. Each o these decisions has an associated cost, whether


4/22


it is adding administrative overhead to accelerate new deployments or optimizing the data layouton the underlying storage to improve per ormance.

When deploying a SQL Server database application and an enterprise-class storage system, ITadministrators must nd a way to overcome the ollowing common challenges o database tuning,

storage provisioning and resource utilization:

d s a i i p

Tuning a database application to scale with predictable levels o per ormance is not a trivial exercisewhen the storage subsystem must respond to a multitude o di ering workloads. Applicationper ormance can su er when poor decisions are made about data placement or when data growthresults in les with di ering workloads competing or the same computing resources. Planningmiscalculations can result in inconsistent per ormance when data volumes are overutilized orunderutilized. As a result o these complexities, the time and money spent tracking and managingthe per ormance across the datacenter can escalate unless an easier process is introduced.

r s u i iz i

When building a database application, the database administrator (DBA) must estimate a databasesgrowth rate and predict its nal size in a year or more. As a result, storage is o ten purchased up-

ront to satis y the projected growth, even though most o the storage capacity is not used initially.These practices o ten lead to the underutilization o purchased storage resources. Poor utilization

orces companies to unnecessarily spend resources powering, cooling, and administering unusedstorage resources. A more desirable outcome is to postpone the purchase o storage required or

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

S p isi iComplex database applications are requently comprised o tens o database les that must bemapped to multiple volumes on a large storage system. The DBA must decide which storage volumesto place the database les onto while keeping both per ormance and uture growth in mind. Tomake these decisions, administrators usually ollow a complex process in order to map the disks tothe individual volumes and assign them to speci c les, a process which o ten leads to human error.File growth or the inclusion o additional database les can introduce urther complexity. I notmanaged correctly, ongoing growth can result in misbalanced IO and per ormance degradation, orthe growth may require the movement o large chunks o data.

cuStomer ScenarIo and SolutIonS uSedThe customer scenario reviewed in this paper is a SQL Server OLTP application deployed on a3PAR InServ Storage Server.

Microso t SQL Server 2008. Microso t SQL Server 2008 is an intelligent data plat ormthat enables you to run your most demanding mission-critical applications, reduce timeand cost o development and management o applications, and deliver actionable insight toyour entire organization. Microso t SQL Server leverages the capabilities o enterprise SAN


5/22


storage such as 3PAR to help reduce the management requirements o an organizationsdatabase storage as well as reduced capital costs.

3PAR InServ Storage Servers. 3PAR Utility Storage is a category o next-generationstorage arrays built or utility computing. 3PAR o ers a virtualized, tiered-storage arraydesigned to help customers reduce the costs o allocated capacity, administration, andSAN in rastructure while increasing adaptability and resiliency. 3PARs autonomic andsimpli ed storage provisioning eliminates the hassles and errors o preplanning by stripingdata widely across all o the arrays physical spindles, resulting in the massive parallelizationo resources.

teSt objectIve

The recent tests per ormed by Microso t, in consultation with 3PAR, are aimed at providingguidance on the optimized con gurations or a SQL Server application with a typical enterprise-class OLTP workload that has been deployed on 3PAR Utility Storage. The goal o the test caseswas to demonstrate the potential bene ts that a SQL Server workload could gain rom the 3PARInSpire Architecture.

The ollowing ve tests were run during the course o this investigation, and the results are analyzedin greater detail in subsequent sections:

Massive Parallelization through Wide Striping.1. The objective o this test was todetermine whether 3PARs wide striping capabilities provided SQL Server with su cientlyhigher per ormance and lower administrative complexity as compared to the per ormancemeasured when SQL Server is run on a subset o the physical spindles that are manuallycarved out but dedicated to our SQL Server database.

RAID 1 Per ormance with Variable Volume and Database Files.2. The objective o thistest was to identi y the optimal number o RAID 1 data volumes in combination with theoptimal number o database les that yield the best SQL Server per ormance. These testsprovided a baseline per ormance result that was used or comparisons with the other tests.

RAID 5 versus RAID 1 Per ormance and Capacity Benefts.3. The objective o these testswas to compare the SQL Server per ormance when deployed with RAID 5 volumes, withvarying parity set con gurations, versus the RAID 1 per ormance results rom Test Case 2.The test analyzed RAID 5 con gurations with parity sets o 3+1, 5+1 and 7+1. In addition,we analyzed the capacity savings o RAID 5 versus that o RAID 1.

Thin Provisioning and SQL Server.4. The objective o this test was to identi y the resourcesavings that can result rom implementing thin provisioninga storage technology thataddresses storage underutilizationalong with any per ormance impact that results romleveraging thin provisioned volumes.

Mixed Workload.5. The objective o this test was to determine whether an OLTP workloadneeds to be segregated rom other workloads running on the 3PAR InServ to optimizeper ormance. The per ormance o SQL Server with an OLTP workload running alone on


6/22


the 3PAR array was compared against the per ormance o the same OLTP workload runningconcurrently with a bandwidth-intensive sequential workload.

c i oltp t s d s

The OLTP database used throughout the tests was made up o three legroups that provided the

logical grouping o the associated data which consisted o order, broker and customer in ormation.The OLTP database les were grouped together in legroups to simpli y administration and provideoptimal allocation across multiple volumes. For example, all data associated with orders was storedon a number o order database les which were contained in the order legroup. By associating like

unctions into speci c legroups and placing them in speci c volumes, the administrative overheado creating a database with multiple les and the placement o these les upon multiple volumeswas greatly simpli ed.

In order to measure the impact o the number o database volumes les in Test Case 1, ourdatabases were created with the exact same data. For the rst database, one le was allocated

per legroup. For the second database, two les were allocated per legroup and so on untilthe ourth database was created with eight les allocated per legroup. The end result was ouridentical databases consisting o three le groups with 1, 2, 4 or 8 les per legroup, respectively.A client data generation program populated the OLTP databases with data until it reached a sizeo approximately 1.5 TB.

The database was run on a 16-core X64 server with 64 GB o RAM. The client workload was tunedto su ciently stress the 3PAR IO subsystem with an 80/20 ratio between reads and writes. The testsystem was also tuned to ensure that the server CPU remained at approximately 60% utilization,that the SQL Server bu er cache hit ratio was 95%, and that the page li e expectancy was about

100 seconds. The workload was tuned to be a demanding workload that would su ciently stressour speci c 3PAR storage con guration (see Appendix A or details).

The number o IOPS measured during the initial test warm-up period was approximately 27,000IOPS. This result can be attributed to SQL Server per orming larger 64-KB reads while llingits data cache. The average number o IOPS achieved during the steady state o the tests wasapproximately 21,000 while spikes upward to 23,000 were noted during periods when a SQLServer checkpoint occurred. The primary IO pattern was random 8-KB reads. The tests were run

or an hour; no bottlenecks were observed in the network, memory or CPU resources. As a result,the relative per ormance 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 or the test cases, represented in both IOPS and MB/ second. The steady state condition is de ned as the period o time a ter initial database warm upwhen the system exhibits consistent behavior. The checkpoint condition is de ned as a period o time when a database checkpoint is occurring. During a checkpoint period, the number o writesincreases as the dirty database pages are written rom memory to disk.


7/22


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 or the test cases

The test client was run on an 8-core server with 64 GB o RAM and no measurable bottlenecks.The test harness parameters were tuned to ensure random 8 K read activity across the entiredatabase with enough load on the storage to show IO waits rom the SQL Server perspective.The test harness was able to provide an average transaction per second measurement across alllogical unctions o the OLTP workload as an output. This measurement was used to compare theassociated test runs or relative per ormance.

SQl Server and 3par Storage teSt reSultS

I i

The primary intention o the tests was to emulate a real-word OLTP scenario with a demandingload that would su ciently stress the backend 3PAR storage so that accurate comparisons couldbe made between the di erent permutations and con gurations o the test cases. The ollowingsections summarize the results o the ve tests conducted on SQL Server and 3PAR Storage anddiscuss what these results mean to an end-user.

t s 1 r s s m ssi p iz i Wi S i i

The purpose o this test was to determine whether the automatic wide striping capabilities o the 3PAR InSpire Architecture provided su ciently higher per ormance and lower administrativecomplexities over manually carving up a subset o the physical spindles and assigning them to aspeci c SQL Server database.

3PAR storage uses a clustered architecture that implements ne-grained striping o data acrossall o the physical resources in the system. The 3PAR InServ Storage Server breaks each disk into256-MB slices called chunklets and, unless manually con gured otherwise, data is automaticallywritten to chunklets located on all o the physical drives that share the same per ormance andavailability characteristics. The massive parallelism can help a DBA achieve very predictable levelso per ormance and can help eliminate the problems o ten associated with hot spots on a storagearray.

The OLTP database consisted o our database les per legroup provisioned rom our RAID 1database volumes. The test was per ormed on two di erent con gurations o the 3PAR storage.First, an isolated con guration was used where two OLTP workloads were each limited to just 120disks in the array. To examine the per ormance o 3PARs wide striping, a second con gurationwas tested where the 3PAR InServ automatically striped all SQL Server database volumes acrossall 240 disks available within the array.


8/22


The per ormance results o the two con gurations are illustrated in Figure 1. The gure showsthat the wide striping o data by the 3PAR InServ results in a 27% per ormance increase over thecon guration that was manually isolated to a subset o hal o the total drives. This test showedthat the InServs de ault behavior o leveraging all o the physical spindles in the storage array ledto a higher overall application per ormance versus manually deploying SQL Server on an isolated,

dedicated set o physical drives.

80

90

100

110

120

130

140

240 Drives120 Drives

Massive Parallelization Test (Wide Striping)

R e l a t i v e

T r a n s a c

t i o n s /

S e c

100.0

127.3

Fig. 01: Massive parallelization test comparing SQL Server per ormance onisolated drives versus all o the drives.

3PARs simple approach to storage provisioning enables massive parallelization to occurautomatically through wide striping. This approach enables each SQL Server deployment to leverage

the cumulative IOPS o all o the spindles in the array. The results show that high per ormanceSQL Server databases can be deployed without the administrative complexities o ten associatedwith con guring and tuning larger traditional storage arrays. Bene ts o massive parallelizationcan be seen in the rest o the tests, and, in particular, Test 5 looks at how massive parallelizationcan help SQL Server when deployed in mixed workload environments.

t s 2 r s s raId 1 p wi v i v s f i s

The purpose o this test was to identi y the optimal number o data volumes and database lesneeded to achieve acceptable per ormance while minimizing the cost o maintaining, upgradingand tuning a SQL Server database application. As a database grows in size and user demand, the

database administrator is presented with a number o decision points to e ectively manage thisgrowth. The number o le system volumes and the number o database les are two important

actors that can a ect the databases per ormance and manageability costs.

The variable volume tests were per ormed on the OLTP data base consisting o our les per databaselegroup and were provisioned rom a variable number o RAID 1 volumes. The 3PAR RAID 1

volumes are always RAID 1+0 volumes because data is striped across all o the systems internalresources, including disks, controllers and Fibre Channel loops. Similarly, RAID 5discussed inmore detail in the ollowing sectionis implemented as RAID 5+0 on an InServ array.


9/22


The massive parallelism discussed in the previous section ensures that all o the capabilities o thestorage systems resources are used and assures a high level o per ormance or all o the volumesused by SQL Server. In addition, our results show that 3PAR Utility Storage provided a consistentand predictable level o per ormance rom the volumes, regardless o the number used.

Figure 2 illustrates the relative per ormance o the workload run against the database with avariable number o volumes. The results are statistically equivalent and show that the number o volumes does not impact the per ormance o the SQL Server database OLTP workload. This resultprovides the DBA with fexibility in deciding how to con gure the database without having toworry about how the number o volumes will impact the underlying storage systems per ormance.These results are used as our baseline when analyzing the per ormance o the other tests.

R e

l a t i v e

T r a n s a c

t i o n s /

S e c

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 per ormance o an OLTP workload across multiple RAID 1volume sets

The next test ocused on measuring the impact o changing the number o database les whileholding the number o volumes xed. The variable le tests were per ormed on the OLTP databaseconsisting o 1, 4 and 8 database les per legroup provisioned rom a single RAID 1 volume.Figure 3 shows the relative per ormance o these three tests. From the test results we can observea small degradationa 4% decrease in per ormance when moving rom one le to eight lesin

the databases per ormance as the number o les increased.


10/22


50

60

70

80

90

100

110

8 Files4 Files1 File

RAID 1 Performance vs. Number of Files

R e

l a t i v e

T r a n s a c

t i o n s / S e c

OLTP Workload (Single RAID 1 Volume)

100 9896

Fig. 03: Relative per ormance o an OLTP workload with one RAID 1 volume and a variable number o database fles

These tests illustrate that the number o volumes selected has no measurable impact on theper ormance o SQL Server running on 3PAR Utility Storage. The second result shows that thenumber o database les has minimal impact on per ormance as well.

This demonstrates that high per ormance can be achieved without having to create and managea large number o volumes and les. IT administrators can achieve their desired per ormance

with a simplistic data layout, which results in quicker implementations, aster response to newrequirements, and lower overall cost o administration.

t s 3 r s s raId 5 s s raId 1

The purpose o this test was to test the per ormance o 3PARs RAID 5 implementation and comparethe results with the RAID 1 baseline to determine i the improved resource e ciencies associatedwith RAID 5 could be achieved without sacri cing database per ormance.

With traditional storage, RAID 1 is usually associated with providing noticeably higher per ormancethan RAID 5 since no parity calculation is required; RAID 5 is viewed as o ering lower per ormance

but is advantageous because ewer spindles are required to store the same amount o data. ITadministrators have traditionally had to weigh the tradeo s between higher per ormance andgreater capacity utilization when deciding on the optimal RAID con guration.

To understand the space savings o ered by RAID 5, consider the ollowing example: I RAID 1is implemented on data that lls three physical disks, then 6 total disks are requiredthree or theactual data and three or the mirrored data. I RAID 5 with a parity set o 3+1 is used, then only

our total disks are requiredthree or the actual data and one additional disk to store the parity


11/22


in ormation. This means that, or every two disks required in a RAID 1 implementation, only1.33 are required or RAID 5. I a parity set o 5+1 is used, then the number o disks required orRAID 5 (5+1) is urther reduced to just 1.2 disks or every 2 needed with RAID 1. These examplesshow that RAID 5 can o er signi cant capacity savings as compared to RAID 1. Un ortunately,traditional array users concerned with database per ormance o ten sacri ce the capacity savings

o ered by RAID 5 in avor o RAID 1s higher per ormance.

To determine the actual per ormance di erence between RAID 1 and RAID 5 on new storagearchitectures, this test measured the per ormance o the SQL Server database while running on

our di erent RAID 5 con gurations o the 3PAR array. The RAID 5 tests were per ormed on anOLTP database consisting o our database les per database that were provisioned on our RAID5 volumes. The results were compared against the RAID 1 baseline results consisting o ourdatabase les and our volumes. Additionally, to test the impact o the parity sets on SQL Serversper ormance, the RAID 5 parity ratio was tested at 3+1, 5+1 and 7+1.

Figure 4 illustrates the result o the three RAID 5 tests and how they compared against the RAID 1baseline measured in Test 2. When compared to the RAID 1 baseline, the tests revealed only a 3%reduction in per ormance when RAID 5 (7+1) was used. The per ormance between the di erentRAID 5 parity levels was minimalapproximately 4% di erent between RAID 5 with 3+1 and7+1 parity.

R e

l a t i v e

T r a n s a c

t i o n s

/ S e c

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: Per ormance o di erent RAID 5 parity levels normalized to theRAID 1 baseline per ormance

For this speci c test, we noted a slight increase in per ormance as the parity set size increased. Onereason or this change in per ormance can be attributed to the large number o reads used in ourOLTP workload compared to the number o writes. Because the number o spindles in our testremained constant, the higher parity set size reduced the amount o overall data per spindle, whichresults in slighter aster access times or read-intensive workloads.


12/22


On top o the near-equivalent per ormance, the usable storage space increases rom 50% in RAID1 to 87.5% in RAID 5 (7+1). To illustrate this bene t, Figure 5 shows the percentage o the diskspace available or actual written data, not mirrored or parity in ormation, or the our RAIDsettings analyzed in this test. Simple math shows that RAID 5 (3+1) results in a 33.3% reduction intotal storage needs over RAID 1 while RAID (7+1) can save 43%. The results o these speci c tests

show that 3PARs RAID 5 implementation o ers the customer running SQL Server nearly identicalper ormance to that o RAID 1 but with dramatic capacity savings. These results can be attributedto the act that 3PAR o ers hardware-accelerated, ast RAID 5 calculations.

D i s k U t i l i z a t

i o 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 o the disk space used per RAID type or actual data rather than or mirrored or parity in ormation

Deeper analysis o the RAID 1 and RAID 5 tests show a number o interesting observations. Figure6 shows a 15-minute sample o the total average disk trans er time or both the RAID 1 and RAID5 runs. The RAID 5 trans er time is higher than that o the RAID 1, which is to be expected sinceSQL Server is waiting on disk IO even during the RAID 1 tests and RAID 5 requires the overheado an additional read or parity calculations. This act is con rmed by examining the average bytesper second rom both the RAID 5 and RAID 1 con gurations as shown in Figure 7. The spikeo activity at both 2 minutes and 11 minutes in the gure correspond to the time when the SQL

Server checkpoint process is fushing dirty pages to disk. Examining Figures 6 and 7, in the RAID1 case we observe little i any increase in the trans er time but with a signi cant increase in diskthroughput. In the RAID 5 case, we detect the opposite; an increase in writes has a slight negativeimpact on both the trans er time and the RAID 5 disk throughput. Altogether, the gures belowalong with Figure 4 show RAID 5 results in only a 3% reduction in per ormance relative to RAID1 as observed by the client.


13/22


6

7

8

9

10

11

12

RAID 5RAID 1

A v e r a g e

M S / T r a n s f e r

OLTP Workload Average MS/Transfer vs. RAID Level

0 : 0 0

0 : 1 5

0 : 1 4

0 : 1 3

0 : 1 2

0 : 1 1

0 : 1 0

0 : 0 9

0 : 0 8

0 : 0 7

0 : 0 6

0 : 0 5

0 : 0 4

0 : 0 3

0 : 0 2

0 : 0 1

0 : 1 6

Fig. 06: RAID 1 and RAID 5 Average Disk Trans er Time

110

120

130

140

150

160

170

180

190

200

210

RAID 5RAID 1

M e g a b y t e s

/ S e c

OLTP Workload Megabytes/Sec vs. RAID Level

0 : 0

0

0 : 1

5

0 : 1

4

0 : 1

3

0 : 1

2

0 : 1

1

0 : 1

0

0 : 0

9

0 : 0

8

0 : 0

7

0 : 0

6

0 : 0

5

0 : 0

4

0 : 0

3

0 : 0

2

0 : 0

1

0 : 1

6

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


14/22


Based on these results, it is clear that 3PARs RAID 5 implementation o ers near RAID 1 per ormanceand can provide signi cant savings on the amount o storage required. Given the near-identicalper ormance to RAID 1, database administrators should give strong consideration to implementingRAID 5 more o ten when deploying SQL Server with 3PAR Utility Storage.

t s 4 r s s t i p isi i p SQl SThe intention o this test was to measure the impact o thin provisioning in concert with SQL Serverand its SQL Server Instant File Initialization eature during a typical OLTP workload scenario.

The SQL Server Instant File Initialization eature enables data les to be initialized instantaneouslywhen a database is created or the data les are added or changed. Traditionally, whenever adatabase le is created or changed, the le was initialized by lling it completely with zeros toremove any data le t on the disk rom deleted les. With Instant File Initialization, SQL Serverno longer writes zeros across the entire le to initialize it. This eature is critical to achieving themaximum bene t o thin provisioning on the storage array, which can help eliminate the problem

o allocated but unused storage since SQL Server with Instant File Initialization no longer writeszeros across the entire le up ront.

Thin provisioning is a storage solution with which IT departments are allowed to sa ely provisionas much logical capacity as is needed to meet the needs o a database application over the li etimeo the system; meanwhile, physical capacity is only allocated when a SQL Server write is initiatedthat actually requires additional physical storage. This dedicate-on-write so tware technologyallows users to purchase disk capacity based on their actual written data and then non-disruptivelyadd additional capacity when the application grows and requires additional storage. 3PAR ThinProvisioning with SQL Server Instant File Initialization can provide signi cant cost savings by

eliminating the need to purchase and allocate the storage at the time o the database deployment. Allo these capacity bene ts can be achieved while maintaining strong per ormance, as demonstratedby the ollowing results.

Note that Instant File Initialization is not used with log les because they must be ully initializedwith zeros to maximize per ormance and guarantee database recovery. The data les, whichrepresent the majority o the databases data, are dynamically created with Instant File Initializationto reduce the storage requirements and thus can bene t rom thin provisioning. These tests ocuson measuring the per ormance and bene ts o using thin provisioning with SQL Servers database

les.

The thin provisioning tests were per ormed on the OLTP database consisting o our databaseles per legroup provisioned rom our thinly provisioned RAID 1 volumes widely striped across

all disks in the system. The database was created with Instant File Initialization. The thinlyprovisioned database was populated in a way that mimicked a real-world scenario where an OLTPdatabase would grow over a period o time.

Our real-world scenario o creating a SQL Server database, illustrated in Figure 8, begins withthe quick provisioning o a 2-TB thin provisioned volume on the 3PAR InServ. At the start o Year 1, the server sees a standard, 2-TB volume, but because no data has been written to the thin


15/22


provisioned volume, no physical storage has been allocated or used yet. Early in Year 1, the SQLServer database le is initialed to a size o 200 GB, but, as a result o Instant File Initialization, nophysical storage is allocated rom disk yet. A 20-GB log is initialized at this time and consumes the

rst meaning ul amount o disk space. In our example, the database has a projected data growtho 500 GB per year.

DATABASEINITIALIZED

THIN VOLUMESALLOCATED 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 VOLUMES UNALLOCATED STORAGE

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

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

To simulate three years o growth, the database was set to autogrow at rate that resulted inapproximately 500 GB o new written data per year. As the data is steadily inserted by the datageneration client, the database les grow to accommodate the written data and consume onlyenough physical storage to store the new writes. At the end o Year 1, 500 GB o data was writtento the database and consumed only 500 GB o disk space rom the overall 2 TB o logical disk spaceavailable to SQL Server. This means that only a quarter o the originally allocated logical spacehad to be purchased in Year 1, resulting in signi cant cost savings. The database in this examplewill reach its target size o 1.5 TB a ter three years o production. As illustrated in Figure 8, thedatabase e ectively used thin provisioning to both delay and reduce the need or physical storage.

The per ormance o this database with thin provisioned volumes was measured and comparedagainst our baseline results rom Test 1 that used standard non-thin provisioned volumes onthe 3PAR InServ. Figure 9 shows the comparative results o the OLTP workload run against aset o ully provisioned volumes (i.e. standard provisioning) versus the per ormance results o thethinly provisioned volumes. The results o the test show that only a 4% reduction in SQL Serverper ormance occurred when using thin provisioned volumes, while much less storage was required

or the database over time. This example shows that 3PAR Thin Provisioning could reduce thetotal storage required while maintaining high per ormance, enabling the physical storage to bepurchased as needed over the three year time period rather than being purchased all up ront.


16/22


50

60

70

80

90

100

Full Provisioning vs. Thin Provisioning Performance

R e

l a t i v e

T r a n s a c

t i o

n s /

S e c

100

96

OLTP Workload (RAID 1)

Full Provisioned Thin Provisioned

Fig. 09: Relative per ormance o an OLTP workload with ully provisioned and thinly provisioned volumes

For DBAs and IT administrators, these results con rm that SQL Server behaves very well with thinprovisioned volumes with a minimal impact on per ormance. For environments where the databasehas consistent or predictable growth, thin provisioning can drastically reduce the up- ront storagecosts and enable users to only purchase additional storage when and i it is required or data growth.In addition, higher utilization rates mean less physical resources must be purchased, managed andmaintained by IT administrators, resulting in noticeably lower operational expenses.

t s 5 r s s mi W k

The purpose o the ollowing two mixed workload tests was to determine whether an applicationenvironment consisting o both random (OLTP) and sequential database disk activity can coexiston the same underlying physical spindles and still achieve satis actory per ormance.

t s 5 : mi -W k o

On traditional storage, IT administrators must pay care ul attention to how they lay out data onthe storage so that applications with di erent workload characteristics do not adversely impact theper ormance o other applications. The typical solution is to provide physical separation o mixedworkloads by allocating separate controller, cache and disk resources or sequential workloadsand random workloads. In many cases, storage vendors may advise separating these workloadsonto completely di erent arrays. This process can be quite time consuming and complex, as theIO characteristics o an application are o ten di cult to ascertain and predict, and the separationo ten 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 o I/O controlcommands rom the data movement. Unlike legacy architectures that process I/O commands andmove data using the same processor, 3PARs processing separation helps eliminate the per ormancebottlenecks o traditional systems when simultaneously serving competing workloads.


17/22


To measure the impact o 3PARs mixed-workload architecture on a shared SQL Server environment,a set o tests were conducted to measure and compare the per ormance o the SQL Server databaserunning alone versus running simultaneously with a large, sequential workload stored on the samephysical drives. The second test composed o the two workloads running together is re erred tolater as the mixed-workload. The workloads were automatically striped across all 240 drives

or both tests. By keeping the bene ts o massive parallelization constant in both tests, the uniquemixed-workload architecture o 3PAR Utility Storage can be examined.

The mixed workload used was a combination o the OLTP workload discussed in the previoustest cases and a new sequential workload. The OLTP database consisted o our database les per

legroup provisioned rom our RAID 1 database volumes. The sequential workload was run on asecond server that generated a constant and relatively heavy stream o data at a rate o 100 MB/Secin a series o reads and writes with a trans er size o 64 KB. The sequential and OLTP workloadswere run simultaneously with measurements taken to compare the average transactions per secondachieved or only the OLTP workload.

The results o this test are illustrated in Figure 10. The results show that the OLTP per ormanceon the 3PAR array decreased by only 16% when run simultaneously with a heavy, sequentialworkload, whose per ormance is not included in Figure 10. The 3PAR InSpire Architecture enablesboth o these workloads to coexist on the same physical drives with minimal impact on theirindividual per ormance. In addition to completing 106.9 transactions per second, relative to theother measurements, or the OLTP workload the 3PAR array also completed the I/Os o the heavysequential workload running simultaneously. Since such a combination o workloads generallyuses two separate arrays, the simplicity and cost savings o the 3PAR array is sel -evident.

60

70

80

90

100

110

120

130

140

R e

l a t i v e

T r a n s a c

t i o n s /

S e c

127.3

106.9

OLTP Performancewith OLTP Only Workload

(240 Drives)

OLTP Performancewith Mixed Workload

(240 Drives)

Mixed Workload Impact on OLTP Performance

Fig. 10: OLTP Per ormance when run alone and when run simultaneously with a sequential workload


18/22


t s 5 : mi -W k m ssi -p iz i

Finally, an additional set o tests were conducted to illustrate the combined bene ts o 3PARsmassive-parallelization and mixed-workload architecture. For this nal test case, the mixedworkload was run and measured on two di erent storage con gurations: an isolated con gurationand a shared con guration. In the isolated test case, the 3PAR InServ was con gured into

two separate pools o 120 disks with the rst pool dedicated to the OLTP workload and thesecond pool dedicated to the sequential workload. The shared disk case is the same testdiscussed previously where the OLTP per ormance was measured when the mixed workload wasloaded on a shared pool o 240 disks. Figure 11 illustrates these two storage con gurations.

SHARED DISKSSHARED DISKS

OLTP ANDSEQUENTIALWORKLOADS(240 DISKS)

ISOLATED DISKSISOLATED DISKS

SEQUENTIALWORKLOAD(120 DISKS)

OLTPWORKLOAD(120 DISKS)

Fig. 11: Storage confguration or results in OLTP mixed workload per ormance tests

The results rom this test o the mixed-workload run in an isolated storage con guration and thena shared con guration is illustrated in Figure 12. The results show that the OLTP per ormancewithin the shared storage con guration proved to have an 11% advantage in per ormance over theisolated disk con guration. By allowing the 3PAR array to automatically stripe both workloadstogether across all 240 disks (versus isolating each workload to a di erent group o 120 drives orthe isolated con guration), the OLTP workload saw a noticeable increase in per ormance over thetraditional method o carving out isolated disks to store only the OLTP data (note that segregatingworkloads is the standard practice on legacy storage arrays).


19/22


106.9

60

65

70

75

80

85

9095

100

105

110

R e

l a t i v e

T r a n s a c

t i o n s /

S e c

96.3

OLTP Performancewith Mixed Workload(Isolated - 120 Drives)

OLTP Performancewith Mixed Workload(Shared - 240 Drives)

Mixed Workload and Massive Parallellization Performance

Fig. 12: OLTP per ormance in a mixed-workload environment using isolated versus shared storage confgurations

The results o this second test illustrate that the wide striping and mixed-workload architectureo ered by 3PAR Utility Storage help OLTP workloads per orm better when deployed in a sharedenvironment versus using isolated storage con gurations, even when the shared drives are also beingused by an active, sequential workload. In addition to the per ormance bene t, the shared storagecan help reduce the time spent planning data layouts and can simpli y the storage provisioning andmanagement.

concluSIonBased on the results o these tests per ormed or a joint customer, Microso t and 3PAR were ableto demonstrate con guration optimizations that yielded high SQL Server per ormance, low storagecosts, and simple management. The tests were able to demonstrate:

hi p

3PARs parallelized architecture widely stripes data, leveraging the cumulative IOPS o all o

the systems drives rather than allocating a limited number o drives to a given application

hi r s u i iz i

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

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

Fast RAID 5 implementations on 3PAR InServ arrays can signi cantly reduce storage costs

while maintaining per ormance levels comparable with RAID 1.


20/22


r S p isi i m c s s

Database administration costs and simpli ed database layouts are made possible by using

ew storage volumes and database les.

Reduced time and e ort to provision volumes resulted rom leveraging 3PARs massive

parallelization.

Straight orward and uncomplicated per ormance tuning o storage was achieved by

automatically striping mixed workloads across the entire InServ array.

about 3par

3PAR (NYSE: PAR) is the leading global provider o utility storage, a category o highly virtualizedand dynamically tiered storage arrays built or public and private cloud computing. Our virtualizedstorage plat orm was built rom the ground up to be agile and e cient to address the limitationso traditional storage arrays or utility in rastructures. As a pioneer o thin provisioning and other

storage virtualization technologies, we design our products to reduce power consumption to helpcompanies meet their green computing initiatives and to cut storage total cost o ownership. 3PARcustomers have used our sel -managing, e cient, and adaptable utility storage systems to reduceadministration time and provisioning complexity, to improve server and storage utilization, and toscale and adapt fexibly in response to continuous growth and changing business needs. For morein ormation, visit the 3PAR Website at: www.3PAR.com.

2009 3PAR Inc. All rights reserved. 3PAR, the 3PAR logo, Serving In ormation, InServ, InForm, InSpire, and Thin Built In are all trademarks or registered trademarkso 3PAR Inc. Microso t, SQL Server 2008, SQL Server are trademarks o the Microso t group o companies. All other trademarks and registered trademarks are theproperty o their respective owners.


21/22


appendIx a

t s c i i d i s

The host-side o the test system was composed o a database server, a client load server and a mixedIO workload server. The volumes presented to the database and mixed IO workload servers wereconnected through two 4Gb/sec HBAs, each o which was load balanced in a round robin ashionwith the Microso t MPIO and Device Speci c Module.

Server Specifcs 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 bre channel drives. Thespeci cs o the storage system used or the tests are summarized in the ollowing table:

3PAR S400 Features SQL Server LabConfguration Maximum Supported

3PAR InForm OS Version 2.2.4 -

Number o 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 o Drive Chassis 6 chassis 16 chassis

Number o Drive Magazines 60 mags 160 mags

Number o 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 -


22/22

u.S. corporate headQuarterS

3PAR Inc.

4209 Technology DriveFremont, CA 94538Phone: 510-413-5999Fax: 510-413-5699

Email: salesin [email protected]

3par sqlserver wp 09.0

Documents