High Availability for RHV-M

Hi folks, so time ago (years?) I wrote about how to put together High Availability for RHV-M. At the time the actual configuration that I proposed was solid, if a little unorthodox. Still, it certainly left room for improvement. In this week’s post, I’m updating the configuration with something that Red Hat fully supports. They refer to the configuration as Self-Hosted Engine.

Why Hosted Engine?

The primary benefits to using the Self-Hosted Engine, or “HE”, is that it provides a fully supported HA configuration for RHV-M as well as a smaller overall footprint as compared to a traditional deployment of RHV. Also, RHV-M is delivered as an appliance for the HE configuration, so the entire process is streamlined. Who doesn’t like that?

he_good

Let’s go back to the smaller footprint statement a few times though.. First off, in a traditional deployment of RHV, you have RHV-M, plus hosts. That deployment of RHV may be on a bare-metal host or it may be on a VM in a different virtualization environment. Regardless, you’re already using up resources and software subscriptions that you may not want to use. Not to mention the fact that it may cause you to cross-deploy resource across tenant or administrative boundaries that you wouldn’t normally want to cross.

The HE configuration allows for a much “cleaner” and concise deployment in that not only do you deploy fewer resources, but administratively, they are self-contained as well.

The diagram below shows examples of non-HE deployments. In comparison, they aren’t as streamlined. I know the “red x’s” are a little dramatic, but the only truly awful configuration is the second configuration with the separate HA software.. truly unnecessary and added complication.

he_bad

Secondly, from a footprint standpoint there is the option (read: recommendation) of the lightweight host for the HE configuration. I’ve posted several articles now on the “next generation node” (RHVH) and this is a fantastic use case – hosting the RHV-M appliance in an HE configuration as well as some other “infrastructure level” tools. If you have some other VMs that will service the environment such as PXE, DNS*, DHCP, LDAP, they would fit in nicely.

To that end, I would also suggest that the RHV-M appliance and any other infrastructure VMs be in their own RHV data center and cluster, separate from your other workloads. That’s for security, workload separation, and it just makes good sense.

So what is the general workflow? Glad you asked. Essentially, it works like this:

  1. Have a FQDN ready to go (backward and forward lookup must work!!)
  2. Install RHVH, configure the “performance profile” for “virtual host”
  3. Download the RHV-M appliance and transfer it to the RHVH
  4. Launch the `hosted-engine –deploy` command or launch from Cockpit web admin console

Yes, there are other things, but that’s the gist. And it’s still faster than deploying from scratch, and definitely faster than trying to create your own HA configuration..

What else should I know about the HE configuration?

If you’ve been running RHV for a while, then you know that RHV-M handles the HA parts for the VMs that need it.. In other words, if you configure a VM to be highly available, and the host underneath it goes down, that VM will automatically be restarted on another host in the cluster. So now you must be wondering then, if RHV-M handles HA, then how does it restart itself if it itself goes down????

Fantastic question. That is part of the special HE configuration. The HA configuration for RHV-M is actually handled by the hosts in an HE configuration, and as such if you need to do any work such as upgrades or even take RHV-M down, then you put the HA status into maintenance mode.

The other big consideration to be made is performance. Because the configuration has been streamlined and RHV-M has been deployed as an appliance in the HE deployment, most of the decisions have been made for you, but have no fear. If you need to have your PostgrSQL database, data warehouse, or websocket proxy broken out to separate hosts in order to eek out as much horsepower as possible, you can do so. Post deployment.

I plan to follow all of this up with a few demo’s around deployment as well as showing off the HA portion. If you want to find out more, check out the official docs: https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/paged/self-hosted-engine-guide/

*DNS actually wouldn’t be a good candidate in this particular cluster… Losing DNS here would have far reaching implications. 😉

Hope this helps,

Captain KVM

4 thoughts on “High Availability for RHV-M”

  1. Since upgrading to 4.0 requires reinstalling RHV-M on a RHEL 7 host can migration to Hosted Engine be combined with a 3.6 to 4.0 upgrade? Is this something we might see a KB article on?

    1. Hi Jeff,

      Thanks for dropping by. Great question and the answer to your first question is…. YES!!!!! As a matter of fact, the fantastic folks in Red Hat CEE (fancy pants way of saying support) even put together a tool for upgrading from 3.6 to 4.0, and it EVEN SUPPORTS HOSTED ENGINE! And yeah, I might even put a post together on the process of upgrading. 😉

      You’ll find the “upgrade helper tool” at https://access.redhat.com/labs/rhevupgradehelper/

      Captain KVM

      1. Thanks for the response. That upgrade tool is great, but it doesn’t cover this exact scenario. It would be great if they could add upgrading from a non hosted engine environment to a hosted engine environment for the 3.6 to 4.0 upgrade. I’m sure I could figure it out, but it would be really nice to have a validated guide.

        1. Hi Jeff,

          That would actually be 2 separate processes; both of which are supported scenarios. I would do the upgrade first then the conversion.

          Captain KVM

Agree? Disagree? Something to add to the conversation?