Stripping EMC Clariion disk at the LVM level

[Tracey Katrusiak]

The following storage layout was recommended to our storage group from EMC, this will be the first time we stripe Clariion luns in a volume group.
On a different server we currently stripe 7 symdevs into one logical volume. My concern is that we are only using 3 Clariion devices in this stripe configuration. Any input would be greatly appreciated.


3*174GB LUNs from CX allocated to pc1065:

/dev/rdsk/c14t0d0 :DGC :CX3-80WDR5 :HP03 :Ch2 CONT : 182452224
/dev/rdsk/c14t0d1 :DGC :CX3-80WDR5 :HP03 :Ch2 CONT : 182452224
/dev/rdsk/c14t0d2 :DGC :CX3-80WDR5 :HP03 :Ch2 CONT : 182452224


please build a new VG using these 3 LUNs, use LVM to stripe across the VG using a stripe width of 256KB.

Also, as mentioned before:

1. no pv links (because we are using PP)
2. pv time out setting for PP (90)
3. turned off BBR flag

[Hein van den Heuvel · Accepted solution]

Tracey,

Those 3 clarion devices are surely build on top of several drives already.

Google for: EMC Clariion plaid.

You will find a powerlink document "EMC CLARiiON Best Practices for Fibre Channel Storage", for example as: bbs.doit.com.cn/attachment.php?aid=6757
The "Volume Manager" chapter (Page 12 and 13) in there describes the Do's and Dont's for plaid. It explains probably more concise then anyone else here can.

hth,
Hein.

[Tracey Katrusiak]

Thanks for the info I'll take a look at EMC's recommendations, I would really like an HP-UX point of view on stripping so few devices at the LVM layer.

[Tim Nelson]

Some of those docs you will read will propose that plaiding just may have a negative effect on performace by possibly disabling the the benefits of read-ahead caching and other performance boosters in the arrays.

Every doc I have read takes a test-it and pick the best configuration for your environment.

Best of luck, Please post your findings.

Cheers.

[TwoProc]

Just from memory -

Isn't the max stripe size 64k?

[Bill Hassell]

Striping is great for JBODs, but can cripple all the nifty electronics inside a smart disk array. Using a general purpose OS and volume manager will always provide much lower performance than specialized hardware and dedicated cache in an array. And striped lvols are a real pain to manage -- you need lots of docs and adding more disks (LUNs) can also degrade performance unless the lvols are rebuilt from scratch. Let the hardware do the work.

[Stephen Doud]

I agree with Bill (Hi Bill!) and add to his comments.
- LVM striping is software-based striping, which is only valuable when the array itself doesn't provide efficient hardware-based striping.

- Software striping a set of LUNs that utilize hardware striping may generate more inefficiency than no striping at all.

- Software-based striping requires calculations which load the server, whereas hardware-based striping is done externally in the array.


As for the min/max stripe size in LVM, the man page states:

-I stripe_size Set the size in kilobytes of the stripe.
stripe_size should be a power of 2 in
the range 4 to 32768. -i and -I must be
specified together.

[Tracey Katrusiak]

Thanks to all who replied to my question, I have decided to stripe the three luns as EMC directed, I will monitor the IO performance and I may redo the storage allocation if required.

Thanks again.

TJK

[Tracey Katrusiak]

TJK

[Tim Nelson]

One last note.

LVM striping may be an option to HIDE the poor performance of these 3 large luns. This might be why EMC is recommending it ?

As I said it could be usefull in some environments :)

[TwoProc]

My guess is that EMC is requesting the stripe to balance the load across more hardware. This is pretty common - HP even recommends this on their XP implementations - however, their recommendations usually suggest large stripe sizes, of the type available using Distributed stripes (PE size). The goal isn't really the stripe, it's a way to load balance I/O segments across hardware. This follows the theory that an equally loaded (that is, well balanced) storage server gives the optimal performance as it should have the fewest bottlenecks. This is based on the view that if there are little to no bottlenecks then waits system wide are decreased and total throughput availability is increased.

Makes sense, I've used that approach for years, and it works very well, and has held up across many benchmarks as a solid performance approach. Have to admit though, when it was first suggested as the strategy, I was very skeptical.