HA questions
-
- We don't expose custom fields
- Two node cluster expose you to a risk of splitbrain, so we discourage using HA on 2 nodes (except if you have an external "arbiter")
- HA can be enable in XOA, in Advanced view. You can't configure start order because it doesn't really have a meaning without Vapp feature that's not supported.
- Heartbeat SR can be set via
xeCLI
-
Hi,
so what is the functionality of the HA filed in the advanced options? It show restart for a VM but XCP-ng HA is not enabled.
What is the "best efford" option for the restart for?Split brain is handled by iSCSI-HA, also from HA-Lizard.
Start order would be handy since we have installations with different layers of VMs. All layer 10 VMs have to be started, before the layer 20 VMs can be started because they supply services, the layer 20 VMs rely on, then the layer 30 VMs and so on. Doing that manually is quite an efford.
Best,
Alexander -
I understand you probably want HA, but do you need it?
Also, split brain can't be "handled" in a 2 hosts scenario, that's not really possible in various cases. Don't be surprised to lose data one day (data you won't lose if you didn't use HA).
I know it's not really enjoyable to hear that you don't need something you want.
HA feature in XCP-ng (and originally for XenServer) was meant for a 3 hosts setup, nothing less.
-
Hi,
regarding split brain and iSCSI-HA please consult the documentation to see what is handled and what is not.
Will custom fields ever be exposed? Would really be nice to be able to see and set them as in XCP-ng Center.
Our larger setups with the VM layers consist of multiple nodes and shared external storage (ceph). There the start order after a complete shutdown would be a great benefit. XCP-ng Center allows to configure it.
Are there any plans to support the XCP-ng features in XOA in future or will we always have to use cli?
Best,
Alexander -
I know what are their product claims, but I also know personally the inventor of DRBD, and we discussed this last month when I met him in his office. There's an inherent risk using DRBD on 2 node setup without an external arbiter.
Regarding custom field, that will be the case, check if there's an issue opened in XO Github repository.
Regarding VM order without vApp, I'm not sure it's supported, we already checked that on our side, and this doesn't really work as expected.
You last question: obviously, the goal is to be able to get rid of XCP-ng Center, but we won't introduce features that doesn't work correctly. Order field of a VM without a vApp doesn't work, at least last time we tested it.
-
Hi,
regarding iSCSI-HA, the use of an external ip address for heuristics helps.
Regarding the last question : setting the HA-SR is working correct and necessary to be able to use HA at all AFAIK.
Best,
Alexander -
If you use an external machine, yes it works. But then it's not a 2 nodes scenario
(it's 3 with the arbiter)Regarding HA SR, it might be already done or in a GH issue on XO repo. If not, feel free to create one.
-
Depending on what you regard as a node. I would not regard a switch, which we take for the external ip, as a XEN node.
-
@olivierlambert said in HA questions:
except if you have an external "arbiter"
By that do you mean another install of XCP-ng on a low power machine or something that doesn't actually run any VMs?
-
With iSCSI-HA you just need an IP address that is always reachable from every node. We use the IP address of a managed switch for that. No XCP-ng, no VMs, just a reachable IP address.
-
@olivierlambert Hey, so we've run some basic tests with High Availability (HA) in our environment, which currently runs on two hosts. I understand that you're suggesting that we need at least three nodes to have safe HA without data loss, but I guess I'm wondering what, specifically (if anything) we need to do to configure that third node to do the job that you're saying we need it for. Do we just need to add a third node, and XCP-ng will take care of that for us, or is there some kind of special configuration that we need with that third node?
Further, is there a way that we can set up VMs to return to their affinity host when it comes back up? I've tested a basic HA setup (with our two hosts), and our little test VM died, but it worked - it came back up on the still-living node, which was great. We don't need like, life-or-death mission critical HA, but having services automatically come back in the event of a downed host is pretty damn handy for the flow of daily business operations.
-
Nothing to do for the 3rd node. It's all a matter of quorum, which can't be reached with 2 entities
Regarding affinity, it's only on boot. And it's not mandatory to be compliant, XAPI will do its best. You might try to play with Xen Orchestra Load balancer plugin if you want to keep control on what's running where at any moment.
-
@olivierlambert So we just need three nodes for "quorum", but high availability suggests that a VM "won't" go down in certain instances, correct? If so, "where" is that VM running and would it be correct to say that that third node is present to make a vote as to "which" VM image is running?
Do you guys have a doc on your high availability implementation?
-
Take a look here: https://xen-orchestra.com/blog/xenserver-and-vm-high-availability/
Old but still relevant. XAPI will place the VM where there's enough resources.
