闪电从不打击两次：幸存Azure云中断

昨天早上我打开了我的Twitter订阅源，发现很多人都受到了Azure Cloud中断的影响。几乎每个关于中断的资源页面都不可用。幸运的是，@ AzureSupport继续通过Twitter提供更新。来自@AzureSupport的原始更新于美国东部时间上午7:12发布。回顾Twitter推文，似乎问题最初是在此之前的一两个小时开始的。 很明显，这次中断的传播影响比最初报道的美国中南部地区更广泛。似乎依赖Azure Active Directory的服务也可能受到影响，并且尝试配置新订阅的客户遇到了问题。 24小时后问题还没有完全解决，根据今天上午的最新更新…那么你可以做些什么来减少这种蔚蓝云停电的影响？没有人可以责怪微软发生雷击等自然灾害。但是在一天结束的时候，如果您唯一的灾难恢复计划是打电话，发推特并通过电子邮件发送电子邮件直到问题得到解决，那么您刚刚收到了一个粗鲁的觉醒。在您的灾难恢复计划中，您需要确保涵盖所有基础。

是时候探索一些替代品？

虽然灰尘仍在准确定位受影响的内容以及客户可以采取哪些措施来最大限度地减少停机时间，但这里有一些我最初的想法。

可用性集（故障域/更新域）

在这种情况下，即使您构建了故障转移群集，或利用Azure负载均衡器和可用性集，您仍然会因为整个区域脱机而运气不佳。虽然仍建议使用可用性集，尤其是计划停机时间，但在这种情况下，您仍然可以脱机。

可用区域

它尚未在美国中南部地区推出。然而，似乎在Azure中推出可用区的概念可以最大限度地减少中断的影响。假设雷击仅影响一个数据中心，则另一个可用区中的另一个数据中心应保持运行。但是，Azure Active Directory（AAD）等其他非区域性服务的中断似乎影响了多个区域。我不认为可用区会完全孤立你。

全局负载均衡器，跨区域故障转移群集等

无论您是构建跨区域的SANLess集群，还是使用全局负载均衡器将负载分散到多个区域，您都可以最大限度地减少美国中南部停电的影响。但是你可能仍然容易受到AAD中断的影响。

混合云，跨云

云端故障情况下的保证弹性是制定DR计划，其中包括将数据实时复制到主云提供商以外的目标，以及制定应用程序以在其他位置快速联机应用程序的计划。这两个地点应该完全独立。它不应该依赖主要位置的服务，例如AAD。DR位置可以是另一个云提供商。在这种情况下，AWS或Google Cloud Platform似乎是合乎逻辑的替代方案，或者它可能是您自己的数据中心。但这种方式首先打败了在云中运行的目的。

软件作为服务

虽然Azure作为服务（如Azure Active Directory（ADD），Azure SQL数据库（Database-as-Service）或任何云提供商提供的众多SaaS产品之一）看起来很诱人，但您确实需要针对最糟糕的情况进行规划。您可能几乎无法控制，因为您信任单个供应商的业务关键型应用程序。请记住，它包括DR选项，包括当前云服务提供商之外的恢复。除了在实施任何SaaS服务之前调查您的DR选项之外，我在这里没有任何智慧的话。如果无法在云之外进行恢复，那么在注册该服务之前，请仔细考虑。告知业务所有者，如果云服务处于脱机状态，除了电话和投诉之外，您可能无法做任何事情。

未来的趋势

我想在不久的将来，您将开始越来越多地了解跨云可用性。 此外，还有人们如何利用SIOS DataKeeper等解决方案构建跨云提供商的强大HA和DR策略。真正跨云或混合云模型是真正将自己与最可能的云中断隔离开来的唯一方法。如果您受到这次最新停电的影响，我很乐意听取您的意见。告诉我发生了什么事，你垮了多久，以及你做了什么来恢复。您打算如何做，以便将来您的体验更好？阅读更多文章，例如如何生存Azure云中断？经Clusteringformeremortals.com许可转载