淺談分散式存儲系統Pangu2.0——它讓雙11運維變得智能起來

摘要： 12月13-14日，由雲棲社區與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背後的黑科技。本文是《省身：分散式存儲系統Pangu2.0在雙十一中的戰役》演講整理，主要講解了分散式存儲系統Pangu2.0在雙11一役中的表現，以及這一系統的架構，研發歷程，和在提升系統穩定、強化系統性能、壓縮用戶成本、以及擴大業務適配等方面所取得的優異成績。

12月13-14日，由雲棲社區與阿里巴巴技術協會共同主辦的《2017阿里巴巴雙11技術十二講》順利結束，集中為大家分享了2017雙11背後的黑科技。本文是《省身：分散式存儲系統Pangu2.0在雙十一中的戰役》演講整理，主要講解了分散式存儲系統Pangu2.0在雙11一役中的表現，以及這一系統的架構，研發歷程，和在提升系統穩定、強化系統性能、壓縮用戶成本、以及擴大業務適配等方面所取得的優異成績。

分享嘉賓：省身

阿里雲資深技術專家，2012年加入飛天Pangu團隊，主攻分散式存儲方向，推動了Pangu2.0在雙11期間的全面落地

這篇整理來自於阿里雲飛天八部Pangu團隊技術專家「省身」在2017阿里雙11在線技術峰會中的分享，該分享整體由三個部分構成

1.Pangu2.0在雙十一當天的表現

2.Pangu2.0的背景和架構 以及完善這一系統的歷程

3.詳細介紹Pangu2.0在穩定性，高性能，低成本和業務性上面的一些進展

實測業務支持，在雙十一中保持完善與穩定

既然把雙11作為一次對Pangu系統的戰役，那麼勝利的目標就是在業務支持方向達到最佳，事實上，Pangu2.0在雙11的業務支持主要由四個部分構成：

1.集團DB

2.中間件

3.列式資料庫Histore

4.對螞蟻金服支付業務的支持

那麼就首先從DB開始聊聊吧。根據下面的圖片顯示，雙十一當天的資料庫壓力存在明顯的峰值（即波峰與波谷），但同時可以看出，全天之內衡量I/O質量的時延Latency值卻極為平穩的保持在500上下，沒有明顯的波動，如果用一句話來概括I/O表現的情況，想必就應該是「如絲般順滑」，不存在驚喜，也不存在意外，且同樣沒有超出客戶們的預期，監控人員對著平穩的波動表也抓不到什麼特殊的數據——儘管這一天的UPS吞吐量波動堪稱驚人，但時延指標卻一直平穩。著充分的表明:系統的容量壓力還遠遠沒有達到上限，依舊可以對更大的UPS實現支持。

我們可以在PG-BS圖上看到全天的UPS情況和時延情況。上圖為將全部UPS平均到每台機器上的數據。很容易可以看出，UPS的峰值出現在上午十一時前後，這是因為在這一時間點，工作人員對業務進行了一些熱操作，導致此時的峰值一躍提升至平均值的十倍，但對應到下圖中的時延指標，卻只出現了不到十分之一水平的波動，全天讀寫表現出極為平穩的態勢，僅僅到雙十一當夜二時左右因為I/O SIZE的變化方才又一次帶來大致十分之一的波動。

接下來談談中間件。起初因為集群負載偏高，無論是存儲水位還是UPS水位都處於一個很高的水平，導致大家對此產生了一些擔心，但實際值班時，我們對中間件時延的檢測結果同樣遠小於預測，Latency的抖動幅度只有用戶預期的八分之一，曲線非常的漂亮。

Pangu2.0誕生的原因，歷史沿革以及相關架構

這裡首先對Pangu1.0的整體架構進行介紹：它是一款經典的分散式存儲架構，由幾個部分構成，上層是PanguMaster，下轄三台機器，負責解決存儲原數據，命名空間以及具體數據的放置策略等問題，下面的部分是具體的存儲節點，它的功能是確定數據具體放在哪台機器上，並在這一層對數據進行存儲，通常格式為64位。這是一個極為經典的架構，與業界的很多存儲系統都很類似，例如Google的GFS，Hadoop的HDFS等等。他們的宏觀架構都相差不多，具備著成熟的應用環境，完善的就近調度策略，其對線上業務的支持也已經持續了很長的時間。

推出Pangu2.0的原因

這是一個硬體和網路飛速發展的時代，最早做存儲系統的時候，主流的網路制式還是千兆網。而如今，雙25GB乃至100GB的網路已經逐步的投入使用。最早的存儲媒介HDD機械硬碟需要10毫秒的時延才能成功進行訪問，而現在NVME的盤時延則比之極低，十微秒之內就能完成一次寫入，硬體的時延從毫秒壓縮到微秒，使性能瓶頸的逐漸轉移到傳統的存儲軟體，傳統軟體無法適配新的硬體，令時延問題變得突出，必須進行革新來適配硬體的變化

可以舉這樣一個例子來方便說明——假設過去去美國一趟，飛機需要在空中飛行十個小時 ，中美海關各需要一小時的通關時間，旅程的總時長為12小時。但隨著技術的進步，某款超音速客機在一小時就能直接抵達，那麼整個旅程就變成了三小時，三分之二的通關時間就顯得冗長起來。類比分散式存儲系統：開始的時候，因為硬體的瓶頸，軟體響應時間的長短並不是突出的矛盾，但隨著硬體的提升，這一矛盾的重要性也會日益凸顯。我們能夠得知：軟體必須適應硬體的變化，這是創造良好用戶體驗的必要前提。

同時，近些年來，用戶上傳的數據一直在飛速的增長，分散式系統所覆蓋的文數件也從十億級躍升到了千億級，單純垂直方向的Scale-up的存儲架構已經難以滿足用戶數據的需要，我們更多的開始需要一個能夠水平擴展，不斷滿足千億乃至更高級別需求，能夠實現Scale-out模式的存儲架構

作為通用的存儲平台，Pangu系統一直在力求對更多的業務進行支持。完成多業務的的並行發展需要令模塊分層更加單元化，以適應不同使用者定製化的需求。Pangu1.0每次發布一個新版本都必須對每種不同業務需求進行綜合考量，不僅時間上難以協調，且隨著團隊的規模逐漸擴大，這樣一個單元和模塊化不夠細緻的架構也愈發的不適於一個大團隊的開發。亟需一個更加高效的架構，以更好的分層和更好的模塊化來滿足大團隊快速迭代開發的需要。

還有一點，隨著近年來專有雲，混合雲的快速發展，對存儲系統獨立輸出，輕量化輸出的需求也越來越強烈，Pangu1.0的輸出不夠輕量級，敏捷性也略顯不足，這個過程也同樣是需要加速處理的。

Pangu2.0的總體業務架構

接下來，我們來聊聊Pangu2.0的總體業務架構。它的最底層是物理硬體架構與Datacenter網路，其上則是Pangu的存儲系統，裡面包括存儲節點，分散式系統，存儲系統內部的上層輻射出支持的多個業務方向，例如Block FS，LogFil，DBFS以及 HDFS ，整個系統的最上層則是目前主要的業務形式，包括存儲服務、資料庫服務、和大數據處理等一眾分類。

詳細分析Pangu2.0的模塊劃分，則可以將其分為兩個部分，下層橙色的部門稱為PanguCore，即核心層，上層綠色部分則對應於各項業務的適配。PanguCore的最底端是一個單機存儲引擎，目的在於屏蔽左右硬體差異，保證為上層業務提供一致和介面相對穩定的內容，以此來解決基於硬體的高性能問題和新硬體的適配問題。Core內部的藍色部分下轄多個模塊，包括多副本協議、元數據管理數據放置策略、EC、壓縮、多種數據間的分層存儲，以及自研的分散式cache等。兩層架構的應用有效的克服了1.0版本的不足，使各個模塊能夠獨立發布，提高了敏捷性。模塊改革的耦合度低，團隊戰線布的非常寬，也更適合一個大團隊進行共同項目的開發。

解決核心訴求 做到用戶滿意

存儲系統的核心訴求無外乎幾點，重中之重的穩定性、性能儘可能高、成本儘可能低，運維難度同樣越低越好。在接下來的文段中，我們將針對這些用戶永恆的追求，來詳細的介紹Pangu2.0在這四個部分做到的一些成績。

穩定性：高可用

首先是在穩定性方面的成果。面向線上眾多的塊存儲集群，我們要在日常工作中頻繁的對其進行擴容、縮容、下線、機器維修、集群整體遷移、軟體版本發布和變更等各式各樣的操作。在自始至終的整個過程中，我們實現了全年零故障，完全保障了業務的穩定性格。

現在正在進行的 「系統盤雲化」工作也是一項良好的佐證，未來，我們的伺服器物理機將不再採購系統盤，而是直接通過協議導出做成雲盤，這同樣充分體現了我們對穩定性的掌控，一旦突發問題產生，我們的終極目標就是讓用戶需要意識不到存在穩定性波動的可能。實現這點需要內部極為複雜的技術手段和管理手段，以及反覆進行的嘗試。

我們的另一個成果在於使基礎設施完全消除了故障依賴，沒個數據三副本都分散在三個rack上，每個rack都是獨立的供電和網路單元，發生供電或交換機故障時不會影響全部數據，對用戶讀寫也不會產生影響。以及保持健康狀態，即對所有硬體進行自動化管理，在用戶感知前就能夠自動發現問題和解決問題，對故障硬體自行觸發汰換流程，實現無人為的有機循環。

說道穩定性，實現單機的一致性就是保持數據穩定不可或缺的一部分：日常使用中，數據和日誌同步落盤寫入一個存儲，必須保證二者一致來保證讀寫穩定，即數據寫透碟片後，必須進行掉電測試。

第一是進行端到端的數據校驗 ，消除靜默錯誤。每次數據寫入都要通過一個CRC來進行保證，不管硬碟，內存還是CPU網路出現錯誤，用戶在讀取數據的時候要能夠知道數據是錯的，絕對不能將錯誤的數據傳遞給用戶。

第二是快速副本補齊。在某些緊急情況下，我們需要進行對於三副本的數據複製，集群交換機故障或者掉電的出現都屬於這一範疇。這一過程非常精細，且具備嚴格的優先順序區分。發生硬體故障後必須先複製高優先順序的（例如三個副本只余其一）。在大範圍掉電條件下，先進行單副本chunk數的降低，隨後才進行單雙副本的共同複製。該過程中存在精準流控，能夠反覆權衡流量的使用，保證複製的同時前端用戶的I/O依舊維持在可用度很高的狀態，並採取並行複製的方法在半小時內完整恢復單台宕機的全部數據，從而儘可能的淡化影響。

前文中，我們講了用於維持穩定性的一些大體技術手段，而面對系統抗壓能力的測試，我們也同樣會採用非常嚴格的手段。從圖中可以看到，平均每台機器都在每秒上百個UPS的條件下各種自殺進程（包括但不限於cs、bs、同時殺兩台bm等）的failover 測試才敢於交付給用戶。這一套測試和管控成熟 無論下面的進程如何failover，上面的UPS始終處於一條直線上 波動極小。

除了自殺進程，rack掉電的模擬往往會顯得更加的極端，每個版本發布前我們都要進行rack掉電的模擬：直接關掉涵蓋48台機器的rack集群，並測試其恢復的過程，實際結果表明，掉電的機器能安全的將負載轉移到其它機器上，待掉電的rack恢復後再將負載轉移回來，全部掉電機器的功能都能在一分鐘之內恢復。整體過程對用戶使用上的衝擊很小。

還有另外有趣的一點，這比較像一道概率題：通常情況下，在一個集群的規模內，非常小的時間窗口內（例如一台機器重啟的時間內）兩台機器failover的概率應該是可以忽略不計的，但隨著樣本的容量增加，小概率事件長期積累就會必然發生，很短的時間窗口內兩台機器同時failover 的糟糕境況也會時有出現。如果一個客戶端同時寫入A、B、C這3台機器，但A和B都出現了failover，就會只剩下C的一份形成I/O HANG。解除的唯一方法就是進行數據複製，將C中的數據複製到D，形成至少兩份數據以確保其安全，但是在複製的幾秒鐘的時間內，這一I/O HANG無法解除，可能會嚴重的影響用戶業務。這一問題在Pangu2.0中得到了妥善的解決：我們直接假定double fail 常在，默認用Block Sever對A、B、C進行寫入，如果A和B同時出現錯誤，就直接切換文件，把數據寫到一個其它流上（例D、E、F），從而將用戶干擾下降到毫秒級別。

我們知道，在工程領域，黑天鵝事件的發生通常是無法避免的，永遠會有超出認知範圍之外的意外在前方等著我們。這種事情發生時，我們要考慮的內容就會變成怎樣在既定條件下將損失控制在一個最有限的範圍內。對此，我們針對Pangu系統的1.0版本進行了優化，將元數據管理劃分成兩個部分：即Namespace 和Meta Server。把原來三節點的元數據管理分成多組，離散的分擔到所有存儲節點上去，即使其中的一組發生完整故障，也只會影響一小部分用戶，可以根據內部的其它策略進行及時的遷移。確保無論任何一個組件發生故障， 整個系統依舊能維持在可用的狀態，並做到在最短時間內恢復，怎樣減少爆炸半徑，在極端事件發生的情況下保證系統柔性可用。

接下來將問題細化到具體單個存儲節點的failover。我們此前的調度是全局調度，它存在一定的缺陷：如果一台機器出現宕機，那麼這台機器上承載的全部I/O流都會受到影響，甚至會在極端情況影響所有的用戶。而如今，我們進行了一個分組關聯，將部分用戶和某個存儲節點進行鏈接，成功使機器錯誤的影響範圍縮小至最低，如果集群規模較大，影響用戶的比例就會變得極低。

技術手段的發揮離不開相關標準的制定，硬體和環境上的標準也是穩定性足以實現的重要部分。線上集群諸多，由於歷史原因的影響，各類硬體，網路，內核，和應用配置等信息的跨度都很發散，造成了隱形的危險：任何一個變化的影響都很難百分百的提前進行覆蓋和評估。對此，我們著力推行環境標準化，標準服務化， 一切內容都只有先遵循標準才能進行上線 ，從而真正把環境標準落到實處。

此外，改進穩定性的手段還有不少，比如，我們會組織兩個工程師團隊形成攻守同盟，

拋開經驗，發揮想像，藍軍的任務是在系統不同單元製造failover，例如磁碟，網路，內核等，紅軍進行防禦，並在接下來評估對錯誤系統和用戶的影響。通過這一內部競爭顯著提升了系統的穩定性。

針對運維操作的響應性，我們制定了一個「雙十」標準作為最後的兩道防線：任何時候收到告警，團隊都要在十分鐘內響應。且一周收到的告警數不得超出10條。在技術人員的長期堅持和推行下，這兩個標準都取得了成功。

高性能：對競品和自我的同時超越

先看一組客戶對於Pangu2.0性能的反饋。

1.DB: XDB+Pangu2.0 取得了超Aurora的4倍以上的TPS。後續會和Pangu2.0 在性能，成本，高可靠等領域深度合作，為用戶提供更好的DB。

2.中間件：鏡像加速項目每次鏡像push、pull時間從50多秒縮短至1秒內，一個月全集團走aone的發布可以節省數百人天。Pangu 2.0 性能和穩定性全面超越競品，今年合作磨合非常順利，明年大規模的存儲計算分離，「離在線」和「在離線」混部會大力推進。

3.分析型資料庫：pangu2.0 非常靠譜，相比同規格的物理盤，為分析型資料庫帶來至少10% 的性能提升，後面分析型資料庫的存儲會全部遷移到pangu2.0上。

4.ECS雲盤產品：性能大幅超越AWS最新的C5！存儲領域提前實現對AWS的技術超越。

下面是對Pangu2.0和AWSC5實際性能的表格對比，可以很直觀的看出，無論是單路讀時延、單路寫時延；還是單路讀99.9%時延 、單路寫99.9%時延，藍色的Pangu2.0都要明顯優於橙色的AWSC5，極限吞吐量更是超越了一個數量級。

這麼好的性能數據從哪兒來

首先，Pangu2.0擁有自己的單機存儲引擎Bypass OS kernel，它是一個基於SPDK的用戶態文件系統，區別於使用VFS、Block Layer 和drivers進行傳遞的傳統文件系統，Bypass OS kernel直接將文件返回NVME盤，使用Polling方式進行訪問來降低延遲，Data + meta直接一次落盤，整個過程中無需進行任何拷貝。

網路上，Pangu2.0不再使用基於內核的TCP，而是利用RMDA網路 Bypass掉內核，省略系統調用的過程。同樣使用Polling方式進行訪問，全過程零拷貝。

另外一件很有趣的事情就是在線程模型上的優化，我們將客戶端和服務端進行了一些配合， 客戶端的鏈接由指定線程處理，形成Run-Complete的線程模型，從I/O請求到業務完成全部在一個線程內轉完，沒有任何上下文切換，且時間可控、關鍵路徑無鎖、無數據拷貝。

我們還真正實現了I/OPS與雲盤空間的解耦，現有的雲盤最大IOPS值為20000，此前，如果用戶需要使用2萬I/OPS，則至少需要購買600GB空間才能實現。而Pangu2.0 徹底實現了I/OPS與空間的解耦，只需128GB的雲盤即可實現超百萬I/OPS，對I/OPS需求大，空間需求小的用戶尤為適用，避免了維度浪費。只要願意，多大的盤都能得到超高的I/OPS。

前面的文段中，我們綜合介紹了平均水平上Pangu2.0在高性能的方面舉措，但評價I/O水平的指標除了平均水平外還有長尾收斂，我們往往希望長尾收斂的越快越好。同樣，Pangu2.0在長尾指標上也做了不少的建設。

第一是讀長尾快速收斂，我們做了一個Backup Read的演算法來進行優化，載入Read CS1後，如果短時間內沒有返回值，那麼會在極短的時間內直接載入CS2 ，CS2無返回值則繼續讀CS3，只要有一個請求得到回復，我們就認為是響應成功的，就能在即使最壞的結果下也能把用戶的讀操作收斂到四倍的平均時間內，如圖可以看出，在百分率達到99.9之後，讀長尾的收斂效果極佳。

第二是寫長尾快速收斂——這裡採用2-3非同步的模式進行。對於一個需要寫入三份的文件， 通常情況下認定寫入兩份即為寫入成功，第三份可通過非同步化操作的方式進行補充。假設文件寫在A、B、C三台機器上，且其中一台真的發生了故障，那麼寫入A和B兩份成功後，首先將信息返回用戶，再對另外一份在客戶端中進行range的記錄 （描述第三份有那些數據沒有計入），再從後台向空置的C端進行推送，在這一條件下，即使系統中出現單機的抖動或故障，絕大多數用戶也能夠可以被系統過濾，從而可圈可點的降低時延指標。

此外，分散式系統中還有一個非常複雜並難以處理的問題：局部熱點。一般情況下，規模較大的分散式系統都有多個租戶同時使用，一部分節點會因為外界巨大的訪問量而形成熱點。例如圖中的三台機器，如果有一台變成熱點，前文中的快速讀寫可以讓用戶屏蔽掉這個問題，但如果情況再進一步，有兩個節點都變成熱點，讀取數據可能影響不大，但寫入的過程則會出現困難

這時，我們會引入一項多流技術。將因為形成熱點而速度下降的流廢棄，立刻切換到另外一個流里去。因為新出現的Datafile客觀全新，所以就不會存在這個問題，這一切換過程只需要一個RPC的時間，可以做到用戶基本無感知，如果問題出現在BS上，即BS所承載的I/O過量的話，就會在用戶中產生一個較高的時延。這時我們同樣會對BS進行切換，對用戶的I/O的影響依舊可以控制在很小的範圍內。

實際上，在很多維度中，基於雲的Pangu2.0已經對物理盤實現了超越，例如：

1.多流並行映射技術，使得雲盤的吞吐量可以水平擴展，吞吐量大幅超越物理盤。只受限於客戶端所在的網路帶寬。

2.空間上的水平擴展沒有限制， 雲盤可以做到PB級別的容量, 與最新的物理盤相比，有幾個數量級的優勢。

3.能夠通過一系列技術手段來優化長尾，做到長尾優於物理盤，物理盤的熱點無法通過切走來進行優化，雲盤讓這一點變得可能。

低成本：穩定高效之外，經濟依舊是特長

除了出色的穩定和優秀的性能之外，更低的成本也是Pangu2.0的一大特色，例如：

1.全面支持EC，從而能夠把經典的8+3從三份變成1.375份。

2.支持自適應壓縮 根據特定演算法篩選出能夠壓縮的文件，對其進行壓縮。

3.數據冷熱分離，冷數據存儲到廉價介質，熱數據存到高性能介質，形成資源的合理規劃。

4.管控水平拆分到所有的存儲節點，不需要獨立的管控機型。

5.雲盤跨集群，將單集群的空間利用率做到極致，充分發揮雲的優勢。

Pangu2.0的軟硬體一體化工作也一直在同步進行，我們與AIS合作，共同研發了USSOS – User Space Storage Operating System，並實現了很多之前所期待的目標：

1.建立一個統一的用戶態存儲軟體基礎平台

2.實現對新硬體的快速適配，任何硬體只要在USSOS層進行適配就能直接應用，且對從前的軟體和服務毫無影響，完全公開和透明。

3.提升I/O處理效率，發揮I/O極致性能

4.識別和冗餘硬體故障，簡化系統運維與管理，增強系統穩定性

5.實現存儲硬體的自主可控，降低供應鏈風險，降低成本，使用戶能夠選擇低成本的硬體，同時更激進的使用新的技術。

易運維:將使用的壓力同樣降到最低

1.高度的可運維性也是Pangu2.0不得不提的一個點，並在相當多的方面能夠得到體現：

2.所有存儲節點故障自愈，無需人工干預 提前檢測，自行報修，自動下線和複製技術 維修後自動重新上線

3.管控故障自動遷移替換 管控節點自動替換

4.運維高度自動化，ECS 線上人均可運維數百個集群，數萬台伺服器

5.在支持集團業務中，我們承擔所有存儲的運維工作，把麻煩留給自己，把便捷送給客戶。

文章的尾聲，就讓我們再次來回顧一下Pangu2.0在阿里雲內部所有支持的業務，這是一個穩定而無處不在的平台，它將阿里的集團業務、雲業務，螞蟻業務和對接人串聯在一起，我們完全可以這樣進行描述————名為Pangu2.0分散式存儲系統，切切實實的讓雙11運維變得智能了起來。