EVA4400 Performance.pdf

HP StorageWorks 4400 Enterprise Virtual

Array (EVA4400) 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 midsize to enterprise-size

customers leading performance, high-capacity, and high-availability storage solutions for reducing 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 4400 Enterprise Virtual Array (EVA4400).

Though the EVA4400 has many useful attributes and features, one important but basic attribute is its

excellent I/O performance. The EVA4400 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 will 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 EVA4400

•

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 (1) the workload to which the array subjected,

(2) the configuration of the array, and (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 of storage will see 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 HP’s 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’s 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 ensures that the properties of only the array are being

determined and not the properties of something else, such as a server, a switch, or some host bus

adapter. 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 never 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 because

they are

•

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 eliminating

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 will 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 4400 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 EVA4400 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 filesystems, transaction-orientated

databases, or email applications.

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

delivered by the EVA4400 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 EVA4400 for three

workloads:

•

Read requests

•

Write requests

•

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

All random workloads used 8 KB request lengths.

Figures 2 and 3 are similar to Figure 1 except that all workloads target RAID 5 storage or RAID 6

storage, respectively.

Figures 4, 5, and 6 show the relationship between average throughputs and response times for large-

block sequential workloads, targeting RAID levels 1, 5, and 6, respectively. Each of these figures

shows two curves, one for sequential read workloads and one for sequential write workloads. In every

case, 128 KB request sizes were used.

In Figures 4 through 6, the cache algorithms used by the EVA4400 result in very high data transfer

rates at very low response times. This illustrates the importance of a disk array’s cache and the

algorithms used for managing it. Although we are seeing the effects of cache in the measurements

shown, these effects are included as part of the end-to-end performance measurements.

Figure 1. Random IO Performance for RAID 1 8 KB Transfers

Reads

Wr i t es

OLTP

5000

10000

15000

20000

25000

30000

35000

Throughput (IO/s)

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: