Can you mismatch hardware and virtual appliances for high availability?

This question came up here the other day and, while I do not recommend this approach, I thought it would be worth exploring in a blog post, explaining when and how it could be done.

When might you want to do this?

Ok, so I'm guessing most of us have a bigger wish list right now than we have budget for. So what are your options if you still want high availability but can't afford a conventional load balancing solution?

Could you have a dedicated hardware load balancer for all of your load balancing needs, and then a separate virtual appliance to temporarily shoulder the load should you ever have downtime? The short answer is yes.

At the end of the day, we all know downtime can be costly, so does the end justify the means? We might know we need to migrate to virtual but not have the money in the bank right now to achieve this. So what do you do if you want to have a virtual machine as a backup because you're worried your hardware is getting old? Flexibility will be critical for you to ensure you have the right appliance when you need it.

The good news is that with our Freedom License, you can mismatch hardware and virtual as a temporary fix, and then move to virtual for free when you’re ready to retire your hardware!

So, how exactly could you use one of our hardware appliances with a virtual appliance to achieve high availability?

Before I get into this I will reiterate what I said at the beginning - this is not something we recommend. You can do it, however, and it is something that we would support.

Having a like pair of appliances is always our recommended deployment - either a pair of virtual appliances or a pair of hardware appliances. This is because we cannot be sure what the VA is going to be run on, and if it will match the performance of the dedicated hardware for the load balancer. So if you have a CPU intensive deployment and the VA cannot meet the demand, it will cause network bottlenecks and slow things down.

But...if the specs are matched correctly then it should be ok. We recommend scaling the specifications of the vCPU and RAM up around 30% to mitigate the overheads deploying on a hypervisor.

There are however a few reasons why we can't promise that everything will failover smoothly:

• There may be a resource mismatch on the hardware box and virtual machine.
• There may be a version mismatch of the appliances.
• There may be no serial cable support (although thousands of our users use our UDP unicast method of heartbeat).

But if you are on a budget, it is completely possible to have a hardware box dedicated to load balancing and a virtual machine to take over to save you from the dreaded downtime.

In other words, changing where our appliance is hosted will not necessarily take away the things you love (such as configuration sync from the primary appliance to the secondary, and of course a feature rich, highly available load balancing solution).

How could you do this?

Now we get to the fun bit.

To pair your appliance, simply...

1. Head to your load balancer's WebUI on the box you wish to be the Primary, active appliance (I'd recommend the hardware box being the Primary, active due to the dedicated hardware for load balancing).
2. Head to “Cluster Configuration” -> “High Availability Configuration”
3. Fill in the IP and password of the already setup virtual machine.

You can configure the load balancer on the primary, active master, before or after pairing. Either way, you will overwrite the configuration on the secondary, passive node.

Do not configure the Secondary, passive node before pairing, as the configuration will be overwritten with whatever box you’re pairing from.

And there you have it! Keep the questions coming!