Preliminary study on Keepalived

Keepalived was originally designed for LVS, specifically to monitor the health status of each real server in the LVS cluster system, and later implemented the VRRP protocol, VRRP namely virtual Router Redundancy protocol ( Virtual Router Redundancy Protocol (VRRP), the purpose of this system is to solve the problem of single point of failure in static routing, which can guarantee the uninterrupted and stable operation of the network. Therefore, keepalived on the one hand has the function of the server health detection, on the other hand also has the function of HA cluster.

VRRP uses a campaign protocol to dynamically hand over routing tasks to a VRRP router in the LAN VRRP virtual router .

VRRP Router : The server running the VRRP protocol, used as a VRRP router, is a physical server.

VRRP Virtual Router : Generally consists of two physical VRRP routers, which have a high-availability (fail over) function, together to form a virtual sense of the VRRP router to provide services externally.

So it is generally two servers running the VRRP protocol, two VRRP routers, two VRRP routers that make up a VRRP virtual router. Two VRRP routers one for master, one for backup, and if master hangs, backup becomes the new master, takes over the service, and provides routing capabilities.

VRRP virtual router, there is a virtual IP--VIP, the client is to use this IP address as a static route to access the service, so the VRRP protocol solves the VIP high availability, single point of failure function.

VRRP virtual router, regardless of who is the master, the external is the same Mac and IP (VIP), the client does not need to modify their own routing configuration because of the change of master, for them, this master-slave switch is transparent.

Vrid: The virtual router has a vrid (virtual_router_id, value range 0~255) attribute to flag itself, and all VRRP routers that make up the virtual router must be the same in the configuration file. Because the MAC address of the virtual route contains Vrid, because the MAC address and IP address cannot be changed, in order to ensure that the MAC address is not changed when Master is switched on, all VRRP routers must have the same vrid.
VRRP The principle of solving a static route single point of failure :

In a VRRP virtual router, only the VRRP router as master will always send VRRP ad packets, and backup will not preempt master unless he has a higher priority. When Master is unavailable (backup does not receive the ad pack), the highest priority in multiple backups is preempted to become the new master. This preemption is very fast (<1s) to ensure the continuity of the routing service. And keepalived implements the VRRP protocol.

Installation of keepalived:

Yum install keepalived;

To view the configuration file:

[Email protected] ~]# RPM-QL keepalived/etc/keepalived/etc/keepalived/keepalived.conf/etc/rc.d/init.d/keepalived/ Etc/sysconfig/keepalived/usr/bin/genhash/usr/sbin/keepalived/usr/share/doc/keepalived-1.2.13 ...

keepalived?? The configuration :

The configuration file for the keepalived shown above is located in:/etc/keepalived/keepalived.conf, which generally keepalived the configuration file into three parts:

1> Global configuration : mainly set in the master switch, the administrator's alarm information, including some email configuration information, a flag is which VRRP router fault--router_id;

global_defs{   notification_email   {      [email protected]   }   notification_email_from [email Protected]   smtp_server 127.0.0.1   stmp_connect_timeout   router_id lvs_125}

Notification_email: Recipients of mail;

Notification_email_rom: Mail sender;

Smtp_server: Mail server address;

Smtp_connect_timeout: Message send timeout time;

ROUTER_ID:VRRP Router flag ID, which is the flag which VRRP router has failed;

2> VRRPD Configuration : Is the core of the keepalived, the main configuration vrrp_instance, that is, configure VRRP instances, that is, configure the VRRP router:

Vrrp_instance vi_1 {State   MASTER   interface eth0   virtual_router_id   1   Authentication {      auth_type PASS      auth_pass 308537   }   virtual_ipaddress {      192.168.137.135   }}

State: Specifies which VRRP router is the master, and the value is master/backup;

Interface:vi_1 instance-bound NIC;

VIRTUAL_ROUTER_ID: Specifies the Vrid value of the virtual router, and the Vrid value of the range 0~255,master and backup must be the same;

Priority: The precedence of the instance;

Advert_int: check interval, default 1s;

Authentication: Encryption authentication message, master and backup configuration must be the same;

Virtual_ipaddress: Designate VIP;

3> LVS? Configuration : The configuration section is only required if you are using keepalived to configure and manage LVS, and if you use only keepalived to do ha, the configuration of this part is completely unnecessary.

Virtual_server 192.168.137.135 {   delay_loop 3   lb_algo wrr   lb_kind DR   nat_mask 255.255.255.0   Persistence_timeout   Protocol TCP   real_server 192.168.137.200 {      weight  2      Tcp_check {         Connect_timeout         nb_get_retry 3         delay_before_retry 3         connect_port      }   }   Real_ Server 192.168.137.201 {      weight  1      tcp_check {         connect_timeout         nb_get_retry 3         Delay_before_retry 3 Connect_port}}}       

How the DS server of the main configuration LVs is distributed to RS and the configuration of the RS server.

Virtual_server: Specifies that the VIP address is already port;

Delay_loop: Specifies the time interval for service polling;

Lb_algo: The load balance algorith, which is the loading equalization algorithm;

Lb_kind: Load Balance Kind (dr/tun/nat);

Persistence_timeout: Session hold time, per second;

Real_server: Specify the IP and port of the RS service;

Tcp_check: Specify keepalived How to perform a health check on RS;

Note on the BACKUP VRRP router, it must be modified: State Backup,priotiry, router_id best also modified under lvs_126.

keepalived Health Check method :

Keepalived can work in the IP layer of the IP/TCP protocol stack, TCP layer, and application layer, so the corresponding health check method must also have a variety.

TCP Health Check mode, SMTP health check mode, http_get| Ssl_get Health Check Way, Misc_check and so on.

The health check of RS in LVs above is the use of Tcp_check. Using Keepalived's misc_check approach, we can write our own scripts for health checks:

Real_server 192.168.137.202 80358 {   weight 1   misc_check {      misc_path "/usr/local/bin/script.sh"   }}

Use the specified script script.sh to perform a health check.

Preliminary study on Keepalived