Xen Orchestra Application XOA Deployment Options/Best Practices.
-
I am migrating from ESXi to a XCP-NG cluster with 3 servers and have pretty much all of my VMs now migrated over.
I currently have Xen Orchestra Application (XOA) running as a VM on the XCP-NG cluster (this is the open-source, build from source, CE version, of XOA).
If the XOA VM dies or locks up I could be without an easy way to determine the state of the cluster or to resolve any issues.
I do have the VM stored on a contigent SAN and have the XOA VM set up as HA (restart) and have tested failover works OK. But there can be instances when the XOA VM dies or locks up that do not trigger a HA failover in XCP-NG (indeed that has occurred to me twice now and has required my to use XE commands from the XCP-NG host terminal to force reboot the VM to recover).
I am thinking I should run a second backup instance of the XOA VM that can be accessed in case the first is "not working". Potentially using keepalived to present a load-balanced URL/IP for access. I think that would probably work but it feels a bit "clunky".
Any there any other options I am missing to provide availability for XOA? Does anyone have any feeling for what could be best practice here?
-
Hi,
- HA isn't managed by XO but by XCP-ng itself
- So losing XO VM isn't a big deal, as you can redeploy one quickly from XCP-ng small web UI.
Also, XO is stateless for all XCP-ng objects, so it's not critical as you have experienced with vCenter. At least for now. If it becomes more critical in the future, then we'll plan a way to make it with HA bundled.
Finally, XOA is only the version we (Vates) distribute, not the version from the sources
-
@olivierlambert Thanks for the prompt response.
HA isn't managed by XO but by XCP-ng itself
I'm assuming that XO is just a web front end that calls into XCP-NG (with XE calls etc?) to do the majoring of the work. There's obviously some intelligence in XO as it often simplifies several xe commands into a single key press from what I can see.
losing XO VM isn't a big deal, as you can redeploy one quickly from XCP-ng small web UI.
I could redeploy a VM with XOA, I hadn't really thought of that. I should put that in a batch script ready to go in case it is needed.
What exactly do you mean when you say "XCP-ng small web UI" ? I don't think I have heard of that before?
XOA is only the version we (Vates) distribute, not the version from the sources
What is the correct name for the version from the sources then? Is that just called Xen Orchestra?
Whilst redeploying a new VM with Xen Orchestra would be fine, I was also really hoping for a more "instant" solution, that also didn't involve command line scripting in case the VM failed. I assumed running 2 instances would work OK? I has assumed others would be doing something like that too?
-
@geoffbland said in Xen Orchestra Application XOA Deployment Options/Best Practices.:
What exactly do you mean when you say "XCP-ng small web UI" ? I don't think I have heard of that before?
If you go to http://your.xcp-ng.host.ip you will receive web UI with some links to documentation and to management tools, including Xen Orchestra Virtual Appliance quick deploy wizard
XOA is only the version we (Vates) distribute, not the version from the sources
What is the correct name for the version from the sources then? Is that just called Xen Orchestra?
They are calling community version (from sources) XO and precompiled virtual appliance (paid version) XOA.
-
Thanks for the reply.
If you go to http://your.xcp-ng.host.ip you will receive web UI
OK I understand now - thanks.
They are calling community version (from sources) XO and precompiled virtual appliance (paid version) XOA.
Thanks for the clarification.
