About using Keepalived to achieve automatic restart of Nginx and dual-active hot standby high availability

1. Overview

Previously, we used Keepalived to implement dual-machine active-standby high availability of Nginx services, but there were several problems that were not solved. Let's discuss them together today.

1) In the dual-machine active-standby mechanism, if the Keepalived service goes down, the standby machine will be automatically enabled to provide services. However, if the Nginx service goes down due to excessive load, the virtual IP will not point to the standby machine.

2) The characteristic of dual-machine active-standby is that only one machine is providing services, and the standby machine will only provide services after the Keepalived service of the host machine goes down, which greatly wastes resources.

3) Currently it is popular to rent cloud servers to operate the company's products. Does the cloud server support virtual IP?

Today we will explain the above three questions.

2. Use Keepalived to automatically restart Nginx

2.1 Restart Nginx with Shell Script

Keepalived cannot start Nginx directly, but it can execute shell scripts, so here we need to start Nginx with the help of Shell scripts.

In the /etc/keepalived directory, create a new script check_nginx.sh. The following is the specific content of the script:

#!/bin/bash

# Execute the command to view the Nginx process and put it in variable A A=`ps -C nginx --no-header | wc -l`

# Determine whether it is down. If it is down, try to restart it. If the restart fails, stop Keepalived
if [ $A -eq 0 ];then
    /usr/local/nginx/sbin/nginx
    sleep 3
    if [ `ps -C nginx --no-header | wc -l` -eq 0 ];then
        killall keepalived

    fi
fi

The script comes from the Internet

2.2 Grant execution permissions to the script

# chmod +x /etc/keepalived/check_nginx.sh

2.3 Add configuration to the Keepalived configuration file

Open the Keepalived configuration file, # vi /etc/keepalived/keepalived.conf

Modify the configuration file and add the configuration of vrrp_script and track_script. The configuration is as follows:

global_defs {
   
   # Globally unique host identifier router_id server_a
   
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 3 # Run the Shell script every 3 seconds weight 10 # If the script runs successfully, the weight increases by 10
}

vrrp_instance VI_1 {

    # Identifies whether it is a master node or a backup node. The value is MASTER or BACKUP
    state MASTER
    #Bound network card interface ens33
    # Virtual router id, ensure that the primary and backup nodes are consistent virtual_router_id 51
    # Weight priority 100
    # Synchronous check time, the default interval is 1 second advert_int 1
    # Password for authentication and authorization. All active and standby servers need to have the same authentication {
        auth_type PASS
        auth_pass 1111
    }

    track_script {
        check_nginx
    }

    # Virtual IP
    virtual_ipaddress {
        192.168.1.88
    }
}

2.4 Restart Keepalived service

After restarting, I found that Nginx would start automatically soon after it was stopped.

3. Construction of dual-active hot standby

3.1 Overview of Dual Active Hot Standby

Due to the dual-machine master-slave mechanism, only one server will provide services to the outside world at a time, and the configurations of the master and backup machines are the same, which greatly wastes resources.

Dual-active hot standby solves this problem. The principle of dual-active hot standby is that two servers use Keepalived to serve as each other's active backup, so two virtual IPs are required. Then, by using the DNS polling configuration, a domain name is routed to the two virtual IPs in a round-robin manner, ultimately achieving high availability.

3.2 Scenario Description

Virtual IP1: 192.168.1.88

Virtual IP2: 192.168.1.66

A server IP (primary): 192.168.1.144

B server IP (backup): 192.168.1.22

3.3 Modify the A server configuration

The configuration is as follows:

! Configuration File for keepalived

global_defs {
   
   # Globally unique host identifier router_id server_a
   
}

vrrp_instance VI_1 {

    # Identifies whether it is a master node or a backup node. The value is MASTER or BACKUP
    state MASTER
    #Bound network card interface ens33
    # Virtual router id, ensure that the primary and backup nodes are consistent virtual_router_id 51
    # Weight priority 100
    # Synchronous check time, the default interval is 1 second advert_int 1
    # Password for authentication and authorization. All active and standby servers need to have the same authentication {
        auth_type PASS
        auth_pass 1111
    }
    # Virtual IP
    virtual_ipaddress {
        192.168.1.88
    }
}

vrrp_instance VI_2 {

    # Identifies whether it is a master node or a backup node. The value is MASTER or BACKUP
    state BACKUP
    #Bound network card interface ens33
    # Virtual router id, ensure that the primary and backup nodes are consistent virtual_router_id 52
    # Weight priority 80
    # Synchronous check time, the default interval is 1 second advert_int 1
    # Password for authentication and authorization. All active and standby servers need to have the same authentication {
        auth_type PASS
        auth_pass 1111
    }
    # Virtual IP
    virtual_ipaddress {
        192.168.1.66
    }
}

3.4 Modify the B server configuration

The configuration is as follows:

! Configuration File for keepalived

global_defs {
   
   router_id server_b
   
}

vrrp_instance VI_1 {
    
    # Set to backup state BACKUP
    interface ens33
    virtual_router_id 51
    # The weight is set lower than the host priority 90
    advert_int 1
    authentication
        auth_type PASS
        auth_pass 1111
    }
    # The virtual IP needs to be set to the same virtual_ipaddress for both primary and backup
        192.168.1.88
    }
}

vrrp_instance VI_2 {
    
    # Set to master state MASTER
    interface ens33
    virtual_router_id 52
    # The weight is set to be lower than the host priority 100
    advert_int 1
    authentication
        auth_type PASS
        auth_pass 1111
    }
    # The virtual IP needs to be set to the same virtual_ipaddress for both primary and backup
        192.168.1.66
    }
}

3.5 Restart Keepalived on both servers

Just restart Keepalived.

3.6 Setting DNS round robin

Contact your network operator to resolve the issue.

4. Cloud server load balancing

Nowadays, many companies choose to rent cloud servers to run their products because it is more cost-effective, more stable, and has professionals responsible for operation and maintenance.

However, when using a cloud server, you will be subject to the restrictions of the cloud service operator.

Take the virtual IP as an example. Some cloud service operators do not support it.

If virtual IP is not supported, the Keepalived solution can only be abandoned.

But even if Keepalived cannot be used, there are still solutions for Nginx's high availability. Many cloud service providers have launched their own load balancing services (for example: Alibaba Cloud's load balancing SLB and Tencent Cloud's load balancing CLB). We can just rent it directly, we don’t need to configure it ourselves.

5. Overview

Today I talked about KeepAlived's automatic restart of Nginx, the construction of Keepalived's dual-active hot standby high availability, and the cloud server load balancing solution. I hope it will be helpful to everyone.

This is the end of this article about using Keepalived to implement automatic restart of Nginx and dual-active hot standby high availability. For more information about how Keepalived can implement automatic restart of Nginx, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!