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?
Best Answer
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
s3cmddocumentation with the--syncflag.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
rsyncrun 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.