Keepalived implements Nginx load balancing and high availability sample code

Chapter 1: Introduction to keepalived

The purpose of VRRP protocol is to solve the single point failure problem of static routing.

Chapter 2: How keepalived works

2.1 High availability function (failover) as a system network service

The basic principle of keepalived high availability function is:
Install the keepalived software on both hosts and start the service. When the two hosts start working normally, the host with the role of Master obtains all resources and provides services to users. The host with the role of Backup serves as a hot standby for the Master host.

When the host with the Master role fails or malfunctions, the host with the Backup role will automatically take over all the work of the Master host, including taking over VIP resources and corresponding resource services.

When the failure of the host with the role of Master is repaired, it will automatically take over the work it originally handled. The host with the role of Backup will also release the work it took over when the Master host failed. At this time, the two hosts will return to their original roles and working states at the time of startup.

2.2 What is VRRP
VRRP, full name Virtual Router Redundancy Protocol, Chinese name is Virtual Router Redundancy Protocol
VRRP was created to solve the single point failure problem of static routing.
VRRP assigns routing tasks to a VRRP router through a campaign mechanism.

VRRP implements the function of virtual router through election mechanism. All protocol messages are sent in the form of IP multicast packets (default multicast address 224.0.0.18).
A virtual router consists of a VRID (range 0-255) and a set of IP addresses, which appear externally as a well-known MAC address: 00-00-5E-00-01-{VRID}.
Therefore, in a virtual router, no matter who is the Master, the same MAC and IP (called VIP) are used externally.
Client hosts do not need to modify their routing configurations due to changes in the Master. For them, this switch is transparent.

In a group of virtual routers, only the VRRP router that is the Master will always send VRRP broadcast packets. At this time, the Backup will not preempt the Master.
When the Master is unavailable, the Backup will not receive broadcast packets from the Master. At this time, the router with the highest priority among the multiple Backups will take over as the Master.
This preemption is very fast (maybe only 1 second or even less) to ensure service continuity. For security reasons, VRRP data packets are encrypted using encryption protocols.

2.3 What to say during an interview <br /> Answer:
Keepalived high-availability pairs communicate via VRRP, so I'll start with VRRP.
1) VRRP, the full name of which is Virtual Router Reduancy Protocol, is designed to solve the single point failure of static routing.
2) VRRP uses a campaign protocol to assign routing tasks to a VRRP router.
3) VRRP uses IP multicast (default multicast address (224.0.0.18)) to achieve communication between high-availability pairs.
4) When working, the master node sends packets and the standby node receives them. When the standby node cannot receive the packets sent by the master node, it starts the takeover program to take over the resources of the master node. There can be multiple standby nodes, which are elected through priority, but generally there is a pair in the operation and maintenance of the keepalived system.
5) VRRP uses encryption protocols to encrypt data, but keepalived officials currently recommend using plain text to configure authentication types and passwords.
After introducing VRRP, let me introduce the working principle of keepalived service;
Keepalived high-availability pairs communicate with each other through VRRP. VRRP determines the master and the standby through an election mechanism. The master has a higher priority than the standby. Therefore, it will get all resources first when working. The standby node is in a waiting state. When the master node hangs up, the standby node will take over the resources of the master node and then replace the master node to provide external services.
Between the keepalived service pairs, only the master server will keep sending VRRP broadcast packets to tell the backup server that it is still alive. At this time, the backup server will not preempt the master server. When the master server is unavailable, that is, when the backup server cannot monitor the broadcast packets sent by the master server, it will start related services to take over resources to ensure business continuity. The takeover speed can be as fast as less than one second.

Chapter 3: VRRP Protocol
VRRP implements the function of virtual router through election mechanism. All protocol messages are transmitted through IP multicast packets. The default multicast address is 224.0.0.18

VIP Prerequisites:
1. The virtual public IP must be real and available
2. Virtual public IP cannot be repeated
3. The multicast address must be communicable

Chapter 4: keepalived installation and configuration

1. Install keepalived

yum install keepalived -y

2. Configuration file explanation

global_defs {  
  router_id lb01 #Set the routing ID, each host is different} 

vrrp_instance VI_1 { #Set VRRP group name, the same group name state MASTER #Set role status, divided into MASTER BACKUP
    interface eth0 #Network card bound to VIP virtual_router_id 50 #Virtual router id, same for the same group priority 150 #Weight, the higher the weight, the higher the priority advert_int 1 #Interval for sending multicast authentication { #Set authentication, the password is in plain text auth_type PASS 
      auth_pass 1111 
    }
    virtual_ipaddress { #Set the virtual IP. This virtual IP must exist, be valid and not be in use.
      10.0.0.3
    }
}

3.lb01 configuration

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb01
}

vrrp_instance VI_1 {
  state MASTER
    interface eth0
    virtual_router_id 50
    priority 150
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }
}

4.lb02 configuration

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb02
}

vrrp_instance VI_1 {
  state BACKUP 
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }
}

5. Startup

systemctl start keepalived

6. Test by shutting down any machine and observing whether the VIP will drift back to the master and whether the BACKUP VIP will disappear.

Chapter 5: Split-brain phenomenon

1. Install the packet capture tool

yum install tcpdump -y 

2.lb02 packet capture and viewing

tcpdump -nn -i any host 224.0.0.18

3. lb02 Open a new terminal and turn on the firewall

systemctl start firewalld.service

4.lb02 observes the packet capture phenomenon to see if there are VIPs on both sides

5. Add release rules

firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface eth0 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --in-interface eth1 --destination 224.0.0.18 --protocol vrrp -j ACCEPT
systemctl reload firewalld

6.lb02 Observe the packet capture phenomenon to see if there are VIPs on both sides

Chapter 6: keepalived dual-master experiment
1.lb01 configuration file

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb01
}

vrrp_instance VI_1 {
  state MASTER
    interface eth0
    virtual_router_id 50
    priority 150
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }
}

vrrp_instance VI_2 {
  state BACKUP 
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 2222 
    }
    virtual_ipaddress {
      10.0.0.4
    }
}

2.lb02 configuration file

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb02
}

vrrp_instance VI_1 {
  state BACKUP 
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }
}

vrrp_instance VI_2 {
  state MASTER 
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 2222 
    }
    virtual_ipaddress {
      10.0.0.4
    }
}

3. Restart keepalived and observe the phenomenon

systemctl restart keepalived

Chapter 7: keepalived combined with nginx reverse proxy load balancing
Nginx configuration for lb server:
Notice! The Nginx configuration of the two lb servers is exactly the same

1. Back up the original configuration

mkdir /backup
cd /etc/nginx/conf.d
mv * /backup 

2. Write the Nginx configuration file

[root@lb01 /etc/nginx/conf.d]# cat proxy.conf 
upstream web_pools {
  server 172.16.1.7;
  server 172.16.1.8;
}

server {
  listen 80;
  server_name (www|bbs).mysun.com;
  location / {
   proxy_pass http://web_pools;
   include proxy_params;
  }
}

3. Test and restart nginx

nginx -t
systemctl restart nginx 

Keepalived configuration of lb server:

1.lb01 keepalived configuration

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb01
}

vrrp_instance VI_1 {
  state MASTER
    interface eth0
    virtual_router_id 50
    priority 150
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }
}

2.lb02 keepalived configuration

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb02
}

vrrp_instance VI_1 {
  state BACKUP 
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }
}

Web server configuration:

Notice! The two web servers have the same configuration

1. nginx configuration

[root@web01 ~]# cat /etc/nginx/conf.d/www.conf 
server {
 listen 80;
 server_name www.mysun.com;
 location / {
   root /code;
   index www.html;
 }
}

2. Write test files

echo "$(hostname)" >/code/index.html 

Chapter 8: Split-brain Prevention Script

1. Problem phenomenon:
1.nginx is down, but keep is still alive
2. Both sides have VIP

2. Ideas:
Solve the nginx hang problem:
1. Write a script

• Start nginx
• If the startup fails twice, stop your keepalived

2.keepalived calls this script regularly

3. Implementation:

1. How to implement the command

systemctl start nginx

2. Check the nginx process

[root@lb01 ~]# ps -ef|grep nginx|grep -v "grep"
root 1210 1 0 11:21 ? 00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 1211 1210 0 11:21 ? 00:00:00 nginx: worker process
[root@lb01 ~]# ps -ef|grep nginx|grep -v "grep"|wc -l
2
[root@lb01 ~]# ps -ef|grep nginx|grep -v "grep"|wc -l
0

Script content:

[root@lb01 ~]# cat check_web.sh 
!/bin/bash

nginx_status=$(ps -C nginx --no-header|wc -l)

if [[ ${nginx_status} == 0 ]]
then
  systemctl start nginx &> /dev/null 
  sleep 1
  nginx_status=$(ps -C nginx --no-header|wc -l)
  if [[ ${nginx_status} == 0 ]]
  then
    systemctl stop keepalived 
  fi
fi

Keepalived calls the script:

[root@lb01 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb01
}

vrrp_script check_web {
  script "/server/scripts/check_web.sh"
  interval 5
  weight 50
}

vrrp_instance VI_1 {
  state MASTER
    interface eth0
    virtual_router_id 50
    priority 150
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }

  track_script {
    check_web
  }

}

4. The second problem: Split-brain problem <br /> Both sides have VIPs

Phenomenon:
VIP on both sides
Nginx on both sides is alive

The Nginx of the opposite MASTER is still alive

curl -I -s -w "%{http_code}\n" -o /dev/null 10.0.0.5

But I have VIP again

ip a |grep "10.0.0.3"|wc -l

I'll kill myself

systemctl stop nginx 
systemctl stop keepalived 

Script content:

[root@lb02 /server/scripts]# cat check_vip.sh 

#!/bin/bash

master_status=$(curl -I -s -w "%{http_code}\n" -o /dev/null 10.0.0.5)

my_vip=$(ip a |grep "10.0.0.3"|wc -l)

if [ ${master_status} == 200 -a ${my_vip} == 1 ]
then
  systemctl stop nginx 
  systemctl stop keepalived 
fi

keepalived configuration:

[root@lb02 ~]# cat /etc/keepalived/keepalived.conf 
global_defs {
  router_id lb02
}

vrrp_script check_web {
  script "/server/scripts/check_web.sh"
  interval 5
  weight 50
}

vrrp_script check_vip {
  script "/server/scripts/check_vip.sh"
  interval 5
  weight 50
}

vrrp_instance VI_1 {
  state BACKUP 
    interface eth0
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication
      auth_type PASS
      auth_pass 1111
    }
    virtual_ipaddress {
      10.0.0.3
    }
  track_script {
    check_web
    check_vip
  }
}

This is the end of this article about the sample code for implementing Nginx load balancing and high availability with Keepalived. For more related Keepalived Nginx load balancing and high availability content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!