Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a couple of ubuntu instances running on Amazon EC2 and would like to make them a bit more fault tolerant by running a duplicate instance in another region(generated from a snapshot) with load balancers -- or even a manual fail over with elastic ip.

The problem is the specific data, as an example it does no good to fail over from one web server to another web server if the contents of the document root i.e. /var/www are not identical.

In this example I would have the contends of /var/www on their own volume as to not impact the root partition. Is there a way to share a volume across two or more instances on different zones? or perhaps a way to keep two or more different volumes in sync across regions?

share|improve this question
An EBS volume cannot be mounted on multiple instances simultaneously. Since you are only trying to keep the document root the same, the simplest way is to pull the source code from your repository on boot and push out new changes on commit. If that doesn't suit your scenario, you could try: GlusterFS, S3FS, or DRBD - each have their use cases. – cyberx86 Jul 30 '13 at 17:13
Concerning your specific problem, you should just create a rsync task between your two instances which update only the last modified files, and cron it regularly, like, every 10 minutes, but omitting your cache files. – Yannovitch Jul 31 '13 at 7:38
web hosting was just an example, the scope of the actual servers goes well beyond just web pages. The point is to have a shared filesystem, or two sync'd filesystems so that systems can easily failover without data loss. – Ryhnn Jul 31 '13 at 11:28
up vote 3 down vote accepted

As cyberx86 says, EBS volumes cannot be mounted on multiple EC2 instances (even in the same Availability Zone).

The first answer should be to store your shared assets in Amazon S3 - that way, you can deploy your code via Capistrano/Mcollective/whatever directly to both your live and standby EC2 instances, and completely offload your static content (i.e. images, media) to S3, perhaps even with CloudFront providing edge caching.

That said, S3 doesn't do cross-region replication (EU-West-1 to US-East-1), however it does offer "four nines" (99.99%) of availability within a region, so a full region-wide failure is unlikely. For a 'belt and braces' approach you may want to configure a cron'd synchronisation process between S3 buckets in two different regions - take a look at the s3cmd documentation with the --sync flag.

If porting your assets to S3 is too much of a pain, and if your failover mechanism is hot-standby (i.e. you have an always-ready clone in another region and manual failover), you can configure a cron'd rsync run to keep your non-version-controlled assets synchronised (as before, you should always release your app code to all servers.

Clustered filesystems (e.g. GlusterFS, GFS2) or block-level replication (e.g. DRBD) isn't really recommended with EC2 (or at least not unless you shell out for instances with guaranteed NIC bandwidth such as the cluster networking range). S3FS has proven to be painfully slow, due to the fact that every IO request on the filesystem has to be backed with an S3 API call - details here: (1), (2).

You can run into network congestion caused by other tenants (or even create congestion yourself) - these types of solutions are best fitted to environments where you control (or at least have influence over) the entire stack.

share|improve this answer
Not the answer I was hoping for, but consistent with everything else I've read. Guess I am going to have to find a different way of doing this. – Ryhnn Jul 31 '13 at 11:25
One small nitpick: while you don't technically get cross-region replication, the US Standard region for S3 does locate content in both Virginia and California and routes content requests based on whichever is closer to the requestor; it's isolated from datacenter or network failures in either site. As a consequence of this, however, you lose the ability to have read-after-write consistency in this region. – jgoldschrafe Jul 31 '13 at 18:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.