Creating a High Availability Cluster – Final Thoughts
Welcome to the final part of using the VPS.net public cloud to create a highly available web server solution for your website. Over the previous parts we’ve looked at creating a MySQL Master-Master replication system for your database, automating Unison to replicate files between the two servers and using Heartbeat to manage Apache and an IP that floats between the servers.
Something that we touched on just briefly while doing the configuration was security in allowing MySQL to communicate between the servers by adjusting the firewall rules. In general, the same rules and advice for securing your server apply to a system in a high availability solution as an individual server. Your firewall should only allow access from the whole world to the web server, otherwise you’ll want to be locking down everything else incoming. MySQL and heartbeat should only be open to the other server. SSH should be restricted to only places you know you will be connecting from and the other server as far as possible. You can allow ping globally or restrict it to just between the two servers.
An example configuration for getting started with iptables may look like this:
*filter
:FORWARD ACCEPT [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
#Accept all established connections
-A INPUT -m state –state NEW,ESTABLISHED -j ACCEPT
#Accept all traffic from the other server
-A INPUT -s 192.168.0.3 -j ACCEPT
#Accept website traffic from anywhere
-A INPUT -p tcp –dport 80 -j ACCEPT
-A INPUT -p tcp –dport 443 -j ACCEPT
#Accept ping traffic from anywhere
-A INPUT -p icmp –icmp-type echo request -j ACCEPT
#Accept SSH connections from office range
-A INPUT -p tcp –dport 22 -s 172.16.5.0/24 -j ACCEPT
With this configuration, your server would be suitably locked down. In the section for accepting traffic from the other server, you’d need to change the IPs to match your opposing servers. As for the SSH connections, you’ll need to use a number of lines if you connect from multiple locations. Alternatively you can remove the -s section to allow connections from anywhere.
While we’ve provided some example of configuration here for iptables, you can use whichever firewall you prefer to configure. The general advice with regards to ports to open remains the same. If you aren’t confident with what is outlined here when working with iptables, or are unsure when it comes to firewalls, it’s worth reading detailed guides, as there’s no differentiation between setting up a firewall in a high availability setup and a single server.
Another consideration for websites is SSL certificates. These can be applied as usual; nothing special needs to be done here. When generating the CSR and the key for the certificate, do this only on one of the servers. Once applied for, the certificate can be installed on the server where the CSR was generated and the Apache configuration modified to use the certificate. When this step is complete you can duplicate the configuration and copy the key and certificate over to the same locations on the other server. There’s no need for a special SSL certificate, or to license two certificates, as one for each server will suffice.
If you choose to use a service such as Let’s Encrypt for your SSL certificates then it’s best to run it on one of the servers. You can then configure Unison to duplicate the directory in which is stores the SSL files over to the other server. Alternatively, you can write your own scripts to update the certs and the Apache configuration.
At this point we’ve covered pretty much everything you’ll need to get started building your own high availability solution on a public cloud. We hope you’ve found this series interesting and helpful.