Oracle Cloud Infrastructure Services and Platform 的抗逆力和持續可用常見問題

針對所有類型的服務，我們使用一組相同的工程原則來達到彈性與可用性，因為對於所有類型的服務來說，建置容錯、可擴展分散式系統的基本工程挑戰都相同。

為了實現復原能力和持續可用性，必須先瞭解，然後處理雲端規模系統中所有導致無法使用的原因 (雲端擴展系統中的效能和無法處理故障)。這類原因很多，因此我們根據原因的本質加以分類

傳統上，企業 IT 系統的可用性分析是將焦點放在硬體故障類別。對雲端系統來說，硬體故障是相對較不嚴重且已詳細探討的問題。因此現在要避免或降低大多數單點硬體故障的風險已相對簡單。例如，機架可以有雙重電源供電和關聯的電源分配器，同時許多元件都可以進行熱插拔。當然也有可能發生大規模的硬體故障和丟失，例如遭受自然災害。不過，我們的經驗及來自其他雲端供應商的公開檢討報告顯示，相對於其他導致無法使用的原因，整個資料中心的故障或遺失極為罕見。大量硬體故障仍然必須處理 (例如運用災害復原和其他機制)，但它不算是主要的可用性問題。

無法使用雲端擴展系統的主要原因如下：

• 軟體錯誤
• 組態錯誤
• 人工操作員所犯的錯誤
  注意：業界的經驗認為，以上三種人為錯誤顯然是造成無法使用的主要原因。雖然透過工具、自動化及訓練可以降低發生頻率，但也無法加以消除。因此必須在系統的架構、設計及導入中，視為主要考量並加以處理。
• 效能 (延遲或傳輸量) 因任何原因而產生無法接受的變異，包括下列各項：
  • 多租用戶被「其他客戶干擾」(QoS 機制失靈)
  • 持續進行有用的工作時，無法有效拒絕超載 (意外或惡意)
  • 分散式超負荷執行、訊息風暴、重試風暴及其他突然出現的耗費資源互動方式
  • 重新開機 (特別是多個系統同時重新開機) 後的冷休克 (空白快取)
  • 調整系統規模 (例如重新分區) 時的額外負荷
• 無法限制上述任何問題的影響範圍 (影響客戶和系統的數目)

這些挑戰普遍存在，就像是雲端規模分散式系統的「物理定律」一樣。

針對上述每個類別，我們透過經實證的工程策略來處理問題。這些當中最重要的是：

• 架構與系統設計的原則
• 新的架構概念 (通常是因套用上述原則而產生)
• 服務工程程序

架構與系統設計的原則

這些原則當中許多早已存在，我們把焦點放在與抗逆力和可用性最相關的原則。

復原導向運算

為了處理操作員對局部影響的軟體錯誤和人為失誤，我們依照復原導向運算¹ 的原則處理。概要來說，這意謂我們不會保證永遠不會發生問題 (無法測試)，而是將焦點放在以可測試的方式低調處理任何問題。具體來說，焦點會放在將平均復原時間 (MTTR) 縮到最短，這段時間包括平均偵測時間、平均診斷時間及平均降低風險時間。

我們的目標是迅速復原，讓人員不會因問題而感到不便。下列點有助於達成這個目標：

• 在程式碼中普遍使用宣告，以及在所有層次主動監控並發出警訊，可快速且自動偵測操作員發生錯誤的徵兆。
• 將功能封裝成許多鬆散耦合的個別精細隔離單位 (繫線、處理作業、纖維、狀態機器等)；也就是說，它們並不直接共用可能損毀的記憶體。
• 偵測操作員發生錯誤的徵兆時，自動儘快重新啟動封閉的隔離單位。重新啟動是一種嘗試從任意故障情況復原的實用方法，因為它會嘗試重新建立已經過妥善測試的狀態，所以可以回復不變的項目。
• 如果精細隔離層次復原沒有發揮作用 (例如，宣告繼續在該層次過度頻繁地觸發而導致旋轉當機)，便提升至下一個更大的單位 (處理作業、程式實際執行、主機、邏輯資料中心、呼叫人工操作員)。
• 建立機制來啟用「全系統還原」(包括所有持續性狀態和組態的版本控制)，以快速識別並還原錯誤的確認。

將問題影響降到最低

為了處理影響較為廣泛的錯誤，我們會建立機制將任何問題的影響範圍縮減到最小。也就是說，我們的焦點放在將受任何問題影響的客戶、系統或資源數目降到最低，這些問題包括一些特別具挑戰性的問題，例如多租用戶被「其他客戶干擾」、提供的超載、處理能力降低，以及分散式超負荷執行。我們會透過使用各種隔離界限和變更管理做法 (請參閱下列各節) 來達到此目的。

由設計原則產生的架構概念

這些概念當中許多早已存在，我們把焦點放在限制影響範圍的概念。

深深刻劃在公用 API 的佈局概念：區域、可用性網域及容錯域

由於容錯域觀念相對較為新穎，我們將以更詳細的方式說明容錯域。

容錯域可用來限制系統進行主動變更時所發生問題的影響範圍，這類主動變更包括：部署、打補丁、虛擬機器管理程式重新啟動及實體維護。

系統可保證在指定的可用性網域中，任一時間點最多只會變更一個容錯域中的資源。如果在變更過程中發生問題，則該容錯域中的部分或全部資源可能會一時無法使用，但可用性網域中的其他容錯域則不受影響。每個可用性網域都至少包含三個容錯域，以便允許在單一可用性網域內，以高可用性方式代管法定型複寫系統 (例如 Oracle Data Guard)。

因此針對主要類別的可用性問題 (軟體錯誤、組態錯誤、操作員失誤，以及變更程序期間發生的效能問題)，每個容錯域都可作為可用性網域內個別的邏輯資料中心。

容錯域也可以防止某些類型的局部硬體故障。容錯域的特性會以最大的實際程度，保證放在不同容錯域中的資源不會在可用性網域內共用任何潛在的單點硬體故障。例如，不同容錯域中的資源不會共用同一個「機架頂端式」網路交換器，因為這類交換器的標準設計缺少備援。

不過，容錯域對硬體問題或實體環境問題的防護能力僅止於本機層次。與可用性網域和區域對比之下，容錯域並未提供任何大規模的基礎架構實體隔離。在天然災害或全可用性網域基礎架構故障等罕見案例中，多個容錯域中的資源可能會同時受到影響。

我們內部服務使用容錯域的方式與客戶的使用方式相同。例如，區塊磁碟區、物件儲存及檔案儲存服務會將資料複本儲存在三個不同的容錯域。所有控制層和資料層的所有元件都由這三個容錯域 (或多重可用性網域區域、多個可用性網域) 代管。

服務單元

服務單元可用來限制發生問題 (甚至是系統未進行主動變更) 時的影響範圍。之所以會發生這類問題，是因為多租用戶雲端系統的工作負載可能隨時發生劇變，也因為任何大型分散式系統都可能隨時發生複雜的局部故障。這些案例可能觸發隱藏的細微錯誤或突然出現的效能問題。

服務單元也可以在系統進行主動變更時的某些罕見但具挑戰性的案例中，限制問題的影響範圍。其中一個經典的範例是，部署至個別容錯域雖顯示成功 (沒有任何錯誤或效能變更)，但在第二個或最後一個容錯域更新之後，系統 (具有生產環境工作負載的完整雲端規模) 內的新互動立即造成效能問題。

請注意，使用服務單元是一個架構模式，並非 Oracle Cloud API 或 SDK 中明確指定的概念。任何多租用戶系統都可以使用此架構模式；它並不需要雲端平台的特殊支援。

服務單元的作用如下：

• 每個服務執行處理 (例如在特定區域中，或在可用性網域本機服務的特定可用性網域中) 都是由服務軟體堆疊的多個個別部署所組成。每個個別的部署稱為一個單元。每個單元都會儘可能由其自己的基礎架構代管。至少要讓單元不共用主機或 VM。
• 服務在每個可用性網域或區域中一開始可能只有少數幾個單元。隨著服務擴展規模以滿足增加的需求，將新增更多單元以維持任何問題影響範圍大小的限制。大型的熱門服務可能會有多個單元。換句話說，單元提供 n 對 m 的客戶工作負載多工處理，以便區隔代管環境 — 區隔資源隔離島。單元沒有像針對容錯域存在的明顯基數。(如先前提到的，容錯域基數的明顯選擇是每一可用性網域三個容錯域，這讓單一可用性網域以高可用性方式代管法定型複寫系統。)
• 每個客戶工作負載「自然單位」都會指定給特定的單元。「自然單位」的定義取決於特定服務的本質。例如，就我們的內部共用工作流程服務 (稍後將會說明) 而言，自然單位可能是「這個可用性網域或區域中用於特定控制層的所有工作負載」。
• 在每個單元群組的前面不是簡約的路由層，就是用於探索單元端點的 API。例如，串流處理/訊息傳遞系統具有 API，可探索特定主題的目前資料層端點，而內部描述資料存放區的每一單元則具有一個個別的端點。不過，其他單元型服務則為一個單一資料層端點和一個共用路由層。路由層是多個單元發生關聯性故障的潛在原因，但透過讓路由層維持極度簡單、可預測且高效能 (沒有任何耗費資源的作業)，並為其佈建大量的空餘空間容量和精密的 QoS 配額與節流機制，即可降低這項風險。
• 服務擁有者可以視需要將工作負載從一個單元搬移至另一個單元。以下是一些範例案例：
  • 透過搬移繁重的工作負載，有助於避免多租用戶被「其他客戶干擾」問題，讓單元的其他使用者不受影響。
  • 協助從超載或電壓不足的情況 (可能是由分散式阻斷服務攻擊所造成) 復原。我們以配額和節流機制抵禦這類攻擊，但有時會發生邊緣案例，其中特定使用案例 (API、存取模式) 對服務而言，比配額或節流系統目前所理解的更為費力。單元提供一個短期降低風險的機制。
  • 將關鍵工作負載分成不同的單元，以大幅降低發生關聯性故障的可能性。例如，就控制層的內部共用工作流程而言，「關鍵核心」控制層 (例如平台、運算、網路及區塊磁碟區) 皆個別被指定給不同的單元，因此與不使用單元或指定給相同單元的情況相比，故障關聯性大幅降低。
    注意：這個使用單元的方式可讓客戶不太需要考量服務的內部相依性，即可建置具有復原能力的應用系統。考量相依性圖表仍然是一個很好的做法 (本文件稍後將會進一步說明)，但去關聯性機制已經運作時，此做法的需求就大幅降低。

結果就是每個服務單元都是單一可用性網域或區域內另一種類型的「邏輯資料中心」(效能隔離和錯誤隔離的邏輯群組)。

總而言之，服務單元和容錯域以下列方式彼此互補：

• 容錯域可防止在系統進行主動變更時發生問題。
• 服務單元可在系統發生潛在嚴重問題時限制問題的影響範圍 (不論系統是否是進行主動變更)。

我們執行部署和打補丁時，會將容錯域與服務單元的特性結合成整合策略。

服務工程程序

由於測試及操作上的優異表現對雲端系統的可靠性至關重要，因此我們有大量的工程程序。以下是一些運用前一節所述概念的重要程序：

• 我們以遞增方式部署服務，每個步驟之間會仔細進行驗證，並在發生任何意外狀況時立即倒回。具體流程如下：
  • 在每個可用性網域中，我們一次部署至一個服務單元。針對每個單元，我們一次部署至一個容錯域，直到完成該單元的所有容錯域為止。接著，我們會進展到該可用性網域中的下一個單元。
  • 在每個部署步驟之後 (在每個容錯域和單元之後)，我們會驗證變更是否如預期般運作，也就是不論是內部或外部，都沒有造成效能降低或任何錯誤。如果發生任何錯誤或意外狀況，我們就會立即倒回變更。我們非常注重倒回程序的準備與測試 (包括自動化測試)，這些倒回程序包括會影響持續性狀態或綱要的變更。
  • 基於這個原因，我們採用一次只對一個可用性網域進行部署的方式，將變更部署至每個區域。透過不同時修改客戶可能用於主要網站與災害復原網站的任何一組區域，部署至範圍中的所有區域。
• 我們會定期確認錯誤處理機制及其他風險降低措施如預期般運作，而不會讓問題大規模惡化。如果沒有這類測試，錯誤處理機制 (例如重試、損毀復原演算法，以及狀態機器重新組態設定演算法) 通常會有錯誤、太耗費資源或以意外方式進行互動，因而造成分散式超負荷執行或其他嚴重的效能問題。
• 我們會確認能夠快速且安全地倒回上一個已知的良好軟體和組態，包括先前所述的持續性狀態和綱要。

是。在每個區域中，所有可用性網域都提供一組相同的服務。

在單一可用性網域區域中，客戶可以使用容錯域 (在群組間採用去關聯性故障模式的邏輯群組) 實現個別「邏輯資料中心」的絕大多數特性。客戶也可以使用多個區域來進行災害復原 (DR)。

在多重可用性網域區域中，客戶可以透過相同的方式運用容錯域。客戶也可以透過可用性網域本機服務、可用性網域間容錯移轉功能 (例如搭配 Data Guard 的 DBaaS) 及區域服務 (物件儲存、串流處理) 的組合，實現更高層次「邏輯資料中心」(可用性網域) 的完整高可用性。最後，客戶還可以使用多個區域來進行復原。

在所有情況下，客戶都可以使用服務單元的概念進一步實行隔離，甚至面對最嚴重的問題 (例如分散式超負荷執行) 也可以這麼做。

我們透過容錯域、服務單元及增量部署與驗證操作程序來達到此目的。請參閱本文件前面的討論。

是。所有類別的服務都會跨多個邏輯資料中心部署，隔開錯誤隔離與效能隔離邏輯群組，以提供抗逆力和持續可用性。

如同本文件其他地方討論的內容，在單一可用性網域區域中，我們提供容錯域作為「多個邏輯資料中心」的機制。

在多重可用性網域區域中，我們提供的服務和功能提供甚至更高層次的同步複寫資料實體持久性 (由於區域中可用性網域之間的距離，因此可提供適中的效能和成本，以及光速般的速度)。

我們並未提供跨區域的自動高可用性或容錯移轉機制，因為這會在區域之間建立緊密耦合關係，導致多個區域可能同時發生問題的風險。我們改為在區域之間啟用各種形式的非同步複寫，並提供不斷擴增的清單功能 (例如非同步複製與備份)，以實現跨區域災害復原。

這是一個複雜的問題，因此為了釐清，我們再以幾個不同方式重新敘述：

• 如果客戶想要使用兩個 Oracle 服務 (服務 A 和服務 B)，並且想要建置能夠在其中一項服務失敗時復原的應用系統，客戶是否需要知道服務 A 是否依存於服務 B？內部相依性是否會導致嚴重的關聯性故障？如果是，則客戶需要知道這類內部相依性，才能在應用系統層次建置自己的抗逆力機制時，決定要對服務 A 和服務 B 做哪些其他利用；或者，是否要改為引進不相關的服務 C 進行這些額外的案例。
• 若 Oracle 服務發生任何關聯性故障，什麼是客戶的最佳防禦方式？

答案分為兩個部分。

架構原則

我們的架構原則可大幅降低各個相依服務的關聯性故障。在某些情況下，此技術會降低關聯性故障的發生率，若從滿足可用性服務等級協議 (SLA) 的角度來看，降低到可以忽略的程度。

特別是，如本文件先前所述，我們使用服務單元。單元可協助處理此問題，因為如果內部服務 A 受到其中一個相依項目服務 B 的問題影響，則服務 B 的問題非常可能被侷限在一個單元內。其他使用服務 B 的更高層次服務 (以及客戶自己的應用系統) 可以使用其他未受影響的單元。這個可能性論點會因單元數目而異，單元數目是會變更 (增加) 的隱藏內部參數，因此除了服務 A 和服務 B 的獨立服務 SLA 之外，並不提供任何量化或保證。但實際上，這可以大幅去除服務間的故障關聯性。

我們的許多共用內部服務 (例如控制層的工作流程和描述資料服務，以及串流處理/訊息傳遞服務) 都使用服務單元，去除中斷情況關聯性，供上游服務加以運用。

相依性

以下是概要指引，因為服務的詳細導入與詳細資訊可能不時會發生變更。但針對運算、儲存、網路及認證/授權的主要觀點，我們會指出下列相依性。

就控制層而言，常見的相依性如下：

• 認證和授權的身分識別/平台資料層
• 稽核追蹤服務
• 提供諸如工作流程、描述資料儲存及日誌記錄的內部服務
• 各種類型的負載平衡器

有些控制層明顯具有服務特定相依性。例如，啟動裸機或 VM 執行處理時，運算控制層會取決於：

• 物件儲存 (用以擷取指定的作業系統映像檔)
• 區塊磁碟區控制層 (用於佈建和連附開機磁碟區)
• 網路控制層 (用於佈建和連附 VNIC)

針對核心服務資料層，一般原則是每個資料層皆刻意設計成具有最小相依性，以便實現高可用性、快速診斷及快速復原。該原則的結果如下：

• 獨立的網路資料層。
• 獨立的區塊磁碟區資料層。
• 運算裸機和 VM 執行處理依存於區塊磁碟區資料層 (用於開機磁碟區) 和網路資料層。
• 物件儲存資料層依存於身分識別/平台資料層，用於認證和授權 (因為業界的期望)。物件儲存資料層不依存於區塊磁碟區或檔案儲存。
• 所有支援備份和回復的服務都依存於物件儲存資料層，以運用該功能。

針對 IaaS 資料層，一般原則是只依存於核心或更低層次的資料層 (為了避免循環相依性)。

• 資料庫多節點 RAC 依存於網路資料層和區塊磁碟區資料層。
• Kubernetes 的容器引擎明顯依存於 Kubernetes 及其可轉移相依性 (例如 etcd) 和網路資料層。
• 所有備份和回復支援都依存於物件儲存資料層。

是，Oracle Cloud Infrastructure 服務會封存為獨立區域，讓 Oracle Cloud Infrastructure 區域中的服務即使與其他 Oracle Cloud Infrastructure 區域和 (或) 全球控制層隔離，仍可繼續運作。即使區域被隔離，資料層與控制層功能 (包括服務 API 端點) 仍可繼續使用。

許多 Oracle Cloud Infrastructure 服務都提供跨區域功能，例如 Oracle Cloud Infrastructure Object Storage 提供的跨區域物件複製功能。Oracle Cloud Infrastructure 中的跨區域功能一律會封存為核心服務的一層，讓區域隔離不會影響核心服務，即使會影響跨區域功能。舉例來說，Oracle Cloud Infrastructure 物件存放區跨區域複製功能會封存為物件存放區服務上的一層，因此區域的隔離可能會影響相關的跨區域複製功能，但不會影響區域中的核心物件儲存服務。

是，Oracle Cloud Infrastructure 服務經過封存，即使與對應的區域控制層隔離，每個邏輯資料中心中的資料層功能也會持續運作。舉例來說，邏輯資料中心中的 Oracle Cloud Infrastructure 運算執行處理將繼續與連附的區塊磁碟區及關聯的虛擬網路功能搭配運作，即使資料中心與運算、區塊儲存、VCN 和 (或) 身分識別與存取管理的控制層功能隔離。

是。Oracle Cloud Infrastructure 透過多個商業區域中的備援提供者連線至網際網路。這些連線使用 BGP (邊界閘道協定)。