Overview
Introduction The EMC VNX series storage platform provides the following LUN provisioning options:
Pool LUNs
o Thick LUNs (Fully provisioned pool LUNs) o Thin LUNs
o Compressed LUNs RAID group LUNs
There are several ways to build an FC LUN on an EMC VNX series array. The traditional way used for the CX4 series of storage arrays required a user to specify a RAID group and then allocate all the space required for a LUN immediately. This is called a RAID group LUN. The CX4 series of arrays combined with FLARE® 30 introduced the concept of a storage pool, and by extension, a pool LUN. Pool LUNs can be fully provisioned, like a RAID group LUN, with all the space reserved
immediately. They can also provision space as needed. This is called a thin pool LUN. The equivalent of a fully provisioned pool LUN is commonly referred to as a thick pool LUN.
Pool LUNs enable you to take advantage of several features that were introduced with FLARE 30 like compression and FAST. For the VNX series of storage, the default recommendation is to provision LUNs as thick pool LUNs.
Compression is an attribute that can be enabled or disabled on each LUN. It can reduce storage costs significantly and is ideal for datasets that have low
performance requirements. Compression is also flexible because it is implemented at the LUN level, which can be applied to any data type that resides on the array.
This chapter compares the performance of Microsoft SQL Server 2008 when using each of these LUN types. The chapter also examines the snapshot performance for pool LUNs and RAID group LUNs.
Contents This chapter contains the following topics:
Topic See Page
Overview 34
Testing tools 35
Methodology 35
Test results summary 35
Results analysis 36
Testing tools
Introduction To test the SQL Server 2008 environment, the Quest Benchmark Factory tool, designed by Quest, was used.
Quest Benchmark Factory
The ―Quest Benchmark Factory‖ section on page 23 provides more information on Quest Benchmark Factory.
Methodology
Introduction This section explains the testing methodology used. This testing used a single database with 5,000 TPC-C warehouses. This resulted in a database with approximately 400 GB of active data.
Testing
methodology 1
This methodology was used for the performance scaling test. Virtual users were added to this environment in periodic increments. The testing was stopped after the average transaction response time breached the gating metric of 2 seconds.
For each load level, a series of virtual users was started in the test environment.
Based on the user parameters, each user was expected to generate a certain TPS load under ideal circumstances. In the graphs, this is denoted on the horizontal axis as the Projected TPS for the load. It was expected that the achieved TPS will be below this level for any significant load on the system.
Unless otherwise noted, the scaling run was repeated at least twice with only minor differences observed between the runs.
Testing
methodology 2
This methodology was used for the snapshot performance test. A constant user load (approximately 25 percent of the saturation user load) was run. During the test run, the snapshot operation was triggered so that the impact of the operation on the production could be seen. In this solution, four snaps were taken at an interval of one hour duration. The duration of the constant user load test was selected such that it accommodated the completion of the snapshot operation in its window.
Testing results summary
Results summary
The following table summarizes the test results. The performance of different LUN types was compared with the performance of thick pool LUNs.
Method Impact
Thick pool LUNs baseline
Thin pool LUNs <1%
RAID group LUNs (+) 16.12%
Compressed pool LUNs (-) 4.57%
NOTE: CX4-480 RAID group LUNs were almost 8 percent slower than the VNX5700 RAID group LUNs.
Result analysis
Introduction This section provides the result analysis for the following test scenarios:
Thick pool LUNs Thin pool LUNs RAID group LUNs Compressed pool LUNs
Configuration The configuration for all the scenarios used in this test was 20 SAS drives (16 RAID 10 for database and four RAID 10 for log).
Setup The ―Setup‖ section on page 25 provides the server configuration.
The following figure shows the storage configuration that is specific to this test scenario:
The configuration used 300 GB 15k rpm SAS spindles.
NOTE: The shelf positioning in the diagram is for illustration purposes only.
Components in the presented solution do not require a specific location within the DAE or cabinet. The drive positioning must be based on published best practices as they apply to your individual environment.
Testing results Performance study – LUN provisioning options
This section presents the performance results achieved with each type of LUN along with the details of the actual storage space consumption on the array.
In the validated solution, four LUNs were provisioned from the database pool to the SQL server, each with a user capacity of 200 GB and containing 131 GB of data. The total amount of consumed space on the database pool varies depending on the type of LUN provisioned from that pool.
Thick pool LUNs
When thick pool LUNs were provisioned, the consumed capacity of the database pool was nearly 800 GB. The consumed capacity of the database changes with the provisioning options. This is discussed in the following sections.
Thick pool LUNs achieved a maximum of 1,247 TPS before becoming saturated based on the gating metric.
Thin pool LUNs
When thin LUNs were provisioned, the consumed capacity of the database pool reduced to 552 GB, giving 248 GB of space to the pool. However, the host still viewed 200 GB of space on all four LUNs.
Thin pool LUNs achieved a maximum of 1,243 TPS before becoming saturated based on the gating metric.
These results indicate that thin LUNs perform almost equal to thick LUNs while providing additional space savings.
Compressed LUNs
When compression was enabled on thin LUNs, the consumed capacity of the database pool reduced from 552 GB to 492 GB, saving 60 GB of space with a compression ratio of 0.89.
Compressed pool LUNs achieved a maximum of 1,190 TPS before becoming saturated based on the gating metric. The degradation was less than 5 percent compared to thick pool LUNs, which is trivial considering the compression overhead.
RAID group LUNs
RAID group LUNs consume the same amount of space as the user capacity seen by the host server.
RAID group LUNs achieved a maximum of 1,448 TPS before becoming saturated based on the gating metric. RAID group LUNs performed nearly 16 percent better than thick pool LUNs.
The following two graphs show the performance comparison between the thick pool LUNs, thin pool LUNs, RAID group LUNs, and compressed LUNs.
The supported TPS and response times are given in the following table:
Scenario Max TPS
Avg Response
Time (s)
Percent TPS improvement / decline when compared to
thin LUNs
Thick pool LUNs 1,247 0.9 --
Thin pool LUNs 1,243 0.9 (-) 0.32
RAID group LUNs
(VNX5700) 1,448 1.8 (+) 16.12
RAID group LUNs
(CX4-480) 1,331 1.7 (+) 6.73
Compressed LUNs 1,190 1.7 (-) 4.57
In the tested environment, thin pool LUNs showed very minor performance decrement compared to thick pool LUNs, while compressed LUNs showed a marginal 4.5 percent decline.
The performance of VNX5700 RAID group LUNs was nearly 16 percent better, whereas the performance of CX4-480 RAID group LUNs was 6.7 percent better than VNX thick pool LUNs.
Conclusion Thick pool LUNs perform well in SQL OLTP environments and are a good choice to start with. These can be converted to thin LUNs at a later point of time with minimal impact, if more efficient space management is required. If further space savings is required, compressing the LUNs is a good option. But this comes at the cost of reduced performance.
However, if there are stringent performance requirements that outweigh the
functional benefits of pool LUNs, it is recommended to provision RAID group LUNs in the environment.
Snapshot performance study – pool LUNs (Thick, Thin, and Compressed) as compared to RAID group LUNs
Testing results This section examines the snapshot performance of different LUN types. The impact due to copy on first write (COFW) operation is observed and the time taken for each LUN type to settle back to the baseline value is noted.
Thick pool LUNs
There was no significant degradation in the TPS value due to the snapshot operation.
After the snapshot was initiated, the database disk latency shot up almost 10 times the normal value and then gradually came down. It took almost 2 hours and 30 minutes to come back to the baseline value from the last snapshot.
Thin pool LUNs
Thin pool LUNs also performed similar to thick pool LUNs. After the snapshot was initiated, the database disk latency shot up almost 10 times the normal value and then gradually came down. It took almost 3 hours and 30 minutes to come back to the baseline value from the last snapshot.
Compressed LUNs
There was no significant degradation in the TPS value even in this case. After the snapshot was initiated, the database disk latency shot up almost 15 times the normal value and then gradually came down. It took almost 3 hours and 30 minutes to come back to the baseline value from the last snapshot.
VNX5700 RAID group LUNs
After the snapshot was initiated, the database disk latency shot up almost 10 times the normal value and then gradually came down. It took around 1 hour and 15 minutes to come back to the baseline value from the last snapshot.
CX4-480 RAID group LUNs
After the snapshot was initiated, the database disk latency shot up almost 10 times the normal value and then gradually came down. It took around 4 hours and 30 minutes to come back to the baseline value from the last snapshot.
The following table compares the snapshot performance of different LUN types.
LUN type Avg DB disk latency before the snap
Impact of snapshot on baseline (approx)
Settling time (approx)
Thick pool LUNs 7 ms 10x 150 min
Thin pool LUNs 10 ms 10x 210 min
RAID group LUNs
(VNX5700) 11.5 ms 10x 75 min
RAID group LUNs
(CX4-480) 12 ms 10x 270 min
Compressed LUNs 30.5 ms 15x 210 min
The thick pool LUNs perform better than the thin pool LUNs in terms of settling time.
Settling time is the time taken for the database disk latency to come back to the baseline value after a snapshot is taken.
The settling times for all the LUN types of VNX5700 are better than those of the CX4-480 RAID group LUNs.
The impact of the snapshot due to COFW operation is almost the same in all scenarios except for the compressed LUNs. In the compressed LUN scenario, there are large spikes in the disk latency, which is expected due to the extra processing required for compressing/uncompressing the data.
Conclusion Thick pool LUNs perform well with snapshots in a SQL OLTP environment and are a good choice to start with. These can be converted to thin LUNs at a later point of time with minimal impact, if there is a need for more efficient space management. If further space savings is required, compressing the LUNs is a good option. But this comes at the cost of reduced performance.
However, if there are stringent performance requirements that outweigh the
functional benefits of pool LUNs, it is recommended to provision RAID group LUNs in the environment.