Upload
dinhanh
View
248
Download
0
Embed Size (px)
Citation preview
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
3PAR AND MICROSOFT WHITE PAPER2009
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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).
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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.
Manageability and Performance Benefits of 3PAR Utility Storage in a Microsoft SQL Server Environment
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