Tenant Cloud Network Virtual Private Cloud Best Practice

Building High Availability Primary/Secondary Cluster with HAVIP+Keepalived

Last Updated At: 2025-10-21 09:10:00

This document will introduce how to build a high availability primary/secondary cluster with keepalived software + high availability virtual IP (HAVIP) in VPC.

Basic Principles

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. The high-availability primary/secondary model is widely applied, such as MySQL primary/replica switch and Nginx Web connect.

In VPC, high availability primary/secondary clusters can be implemented by deploying Keepalived on Cloud Virtual Machines. Keepalived is a VRRP protocol high availability software. To use Keepalived, first complete its configuration in the Keepalived.conf file.

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 VPC, keepalived can be deployed to build primary/secondary high availability clusters. Compared to physical networks, the main difference is:
- The VIP used must be a High Availability Virtual IP (HAVIP) applied from the cloud platform.
- The VIP has a subnet attribute and can only be bound between machines in the same subnet.

Notes

It is recommended to use unicast method for VRRP communication.
It is recommended to use Keepalived (1.2.24 version and above).
Ensure the following garp-related parameters are configured. Because Keepalived relies on ARP packets to update IP information, missing these parameters may lead to scenarios where the primary device does not send ARP, causing communication anomalies.
```
garp_master_delay 1
garp_master_refresh 5
```
Ensure each primary/secondary cluster within the same VPC needs to be configured with different vrrp router id.
Ensure the "vrrp_strict" configuration is removed, that is, not using the strict mode.
Control the number of VIPs configured on a single network interface. It is suggested that the number of Highly Available Virtual IPs bound to a single network interface not exceed five. If multiple virtual IPs are needed, it is recommended to add or modify the configuration vrrp_garp_master_repeat 1 in the global_defs section of the Keepalived configuration file.
By adjusting the size of the adver_int parameter, balance the resistance to network jitter and disaster recovery speed. If the advert_int parameter is too small, it may be prone to frequent failovers and temporary dual-master (split brain) until the network recovers. If the advert_int parameter is too large, it could lead to slow failover (i.e., longer service downtime) when the host fails. Assess the impact of dual-master (split brain) on your business thoroughly.
The interval parameter in the specific execution items (such as checkhaproxy) of the track_script script shall be appropriately increased to avoid script execution timeout causing a FAULT state.
Optional: Be aware of the increase in disk usage caused by log printing, which can be resolved by tools such as logrotate.

Directions

Note:

The directions in this document are based on the following environmental conditions. When performing the operations, be sure to replace them with actual environmental parameters.

Primary Node Cloud Virtual Machine: HAVIP-01, 172.16.16.5

Replica Node Cloud Virtual Machine: HAVIP-02, 172.16.16.6

High Availability HAVIP: 172.16.16.12

EIP: 81.71.14.118

Image Version: CentOS 7.6 64-bit

Step 1: apply for VIP

Log in to the VPC console.
In the left sidebar, select IP & Network Interface > High Availability Virtual IP.
On the HAVIP Management page, click Apply.
In the Apply for High Availability Virtual IP pop-up dialog box, enter the name, and select the Virtual Private Cloud and subnet where the HAVIP resides, and click OK.

Note:

The IP address of the HAVIP can be assigned automatically or can be filled in manually. If you choose to fill in manually, make sure that the private IP you fill in is within the subnet IP range and is not a system reserved IP. For example, if the subnet IP range is: 10.0.0.0/24, then the available private network IP range is: 10.0.0.2 - 10.0.0.254.

Step 2: Install keepalived software on the primary and secondary servers (version 1.2.24 and above is recommended)

This document provides the method for installing keepalived based on CentOS 7.6 image-type servers.

Check whether the keepalived software package version number meets requirements.
```
yum list keepalived
```

Yes = Execute 2
No = Execute 3

Use yum to install the software package.
```
yum install -y keepalived
```

Use source code to install the software package.< 1></ 1>

tar zxvf keepalived-1.2.24.tar.gz
cd keepalived-1.2.24
./configure --prefix=/
make; make install
chmod +x /etc/init.d/keepalived   // To prevent the error: env: /etc/init.d/keepalived: Permission denied

Step 3: Configure keepalived and bind the high-availability VIP to the primary/secondary Cloud Virtual Machine

Log in to the primary node Cloud Virtual Machine HAVIP-01, execute vim /etc/keepalived/keepalived.conf, and modify the relevant configurations.

Note: In this example, HAVIP-01 and HAVIP-02 will be configured as "equal weight nodes", that is, both are set to BACKUP, with a priority of 100. The advantage is that it can reduce the number of failovers caused by jitter.

  ! Configuration File for keepalived
  global_defs {
     notification_email {
       acassen@firewall.loc
       failover@firewall.loc
       sysadmin@firewall.loc
     }
     notification_email_from Alexandre.Cassen@firewall.loc
     smtp_server 192.168.200.1   
     smtp_connect_timeout 30
     router_id LVS_DEVEL
     vrrp_skip_check_adv_addr
     vrrp_garp_interval 0
     vrrp_gna_interval 0
  }
  vrrp_script checkhaproxy
  {
       script "/etc/keepalived/do_sth.sh" # Check if the business process is running properly. The "do_sth.sh" file is a user-defined service process detection script, execute according to business needs, and replace "do_sth.sh" with the actual script name when executing.
       interval 5
  }
  vrrp_instance VI_1 {
  # Be aware of the primary-secondary parameter selection
  state BACKUP              # Set the initial state to "Backup"
      interface eth0          # The ENI such as `eth0` used to bind a VIP  
      virtual_router_id 51    # The `virtual_router_id` value for the cluster
      nopreempt               # Non-preempt mode,
      # preempt_delay 10      # valid when it is state MASTER    
      priority 100            # Two devices are equal weight nodes of the same value
      advert_int 5        
      authentication {
          auth_type PASS
          auth_pass 1111
      }
      unicast_src_ip 172.16.16.5  # Set the private IP address of the local device.
      unicast_peer {
          172.16.16.6             # IP address of the peer device
      }
      virtual_ipaddress {
          172.16.16.12           # Set the high availability virtual VIP 
      }
      notify_master "/etc/keepalived/notify_action.sh MASTER"
      notify_backup "/etc/keepalived/notify_action.sh BACKUP"
      notify_fault "/etc/keepalived/notify_action.sh FAULT"
      notify_stop "/etc/keepalived/notify_action.sh STOP"
      garp_master_delay 1    # Set the delay in updating ARP cache after transitioning to master status
      garp_master_refresh 5   # Set the interval for sending ARP packets by the primary node

      track_interface {
                  eth0               # The network interface such as eth0 used to bind a VIP
          }
      track_script {
         checkhaproxy 
      }
  }

Press esc to exit the edit mode and enter :wq.<to save and exit.

Log in to the replica node Cloud Virtual Machine HAVIP-02, execute vim /etc/keepalived/keepalived.conf, and modify the relevant configurations.

! Configuration File for keepalived
global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL
   vrrp_skip_check_adv_addr
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}
vrrp_script checkhaproxy
{
    script "/etc/keepalived/do_sth.sh"
     interval 5
}
vrrp_instance VI_1 {
# Be aware of the primary-secondary parameter selection
state BACKUP            # Set the initial states to "Standby"
    interface eth0          # The ENI such as `eth0` used to bind a VIP  
    virtual_router_id 51    # The `virtual_router_id` value for the cluster
    nopreempt               # Set non-preempt mode.
    # preempt_delay 10      # valid when it is state MASTER   
    priority 100            # Two devices are equal weight nodes of the same value
    advert_int 5       
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    unicast_src_ip 172.16.16.6  # Set the local private network IP address
    unicast_peer {
        172.16.16.5              # IP address of the peer device
    }
    virtual_ipaddress {
        172.16.16.12           # Set the high availability virtual VIP 
    }
    notify_master "/etc/keepalived/notify_action.sh MASTER"
    notify_backup "/etc/keepalived/notify_action.sh BACKUP"
    notify_fault "/etc/keepalived/notify_action.sh FAULT"
    notify_stop "/etc/keepalived/notify_action.sh STOP"
    garp_master_delay 1    # Set the delay in updating ARP cache after transitioning to master status
    garp_master_refresh 5   # Set the interval for sending ARP packets by the primary node
    track_interface {
                eth0               # The network interface such as eth0 used to bind a VIP
        }
    track_script {
       checkhaproxy 
    }
}

Press esc to exit the edit mode and enter :wq.<to save and exit.
Restart the keepalived process to apply the configurations.
```
systemctl start keepalived
```
Check the primary/secondary status of the two Cloud Virtual Machines, and confirm that HAVIP has been correctly bound to the primary/secondary servers.

Note:

In this example, HAVIP-01 initiates the keepalived service first, so under normal circumstances, HAVIP-01 will be selected as the primary node. You can log in to the Highly Available Virtual IP Console to view the Cloud Virtual Machine bound to HAVIP as the primary node cloud HAVIP-01.

Step 4: Bind the EIP (optional)

In the High Availability Virtual IP Console, click Bind in the row where HAVIP is located.
In the Bind the EIP pop-up dialog box, select the EIP to be bound and click OK. If no EIP is available, apply in the EIP Console first.

Step 5: use notify_action.sh for simple log recording (optional)

The main logs of keepalived are still recorded in "/var/log/message", and you can add a script for simple log recording via notify.

Log in to the Cloud Virtual Machine and execute vim /etc/keepalived/notify_action.sh command to add the "notify_action.sh" script, which is as follows:

#!/bin/bash
#/etc/keepalived/notify_action.sh
log_file=/var/log/keepalived.log
log_write()
{
    echo "[`date '+%Y-%m-%d %T'`] $1" >> $log_file
}
[ ! -d /var/keepalived/ ] && mkdir -p /var/keepalived/

case "$1" in
    "MASTER" )
        echo -n "$1" > /var/keepalived/state
        log_write " notify_master"
        echo -n "0" /var/keepalived/vip_check_failed_count
        ;;
    "BACKUP" )
        echo -n "$1" > /var/keepalived/state
        log_write " notify_backup"
        ;;
    "FAULT" )
        echo -n "$1" > /var/keepalived/state
        log_write " notify_fault"
        ;;
    "STOP" )
        echo -n "$1" > /var/keepalived/state
        log_write " notify_stop"
        ;;
    *)
        log_write "notify_action.sh: STATE ERROR!!!"
        ;;
esac

Execute chmod a+x /etc/keepalived/notify_action.sh to modify the script permissions.

Step 6: Verify whether the VIP and public network IP are switched normally during primary/secondary switchover

Simulate the host failure by restarting the keepalived process, rebooting sub-machines and other methods to check whether VIP can migrate normally.

If the primary/replica switch is completed, you can see that the host bound in the console has been switched to the backup Cloud Virtual Machine.
Additionally, you can ping the VIP from within the VPC to observe the time interval from network interruption to recovery; each switch causes approximately 4 seconds of ping interruption. Pinging the EIP bound to HAVIP from the public network side also shows about 4 seconds of ping interruption per switch.
Use ip addr show to check whether havip appears on the primary device network interface card.