Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you about how to use Keepalived to achieve high availability of the site in Nginx. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

1. Keepalived introduction

Keepalived is a highly available service solution based on VRRP protocol, which can be used to avoid a single point of failure of IP. Similar tools include heartbeat, corosync and pacemaker. However, it generally does not appear alone, but works with other load balancing technologies (such as lvs, haproxy, nginx) to achieve high availability of the cluster.

1.1 VRRP protocol

The full name of VRRP is Virtual Router Redundancy Protocol, that is, virtual routing redundancy protocol. It can be thought of as a fault-tolerant protocol to achieve high availability of routers, that is, N routers with the same function form a router group (Router Group), which contains a master and multiple backup, but looks like a virtual router with a virtual IP (vip, that is, the default route of other machines in the local area network where the router is located). The master that owns this IP is actually responsible for ARP corresponding and forwarding IP packets, while other routers in the group stand by as backups. Master will send a multicast message, and when backup fails to receive vrrp packets within the timeout period, it will think that master has been dropped, so it is necessary to choose a backup as master according to the priority of VRRP to ensure the high availability of the router.

In the implementation of the VRRP protocol, the virtual router uses 00-00-5E-00-01-XX as the virtual MAC address, and XX is the only VRID (Virtual Router IDentifier), which is occupied by only one physical router at a time. Advertisement messages are regularly sent in the physical router group within the virtual router through the multicast IP address 224.0.0.18. Each Router has a priority between 1 and 255, and the highest level (highest priority) will become the master router. By reducing the priority of the master, the router in the backup state can preempt (pro-empt) the state of the master router. The higher address of the two IP addresses with the same backup priority is master, which takes over the virtual IP.

Compared with heartbeat/corosync et al.

Excerpt directly from http://www.linuxidc.com/Linux/2013-08/89227.htm:

Which of the three cluster components do we choose, Heartbeat, Corosync or Keepalived? first of all, I would like to make it clear that Heartbeat and Corosync belong to the same type, and Keepalived is not the same type as Heartbeat and Corosync at all. The vrrp protocol used by Keepalived, Virtual routing redundancy Protocol (Virtual Router Redundancy Protocol, referred to as VRRP); Heartbeat or Corosync is a highly available way based on host or network services; to put it simply, the purpose of Keepalived is to simulate the high availability of routers, and the purpose of Heartbeat or Corosync is to achieve the high availability of Service.

Therefore, the general Keepalived is to achieve the front-end high availability, the commonly used front-end high-availability combinations are our common LVS+Keepalived, Nginx+Keepalived, HAproxy+Keepalived. While Heartbeat or Corosync is the high availability of implementing services, the common combinations are Heartbeat v3 (Corosync) + Pacemaker+NFS+Httpd to realize the high availability of Web server and Heartbeat v3 (Corosync) + Pacemaker+NFS+MySQL to realize the high availability of MySQL server. To sum up, lightweight high availability is implemented in Keepalived, which is generally used for front-end high availability and does not require shared storage, but 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. We have made this question clear.

Another blog friend asked, which should we choose between heartbaet and corosync? I would like to say that we generally use corosync, because the operating mechanism of corosync is better than heartbeat, and even the pacemaker separated from heartbeat says that it is more inclined to corosync in future development, so now corosync+pacemaker is the best combination.

1.2 Keepalived + nginx

Keepalived can be regarded as the implementation of VRRP protocol on Linux. There are three main modules, namely, core, check and vrrp. Core module is the core of keepalived, which is responsible for the startup and maintenance of the main process as well as the loading and parsing of global configuration files. Check is responsible for health check-ups, including common check-ups. The vrrp module is used to implement the VRRP protocol. This article is based on the following topology diagram:

+-+ | uplink | +-+ | + MASTER keep | alived BACKUP172.29.88.224 172.29.88.222 172.29.88.225 -+ +-+ +-+ | nginx01 |-| virtualIP |-| nginx02 | +-+ | | +-+-+ | +-+ | web01 | | web02 | | | web03 | +-+ 2. Keepalived to achieve nginx high availability 2.1 installation

My environment is CentOS 6.2 X86x64, and it is easiest to install directly through yum:

# yum install-y keepalived# keepalived-vKeepalived v1.2.13 (03Universe 19heli2015) 2.2 nginx monitoring script

This script detects the running status of ngnix and attempts to restart ngnix when the nginx process does not exist, and stops keepalived if it fails, ready for another machine to take over.

/ etc/keepalived/check_nginx.sh:

#! / bin/bashcounter=$ (ps-C nginx-- no-heading | wc-l) if ["${counter}" = "0"]; then / usr/local/bin/nginx sleep 2 counter=$ (ps-C nginx-- no-heading | wc-l) if ["${counter}" = "0"]; then / etc/init.d/keepalived stop fifi

You can also summarize when to turn off keepalived according to your business needs. For example, if the curl home page fails to respond for 2 consecutive 5s, you can switch:

#! / bin/bash# curl-IL http://localhost/member/login.htm# curl-- data "memberName=fengkan&password=22" http://localhost/member/login.htmcount = 0for ((kryp0; k state BACKUP,priority 101-> priority 100 mcastcastings IP 172.29.88.224-> mcast_src_ip 172.29.88.225)

Description of service keepalived restart2.4 configuration options

Global_defs

Notification_email: keepalived needs to send an email notification address when a switching operation occurs, and it is also known to be a mail server address compared to the following smtp_server. You can also call the police in other ways. After all, e-mail is not notified in real time.

Router_id: machine ID, which can usually be set to hostname. When a failure occurs, email notifications will be used

Vrrp_instance

State: specify the initial state of instance (Initial), that is, after configuration, the initial state of the server is specified here, but what is specified here does not count, it still has to be determined by campaign priority. If this is set to MASTER, but if his priority is lower than the other one, then this one will send its own priority when sending a notification, and the other one will find that the priority is not as high as his own, then he will preempt it as MASTER

Interface: the network card bound to the instance, because it must be added to the existing network card when configuring the virtual IP

Mcast_src_ip: the source IP address when sending multicast packets. Note here that this is actually the address where VRRP advertisements are sent. This is very important. Be sure to choose a stable network card port to send. This is equivalent to the heartbeat port of heartbeat. If it is not set, then use the IP of the default bound network card, that is, the IP address specified by interface.

Virtual_router_id: set VRID here, it's very important here, the same VRID is a group, it will decide the MAC address of multicast.

Priority: set the priority of this node. The highest priority is master.

Advert_int: check interval. Default is 1 second. This is the timer of VRRP. At such intervals, MASTER sends an advertisement message to notify other routers in the group that they are working properly.

Authentication: define authentication method and password. Master and slave must be the same.

Virtual_ipaddress: what is set here is VIP, that is, the virtual IP address. It is added and deleted with the change of state, added when state is master, and deleted when state is backup. Here, it is mainly determined by priority, which has little to do with the value set by state. Here, you can set multiple IP addresses.

Track_script: reference the VRRP script, which is the name specified in the vrrp_script section. Run them periodically to change the priority and eventually trigger the active / standby switch.

Vrrp_script

It is particularly important to tell keepalived under what circumstances to switch. Can have multiple vrrp_script

Script: write your own test script. It can also be an one-line command such as killall-0 nginx

Interval 2: check every 2s

Weight-5: if the detection fails (the script returns a non-0), the priority is-5

Fall 2: the test fails twice in a row to determine whether it is a true failure. Weight will be used to reduce priorities (between 1 and 255)

Rise 1: a successful test is considered a success. But the priority is not modified.

Here is a hint that there are two general ways to write script:

Through the return result of the script execution, change the priority, keepalived continues to send notification messages, and backup compares the priority before deciding.

If an exception is detected in the script, close the keepalived process directly. If the backup machine does not receive the advertisement, it will preempt the IP.

In the vrrp_script configuration section above, killall-0 nginx is in the first case and / etc/keepalived/check_nginx.sh is in the second case (turn off keepalived in the script). Individuals prefer to judge by shell script, but if there is an exception, exit 1 will exit exit 0 normally, and then keepalived will decide whether to preempt VIP according to the dynamically adjusted vrrp_instance priority:

If the script execution result is 0 and the value of the weight configuration is greater than 0, the priority increases accordingly

If the execution result of the script is not 0 and the value of the weight configuration is less than 0, the priority is reduced accordingly.

Otherwise, the priority of the original configuration remains the same, that is, the value corresponding to priority in the configuration file.

Tip:

The priority will not be raised or lowered continuously.

You can write multiple test scripts and set a different weight for each test script (just list it in the configuration)

Regardless of whether the priority is raised or lowered, the range of the final priority is in [1254], and there will be no cases where the priority is less than or equal to 0 or the priority is greater than or equal to 255.

Configure nopreempt in the vrrp_instance of the MASTER node. When it recovers abnormally, it will not preempt even if its prio is higher. This can avoid unnecessary switching under normal circumstances.

The above can be achieved by using scripts to detect the status of business processes and dynamically adjust priorities to achieve active / standby switching.

End of configuration

There is a configuration like virtual_server,real_server in the default keepalive.conf. We don't need it here. It's for lvs. Notify can define scripts to be executed when switching to MASTER or BACKUP. If necessary, please google yourself.

Notify

2.5 nginx configuration

Of course, nginx has nothing to configure because it is not associated with keepalived. But remember, the configuration on the two nginx servers should be exactly the same (rsync synchronization), so that it can be transparent to users. The server_name in nginx.conf is replaced by a domain name as far as possible, and then dns resolves the domain name to the virtual IP 172.29.88.222.

For more information about nginx content configuration, please refer to here.

3. test

According to the above configuration, the initialization status is 172.29.88.224 (itoatest1,MASTER,101), 172.29.88.222 (itoatest2,BACKUP,100), both nginx and keepalived are started, and the virtual IP 172.29.88.222 is on itoatest1:

# ifconfig cannot view [root@itoatest1 nginx-1.6] # ip a using the ip command | grep eth02: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 172.29.88.224 scope global eth0 inet 24 brd 172.29.88.255 scope global eth0 inet 172.29.88.222 scope global eth0

The browser visits 172.29.88.222 or the domain name, OK.

Directly close the nginx:/usr/local/nginx-1.6/sbin/nginx-s stop on itoatest1:

[root@localhost keepalived] # ip a | grep eth02: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 172.29.88.224 brd 24 brd 172.29.88.255 scope global eth0

Vip disappears and drifts to itoatest2:

Cdn.segmentfault.com/v-5d2ffc9a/global/img/squares.svg ">

You can see / var/log/messages on both servers at the same time:

# # itoatest1Jun 5 16:44:01 itoatest1 Keepalived_vrrp [44875]: VRRP_Instance (VI_1) Sending gratuitous ARPs on eth0 for 172.29.88.222Jun 5 16:44:06 itoatest1 Keepalived_vrrp [44875]: VRRP_Instance (VI_1) Sending gratuitous ARPs on eth0 for 172.29.88.222Jun 5 16:44:46 itoatest1 Keepalived_vrrp [44875]: VRRP_Script (chk_nginx) failedJun 5 16:44:48 itoatest1 Keepalived_vrrp [44875]: VRRP_Instance (VI_1) Received higher Prio advertJun 5 16:44:48 itoatest1 Keepalived_vrrp [44875]: VRRP_Instance (VI_1) Entering BACKUP STATEJun 5 16:44:48 itoatest1 Keepalived_vrrp [44875]: VRRP_Instance (VI_1) removing protocol VIPs.Jun 5 16:44:48 itoatest1 Keepalived_healthcheckers [44874]: Netlink reflector reports IP 172.29.88.222 removed## itoatest2Jun 5 16:44:00 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) Transition to MASTER STATEJun 5 16:44:00 itoatest2 Keepalived_vrrp [ 35555]: VRRP_Instance (VI_1) Received higher prio advertJun 5 16:44:00 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) Entering BACKUP STATEJun 5 16:44:48 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) forcing a new MASTER electionJun 5 16:44:48 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) forcing a new MASTER electionJun 5 16:44:49 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) Transition to MASTER STATEJun 5 16:44:50 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) Entering MASTER STATEJun 5 16:44:50 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) setting protocol VIPs.Jun 5 16:44:50 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) Sending gratuitous ARPs on eth0 for 172.29.88.222Jun 5 16:44:50 itoatest2 Keepalived_healthcheckers [35554]: Netlink reflector reports IP 172.29.88.222 addedJun 5 16:44:55 itoatest2 Keepalived_vrrp [35555]: VRRP_Instance (VI_1) Sending gratuitous ARPs on eth0 for 172.29.88.222

You can also check the change in priority priority by grabbing packets on two servers:

# # output directly on # # itoatest1, or add-w itoatest-kl.cap to save the file using wireshark to view # tcpdump-vvv-n-I eth0 dst 224.0.18 and src 172.29.88.224 above is how to use Keepalived to achieve high availability of the site in the Nginx shared by the editor. If you happen to have similar doubts, please refer to the above analysis for understanding. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.