LVM Mirroring/Stripping

[Juan M Leon]

Hello All, I am looking for some advice.
We have a volume group with 4 lvols (very busy lvols).
The volume group is attached to a jbod.
The volume group does have 2 mirrors.
the first mirror is for redundancy and to be able to continue working if one of the disk dies.
the second mirror is used for backup purposes. Basically we split the second mirror onto different filesystem and we have backup running without affecting production.

We want to keep mirrors this way.
Considering that the lvols are very busy servicing reads we want to strip the lvols onto 3 or 4 disks.

What concerns me is to have mirror and stripe at the same time.
is this possible? Any known issues?

The reason for stripping is to have multiple paths (disks) instead of one path (disk) servicing the database requests.


Any suggestions or comments will be appreciated.

Thank you

Juan

[KapilRaj]

I forgot but there is something called PVG ( Physical Volume Groups ?? ) and a file called /etc/lvmpvg ..

Check the man pages .. What you said is possible

Regds,

Kaps

[Sundar_7]

Juan,

With LVM and MirrorDisk/UX, you cannot mirror a striped LV, unless you choose a layout called "extent based stripes".

The difference is the stripe size. With extent based stripes, the stripe size equals the PE size, unlike the regular striping where you have the freedom of choosing the stripe size.

Sundar.

[Juan M Leon]

Raj/sundar thank you for your replies.
what is the command syntax of extent based stripes.

Thank you

[A. Clay Stephenson]

You don't actually need PV groups you can do it by first creating a VG of 0 size with vgcreate. You then vgextend. However, this is going to be a big waste of time because extent-based striping rarely yields even a measurable performance increase much less a significant one. The problem is that the smallest possible PE (1 MiB -- which would limit the size of your PV's and LVOL's is still much too large to efficiently switch very quickly between i/o paths). The stripe size needs to be 64KiB to an absolute maximum of 256KiB for good i/o distribution.

[Dave Wherry]

I wonder if your strategy of splitting the second mirror off for backup purposes actually buys you anything.

You say these lvols are on a jbob which leads me to assume all of the traffic is on the same HBA or HBAs.

So every write goes down that/those channel(s) 3 times.

When you split off the second mirror for your backups is the system still busy with production activity? If not, you have created more traffic during production hours maintaining the mirrors.
There has to be a break even point.

[A. Clay Stephenson]

Since you mention filesystems (rather than raw LVOL's) let me suggest a Plan B. As I've already indicated, extent-based striping (which does allow mirroring) is not going to buy you very much (if anything) in terms of performance. A better approach (because only the one mirror is needed) would be to make vxfs snapof mounts of your filesystems and reduce your mirrors to one 1 mirror. This will improve write performance and you will still have a completely safe (and staic) snapshot image for backups. This does require ONlineJFS. Man mount_vxfs for details.

[Tim Nelson]

Extent / Distibuted striping.

lvcreate -m 1 -D y -s g /dev/vgxyz

edit /etc/lvmpvg and create disk groups. The -s resticts mirroring to those groups.

CHeck out the man page for lvcreate.

Used it for may years until we moved to SAN based environment. Performance using 36GB SCSI2 drives ( DS2100 ) is equivelant to SAN performance less the cache hits. The more drives in each group the better the performance. We used 4 drives striped then mirrored to another 4 drives on separate controller.

[vinod_25]

Hi Juan,

Here is my procedure for extend-based striped logical volume. Expecting more points for revealing this secret. :-))

# lvcreate -n stripy /dev/vgora1

Logical volume "/dev/vgora1/stripy" has been successfully created with

character device "/dev/vgora1/rstripy".

Volume Group configuration for /dev/vgora1 has been saved in /etc/lvmconf/vgora1.conf

#

# PV1=/dev/dsk/c0t1d0

# PV2=/dev/dsk/c0t2d0

# PV3=/dev/dsk/c0t3d0

# SIZE=300

# COUNT=1

# while [ $COUNT -le $SIZE ]

> do

> lvextend -l $COUNT /dev/vgora1/stripy $PV1

> let COUNT=COUNT+1

> lvextend -l $COUNT /dev/vgora1/stripy $PV2

> let COUNT=COUNT+1

> lvextend -l $COUNT /dev/vgora1/stripy $PV3

> let COUNT=COUNT+1

> done

Logical volume "/dev/vgora1/stripy" has been successfully extended.

Volume Group configuration for /dev/vgora1 has been saved in /etc/lvmconf/vgora1.conf

Logical volume "/dev/vgora1/stripy" has been successfully extended.

Volume Group configuration for /dev/vgora1 has been saved in /etc/lvmconf/vgora1.conf

...

Logical volume "/dev/vgora1/stripy" has been successfully extended.

Volume Group configuration for /dev/vgora1 has been saved in /etc/lvmconf/vgora1.conf

#

# lvdisplay -v /dev/vgora1/stripy | more

--- Logical volumes ---

LV Name /dev/vgora1/stripy

VG Name /dev/vgora1

LV Permission read/write

LV Status available/syncd

Mirror copies 0

Consistency Recovery MWC

Schedule parallel

LV Size (Mbytes) 1200

Current LE 300

Allocated PE 300

Stripes 0

Stripe Size (Kbytes) 0

Bad block on

Allocation strict

IO Timeout (Seconds) default



--- Distribution of logical volume ---

PV Name LE on PV PE on PV

/dev/dsk/c0t1d0 100 100

/dev/dsk/c0t2d0 100 100

/dev/dsk/c0t3d0 100 100



--- Logical extents ---

LE PV1 PE1 Status 1

00000 /dev/dsk/c0t1d0 00250 current

00001 /dev/dsk/c0t2d0 00000 current

00002 /dev/dsk/c0t3d0 00000 current

00003 /dev/dsk/c0t1d0 00251 current

00004 /dev/dsk/c0t2d0 00001 current

00005 /dev/dsk/c0t3d0 00001 current

...

00297 /dev/dsk/c0t1d0 00349 current

00298 /dev/dsk/c0t2d0 00099 current

00299 /dev/dsk/c0t3d0 00099 current

Regards,

Vinod