I've built the cluster, and I can access each node individually, and I've put the cluster in place in my miniature ARM server farm. In these pictures, the Banana Pis are in the rack on the left, and the other two racks contain Raspberry Pis which host RaspberryWebserver.com.
The next step is to make the cluster accessible from the internet.
The load balancer is a PC running Apache on Lubuntu. I originally set it up to feed HTTP requests from my router to my Raspberry Pi cluster. I needed to configure Apache to send traffic for the Raspberry Pi site to one cluster, and traffic for this site to the Banana Pi cluster. I did this by adding a new virtual host to Apache.
I created a new virtual host file in /etc/apache2/sites-available/banoffeepiserver.conf. I copied the contents of the default configuration file and pasted them into the new file, and made a few simple changes. This is what the new virtual host file looks like:
The ServerName directive tells Apache to use this virtual host for any HTTP request with banoffeepiserver.com in the host field.
For local testing the load balancer's IP address can be entered in the hosts file on your PC. Adding this line to my laptop's hosts file allowed me to see my site in a web browser when I typed my site's name in my browser:
In Linux this file is /etc/hosts. In Windows, it's C:\Windows\System32\drivers\etc\hosts.
ProxyRequests are turned off so that the load balancer can't be used as an open proxy.
The balancer is defined as bpicluster. It contains four members defined by their IP addresses.
The balancer module can display a web UI that can be used to monitor and control the cluster. The location of this UI is defined as /bpi-balancer-manager, and access is limited to IP addresses on the local network.
Any path in Pyplate's admin directory is blocked from the outside world. The admin area of the CMS only needs to be accessible locally.
Finally, the ProxyPass directives tell Apache to pass most requests to the cluster, apart from requests for /bpi-balancer-manager, which are handled by the load balancer.
After saving the new virtual host file, the site has to be enabled:
The a2ensite command creates a symbolic link from /etc/apache2/sites-available/banoffeepiserver.conf to /etc/apache2/sites-enabled/banoffeepiserver.conf. Apache must be restarted for these changes to take effect.
Follow this link to see detailed information on how to set up an Apache 2.4 reverse proxy on Ubuntu.
I did some benchmarking using a PC on my local network to generate HTTP get requests. I used the siege command to test the cluster:
The cluster could handlle 1050 transactions per second, with through put of 8.11MB/Sec.
I haven't done detailed a comparison with my Raspberry Pi cluster because there are so many differences between them.
The Raspberry Pi cluster uses an older version of Pyplate CMS which used CGI scripting. The latest version of Pyplate uses WSGI instead of CGI making dynamic pages much faster. I've also used Nginx on the nodes in this cluster, instead of Aapche.
To complicate things further, the load balancer appears to be a bottleneck. One Banana Pi is capable of handling 440 transactions per second. With two nodes in the cluster, the transaction rate went up to 910 transactions per second. When I added a third node to the cluster, there was a relatively small increase in performance, up to 1050 transactios per second. Adding a fourth node didn't improve perfomance at all. While siege was running, the load balancer's CPU utilization was 100%.
There is no benefit in allowing the master node to serve traffic, so I removed its entry from the bpicluster in the banoffeepiserver.conf virtual host file. In some ways this is a good thing because it make the master node harder to hack into.
Until I get a new load balancer, it's going to be difficult to determine how powerful the cluster actually is.
When I bought the domain name for this site, I updated it to point to my router's public IP address. If you don't have a static IP address, you should use a dynamic DNS service.
It can take time for DNS changes to propagate to every DNS server. In theory it can take 24-48 hours for DNS settings to propagate, but in this case it seemed to happen in just a few hours.
My router is configured to forward incoming HTTP requests on port 80 to the load balancer's public IP address. I already had this set up for my Raspberry Pi site, so I didn't need to make any changes to my router.
Share this page: