White Paper on hp virtual array technology

[Tim D Fulford]

Ive just had a quick read of the hp virtual array tech paper and am very dissapointed...
http://www.hp.com/products1/storage/disk_arrays/midrange/virtualization_whitepaper.pdf

I'm very dissapointed because I now have to argue against "HP sid....". I can prove my points but this takes time & money that my company do not really need to spend. I feel, whilst the VAxxxx is probably a step forward in technology & will increase performance some of the claims are wrong, or at least misleading.... My specific gripes are below

1 - in section "RAID5DP"
o Is not RAID5DP the same as RAID6 see http://www.acnc.com/04_01_06.html and compare with http://www.hp.com/cposupport/information_storage/support_doc/lpg64121.html
o In this section the claim that RAID5DP offers 10% greater storage efficiencl than RAID5. This is IMPOSSIBLE!

2 - in section "Large Stripe Size"
o The claim that it is now a good idea to stripe everything across everything will be faster than dedicated disk groups. I would only agree with this if it ONLY refered to random writes. I can certainly prove this on a unbuffered [or disk] logged OLTP Informix database (see ** below), & I'm sure the same will be so for every database with disk logging.
a - logging aggregates the random writes that would go to data/index disk areas into sequential writes to the log. This is done by design to improve performance.
b - The number of transactions is limited by how fast you write to the logged disks. This is done to ensure data integity of the transactions.
Given the above two points you should tune your logging disk(s) to get the throughput required & SEPERATELY put your data/indexs somewhere else. Data/index disk speed/throughput is less critical as data will be aggregated & flushed out from the logged disks to these disks at a later point, independant to the transaction.
o To put this another way, use solid state disks for your logging area & the database will fly as if it were buffered (memory) logged.

** on fc60 256MB cache using 24x(10k rpm 18GB) disks we have 12 LUNS in a mirrored (RAID1) pair. Informix OLTP database. We then stripe (LVM 4k stripe size) everything across these 12 LUNS. The avererage service time is some 5-6ms. Pritty good as the average random write time should be some 8ms. However, if we dedicate 1 disk to logging (really need two, 1 physical & 1 logical) we see 2ms service times, up to 3 fold increase! If we used 2 LUNS I'm confident we'd get better performance again.

[harry d brown jr · Accepted solution]

Tim,

You make great points. I think the author's failed to consider "a point of diminishing returns", a fatal mistake a lot of Technical Papers have when the try to tout their products. To me a Technical Paper should be unbaised, meaning that they should not hail their product as being better than another in all cases. A truely well written Technical Paper would and should exactly describe how/who/what/when/where their data for the Technical Paper was derived.

I have had the same ongoing dispute with EMC engineers, that their Technical Papers exclude the details on how they arrived at their "limitations", especially when it comes to how many hpux systems I can boot off a symmetrix in a SAN environment (they have a pseudo-limit of 8 hosts per adapter on the symmetrix). My argument with EMC is WHY? They say because they tested it. And I asked, tested what: "The IQ of a firehydrant?". Without knowing what details were used to arrive at the "whitepaper" results, the whitepaper is nothing more than sales literature!!!

live free or die
harry

[Tim D Fulford]

Thanks harry. I was hoping someone from HP storage would be able to say.... Tim your wrong because...... But I think you hit the nail on the head, it is sales litrature, and as such it requires some (alot of) spin.

Hey ho I now need to get HP to lend me the HW to waste time to dis-prove the sales litrature, only to say ... we can still buy this HW, it is better than fc60, business benefits, reduced cost of ownership, more scalable..blah, blah.... Life is full or irony

Any other comments will, as usual, be greatly rewarded with points

[Paul McCleary]

Hi Tim,

I'm not from HP but I will try to address some of your questions.

Firstly, I agree with you, RAID5DP seems for all intents and purposes the same as RAID6 - HP state that it's a combination of RAID5 and RAID6 but it doesn't seem to be anything different than normal RAID6. The site you point to doesn't describe RAID6 correctly, it is missing segment D0; HP state you need a minimum of 5 disks and I would agree.

I've not seen anywhere where HP says that RAID5DP offers more storage efficiency as this is physically impossible. RAID5 will give you about 5% more if you look at stripes of around 15+ disks. This margin decreases as you get to around 40-50 disks. The problem with long stripes across many disks is recovery can take a serious amount of time, during which the RAID system has degraded performance. This makes big RAID5 disk stripes risky and unrealistic for the business.

The argument HP have is that with 5DP it is more acceptable to deploy longer disk stripes and thus gain greater storage efficiency because the Mean Time to Data Loss is greater than with RAID5, i.e. can tolerate 2 disks failing and not just 1. If in RAID5 one disk fails then recovery is a high priority, however the threat to data only exists in 5DP after 2 disk failures so recovery can be scheduled to a time convenient to the business.

As to your FC60 5-6ms avg svc time is what I'd expect as the disks have an avg seek of 5.7, if you have the 10K ones, and I assume you have quite an efficient setup with one 6 disk LUN off controller A and the mirror off cont B.

Hope this helps?

Paul

[Tim D Fulford]

Paul

Many thanks
o If you read the section headed RAID5DP it says "First, in a typical configuration RAID5DP is over 100 times more powerful at protecting data than standard RAID5 and, in this same configuration, provides 10% greater storage efficiency".

I've been working some numbers on this and for the SAME chance of failure 10 disks RAID5 approximately is equal to 22 disks on RAID5DP (RAID6), assuming 1% chance of failure. But this is stupid because it is putting the cart before the horse. You would base your stratagy on performance so it would be better to comnpare say two 10 disk LUNS in RAID5 & RAID5DP. Verry different numbers

You are correct the disks are 10krpm, BUT for random writes, no buffer cache you actually get 8ms, SEAGATES figures of 5ms are very optimistic.

Tim

[Vincent Fleming]

Hi;

In regards to performance and striping everything, I think you're forgetting that a VA has up to 2GB of cache in it.

Cache is the great equalizer... it mitigates all sorts of performance bottlenecks. Your logs don't depend on the response time of the disks, but on the reponse time of the controllers and cache. Sequential data such as logs can be dumped to the disks very rapidly when striped. When it gets dumped is up to the controllers and cache so it doesn't slow down your host.

When it comes to the efficiency of the RAID-5DP, I think they're comparing it to more traditional RAID arrays that require no more than 5-6 disks in a RAID set, where RAID-5DP can have up to 52.

You should benchmark the VA. I've seen a VA7400 significantly outperform Clariion, HDS9200, Compaq and IBM Fast T-500.

Good luck!

[Tim D Fulford]

Vince, thanks for the reply

The cache is 8x the fc60 cache, so that is a good thing for RANDOM writes. I know that 256MB reduces 8ms** average service times to 4-6ms, but what 2GB will reduce it to I do not know (bench mark time!). I'm not sure if cache/throughput is important or cache per spindle?, I suspect it is somewhere between the two. we currently do something like 6MB/s so 42 seconds of cache, this would go up to 341 seconds. Hmm this has got me thinking....

** The SEAGATE disks are 10,000rpm so 3ms average seek, and there is 5ms average latency, total of 8ms average service time ignoring xfr time (0.1ms or so for 4kB)

[Roger Buckthal_2]

Tim,

You should to read:

http://www.hp.com/products1/storage/products/disk_arrays/infolibrary/mathematics_behind_RAID_5DP.pdf
and
http://www.hp.com/products1/storage/products/disk_arrays/infolibrary/analysis_0f_RAID_5DP.pdf

The first document describes how RAID 5DP is implemented and the second will help you understand the mathematics behind a comparison of RAID 5 and RAID 5DP data availability. As far the naming of RAID 5DP, like it or not, it???s called marketing. Note that others are not immune to this, see Compaq???s ???Advanced Data Guarding???.

The capacity savings in the white paper refers to typical array configurations of multiple RAID 5 sets vs. a single RAID 5DP set. Yes, it???s possible to have a RAID 5 35+1 disk configuration. But, this is not typical ??? the availability risks are too high. Whereas a 34+2 RAID 5DP stripe is statistically very reliable.

Large stripe sets are a good performance practice. Read the attached white paper from Oracle. It explains the advantages of stripe and mirror everything ??? S.A.M.E. HP/Oracle will soon publish a set of white papers referencing specifically the XP and VA arrays and the S.A.M.E. technology. Also, as a proof point, see
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster
both the HP entries in the TPC-C top ten benchmarks use the VA7100. These configurations stripe the logs, indexes and table space across all the arrays in the configuration. This is not unique to Oracle; the original VA7100 TPC-C benchmark (no longer published) used Sybase, and was configured similarly.

The performance impacts of RAID 5DP (both in normal and degraded mode) are minimized in the VA by the usage of AutoRAID. AutoRAID creates a RAID 1+0 area that acts like a write cache (this is in addition to the normal NVRAM write cache). The majority of write activity is directed to this area, thus the performance characteristics are more like RAID 1+0.

I???m sorry you didn???t view the white paper as objective. The title was ??????extends the capability of fault-tolerant storage subsystems???, and was intended to discuss the unique capabilities of the array that differentiate it from other disk arrays.

Thanks for your feedback; although I would like to think of this as an education opportunity, you can consider this the official ???you???re wrong??? from hp storage per your request.

The author

[Tim D Fulford]

Roger,

Many thanks for replying. The power of the web continues to amaze me, a reply from the Author!

I have not had the time to read all the links etc but I'll do this soon.

I'm very interested to see that you say that using large stripes & striping everything across everything are good things! I suppose it comes down to how much (%) log data is being written to cache. More cache more chance it is fast. At the end of the day the speed of the log read/writes determines the speed of the system, the consolidation of data after this is very much secondary. (if you have any thoughts on this, feel free to say so).

You have the 10 points for saying "you are wrong because....".

Regards

Tim