Shulou(Shulou.com)06/02 Report--

In this highly information-based IT era, the production system, business operation, sales and support, and daily management of enterprises increasingly rely on computer information and services, and the demand for the application of high availability (HA) technology is increasing in order to provide continuous and uninterrupted computer systems or network services.

1. Overview of the basic knowledge of Keepalived dual-computer hot backup 1.Keepalived

Keepalived was originally a powerful auxiliary tool designed specifically for LVS, mainly used to provide failover and health check functions-to determine the availability of LVS load dispatchers and node servers, isolate and replace them with new servers in time, and rejoin the cluster when the failed host is restored.

Keepalived's official website: although http://www.keepalived.org/ is mainly used in LVS cluster environment, it can also be used as hot backup software in non-LVS cluster environment.

Hot standby mode of 2.Keepalived

Keepalived adopts VRRP (Virtual routing redundancy Protocol) hot backup protocol to realize the multi-machine hot backup function of Linux server in the way of software. VRRP is a backup solution for routers-multiple routers form a hot backup group that provides services through a shared virtual IP address; only one router in each hot backup group provides services at a time, and other routers are in a redundant state. If the current online router fails, the other routers will automatically replace (according to priority) the virtual IP address to continue to provide services.

The principles of VRRP (Virtual routing redundancy Protocol) and HSRP (Hot standby routing Protocol) are almost the same, except that VRRP is a public protocol; HSRP is a private protocol of Cisco. For the principle of VRRP (Virtual routing redundancy Protocol) is not clear, you can refer to the blog post: HSRP (Hot backup routing Protocol) detailed explanation of the blog article.

Each router in a hot standby group may be called the primary router, and the IP address (VIP) of the virtual router can be transferred between the routers in the hot standby group, so it is also called a drift IP address, as shown in the figure:

When using Keepalived, the implementation of the drift address does not need to manually establish a virtual interface profile (such as ens33:0); instead, it is automatically managed by Keepalived based on the configuration file.

3. Install Keepalived

It is very easy to install Keepalived services. There are corresponding software packages on the Centos 7 system disk, which can be installed through YUM! In addition, ipvsadm management tools (used when viewing load distribution) are also required when applied in a LVS cluster environment.

[root@localhost ~] # yum-y install keepalived ipvsadm// install Keepalived and ipvsadm [root @ localhost ~] # systemctl start keepalived// start Keepalived service 2, use Keepalived to achieve dual hot backup

Based on the hot backup method of VRRP, Keepalived can be used for server failover, and each hot backup group can have multiple servers-of course, the most commonly used is dual-server hot backup. In this dual-computer hot standby scheme, failover is mainly aimed at the drift of virtual IP addresses, so it can be applied to a variety of application servers (such as Web, FTP, Mail, SSH, DNS, etc.).

Use an example to understand the configuration method of Keepalived dual-machine hot backup, as shown in the figure:

Keepalived needs to be installed in both primary and standby servers. (httpd services had better be installed for testing! ) the 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 operations are as follows:

[root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0 [root@localhost ~] # yum-y install keepalived ipvsadm httpd// install the appropriate service, Close the firewall and Keepalived [root @ localhost ~] # vim / etc/keepalived/keepalived.conf / / Edit the configuration file of the Keepalived service, global_defs {root {root / / recipient address} notification_email_from root root@localhost.localdomain / / sender name, Address smtp_server 127.0.0.1 smtp_connect_timeout 30 / / the above information is about the content of sending mail Just fill in router_id HA_TEST_R1 / / the name of this router (server)} vrrp_instance VI_1 {/ / define VRRP hot backup instance state MASTER / / hot backup status according to the actual situation. MASTER represents the ID of the primary server interface ens33 / / the physical network card interface virtual_router_id 1 / / virtual router that hosts the VIP. Each hot backup group maintains a consistent priority 100 / / priority of 100. The higher the number, the higher the priority (maximum 255s) advert_int 1 / / seconds between announcements (heartbeat rate) authentication {/ / authentication information Each hot backup group should maintain consistent auth_type PASS / / authentication type auth_pass 1111 / / password string} virtual_ipaddress {192.168.1.254 / / specify drift address (VIP) There can be multiple (but must be on the same network segment as the physical interface)}}

After confirming that there are no errors in the configuration information, start the Keepalived service. The master server with the actual state of MASTER will automatically add the VIP address to the ens33 interface, which can be viewed by the ip command (not seen by the ifconfig command).

[root@localhost ~] # systemctl restart keepalived// restart service [root@localhost ~] # ip addr show dev ens33// to check whether the drift IP address exists 2: ens33: 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 brd 24 brd 192.168.1.255 scope global ens33 valid_lft forever preferred_lft forever inet 192. 168.1.254 scope global ens33 valid_lft forever preferred_lft forever inet6 fe80::c4bc:2e5a:89b:8729/64 scope link valid_lft forever preferred_lft foreve 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// modifies the home page file of the httpd service For testing! two。 Configuration of standby server

In the same Keepalived hot backup group, the Keepalived configuration files of all servers are basically the same, including virtual router ID, authentication information, drift address, heartbeat rate, etc. (must be the same); the main difference lies in router name, hot standby status, priority.

Router name: it is recommended to specify a different name for each server participating in the hot backup; hot standby status: there should be at least one primary server. Set the status to MASTER; and multiple standby servers, and set the status to BACKUP; priority: the higher the value, the higher the priority of obtaining VIP control, so the priority of the primary server should be the highest in the hot standby group. The priorities of other standby servers can be decreased in turn, but not the same, so as to avoid conflicts when competing for control of VIP.

When configuring a standby server (there can be multiple servers), you can refer to the contents of the keepa.conf configuration file of the primary server, and just modify the router name, hot standby status, and priority. As follows:

[root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0 [root@localhost ~] # yum-y install keepalived ipvsadm httpd// install the appropriate service, Close the firewall and Keepalived [root @ localhost ~] # vim / etc/keepalived/keepalived.conf / / Edit the configuration file of the Keepalived service, global_defs {root {root@localhost.localdomain} notification_email_from root root@localhost.localdomain smtp_server 127.0.0.1 root 30 router_id HA_TEST_R2 / / the name of this router (server) Call (modify)} vrrp_instance VI_1 {state BACKUP / / Hot standby status BACKUP means standby server (modified) interface ens33 virtual_router_id 1 priority 99 / / priority (modified) advert_int 1 authentication {auth_type PASS auth_pass 1111} virtual_ipaddress {192.168.1.254}}

Confirm that the configuration is correct, start the Keepalived service, and the primary server is online. The VIP is still controlled by the primary server, while other servers are in a standby state.

[root@localhost ~] # systemctl start keepalived [root@localhost ~] # ip addr show ens33// starts the Keepalived service, Confirm the VIP address (no VIP address) 2: ens33: 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 pick 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// starts the http service Set up a different home page (for testing! ) 3. Test dual hot standby function (1) connectivity test

Execute "ping-t 192.168.1.254" (VIP address) on the client, can communicate normally, continue to test!

[root@localhost ~] # systemctl stop keepalived// master server intentionally stops Keepalived service

View the results of the client test, as shown in the figure:

The customer may have a delay when switching, or he may lose one or two packets.

[root@localhost ~] # ip addr show ens33// standby server to check the VIP address (found that VIP has been automatically transferred to the standby server) 2: ens33: 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 link/ether 00:0c:29:2b:56:b5 brd ff:ff:ff:ff:ff:ff inet 24 brd 192.168.1.255 scope global ens33 valid_lft forever preferred_lft forever inet 192. 168.1.254 Web 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) access Test

Client access test, as shown in the figure:

When the Keepalived service is turned on on the server with the original priority of 100, the client accesses it again, which will change the content of the page.

[root@localhost ~] # systemctl start keepalived// master server starts Keepalived service

Client access test, as shown in the figure:

You can also check the system log (/ var/log/messages) for more information!

A highly available cluster is built through Keepalived service, which is different from a load balancing cluster built through LVS. For information on cluster types, please refer to the blog post: LVS load balancing Cluster details

The main purpose of this blog is to use Keepalived to build dual-computer hot backup (one master + one standby); by the same token, it is the same to use Keepalived to build multi-machine hot backup (one master + multi-backup). Here is the detailed introduction!

-this is the end of this article. Thank you for reading-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.