Create Striped lv on VG having different size disks?

[Michael Steele_2]

You are confused about the difference between HW Raid and SW/OS Raid. SW/OS raid 0 is obsolete for the reasons given because HW Raid 0 is much faster and easier to admin.

I see nothing in my response that needs to be changed. Please do more reading.

[Michael Steele_2]

Oh, I just read Torsten's reply. Gee I hope you're not going to SW/OS Raid 0 on top of HW Raid 0?

Please don't do this. The performance hit that you will take will probably get you another job.

[Torsten.]

A vraid1 stripes the data across all available disks within a diskgroup; so if you have multiple vdisks in the same disk group they all share the same disks - so it is unlikely that additional striping from OS makes anything faster ... working with multiple vdisks just for LVM striping just increase the administration complexity. You probably make a simple environment much more complicated.

[ManojK_1]

Hi,

I Agree with all of you.H/W raid performs better than software raid

Just tell me in which way i have to create an LV on a vraid1 disks presented from EVA.
I think i don't neeed to create PVG group and create lun in raid 0 1.

What i have seen if create a lun in os level on the eva disks with out stripe or mirror. When heavy write is coming only one lun showing very high I/O rate. If i am creating a lun with stripe i can see the I/O distributed on all the luns in the VG.
In eva side there is any change with these write (OS write on stripe and non-stripe luns)?
Which is burden to OS?


Manoj K

[Torsten.]

>> What i have seen if create a lun in os level on the eva disks with out stripe or mirror. When heavy write is coming only one lun showing very high I/O rate. If i am creating a lun with stripe i can see the I/O distributed on all the luns in the VG.


As expected, right?

IMHO you should simply create a single LUN in vraid1 mode. Performance usually increases if the number of disks in the diskgroup is increasing.

[Michael Steele_2]

HW raid is transparent to the O/S and you don't have to compensate for it.

Just follow your usual LVM procedures.

Do you need help with this too?

[ManojK_1]

Hi Michael,

Thanks. No more helps required.

The knowledge you passed is more than enough.

Manoj

[Michael Steele_2]

Great, then don't do SW/RAID 0 on HW/RAID 0 like you did with this command:

#lvcreate -l 5594 -i 6 -I 128 -n lvol1 vg03

I sure hope you deleted this vg03 for your sake

[Bob_Vance]

> it makes probably no sense to stripe across EVA LUNS ...

Just to show that nothing is as simple as it seems, I will offer this:


If there is no multipathing software (like Secure Path, e.g.) and you are not yet up to 11.31, then there will no load balancing across PVlinks; i.e., across dual HBAs in the server.


So a poor-man's load balancing can be achieved with striping across 2 PVs where you manually set the Primary link of PV1 as HBA1 and the Primary link for PV2 as HBA2.

We used to do this using Distributed Allocation as well, which is a poor-man's striping with much larger chunks. But this also reduces the overhead from -i striping.

There are some other considerations, such as LUN-owning controllers, etc., so it is not necessarily all clear.


bv

[klb]

Indeed, I've used striping ( and the less overhead Max Distro options ) to effect load balance across all fiber loops to the SAN.

This was in a Secure-Path A/P environment w/ 2 HBA x 2 ports each. Created VG with 4 equal size LUNs, preferred each LUN down its own unique path to the SAN, spread these paths across the SAN controllers, then striped LV's across these 4 LUNs.

This effectively gatlin-gunned I/O across all paths to the SAN in a round-robin fashion.

Certainly this didn't improve I/O speed ( raw xfer speed ), but it could and did IMHO improve bandwidth utilization from the host to the SAN.

YMMV,

-klb