For static content, this is easy, even RSYNCs will be scalable to push out changes to your content amongst your farm. User uploaded content is quite a bit trickier. Within a single datacenter you can efficiently (though not always affordably) solve this using shared storage, iSCSI or NFS. Then applications pretty much can work as if they’re on a single server, session management can be tackled by using cookie or host persistence on the load balancers to make sure a user stays on the same server. What about servers in different locations though? NFS and iSCSI will not be terribly effective over transit.

You will have to push content between your locations then. If you are trying to geographically distribute your own application, you would just write functionality in to immediately push any user uploaded content out to other locations as its created.  Google/Youtube are great examples of this. When you hit content they’ve hosted, it isn’t even hosted on every server, and they direct you to the closest server that has said content. If that content isn’t available locally to you yet, or at all, they can stream it over their own fiber backhaul and out your closest Google POP.

But what if you are hosting a variety of 3rd party software. To my knowledge none of the popular blog packages, forum software, etc has any sort of geo-diversity designed into them. You could of course fork them and write your own, but then you end up supporting N different software packages for your N clients, not affordable or reasonable.  Rsync would do this task but unfortunately it is very intensive and doesn’t scale particularly well because it md5′s your entire tree constantly to see if things changed. As your content scales, the rsyncs would get slower and slower just seeing if changes occurred, eventually leading to massive delays on syncing out user created content.

In the end, its a cool problem, a problem that not too many people have tackled so far. We came up with our own solution, which I unfortunately probably shouldn’t disclose. I wrote the basis of the software last month, though it still needs some bug fixes, testing and more modules to be written for it. It is a difficult problem to tackle, but having worked in telecommunications, no facility is bullet proof, no power is bullet proof, no connectivity is bullet proof, no hardware is bullet proof: geo-diversity is a must going forward in this highly demanding world where everyone expects connectivity and content 24/7