Benutzer mit den meisten Antworten
Im looking for any feedback or suggestions on the following...
Last weeks Azure compute outage was a cold reminder to us about not putting all your eggs in one basket when it comes to hosting in the cloud. We lost compute access for around 7 hours. We weren't really prepared for this, and it took us almost 6 hours to set up other servers outside of the Azure environment. Live & learn.
Thankfully with compute, hosting code elsewhere is not impossible. However we are also heavy users of Azure Storage (Tables, Blobs, Queues). In fact our entire company hinges on this technology. Lets say hypothetically the storage service goes down for a day, or 2, or worse - what do we do?
Option 1: Wait for Microsoft to fix the issue. While I have complete faith that Microsoft will work hard to fix outages like this, I don't think it makes business sense not to have a contingency.
Option 2: Switch to another database environment outside of Azure. To make this possible, I think we'd need the following:
a. Log Shipping. Every storage operation would need to be logged, and then transfer the logs elsewhere on a regular basis. Since there is no framework for this that I'm aware of (??) we'd need to write this. Perhaps we could write a proxy to channel all storage operations through, or a custom LINQ provider that inherits from the standard storage library.
b. Storage service emulation. To run our storage on another server, we'd need to emulate it. The most obvious solution would be to run the standard development storage on a server - however I doubt it's ability to handle any sort of significant load (and I'm guessing it would violate licence terms too). That means we'd need to write this too - either mimic all of the http operations that Azure storage supports - or instead perhaps use a different LINQ provider (perhaps even a standard LINQ to SQL provider?)
All this sounds like a mountain of work, is there another solution? Or is everyone else just placing all their faith in Microsoft that there will never be a major problem?
We apologize for the outage. And we’ll work hard to ensure this won’t happen. If you’re still concerned, you can back up your data to somewhere else. Instead of backing up real time data, you can, for example, run a daily job that performs back up. The difficult part is to figure out which data to back up. You may need to create a particular table to track changes since the last back up. That table will store information like:
Table name Partition key Row key operation
Here operation could be insert, update, or delete.
- Als Antwort markiert Arwind - MSFTModerator Mittwoch, 14. März 2012 03:19