10:48 a.m.
Hey,
As for libgfapi, there are several uses for it in oVirt, not all fully
implemented at his point. However, you need to remember that this is an
optimization so whenever it's ready it will be release (as a part of the
relevant version) but not having it is still not lacking any functionality.
Per your question, we usually recommend working with replica-3 in hosted
engine scenario. I'd stick to this mode even without HE to ensure you
have replicas as well as quorum in case of a failure. In this mode you
can loose the first host and keep running with replica. Loosing the 2nd
host will cause the FS to become read only. This is double failure which
is pretty impressive for a community project.
Finally, HA is leveraging fencing to ensure we do not start an HA VM on
a host while it's still running on the old host and cause a split brain.
If we do not wish to fence bricks yet still use HA you need to manually
approve each time something happens that host has been rebooted which
kind of make this a manual mode and less highly available.
Doron
On 06/07/15 18:01, Tiemen Ruiten wrote:
Also, while I can imagine why fencing might be a problem, what would
be
the issue with HA?
On 6 July 2015 at 16:52, Tiemen Ruiten <t.ruiten(a)rdmedia.com
<mailto:t.ruiten@rdmedia.com>> wrote:
Thanks Doron,
I would initially start with a 3 host cluster, possibly adding more
hosts later on. Is this enough to ensure integrity of the Gluster
storage domain, eg. in case of host failure?
What are recommendations (if they exist) for the type of Gluster
volume for a 3-5 host cluster (replicated or replicated distributed,
number of replica's)?
Would this setup already leverage libgfapi instead of FUSE?
On 6 July 2015 at 16:33, Doron Fediuck <dfediuck(a)redhat.com
<mailto:dfediuck@redhat.com>> wrote:
On 06/07/15 15:03, Tiemen Ruiten wrote:
> Please note I will -not- be using Hosted Engine.
>
> On 6 July 2015 at 13:54, Tiemen Ruiten <t.ruiten(a)rdmedia.com
<mailto:t.ruiten@rdmedia.com>
> <mailto:t.ruiten@rdmedia.com <mailto:t.ruiten@rdmedia.com>>>
wrote:
>
> Hello,
>
> I'm in the planning stage of setting up a new oVirt
cluster, where I
> would prefer to use the local disks of the hypervisors for a
> GlusterFS storage domain. What is the current
recommendation (for
> version 3.5.x)?
>
> I found this presentation which seems to suggest that it's
possbile
> with some
> caveats:
http://www.ovirt.org/images/6/6c/2015-ovirt-glusterfs-hyperconvergence.pdf
>
> And a few open bugs:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1177791
> https://bugzilla.redhat.com/show_bug.cgi?id=1177775
> https://bugzilla.redhat.com/show_bug.cgi?id=1177773
>
> What I can't find is current information on if this setup
is already
> possible with 3.5.x or it's better to wait for 3.6. Could
someone
> enlighten me?
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>
>
>
>
> --
> Tiemen Ruiten
> Systems Engineer
> R&D Media
>
>
Hi,
most of the current work is focused in hyperconverged using
hosted engine and
this includes the installation and a few other features such as
not fencing hypervisors
to avoid killing running bricks.
If you do not want to use hosted engine, then you should be able
to create bricks
and manage them as a gluster volume which your setup should be
able to work with.
If you do not use HA and/or fencing you should be mostly ok with
this use case.
Anything specific you're looking for?
--
Tiemen Ruiten
Systems Engineer
R&D Media
--
Tiemen Ruiten
Systems Engineer
R&D Media