If you’ve been following my WordPress cluster guides, you’ll know that I use GlusterFS or Unison to handle file replication between nodes in the cluster.
This works well when there are not too many files per directory. But if you have thousands upon thousands of images in your uploads folder then GlusterFS can get a bit slow. This is because of the technique it’s using to check if the file has been changed on any of the other nodes.
Anyway, the ideal situation would be for it to be possible to mount a Digital Ocean volume from all 3 of your nodes, but unfortunately that’s not yet possible. What you can do is to create yourself a file storage droplet and attach a huge volume to it, then use NFS to access that single volume from the clusters.
There are options for how to go about using this knowledge with a WordPress cluster. For example, we could stick the entire WordPress folder in this single location, but then if the volume is down, all your nodes will be down.
The approach I’m taking in this article is to put the wp-content/uploads folder onto the shared volume over NFS. Then, if for some reason the single-point-of-failure of this shared storage volume is down, it’s only images that are affected, and hopefully for the duration they will be largely unaffected as we’ll have a CDN in front of our cluster serving up this static content.
Here’s a link to Digital Ocean’s guide to setting up NFS: https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nfs-mount-on-ubuntu-16-04
Create a new droplet – I chose a 2GB 2CPU droplet – add private networking, and add a volume of your choice.
Once the droplet has been created, log onto it using Putty and then run the commands provided by Digital Ocean.
They make it easy to click to copy the commands, then you can right-click in the putty window. This will configure and format your new massive storage volume.
Once that is done, you’re ready to configure NFS.
Configure your file server
On the new storage volume droplet – the host – run the following:
apt-get install nfs-kernel-server
mkdir /var/largestorage -p
chown www-data:www-data /var/largestorage/
systemctl restart nfs-kernel-server
Edit the /etc/exports file to configure remote access to your share.
In my example, I’ve added the following line:
/var/largestorage 10.138.104.226(rw,no_root_squash,no_subtree_check) 10.138.232.3(rw,no_root_squash,no_subtree_check) 10.138.232.6(rw,no_root_squash,no_subtree_check)
Configure your nodes to access the file server
On your cluster nodes – the clients – run the following:
apt-get install nfs-common
Now in my example, I’m replacing the uploads folder, so I’ve temporarily moved the contents of that elsewhere. You still need a folder on the client for the mount point however, so ensure that your uploads folder exists and is empty. Then run the following:
mount 10.138.148.38:/var/largestorage /var/largestorage
Once you’ve run the 2 commands above on all your nodes, they will all have access to the same storage folder for uploads on your large volume droplet.
Configure everything to mount when you reboot
Add this line for the NFS share.
10.138.148.38:/var/largestorage /var/www/wpicluster/wp-content/uploads nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0
Create a symbolic link to the newly mounted folder. Providing you have the storage mount on each device, when Unison or GlusterFS replicates the symbolic link it will still work on that new node.
ln -s /var/www/wpicluster/wp-content/uploads /var/localstorage
Let me know any questions.
Latest posts by Dave Hilditch (see all)
- Faster Woo Widgets beta - February 13, 2020
- Performance review of the Yith Wishlist (it’s bad, but they fixed it in 24 hours!) - July 17, 2019
- My journey fixing WooCommerce slow speed with many variations – part 1 - July 6, 2019