Question

AFAIK Amazon AWS offers so-called “regions” and “availability zones” to mitigate risks of partial or complete datacenter outage. Looks like if I have copies of my application in two “regions” and one “region” goes down my application still can continue working as if nothing happened.

Is there something like that with Windows Azure? How do I address risk of datacenter catastrophic outage with Windows Azure?

Answer 1

Within a single data center, your Windows Azure application has the following benefits:

• Going beyond one compute instance, your VMs are divided into fault domains, across different physical areas. This way, even if an entire server rack went down, you’d still have compute running somewhere else.
• With Windows Azure Storage and SQL Azure, storage is triple replicated. This is not eventual replication – when a write call returns, at least one replica has been written to.

Ok, that’s the easy stuff. What if a data center disappears? Here are the features that will help you build DR into your application:

• For SQL Azure, you can set up Data Sync. This facility synchronizes your SQL Azure database with either another SQL Azure database (presumably in another data center), or an on-premises SQL Server database. More info here. Since this feature is still considered a Preview feature, you have to go here to set it up.
• For Azure storage (tables, blobs), you’ll need to handle replication to a second data center, as there is no built-in facility today. This can be done with, say, a background task that pulls data every hour and copies it to a storage account somewhere else. EDIT: Per Ryan’s answer, there’s data geo-replication for blobs and tables. HOWEVER: Aside from a mention in this blog post in December, and possibly at PDC, this is not live.
• For Compute availability, you can set up Traffic Manager to load-balance across data centers. This feature is currently in CTP – visit the Beta area of the Windows Azure portal to sign up.

Remember that, with DR, whether in the cloud or on-premises, there are additional costs (such as bandwidth between data centers, storage costs for duplicate data in a secondary data center, and Compute instances in additional data centers). .

Just like with on-premises environments, DR needs to be carefully thought out and implemented.