HPE Storage Users Group

Hi All,

Have a 3PAR storeserv 7200, 8Gbps SAN with 8 x 600 SAS drives. I am wondering what kind of speeds I am supposed to get from it. Come from and EVA background and still a newbie to 3PAR.

Kind regards,

Tommytis

about 1100 iops@15msec, based on the following assumptions:

50/50 Read/Write ratio
0% cache hit ratio
Raid5, 3+1

Thanks!!

I was hoping for a MB/s rating.. Why have you put down 0% cache hit ratio?


Kind regards,

Tommytis

MB/s benchmarks alone are not very meaningful. Streaming data from your array sequentially with a large 512k block read will probably bottle neck your HBA. Randomly writing tiny blocks to the array will yield a much poorer MB/S result.

Thanks Richard,

I did do some testing and benchmarking using the VMWARE IO analyser. The comparison I made are between a P2000 G3 and the 3PAR 7200. The HP P2000 has 8 port 1Gbe iSCSI split between 2 controllers.

Do these figures look ok ?

Kind regards,

Tommytis

So I believe what those screen shots are reporting is that your 3par (with 8 SAS spindles?) is delivering 25,000 write iops and 67,000 read iops. That seems high based on the spindle count you provided, I would allege that much of those requests are being serviced by cache (Host, hypervisor, and 3PAR), the benchmark capacity might be too small such that the entire test can fit inside cache, and/or the data on the test LUN is bad or non-existant.

For example, if you do a read benchmark on a empty 1 TB thin provisioned volume, with no data... you will get amazingly high results far beyond what the spindles are capable of. Since there is physically no data on disk to read, the storage controllers will receive random read requests to various locations on a virtual 1TB volume that has 0 physical space allocated to it. The controllers will know the block to be read does not physically exist, therefore the returned result is automatically zeros. All handled on the controller, and not on the disk.

The same can be true for a write benchmark if the data being written is all zeros. Intelligent thin provisioning arrays will not allocate space for a solid blocks of zeros.

When I last did benchmarks between Netapp and 3PAR, I used IOMETER to do a sequential write to all my test LUNs for several hours to fill them up before doing any benchmarking. I did discover that IOMETER writes are not random data per se, it has a large paragraph of text it uses over and over again for write testing, good enough for my goal. It did the trick to nullify the thin provisioned "magic benchmark", and it provided data on both compared systems that was "equal", so as to prevent one vendor claiming his array got a tougher "seed" of random data than the other guy's. It you require large amounts of completely random data, I would suggest using something like unix DD commands reading from /dev/urandom and writing to files on your test lun.