Redpaper

Ed Moffatt

IBM SAN Volume Controller 8A4

Hardware: Performance and Scalability
with the IBM System Storage DS3400

In this IBM® Redpaper™ publication, we discuss the performance and scalability of a storage
area network (SAN) environment that is based around IBM SAN Volume Controller (SVC)
8A4 hardware and IBM System Storage™ DS3400 storage controllers.

We discuss performance, in terms of I/O per second (IOPS) and MB per second (MBPS), that
can be achieved from a single I/O group of SVC 8A4 nodes. By focusing on cache hit I/Os, we
demonstrate that the entry level hardware can achieve significant performance benefits in a
SAN, thereby offering a suitable alternative to the 8G4 for mid-sized businesses.

In addition, we discuss the performance of IBM DS3400 storage controllers virtualized by an

8A4 cluster. We consider the best RAID configuration for logical unit numbers (LUNs) on the
back end and look at the performance that can be achieved on disk reads and writes (cache
misses). We examine the relative performance of a SAN with one, two, and three DS3400
controllers managed by the SVC, and thereby demonstrate the effectiveness of the SVC 8A4
and DS3400 as a scalable solution.

Background
8A4 is the name for the SVC Entry Edition model that was announced in October 2008. The
SVC software that it runs is the same code that runs on all SVC nodes. The hardware has
been modified to make it a more viable and cost-effective solution for mid-sized businesses. It
uses a single socket variant of the Intel® Xeon platform that all other SVC hardware uses.
Each node has 8 GB of cache and a Dual Core 3.0 GHz Xeon CPU. The SAN interface
remains the same as for other node types with four 4 Gbps Fibre Channel ports. Because the
software running on an 8A4 is the same as on other node types, the dual core CPU achieves
the same benefits of binding, lock elimination, and performance enhancements, thereby
boosting the I/O throughput of a SAN and reducing response times.

© Copyright IBM Corp. 2010. All rights reserved. ibm.com/redbooks 1

 In comparison with the 8G4 node, the most notable difference of the 8A4 is a reduced
bandwidth of internal memory. The 8A4 uses a single socket Intel Xeon® platform, where the
8G4 has a dual socket platform, meaning that the 8A4 can provide about 60% of the
bandwidth of an 8G4, at roughly 60% of the cost.

On the basis of these hardware differences, we expect 8A4 nodes to be capable of less
impressive performance than 8G4s or CF8s (the other two current SVC hardware types), but
still offer considerable benefit to mid-sized businesses. By benefit, we mean that installing an
8A4 cluster in your SAN can lead to considerable performance increases (as well as the
management and maintenance benefits that we do not measure quantitatively in these tests).
In addition, by installing such a cluster in your SAN, you gain the ability to scale out the
storage that is managed underneath the SVC, while observing improved performance when
you add storage controllers.

Hardware and test details

All results presented in this paper were obtained through tests by using the same two-node
cluster of 8A4 SVC nodes, running SVC 5.1.0.0 code. The I/O was driven by an
IBM System p® host with thirteen IBM POWER5™ processors, 26 GB of physical memory,
and eight 4 Gbps FC ports. All of the DS3400s used were the dual-controller model, with
three EXP3000 expansion drawers attached, for a total of 48 15,000 RPM SAS drives each.
The drives were a mixture of sizes between 73.4 GB and 146.8 GB hard disk drives (HDDs).

The I/Os were run at the cluster with three different block sizes: 512 B, 4 KB, and 64 KB.
Queue depths were increased until we saw response times go over 30 ms. Anything with a
longer response was judged inappropriate for customer practical use cases. In such a case,
any increases in IOPS or MBPS that we saw might not be true performance improvements for
a data center, because we might wait too long for the I/O to complete.

I/O can be either sequential or random. For cache hit tests, sequential I/O can be used.
However, we used random I/O for cache misses, because the SVC starts to prefetch data if it
detects that sequential operations are performed.

Terminology
The following terminology is useful in understanding how physical SAS drives in back-end
storage relate to the devices to which the host performs I/O and to the role of the SVC in
virtualizing and managing these devices. We begin at the lowest level (individual HDDs) and
move up to the highest level (devices used by the host).
Physical disks A DS3400 enclosure contains one or two controllers and several SAS
drives. The number of disks available to a controller can be increased
by attaching expansion drawers to the controller.
RAID arrays The DS3400s present their disks to the SVC as RAID arrays (RAID10
or RAID5 in this testing).

Note: Because we are not interested in a configuration that does

not provide both striping and HDD failure protection in a data
center, RAID10 and RAID5 are the most viable RAID types to use.

The controller uses the relevant RAID algorithm to arrange extents

from one of more disks into logical units (LUs). Each controller in our
testing presented the SVC with 11 LUs.

2 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400
 MDisks SVC refers to LUs that it has been presented with as managed disks
(MDisks). The MDisk is distinct from the LU because it is the SVC
reference to the LU rather than the array that exists on the storage
controller.
MDisk groups Administrators can use the SVC to arrange MDisks into MDisk groups.
These groups are pools of storage that can span some or all of the
MDisks that are presented by one or more controllers in the back end.
For the one and two controller tests, we used four MDisk groups.
When the third controller was added, we increased the number of
MDisk groups to six MDisk groups to ensure a wider striping of extents
across the back end.
VDisks Virtualized disks (VDisks) are created from the MDisk groups (pools of
capacity). The SVC presents the VDisks to the host.
HDisks We used AIX® hosts. The VDisks that the SVC presents through a
Fibre Channel to the host are referenced by AIX as HDisks. AIX
manages volume groups, logical volumes, and multipathing to these
devices, but an explanation of these concepts is not within the scope
of this paper.

RAID5 scalability comparisons

In this section, we consider the performance of reads and writes first for RAID5 and then for
RAID10. The I/O was randomized to avoid data prefetching by the SVC and boosting
performance that way. In doing so, we were able to gain a clearer idea of how the back end
was performing.

Performance is measured by two metrics, which are considered in separate charts. We can
aim to optimize either the number of IOPS or the throughput in MBPS. The following charts
show the best results that were achieved. For detailed results and a comparison of
performance with different block sizes, see “Tables of the results” on page 9.

Figure 1 on page 4 shows the RAID5 disk read IOPS. This chart shows that the throughput is
reaching its optimal point for one and two controllers. There is a point on the curve where the
second differential reaches its maximum. After this point, we incur more of a cost in terms of
increased response time for every throughput gain that we manage to achieve from the SAN.
For one controller, this point happens at around 18,000 or 19,000 IOPS. For two controllers,
we just reach it at the highest tested queue depths, which is around 38,000 IOPS. At our
highest queue depth, we had not yet managed to reach this point for three controllers, but a
continuation of the graph’s trend might suggest that we may see another linear increase with
the addition of a third controller.

Therefore, the chart in Figure 1 on page 4 shows evidence of the linear performance scaling
that we expect. It also indicates that the addition of more controllers will allow for much higher
I/O queue depths before we start seeing any noticeable impact to our response times.

IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400 3
 Figure 1 RAID5 disk read IOPS

Figure 2 shows RAID5 disk read MBPS. Larger block sizes are less tolerant of over queuing,
but this chart still shows similarly shaped curves to the IOPS chart. We can achieve about
560 MBPS from a single controller, 1000 MBPS from two controllers, and 1500 MBPS from
three controllers, demonstrating neat and linear performance scalability on disk reads when a
data center must obtain high volume throughput. Fewer results are in the data set for three
controllers simply because of time constraints. We went straight to the optimal queue depths
rather than testing all of the lower ones to demonstrate a smooth curve, because this had
already been shown for one and two controllers.

Figure 2 RAID5 disk read MBPS

4 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400
 Figure 3 shows RAID5 disk write IOPS. As we might expect, throughput for disk writes is
significantly lower than on reads. We also observe that fewer I/Os can be queued up before
response times become large. The chart clearly shows a progressive and even performance
increase as we add controllers. The best result with one controller was 3761 IOPS with a
response time of 8.506 ms. Because I/O was random in these tests, we cannot be sure of
even, wide usage of our SAS drives in each result set. We might expect somewhere around
11,000 IOPS from the three controllers to demonstrate totally linear scaling. We observed
10,876 IOPS, which is achievable with a response time of 1.467ms.

We do not see such ideal curve shapes (“hockey-stick-shaped” curves) in our write results,
because of the nature of the testing that was done. Our host simply drives the I/O as hard as
it possibly can. Therefore, even with the minimum queue depth tested, it was already driving
the I/O hard enough to have passed the point of the curve where performance was rapidly
increasing. If we wanted to show similar curve shapes to our read results, it might be a case
of forcing the host to drive fewer writes.

Figure 3 RAID5 disk write IOPS

IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400 5
 Figure 4 shows the RAID5 disk write MBPS. Emphasis on MBPS performance is achieved by
performing the I/O with a larger block size. In this chart, we see scaling similar to what we
observed with IOPS. The scaling indicates that adding DS3400 controllers underneath an
8A4 cluster offers performance scalability on writes, regardless of the metric that we use.
Notice that there are fewer results for one controller because we achieved the expected result
quickly. Therefore, there seemed no point in ramping up our queues because we were
already close to the 30 ms response time threshold that we set for validity of the results. The
reasons for not seeing “hockey-stick-shaped” curves are the same as for write IOPS.

Figure 4 RAID5 disk write MBPS

RAID10 scalability comparisons

For RAID10 disk reads, we have good results for two controllers. Yet we must remember that
the I/Os are random and that performance depends on load distribution across the SAS
drives. However, we can see that performance is scaling linearly as we add the additional
DS3400s.

Figure 5 on page 7 shows the RAID10 disk read IOPS. The data set looks slightly unusual for
two controllers (less spread out than the others). This result is because the test was run when
we already had a shrewd idea of the optimal queue depth, and therefore, it was not necessary
to test such a wide range of values.

For reads, RAID10 and RAID5 are a lot closer to each other than on writes. With one
controller, we see that RAID5 marginally outperforms RAID10. Again, we attribute this to the
randomness of the I/O. However, as we add to the back end, RAID10 overtakes RAID5 as the
true performance deficits are scaled up accordingly, meaning that we are about 15% up on
the RAID5 number of reads when testing with three DS3400s.

6 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400
 Figure 5 RAID10 disk read IOPS

Figure 6 shows the RAID10 disk read MBPS. For MBPS read performance, RAID5 again
comes close, but RAID10 still slightly outperforms it. This chart clearly shows both the linear
performance scaling that we expect and the optimal point on each curve before response time
increases start to outweigh performance gains. For all three data sets, the optimal point is
achieved with a response of around 15 ms and queues of roughly 10 I/Os to 20 I/Os.

Figure 6 RAID10 disk read MBPS

IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400 7
 Figure 7 shows the RAID10 disk write IOPS. Configuring RAID10 arrays on our DS3400
controllers for this test allows for almost 175% of the throughput of a RAID5 configured
back end. Therefore, clearly RAID10 is a better option for high IOPS throughput. We verify
this later with read I/Os.

We see that our best results for this test are with low queue depths (between one and eight
I/Os queued). Also, it is clear from the chart that our expected linear performance increases
as controllers are added. As with the RAID5 results, we might need to limit the writes that our
host is driving to see the steep performance increases in the first part of the curves and give
us the ideal shapes that we expect.

Figure 7 RAID10 disk write IOPS

8 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400
 Figure 8 shows RAID10 disk write MBPS. For MBPS measurements on disk writes, we again
see that RAID10 significantly outperforms RAID5. With three DS3400s, we see an 89%
performance increase.

Figure 8 RAID10 disk write MBPS

Tables of the results

Our results suggest that it is best to have your storage configured in RAID10 arrays to push
for maximum performance. However, there might be situations in which the I/O block size in a
data center cannot be easily controlled. Therefore, choosing RAID5 might be beneficial in
some situations. The tables in the following sections show the results that we collected for all
three of our tested block sizes (512 B, 4 KB, and 64 KB) and demonstrate that there are some
cases when RAID5 benefits performance.

Cache hit results

Regardless of the back-end storage, a SAN can take advantage of the caching capabilities of
the SVC to boost performance. The results in Table 1 on page 10 show the performance that
can be seen on cache hit reads and writes with our hardware setup as explained earlier in this
paper.

It is important to note that we are limited in our results by how much I/O the host is capable of
driving. For example, a two-node 8A4 cluster might be able to report significantly higher
values than this if we had the processing power to drive more workload to it.

IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400 9
 Table 1 shows the cache hit results.

Table 1 Cache hit results

Workload Response (ms) IOPS MBPS

Read hit 512 blocks 0.644 385,263 192.632

Sequential

Read hit 4K blocks 0.687 363,454 1,453.816

Sequential

Read hit 64K blocks 3.078 41,545 2,658.885

Sequential

Write hit 512 blocks 5.585 109,786 54.393

Sequential

Write hit 4K blocks 3.425 176,869 707.478

Sequential

Write hit 64K blocks 27.065 21,279 1,361.868

Sequential

Results with one DS3400 controller

Unlike the results shown in Table 1, in this section, in this section, we show the results of
doing cache miss I/Os. As you can see in the results, we start to be limited by the speed that
we can drive from the spindles in our back-end storage. Nevertheless, the wide striping of the
SVC for miss-type workloads such as this means that we can activate more spindles and
boost the performance of the controller.

We ran tests with the disks configured by the DS3400 controller into RAID10 and RAID5
arrays to compare the performance of the two arrays. In general, it seems that RAID10 will
provide more performance benefits, but you might want to choose RAID5 for specific
workloads. See Table 2 (for RAID10) and Table 3 (for RAID5) for a comparison.

Table 2 shows the RAID10 results.

Table 2 RAID10
Workload Response (ms) IOPS MBPS

Read miss 512 blocks 28.406 20,275 10.138

Random

Read miss 4K blocks 28.187 20,433 81.375

Random

Read miss 64K blocks 27.876 9,183 587.733

Random

Write miss 512 blocks 21.252 6,022 3.011

Random

Write miss 4K blocks 20.517 6,237 24.952

Random

Write miss 64K blocks 26.335 2,430 155.523

Random

10 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400
 Table 3 shows the RAID5 results.

Table 3 RAID5
Workload Response (ms) IOPS MBPS

Read miss 512 blocks 25.77 22,350 11.175

Random

Read miss 4K blocks 26.089 22,076 88.307

Random

Read miss 64K blocks 29.315 8,732 558.861

Random

Write miss 512 blocks 8.506 3,761 1.880

Random

Write miss 4K blocks 9.251 3458.3 13.833

Random

Write miss 64K blocks 25.904 1,235 79.053

Random

Results with two DS3400 controllers

Table 4 shows the RAID10 results.

Table 4 RAID10
Workload Response (ms) IOPS MBPS

Read miss 512 blocks 14.466 39812 19.906

Random

Read miss 4K blocks 17.168 42865 171.4632

Random

Read miss 64K blocks 23.43 16388 1048.829

Random

Write miss 512 blocks 20.508 12481.9 6.241

Random

Write miss 4K blocks 20.209 12665.8 50.663

Random

Write miss 64K blocks 28.156 4545.8 290.928

Random

Table 5 shows the RAID5 results.

Table 5 RAID5
Workload Response (ms) IOPS MBPS

Read miss 512 blocks 15.411 37371 18.686

Random

Read miss 4K blocks 15.377 37454 149.817

Random

IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400 11
 Workload Response (ms) IOPS MBPS

Read miss 64K blocks 24.63 15589 997.725

Random

Write miss 512 blocks 17.556 7289 3.645

Random

Write miss 4K blocks 19.367 6608 26.434

Random

Write miss 64K blocks 27.07 2364.1 151.301

Random

Results with three DS3400 controllers

Table 6 shows the RAID10 results.

Table 6 RAID10
Workload Response (ms) IOPS MBPS

Read miss 512 blocks 11.288 51019.7 25.510

Random

Read miss 4K blocks 16.227 63095.2 252.3809

Random

Read miss 64K blocks 24.516 23492.8 1503.54

Random

Write miss 512 blocks 27.551 18576.2 9.288

Random

Write miss 4K blocks 6.772 188894.6 75.578

Random

Write miss 64K blocks 4.734 6756.3 432.4021

Random

Table 7 shows the RAID5 results.

Table 7 RAID5
Workload Response (ms) IOPS MBPS

Read miss 512 blocks 11.09 54812.6 27.406

Random

Read miss 4K blocks 11.049 55016 220.0641

Random

Read miss 64K blocks 24.664 23352.6 1494.569

Random

Write miss 512 blocks 1.469 10876 5.438

Random

Write miss 4K blocks 1.642 9731.5 38.926

Random

12 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400
 Workload Response (ms) IOPS MBPS

Write miss 64K blocks 4.454 3590.8 229.809

Random

Conclusions
The cache hit results show the performance levels that our test configuration is capable of. In
summary, we can drive 385K read IOPS and 177K write IOPS (values rounded to three
significant figures). If we focus on larger block sizes, and on driving a large amount of data
transfer rather than completed operations, we see the performance of 2,659 MBPS on reads
and 1,362 MBPS on writes (values rounded to the nearest full MB).

As mentioned in “Tables of the results” on page 9, the limiting factor is not the SVC cluster but
the System p host that we used. We reached the limits of how much throughput the host
could drive before we reached the limit of how much the SVC could handle. With more
processing power, the same two-node 8A4 cluster might be able to comfortably handle 550K
IOPS and over 3K MBPS on reads.

As mentioned earlier, the 8A4 hardware provides roughly 60% of the performance of an 8G4,
which is offset in terms of business value by the fact that it costs 60% more as compared to
the 8G4. In fact, based on recent performance data for the 8G4, the lowest percentage of 8G4
performance that an 8A4 delivers is on read hits, where the 8A4 hits over 65% of the
capability of the 8G4. This result shows that an 8A4 cluster can deliver impressive
performance regardless of the lower price tag and the reduced internal memory bandwidth.

In addition, we showed the scalability of performance that is available by adding DS3400

controllers (and extra HDDs) to a SAN underneath the 8A4 cluster. In “RAID5 scalability
comparisons” on page 3 and “RAID10 scalability comparisons” on page 6, our charts
demonstrate that performance scales linearly as we add storage controllers and disks to the
back end. When looking at these charts, we note that any results with a response time of
>30 ms are artificial, because such responses might not be acceptable in a data center.

The team who wrote this IBM Redpaper

This paper was produced at IBM Hursley Park, in Hursley, UK.

Ed Moffatt is a software tester who has five years of computing and programming experience
including a year of working on software for the IBM accounting department in North Harbour. He
joined the IBM Hursley Labs in September 2008, after completing a Bachelor of Science degree
in mathematics at Bath University. Before joining the SVC performance test team, he worked on
regression and CVT testing and is continuing his SVC career with a role in Level 3 support.

Jon Tate, project manager for this paper, is a Project Manager for IBM System Storage SAN,
DCN, and Virtualization Solutions at the International Technical Support Organization (ITSO).
Before joining the ITSO in 1999, he worked in the IBM Technical Support Center, providing
Level 2 and 3 support for IBM storage products. Jon has 24 years of experience in storage
software and management, services, and support, and is both an IBM Certified IT Specialist
and an IBM SAN Certified Specialist. He is also the UK Chairman of the Storage Networking
Industry Association.

Thanks to Barry Whyte of IBM Hursley for his contributions to this project.

IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400 13
14 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400
Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.

© Copyright International Business Machines Corporation 2010. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp. 15
This document REDP-4631-00 was created or updated on January 8, 2010.

Send us your comments in one of the following ways: ®

򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A. Redpaper ™
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

AIX® Redpaper™ System Storage™

IBM® Redbooks (logo) ®
POWER5™ System p®

The following terms are trademarks of other companies:

Intel Xeon, Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks
of Intel Corporation or its subsidiaries in the United States and other countries.

Other company, product, or service names may be trademarks or service marks of others.

16 IBM SAN Volume Controller 8A4 Hardware: Performance and Scalability with the IBM System Storage DS3400