How does keepalived work?

The working principle of keepalived is to detect the status of each service node based on the third, fourth and fifth layer switching mechanisms of the TCP/IP reference model. If a server node is abnormal or fails, Keepalived will The failed server node is detected and removed from the cluster system.

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

Keepalived introduction

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

It implements similar functions to HeartBeat, both of which can achieve high availability of services or networks, but there are differences. HeartBeat is a professional, fully functional high-availability software that provides the basic requirements for HA software. Functions, such as: heartbeat detection, resource takeover, detection of services in the cluster, transfer of owners of shared IP addresses on cluster nodes, etc.

HeartBeat is powerful, but deployment and use are relatively troublesome. Compared with HeartBeat, Keepalived mainly implements high availability functions through virtual routing redundancy. Although it is not as powerful as HeartBeat, Keepalived is very easy to deploy and use. Extremely simple, all configurations only require one configuration file.

What is Keepalived?

Keepalived was originally designed for LVS and is specifically used to monitor the status of each service node in the cluster system. It is based on the third, fourth and fifth layer switching mechanisms of the TCP/IP reference model. Detect the status of each service node. If a server node is abnormal or the work fails, Keepalived will detect it and remove the failed server node from the cluster system. All these tasks are completed automatically and do not require Manual intervention requires manual work only to repair the failed service node.

Later Keepalived added the VRRP function. The purpose of VRRP (VritrualRouterRedundancyProtocol, virtual routing redundancy protocol) is to solve the single point of failure problem in static routing. VRRP can achieve uninterrupted and stable operation of the network, so On the one hand, Keepalvied has server status detection and fault isolation functions, and on the other hand, it also has the HAcluster function.

Health check and failover are the two core functions of keepalived. The so-called health check uses TCP three-way handshake, ICMP request, HTTP request, UDP echo request, etc. to keep alive the actual server behind the load balancer (usually the server that carries the real business); while failed switching is mainly the application For load balancers configured in active and standby mode, VRRP is used to maintain the heartbeat of the active and standby load balancers. When a problem occurs with the active load balancer, the standby load balancer carries the corresponding services, thereby minimizing traffic loss and Provide stability of services.

VRRP protocol and working principle

In a real network environment. Communication between hosts is completed by configuring static routing or (default gateway). Once the router between hosts fails, communication will fail. Therefore, in this communication mode, the router becomes a single point bottleneck. ,In order to solve this problem, the VRRP protocol was ,introduced.

The VRRP protocol is a fault-tolerant master-backup mode protocol, which ensures that when the host's next-hop route fails, another router will replace the failed router. VRRP can be used on the network When a failure occurs, device switching is performed transparently without affecting data communication between hosts.

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

A virtual router has a virtual IP address and 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}. Normally, the virtual router uses the virtual MAC address in response to the ARP request. Only when the virtual router is specially configured, will it respond to the real MAC address of the interface.

Main router (MASTER): The virtual router provides services to the outside world through the virtual IP, and within the virtual router, there is only one physical router that provides services to the outside world at the same time. This physical router that provides services is called the master router. Generally, the Master is generated by an election algorithm. It has a virtual IP for external services and provides various network functions, such as ARP requests, ICMP data forwarding, etc.

Backup router (BACKUP): Other physical routers in the virtual router do not have external virtual IPs, nor do they provide external network functions. They only accept the VRRP status advertisement information of the MASTER. These routers are called backup routers. When the main router fails, the backup router in the BACKUP role will be re-elected to generate a new main router to enter the MASTER role and continue to provide external services. The entire switch is completely transparent to users.

VRRP election mechanism

The VRRP router has three states during operation:

1. Initialize state: After the system starts, it enters Initialize. In this state, the router does not process VRRP packets;

2. Master state;

3. Backup state;

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

VRRP uses an election mechanism to determine the status of the router. Priority election:

1. IP owner in the VRRP group. If the virtual IP address is the same as the IP address of a VRRP router in the VRRP group, then this router is the owner of the IP address and this router will be positioned as the master router.

2. Compare priorities. If there is no IP address owner, compare the priorities of the routers. The priority range is 0~255. The one with the higher priority will be used as the main router

3. Compare the IP addresses. In the case where there is no IP address owner and the priority is the same, the one with the larger IP address acts as the main router.

As shown in the figure below, the virtual IP is 10.1.1.254. There is no IP address owner in the VRRP group. Then compare the priorities. Obviously the priorities of RB and RA are greater than RC. Then compare RA and RB. The IP address of RB is larger. So RB is the main router in the group.

Working process

After the router uses the VRRP function, it will determine its role in the backup group based on priority. The router with higher priority becomes the Master router, and the router with lower priority becomes the Backup router. The Master has a virtual IP for external services, provides various network functions, and regularly sends VRRP messages to notify other devices in the backup group that it is working normally; the Backup router only receives message information sent by the Master to monitor the operation of the Master. state. When the Master fails, the Backup router will elect, and the Backup with higher priority will become the new Master.

In preemption mode, when the Backup router receives the VRRP message, it will compare its own priority with the priority in the message. If it is greater than the priority in the advertisement message, it will become the Master router; otherwise it will remain in the Backup state;

In non-preemption mode, as long as the Master router does not fail, the routers in the backup group will always remain Master or Backup. status, the Backup router will not become the Master router even if it is subsequently configured with a higher priority;

If the Backup router does not receive the VRRP message sent by the Master router after its timer expires, it is considered The Master router is no longer working properly. At this time, the Backup router will think that it is the Master router and send VRRP packets to the outside world. The routers in the backup group elect a master router based on priority to assume the packet forwarding function.

Keepalvied’s working principle

Keepalived’s working principle for server running status and fault isolation:

Keepalived works in the third phase of the TCP/IP reference model Layer, four, and five (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 Ping function), if a node does not return a response packet, it is considered that the node has failed. 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 the TCP protocol in the transport layer to determine whether the port of the cluster node is normal, such as port 80 of the common WEB server. Or SSH service port 22. Once Keepalived detects that these port numbers have no data response or data return at the transport layer, it will consider these ports to be abnormal, and then forcibly remove the nodes corresponding to these ports from the server cluster.

Application layer (5): The operation mode of Keepalived is also more comprehensive and complex. Users can customize the working mode of Keepalived. For example, you can run Keepalived by writing a program or script, and Keepalived will be run according to the The user's set parameters detect whether various programs or services are allowed to function normally. If Keepalived's detection results are inconsistent with the user's settings, Keepalived will remove the corresponding server from the server cluster.

Keepalived Architecture

Keepalived was originally designed for LVS. Since Keepalived can detect the status of cluster nodes, and IPVS can realize the load balancing function, Keepalived relies on The third-party module IPVS can easily build a load balancing system. The IPVS module in Keepalived is configurable. If you need the load balancing function, you can turn on the load balancing function when compiling Keepalived, or turn it off through compilation parameters.

SchedulerI/OMultiplexer is an I/O multiplexing distribution scheduler, which loads all internal task requests of Keepalived;

Memory Mngt is a memory Management mechanism, this framework provides some common methods of accessing memory;

Control Plane is the control plane of keepalived, which can compile and parse configuration files;

Core componets This part mainly includes 5 parts;

• Watchdog: It is an extremely simple and very effective detection tool in the field of computer reliability. Keepalived monitors Checkers and VRRP processes through it.

• Checkers: This is the most basic function of Keepalived and the most important function. It can detect the running status of the server and isolate faults.

• VRRP Stack: This is the VRRP function that keepalived later quoted, which can realize the failover function in the HA cluster. Responsible for failover switching between load balancers FailOver;

• IPVS wrapper: This is an implementation of the IPVS function. The IPVSwarrper module sends the kernel space that can be set up and provides IPVS rules to IPVS module finally realizes the load function of IPVS module.

• Netlink Reflector: Used to implement the setting and switching of virtual IP (VIP) during high-availability cluster Failover.

When keepalived is running, it will Start 3 processes, namely: core (core process), check and vrrp

- core: responsible for the startup, maintenance and loading of the global configuration file of the main process;

- check: responsible for Health check

- vrrp: Used to implement the vrrp protocol

Compare with heartbeat/corosync

The three cluster components of Heartbeat, Corosync, and Keepalived Which one should we choose? Heartbeat and Corosync belong to the same type. Keepalived, Heartbeat and Corosync are not the same type at all.

Keepalived uses the vrrp virtual routing redundancy protocol method; Heartbeat or Corosync is a high-availability method based on host or network services; simply put, the purpose of Keepalived is to simulate the high availability of the router, Heartbeat or Corosync The purpose is to achieve high availability of Service.

So generally Keepalived is used to achieve front-end high availability. Commonly used combinations of front-end high availability include our common LVS Keepalived, Nginx Keepalived, and HAproxy Keepalived. Heartbeat or Corosync is used to achieve high availability of services. Common combinations include Heartbeat v3 (Corosync) Pacemaker NFS Httpd to achieve high availability of Web servers, and Heartbeat v3 (Corosync) Pacemaker NFS MySQL to achieve high availability of MySQL servers.

To summarize, Keepalived implements lightweight high availability, which is generally used for front-end high availability and does not require shared storage. It 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.

(Recommended learning: linux tutorial)

The above is the detailed content of How does keepalived work?. For more information, please follow other related articles on the PHP Chinese website!