结束Azure Outage Post-Mortem第3部分
我以前的博客帖子，Azure Outage Post-Mortem – 第1部分和Azure Outage Post-Mortem第2部分，基于来自博客帖子和Twitter的有限信息做出了一些假设。我刚刚参加了Ignite的一次会议，它更明确地说明了实际发生的事情。明天某个时候你应该能够自己查看会话。BRK3075 – 为意外做准备：解决Azure中断官方根本原因分析即将发布。与此同时，这里有一些从会话中收集到的信息。
原因
从死后的蔚蓝停电中，停电不是由先前报道的雷击引起的。相反，由于风暴的性质，电风暴下陷和膨胀。结果，它锁定了第一个数据中心的冷水机组。在第一次停电期间，他们能够快速恢复冷却器，没有明显的影响。此后不久，第二个数据中心发生了第二次中断，无法正常恢复。这开始了一系列不幸的事件。
第二次停电
在此次停电期间，微软表示“工程师没有正确分类警报 – 冷水机组恢复没有优先考虑”。此时触发了大量警报。不幸的是，冷冻机处于脱机状态并没有得到应有的优先权。关于为何发生这种情况的RCA仍在调查中。微软声称当然有多余的冷却系统。但是，冷却系统未设置为自动故障转移。最近安装的新设备尚未经过全面测试。 所以它被设置为手动模式，直到测试完成。45分钟后，环境冷却失败，硬件停机，空气处理人员关闭，因为他们认为发生火灾。 工作人员因虚假火警而被疏散。在此期间，数据中心的温度在升高。某些硬件没有正常关闭，导致某些存储和网络损坏。手动重置冷却器并打开空气处理器后，温度开始恢复正常。他们花了大约3小时29分钟才能全面了解数据中心的状态。最大的问题是存储损坏。微软最关心的是数据保护。Microsoft将努力恢复数据以确保不会丢失数据。这当然需要一些时间，这延长了停机的总长度。好消息是没有客户数据丢失。 坏消息是，事情似乎需要24-48小时才能恢复正常。这是基于我在Twitter上从抱怨长时间停机的客户那里读到的内容。
假设
每个人都预计这次中断会影响在中南部地区的客户。但他们没想到的是，停电会对该地区产生影响。在会话中，Microsoft讨论了中断的一些扩展范围。
Azure服务管理器（ASM）
这可以控制Azure“Classic”资源，AKA，ARM之前的资源。任何依赖ASM的人都可能受到影响。我不清楚为什么会这样。南中部地区似乎拥有该服务的一些重要组成部分，而这些部分无法使用。
Visual Studio团队服务（VSTS）
同样，似乎许多支持此服务的资源都在中南部地区托管。Azure DevOps此博客文章的工程总监Buck Hodges（@tfsbuck）详细介绍了这次中断。
Azure Active Directory（AAD）
当中南部地区失败时，AAD按照预期的方式行事，并开始将身份验证请求指向其他地区。随着东海岸开始醒来并上线，身份验证流量开始增加。现在通常AAD会通过自动缩放来处理流量的增加。但是自动缩放依赖于ASM，当然它是离线的。如果没有自动缩放功能，AAD无法处理身份验证请求的增加。令人恼火的情况是Office客户端中的一个错误，这使得它们具有非常积极的重试逻辑，并且没有退避逻辑。这种额外的身份验证流量最终使AAD陷入困境。他们没有时间在Ignite会议期间进一步讨论这个问题。 他们将介绍的一个功能是让用户能够在将来手动故障转移存储帐户。因此，如果恢复时间目标（RTO）比（RPO）更重要，则用户将能够在备用数据中心恢复其异步复制的地理冗余存储，如果Microsoft未来再次遭遇延长中断的话。
你现在能做什么
在此之前，您将不得不依赖其他复制解决方案，例如SIOS DataKeeper Azure Site Recovery。或者是特定于应用程序的复制解决方案，它能够跨区域复制数据，并能够在您的控件中实施灾难恢复计划。了解有关我们的蔚蓝停电事件的更多信息，经Clusteringformeremortals.com许可转载