淺談分佈式存儲系統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運維變得智能了起來。