EVA6400 Performance.pdf

HP StorageWorks 6400 Enterprise Virtual

Array (EVA6400) Performance

White paper

Table of contents

Introduction......................................................................................................................................... 2

Sizing up performance numbers ............................................................................................................ 2

End-to-end performance numbers ....................................................................................................... 3

Cache performance numbers............................................................................................................. 4

Performance summary .......................................................................................................................... 4

Conclusion.......................................................................................................................................... 9

For more information.......................................................................................................................... 10

Introduction

The HP StorageWorks Enterprise Virtual Array (EVA) product family offers leading performance,

high-capacity, and high-availability storage solutions to midsize and enterprise-size customers to help

them reduce their IT costs and complexity. The EVA provides virtualized storage, enabling capacity

pooling, simplified management, automatic performance load-balancing, dynamic configuration, and

reconfiguration. Continuing to build on this success is the HP StorageWorks 6400 Enterprise Virtual

Array (EVA6400).

Though the EVA6400 has many useful attributes and features, one of the most important and basic

attribute is its excellent I/O performance. The EVA6400 achieves this performance under both

transaction-oriented workloads and sequential workloads. One purpose of this paper is to describe

this I/O performance quantitatively by showing the results of direct measurements made on the array

using different RAID types and workloads.

Performance numbers without context yield no useful information. In fact, these numbers may cause

misunderstandings about the performance that a storage system can actually achieve when it is

deployed in a production environment. Such misunderstandings can be expensive in terms of both

equipment and human resource costs. So, a second purpose of this paper is to provide some context

surrounding the performance numbers.

This white paper includes:

 A high-level discussion about performance numbers in general, including a discussion about the

usefulness (or lack thereof) for capacity planning purposes of cache-only performance numbers

versus end-to-end performance

 A summary of performance results for the EVA6400

Sizing up performance numbers

The HP StorageWorks research and development (R&D) philosophy embodies two important tenets:

 Create products that deliver value and quality to the customer. This tenet guides HP decision-making

for deploying cutting-edge technology.

 Build trust by using testing procedures that, within normal engineering constraints, customers can

verify and repeat at their place of business. Many HP customers refer to HP as their “trusted

advisor” and have “bet their business” on HP technology. HP enables customers to substantiate any

claims by using test procedures that they can repeat and verify at their site.

When reporting performance numbers for an array, HP has found that the most useful numbers for

customers are those associated with workload, configuration, and other characteristics that tie directly

to actual business conditions. Obtaining such numbers is an extremely difficult task because the

performance of any disk array depends strongly on the following conditions:

1.The workload to which the array subjected

2.The configuration of the array

3.The configuration of the SAN to which the array is connected

There are at least as many different workloads as there are users of storage so that no single set of

performance numbers can be used to describe what every user sees when an array is deployed in

their environments. The configuration of the array is important, for example, because different RAID

levels result in different performance characteristics for the same workload. Configuration of the SAN

plays a role because some configurations force performance bottlenecks to exist outside the array.

Despite all this complexity, experience garnered while working with its large base of storage customers

has allowed HP performance engineers to identify a small set of workloads and configurations that

expose some of the most important performance characteristics of a disk array. These workloads and

configurations are used to derive all of the performance numbers shown in this paper.

With respect to SAN configurations, HP disk array performance engineers perform all measurements

on their arrays when no element of the SAN can be a performance bottleneck, with the exception of

the array being studied. This process verifies that the properties of only the array—and not something

else, such as a server, a switch, or some host bus adapter—are determined. The performance

measurements shown in the section entitled Performance summary were obtained with a test setup that

satisfies this criterion.

Another important aspect of the measurement results shown in this paper is that the average

throughputs and average response times reported correspond to steady-state behavior. Transient

effects, such as those caused by empty write caches—which skews throughputs up and response times

down dramatically—are not a part of any of the measurements. The steady-state condition implies that

all measurement results are indicative of sustained performance, even regarding performance

associated with 100% cache accesses.

For the purposes of this paper, HP refers to the performance numbers that exercise both the normal

data path and the normal code path as “end-to-end” performance numbers. A normal data path

includes the array’s Fibre Channel connections to servers, cache, internal buses, and disk drives. The

normal code path includes software or firmware running on an array’s controllers that moves user

data between its disk drives and the servers that connect to the array. “Cache” performance numbers

are those obtained from 100% cache-only accesses, which, by definition, do not represent the effects

of the additional loads placed on a disk array’s components when moving data between servers and

the disks of the disk array.

End-to-end performance numbers

End-to-end performance numbers reflect typical data and code paths exercised in an array when that

array is deployed in a customer environment. These numbers are an excellent choice for capacity

planning when obtained under two additional engineering constraints.

First, when evaluating performance under random workloads, HP recommends using uniform

probability to access most, if not all, of the usable array capacity. Such measurements are more

accurate than “short-stroking (destroking),” a configuration that allows each disk to access only a

small fraction of its capacity, thus inflating throughputs artificially. Measuring performance by

accessing all of an array’s capacity leads to sizing estimates that will not become obsolete over time

as the customer consumes more of the array’s capacity.

The second constraint applies to the recognition from HP that it is meaningless to talk about

throughputs that an array can deliver without specifying the average response time at which that

throughput is measured. This is so much more than just a statement targeted at scientists because

response times are very important, sometimes critical, to customers and their business applications.

For this reason, HP publishes “end-to-end” throughputs at average response times of less than or equal

to 30 milliseconds. The maximum average response time of 30 ms is high for most customers under

transaction-based workloads (15 ms is often quoted as being high for many such applications), but it

is used in case such high response times are acceptable to some users. Because cache numbers are

not useful from a customer-deployment point of view, HP does not apply this response-time constraint

to cache-only throughputs.

HP best practices recommend using end-to-end performance numbers for capacity planning for the

following reasons:

 Measurements that can be used for sizing in a real-life business condition

 Easy to verify at the customer site using a reasonable “black box approach” by removing

bottlenecks outside the array and balancing the load across an array’s controllers and host ports

End-to-end performance numbers provide customers with the best data to determine which array

configurations make the best business, technical, and financial sense.

Cache performance numbers

Cache performance numbers register the largest throughputs possible with an array when no disk

accesses occur. Therefore, they do not reflect the performance of a disk array under normal business

conditions, rendering them useless for ascertaining whether a given array will meet a customer’s

performance requirements. This means that they are useless for purposes of capacity planning.

Such cache-only workloads place a lighter load on an array’s internal buses than would exist at a

customer site. Exercising only a part of an array’s data and code paths does not reflect actual response

times or latencies that normally occur because the cache-only data path is shorter than the normal data

path. These paths are those used when 100% of all I/O requests are satisfied from the array’s cache,

with no disk accesses occurring. Cache performance numbers are unsustainable in day-to-day

operations, though exceptions occur momentarily, and show up as short-lived transients.

Cache serves as an intermediary between the servers and the disk drives. When viewed separately,

cache performance numbers provide an artificial view of an array’s performance capabilities. What is

most important about cache performance is the interaction of the cache with a disk array’s disk drives.

Because disk overload is a highly likely consequence of using cache performance numbers for

capacity planning, HP best practices do not recommend using such numbers.

Performance summary

In this section, a summary of the performance of the HP StorageWorks 6400 Enterprise Virtual Array

is provided. The summary is based on actual measurements made for a number of select workloads

and RAID levels. Since the vast majority of EVA customers use EVAs to service large-block sequential

workloads or small-block random workloads, we focus on the performance of the EVA6400 under

these workloads.

The large-block sequential performance information is most relevant to customers who care about data

transfer rates (MB/s), which is often the case when their applications perform data warehousing,

streaming video, high-performance technical computing, backups, and restore functions. The

small-block performance information is most relevant to customers who care about throughputs (IO/s

or IOPS), which is often the case when their applications are file systems, transaction-orientated

databases, or email applications.

Figures 1 through 6 show the relationships between the average response time and the throughput

delivered by the EVA6400 for several workloads and RAID levels. Customers can use these curves to

consider the tradeoff between increased throughput and the resulting increased average response time.

In Figures 1 through 3, the 60% read workload is what HP calls the OLTP workload.

Figure 1 shows curves for random workloads directed at RAID 1 storage on the EVA6400 for

three workloads:

 Read requests

 Write requests

 60% reads and 40% writes (labeled as OLTP)

All random workloads used 8 KB request lengths.

Figure 1: Random IO Performance for RAID 1 8-KB Transfers

Reads

Writes

OLTP

Reads

Writes

OLTP

10,000

20,000

30,000

40,000

50,000

60,000

70,000

Throughput (IO/s)

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: