本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
容錯和故障隔離
當我們考慮可用性時,這是兩個重要的概念。容錯能力是承受子系統故障並維持可用性的能力(在已建立的 SLA 內做正確的事情)。若要實作容錯,工作負載會使用備用 (或備援) 子系統。當冗餘集合中的其中一個子系統發生故障時,另一個子系統會取得其工作,通常幾乎無縫。在這種情況下,備用零件是真正的備用容量;它們可以承擔故障子系統 100% 的工作。使用真正的備援裝置時,需要多個子系統故障,才能對工作負載產生不利影響。
故障隔離可最大限度地減少發生故障時的影響範圍。這通常是通過模塊化實現的。工作負載會分解成小型子系統,這些子系統會獨立故障,而且可以單獨修復。模塊的故障不會傳播到模塊之外。這個想法橫跨工作負載中的不同功能,以及橫向跨越提供相同功能的多個子系統。這些模組充當錯誤容器,可限制事件期間的影響範圍。
控制平面、資料平面和靜態穩定性的架構模式直接支援實作容錯和容錯隔離。Amazon Builder Library 文章使用可用區域的靜態穩定性
-
控制平面 — 進行變更所涉及的工作負載部分:新增資源、刪除資源、修改資源,以及將這些變更傳播到需要的位置。控制平面通常比資料平面更複雜,而且具有更多的移動零件,因此在統計學上更容易發生故障並具有較低的可用性。
-
資料平面 — 提供 day-to-day 業務功能的工作負載部分。數據平面往往比控制面更簡單,並且以更高的體積運行,從而導致更高的可用性。
-
靜態穩定性 — 儘管相依性受損,工作負載仍能繼續正確操作的能力。實現的一種方法是從數據平面中刪除控制平面依賴關係。另一種方法是鬆散耦合工作負載相依性。也許工作負載沒有看到任何更新的信息(例如新事物,刪除的東西或修改的東西),它的依賴項應該已經交付。但是,在依賴關係受損之前它所做的一切都繼續起作用。
當我們考慮工作負載的損害時,我們可以考慮兩種高層次的方法進行恢復。第一種方法是在損害發生後對該損害做出反應,也許使用AWS Auto Scaling來添加新的容量。第二種方法是在這些損壞發生之前做好準備,也許是通過過度佈建工作負載的基礎結構,以便它可以繼續正確運行,而不需要額外的資源。
靜態穩定的系統使用後一種方法。它預先佈建了故障期間可用的備用容量。此方法可避免在工作負載復原路徑中建立控制平面的相依性,以便佈建新容量以從故障中復原。此外,為各種資源佈建新容量需要時間。在等待新容量時,您的工作負載可能會因現有需求而超載,並經歷進一步降級的情況,進而導致「中斷」或完全可用性損失。但是,您也應該考慮將預先佈建的容量用於可用性目標的成本影響。
靜態穩定性為高可用性工作負載提供接下來的兩個規則。
規則第 7 條
請勿依賴資料平面中的控制平面,尤其是在復原期間。
規則第 8 條
鬆散地耦合相依性,因此您的工作負載可以在可能的情況下正確運作,儘管依賴