[Gluster-users] replica count documentation

[Craig Younkins]

>
> > > Assuming I have my replica count set to 2 with my 2 brick setup, it
> sure
> > > isn't strict. I've waited 15 mins after the write to one brick has
> > > finished before it was actually synced up on the second.
> >
> > There is no consistency level. Response will be returned to the user
> > after the slowest writes is done. Writes occur sync. to all the
> > servers in replica set.
> Something doesn't match up here. If it can take 15 minutes for a write to
> replicate to the second brick, according to the first comment, then it
> should take that whole 15 minutes for the control to be returned to the
> user, per the second comment.
>

You're right, and I think it was my fault. Say you make a volume like so:

gluster volume create test-volume replica 2 192.168.0.150:/test-volume
192.168.0.151:/test-volume

A naive person like myself would see the storage mounted at /test-volume on
the filesystem and think that they could write to it. I believe this is
wrong.

Someone please verify: You must mount the gluster volume on storage bricks
and access it through that mount point (eg /mnt/test-volume), and NOT the
"volume point" (eg /test-volume) which you declared when you created the
volume.

If this is the case, I really think having documentation that has examples
of creating volumes with targets such as /test-volume can really create
confusion.

---

Despite that I'm trying to work out the logic of how to put an HA KVM setup
> on a 2-unit replicated Gluster system.


Same use case here.

--

As for determining how many replicas a volume was created with, I've
discovered this thus far:

For a volume created without the replica param, gluster volume info shows:

Volume Name: test-volume2
> *Type: Distribute*
> Status: Started
> Number of Bricks: 2
> Transport-type: tcp
> Bricks:
> Brick1: 192.168.0.150:/test-volume2
> Brick2: 192.168.0.151:/test-volume2


 For a volume created with replica 2, gluster volume info shows the
following. Note the type difference.

Volume Name: test-volume
> *Type: Replicate*
> Status: Started
> Number of Bricks: 2
> Transport-type: tcp
> Bricks:
> Brick1: 192.168.0.150:/test-volume
> Brick2: 192.168.0.151:/test-volume



Now, if you are replicating, how do you know how many replicas?


Craig Younkins


On Thu, Apr 14, 2011 at 5:51 PM, Whit Blauvelt
<whit.gluster at transpect.com>wrote:

> On Thu, Apr 14, 2011 at 02:20:02PM -0700, Mohit Anchlia wrote:
>
> > Which similar systems are you referring to?
>
> DR:BD has an overlapping use case, although it's pretty much constrained to
> mirroring between two storage systems. And it has options to return to the
> user after either writing to the first system, or only after writing to the
> second - or even _before_ writing to the first if you trust that once it
> has
> the data it will get there.
>
> DR:BD's also more typically used in primary-secondary arrangements for
> failover than in primary-primary arrangements for load sharing. But there
> are ways to do the second. I've got one pair of servers mirrored through
> DR:BD proving file storage via NFS, and another pair now running Gluster,
> also providing NFS service. Both are doing well so far, although my Gluster
> use is only a few days, where DR:BD's been running happily for months.
>
> Gluster is easier to configure, as DR:BD takes cryptic commands, and
> requires combination with other daemons to get the job done. But DR:BD is
> very good at what it does, and well documented - except that you've got to
> cobble together its documentation with that of the other daemons you're
> integrating it with to get your result, which can be a bit of a mental
> stretch (at least for me).
>
> DR:BD also, being at the device level and in the kernel, has advantages in
> stacking with other stuff. I can put a KVM in an LVM on DR:BD - and KVMs do
> well as LVMs, both running efficiently in them and allowing LVM
> snapshotting
> - it's a better format than qcow. As I understand it I can't put an LVM on
> top of a Gluster - although it has no problem using ext4-formatted LVMs as
> bricks, I doubt it can work in any way with LVMs which are KVMs, with no
> file system in between.
>
> Despite that I'm trying to work out the logic of how to put an HA KVM setup
> on a 2-unit replicated Gluster system. It should be possible to get both
> failover, and live-migration failback going, once I get the concepts and
> incantations right. While KVM is solid, its docs are terse and incomplete.
> That seems to be a trend. Book publishers no longer rush out books on the
> latest tech, and free software creators who hold back instructions improve
> their chance of consulting contracts.
>
> Whit
>
>