一、概述
2020年6月，阿里雲對象存儲 OSS 通過十年積累的技術紅利，將可用性 SLA（Service Level Agreement) 提升 10 倍，做到了全球第一的核心競爭力，是其他的雲廠家的 10～20 倍，如下圖所示。
其中， OSS 的標準型（同城冗餘）存儲，SLA 從 99.95% 提升到 99.995%，簡單理解就是如果 10萬 個請求中只要有 5 個請求返回服務端錯誤，OSS 將會賠付。
二、OSS 可用性 SLA 說明
2.1 常見的可用性指標（年故障時長）
業界對可用性的描述，通常採用年故障時長。比如，數據中心機房劃分為不同等級，如 T1～T4 機房，它們的可用性指標如下所示。
T1 機房：可用性 99.671%、年平均故障時間 28.8 小時
T2 機房：可用性 99.741%、年平均故障時間 22 小時
T3 機房：可用性 99.982%、年平均故障時間 1.6 小時
T4 機房：可用性 99.995%、年平均故障時間 0.4 小時
網絡服務的可用性，通常也會折算為不能提供服務的故障時間長度來衡量，比如典型的 5 個 9 可用性就表示年故障時長為 5 分鐘，如下表所示。
對於實例型雲服務，典型如阿里雲的 ECS，它提供了一臺計算實例，該實例的可用性直接與可用時間相關，所以它也是採用年故障時長來定義可用性。
2.2 對象存儲 OSS 可用性 SLA 指標
對象存儲是資源訪問型雲服務，它不提供實例而是 Serverless 化的 API 調用，按照“年故障時長”計算可用性是不合適的。所以，阿里雲對象存儲 OSS 選擇“失敗請求數：總請求數”的錯誤率嚴苛邏輯來計算可用性。
2.2.1 每5分鐘粒度計算錯誤率
每5分鐘錯誤率 = 每5分鐘失敗請求數/每5分鐘有效總請求數*100%
計算請求錯誤率時，將計算請求的時間範圍拉長，對雲服務有利。因為時間越長，總請求數越多，會導致錯誤率降低。為了更好的從客戶角度計算錯誤率，按照5分鐘的粒度來計算。高可用系統設計關鍵是冗餘，而 5 分鐘是業界典型的機器故障恢復時間，能夠快速修復機器，可以將降低系統的錯誤率。
2.2.2 基於服務週期內的5分鐘錯誤率計算可用性
服務可用性=（1-服務週期內∑每5分鐘錯誤率/服務週期內5分鐘總個數）*100%
對象存儲 OSS 按月收費，因此服務週期就是自然月。服務可用性，就是將服務週期內的每5分鐘錯誤率求和，然後除以服務週期內 5 分鐘總個數(按照自然月 30 天算，該值為 302460/5=8640)，然後用 1 減去平均錯誤率，就可得到該月的可用性。
根據此公式，如果每 5 分鐘錯誤率過高，將會導致可用性下降；因此，提升每 5 分鐘的請求成功率，將是提升可用性關鍵。
2.2.3 對比年故障時長和請求錯誤率模型
按照全年 26 分鐘故障為基礎，年故障時長模型可用性為99.995%。而 OSS 的請求錯誤率模型下，按每5分鐘錯誤率來算，26 分鐘至少有5個每5分鐘錯誤率為100%，其他的每5分鐘假設全部為0(沒有錯誤)，因此可用性最多為 1-5*100%/8640 = 1-0.058% = 99.942%，從而 OSS 的請求錯誤率模型更加嚴格。
2.2.4 OSS 可用性 SLA 承諾
基於上述可用性計算，用戶可以得到自然月內的實際可用性。按照 OSS 可用性 SLA 承諾，如果沒有達標，將進行賠付，真正做到“你敢用、我敢賠”，從而提升客戶業務的可用性。
2.3 雲廠商對象存儲可用性 SLA 對比分析
分析 AWS、AZURE、GCS、阿里雲、騰訊雲、華為雲等廠家的對象存儲可用性 SLA，，可以看出阿里雲對象存儲可用性 SLA 是其他廠家的 10～20 倍，而且採用最嚴苛的5分鐘粒度計算，保證客戶第一。其中，某傳統存儲轉向做公共雲的廠家，仍然採用傳統線下存儲的“可用時間方式”來計算可用性，確實還是延續原有的思路。
三、OSS 可用性體系建設
阿里雲對象存儲 OSS 是歷經十年研發的雲服務，始終把可用性的建設作為核心競爭力來構建，從而形成了如下的可用性體系。
3.1 本地冗餘和同城冗餘架構
OSS 提供了本地冗餘存儲（部署在一個 AZ）、同城冗餘（部署在三個 AZ）存儲類型，它們的邏輯架構相同，主要包含如下模塊：女媧一致性服務、盤古分佈式文件系統、OSS 元數據（有巢分佈式 KV 索引）、OSS 服務端、網絡負載均衡等。
同城冗餘存儲（3AZ）則是在物理架構上是提供機房級別的容災能力，將用戶數據副本分散到同城多個可用區。當出現火災、颱風、洪水、斷電、斷網等災難事件，導致某個機房不可用時，OSS 仍然可以提供強一致性的服務能力。故障切換過程用戶業務不中斷、數據不丟失，可以滿足關鍵業務系統對於 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）為 0 的強需求。同城冗餘存儲，可以提供 99.9999999999%（12個9）的數據設計可靠性以及99.995% 的服務設計可用性。
3.2 IDC 冗餘設計
要實現更高的可用性，就必須在物理層做好冗餘設計，包括如下的技術：
同城冗餘多 AZ的距離和時延設計。在公共雲部署時，會遵循阿里雲IDC與網絡架構設計規則及AZ選址標準，特別是要滿足 OSS 的多 AZ 設計要求時，會嚴格要求時延和距離。
供電、製冷冗餘。OSS 對象存儲是多區域部署的雲服務，幾乎每年都會遇到自然災害、供電異常、空調設備故障等問題，在數據中心建設時要做好雙路市電和柴油發電機備電的設計，以及連續製冷能力。
網絡冗餘。OSS 作為公共雲服務，既要提供外部的互聯網訪問、VPC網絡訪問，還要提供分佈式系統的內部網絡連接，它們都需要做好冗餘設計。
外部網絡。互聯網接入多運營商的BGP和靜態帶寬，實現公網訪問的冗餘。同時，VPC 網絡的接入則通過阿里雲網絡的冗餘。
內部網絡。OSS 是分佈式存儲，由多臺服務器組成，採用內部網絡將多臺服務器連通起來，通過數據中心的機櫃級交換機、機櫃間交換機、機房間交換機的分層設計實現冗餘，即使某臺網絡設備故障，系統仍然能夠正常工作。
服務器。OSS 採用貔貅服務器系列優化性價比，基於分佈式系統和軟件定義存儲的需求，硬件上採用通用服務器（commodity server），並提供冗餘的網絡接口，無需採用傳統存儲陣列雙控冗餘設計的定製硬件。
3.3 分佈式系統設計
3.3.1 女媧一致性服務
女媧是阿里雲飛天系統底層核心模塊之一，從2009年飛天建立起開始自主開發，女媧對外提供一致性，分佈式鎖，消息通知等服務。同業界類似功能的開源軟件（ZooKeeper、ETCD）相比，女媧在性能、可擴展性、和可運維性上有明顯的優勢。
女媧服務採用兩層架構，後端是一致性維護的功能模塊，前端是達到分流效果的前端機。
前端機通過 VIP 做負載均衡。主要實現兩個功能：第一點，負責維護眾多客戶端的長連接通信，從而保證客戶端請求能夠均衡到後端；第二點，向客戶端隱藏後端的切換過程，同時提供高效的消息通知功能。
後端由多個服務器組成 PAXOS 組，形成一致性協議核心。對客戶端提供的資源（文件，鎖等），在後端都有歸屬的 Paxos Group仲裁，它採用 PAXOS 分佈式一致性協議進行同步，保證資源的一致性和持久化。為了提供更好的擴展能力，後端提供了多個 Paxos Group。
因此，通過多 VIP 冗餘、前端機透明切換、冗餘的一致性仲裁 Paxos Group，實現故障時的快速切換，從而在一致性協調時提供高可用性。
3.3.2 盤古分佈式文件
盤古2.0是第二代自研開發的分佈式存儲系統，在高性能、大規模、低成本等方面深度挖掘了系統的極限能力，支持更豐富的接入形態，進一步提升了系統的部署運維自動化智能化能力，同時繼承了1.0在高可靠、高可用、數據強一致性等方面的積累優勢。
3.3.3 對象服務有巢分佈式KV元數據快速切換
有巢分佈式 KV 為 OSS 對象存儲提供分佈式 Key-Value 元數據功能，作為阿里雲最早研發的的 KV 系統，歷經多年 OSS 的業務打磨，它在大規模集群下有非常深厚的技術積累。2014 年實現了多實例冗餘的特性，把KV 分解為由多個副本成的分區組（partition group），該分區組通過一致性協議選舉出 Leader 節點對外提供服務，當 Leader 節點故障或出現網絡分區時，能夠快速選出新的 Leader 節點並接管該分區的服務，從而提升 OSS 元數據服務的可用性，如下圖所示。
3.3.4 對象服務QoS
OSS 服務層聚焦數據組織和功能實現，由於底層盤古和有巢的分佈式能力，OSS 服務層按照無狀態方式設計，從而故障時可以快速切換，提高可用性。但是，由於 OSS 是多租戶模型設計，做好 QoS 的監控和隔離，是保障租戶可用性的關鍵。
3.3.5 網絡負載均衡
OSS 要承接海量的訪問請求，因此接入層採用負載均衡，通過綁定VIP提供高可用服務，並且和 OSS 的前端機（FrontEnd）集群對接，任何模塊故障都能能夠快速切換，保證可用性。OSS 基於阿里雲網絡團隊的負載均衡技術，提供了大流量、高性能訪問能力。
3.4 安全防護
OSS 提供 HTTP/HTTPS 的數據訪問服務，會受到來自“互聯網和VPC網絡”的安全攻擊，典型為DDoS (Distribution Deny of Service)，安全攻擊防護是保障 OSS 可用性的重要工作。
安全攻擊的一個目的，就是讓 OSS 之上的業務受損失，讓整體的可用性降低。
安全攻擊的兩種方法，就是擁塞 OSS 有限的帶寬入口（擁塞帶寬）、耗盡 OSS 的計算資源（耗盡資源）。
安全攻擊的三類攻擊方式，針對擁塞帶寬的網絡流量型攻擊（L3/L4 DDoS），針對耗盡資源的4層CC攻擊（鏈接資源）、7層CC攻擊（應用資源）。
細化的攻擊分類，如下表所示。
3.5 智能運維
3.5.1 赤驥
赤驥是阿里雲存儲服務的管控平臺，面向開發、運維、運營等內部用戶，目前已經介入對象存儲、文件存儲、表格存儲、日誌服務和函數計算五大產品，提供實時數據監控、智能運維管理、秒級的響應報警、安全審計保障等功能，致力於用精準、高效、智能的管控系統為產品運行保駕護航。
為了更好的管控 OSS 可用性指標，赤驥從問題的發現、定位、恢復三個緯度，按照監控報警、分析診斷、問題解決分解設計，提高運維能力。同時，赤驥提供了月度 SLA 管理功能，監控月度 SLA 不達標名單以及不達標原因，從而支撐 SLA 的不斷優化。
3.5.2 OSS brain
OSS Brain 是智能運維平臺，它的目標和使命是用數據+算法來保障OSS穩定運行，賦能線上運維及運營。它通過分析線上數據，提供智能決策，包括機器隔離、線上主動預警、用戶畫像、異常檢測、資源調度、用戶隔離等。通過快速敏捷的智能運維、快速的隔離錯誤，從而提高可用性。
3.6 高可用解決方案
OSS 是區域級服務，區域故障將會導致服務不可用，為了提供更高的業務可用性，OSS 提供了異地多活架構的高可用解決方案，如下所示。
寫入時只寫主區域，開發便捷。利用 OSS 跨區域複製能力，將數據複製到備區域，從而備區域有全量的數據。
讀取時可根據地域就近讀取，降低延遲。由於寫入時只寫數據到主區域，數據是異步複製到備區域，所以用戶讀備區域數據時，可能數據還未複製完成，此時可通過 OSS 鏡像回源功能從主區域讀取數據。
從而，可在不同的區域級故障場景時，實現快速切換，提供容災秒級 RPO(Recovery Point Objective)，保證業務應用連續性。
備區域不可用，上層業務快速切換到另外 2 個區域，並將流量均分，業務能立即恢復，切換也非常方便。
主區域不可用，則選擇新的主區域(如選擇區域2)，並開通區域2到區域3的跨域複製，從而業務可以將寫請求切換到新的主區域，讀請求也切換到剩下的區域；同時，基於 OSS 的版本控制 和 業務無更新寫，實現了主區域故障切換的數據一致性。
3.7 管理機制
除了上述的各種技術保障外，還有如下的管理機制來提升可用性。
庫存管理。公共雲服務是重資產模式，需要自己管理供應鏈庫存，智能預測資源需求，按需提供服務是可用性的基本保證。
水位管理。對象存儲是雲存儲服務，監控容量水位、帶寬水位、QPS 等水位能力，進行動態的智能調度，可以優化系統的可用性。
穩定性文化。從開發、設計、測試、運維等環節制定穩定性制度，追求卓越的可用性能力。
雙十一錘鍊和百萬級用戶打磨。OSS 長期參與阿里集群雙十一業務支撐，在業務洪峰的不斷錘鍊下，持續淬鍊產品的架構、特性、穩定性。在阿里雲的公共雲服務體系下，有百萬級用戶的打磨，支撐各行各業的負載。經年累月的技術積累，總結了持續提升可用性的機制。
四、OSS 可用性未來工作
儘管OSS 將可用性 SLA 提升 10 倍，但是技術無止境，未來將在升級異常、超級熱點、高頻攻擊等場景下繼續優化可用性。
