針對所有類型的服務,我們使用一組相同的工程原則來達到彈性與可用性,因為對於所有類型的服務來說,建置容錯、可擴展分散式系統的基本工程挑戰都相同。
為了實現復原能力和持續可用性,必須先瞭解,然後處理雲端規模系統中所有導致無法使用的原因 (雲端擴展系統中的效能和無法處理故障)。這類原因很多,因此我們根據原因的本質加以分類
傳統上,企業 IT 系統的可用性分析是將焦點放在硬體故障類別。對雲端系統來說,硬體故障是相對較不嚴重且已詳細探討的問題。因此現在要避免或降低大多數單點硬體故障的風險已相對簡單。例如,機架可以有雙重電源供電和關聯的電源分配器,同時許多元件都可以進行熱插拔。當然也有可能發生大規模的硬體故障和丟失,例如遭受自然災害。不過,我們的經驗及來自其他雲端供應商的公開檢討報告顯示,相對於其他導致無法使用的原因,整個資料中心的故障或遺失極為罕見。大量硬體故障仍然必須處理 (例如運用災害復原和其他機制),但它不算是主要的可用性問題。
無法使用雲端擴展系統的主要原因如下:
- 軟體錯誤
- 組態錯誤
- 人工操作員所犯的錯誤
注意:業界的經驗認為,以上三種人為錯誤顯然是造成無法使用的主要原因。雖然透過工具、自動化及訓練可以降低發生頻率,但也無法加以消除。因此必須在系統的架構、設計及導入中,視為主要考量並加以處理。
- 效能 (延遲或傳輸量) 因任何原因而產生無法接受的變異,包括下列各項:
- 多租用戶被「其他客戶干擾」(QoS 機制失靈)
- 持續進行有用的工作時,無法有效拒絕超載 (意外或惡意)
- 分散式超負荷執行、訊息風暴、重試風暴及其他突然出現的耗費資源互動方式
- 重新開機 (特別是多個系統同時重新開機) 後的冷休克 (空白快取)
- 調整系統規模 (例如重新分區) 時的額外負荷
- 無法限制上述任何問題的影響範圍 (影響客戶和系統的數目)
這些挑戰普遍存在,就像是雲端規模分散式系統的「物理定律」一樣。
針對上述每個類別,我們透過經實證的工程策略來處理問題。這些當中最重要的是:
- 架構與系統設計的原則
- 新的架構概念 (通常是因套用上述原則而產生)
- 服務工程程序
架構與系統設計的原則
這些原則當中許多早已存在,我們把焦點放在與抗逆力和可用性最相關的原則。
復原導向運算
為了處理操作員對局部影響的軟體錯誤和人為失誤,我們依照復原導向運算1 的原則處理。概要來說,這意謂我們不會保證永遠不會發生問題 (無法測試),而是將焦點放在以可測試的方式低調處理任何問題。具體來說,焦點會放在將平均復原時間 (MTTR) 縮到最短,這段時間包括平均偵測時間、平均診斷時間及平均降低風險時間。
我們的目標是迅速復原,讓人員不會因問題而感到不便。下列點有助於達成這個目標:
- 在程式碼中普遍使用宣告,以及在所有層次主動監控並發出警訊,可快速且自動偵測操作員發生錯誤的徵兆。
- 將功能封裝成許多鬆散耦合的個別精細隔離單位 (繫線、處理作業、纖維、狀態機器等);也就是說,它們並不直接共用可能損毀的記憶體。
- 偵測操作員發生錯誤的徵兆時,自動儘快重新啟動封閉的隔離單位。重新啟動是一種嘗試從任意故障情況復原的實用方法,因為它會嘗試重新建立已經過妥善測試的狀態,所以可以回復不變的項目。
- 如果精細隔離層次復原沒有發揮作用 (例如,宣告繼續在該層次過度頻繁地觸發而導致旋轉當機),便提升至下一個更大的單位 (處理作業、程式實際執行、主機、邏輯資料中心、呼叫人工操作員)。
- 建立機制來啟用「全系統還原」(包括所有持續性狀態和組態的版本控制),以快速識別並還原錯誤的確認。
將問題影響降到最低
為了處理影響較為廣泛的錯誤,我們會建立機制將任何問題的影響範圍縮減到最小。也就是說,我們的焦點放在將受任何問題影響的客戶、系統或資源數目降到最低,這些問題包括一些特別具挑戰性的問題,例如多租用戶被「其他客戶干擾」、提供的超載、處理能力降低,以及分散式超負荷執行。我們會透過使用各種隔離界限和變更管理做法 (請參閱下列各節) 來達到此目的。
由設計原則產生的架構概念
這些概念當中許多早已存在,我們把焦點放在限制影響範圍的概念。
深深刻劃在公用 API 的佈局概念:區域、可用性網域及容錯域
由於容錯域觀念相對較為新穎,我們將以更詳細的方式說明容錯域。
容錯域可用來限制系統進行主動變更時所發生問題的影響範圍,這類主動變更包括:部署、打補丁、虛擬機器管理程式重新啟動及實體維護。
系統可保證在指定的可用性網域中,任一時間點最多只會變更一個容錯域中的資源。如果在變更過程中發生問題,則該容錯域中的部分或全部資源可能會一時無法使用,但可用性網域中的其他容錯域則不受影響。每個可用性網域都至少包含三個容錯域,以便允許在單一可用性網域內,以高可用性方式代管法定型複寫系統 (例如 Oracle Data Guard)。
因此針對主要類別的可用性問題 (軟體錯誤、組態錯誤、操作員失誤,以及變更程序期間發生的效能問題),每個容錯域都可作為可用性網域內個別的邏輯資料中心。
容錯域也可以防止某些類型的局部硬體故障。容錯域的特性會以最大的實際程度,保證放在不同容錯域中的資源不會在可用性網域內共用任何潛在的單點硬體故障。例如,不同容錯域中的資源不會共用同一個「機架頂端式」網路交換器,因為這類交換器的標準設計缺少備援。
不過,容錯域對硬體問題或實體環境問題的防護能力僅止於本機層次。與可用性網域和區域對比之下,容錯域並未提供任何大規模的基礎架構實體隔離。在天然災害或全可用性網域基礎架構故障等罕見案例中,多個容錯域中的資源可能會同時受到影響。
我們內部服務使用容錯域的方式與客戶的使用方式相同。例如,區塊磁碟區、物件儲存及檔案儲存服務會將資料複本儲存在三個不同的容錯域。所有控制層和資料層的所有元件都由這三個容錯域 (或多重可用性網域區域、多個可用性網域) 代管。
服務單元
服務單元可用來限制發生問題 (甚至是系統未進行主動變更) 時的影響範圍。之所以會發生這類問題,是因為多租用戶雲端系統的工作負載可能隨時發生劇變,也因為任何大型分散式系統都可能隨時發生複雜的局部故障。這些案例可能觸發隱藏的細微錯誤或突然出現的效能問題。
服務單元也可以在系統進行主動變更時的某些罕見但具挑戰性的案例中,限制問題的影響範圍。其中一個經典的範例是,部署至個別容錯域雖顯示成功 (沒有任何錯誤或效能變更),但在第二個或最後一個容錯域更新之後,系統 (具有生產環境工作負載的完整雲端規模) 內的新互動立即造成效能問題。
請注意,使用服務單元是一個架構模式,並非 Oracle Cloud API 或 SDK 中明確指定的概念。任何多租用戶系統都可以使用此架構模式;它並不需要雲端平台的特殊支援。
服務單元的作用如下:
- 每個服務執行處理 (例如在特定區域中,或在可用性網域本機服務的特定可用性網域中) 都是由服務軟體堆疊的多個個別部署所組成。每個個別的部署稱為一個單元。每個單元都會儘可能由其自己的基礎架構代管。至少要讓單元不共用主機或 VM。
- 服務在每個可用性網域或區域中一開始可能只有少數幾個單元。隨著服務擴展規模以滿足增加的需求,將新增更多單元以維持任何問題影響範圍大小的限制。大型的熱門服務可能會有多個單元。換句話說,單元提供 n 對 m 的客戶工作負載多工處理,以便區隔代管環境 — 區隔資源隔離島。單元沒有像針對容錯域存在的明顯基數。(如先前提到的,容錯域基數的明顯選擇是每一可用性網域三個容錯域,這讓單一可用性網域以高可用性方式代管法定型複寫系統。)
- 每個客戶工作負載「自然單位」都會指定給特定的單元。「自然單位」的定義取決於特定服務的本質。例如,就我們的內部共用工作流程服務 (稍後將會說明) 而言,自然單位可能是「這個可用性網域或區域中用於特定控制層的所有工作負載」。
- 在每個單元群組的前面不是簡約的路由層,就是用於探索單元端點的 API。例如,串流處理/訊息傳遞系統具有 API,可探索特定主題的目前資料層端點,而內部描述資料存放區的每一單元則具有一個個別的端點。不過,其他單元型服務則為一個單一資料層端點和一個共用路由層。路由層是多個單元發生關聯性故障的潛在原因,但透過讓路由層維持極度簡單、可預測且高效能 (沒有任何耗費資源的作業),並為其佈建大量的空餘空間容量和精密的 QoS 配額與節流機制,即可降低這項風險。
- 服務擁有者可以視需要將工作負載從一個單元搬移至另一個單元。以下是一些範例案例:
- 透過搬移繁重的工作負載,有助於避免多租用戶被「其他客戶干擾」問題,讓單元的其他使用者不受影響。
- 協助從超載或電壓不足的情況 (可能是由分散式阻斷服務攻擊所造成) 復原。我們以配額和節流機制抵禦這類攻擊,但有時會發生邊緣案例,其中特定使用案例 (API、存取模式) 對服務而言,比配額或節流系統目前所理解的更為費力。單元提供一個短期降低風險的機制。
- 將關鍵工作負載分成不同的單元,以大幅降低發生關聯性故障的可能性。例如,就控制層的內部共用工作流程而言,「關鍵核心」控制層 (例如平台、運算、網路及區塊磁碟區) 皆個別被指定給不同的單元,因此與不使用單元或指定給相同單元的情況相比,故障關聯性大幅降低。
注意:這個使用單元的方式可讓客戶不太需要考量服務的內部相依性,即可建置具有復原能力的應用系統。考量相依性圖表仍然是一個很好的做法 (本文件稍後將會進一步說明),但去關聯性機制已經運作時,此做法的需求就大幅降低。
結果就是每個服務單元都是單一可用性網域或區域內另一種類型的「邏輯資料中心」(效能隔離和錯誤隔離的邏輯群組)。
總而言之,服務單元和容錯域以下列方式彼此互補:
- 容錯域可防止在系統進行主動變更時發生問題。
- 服務單元可在系統發生潛在嚴重問題時限制問題的影響範圍 (不論系統是否是進行主動變更)。
我們執行部署和打補丁時,會將容錯域與服務單元的特性結合成整合策略。
服務工程程序
由於測試及操作上的優異表現對雲端系統的可靠性至關重要,因此我們有大量的工程程序。以下是一些運用前一節所述概念的重要程序:
- 我們以遞增方式部署服務,每個步驟之間會仔細進行驗證,並在發生任何意外狀況時立即倒回。具體流程如下:
- 在每個可用性網域中,我們一次部署至一個服務單元。針對每個單元,我們一次部署至一個容錯域,直到完成該單元的所有容錯域為止。接著,我們會進展到該可用性網域中的下一個單元。
- 在每個部署步驟之後 (在每個容錯域和單元之後),我們會驗證變更是否如預期般運作,也就是不論是內部或外部,都沒有造成效能降低或任何錯誤。如果發生任何錯誤或意外狀況,我們就會立即倒回變更。我們非常注重倒回程序的準備與測試 (包括自動化測試),這些倒回程序包括會影響持續性狀態或綱要的變更。
- 基於這個原因,我們採用一次只對一個可用性網域進行部署的方式,將變更部署至每個區域。透過不同時修改客戶可能用於主要網站與災害復原網站的任何一組區域,部署至範圍中的所有區域。
- 我們會定期確認錯誤處理機制及其他風險降低措施如預期般運作,而不會讓問題大規模惡化。如果沒有這類測試,錯誤處理機制 (例如重試、損毀復原演算法,以及狀態機器重新組態設定演算法) 通常會有錯誤、太耗費資源或以意外方式進行互動,因而造成分散式超負荷執行或其他嚴重的效能問題。
- 我們會確認能夠快速且安全地倒回上一個已知的良好軟體和組態,包括先前所述的持續性狀態和綱要。