[Gluster-users] replica count documentation

[Mohit Anchlia]

I suggest reading gluster docs 3.1. It has basic info on how to
configure. Yes you need to mount since you are creating file system.
You never write to VOLUME directly, ever.

Like I mentioned before look at subvolume info inside volume file that
has the information about replica that you are looking for.

On Thu, Apr 14, 2011 at 3:45 PM, Craig Younkins <cyounkins at gmail.com> wrote:
>> > > 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
>>
>
>