雲棲號資訊：【點擊查看更多行業資訊】
在這裏您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
阿里妹導讀：對象存儲被廣泛應用於互聯網應用中，當我們打開手機觀看視頻、收聽音樂、分享圖片、瀏覽網頁、淘寶購物時，背後的數據基本都是存在對象存儲中。應用使用卡、打不開就和對象存儲的可用性 SLA 有關，SLA 越高，應用體驗越好。本文分享阿里雲在對象存儲 OSS(Open Storage Service) 的可用性 SLA (Service Level Agreement) 上的實踐和技術沉澱。
一 概述
阿里雲對象存儲 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 倍，但是技術無止境，未來將在升級異常、超級熱點、高頻攻擊等場景下繼續優化可用性。
【雲棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live立即加入社羣，與專家面對面，及時瞭解課程最新動態！
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK