How a virtual IP address works (Windows/Linux)?

Evidian SafeKit

How a primary/secondary virtual IP address works in the same subnet?

Case of a mirror cluster with 2 Windows or Linux servers

In a mirror cluster, a primary/secondary virtual IP address is required to reroute clients in case of failover.

How a virtual IP address works in a primary/secondary mirror cluster with 2 servers in the same subnet (Windows/Linux)?

When both servers of the cluster are in the same subnet, the virtual IP address is set on the Ethernet card of the primary server (through IP aliasing). The virtual IP address is a third IP address coming in addition to the two physical IP addresses of server 1 and server 2. Note that with SafeKit, several virtual IP addresses can be set in the cluster on the same Ethernet card or on different Ethernet cards.

If server 1 is the primary server, then the virtual IP address is associated to the Ethernet MAC address of server 1 in the clients ARP caches: mac1 in the figure. If there is a failure of server 1 and a failover on server 2, SafeKit automatically sends gratuitous ARP to reroute clients ARP caches with the Ethernet mac2 address of server 2. Thus, clients are reconnected to server 2 running the application which has been restarted on this server by the SafeKit clustering mechanisms.

When two servers are in remote sites, the previous virtual IP address algorithms are working if they are connected in the same subnet through an extended LAN/VLAN. This is the simplest use case for remote sites.

How a primary/secondary virtual IP address works in different subnets?

Case of a mirror cluster with 2 Windows or Linux servers

How a virtual IP address works in a primary/secondary mirror cluster with 2 servers in differents subnets (Windows/Linux)?

If the servers are in differents subnets, the virtual IP address can be set at the level of a load balancer. The load balancer is configured with the two physical IP addresses of the two servers in their respective subnets. And the load balancer routes the traffic according a health check to servers.

The health check is based on a URL managed by SafeKit servers and answering OK or NOT FOUND according the status of a server. If the server is SECOND, the SafeKit health check returns NOT FOUND. Thus no traffic is sent by the load balancer to the secondary server. And if the server is PRIM, then the SafeKit health check returns OK. Thus all the traffic is sent by the load balancer to the primary server. In case of failover, SafeKit changes its answers to the health check. Thus the traffic of the load balancer is rerouted.

This implementation is the one used in SafeKit mirror-like solutions in the Cloud: Amazon AWS, Microsoft Azure and Google GCP.

Note that there is another solution by rerouting at the DNS level. But this solution is not working in most cases because the prerequisite is that clients makes a DNS resolution after a failover to be rerouted to the new primary server. Most often, they do not and continue their execution with the IP address resolved when they started.

How a load balanced virtual IP address works in the same subnet?

Case of a farm cluster with 2 Windows or Linux servers

How a virtual IP address works for a primary/secondary mirror cluster in the same subnet (Windows/Linux)?

In a load balancing farm cluster, a virtual IP address is required to load balance clients requests and to reroute clients in case of failover. In this example, we consider only two servers but the solution works with more than two servers.

When both servers of the cluster are in the same subnet, the virtual IP address is set on the Ethernet card of both servers (IP aliasing). The virtual IP address is a third IP address coming in addition to the two physical IP addresses of server 1 and server 2. With SafeKit, several virtual IP addresses can be set in the cluster on the same Ethernet card or on different Ethernet cards.

In the ARP cache of clients, the virtual IP address is associated to the Ethernet MAC address of one server: mac1 of server1 in the figure. A filter inside the kernel of server 1 receives the traffic and split it according the identity of the client packets (client IP address, client TCP port).

Once a packet is accepted by the filter on a server, only the CPU and memory of this server are used by the application that responds to the request of the client. The output messages are sent directly from the application server to the client.

If there is a failure of server 1, SafeKit sends gratuitous ARP to reroute clients ARP caches with the Ethernet mac2 address of server 2. Thus, clients are reconnected to server 2.

When two servers are in remote sites, the previous virtual IP address algorithms are working if they are connected in the same subnet through an extended LAN/VLAN. This is the simplest use case for remote sites.

Note that SafeKit does note require a specific multicast Ethernet address like with NLB on Windows and works on Windows and Linux.

How a load balanced virtual IP address works in different subnets?

Case of a farm cluster with 2 Windows or Linux servers

How a virtual IP address works for a primary/secondary mirror cluster in different subnets (Windows/Linux)?

If the servers are in differents subnets, the virtual IP address can be set at the level of a load balancer. The load balancer is configured with the two physical IP addresses of the two servers in their subnets. And the load balancer routes the traffic according load balancing rules (client IP address, client TCP port) and according a health check to servers.

The health check is based on a URL managed by SafeKit servers and answering OK or NOT FOUND according the status of a server. If the server is UP, the SafeKit health check returns OK, else NOT FOUND. In case of failover, SafeKit does not answer anymore OK to the health check on the failed server. Thus the traffic of the load balancer is rerouted.

This implementation is the one used in SafeKit farm-like solutions in the Cloud: Amazon AWS, Microsoft Azure and Google GCP.

Note that there is another solution by load balancing at the DNS level. But this solution is not working in most cases because the prequisite is that clients makes each time a DNS resolution for load balancing and failover. Mostoften, they do not and continue their execution with the IP address resolved when they started.

SafeKit Modules for Plug&Play High Availability Solutions

SafeKit High Availability Differentiators against Competition

Demonstrations of SafeKit High Availability Software

SafeKit Webinar

This webinar presents in 10 minutes Evidian SafeKit.

In this webinar, you will understand:

  • mirror and farm clusters
  • cost savings against hardware clustering solutions
  • best use cases
  • the integration process for a new application

Microsoft SQL Server Cluster

This video shows a mirror module configuration with synchronous real-time replication and failover.

The file replication and the failover are configured for Microsoft SQL Server but it works in the same manner for other databases.

Free trial here

Apache Cluster

This video shows a farm module configuration with load balancing and failover.

The load balancing and the failover are configured for Apache but it works in the same manner for other web services.

Free trial here

Hyper-V Cluster

This video shows a Hyper-V cluster with full replications of virtual machines.

Virtual machines can run on both Hyper-V servers and they are restarted in case of failure.

Free trial here