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

This article mainly explains "what is the working principle of keepalived". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the working principle of keepalived"?

The working principle of keepalived is: according to the switching mechanism of the third, fourth and fifth layers of the TCP/IP reference model to detect the status of each service node, a server node is abnormal or malfunctioning, Keepalived will detect the failure of the server node from the cluster system.

The operating environment of this tutorial: centos7 system, thinkpad T480 computer.

Introduction to Keepalived

Keepalived is the next lightweight and highly available solution for Linux. High availability: in a broad sense, it refers to the highly available rows of the entire system; in a narrow sense, it refers to the redundancy and takeover of the host.

It is similar to HeartBeat to achieve high availability of services or networks, but there are differences. HeartBeat is a professional, fully functional, highly available software that provides basic functions required by HA software, such as heartbeat detection, resource takeover, detection of services in the cluster, transfer of owners of shared IP addresses in cluster nodes, and so on.

HeartBeat is powerful, but it is relatively troublesome to deploy and use. Compared with HeartBeat, Keepalived mainly achieves high availability through virtual routing redundancy. Although it is not as powerful as HeartBeat, Keepalived is very simple to deploy and use. All configuration can be completed with only one configuration file.

What is Keepalived?

Keepalived was originally designed for LVS to monitor the status of each service node in the cluster system. It detects the status of each service node according to the switching mechanism of layers 3, 4 and 5 of the TCP/IP reference model. If a server node is abnormal or fails, Keepalived will detect and remove the faulty server nodes from the cluster system. All this work is done automatically. There is no need for human intervention, what needs to be done manually is to repair the faulty service node.

Later, Keepalived added the function of VRRP. The purpose of VRRP (VritrualRouterRedundancyProtocol, Virtual routing redundancy Protocol) is to solve the problem of single point of failure of static routes, and the network can run stably and continuously through VRRP. Therefore, Keepalvied has the functions of server state detection and fault isolation on the one hand, and HAcluster on the other.

Health check and failover are the two core functions of keepalived. The so-called health check is to keep the actual server (usually the server carrying real business) behind the load balancer alive by means of tcp three-way handshake, icmp request, http request, udp echo request and so on. The failed handover is mainly applied to load balancers configured with active and standby modes, and VRRP is used to maintain the heartbeat of primary and standby load balancers. When there is a problem with the main load balancer, the standby load balancer carries the corresponding business, so as to minimize traffic loss and provide service stability.

VRRP Protocol and its working principle

In the real network environment. The communication between hosts is accomplished by configuring static route or (default gateway). Once the router between hosts fails, the communication will fail, so in this communication mode, the router has become a single point bottleneck. In order to solve this problem, VRRP protocol is introduced.

VRRP protocol is a fault-tolerant protocol in active and standby mode, which ensures that when the next-hop routing of the host fails, another router will replace the faulty router to work. Through VRRP, the device can be switched transparently in the event of network failure without affecting the data communication between hosts.

Virtual router: a virtual router is a collection of all the routers in the VRRP backup group. It is a logical concept and does not really exist. Looking at the routers in the backup group from the outside of the backup group, it feels like all the routers in the group are like one, which can be understood as in one group: primary router + all backup routers = virtual router.

The virtual router has a virtual IP address and a MAC address. The host uses the virtual router as the default gateway. The format of the virtual MAC address is 00-00-5E-00-01-{VRID}. Usually, the virtual router responds to the ARP request with the virtual MAC address, and only when the virtual router is configured specially, it responds to the real MAC address of the interface.

Master router (MASTER): the virtual router provides services through the virtual IP, while only one physical router provides services at the same time inside the virtual router. The physical router that provides services is called the master router. In general, Master is generated by the election algorithm, it has a virtual IP for external services, and provides a variety of network functions, such as: ARP request, ICMP data forwarding and so on.

Backup routers (BACKUP): other physical routers in virtual routers do not have external virtual IP and do not provide network functions, but only accept VRRP status advertisement information of MASTER. These routers are called backup routers. When the primary router fails, the backup router in the BACKUP role will be re-elected to generate a new primary router to enter the MASTER role and continue to provide external services, and the whole handover is completely transparent to the user.

VRRP election mechanism

The VRRP router has three states during operation:

1. Initialize status: after the system starts, it enters Initialize. In this state, the router does not do any processing to VRRP messages.

2. Master status

3. Backup status

Generally, the primary router is in the Master state and the backup router is in the Backup state.

VRRP uses an election mechanism to determine the status of the router, priority election:

The IP owner in the 1.VRRP group. If the virtual IP address is the same as the IP address of a VRRP router in the VRRP group, the router is the owner of the IP address and will be located as the primary router.

two。 Higher priority. If there is no IP address owner, compare the priority of the router. The range of priority is 0x255, and the higher priority is the primary router.

3. Compare IP addresses. In the case of no Ip address owner and the same priority, the large IP address serves as the primary router.

As shown in the following figure, the virtual IP is 10.1.1.254. If there is no IP address owner in the VRRP group, it is a priority. Obviously, the priority of RB and RA is higher than RC, then the IP address of RA and RB is compared, and the IP address of RB is larger. So RB is the primary router in the group.

Working process

After using the VRRP feature, the router determines its role in the backup group based on its priority. The high priority router becomes the Master router, and the low priority router becomes the Backup router. Master has a virtual IP for external services, provides a variety of network functions, and regularly sends VRRP messages to inform other devices in the backup group that they are working properly; Backup routers only receive message messages from Master to monitor the running status of Master. When the Master fails, the Backup router will be elected, and the high priority Backup will become the new Master.

In the preemptive mode, when the Backup router receives the VRRP message, it will compare its priority with the priority in the message. If it is greater than the priority in the advertisement message, it becomes a Master router; otherwise, it will remain Backup.

In non-preemptive mode, as long as the Master router does not fail, the router in the backup group always maintains the Master or Backup state, and the Backup router will not become a Master router even if it is subsequently configured with a higher priority.

If the timer of the Backup router does not receive the VRRP message from the Master router after the timer expires, it is considered that the Master router is no longer working properly, and the Backup router will think that it is a Master router and send a VRRP message to the outside. The router in the backup group selects the Master router according to the priority and undertakes the function of packet forwarding.

How Keepalvied works

How Keepalived isolates server operation status and failures:

Keepalived operates at layers 3, 4, and 5 of the TCP/IP reference model (physical layer, link layer):

Network layer (3): Keepalived sends an ICMP packet to each node in the server cluster through the ICMP protocol (somewhat similar to the function of Ping). If a node does not return a response packet, the node is considered to have failed, and Keepalived will report the node failure and remove the failed node from the server cluster.

Transport layer (4): Keepalived uses the port connection and scanning technology of TCP protocol in the transport layer to determine whether the port of the cluster node is normal, such as port 80 for the common WEB server. Or SSH service port 22. Once Keepalived detects that these port numbers have no data response and data return at the transport layer, it thinks that these ports are abnormal, and then forcibly removes the nodes corresponding to these ports from the server cluster.

Application layer (5): the operation mode of Keepalived is also more comprehensive and complicated. Users can customize the working mode of Keepalived, for example, you can write programs or scripts to run Keepalived, while Keepalived will check whether various programs or services are allowed according to the parameters set by users. If the test results of Keepalived are inconsistent with those set by users, Keepalived will remove the corresponding servers from the server cluster.

Keepalived architecture

Keepalived was originally designed for LVS. Because Keeplalived can detect the state of cluster nodes and IPVS can achieve load balancing, Keepalived can easily build a load balancing system with the help of the third-party module IPVS. In Keepalived, the IPVS module is configurable. If you need the load balancing feature, you can turn on the load balancing feature when compiling the Keepalived, or you can turn it off through the compilation parameters.

SchedulerI/OMultiplexer is an Imax O multiplex distribution scheduler that loads all Keepalived internal task requests.

Memory Mngt is a memory management mechanism, and this framework provides some general methods to access memory.

Control Plane is the control layout of keepalived, which can compile and parse configuration files.

Core componets mainly consists of five parts.

Watchdog: it is a very simple and effective detection tool in the field of computer reliability, through which Keepalived monitors Checkers and VRRP processes.

Checkers: this is the most basic and main function of Keepalived, which can detect and isolate the running state of the server.

VRRP Stack: this is keepalived's later reference to the VRRP function, which enables failover in a HA cluster. Responsible for failed handover FailOver between load balancers

IPVS wrapper: this is an implementation of the IPVS function. The IPVSwarrper module will be able to set the kernel space sent by IPVS rules and provide it to the IPVS module, eventually realizing the load function of the IPVS module.

Netlink Reflector: used to set up and switch virtual IP (VIP) in highly available cluster Failover

When keepalived runs, three processes are started, namely, core (core process), check and vrrp

-core: responsible for starting and maintaining the main process and loading global configuration files

-check: responsible for health check-up

-vrrp: used to implement the vrrp protocol

Compared with heartbeat/corosync et al.

Which of the three cluster components do we choose, Heartbeat, Corosync or Keepalived? Heartbeat and Corosync belong to the same type, while Keepalived and Heartbeat and Corosync are not the same type at all.

The vrrp virtual routing redundancy protocol used by Keepalived; Heartbeat or Corosync is a highly available way based on hosts or network services; to put it simply, the purpose of Keepalived is to simulate the high availability of routers, and the purpose of Heartbeat or Corosync is to achieve the high availability of Service.

Therefore, the general Keepalived is to achieve the front-end high availability, the commonly used front-end high-availability combinations are our common LVS+Keepalived, Nginx+Keepalived, HAproxy+Keepalived. While Heartbeat or Corosync is the high availability of implementing services, the common combinations are Heartbeat v3 (Corosync) + Pacemaker+NFS+Httpd to realize the high availability of Web server and Heartbeat v3 (Corosync) + Pacemaker+NFS+MySQL to realize the high availability of MySQL server.

To sum up, lightweight high availability is implemented in Keepalived, which is generally used for front-end high availability and does not require shared storage, but is generally used for high availability of two nodes. Heartbeat (or Corosync) is generally used for high availability of services, and requires shared storage, and is generally used for high availability of multiple nodes.

Thank you for your reading, the above is the content of "what is the working principle of keepalived". After the study of this article, I believe you have a deeper understanding of what the working principle of keepalived is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.