Raspberry Pi instances: 2 Pi R Article 2: Web Servers

In my previous article, I talked about how to build a high-availability system: Two Raspberry Pi deploy the GlusterFS cluster file system, and it becomes a fault-tolerant file server. In this article, we will build another Fault-Tolerant Service Based on this high-availability system: Build a simple Web server cluster.

Maybe you have not read my previous article, so here I will briefly review the previous article. I have two Raspberry Pi: Pi1 and Pi2. The IP address of Pi1 is 192.168.0.121, And the IP address of Pi2 is 192.168.0.122. I combined them into a GlusterFS cluster system and shared a storage volume named gv0. The gv0 is mounted on both Raspberry Pi and the mount point is/mnt/gluster1, so that the two Raspberry Pi can access the shared volume at the same time. Finally, I tested the fault tolerance of the system, mounted the shared volume to the third physical machine, and executed a simple script on the shared volume: print the system time and output it to a file on gv0, and turn off two Raspberry Pi in turn to check whether the redundant system is still usable.

Now I have this tested storage system. What I want to do is to make this system into a fault-tolerant Web server cluster. Raspberry Pi's CPU processing speed and memory resources are not very high. Fortunately, it is more than enough to deal with a static Web server. I deliberately made this example very simple, because I think if you can flat this simple example, you can also deal with complicated problems.

Install Nginx

Although I also like Apache, It is ideal for Web servers with full functionality, high performance, and low resource usage when resources are limited. Nginx exists in the default source of Raspbian, so I only need to log on to a Raspberry Pi and enter the following command:

1. $ Sudo apt-get update
2. $ Sudo apt-get install nginx

After Nginx is installed, create the configuration file/mnt/gluster1/cluster. The content is as follows:

1. Server {
2. Root/mnt/gluster1/www;
3. Index index.html index.htm;
4. Server_name twopir twopir.example.com;
5. Location /{
6. Try_files $ uri // index.html;
7. }
8. }

Note: I name the server "twopir" here. you can name your website based on your hobbies. In addition, I set the root directory of the Web server to/mng/gluster1/www. In this way, I can put my static files in this shared storage system so that both Raspberry Pi hosts can access them.

Delete the default Nginx configuration file and use the configuration file configured above as the Nginx configuration file. In the Debian system, Nginx stores its configuration files in the sites-available and site-enabled directories Like Apache. The VM configuration file is stored in sites-available, and the sites-enabled directory contains the soft link of the configuration file you want to take effect.

1. $ Cd/etc/nginx/sites-available
2. $ Sudo ln-s/mnt/gluster1/cluster.
3. $ Cd/etc/nginx/sites-enabled
4. $ Sudo rm default
5. $ Sudo ln-s/etc/nginx/sites-available/cluster.

Now I have placed the configuration file, but the system does not have the Web server root directory mentioned above. The next step is to create the directory/mnt/gluster1/www and copy the index.html file. You can also create your own index.html file, but copying an existing file is a good choice:

1. $ Sudo mkdir/mnt/gluster1/www
2. $ Cp/usr/share/nginx/www/index.html/mnt/gluster1/www

Restart the Nginx service:

1. $ Sudo/etc/init. d/nginx restart

Now go to the DNS server for the Raspberry Pi configuration record of 192.168.0.121. You can configure your own domain name and IP address as needed. Enter http: // twopir/in the browser and the default Nginx homepage is displayed. If you check the/var/log/nginx/access. log file, you can see the record left by clicking the web page.

After Nginx works properly, configure the second Raspberry Pi. Because we have put all the configuration files under the GlusterFS shared directory, all we need to do now is install Nginx, create related soft links, and restart Nginx:

1. $ Sudo apt-get update
2. $ Sudo apt-get install nginx
3. $ Cd/etc/nginx/sites-available
4. $ Sudo ln-s/mnt/gluster1/cluster.
5. $ Cd/etc/nginx/sites-enabled
6. $ Sudo rm default
7. $ Sudo ln-s/etc/nginx/sites-available/cluster.
8. $ Sudo/etc/init. d/nginx restart

Configure two A records on the DNS server

Now two hosts share the same file. The next step is to set up a redundant system. Although you can set a heartbeat-like service to check which Raspberry Pi Web service is enabled, here is a better method: specify the record of two DNS for the same host name, pointing to your two Raspberry Pi (Note: A record is the record that converts the domain name to an IP address, DNS contains many record methods, such as A record, PTR record, MX record, etc.), this is the legendary DNS load balancing, when the DNS accesses the host, if the host name corresponds to multiple IP addresses, DNS will randomly return the order of these IP addresses:

1. $ Dig twopir.example.com A + short
2. 192.168.0.121
3. 192.168.0.122
4. $ Dig twopir.example.com A + short
5. 192.168.0.122
6. 192.168.0.121

Because the random order is returned, users can send requests evenly to the two servers. The Server Load balancer mechanism is provided by multiple A records of the DNS server. Compared with the Server Load balancer Technology of DNS, I am more interested in how Web browsers handle request failures. When the browser obtains two A records from the web host, and the host where the first record is located becomes A machine, the browser almost immediately switches to another record. The switching efficiency is faster than that of the traditional heartbeat line-Robin Request Host.

So add two IP addresses of your Raspberry Pi cluster to the DNS server you are using, and then try the dig command, just as I used above, you should also be able to get two IP addresses.

When you set two A records for the same domain name, this cluster can provide Fault Tolerance services. Open two terminals and log on to two Raspberry Pi respectively. Run the tail-f/var/log/ngnix/access. log command to monitor access to the Web server. When you access the webpage through a browser, you can see that access logs are generated on one Raspberry Pi, and nothing appears in the other log. Now you can refresh the page several times. When you feel satisfied with the successful access to the Web server, you can restart the Raspberry Pi that responds to your request, then, refresh the page several times. Maybe there will be a short inaccessible signal in the browser, but it will be immediately redirected to the second Raspberry Pi, you will see the same page, in addition, you can learn the specific situation through terminal access logs. When the first Raspberry Pi is started, you won't notice it in your browser.

Different browsers have different approaches to how to handle multiple IP addresses in DNS round-robin, only the mozilla netlib Library supports automatic reconnection to the next IP address. If you know more about the browser's DNS round-robin policy, please comment on it. As a matter of fact, DNS polling cannot be regarded as a high-availability solution, rather it can be regarded as a load balancing solution. We recommend that you consider other more reliable solutions .)

Restart a Raspberry Pi randomly. As long as one server is online, the Web server can provide services. This is a very simple case. You can put your other static files on/mnt/gluster1/www to provide you with truly valuable services, enjoy your low-cost fault-tolerant cluster Web server.

Recommended reading:

Raspberry Pi build LAMP Server

Install a game simulator on Raspberry Pi

Install Weston on Raspberry Pi

Linux OS for Raspberry Pi is available

Raspberry Pi (Raspberry Pi) trial note

Introduction to Raspberry Pi (Raspberry Pi) installation, IP configuration, and software source