Configuration example: https://blog.51cto.com/14227204/2438902
1. The working principle and function of keepalived:

At first, keepalived was a powerful auxiliary tool designed specifically for LVS. It was mainly used to provide fault switching and health checking functions - to judge the availability of LVS load dispatcher and node server, to isolate and replace new servers in time, and to rejoin the cluster when the fault host replies. When deploying LVS environment alone, the whole cluster will fail if the scheduler goes down. When a web node goes down, the client will not be able to access the web page when visiting it. Therefore, combining keepalived and LVS can form a real high-availability cluster. Of course, shared memory in the back end. Storage also has to build a highly available storage server. One of the three can not be satisfied and can not be called a highly available cluster environment.

The official website of keepalived: http://www.linuxvirtualserver.org/ In non-LVS environments, keepalived can also be used as hot standby software

Use.

Keeping alived implements the Linux server by software using VRRP (Virtual Routing Redundancy Protocol) hot backup protocol.

Multi-machine hot standby. VRRP is a backup solution for routers, which consists of multiple routers and a hot standby group.

Over-shared virtual IP (VIP) addresses provide services to the outside world; there is only one master router in each hot backup group at the same time.

For service, other routers are in redundant state. If the current online router fails, other routers will automatically take over.

(Priority determines succession order) Virtual IP addresses to continue providing services.

Each router in the hot standby group may become the main router, and the IP address (VIP) of the virtual router can be in the hot standby group.

Routers are transferred, so they are also called drift IP addresses. With keepalived, the implementation of drift addresses does not need to be manually implemented

Create virtual interface configuration files (e.g. ens33:0), which are automatically managed by keepalived according to the configuration files.

Based on VRRP hot standby mode, keepalived can be used for server failure switching, and each hot standby group can have multiple clothes.

Server - The most commonly used is multi-machine hot standby. In this multi-machine hot standby scheme, fault handover is mainly aimed at virtual IP addresses.

Drift is achieved. Therefore, it can be applied to all kinds of application servers (whether Web, FTP, Mail, SSH, DNS...).
2. Detailed description of the hot standby configuration of keepalived dual computers:
.
Through the following simple environment map, you can get a comprehensive understanding of the configuration and functions of dual hot standby:

1. Configure the main server:

[root@lVS1 ~]# systemctl stop firewalld            #Close the firewall
[root@lVS1 ~]# Yum-y install keepalived ipvsadm installation tools required
[root@lVS1 ~]# systemctl enable keepalived        #Set up boot-up self-startup
[root@lVS1 ~]# cd /etc/keepalived/
[root@lVS1 keepalived]# cp keepalived.conf keepalived.conf.bak         #Backup configuration file
[root@lVS1 keepalived]# vim keepalived.conf               #Editing configuration files

global_defs {
   notification_email {
     acassen@firewall.loc     #Enable mail notification function, where you can configure multiple addresses
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc            #Name and address of sender
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL1           #The name of this server (which must be unique in the cluster).
            ..............    #Omit part of content
}
vrrp_instance VI_1 {                     #Define a VRRP hot standby instance
    state MASTER              #Hot standby state, MASTER represents the primary server (note case)
    interface ens33             #Physical Interface Bearing VIP Address
    virtual_router_id 51                 #The ID number of the virtual router is the same for each hot standby group.
    priority 100                           #Priority 0-100, the greater the value, the more priority.
    advert_int 1                   #Number of seconds between notifications (heart rate).
    authentication {                     #Authentication information, consistent with each hot standby group
        auth_type PASS                #Authentication type
        auth_pass 1111                 #Cryptographic string
    }
    virtual_ipaddress {             #Specify drift addresses, there can be multiple
    192.168.1.100
    }
}

        .........................            #Omit part of content

After confirming that the above configuration is correct, then start the keepalived service. The master server in the actual state of MASTER will automatically add VIP address to the ens33 interface, which can be viewed through the ip command (note: the ifconfig command can not be seen).

[root@lVS1 keepalived]# systemctl start keepalived          #Start the service
[root@lVS1 keepalived]# ip a show dev ens33           #View the ens33 interface
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UPUt qlen 1000
    link/ether 00:0c:29:77:2c:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 192.168.1.100/32 scope global ens33       #You can see that VIP is already configured on ens33.
       valid_lft forever preferred_lft forever
    inet6 fe80::95f8:eeb7:2ed2:d13c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

2. Configure backup server (LVS2):
Within the same keepalived hot standby group, the keepalived configuration files for all servers are basically the same, and certain configuration items are also required.

Must be the same, including the ID number of virtual router, authentication information, drift address, heartbeat frequency and so on. The main difference lies in the path.

By the name of the device, hot standby status, priority. The following points should be paid attention to in the specific configuration:

• Server name (route_id): It is recommended to specify a different name for each server participating in the hot standby.

• Hot standby state: There should be at least one master server to set the state to MASTER; there can be multiple standby servers to set the state to BACKUP.

• Priority: The higher the value, the higher the priority of obtaining VIP control, so the priority of the primary service should be set to the highest; the other standby servers can be reduced in turn, but not the same, so as to avoid conflicts when competing for VIP control.
  .
  When configuring standby servers (there can be more than one), you can copy the keepa.conf file of the main server directly, and modify the name, hot standby status and priority of the server. These three items are all right. Even if the configuration of some web nodes is included, they need not be modified or modified.

[root@LVS2 ~]# systemctl stop firewalld            #Close the firewall
[root@LVS2 ~]# yum -y install keepalived ipvsadm          #Installation of related tools
[root@LVS2 ~]# scp root@192.168.1.1:/etc/keepalived/keepalived.conf /etc/keepalived/
#Use the master server root user to copy the keepalived configuration file of the master server.
root@192.168.1.1 s password:                    #Enter the password of the root user of the primary server
keepalived.conf                             100% 3549     3.5MB/s   00:00   
[root@LVS2 ~]# vim /etc/keepalived/keepalived.conf 
global_defs {
   ...............
   router_id LVS_DEVEL2                    #Modify the server name here
  .....................

}
                ..............
vrrp_instance VI_1 {
    state BACKUP             #Modify the status here to BACKUP
    interface ens33         #If the physical interface of the server hosting VIP is changed, it should also be modified here.
    virtual_router_id 51
    priority 90               #Modification priority is lower than that of the primary server.
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
    192.168.1.100
    }
}   
              .................
#After changing the above lines, save and exit.
[root@LVS2 ~]# systemctl start keepalived         #Startup service
[root@LVS2 ~]# systemctl enable keepalived         #Set up boot-up self-startup

At this point, the primary server is still online, the VIP address is still controlled by the primary server, and the other servers are in the backup state. Therefore, the VIP address will not be added to the ens33 interface in the standby server:

[root@LVS2 ~]# ip a show dev ens33                  #Looking at the ens33 interface, you won't see VIP
2: ens33: <BROADCAST,MULTICAST,Udel state UP group default qlen 1000
    link/ether 00:0c:29:9a:09:98 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::3050:1a9b:5956:5297/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

3. Testing the hot standby function of the two computers:

Turn off the main server or stop the keepalived service. After waiting for about 15 seconds, look at the ens33 network card of the backup server, and you will find that the drift address has been transferred, indicating that the dual hot standby function is in effect. When the primary server starts, the drift address will automatically be transferred back to the primary server.

[root@localhost ~]# ip a show dev ens33   #Viewing Network Card Information of Backup Server after Main Server Shuts Down
2: ens33: <BROADCAST,MULTICAST,UP state UP group default qlen 1000
    link/ether 00:0c:29:9a:09:98 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 192.168.1.100/32 scope global ens33                   #The drift address has been transferred.
       valid_lft forever preferred_lft forever
    inet6 fe80::3050:1a9b:5956:5297/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

When the main server is booted up, it will be found that the VIP has been transferred back to the main server, and the backup server can not find the VIP:

[root@LVS1 ~]# ip a show dev ens33              #View on the primary server
2: ens33: <BROADCAST,MULTICAST,UP,Lefault qlen 1000
    link/ether 00:0c:29:77:2c:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 192.168.1.100/32 scope global ens33             #Here's the VIP address.
       valid_lft forever preferred_lft forever
    inet6 fe80::95f8:eeb7:2ed2:d13c/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
[root@LVS2 ~]# ip a show dev ens33               #View on the backup server
2: ens33: <BROADCAST,MULTICAST,UP,P grou00
    link/ether 00:0c:29:9a:09:98 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope goute ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::3050:1a9b:5956:5297/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever