On 1/2/13 6:01 AM, Brian Candler wrote:
> On Fri, Dec 28, 2012 at 10:14:19AM -0800, Joe Julian wrote:
>> My volume would then look like
>> gluster volume create replica 3
>> server{1,2,3}:/data/glusterfs/vmimages/a/brick
>> server{1,2,3}:/data/glusterfs/vmimages/b/brick
>> server{1,2,3}:/data/glusterfs/vmimages/c/brick
>> server{1,2,3}:/data/glusterfs/vmimages/d/brick
>
> Aside: what is the reason for creating four multiple logical volumes/bricks
> on the same node, and then combining them together using gluster
> distribution?
I'm not Joe, but I can think of two reasons why this might be a good idea. One
is superior fault isolation. With a single concatenated or striped LV (i.e. no
redundancy as with true RAID), a failure of any individual disk will appear as
a failure of the entire brick, forcing *all* traffic to the peers. With
multiple LVs, that same failure will cause only 1/4 of the traffic to fail
over. The other reason is performance. I've found that it's very hard to
predict whether letting LVM schedule across disks or letting GlusterFS do so
will perform better for any given workload, but IMX the latter tends to win
slightly more often than not.
> Also, why are you combining all your disks into a single
> volume group (clustervg), but then allocating each logical volume from only
> a single disk within that VG?
That part's a bit unclear to me as well. There doesn't seem to be any
immediate benefit, but perhaps it's more an issue of preparing for possible
future change by adding an extra level of naming/indirection. That way, if the
LVs need to be reconfigured some day, the change will be pretty transparent to
anything that was addressing them by ID anyway.
