Overview

A high availability virtual IP (HAVIP) is a private IP address assigned from the CIDR block of a VPC subnet. It is usually used together with high-availability software, such as Keepalived and Windows Server Failover Cluster, to build a highly available primary/secondary cluster.

Note:

• To guarantee the CVM high availability in a primary/secondary cluster, we recommend assigning CVMs to different host machines using placement groups.
• The high availability software should support sending ARP messages.

Features

• You can apply for multiple HAVIP addresses in the console for each VPC.
• You must bind the HAVIP in CVM’s configuration file.
• The HAVIP is subnet-specific and can only be bound to a server under the same subnet through announcement.

Architecture and Principle

Typically, a high availability primary/secondary cluster consists of 2 servers: an active primary server and a standby secondary server. The two servers share the same VIP (virtual IP). The VIP can only work on one primary server at the same time. When the primary device fails, the secondary server will take over the VIP to continue providing services.

• In traditional physical networks, Keepalived's VRRP protocol can be used to negotiate the primary/secondary status. The principle is that the primary device periodically sends free ARP packets to refresh the MAC table of the up-link switch or terminal ARP table, triggering the migration of the VIP to the primary device.
• In a VPC, a high availability primary/secondary cluster can also be implemented by deploying Keepalived on CVMs. However, a CVM instance usually cannot obtain a private IP address through ARP announcement due to security reasons such as ARP spoofing. The VIP must be a HAVIP applied from Cloud Platform, which is subnet-specific. Therefore, a HAVIP can only be bound to a server under the same subnet through announcement.

  Note:

  Keepalived is a VRRP-based high availability software. To use Keepalived, first complete its configuration in the Keepalived.conf file.

The following figure shows the HAVIP architecture.

According to the example figure, CVM1 and CVM2 can be built into a high availability primary/secondary cluster with the following steps:

1. Install Keepalived on both CVM1 and CVM2, configure HAVIP as VRRP VIP, and set the priorities of the primary and secondary servers. Larger values represent higher priorities.
2. Keepalived uses the VRRP protocol to compare the initial priorities of CVM1 and CVM2 and determines the Master server. In this case, CVM1 is the Master server and CVM2 is the Backup server.
3. The Master server sends out ARP messages, announces the VIP (a HAVIP), and updates VIP to mac mappings. In this case, the CVM1 is the Master server and provides services by using the private IP address (HAVIP) for communication. You can see the HAVIP is bound to the Master server CVM1 in the HAVIP console.
4. (Optional) Bind an EIP to the HAVIP in the console to implement communication over the public network.
5. The Master server periodically sends VRRP messages to the Backup server. If the Master server fails to send VRRP messages within a certain period, the Backup server will be set as Master and send out ARP update messages that carry its MAC address. In this case, CVM2 becomes the Master server to provide communication services and handle external access requests. You will see that the CVM bound to the HAVIP changes to CVM2 in the HAVIP console.

Common Use Cases

• Cloud Load Balancer HA
  To deploy Cloud Load Balancers (CLB), you will generally take HA between CLB instances and configure real servers as a cluster. Therefore, you must deploy and use HAVIP as a virtual IP between two CLB servers.
• Relational Database Primary/Secondary
  If Keepalived or Windows Server Failover Cluster are used between two databases to build a highly available primary/secondary cluster, use HAVIP as a virtual IP.

FAQs

Why should I use HAVIP along with Keepalived in a VPC?

Some public cloud vendors do not support binding a private IP address to CVM through ARP announcement due to security reasons such as ARP spoofing. If you directly use a private IP address as virtual IP in the Keepalived.conf file, Keepalived will not be able to update the IP to MAC mapping during the primary/secondary server virtual IP switch. In this case, you have to call an API to switch the IP. Using Keepalived configuration as an example, the IP configurations are as follows:
Using Keepalived configuration as an example, the IP configurations are as follows:

vrrp_instance VI_1 {
    state BACKUP           #Backup
    interface eth0          #ENI name 
    virtual_router_id 51
    nopreempt                   #Non-preempt mode
    #preempt_delay 10
    priority 80
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    unicast_src_ip 172.17.16.7   #Private IP address of the local device
    unicast_peer {
        172.17.16.13           #IP address of the peer device. For example: 10.0.0.1
    }

    virtual_ipaddress {

        172.17.16.3  #Enter the HAVIP address you have applied for in the console.

    }

    garp_master_delay 1
    garp_master_refresh 5

    track_interface {
        eth0              
    }

    track_script {
        checkhaproxy
    }
}

If there is no HAVIP, the following section of the configuration file will be invalid.

virtual_ipaddress {
   172.17.16.3 #Enter the HAVIP address you have applied for in the console.
}