In this highly informationized IT era, production systems, business operations, sales and support, as well as daily management of enterprises are increasingly dependent on computer information and services. The demand for the application of high availability (HA) technology is constantly increasing in order to provide continuous and uninterrupted computer systems or network services.
I. Basic knowledge of Keepalived dual-computer hot standby
1.Keepalived Overview
Keepalived was originally designed as a powerful assistant tool for LVS. It was mainly used to provide fault handover and health checking functions - to judge the availability of LVS load dispatcher and node server, to isolate and replace them with new servers in time, and to rejoin the cluster when the failed host recovers.
Keepalived's official website: http://www.keepalived.org/ Although it is mainly used in LVS cluster environment, it can also be used as hot standby software in non-LVS cluster environment.
2.Keepalived Hot Standby
Keepalived uses VRRP (Virtual Routing Redundancy Protocol) hot standby protocol to realize the multi-machine hot standby function of Linux server in a software way. VRRP is a backup solution for routers-a hot standby group composed of multiple routers to provide services through shared virtual IP addresses; there is only one router in each hot standby group to provide services at the same time, and other routers are in a redundant state. If the current online router fails, other routers will automatically take over (according to priority) virtual IP. Address to continue to provide services.
VRRP (Virtual Routing Redundancy Protocol) and HSRP (Hot Backup Routing Protocol) are almost the same, except that VRRP is a public protocol; HSRP is a private protocol of Cisco. For VRRP (Virtual Routing Redundancy Protocol) principle is not clear, you can refer to the blog: HSRP (Hot Backup Routing Protocol) There are detailed explanations in the blog.
Each router in the hot standby group may be called the main router, and the IP address (VIP) of the virtual router can be transferred between routers in the hot standby group, so it is also called the drift IP address, as shown in the figure:
When using Keepalived, the implementation of drift address does not need to manually create virtual interface configuration files (e.g. ens33:0); it is automatically managed by Keepalived according to configuration files.
3. Install Keepalived
Installation of Keepalived service is very simple, Centos 7 system disk has the corresponding software package, through YUM installation can be! In addition, when applying in LVS cluster environment, the ipvsadm management tool (used to view load distribution) is also needed.
[root@localhost ~]# yum -y install keepalived ipvsadm //Install Keepalived and ipvsadm [root@localhost ~]# systemctl start keepalived //Start the Keepalived service
2. Using Keepalived to Realize Double Hot Standby
Based on VRRP's hot standby mode, Keepalived can be used for server failover, and each hot standby group can have multiple servers - of course, the most commonly used should be dual hot standby. In this dual hot standby scheme, fault handover is mainly implemented for the drift of virtual IP address, so it can be applied to various application servers (e.g. Web, FTP, Mail, SSH, DNS, etc.).
An example is given to illustrate the configuration method of Keepalived dual-computer hot standby, as shown in the figure:
Keepalived needs to be installed in both primary and standby servers. (httpd services are best installed for testing!) Detailed steps are as follows:
1. Configuration of the primary server
The configuration file for the Keepalived service is / etc/keepalived//keepalived.conf. The specific operation is as follows:
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0
[root@localhost ~]# yum -y install keepalived ipvsadm httpd
//Install appropriate services, close firewalls, and SELinux
[root@localhost ~]# vim /etc/keepalived/keepalived.conf
//Edit the Keepalived service configuration file
global_defs {
notification_email {
root@localhost.localdomain //Addressee address
}
notification_email_from root root@localhost.localdomain //Name and address of sender
smtp_server 127.0.0.1
smtp_connect_timeout 30 //The above information is about the content of sending mail. Fill it in according to the actual situation.
router_id HA_TEST_R1 //The name of this router (server)
}
vrrp_instance VI_1 { //Define a VRRP hot standby instance
state MASTER //Hot standby state, MASTER is represented as master server
interface ens33 //Physical Network Card Interface Bearing VIP
virtual_router_id 1 //The ID of the virtual router, which is consistent for each hot standby group
priority 100 //Priority 100, the higher the value, the higher the priority (maximum 255)
advert_int 1 //Number of seconds between notifications (heart rate)
authentication { //Authentication information, each hot standby group to maintain consistency
auth_type PASS //Authentication type
auth_pass 1111 //Cryptographic string
}
virtual_ipaddress {
192.168.1.254 //Designated Drift Address (VIP) can have more than one (but must be in the same segment as the physical interface)
}
}After confirming that the configuration information is correct, start the Keepalived service. The master server with the actual state of MASTER will automatically add VIP addresses to the ens33 interface and view them through the ip command (the ifconfig command is not visible).
[root@localhost ~]# systemctl restart keepalived
//Restart service
[root@localhost ~]# ip addr show dev ens33
//Check if the drift IP address exists
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:00:11:89 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet 192.168.1.254/32 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::c4bc:2e5a:89b:8729/64 scope link
valid_lft forever preferred_lft foreve
[root@localhost ~]# echo "aaaaaaaaa" > /var/www/html/index.html
[root@localhost ~]# systemctl start httpd
//Modify the home page file of httpd service for testing!2. Configuration of standby servers
In the same Keepalived hot standby group, the Keepalived configuration files of all servers are basically the same, including virtual router ID, authentication information, drift address, heartbeat frequency, etc. (must be the same); the main differences are router name, hot standby status, priority.
- Router Name: It is recommended to specify a different name for each server participating in hot standby.
- Hot standby state: There should be at least one master server, setting the state to MASTER, and there can be multiple standby servers, setting the state to BACKUP;
- Priority: The higher the value, the higher the priority of VIP control will be, so the priority of the primary server should be the highest in the hot standby group; the priority of 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 refer to the keepa.conf configuration file content of the main server, just modify the router name, hot standby status, priority! As follows:
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0
[root@localhost ~]# yum -y install keepalived ipvsadm httpd
//Install appropriate services, close firewalls, and SELinux
[root@localhost ~]# vim /etc/keepalived/keepalived.conf
//Edit the Keepalived service configuration file
global_defs {
notification_email {
root@localhost.localdomain
}
notification_email_from root root@localhost.localdomain
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id HA_TEST_R2 //This router (server) name (modification)
}
vrrp_instance VI_1 {
state BACKUP //Hot standby state, BACKUP stands for standby server (modification)
interface ens33
virtual_router_id 1
priority 99 //Priority (modification)
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.254
}
}Confirm that the configuration is correct and start the Keepalived service when the primary server is online. VIP is still controlled by the primary server, while other servers are in standby state.
[root@localhost ~]# systemctl start keepalived
[root@localhost ~]# ip addr show ens33
//Start the Keepalived service and confirm the VIP address (no VIP address)
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:2b:56:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::aa26:7be4:3379:130f/64 scope link
valid_lft forever preferred_lft forever
[root@localhost ~]# echo "qqqqqqqqqqq" > /var/www/html/index.html
[root@localhost ~]# systemctl start httpd
//Start the http service and set up different home pages (for testing!)3. Testing Hot Standby Function of Dual Computers
(1) Connectivity testing
Perform "ping-t 192.168.1.254" (VIP address) on the client, can communicate normally, continuous testing!
[root@localhost ~]# systemctl stop keepalived //The primary server deliberately stops the Keepalived service
View the client test results, as shown below:
Customer opportunities may be delayed or one or two packages may be lost when switching.
[root@localhost ~]# ip addr show ens33
//The standby server looks at the VIP address (found that the VIP has been automatically transferred to the standby server)
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:2b:56:b5 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global ens33
valid_lft forever preferred_lft forever
inet 192.168.1.254/32 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::aa26:7be4:3379:130f/64 scope link
valid_lft forever preferred_lft forever(2) Web access testing
Client access tests, as shown in Figure 1:
When a server with a priority of 100 turns on the Keepalived service, the client visits it again and changes the content of the page.
[root@localhost ~]# systemctl start keepalived //The primary server starts the Keepalived service
Client access tests, as shown in Figure 1:
You can also view the system log (/ var/log/messages) for detailed information!
The Keepalived service builds a highly available cluster, which is different from the load balanced cluster built by LVS. Information on cluster types can be referenced in blog posts: LVS Load Balancing Cluster Explanation
———————— This is the end of the article. Thank you for reading.————————