一 概述
阿裡雲對象存儲 OSS 通過十年積累的技術紅利，長期在雙十一淘寶應用如絲般順滑體驗需求的打磨下，2020 年 6 月将可用性 SLA 提升 10 倍，其中 OSS 标準型（同城備援）存儲，SLA 從 99.95% 提升到 99.995%，簡單了解能支援 10 萬張圖檔最多隻有 5 個顯示卡，下一章有詳細解釋。
二 如何度量 OSS 可用性 SLA
要想掌握 OSS 可用性 SLA，可以通過梳理業界可用性的來龍去脈，來了解背後的技術。
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 對象存儲 OSS 可用性 SLA 采用更苛刻的度量
對象存儲是資源通路型雲服務，它不提供執行個體而是 Serverless 化的 API 調用，按照“年故障時長”計算可用性是不合适的。是以，阿裡雲對象存儲 OSS 選擇“失敗請求數：總請求數”的錯誤率嚴苛邏輯來計算可用性，如下是詳細的計算過程。
每 5 分鐘粒度計算錯誤率
每5分鐘錯誤率 = 每5分鐘失敗請求數/每5分鐘有效總請求數*100% 計算請求錯誤率時，将計算請求的時間範圍拉長，對雲服務有利。因為時間越長，總請求數越多，會導緻錯誤率降低。為了更好的從客戶角度計算錯誤率，按照 5 分鐘的粒度來計算。高可用系統設計關鍵是備援，而 5 分鐘是業界典型的機器故障恢複時間，能夠快速修複機器，可以将降低系統的錯誤率。
基于服務周期内的 5 分鐘錯誤率計算可用性
服務可用性 =（1-服務周期内∑每5分鐘錯誤率/服務周期内5分鐘總個數）*100% 對象存儲 OSS 按月收費，是以服務周期就是自然月。服務可用性，就是将服務周期内的每 5 分鐘錯誤率求和，然後除以服務周期内 5 分鐘總個數（按照自然月 30 天算，該值為 302460/5=8640），然後用 1 減去平均錯誤率，就可得到該月的可用性。
根據此公式，如果每 5 分鐘錯誤率過高，将會導緻可用性下降；是以，提升每 5 分鐘的請求成功率，将是提升可用性關鍵。
模型對比
按照全年 26 分鐘故障為基礎，年故障時長模型可用性為 99.995%。而 OSS 的請求錯誤率模型下，全年 26 分鐘平均到每月大約故障 2.16 分鐘，按每5分鐘錯誤率來算，如果請求在 2.16 分鐘内則全部失敗，按比例來說錯誤率為 (2.16/5)*100%，此時可用性為：
1-{(2.16/5)*100%}/8640=99.995% 可以看出，它和年故障市場模型的可用性相同，但 OSS 上主要是帶寬型應用、大請求居多，是以在故障的 2.16 分鐘前後的請求都會受影響，導緻可用性會稍微小于 99.995%，從某種意義上講 OSS 的請求錯誤率模型略微嚴格。
OSS 可用性 SLA 目标
基于上述計算模型，OSS 經過長期的技術打磨，可用性 SLA 提升到标準型存儲(本地備援存儲)為 99.99%，标準型存儲(同城備援存儲)為 99.995%。該目标比原有值提升了 10 倍，為此 OSS 構築了大量核心技術并形成體系，下一章将進行詳細解讀。
三 OSS 可用性體系建設
阿裡雲對象存儲 OSS 是曆經十年研發的雲服務，始終把可用性的建設作為核心競争力來建構，進而形成了如下的可用性體系。
整個體系從架構、IDC 建設、分布式系統、安全防護、管理機制等緯度展開，可用性的核心就是備援和容錯能力，同時要做好安全防護和管理工作。
1 本地備援和同城備援架構
OSS 提供了本地備援存儲（部署在一個 AZ）、同城備援（部署在三個 AZ）存儲類型，它們的邏輯架構相同，主要包含如下子產品：女娲一緻性服務、盤古分布式檔案系統、OSS 中繼資料（有巢分布式 KV 索引）、OSS 服務端、網絡負載均衡等。
同城備援存儲（3AZ）則是在實體架構上是提供機房級别的容災能力，将使用者資料副本分散到同城多個可用區。當出現火災、台風、洪水、斷電、斷網等災難事件，導緻某個機房不可用時，OSS 仍然可以提供強一緻性的服務能力。故障切換過程使用者業務不中斷、資料不丢失，可以滿足關鍵業務系統對于 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）為 0 的強需求。同城備援存儲，可以提供 99.9999999999%（12 個 9）的資料設計可靠性以及 99.995% 的服務設計可用性。
介紹了頂層架構的設計，接下來讨論 IDC 内的機房、供電、制冷、網絡、伺服器等備援設計，從硬體層介紹 OSS 高可用能力。
2 IDC 備援設計
要實作更高的可用性，就必須在實體層做好備援設計，包括如下的技術：
1）同城備援多 AZ(Available Zone) 的距離和時延設計。在公共雲部署時，會遵循阿裡雲 IDC 與網絡架構設計規則及 AZ 選址标準，特别是要滿足 OSS 的多 AZ 設計要求時，會嚴格要求時延和距離。
2）供電、制冷備援。OSS 對象存儲是多區域部署的雲服務，幾乎每年都會遇到自然災害、供電異常、空調裝置故障等問題，在資料中心建設時要做好雙路市電和柴油發電機備電的設計，以及連續制冷能力。
3）網絡備援。OSS 作為公共雲服務，既要提供外部的網際網路通路、VPC 網絡通路，還要提供分布式系統的内部網絡連接配接，它們都需要做好備援設計。
- 外部網絡。網際網路接入多營運商的 BGP 和靜态帶寬，實作公網通路的備援。同時，VPC 網絡的接入則通過阿裡雲網絡的備援。
- 内部網絡。OSS 是分布式存儲，由多台伺服器組成，采用内部網絡将多台伺服器連通起來，通過資料中心的機櫃級交換機、機櫃間交換機、機房間交換機的分層設計實作備援，即使某台網絡裝置故障，系統仍然能夠正常工作。
4）伺服器。OSS 采用貔貅伺服器系列優化成本效益，基于分布式系統和軟體定義存儲的需求，硬體上采用通用伺服器（commodity server），并提供備援的網絡接口，無需采用傳統存儲陣列雙控備援設計的定制硬體。
硬體的備援設計是 OSS 高可用的關鍵，但分布式系統軟體層的高可用設計更是核心，下一章節将重點介紹 OSS 的分布式備援核心設計。
3 分布式系統設計
OSS 的分布式系統核心備援設計，包含女娲一緻性服務、盤古分布式檔案系統、有巢分布式 KV、QoS 保障、網絡負載均衡設計等。
女娲一緻性服務
女娲是阿裡雲飛天系統底層核心子產品之一，從 2009 年飛天建立起開始自主開發，女娲對外提供一緻性，分布式鎖，消息通知等服務。同業界類似功能的開源軟體（ZooKeeper、ETCD）相比，女娲在性能、可擴充性、和可運維性上有明顯的優勢。
女娲服務采用兩層架構，後端是一緻性維護的功能子產品，前端是達到分流效果的前端機。
- 前端機通過 VIP 做負載均衡。主要實作兩個功能：第一點，負責維護衆多用戶端的長連接配接通信，進而保證用戶端請求能夠均衡到後端；第二點，向用戶端隐藏後端的切換過程，同時提供高效的消息通知功能。
- 後端由多個伺服器組成 PAXOS 組，形成一緻性協定核心。對用戶端提供的資源（檔案，鎖等），在後端都有歸屬的 Paxos Group仲裁，它采用 PAXOS 分布式一緻性協定進行同步，保證資源的一緻性和持久化。為了提供更好的擴充能力，後端提供了多個 Paxos Group。
是以，通過多 VIP 備援、前端機透明切換、備援的一緻性仲裁 Paxos Group，實作故障時的快速切換，進而在一緻性協調時提供高可用性。
盤古分布式檔案系統
盤古 2.0 是自主研發的第二代分布式存儲系統，在高性能、大規模、低成本等方面深度挖掘了系統的極限能力，支援更豐富的接入形态，進一步提升了系統的部署運維自動化智能化能力，同時繼承了 1.0 在高可靠、高可用、資料強一緻性等方面的積累優勢。
如上圖描述的架構所示，各層中繼資料（RootServer、NameSpaceServer、MetaServer）都提供了備援設計，故障時可以快速切換，對于資料（ChunkServer）來說通過 None-Stop-Write 特性解決伺服器、磁盤故障時的快速切換，進而在分布式存儲層提高可用性。
有巢分布式 KV(Key-Value) 中繼資料
OSS 采用自研的分布式 Key-Value 來儲存中繼資料，它建構在盤古分布式檔案系統之上，其大規模叢集曆經多年的業務打磨，有着非常深厚的技術積累。
有巢分布式 KV 實作了多執行個體備援的特性，把 KV 分解為由多個副本成的分區組（partition group），該分區組通過一緻性協定選舉出 Leader 節點對外提供服務，當 Leader 節點故障或出現網絡分區時，能夠快速選出新的 Leader 節點并接管該分區的服務，進而提升 OSS 中繼資料服務的可用性，如下圖所示。
對象服務 QoS
OSS 服務層聚焦資料組織和功能實作，由于底層盤古和有巢的分布式能力，OSS 服務層按照無狀态方式設計，進而故障時可以快速切換，提高可用性。但是，由于 OSS 是多租戶模型設計，做好 QoS 的監控和隔離，是保障租戶可用性的關鍵。
網絡負載均衡
OSS 要承接海量的通路請求，是以接入層采用負載均衡，通過綁定 VIP 提供高可用服務，并且和 OSS 的前端機（FrontEnd）叢集對接，任何子產品故障都能能夠快速切換，保證可用性。OSS 基于阿裡雲網絡團隊的負載均衡技術，提供了大流量、高性能通路能力。
4 安全防護
OSS 提供 HTTP/HTTPS 的資料通路服務，會受到來自“網際網路和VPC網絡”的安全攻擊，典型為 DDoS (Distribution Deny of Service)，安全攻擊防護是保障 OSS 可用性的重要工作。
- 安全攻擊的一個目的，就是讓 OSS 之上的業務受損失，讓整體的可用性降低。
- 安全攻擊的兩種方法，就是擁塞 OSS 有限的帶寬入口（擁塞帶寬）、耗盡 OSS 的計算資源（耗盡資源）。
- 安全攻擊的三類攻擊方式，針對擁塞帶寬的網絡流量型攻擊（L3/L4 DDoS），針對耗盡資源的 4 層 CC 攻擊（連結資源）、7 層 CC 攻擊（應用資源）。
細化的攻擊分類，如下表所示。
5 管理機制
除了上述的各種技術保障外，還有如下的管理機制來提升可用性。
- 庫存管理。公共雲服務是重資産模式，需要自己管理供應鍊庫存，智能預測資源需求，按需提供服務是可用性的基本保證。
- 水位管理。對象存儲是雲存儲服務，監控容量水位、帶寬水位、QPS 等水位能力，進行動态的智能排程，可以優化系統的可用性。
- 穩定性文化。從開發、設計、測試、運維等環節制定穩定性制度，追求卓越的可用性能力。
- 雙十一錘煉和百萬級使用者打磨。OSS 長期參與阿裡叢集雙十一業務支撐，在業務洪峰的不斷錘煉下，持續淬煉産品的架構、特性、穩定性。在阿裡雲的公共雲服務體系下，有百萬級使用者的打磨，支撐各行各業的負載。經年累月的技術積累，總結了持續提升可用性的機制。
四 OSS 可用性未來工作
盡管 OSS 将可用性 SLA 提升 10 倍，但是技術無止境，未來将在更新異常、超級熱點、高頻攻擊等場景下繼續優化可用性。