Nginx beginner's tutorial for the backend: configuring a high-availability cluster

Nginx beginner's tutorial for the backend: configuring a high-availability cluster

In the last Nginx entry tutorial for the backend: actual combat article, we started from the actual code and explained the structure of the Nginx configuration file, as well as the commonly used functions such as complex balance, reverse proxy, dynamic and static separation. Simple configuration, does the matter end here? Of course not. Take load balancing as an example. Remember the picture given by our basics about reverse proxy? We will make a small modification and turn it into our load balancing diagram, as shown in the following figure:

At first glance, I didn t find any problems. The request passes through our load balancing server and is distributed to different servers for processing through different strategies. Even if one server goes down, other servers will continue to be on top. , This logic is simply perfect score, my mother no longer has to worry about the huge request to collapse my server.

Wait, the seemingly calm lake surface is often choppy . Knowledge points, friends, interviews may be required.

But, in case, our load balancing server goes down, isn't it GG completely?

Damn it, fuck it, fuck it, why didn't I think of it, what should I do?

Don t panic, there are good strategies at the top and countermeasures at the bottom. Soldiers come to block, and water comes to cover. In order to prevent this kind of choking from happening, someone has provided another way of thinking. Is there only one load balancing server? I can t afford to hang it up. I can get two load balancing servers. One hangs up and I continue to use the other one. Hahahahahahahahahahahahahahahaha , Brother Smelly, don t recruit, so the picture above becomes like this:

When we initiate a request to the server, the address used is not the IP address of the two Nginx servers we configured, but the virtual IP address we set, and the addresses of the two Nginx servers are called our working IP. When, for example, 5 requests (look like I haven't seen a big scene) came to our main Nginx server, our main Nginx server saw so many requests at a glance, so.

Ah, so many requests, I'm dead.

Then, because the two Nginx servers are set to this virtual IP, when the main Nginx server hangs, when we visit again, it is actually access to our slave Nginx server to do specific load balancing, and provide specific services. The IP address has also been switched from the IP of the main Nginx server to the IP of the Nginx server . The entire IP switching process is imperceptible to the user, which is actually a bit similar to the master-slave database we often say.

Then the whole process of working IP address change, the industry gave a special cool name, called IP drift .

Of course, this virtual IP is not configured in a word. It also needs the support of third-party software. Here we use the keepalived software to ensure that our nginx achieves high-availability cluster configuration.

What is keepalived?

Keepalived is a service software that guarantees the high availability of the cluster in cluster management. Its function is similar to heartbeat and is mainly used to prevent single points of failure.

You are not taking off your pants xx, do you want to do it again? Yes, the Nginx server is all right if it hangs, but what if you keepalived hangs?

Hey, I have long thought that someone might ask this question. First of all, our keepalived is simply a load balancing function. The real request is still handed over to Nginx. Therefore, the probability of keepalived hanging is much smaller than that of Nginx. The probability of hang, if it really hangs, then there is really no way.

Having said so much, how do you play specifically? Okay, then, let's not talk nonsense, just look at things.

Detailed explanation of keepalived installation and configuration files:

keepalived installation:

Since we are talking about the configuration of nginx high-availability clusters, first of all, we have to have many prerequisites, cluster clusters, you can't do it with only one linux server, of course you are not required to prepare dozens of servers, two Well, after all, the cost is high. Of course, this server is not a problem for a Rolex man like Zhu once. Secondly, the most basic thing is that Nginx must be installed on our two servers. For details on how to install Nginx, you can go to see. My previous actual combat article, so in order to achieve Nginx's high-availability cluster configuration, we need to prepare:

  • There are two servers, here is a local virtual machine, the IP is and respectively
  • Both of our servers need to install nginx and keepalived

The process is a little bit, to lie to you. According to our previous habits, here is only the simplest installation method. Open the command line terminals of our two virtual machines and enter the yum command to install:

yum install keepalived  y

Detailed explanation of keepalived configuration file:

After the installation is complete, that is to say, the configuration, where is our keepalived configuration file? Generally speaking, under the file etc/keepalived/keepalived.conf, we open this file. Because there is too much content, I will not list them all here, but so many configurations are not all that we need to configure. , On the contrary, we simply need to configure the master-slave Nginx server only a small part of it, so we streamline the keepalived.conf file, the content after streamlining is as follows, you can directly replace this part of the content Original configuration file:

! Configuration File for keepalived

global_defs {
    notification_email {
    ###   sendmail 
    #keepalived email   
    notification_email_from Alexandre.Cassen@firewall.loc
    # email smtp   
    # smtp server  
    smtp_connect_timeout 30
    ##  router_id  
    router_id Master_Nginx 

vrrp_script chk_http_port {
    script "/usr/local/src/" ## 
    interval 2 # 
    weight 2 ## 

vrrp_instance VI_1 {

    # keepalived MASTER BACKUP state         instance(Initial)   
    # MASTER           
    # MASTER   
    state MASTER  #   MASTER   BACKUP 
    interface eth0 ### HA  IP  ip addr  
    virtual_router_id 51 # vrrp vrrp_instance MASTER BACKUP   
    priority 100 #  100   80
    advert_int 1 # MASTER BACKUP      
	authentication { # 
        auth_type PASS   # vrrp PASS AH   
        auth_pass 123456 # vrrp vrrp_instance MASTER BACKUP   

virtual_ipaddress { ## VRRP H  


In our example, the configuration file is divided into three main parts, namely global_defs , vrrp_script chk_http_port and

vrrp_instance VI_1 , let s illustrate their specific roles one by one below:

global_defs block:

Global configuration, email notification and other configurations are all completed here. The more important thing is the router_id option, which is used to identify our host.

How did Master_Nginx in this example come from? In my host file: Master_Nginx

Of course, I took Master_Nginx by myself, and you can also name your host according to your own habits.

vrrp_script chk_http_port block:

See script, isn t it the meaning of script? Yes, this one is mainly about our keepalived script configuration. Didn t I say that before, I have to have a way to know that your Nginx server is down, so I can go Switch to a backup server, this script does this. For the specific meaning of each line, see the notes:

vrrp_script chk_http_port {
    script "/usr/local/src/" ## 
    interval 2 # 
    weight 2 ## Nginx 2

The contents of will be posted at the end of the configuration file.

vrrp_instance VI_1 block:

The third block is more important. This is mainly used for the configuration of our virtual IP. For the specific explanation, I have put it in the code comments above. What is the only additional point that needs to be added, virtual_ipaddress, our virtual IP address There can be more than one. For example, how do I write two virtual IPs? Just change the line:

virtual_ipaddress { ## VRRP H 


Create our script under the/usr/local/src/path.

The content of the script roughly means that when we find that our current nginx server is down, we stop keepalived by the way, because our two nginx servers are installed with keepalived at the same time, and one is down, so naturally we switch to the other A backup server is on, and this is the same reason that the ancient emperor died, and the heavy responsibility naturally fell on the prince.

A=`ps -C nginx  no-header |wc -l`
if [ $A -eq 0 ];then
    sleep 2
    if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
        killall keepalived

After you finish, remember that the path of this script should be the same as the script value in the configuration file. Don't come back and write it. Keepalived can't find it.

Speaking of this, I have finished the relatively simple part of the keepalived configuration file. Don t say that after reading my tutorial, you think you have learned all the essence. In fact, it is not. This is only a part. More detailed configuration needs you to follow. Learn and understand in the future use process.

The actual configuration of high-availability clusters:

In fact, in the process of explaining the configuration file above, we have unknowingly configured the keepalived of our main Nginx server to quiet Mimi, right, the simple configuration is actually not that complicated, the following is to configure our backup Nginx server now. In general, the steps are still the same.

It is still to replace our configuration file, but the main thing you need is that the configuration files of the backup Nginx server and the main Nginx server still need to be changed a little bit. In this example, we mainly need to change the state from MASTER to BACKUP, priority The priority is changed from 100 to 90, and the content after the change is as follows:

vrrp_instance VI_1 {
    state BACKUP   #   MASTER   BACKUP 
    interface eth0 ## ipconfig 
    virtual_router_id 51 #   virtual_router_id  
    priority 90 #  100   80
    advert_int 1 ## Nginx 
	authentication { ## 
        auth_type PASS
        auth_pass 123456

virtual_ipaddress { ## VRRP H  


The content of the script does not need to be modified, just upload it directly to the specified directory.

Note that during the configuration process, the virtual IP address between the primary server and the standby server, that is, virtual_ipaddress, must be the same.


# nginx

# keepalived  
#centos 7 
systemctl start keepalived.service
#centos 6+
service keepalived start

Enter in the browser address, and you can see the familiar Nginx welcome interface.

In order to verify that keepalived really plays a role in it, we manually turn off the keepalived and nginx services of the main Nginx server, and then visit

So we found that it can still be accessed normally, and the familiar Nginx interface appeared in our eyes again, which shows that our backup Nginx server is already in use.

You're done here.

Let's start the technical summary:

In this article, we have simply implemented the configuration of a highly available cluster of Nginx services by using keepalived. Although the configuration is very simple, for beginners, I think it is possible to realize the highly available operation of their own projects through keepalive and Nginx. But this does not mean that this is all, keepalived supports dual-active mode at the same time . Due to the length of this article, I won t add it here, but if you have mastered the configuration of active-standby mode, I think it s easy to configure dual-active mode. What I learned, finally, thank you for reading this article. It is a very happy thing for me to be able to help you. If you have any questions or criticisms, please leave a message at the bottom of this article. You have time If you do, I will reply one by one.

Han Shu's study notes are currently all open sourced to github, you must order a star ah ah ah ah ah

Thousands of rivers and mountains are always in love, can you give a star?

Hanshu's development notes

Welcome to like, follow me, have you good fruit (funny)