Re: LVM

[Rich Graves <rgraves@carleton.edu>]

> able to grow storage on the fly with LVM.  It basically works like this for us...
[...]
>     * reboot the host to see the new partition size.
>          o (partprobe -s is supposed to do this, but it doesn't) 

Any process including the term "reboot" isn't "on the fly." :-)

Current proprietary OSes can rescan and use expanded LUNs on the fly while filesystems are mounted. Apparently, so can the latest development Linux kernel, but stacked device-mapper and LVM layers will need major changes, so don't expect to see this capability in enterprise linices for 2 years.

You can save some time, though, by replacing "reboot" with the minimum steps required to clear all holders of the device:

umount /file/system
vgchange -an VG
service multipathd stop
multipath -ll # note the physical devices involved, here assuming sd[fg]
multipath -f mpathVG
echo 1 > /sys/block/sdf/device/rescan # partprobe -s might also do this
echo 1 > /sys/block/sdg/device/rescan
multipath -v2
service multipathd start

...and continue with the pvresize. But simply adding a new LUN and marking it active with the admin console (or zmvolume) can be done with zero downtime, so that's my new model.

> We're pretty close here to deciding clustering is not worth it
> either....at least Redhat clustering isn't.  It has a tendency to
> arbitrarily decide that the application is down(when it's not)

Exactly my experience.

Certain convertd and amavis fixes post-5.0.3 have substantially reduced the false positives, but still, I'd rather be paged and do the failover manually.

Software and human error are *far* more common than the limited sorts of hardware and software failure from which active/passive cluster failover will save you.
-- 
Rich Graves http://claimid.com/rcgraves
Carleton.edu Sr UNIX and Security Admin
CMC135: 507-222-7079 Cell: 952-292-6529