Home / server / Questions / 1001966
In Process
pestaa
Asked: 2020-02-06 14:49:26 +0800 CST

Public service failover in a cluster

  • 772

I'm getting started with physical server clustering, and have plans for a 3 node hyperconverged oVirt setup.

I currently deploy all my apps and sites on VPSes and API-provisioned cloud instances. I have some experience with HA, but for each project ultimately there is a single load balancer or webserver, to which a domain name is pointed at.

I understand an oVirt cluster is configured so that each node is FQDN-accessible, be it via a VPN or public names.

But how do I run multiple public vhosts from the cluster when any vm can be moved to practically any host? Should I list all host IP addresses as separate DNS A records and rely on browser failover? Seems odd. Or should I extend the whole cluster with a separate firewall/router that acts as an entry point for all TLDs? Again it becomes a single point of failure and an additional box to colo. Or could it be mandatory to script the zone update?

I'm possibly missing something utterly obvious; all advice is greatly appreciated. Thanks!

domain-name-system cluster ovirt failovercluster

1 Answers

  1. oVirt virtualizes hardware, providing VM instances. Those VMs can be booted on a different physical host.

    Logical virtual networks are typically distinct from the physical network. And VM web3 keeps its IP address when it is migrated from ovirt1 to ovirt2. Those physical nodes are not end user facing.

    However, oVirt VMs is far from a complete consideration of high availability.

    What is your recovery time objective? If it is hours, you have time to do significant repairs. Less gets progressively more complex and expensive.

    Consider application design. How do incoming requests flow, to which instance? Can it be load balanced to multiple instances? Does the load balancer itself need HA? Does its database have a replication solution?

    Appreciate that clusters are difficult to do safely and quickly. Criteria for an oVirt HA VM to restart are not trivial. Disaster recovery is always a consideration, including for the (hopefully unlikely) scenario where the cluster split brains and your data is corrupted. When the application doesn't need a single VM to remain available, VM HA becomes less important.

    Speaking of DR, consider whether multiple sites are in scope. As typical for clusters, oVirt has a couple of DR patterns. Stretch active/active, and separate cluster active/passive. Design decisions here affect the problem domains and the time to recovery. For example, a passive setup could be nearly completely isolated from a storage and layer 2 network perspective. Great, difficult for problems in the primary site to extend there. Think a region in public cloud. But cutting over is a manual process, that may involve DNS updates.

    • 2