如何使我的 Windows Azure 应用程序能够抵御 Azure 数据中心灾难性事件？
AFAIK Amazon AWS 提供所谓的“区域”和“可用区”来降低部分或完全数据中心中断的风险。看起来，如果我在两个“区域”中有应用程序的副本，而一个“区域”出现故障，我的应用程序仍然可以继续工作，就像什么都没发生一样。
Windows Azure 有类似的东西吗？如何使用 Windows Azure 解决数据中心灾难性中断的风险？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在单个数据中心内，您的 Windows Azure 应用程序具有以下优势：
好吧，这就是简单的事情。如果数据中心消失怎么办？以下功能可帮助您将灾难恢复构建到应用程序中：
请记住，对于灾难恢复，无论是在云中还是在本地，都会产生额外成本（例如数据中心之间的带宽、辅助数据中心中重复数据的存储成本以及其他数据中心中的计算实例）。 。
就像本地环境一样，灾难恢复需要仔细考虑和实施。
Within a single data center, your Windows Azure application has the following benefits:
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:
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.
大卫的回答很好，但有一点是错误的。对于Windows Azure blob 和表，您的数据实际上在子区域（例如美国北部和南部）之间进行地理复制。这是一个异步进程，目标是大约 10 分钟左右的延迟。这个过程也是你无法控制的，纯粹是为了数据中心的损失。当您使用 Windows Azure blob 和表时，您的数据总共会在 2 个不同的数据中心复制 6 次（令人印象深刻，不是吗？）。
如果数据中心丢失，他们会将您的 Blob 和表存储的 DNS 转移到其他子区域，并且您的帐户将再次在线显示。这仅适用于 blob 和表（不适用于队列、不适用于 SQL Azure 等）。
因此，为了实现真正的灾难恢复，您可以使用 SQL Azure 数据同步和流量管理器进行计算（假设您在另一个子区域运行热备用）。如果数据中心丢失，流量管理器将路由到新的子区域，您也可以在那里找到您的数据。
David's answer is pretty good, but one piece is incorrect. For Windows Azure blobs and tables, your data is actually geographically replicated today between sub-regions (e.g. North and South US). This is an async process that has a target of about a 10 min lag or so. This process is also out of your control and is purely for a data center loss. In total, your data is replicated 6 times in 2 different data centers when you use Windows Azure blobs and tables (impressive, no?).
If a data center was lost, they would flip over your DNS for blob and table storage to the other sub-region and your account would appear online again. This is true only for blobs and tables (not queues, not SQL Azure, etc).
So, for a true disaster recovery, you could use Data Sync for SQL Azure and Traffic Manager for compute (assuming you run a hot standby in another sub-region). If a datacenter was lost, Traffic Manager would route to the new sub-region and you would find your data there as well.
您没有考虑到的一个故障是跨数据中心复制错误的能力。在这种情况下，您可能需要考虑在负载平衡或故障转移场景中将 Azure PAAS 作为 HP Cloud 产品的一部分运行。
The one failure that you didn't account for is in the ability for an error to be replicated across data centers. In that scenario, you may want to consider running Azure PAAS as part of HP Cloud offering in either a load balanced or failover scenario.