
Hi all, I see in the ovirt guides that a gluster volume replica 3 with 1 arbiter is recommended. Why not simple replica 3? Is it due to the higher replication data that would cause performance issues? What I am observing is that a VM running on the server which has the arbiter brick has slower read performance then when the same VM runs on another server with a normal brick. Has anyone observed this? Is it because the arbiter does not have the real data on it? Thanx, Alex

Hi , yes, you are right. Since arbiter brick has only metadata and data for the vm has to be served from one of the other two replicas, read is slow. Arbiter is a special subset of replica 3 volumes and is aimed at preventing split-brains and providing same consistency as a normal replica 3 volume with out consuming 3x space. You could use replica 3 and no issues with that. Thanks kasturi On Fri, Sep 15, 2017 at 12:41 PM, Abi Askushi <rightkicktech@gmail.com> wrote:
Hi all,
I see in the ovirt guides that a gluster volume replica 3 with 1 arbiter is recommended. Why not simple replica 3? Is it due to the higher replication data that would cause performance issues?
What I am observing is that a VM running on the server which has the arbiter brick has slower read performance then when the same VM runs on another server with a normal brick. Has anyone observed this? Is it because the arbiter does not have the real data on it?
Thanx, Alex
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

In the replica 3 + 1 arbiter does this mean that if I loose the two nodes having the normal volumes and left only with the node that has the arbiter volume, I loose all data? Thanx, Alex On Fri, Sep 15, 2017 at 11:25 AM, Kasturi Narra <knarra@redhat.com> wrote:
Hi ,
yes, you are right. Since arbiter brick has only metadata and data for the vm has to be served from one of the other two replicas, read is slow.
Arbiter is a special subset of replica 3 volumes and is aimed at preventing split-brains and providing same consistency as a normal replica 3 volume with out consuming 3x space. You could use replica 3 and no issues with that.
Thanks kasturi
On Fri, Sep 15, 2017 at 12:41 PM, Abi Askushi <rightkicktech@gmail.com> wrote:
Hi all,
I see in the ovirt guides that a gluster volume replica 3 with 1 arbiter is recommended. Why not simple replica 3? Is it due to the higher replication data that would cause performance issues?
What I am observing is that a VM running on the server which has the arbiter brick has slower read performance then when the same VM runs on another server with a normal brick. Has anyone observed this? Is it because the arbiter does not have the real data on it?
Thanx, Alex
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

On Fri, Sep 15, 2017 at 5:48 PM, Alex K <rightkicktech@gmail.com> wrote:
In the replica 3 + 1 arbiter does this mean that if I loose the two nodes having the normal volumes and left only with the node that has the arbiter volume, I loose all data?
Yes!
Thanx, Alex
On Fri, Sep 15, 2017 at 11:25 AM, Kasturi Narra <knarra@redhat.com> wrote:
Hi ,
yes, you are right. Since arbiter brick has only metadata and data for the vm has to be served from one of the other two replicas, read is slow.
Arbiter is a special subset of replica 3 volumes and is aimed at preventing split-brains and providing same consistency as a normal replica 3 volume with out consuming 3x space. You could use replica 3 and no issues with that.
Thanks kasturi
On Fri, Sep 15, 2017 at 12:41 PM, Abi Askushi <rightkicktech@gmail.com> wrote:
Hi all,
I see in the ovirt guides that a gluster volume replica 3 with 1 arbiter is recommended. Why not simple replica 3? Is it due to the higher replication data that would cause performance issues?
What I am observing is that a VM running on the server which has the arbiter brick has slower read performance then when the same VM runs on another server with a normal brick. Has anyone observed this? Is it because the arbiter does not have the real data on it?
Thanx, Alex
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users

mmm, perhaps one more reason to go to simple replica 3... Thanx, Alex On Fri, Sep 15, 2017 at 3:30 PM, Sahina Bose <sabose@redhat.com> wrote:
On Fri, Sep 15, 2017 at 5:48 PM, Alex K <rightkicktech@gmail.com> wrote:
In the replica 3 + 1 arbiter does this mean that if I loose the two nodes having the normal volumes and left only with the node that has the arbiter volume, I loose all data?
Yes!
Thanx, Alex
On Fri, Sep 15, 2017 at 11:25 AM, Kasturi Narra <knarra@redhat.com> wrote:
Hi ,
yes, you are right. Since arbiter brick has only metadata and data for the vm has to be served from one of the other two replicas, read is slow.
Arbiter is a special subset of replica 3 volumes and is aimed at preventing split-brains and providing same consistency as a normal replica 3 volume with out consuming 3x space. You could use replica 3 and no issues with that.
Thanks kasturi
On Fri, Sep 15, 2017 at 12:41 PM, Abi Askushi <rightkicktech@gmail.com> wrote:
Hi all,
I see in the ovirt guides that a gluster volume replica 3 with 1 arbiter is recommended. Why not simple replica 3? Is it due to the higher replication data that would cause performance issues?
What I am observing is that a VM running on the server which has the arbiter brick has slower read performance then when the same VM runs on another server with a normal brick. Has anyone observed this? Is it because the arbiter does not have the real data on it?
Thanx, Alex
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (4)
-
Abi Askushi
-
Alex K
-
Kasturi Narra
-
Sahina Bose