結束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許可轉載