On Fri, Dec 8, 2017 at 9:50 PM, Matt Simonsen <m...@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
