I have several questions about how Virtual IP works for a failover implementation. The goal is to accomplish high-availability of a service running on a TCP server.

The problem can be easily described:

enter image description here


  1. Let's say Machine A running the Primary Server dies. How does the Virtual IP software on Machine 1 work? Does the client need to reconnect to be redirected to the Backup Server on Machine B? Does this machine/connection switch happen transparently?

  2. Is the Virtual IP implemented through software or hardware? Can you give me examples of software solutions that I can use/test?

  3. How about the Virtual IP software being a single-point-of-failure? What happens if Machine 1 dies? Does the Virtual IP software itself have some kind of failover / high-availability capabilities?

  • 1
    @Appleoddity have already made a good answer. If you "just" want to manage the IP's you can take a look into keepalived – Aleksandar Oct 14 '17 at 6:54

We should clarify some terms and technology.

The image you show is that of a "Load Balancer." While technically, the Load Balancer will usually have one or more "frontend" IP addresses that connect to one or more "backend" servers - those frontend IP addresses are not "virtual IPs."

When we talk about virtual IPs we are talking about server clustering. With server clustering there is no load balancer. Instead all servers in the cluster assume the same IP address. They monitor each other with a heartbeat, and make decisions on what server will respond to the requests on the IP address they share.

Now, obviously, you could have clustered load balancers that share one or more IP addresses.

So here are some answers:

1) Machine 1 doesn't run "Virtual IP" software. It runs "Load Balancing" software. What happens to the client when a server goes down is entirely dependent upon your load balancer configuration AND your backend applicaton capabilities. If you have a stateless backend, or shared storage that results in state sharing then when one server fails the user will typically connect to the other server seamlessly and without interruption to their session. In fact, in this scenario, each request the client makes may actually load balance across both servers even during the same session. In other cases, the statefulness is not shared and the user will have to initiate a new session to the other server.

2) Again, it is not a Virtual IP. Virtual IP is a clustering technology. Load Balancers can have multiple public facing IP addresses depending on your actualy, physical setup. It can be done with both hardware or software. Specific recommendations for software or hardware are outside the scope of ServerFault. You can use Google for that.

3) Yes, the load balancer can be a single point of failure. If the load balancer goes down, everything goes down. Implementing true high-availability is something that requires a lot of money and technical know how. In today's cloud computing world - this is best left up to the pros like Microsoft Azure and Amazon AWS. They implement highly-available, redundant systems that you can lease for dirt cheap.

When it comes to high-availability you need to consider every point of failure.

This includes, but is probably not limited to:

  1. Power
  2. Internet
  3. Routers
  4. Switches
  5. Network cables
  6. Server failures (power supplies, motherboards, CPUs, disk drives)
  7. Software crashes
  8. DDoS and other over utilization problems

So, long story short. The scenario described in your drawing isn't even remotely close to providing a highly-available environment.

| improve this answer | |
  • 1
    You did not answer any of my questions, but that's ok. Thanks anyways! – David Oct 14 '17 at 14:08
  • 1
    Come on, please reopen the question. – Ggicci Jul 16 '19 at 13:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.