3 ms·
We've seen floods of these "What you should have done if your application was interrupted Friday night" articles, but a common theme is to leave out the fact th
by TomFrost 14y ago
We've seen floods of these "What you should have done if your application was interrupted Friday night" articles, but a common theme is to leave out the fact that many of these sites require synchronized data storage, which Amazon doesn't support between regions. If your organization is shelling out the money for something like Riak, Oracle, or the mess necessary to support such an architecture though the likes of MySQL or Postgres, this is all well and good (save for the data transfer overhead costs).
If your application is architected to use SimpleDB, DynamoDB, SQS, or even RDS, these simple "You should have been using Route 53 and multiple regions" articles get increasingly frustrating. Most applications simply aren't elementary enough to fit into that boilerplate structure, and getting around that fact either requires switching away from Amazon's managed database services (lots of money) or writing synchronizing scripts that play nicely with your stack and launching them on additional servers (lots of money and lots of resources).
While ideally I'd like to see Amazon release some sort of feature for multi-region sync, it would be interesting to see how the tried-and-true multi-region businesses have approached this problem.
- danoprey 14y agoCompletely true, there's a lot to be written on the subject and there are some great detailed posts out there. I think Google Compute Engine does exactly that, with a direct connection between regions so the entire system works as one network. I'm not sure if that will be the case outside the US, though.
- rdl 14y agoI don't know if I'd trust Amazon to run links between their data centers. They had a couple routing related outages just this year alone (which lasted for some time), and adding complexity would make that worse. You could easily lose interconnections between hosts in AZs in distinct 3 regions, partitioning everything, making it irrelevant that all 3 actually stay up and are accessible to outside users.
- davidacoder 14y agoI looked at Azure to see how these things work there. Here is my current understanding: blob and table storage in Azure Storage is automatically geo-replicated between regions. If you don't want that you can reduce your storage cost by about 30%. VM disks are stored in Azure blobs, so if a region goes down you should actually be able to create a new VM in a different region and attach the SAME disc you had attached to the VM in the region that went down. For the SQL datbases they provide a sync service that can replicate your database automatically between different regions (or even a local database). I have no clue how reliable all of this is, but at least in theory it looks as if it might be quite a bit easier to do full geo replication across different regions on Azure. Anyone with actual experience?
- WALoeIII 14y agoI wish I could upvote this 50 times. The diagrams show two separate masters in different regions with their own slaves, yet DNS is essentially randomly delivering users to each "half". There is no mention of how this is handled, or even that you would have to consider it.
- danoprey 14y agoAgreed, every step in this could be an article in itself, but the intention was just to give an overview of all the options.