建置容錯雲端服務
資料中心和雲端服務管理有很大部分牽涉到根據不可靠組件來設計和維護可靠的服務。 下圖顯示新進員工部分訓練，且應該可供對大型資料中心定期經歷的大量 (多類型) 失敗有個概念。
圖 2：訓練簡報中顯示的可靠性問題
系統因系統內發生錯誤產生無效狀態而發生失敗。 系統一般會開發下列其中一個類型的錯誤：
- 暫時性錯誤：系統中的暫時性錯誤會隨著時間自行修正。
- 永久性錯誤：無法復原且通常需要更換資源的錯誤。
- 間歇性錯誤：系統定期發生的錯誤。
錯誤會降低系統功能的服務或效能，因而影響系統的可用性。 即使系統發生失敗，容錯系統也能執行其功能。 在雲端中，容錯系統通常被視為以一致方式提供服務，但停機時間比服務等級協定 (SLA) 所規定者低的一種系統。
為什麼容錯功能很重要？
因為大型任務關鍵性系統的失敗會導致所有相關單位大量金錢損失。 雲端運算系統的本質在於其有多層式架構。 因此，雲端資源某一層中錯誤可能會觸發其上其他層的失敗，或隱藏其下各層的存取權。
例如，系統任一硬體元件錯誤會影響在虛擬機器上使用發生錯誤資源其 SaaS (軟體即服務) 應用程式的正常執行。 系統任一層中錯誤都和各層級提供者間的 SLA 有直接關係。
主動式措施
服務提供者會採取數種措施，以特定方式設計系統，以避免已知問題或可預測的失敗。
分析與測試
對雲端資源執行負載與壓力測試，以了解失敗的可能原因，對確保服務的可用性至關重要。 分析這些計量有助於設計可成功承受預期負載，而不會出現任何無法預期行為的系統。
過度佈建
過度佈建是在指定時間內，將資源部署在超過一般資源預計使用量的磁碟區中。 在不一定能預測系統確切需求的情況下，過度佈建資源以處理未預期負載高峰是可接受的策略。
以電子商務平台為例，伺服器一整年的負載都是平均一致，但碰到假期就會出現迅速暴增的負載模式。 在這些高峰時段，建議根據高峰使用量的歷程記錄資料來佈建額外資源。 短時間內，一般不容易納入快速增加的流量。 如後面幾節所述，與動態調整建立關聯的時間成本，涉及許多在負載模式中偵測變更並佈建額外資源以容納新負載的耗時步驟。 這兩種步驟都需要時間。 此調整的時間延遲可能長到壓垮系統，最糟的情況是當機，最好的情況也會降低服務品質。
過度佈建也是用來對抗 DoS (阻斷服務) 或 DDoS (分散式 DoS) 攻擊的一種戰術，在這些攻擊手段中，攻擊者會利用擲回大量流量產生導致系統無法負荷的要求來使得系統失敗。 無論何種攻擊，系統都需要花一些時間偵測並採取修正措施。 雖然已分析這類要求模式，但系統已經受到攻擊，且必須能夠容納增加的流量，直到實作緩解策略為止。
複寫
您可使用額外的硬體和軟體元件來重複重要系統元件，以無訊息方式在部分系統中處理失敗，而不致造成整個系統失敗。 複寫有兩項基本策略：
- 主動複寫，所有複寫的資源會同時運作，且回應及處理所有要求。 這表示對於所有用戶端要求，所有資源都會收到相同的要求、所有資源都會回應相同的要求，且要求順序也維持跨所有資源的狀態。
- 被動複寫，只有主要單位會處理要求，次要單位只會維護狀態，並在主要單位失敗時接管。 用戶端只與主要資源連絡，這會將狀態變更轉送至所有次要資源。 被動複寫的缺點是，從主要執行個體切換到次要執行個體時，可能捨棄要求或降低 QoS。
另有一種混合式策略，稱為半主動式，其與主動策略極其相似。 差別在於只會向用戶端公開主要資源的輸出。 系統會隱藏並記錄次要資源的輸出，只要主要資源發生失敗，即立刻切換。 下圖顯示各複寫策略之間的差異。
圖 3：複寫策略
複寫時要考慮的一項重要因素是所用次要資源數量。 雖然根據系統的重要性會因應用程式而異，但有 3 個正式的複寫等級：
- N+1：這表示，需要 N 個節點才能正常運作的應用程式，基本上要多佈建一項資源以免失敗。
- 2N：在此等級上正常運作時，每個節點都要多佈建一個節點以免失敗。
- 2N+1：在此等級上正常運作時，每個節點都要多佈建一個節點，然後在節點總數外再多佈建一個節點以免失敗。
反應式措施
除預測措施外，系統也會採取反應式措施，在失敗發生時予以處理：
檢查與監視
系統會持續監視所有資源，以檢查是否有無法預期的行為或資源遺失。 根據監視資訊，修復或重新設定策略，旨在重新啟動資源或啟動新資源。 監視有助於識別系統中的錯誤。 造成服務無法使用的錯誤稱為當機錯誤，而那些導致系統中不規則/不正確行為的錯誤則稱為複雜錯誤。
有數種監視方法可用來檢查系統中的當機錯誤。 其中兩種方法為：
- Ping-echo：監視服務會要求每項資源的狀態，並指定回應時段。
- 活動訊號：每個執行個體都會依規律的間隔向監視服務傳送狀態，而不需要任何觸發。
監視複雜錯誤通常依賴所提供服務的屬性。 監視系統會檢查基本計量，例如延遲、CPU 使用量和記憶體使用量，並檢查預期值以查看服務品質是否降低。 此外，在每個重要服務執行點通常會保留應用程式特定的監督記錄，並定期分析以查看服務是否隨時都正常運作 (或系統中是否有插入的失敗)。
檢查點和重新啟動
雲端中的數個程式設計模型會實作檢查點策略，其中會在數個執行階段儲存狀態，以便能夠復原至最後儲存的檢查點。 在資料分析應用程式中，通常會有在數 TB 資料集上執行的長時間執行平行分散式工作，以便擷取資訊。 因為這些工作是在數個小型執行區塊中執行，所以程式執行中每個步驟都可將執行的整體狀態儲存為檢查點。 在個別節點無法完成其工作的失敗點，可從先前的檢查點重新開始執行。 識別要復原到的有效檢查點時，最大的挑戰是當平行處理序正在共用資訊時。 其中一個處理序發生失敗，可能會導致另一個處理序中發生串聯復原，因為在該處理序中所做的檢查點，可能是起因於失敗處理序所共用資料中的錯誤。 您將會在稍後課程模組中深入了解程式設計模型的容錯。
復原測試中的案例研究
雲端服務在組建時必須牢記備援和容錯，因為大型分散式系統的任何單一元件都無法保證 100% 可用性或執行時間。
所有失敗 (包括相同節點、機架、資料中心或區域重複部署中的相依性失敗) 都必須以正常方式處理，而不能影響整個系統。 測試系統處理嚴重失敗的能力很重要，因為有時候即使是幾秒鐘的停機或服務降低，都可能會導致數十萬元 (如果不是數百萬元) 的收入損失。
必須定期進行以實際流量測試失敗，讓系統得以強化，並可在發生非計劃性中斷時能夠加以處理。 有各種系統是為了測試復原而建立的。 其中一個這類測試套件，便是 Netflix 所組建的 Simian Army。
Simian Army 是由雲端中的服務 (稱為 Monkey) 所組成，用來產生各種不同的失敗、偵測異常狀況，以及測試系統是否能存活。 其目標是要讓雲端保持安全且高可用性。 在 Simian Army 中找到的部分 Monkey 包括：
- Chaos Monkey：一種工具，會隨機挑選生產執行個體，並停用它以確保雲端能度過常見的失敗類型，而不會影響任何客戶。 Netflix 對於 Chaos Monkey 的描述如下：「在資料中心 (或雲端區域) 中放開配備武器的野猴子，亂槍射擊執行個體，且啃咬纜線 -- 然後在這一切發生時我們繼續為客戶提供服務而不中斷」。這種使用詳細監視進行的測試，可公開系統中各種形式的弱點，且可根據結果來建立自動復原策略。
- Latency Monkey：此服務會在不同用戶端和伺服器的 RESTful 通訊產生延遲，模擬服務降低和停機。
- Doctor Monkey：此服務可尋找出現狀況不良行為 (例如 CPU 負載) 的執行個體，並將它們從服務中移除。 它可供服務擁有者有一些時間找出問題的原因，最後終止執行個體。
- Chaos Gorilla：此服務可模擬失去整個 AWS 可用性區域。 這是用來測試服務是否會在沒有使用者可見影響或手動介入的情況下，自動重新平衡其餘區域之間的功能。