Basic knowledge of high performance cluster software keepalived

I. Introductionof keepalived

Keepalived is the next lightweight, high-availability solution for Linux, which is similar to what Heartbeat and Roseha do, and can be highly usable for services or networks, but with a difference: heartbeat is a professional, fully functional, highly available software, It provides the basic functions required by Ha software, such as heartbeat detection and resource takeover, monitoring of system services in the cluster, transfer of owners of shared IP addresses among cluster nodes, heartbeat powerful, but relatively cumbersome to deploy and use, compared to heartbeat Keepalived mainly through virtual routing redundancy to achieve high-availability features, although it is not heartbeat powerful, but keepalived deployment and use is very simple, all configurations need only one configuration file to complete. This is why this chapter focuses on keepalived.

Second,what is keepalived

The keepalived was originally designed for LVS and was specifically used to monitor the status of each service node in the cluster system. It detects the status of each service node according to the Layer3, 4 & 5 switch system, if a service node is abnormal, or the work fails, keepalived detects and rejects the failed service node from the cluster system, and after the failed node returns to normal, Keepalived can also automatically rejoin this service node to the server cluster, which is fully automated and does not require manual intervention, but only repairs the failed service node manually.

Keepalived later joined the VRRP feature, VRRP is the abbreviation for Virtual Router Redundancy Protocol (redundant protocol to the VM), which is intended to address a single point of failure problem with static routing, Through the VRRP can realize the network uninterrupted, stable operation. Therefore, keepalived has the function of server state detection and fault isolation on the one hand, and HA cluster function on the other. The following details the implementation process of the VRRP protocol.

Iii. VRRP Protocol and working principle

In the real network environment, the communication between the hosts is done by configuring static routes (the default gateway), and once the routers between the hosts fail, the communication fails, so in this mode of communication, the router becomes a single point bottleneck, and in order to solve this problem, the VRRP protocol is introduced.

Readers who are familiar with the Internet should not be unfamiliar with the VRRP protocol. It is a master-and-standby protocol, which involves two concepts: physical router and virtual router, through which the VRRP can transparently switch the device in the event of a network failure without affecting the data communication between the hosts.

VRRP can two or more physical router devices into a virtual router, the virtual router through the virtual IP (one or more) to provide services, and within the virtual router, is a number of physical routers work together, at the same time only one physical router to provide services, This physical router is called the primary router (in the master role). In general, Master is generated by an election algorithm, which has a virtual IP for external services and provides various network functions such as ARP request, ICMP, data forwarding, etc. While other physical routers do not have external virtual IP, and do not provide external network functionality, only receive Master's VRRP status notification information, these routers are collectively referred to as the backup router (in the backup role). When the primary router fails, the backup router that is in the backup role will be re-elected, resulting in a new primary router entering the master role to continue to provide external services, and the entire switchover process is completely transparent to the user.

Each virtual router has a unique identity, called Vrid, and a vrid with a set of IP addresses that make up a virtual router. In the VRRP protocol, all messages are sent via IP multicast, and in a virtual router, only the router in the master role will always send the VRRP packet, and the router in the backup role receives only the message sent by master. is used to monitor the master run state, so backup preemption does not occur unless it has a higher priority. When Master is not available, backup will not be able to receive the message from master, so it is determined that master has failed, then more than one backup will be elected, the highest priority of the backup to become the new master, This kind of election and role switching process is very fast, thus ensuring the continuous availability of services.

Iv. workingprinciple of keepalived

The previous section briefly describes how keepalived works with high-availability features through VRRP, and keepalived as a high-performance cluster software that also enables monitoring and fault isolation of server operations in a cluster. The following is a continuation of the keepalived on how server health monitoring and detection work.

Keepalived works on the third, fourth, and fifth layers of the TCP/IP reference Model, which is the network layer, transport layer, and application layer. According to the functions that the TCP/IP reference Model can implement, the keepalived operation mechanism is as follows.

At the network layer, four important protocols are running: The Interconnection network protocol IP, the Interconnection Network Control Message Protocol ICMP, the address Translation protocol ARP and the reverse address Translation protocol Rarp. The most common way keepalived uses the network layer is to send an ICMP packet (similar to the ping implementation) to each node in the server cluster through the ICMP protocol, and if a node does not return a response packet, the node is considered to have failed. Keepalived will report that this node is invalidated and remove the failed node from the server cluster.

In the transport layer, two main protocols are provided: Transmission Control Protocol TCP and User Data protocol UDP. Transmission Control Protocol TCP can provide reliable data transfer services, IP addresses, and ports that represent a single connection to a TCP connection. To obtain a TCP service, the connection must be established on one port of the transmitter and one port on the receiver, while the keepalived is using the TCP protocol port connection and scanning technology to determine whether the cluster node is normal. For example, for a common Web service default of 80 ports, SSH service default 22 port, etc., once the transport layer detects that these ports do not respond to data return, it is considered that these ports are keepalived, and then force the node corresponding to this port from the server cluster group removed.

In the application layer, you can run FTP, TELNET, SMTP, DNS and other different types of high-level protocols, keepalived operation is also more comprehensive and complex, users can customize the way keepalived work, For example, the user can write a program to run keepalived, and Keepalived will be based on the user's settings to detect the various programs or services are allowed to normal, if the keepalived test results and user settings inconsistent, Keepalived will remove the corresponding service from the server.

V. Thearchitecture of Keepalived

Keepalived is a highly modular software, simple structure, but strong extensibility, such as interested readers, can read the next keepalived source. is the official keepalived architecture topology diagram.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/6C/10/wKiom1U-5OGBU2g0AAHKMde8jdI531.jpg "title=" 111. PNG "alt=" wkiom1u-5ogbu2g0aahkmde8jdi531.jpg "/>

As you can see, the keepalived architecture is divided into two tiers, namely the user space layer and the kernel space layer (Kernel space). The detailed composition of the keepalived two layer structure and the function of its implementation are described below.

The kernel space layer is at the lowest level, and it includes two modules of Ipvs and NetLink. The Ipvs module is a third-party module introduced by keepalived, which enables IP-based load Balancing clusters through Ipvs. The Ipvs is included in the LVS cluster software by default. And for the LVS cluster software, I believe that do operation and maintenance of friends are not unfamiliar: in the LVS cluster, Ipvs installed on a server called director server, while on the director server virtual an IP address to provide services, The user must pass this virtual IP address to access the service. This virtual IP is generally called the LVS VIP, namely virtual IP. Requests that are accessed first go through the VIP to the director server, and then the director server picks a service node from the server cluster node to respond to the user's request.

Keepalived originally is to provide services for LVS, because keepalived can realize the status of the cluster node detection, and IPVS can achieve load balancing function, so keepalived with the help of third-party module Ipvs can easily build a set of load balancing system. Here is a misunderstanding, because keepalived can work well with Ipvs, so many beginners think keepalived is a load balancer software, this understanding is wrong.

In Keepalived, the Ipvs module is configurable, and if load balancing is required, load balancing can be turned on when compiling the keepalived, or it can be closed by configuring the compile parameters anyway.

NetLink module is mainly used to implement some advanced routing framework and some related network functions, complete the user space Layer NetLink Reflector module sent a variety of network requests.

The user space layer is located above the kernel space layer, and all the specific functions of keepalived are implemented here, and the functions implemented in several important sections are described below.

In the user space layer, keepalived is divided into four parts, namely scheduler I/O multiplexer, Memory Management, Control plane and core components. where Scheduler I/O multiplexer is an I/O multiplexing Distribution Scheduler, it is responsible for scheduling keepalived all internal task requests. The memory management is a mechanism for managing memories, a framework that provides some common methods for accessing memory. Control plane is the Keepalived dashboard, can be implemented to compile and parse the configuration file, keepalived configuration file resolution is special, it is not to parse the configuration of all modules at once, but only when a module is used to resolve the corresponding configuration. Finally, let's talk about core components, which is the core component of keepalived and contains some of the column function modules, mainly watchdog, checkers, VRRP Stack, IPVS Wrapper and NetLink Reflector, the following describes the functions implemented by each module as follows.

(1)WatchDog

Watchdog is a very simple and very effective detection tool in the field of computer reliability, which works by setting a counter and a threshold for the target being monitored, watchdog increments the value itself, and waits for the monitored target to periodically reset the count. Once the target is monitored, the value cannot be reset, watchdog will be detected, and a corresponding recovery measure, such as restart or shutdown, can be taken.

The watchdog feature was introduced early in Linux, and keepalived is monitoring checkers and VRRP processes through watchdog's operating mechanism.

(2)Checkers

This is the most basic function of keepalived, and also the most important function, which can realize the server running state detection and fault isolation.

(3)VRRP Stack

This is the VRRP feature that keepalived later introduced to enable failover (Failover) functionality in Ha clusters. Keepalived can deploy a high-performance load Balancing cluster system with VRRP function combined with LVS load balancer software.

(4)IPVS Wrapper

This is an implementation of the Ipvs feature. The IPVS wrapper module can send a set of IPVS rules to the kernel space and submit it to the IPVS module, which ultimately implements the load balancing function of the IPVS module.

(5)NetLink Reflector

Used to set up and switch virtual IP (VIP) when failover in a highly available cluster. All requests for NetLink reflector are finally sent to the NetLink module of the kernel space to complete.

This article is from the "Technical Achievement Dream" blog, please be sure to keep this source http://ixdba.blog.51cto.com/2895551/1639562

Basic knowledge of high performance cluster software keepalived