If you are trying to re-use the existing bricks (gluster hosts) for
both clusters, you could potentially do it by making a seperate volume
on each brick. Then just have both clusters use their own specific
volume.
Underneath the volumes could have different physical media backing
them, or if you're willing to sacrifice space and visibility in the
GUI, the same media. (You'll need to keep them on separate filesystem
trees though.)
As for the engine VM, there's no way for it to use a separate cluster
other than the one it's assigned to, and VMs cannot be shared /
migrated across clusters. (Again, that's due to oVirt not having a
generic CPU type that would work regardless of the host's
manufacturer.)
I've never tried this but, you could potentially fudge it by exporting
the engine VM and re-importing it into the new cluster, setup some
external failover solution that would remap the IPs / hostname, and
start up the VM on the alternate cluster if the original one went down
using the rest api. oVirt can recover from an unexpected engine host
shutdown, (it has to for the hosted engine to work at all), but that
support assumes that only one engine host is present per database. At
the very least, the engine database would need to be on a separate
host, possibly with it's own mirroring and failover solution, and once
the original engine VM was restored, said VM would need to recognize
the other engine already has control over the data center, and not
interfere with the other engine. (I.e. The restored engine would need
to terminate until the replacement was shut down. Both VMs can *never*
be running at the same time.)
Of course, it goes without saying that this idea is completely
unsupported, the second engine VM would need to be kept up-to-date with
the original to avoid conflicts, and such a setup would be inherently
unstable. (Only as stable as the chosen database mirroring and failover
solution.) But if you've got a test setup to toy around and get
measurements with, it might be a fun project to spend a weekend on. :)
-Patrick Hibbs
On Fri, 2022-03-11 at 18:14 +, Abe E wrote:
> Has anyone setup hype converged gluster (3Nodes) and then added more
> after while maintaining access to the engine?
> An oversight on my end was 2 fold, Engine gluster being on engine
> nodes and new nodes requiring their own cluster due to different CPU
> type.
>
> So basically I am trying to see if I can setup a new cluster for my
> other nodes that require it while trying to give them ability to run
> the engine and ofcourse because they arent part of the engine
> cluster, we all know how that goes. Has anyone dealt with this or
> worked around it, any advices?
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/QGP2ZCESCWLFQXHX5XSVNM5AK7KXAOAX/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OTGI4A6AZ3CMPWFQMA7JKQOUX2Y5BURL/
