mount glusterfs from 127.0.0.1
Hello all together, having a three node oVirt cluster for virtualization and gluster, each node providing bricks for a replica 3 volume, I would like to mount the volume from 127.0.0.1 to distribute i/o and to have a better failover situation. This leads to a volume having the same address in oVirt althoght it is addressed on different hosts. Is this common, supported, relyable and recommended? Thanks in advance! /dev/null -- Diese Nachricht wurde auf Viren und andere gefährliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. For all your IT requirements visit: http://www.transtec.co.uk
On Thu, Apr 6, 2017 at 8:53 AM, /dev/null <devnull@linuxitil.org> wrote:
Hello all together,
having a three node oVirt cluster for virtualization and gluster, each node providing bricks for a replica 3 volume, I would like to mount the volume from 127.0.0.1 to distribute i/o and to have a better failover situation.
The right way to do this is to fill in the mount options with: backup-volfile-servers=<IP1>:<IP2>
This leads to a volume having the same address in oVirt althoght it is addressed on different hosts.
Is this common, supported, relyable and recommended?
Thanks in advance!
/dev/null
-- Diese Nachricht wurde auf Viren und andere gefährliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. For all your IT requirements visit: http://www.transtec.co.uk
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Jason, yes - thats how i am doing it. I wonder if its better to access the local bricks primarily for both relyability and performance/load. - if one node fails, it does not mean an impact if we access 127.0.0.1 - if i write to 127.0.0.1 it might be faster than accessing on network host from all hypervisors - backup-volfile-servers was set to the other nodes if local gluster fails My question is, if itÂŽs critical to access all replicas simultanly. Thanks! On Thu, 6 Apr 2017 12:30:28 -0700, Jason Brooks wrote
On Thu, Apr 6, 2017 at 8:53 AM, /dev/null <devnull@linuxitil.org> wrote:
Hello all together,
having a three node oVirt cluster for virtualization and gluster, each node providing bricks for a replica 3 volume, I would like to mount the volume from 127.0.0.1 to distribute i/o and to have a better failover situation.
The right way to do this is to fill in the mount options with:
backup-volfile-servers=<IP1>:<IP2>
-- Diese Nachricht wurde auf Viren und andere gefährliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. For all your IT requirements visit: http://www.transtec.co.uk
On Thu, Apr 6, 2017 at 1:33 PM, /dev/null <devnull@linuxitil.org> wrote:
Jason,
yes - thats how i am doing it. I wonder if its better to access the local bricks primarily for both relyability and performance/load.
- if one node fails, it does not mean an impact if we access 127.0.0.1 - if i write to 127.0.0.1 it might be faster than accessing on network host from all hypervisors - backup-volfile-servers was set to the other nodes if local gluster fails
My question is, if it´s critical to access all replicas simultanly.
I think that using localhost on each node will lead to split-brain. With the backup volfile setting taking care of failover, I don't think mounting at localhost buys you anything, anyway. Gluster already handles spreading out the load among the hosts on its own, when you're using the native gluster mounts (vs nfs, where you are accessing through the specified mount point).
Thanks!
On Thu, 6 Apr 2017 12:30:28 -0700, Jason Brooks wrote
On Thu, Apr 6, 2017 at 8:53 AM, /dev/null <devnull@linuxitil.org> wrote:
Hello all together,
having a three node oVirt cluster for virtualization and gluster, each node providing bricks for a replica 3 volume, I would like to mount the volume from 127.0.0.1 to distribute i/o and to have a better failover situation.
The right way to do this is to fill in the mount options with:
backup-volfile-servers=<IP1>:<IP2>
-- Diese Nachricht wurde auf Viren und andere gefährliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. For all your IT requirements visit: http://www.transtec.co.uk
participants (2)
-
/dev/null -
Jason Brooks