Cluster introduction, keepalived introduction, use keepalived configuration high-availability cluster

Group introduction


Divided into two categories according to functions: high availability and load balancing.  

High availability clusters usually consist of two servers, one for work and the other for redundancy. When the service-providing machine goes down, the redundancy will take over and continue to provide services to  

achieve high The open source software available are: heartbeat and keepalived  

load balancing clusters, which require a server as a distributor, which is responsible for distributing user requests to the back-end server for processing. In this cluster, in addition to the distributor, it provides services to users. Servers, the number of these servers is at least 2.  

Open source software for load balancing includes LVS, keepalived, haproxy, nginx, and commercial ones include F5 and Netscaler


Keepalive introduction (HA cluster) 

HA is high-availability, also known as dual-machine hot standby. It is used for critical services. The simple understanding is that there are two machines A and B. Normally, A provides services, B is on standby and idle, and when A is down Or the service is down, it will switch to the B machine to continue to provide the service. 

Here we use keepalived to achieve high availability clusters, because heartbeat has some problems on centos6, which affect the experimental effect.   

Keepalived uses VRRP (Virtual Router Redundancy Protocl) to achieve high availability. 

In this protocol, multiple routers with the same function will be formed into a group. There will be 1 master role and N (N>=1) backup roles in this group. 

The master will send VRRP protocol data packets to each backup in the form of multicast. When the backup fails to receive the VRRP data packets sent by the master, it will think that the master is down. At this time, it is necessary to decide who becomes the new mater according to the priority of each backup. 

Keepalived has three modules, core, check and vrrp. The core module is the core of keepalived, responsible for the startup and maintenance of the main process, and the loading and analysis of global configuration files. The check module is responsible for health checks, and the vrrp module is to implement the VRRP protocol.



Configure a high-availability cluster with keepalived
There needs to be a service under keepalived to achieve high availability, and nginx is used to replace the service.
Prepare two machines 130 and 132, 130 as master and 132 as backup. Both machines execute yum install -y keepalived. Both machines have nginx installed, and nginx has been compiled and installed on 130, and yum is required to install nginx on 132: yum install -y nginx


Set vip to 100
keepalived on 130 #vim /etc/keepalived/keepalived.conf edit the configuration file, content acquisition from https://coding.net/u/aminglinux/p/aminglinux-book/git/blob/master/D21Z/master_keepalived.conf  
first Clear the contents of the original configuration file, use the shortcut key >!$, and then put the copied file under #/etc/keepalived/keepalived.conf


global_defs {                  
notification_email {//You don’t need to define [email protected] 
} 
notification_email_from [email protected] 
smtp_server 127.0.0.1 
smtp_connect_timeout 30router_id LVS_DEVEL 
} 
vrrp_script chk_nginx {//Check whether the service is normal script "/usr/ng.sbin/check "// definition script path. 3} interval the 
vrrp_instance VI_1 { 
State MASTERinterface ens33virtual_router_id // master 51 is consistent from id priority 100 // {1authentication weight advert_int 
AUTH_TYPE the PASS 
AUTH_PASS aminglinux> COM 
} 
virtual_ipaddress 192.168.37.100 { 
} 
track_script { 
chk_nginx 
} 
}
#vim /usr/local/sbin/check_ng.sh130 Edit the monitoring script, the content is obtained from https://coding.net/u/aminglinux/p/aminglinux-book/git/blob/master/D21Z/master_check_ng.sh
#!/bin/bash#Time variable, used to record logs d=`date --date today +%Y%m%d_%H:%M:%S`#Calculate the number of nginx processes n=`ps -C nginx --no-heading|wc -l`#If the process is 0, start nginx and check the number of nginx processes again. #If it is still 0, it means that nginx cannot be started, and keepalivedif needs to be closed at this time [$n -eq "0 "]; then/etc/init.d/nginx start 
n2=`ps -C nginx --no-heading|wc -l`if [$n2 -eq "0" ]; thenecho "$d nginx down,keepalived will stop" >> /var/log/check_ng.log 
systemctl stop keepalivedfifi
#chmod 755 /usr/local/sbin/check_ng.sh //Give script 755 permission
#systemctl start keepalived //Start keepalived service on master
#Vim /etc/keepalived/keepalived.conf Edit the configuration file on 132, the content is obtained from https://coding.net/u/aminglinux/p/aminglinux-book/git/blob/master/D21Z/backup_keepalived.conf
global_defs {
notification_email {
[email protected]
}
notification_email_from [email protected]
smtp_server 127.0.0.1
smtp_connect_timeout 30router_id LVS_DEVEL
}
vrrp_script chk_nginx {
script "/usr/local/sbin/check_ng.sh"interval 3}
vrrp_instance VI_1 {
state BACKUPinterface ens33virtual_router_id 51priority 90             //权重advert_int 1authentication {
auth_type PASS
auth_pass aminglinux>com
}
virtual_ipaddress {192.168.37.100
}
track_script {
chk_nginx
}
}
Edit the monitoring script on 132, the content is obtained from https://coding.net/u/aminglinux/p/aminglinux-book/git/blob/master/D21Z/backup_check_ng.sh
#Time variable, used to record logs d=`date --date today +%Y%m%d_%H:%M:%S`#Calculate the number of nginx processes n=`ps -C nginx --no-heading| wc -l`#If the process is 0, start nginx and check the number of nginx processes again. #If it is still 0, it means that nginx cannot be started, and keepalivedif needs to be closed at this time. [$n -eq "0" ]; thensystemctl start nginx 
n2=`ps -C nginx --no-heading|wc -l`if [$n2 -eq "0" ]; thenecho "$d nginx down,keepalived will stop" >> /var/log/check_ng.log 
systemctl stop keepalivedfifi
#chmod 755 /usr/local/sbin/check_ng.sh //Give script 755 permission
Start the service on 132 #systemctl start keepalived
Before the simulation, you must turn off the firewall and selinux, 
simulate the downtime in the production environment, and test the high availability: the 
best way is to turn off the keepalived service on the master to test the high availability

Guess you like

Origin blog.csdn.net/boy_hxm/article/details/79385295