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