Azure Outage Post Mortem第2部分

发生了什么？这是我们的Azure Outage Post Mortem第2部分

我之前的博客文章称，云到云或混合云可以让您与CSP可能遇到的任何问题隔离开来。但是，如果在中南部地区提供可用区，则可以避免由此自然灾害造成的大部分停机时间。微软发布了9月4日南中央停电的初步RCA。整个摘要中最重要的部分如下……

“尽管有现实的冗余，有一些情景，其中一个数据中心的冷却故障会影响受影响的数据中心的客户工作。”

这对你来说代表着什么？

如果您的应用程序都在同一个数据中心运行，那么您将来可能会遇到相同类型的中断。在微软的辩护中，这对你来说真的不应该是新闻。无论您是在Azure，AWS，Google还是自己的数据中心运行，这一直都是如此。未能提前计划将数据复制到不同的数据中心以及制定快速恢复应用程序的计划只是缺乏您的计划。Microsoft未发布确切的可用区位置。如果你相信这张地图发表在这里，你可能会猜到它们可能相距2-10英里。 除了最极端的情况之外，在可用区之间复制数据应该足以用于数据保护。某些应用程序（如SQL Server）内置了复制技术。但是，对于广泛的应用程序，操作系统和数据类型，请研究块级复制SANless群集解决方案。SANless集群解决方案传统上用于多站点集群。但是，相同的技术也可以在可用区，区域或混合云中的云中使用，以实现高可用性和灾难恢复。无论是Azure，AWS还是Google，实施跨越可用区的SANless群集都是一个非常简单的过程，只需要合适的工具。作为宰蓝式停电事件的一部分，这里有一些资源可以帮助您入门。循序渐进：在Azure中配置跨越可用区的文件服务器群集如何在Google Cloud Platform中构建SANless SQL Server故障转移群集实例MS SQL Server v.Next在具有复制和高可用性的Linux上#Azure #Cloud #Linux在AWS快速入门中的AWS SANless Linux群集中的#Azure资源管理器（ARM）SAN SANless SQL Server群集中部署Microsoft SQL Server 2014故障转移群集

Azure Outage Post Mortem的教训

如果您在Azure中，则可能还需要考虑Azure站点恢复（ASR）。ASR允许您将整个VM从一个Azure区域复制到另一个区域。ASR将实时复制您的虚拟机，并允许您随时进行无中断的灾难恢复测试。它支持大多数版本的Windows和Linux，并且相对容易设置。您还可以创建具有“多VM一致性”的复制作业。这意味着必须从完全相同的时间点恢复服务器，这些时间点可以放在此一致性组中，并且它们将具有完全相同的恢复点。实质上，如果您在单个区域中构建具有DataKeeper的SANless群集以实现高可用性，则DR有两个选项。一种是您可以将SANless群集扩展到不同区域中的节点，或者可以使用ASR复制一致性组中的两个节点。

有什么不同？

与ASR的权衡是RPO和RTO不如使用SANless多站点群集那么好。虽然它很容易配置并适用于任何应用程序。小心点 如果您的应用程序定期超过10 MBps的磁盘写入活动，ASR将无法跟上。此外，基于Storage Spaces Direct的群集无法使用ASR进行复制，并且在Azure中使用时通常缺乏良好的DR策略。管理磁盘发布后的一段时间，ASR直到大约一年后才完全支持它们。对于许多希望使用ASR的人来说，对托管磁盘的全面支持是一个很大的障碍。幸运的是，从2018年2月开始，ASR完全支持托管磁盘。但是，刚刚引入了另一个问题。随着可用区的引入，ASR再次落后于时代。它们目前不支持已部署在可用区中的VM。

无论如何我继续尝试了。似乎可以配置复制，我能够进行测试故障转移。

了解有关Azure Outage Post Mortem的分析的更多信息，经过Clusteringformeremortals.com的许可转载