On Fri, Dec 8, 2017 at 9:50 PM, Matt Simonsen <matt(a)khoza.com> wrote:
Hello all,
I read with Gluster using hyper-convergence that the engine must reside on
the same LAN as the nodes. I guess this makes sense by definition - ie:
using Gluster storage and replicating Gluster bricks across the web sounds
awful.
This got me wondering about best practices for the engine setup. We have
multiple physical locations (co-location data centers).
In my initial plan I had expected to have my oVirt engine hosted
separately from each physical location so that in the event of trouble at a
remote facility the engine would still be usable.
In this case, our prod sites would not have a "hyper-converged" setup if
we decide to run GlusterFS for storage at any particular physical site, but
I believe it would still be possible to use Gluster. In this case oVirt
would have a 3 node cluster, using GlusterFS storage, but not
hyper-converged since the engine would be in a separate facility.
Is there any downside in this setup to having the engine off-site?
This is called a stretched cluster setup. You have pro and cons, for
instance host fencing could become problematic.
VM leases could help:
https://ovirt.org/develop/release-management/features/storage/vm-leases/
Rather than having an off-site engine, should I consider one engine per
physical co-location space?
This would be simpler but you are going to loose a few capabilities that
can be relevant in a disaster recovery scenario.
Thank you all for any feedback,
Matt
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users