Ask HN: Content Serving Cluster
I run a small website, which shall remain unnamed so as to avoid unneccessary threads. I'm pushing probably a few terabytes of data a month now, so to improve speed whilst keeping costs low, I plan to serve files from multiple machines. A mini-CDN if you will.
The files will be the same across each distribution server, but I am not sure of the best way to replicate the uploaded files across machines.
Example: Someone uploads xyz.tar.gz to Machine #1. I need it replicated, as fast as possible, to Machine #2 and #3, so that when people visit the site, if they get http://cdn-3.mysite.com/, they'll get the file.
Does HN have any suggestions as to the best way to go about this?
Edit: My files aren't very large, they're maybe 5 gb in total and don't grow too fast, they're just accessed a lot.
12 comments
[ 4.1 ms ] story [ 39.0 ms ] threadhttp://en.wikipedia.org/wiki/Lustre_(file_system)
A simpler option would be to do a little scripting magic to catch inotify signals and then trigger an rsync.
Otherwise: rsync is your friend. Run it in daemon mode. If you've just got a handful of machines I'd nominate one machine as the server to receive all uploads. Everybody else just syncs their upload directory to that machine's.
You may also want to consider offering bittorrent as an option, since this situation appears to be tailor-made for it.
I've never set one up myself, but a clustering file system might work, e.g. OCFS: http://oss.oracle.com/projects/ocfs2/
If you already have a reliable central filestore, varnish or squid might accomplish faster distribution without having to replicate all your files.
Otherwise, I'm curious to see everyone's suggestions. I've looked at more *sync programs than I can count to handle this use case and come up empty-handed.
If files are uploaded to multiple machines, is it possible that you'd get two different files with the same name uploaded to different machines? If so, how do you want to handle this?
Will you ever have files deleted?
Do you have any ordering requirements, e.g., files have to appear on each machine in the same order as they were originally uploaded?
Let someone else worry about that issue. The amount of time you'll spend setting it up, testing it, maintaining it, is time wasted on other important aspects of your business/application. You are not going to be able to do it any better or any cheaper.
This worked pretty well for a friend's site and you don't to care about replication anymore.
1. rsync on the backend; it's easy, it's relatively fast, but it is asynchronous and files won't be immediately available on all servers.
2. An inotify watcher that copies files to the slaves when a file is written or changed on the master. Faster than an rsync solution, but you'll need to write it yourself.
In either case you will want to seriously question whether you should do it yourself, look at the costs for keeping machines operational and how much you are paying for bandwidth.