How to share assets between multiple web servers?
There are multiple ways to do this based on your needs.
- Use a central file server mounted with fx NFS on the webservers
- Same as above, but redundant, so if one goes down the other takes over
- Use some sort of synchronization tool (rsync for example) and host the files locally on the webservers. Then setup a cronjob to sync the files between the servers at a specific interval.
- Use a CDN such as Amazon S3, Akamai etc.
The first two are best if you have a lot of new files coming. The third would be the ideal solution if you don't add or change files that often since the users will get 404's on static content not yet synced..
The last option might be ideal in many ways, but might also turn out to be the most expensive of the 4. You would also need to rewrite your websites to support this.
Another great way to decrease load on webservers and perform load balancing is with squid (namely squid3) Set it up as a reverse proxy with caching. It will cache static content such as pictures etc to either the HDD (default) or to RAM (faster and the best) if you set it that way. It is capable of round robin to other squid servers as well if any one particular node is overloaded.
One solution to this challenge I've employed is to have the main read/write copy of the files on a shared NFS drive, but also keep at read-only copy on each webserver so that a failure of the NFS host puts file-access in read-only mode rather than loosing them completely.
- Files live on central host, shared with web-hosts via NFS mount
-
rsync
runs ever 15 minutes to keep the read-only copy on each web host fresh. - A
check_link
bash script runs every minute to make sure the NFS mount is still there and if not swaps a symlink to the read-only copy.
More details are found in this article from when I first set up this system.
Upsides:
- File reads are highly available
- No race conditions for file writes
- New files are instantly available to all web hosts.
Downsides:
- a bit complex.
- the number of read-only copies scales with the number of web hosts, which might be excessive if you have many more than two.
- File writes are not highly available.
- Potential for up to 1 minute of downtime before switching to the read-only copy.
Since usually the need for more servers comes from the resources needed to run dynamic websites/aps, consider hosting static assets at another subdomain/domain. (like static.yourdomain.com)
You can then use another server/servers to host them. Static file hosting doesn't use very much resources, so you will need considerably less servers for your static content. You will also free some resources on the servers for your dynamic content.
Depending on your load balancer you might also be able to do this on the same domain with the load balancer deciding which server to use for which request, but if you use a separate domain you can put your static assets onto a CDN quite easy, if the need should arise!