如何評價阿里雲把SSD雲盤的IOPS提升到100萬？

提速50倍 阿里雲發布全新一代高性能企業級存儲家族www.199it.com

1月9日，阿里雲宣布推出全新一代塊存儲、極速型OSS、NAS Plus等高性能企業級存儲產品家族，並對分散式存儲引擎進行全面升級，性能比過去提升了最多50倍，給用戶帶來了從高速到高鐵的體驗。在相繼發布企業級雲伺服器、網路、資料庫、異構計算後，阿里雲已實現了在企業級服務市場的整體部署。

「除了容量、速度外，存儲正在向多樣性和普惠性發展」，阿里雲存儲產品總監許咼兢表示，線上線下存儲的邊界正在消失，阿里雲要做的是在任何地方、以任何形式向不同企業提供高效的存儲解決方案。

目前，阿里雲已在存儲領域完成高性能布局，包括塊存儲、對象存儲在內的雲上存儲家族，混合雲存儲陣列、混合雲容災的混合雲存儲服務以及高性能分散式專有存儲方案。

全新一代分散式存儲引擎 帶來恐怖的50倍性能提升

企業在雲端部署業務時，很多時候面臨的負載來自頻繁的存儲 I/O，存儲性能決定用戶在雲上的業務能否順利展開。

阿里雲此次宣布了全新一代分散式存儲引擎，在性能、可靠性、成本、自動化運維等維度進一步挖掘潛能，可在底層提供微秒級延遲和百億級IOPS，隨規模彈性增長可支撐的文件數量近乎無限。

基於全新一代分散式引擎，阿里雲推出了高性能企業級存儲產品家族，相比上一代整體IOPS性能提升50%，並新增ESSD雲盤、極速型OSS、NAS Plus等新品。以ESSD超高性能雲盤為例，可提供單盤高達100萬的隨機讀寫能力，相比SSD雲盤提升了50倍，是阿里雲迄今為止性能最強的企業級塊存儲服務，但售價不變，每GB每月僅需1元，可滿足雙11搶購、春晚紅包、大型網遊等對性能有極致要求的應用。

打破線上線下存儲邊界 無處不在的企業級高性能雲存儲

數據因為在線產生價值，這讓線上存儲與線下存儲邊界變得越來越模糊，過去傳統存儲也能獲得雲端的彈性計算能力和靈活的擴展能力。

據悉，阿里雲目前已形成了一整套涵蓋公共雲、混合雲、專有雲在內的全線企業級高性能存儲產品線，包括對象存儲OSS、塊存儲 Block Storage、共享文件存儲NAS、共享塊存儲、表格存儲、歸檔存儲以及混合雲存儲系列，並且提供在線和離線數據搬遷服務。

這些產品和服務不僅面向天生長在雲上的微博、芒果TV、OFO等互聯網客戶，對於天文、海洋、氣象、基因等領域的非互聯網企業來說，阿里雲也提供了高性能線下專有存儲解決方案mdash;mdash;NAS系列，可滿足TB級帶寬、大吞吐量需求，建立可線性擴展的雲上超算中心。

此前，阿里雲與國家天文台宣布合作，共同開展天文科學大數據研究，在迄今為止世界最大面積的深度圖像巡天課程中，僅用20天就完成了原本需要半年的圖像生成工作並對外提供可視化展示及服務。目前，國家天文台將3.5億顆恆星的數據存儲在阿里雲OSS上，用於計算、分析，並向公眾開放。

作為全程經歷者，感慨萬千，怒答一發。

發布會上已經展示了光鮮亮麗的性能數據，這裡我嘗試從另外一個角度來說下這一路走下來的痛並快樂著的艱辛歷程，說下團隊在鐵棒磨針過程中的若干細節。

舞動的橋

• 1940年11月7日，竣工才4個月的塔科馬海峽大橋在微風中大幅度舞動，橋上的汽車急速滑動，很快就戲劇性的垮塌。這件事故給建築工程行業造成極大的震驚，很違反直覺，很低的風速居然會吹垮一座鋼鐵建造的大橋，在此之前所有的橋樑專家都沒有意識到這個問題，事實上若干年後 橋樑結構學與空氣動力學得到極大發展，人類才徹底解決這個問題。在工程領域通常將這類事前缺少認知，只有發生後才能意識到的問題統稱為險惡性問題，這類問題殺傷力極大，對於pangu 這樣的分散式系統同樣會面臨這類險惡性問題，既然對問題都沒有認知，又防禦何談呢？陽光之下並無新事，我們從各種安全至關重要的行業中廣泛的學習，發現各個行業在面對這類問題時，已經有較為豐富的經驗了，同樣以橋樑為例，早於的塔科馬海峽大橋的金門大橋（1937年建成通車）已經巍然屹立了80多年，可謂飽經風霜，後人在分析其設計者留下的設計手稿時發現早期的設計者在面對未知世界時非常謙卑，他們知道有些問題他們搞不清楚，可能會有風險，所以他們做了充分的冗餘設計來抵禦這種未知的風險，通過充分的冗餘來斬斷可能形成的故障鏈。
• 其實存儲是一個高危行業，首先要保障的是不錯，不丟，可訪問，只有在這個前提下，極致的性能才有意義。不錯，不丟，可訪問，看起來平淡無奇，但實踐下來常有如履薄冰之感，因為分散式問題太過複雜，因為操作系統、硬體都不是絕對可靠的，因為代碼不可能絕對無bug,運維也不可能從不出錯。有太多險惡性問題，即使行業先行者AWS 先後在澳洲，北美 都出現過數據丟失和不可用。在pangu設計之初我們學習了上文中冗餘設計的做法，承認自己所知有限，在很多地方做了冗餘設計來抵禦未知風險，並且在長期的演進中不但強化這類冗餘設計，絕不為了性能或者其他的目標來做冗餘設計上的妥協。這些年來團隊兄弟們始終心存畏懼，鐵棒磨針，始終專註於提供穩定可靠高性能的存儲，天道酬勤，10年來我們做到了數據不錯，不丟，非常慶幸。下面我分享幾個我們的冗餘設計。

E2E的數據校驗

• 磁碟可能出錯，內存也會出現出現bit反轉，內核和應用程序更可能出錯，甚至我們遇到過某廠的一塊CPU在做某些特定運算時就會出錯，在這樣一堆不可靠的軟硬體環境下，要構建出一個穩定可靠的存儲平台（沒有哪個用戶能接受哪怕一個bit的錯誤），是非常困難的，一般的做法是端到端的逐層做數據校驗，pangu 很早就做了E2E 的數據校驗。但一次在一個長時間大壓力的測試環境上mysql 報數據錯，核對數據發現CRC和數據是匹配的，並沒有出錯，核對另外2份拷貝，發現另外兩份數據也是CRC自洽的，而且另外兩份完全一致，但與mysql讀取的這一份差異非常大。初步判定是mysql讀取的這一份數據出錯了，但這份錯誤的數據是CRC自洽的，這就非常奇怪了，如果是存儲介質出錯，不太可能還保持CRC自洽，在讀寫鏈路上查看了所有日誌，沒有找到任何異常。調查的同事反覆核對三份拷貝，說這一份看起來就不像是這個文件的數據。說者無心，聽者有意，另外一個同事想在哪種情況下會出現這樣的錯誤，由於我們的CRC和數據是邏輯空間上是相鄰的，會不會是這片數據其實不屬於當前文件，而是和另外一個文件搞串了？大膽假設，小心求證，全盤掃描後果然證實了猜想，A,B 兩個文件中間有一部分內容寫串了，詳細調查後確認是EXT4 文件系統的BUG，它在做空間管理的時候出錯，導致A文件的一個數據片寫入到文件B, 文件B中有一個數據片寫入到文件A中，由於寫入的流程一致，CRC又和數據放置在一起，導致CRC無法發現這個問題，確認問題後解決起來就很簡單了，要麼將CRC和數據分開放置，要麼在計算CRC的時候加上文件的一個特徵值。
• 有E2E的數據校驗是否就安全了呢？呵呵坑深不見底，硬體行業的人知道磁碟極小的概率發生靜默錯誤（讀出來的數據是錯誤的，但底層介面不報錯，磁碟本身也不報錯），如果三份拷貝很長時間都未被讀取，而在這個較長的時間窗口內，如果有三份拷貝所在的3塊盤都發生了靜默錯誤，用戶讀取數據時，存儲系統就會發現3份CRC校驗都不通過，儘管知道出差錯了，卻沒有任何辦法修復。為了降低這種情況發生的概率，我們會定期掃描冷數據，校驗其CRC。

壓縮檢驗

• 一天新來的同事問大家：「我們在做壓縮的時候，為啥壓縮完後，立刻又解壓縮一次，並且將解壓數據和原始數據再去比對一次？直接壓縮不就完了嗎？」，眾人笑而不語，他思考良久，也未能找到足夠的理由。團隊內老司機告訴他，壓縮本身是一個很複雜的東西，有些庫是第三方提供的，儘管我們會review代碼，有嚴格的引入測試，但沒人能保障其絕對正確，萬一壓縮出來的內容是錯的怎麼辦？CPU也可能存在一些偶發性的錯誤，如果壓縮時發生這類小概率的偶發性錯誤，該怎麼辦呢？但戶數據是絕對不能錯的，所以我們這裡採取防禦性編程，壓縮完後立即解壓，再和原始內容比對，確保數據不錯。

PAXOS

• 說到分散式存儲，很多人就言必稱PAXOS,RAFT，PAXOS儼然就成了救世主。PAXOS, RAFT 的確是好東西，但並不是所有的場景都適用。在一個分散式系統中，大家會認為在一個較小的時間窗口內同時發生2台機器failover是一個小概率事件，但隨著集群規模的擴大，集群數量的增多，最終小概率事件長期積累，就變成必然事件了，在quorum=3的時候，PAXOS 協議是無法處理double fail的，甚至無法自愈，需要緊急人為干預才能恢復。想想半夜收到告警，你能在幾分鐘能處理好用戶的IO HANG？ 適合的才是最好的，實踐是檢驗真理的唯一標準。

磁碟錯誤

• 對於做存儲的人來說，磁碟故障是司空見慣的事情了，本身有一套成熟的處理機制。但百密一疏，我們還是在這上面栽過跟頭，進程主動檢測到binary所在的系統盤故障，老司機當然知道此時不能再在該盤上發起任何IO 操作，日誌寫入到內存中，調用exit, 安靜的退出，不帶走一片雲彩即可。但進程居然無法退出，調用exit 無法退出！而此時其它線程還在繼續工作，在幹壞事。所有人都覺得匪夷所思，為啥主線程調用 exit, 進程未能退出，其他線程在長達幾分鐘內還在繼續幹壞事？團隊大牛反覆推演，不放過任何一個蛛絲馬跡，終於搞明白了，原來磁碟故障後，exit這段代碼本身並不在內存中，調用時會產生major fault, 中斷處理程序會嘗試從磁碟上load相應的代碼段，而磁碟已經故障了，load 被hang住，導致出現前面這些匪夷所思的怪事。

今天雲計算已經成為互聯網的基礎設施，隨著眾多電力，水務，醫療企業上雲，我們又成了這些基礎設施的基礎設施，任何一個黑天鵝都有可能帶來難以估量的影響。只有對這個未知的世界保持敬畏，保持謙卑，才能走得更遠。

在為何測試時性能吊炸天而上線卻慘不忍睹？一文中，冬瓜哥指出，不談時延的IOPS都是耍流氓。而阿里雲本次發布的ESSD在100萬IOPS情況下平均延遲500us，50萬IOPS情況下平均延遲100us。這個值已經超越了目前的SAN/全快閃記憶體廠商能夠提供的最佳值。

冬瓜哥有幸與阿里雲存儲的兩位資深研究員Jason（吳結生）和伯瑜進行了交流，也了解到了阿里雲存儲本次性能飆升背後的猛料。

1. 硬體升級。除了伺服器、SSD等基礎規格升級之外，這裡面最關鍵的其實是網路上的升級。目前阿里雲VM上的雲盤（本地盤）統一走的是乙太網訪問後端的盤古分散式存儲平台上提供的各種存儲資源。一百萬IOPS@4KB，對網路的帶寬耗費為40Gb/s，再加上開銷，需要至少50Gb的帶寬才能達到。阿里雲存儲引擎2.0採用了25Gb/s乙太網，提升了帶寬密度。另外，採用了全自研交換晶元和交換機，針對RDMA協議做了晶元級優化，能夠讓跨交換機端到端通信時延降低到2微秒（4KB+128B ack round robin時延）。

2. Luna通信庫框架。有了強力網路硬體的支撐，軟體的開銷會成為優化的重中之重。在固態存儲時代，傳統較長的I/O路徑已經嚴重拖累了I/O時延，對於NVMe SSD而言，由於NVMe協議棧原生已經為我們開鑿好了高並發的通路，那麼，降時延就是升IOPS的唯一途徑了。阿里雲存儲2.0引擎在後端採用了SPDK框架來與NVMe SSD交互，採用用戶態驅動，多隊列自適應Polling模式。在前端，採用私有的I/O協議+RDMA+用戶態驅動方式來轉發前端I/O請求到後端盤古系統上。這一整套的通信庫框架被稱為鯤鵬。SPDK是Intel搞的一套用戶態I/O棧，但是根據業界一些存儲廠商的反饋，其中坑很多，性能也有待優化。阿里雲研究員伯瑜指出，SPDK庫已經在阿里實施了2年多，對它已經是駕輕就熟，該踩的坑也基本踩完了，而且阿里雲應該是第一家將SPDK廣泛使用的。研究員吳結生提到，鯤鵬庫的誕生為阿里雲存儲的開發效率和性能這兩個矛盾點找到了一個很好的平衡。

3. 線程模型改進。阿里雲存儲2.0引擎採用了用戶態驅動，加co-routine協程，加run to completion模式。用戶態驅動可以避免每次發送I/O都必須經歷系統調用到內核來處理的性能損失。在用戶態上實現協程，把內核的線程調度開銷進一步降低，協程之間自主實現用戶態上下文切換，和自主調度切換，這一切內核根本感知不到，這樣可以在有限的線程運行時間片內全速的以非常低的切換開銷執行多個協程。再加上內核可感知的多個用戶線程並發充分利用處理器物理多核心，實現充分的並發。協程的另外一個關鍵點是其可以避免使用鎖，因為多個協程運行在單個核心上，全串列無並發，靠上層邏輯實現手動同步。另外，採用run to completion線程模型，避免I/O路徑上太多的非同步耦合點，後者會帶來較高的長尾效應，導致I/O時延不穩定。可參考冬瓜哥另一片文章：【冬瓜哥手繪】它保你上線性能也吊炸天！

4. 數據布局Append Only。對付隨機寫入的最好的辦法就是append only模式，將所有寫操作順序記錄寫入，然後修改指針，這一招對SSD屢試不爽，實際上SSD內部也是這麼做的。阿里雲存儲後台也採用這種方式。之前只對對象存儲OSS和表格存儲TableStore等做這種策略，阿里雲存儲2.0引擎下針對塊存儲也採用了該策略。

5.vhost-user架構。採用vhost-userI/O架構，bypass QEMU的virtio-blk架構，將IO dataplane從QEMU卸載下來，即IO請求的生命周期完全bypass QEMU。

6. 更細緻的分層和抽象。在後台盤古系統中的單機內部，做了更細緻的分層和抽象。在上層，針對不同的I/O屬性，提供了定製化的策略模塊，滿足不同的I/O Profile需求。

更多細節請參考鄙人公眾號「大話存儲」中對應的文章。