What is the difference between failover vs high availability?

Question

According to my reading on jboss documentation it says,

We define high availability as the ability for the system to continue functioning after failure of one or more of the servers. A part of high availability is failover which we define as the ability for client connections to migrate from one server to another in event of server failure so client applications can continue to operate.

Is failover part of high availability? How can we differentiate failover vs high availability?

Tera

Answer 1

High Availability

Refers to the fact that the server system is in some way tolerant to failure. Most of the time this is done with hardware redundancy. Assume a machine has redundant power supplies, if one fails the machine will keep running.

Failover

Then you have application redundancy (failover), which usually refers to the ability for an application running on multiple hardware installations to respond to clients in a consistent manner from any of those hardware installations. That way, if the hardware does totally fail, or the O/S dies on a particular machine, another machine can carry on.

SQL Server deals with application redundancy in four ways:

• Clustering
• Mirroring
• Replication
• Log Shipping

Managing

I think High Availability is not only about failure tolerance but general availability of the service provided. This may also comprise hot deployment of SW (OS, middleware, application) and HW changes to the solution without reducing availability. – Pericycle

Answer 2

Failover is a means of achieving high availability (HA). Think of HA as a feature and failover as one possible implementation of that feature. Failover is not always the only consideration when achieving HA.

For example, Cassandra achieves HA through replication, but the degree of availability is determined by data consistency settings. In essence, these settings dictate how many nodes need to respond for an action (a read or a write) to succeed. Requiring more nodes to respond means less availability, and requiring fewer nodes means more availability. That's an example of HA that has nothing to do with failover, strictly speaking.

Buffy

Answer 3

High-availability (HA for short) is a broad term, so when I think about it I tend to think as HA clusters.

From Wikipedia High-availability cluster:

High-availability clusters are groups of computers that support server applications that can be reliably utilized with a minimum amount of down-time. They operate by using high availability software to harness redundant computers in groups or clusters that provide continued service when system components fail. Without clustering, if a server running a particular application crashes, the application will be unavailable until the crashed server is fixed.

So the takeaway from the description above is that HA clusters will provide you with the minimum amount of down-time during a failover. Let me explain the two types of failover that HA clusters can provide you:

1. Hot-Hot / Active-Active: The redundant computers are truly operating in parallel, producing the exact same state, and the exact same output. They are all active nodes, operating as a perfect mirror of each other. In this scenario, your failover down-time is zero, and you can simply pull the power plug from any machine in the cluster without any downtime or disruption to your service.

2. Hot-Warn / Active-Passive: Only one primary computer is the active one, while the other computers in the cluster are passively rebuilding the same state as the primary. When the primary computer fails, it has to be disabled or killed (automatically or by an operator) and then a passive computer from the cluster needs to be made active (automatically or by an operator).

So what is the catch? The catch is that applications that can operate in a HA cluster are not trivial to design as they need to be true deterministic finite-state machines. A classic problem is when your application needs to use the clock to build state based on time, as clocks are very non-deterministic by nature.

Disclaimer: I am one of the developers of CoralSequencer.

Stumpf