Create Striped lv on VG having different size disks?

[ManojK_1]

Hi,

I am having a vg containg 6 disks. Five 100GB disks and One 200GB disks.

Is it possible for me to create an striped lv on this vg using all PE ?

[Torsten.]

Please think about - fisrt PE on the first disk, second PE on the second disk ... etc; until the first 5 disks are full. Then you cannot stripe anymore.

[klb]

`
I think what he's saying is that yes you can build striped LVs across this but eventually you will have 600GB of striped LVs and 100GB of free space on your 200GB disk.

-klb

[mvpel]

If I'm remembering correctly the LVM selects free extents round-robin from any device with free extents, so the first 600GB will be LVM-striped and the last 100GB worth of the volume will be on the last 100GB of the sixth disk, not striped at all.

[ManojK_1]

Hi,

While running a lvcreate am getting the following error.

#lvcreate -l 5594 -i 6 -I 128 -n lvol1 vg03
Warning: rounding up logical volume size to extent boundary at size "716544" MB for striping.
Logical volume "/dev/vg03/lvol1" has been successfully created with
character device "/dev/vg03/rlvol1".
lvcreate: Not enough free physical extents available.
Logical volume "/dev/vg03/lvol1" could not be extended.
Run the "lvextend" command to create space on the Logical Volume.

Please assist whether there is anything extra needed in the command.

Manoj K

[Torsten.]

Hard to tell without having a

# vgdisplay -v /dev/vg03

But if one of the disks is already full (no free PEs left), you cannot do this striping anymore.

[Michael Steele_2]

RE: "...Is it possible for me to create an striped lv on this vg using all PE ?..."

First Problem:
Depends upon what the volume group's first disk was during creatation. If the first disk was the 200GB disk then n/p. If the 100GB disk then this is what the vg sets it boundaries too. The only way to change this is to destroy the vg and create a new vg stating that the 200 GB disk in the first position.

Second Problem:
Stripping writes PV1 PV2 / PV2 PV1. So eventually you'll hit the 100GB ceiling and be left with 100GB unused on the 200GB PV. And LVM will stop at this point since there is no way for LVM to revert back to writing contiguous.

Comment: I don't know who is advising you to use this obsolete procedure, AKA Software Raid Zero. But there is absolutely no advantage to it in any way, especially in administration or fault tolerance. For you to have fault tolerance you'd have to create a pvgroup of the disks and then mirror the group to another group of the same number of disks, hence raid 01.

Most disk arrays do this for with much less effort and much better performance.

Do not expect better performance. In many years of hearing others report on this configuration no has ever reported better performance. Why? Added O/S overhead.

[Michael Steele_2]

Don't forget to assign points to all of the responses

[ManojK_1]

Hi Michael,

<< Comment: I don't know who is advising you to use this obsolete procedure, AKA Software Raid Zero

How can you say that raid0 is an obsolete procedure.I have vraid 1 in EVA and that luns are presented to my server. So again i need to do mirroring (raid1) in OS level?

<
So you are saying that there is no performance adavance in raid0 compared to raid1.

This is the first time i am hearing raid0 obsolete and there is no advantage for raid0 over raid1.

Anyway i am planning to unpresent the 200GB disk and split it in to 2 *100GB disk in eva. Present both disks to the host and create lv with stripe (raid0).

Manoj K

[Torsten.]

IMHO what Michael say is - it makes probably no sense to stripe across EVA LUNS, because the EVA already does it (maybe better than the OS can do).

[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

[Michael Steele_2]

Bob Vance and KLB:

Please provide a sar -d output from 11:00 am

[klb]

... and that would .... show .... what exactly?

On the system I mention above, it would show equal amounts of I/O on each LUN for the time period.

[Bob_Vance]

Nothing will be as good as native LB at hba driver level.
But if you had 200 11.23 blades all configured the same way, then all the I/O would only be on one fabric.

Just food for thought.

bv

[Torsten.]

Bob wrote

"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."

You are right. I was focused on 11.31. Because of the built-in load balancing and the ALUA feature of the array you use always several paths via both fabrics to access to owning controller.

But I agree, this kind of "poor-man's" LB is the way to go with 11.23 - otherwise you may have one fabric under pressure, the other totally idle in worst case ...

[Bob_Vance]

11.31 definitely rocks !
I loves me some 11.31 .

IMHO, not worrying about LB & alternate paths in a SAN environment is a good reason to upgrade to 11.31 .

With striping, -i or -D, you then have to worry about how to extend the VG -- always extend at least 2 PVs, sizes of the PVs, and making sure PVlinks alternate properly between the two HBAs.
So, it can be a little hassle.


bv