The Dell PowerVault MD1200/1220 arrays provide a convenient way to expand the PowerEdge servers to gain access to more drives. The MD1200 and MD1220 models use the 6Gb SAS technology, and they can be daisy chained up to 4 units. This allows a maximum of 8 arrays to be connected to a single adapter since PERC H800 adapter has two ports.

When one has four MD1200 arrays, there are a number of different ways that these arrays can be connected to the PERC H800 adapter. The goal of this post is to study the performance of three possible topologies under a workload where a number of threads perform sequential write and read operations. This post is an intermediate study and the results will be used to configure an NFS server to share MD1200 storage to an HPC cluster through NFS. The three topologies that we investigated are as follows:

• Topology 1: Four PV MD1200 arrays are daisy chained using single connection.
• Topology 2: Four PV MD1200 arrays are daisy chained using redundant connections.
• Topology 3: Two PV MD1200 arrays are connected to each port of the PERC H800 controller via single connection.

Topology 1: Four PV MD1200 arrays are daisy chained using single connection.	Topology 2: Four PV MD1200 arrays are daisy chained using redundant connections.

Topology 3: Two PV MD1200 arrays are connected to each port of the H800 controller via single connection.

Four Dell PowerVault MD 1200 RAID arrays are used for these experiments. Each array contains twelve 450 GB 15K rpm SAS6 disks. The storage is configured as a single RAID 50 volume spanning over 48 disks. The RAID 50 span size is set to 12 in order to have one parity disk per array. Increasing this number will reduce the number of parity disks which might improve the performance in the expense of reduced redundancy. A Dell PowerEdge R710 server running Red Hat Enterprise Linux 5 U4 is used to connect to the arrays. The volume is formatted as ext3 (see a previous blog post for a comparison of different ext file systems). We used the IOzone benchmark version 3.327 available from www.iozone.org. The read ahead setting on the OS was set to 8192 sectors to improve sequential read performance using the blockdev command. For this study, the defaults were used for the other settings, however the performance can be further tuned by modifying other OS and storage settings.

The IOZone benchmark was setup to spawn 64 threads performing sequential read and write operations on separate files. Performance graphs show the aggregate throughput observed by the threads. Each experiment was run 10 times and the standard deviation is also reported as positive and negative error bars on the charts. Since the goal is to compare these three topologies, the charts report performance relative to Topology 1.



For this workload, the third topology performs write operations approximately 4% faster than redundant connection and single connection configurations. The read performance for Topology 3 on the other hand was approximately 1.5% lower.

This experiment only covers the test case where multiple threads perform sequential reads and writes; therefore the results may not be applicable to other applications with different access patterns. Since the NFS tests will have a cluster of nodes performing sequential reads and writes, we decided to use the third topology for the NFS performance study that we are performing using the PV MD1200 backend storage.

Aziz