Date: 8 11 月, 2018
標籤: 蔚藍的停電驗屍
結束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許可轉載