933
存儲--盤古，阿裏雲飛天分布式存儲係統設計深度解析
本文依據盤古團隊的吳洋分享了《盤古：飛天分布式存儲係統實踐》視頻整理而成。
他主要從以下三個方麵進行了分享：盤古是什麼？盤古是用來解決什麼問題的？盤古是怎麼解決問題的？他主要介紹了盤古的分布式係統架構和設計理念。
上圖列舉了目前主流的雲計算廠商，我們發現一個很有趣的事情：所有雲計算廠商都是“富二代”，它們的分布式存儲技術全部采用自研技術，而沒有用大家耳熟能詳的開源分布式係統。
上圖介紹了盤古的底層存儲平台，其承擔承上啟下的作用。盤古作為分布式存儲係統，主要提供兩種類型的接口：Append Only接口，Random Access接口。
- 4%磁盤年損壞率，1%%機器日宕機率
- Raid卡崩潰、電容充放電導致write back模式變成write through
- 網絡分割、交換機丟包、升級重啟、光纖損壞帶寬降低90%、兩地機房路由錯誤
- 機架斷電、整個機房掉電
- 網卡TCP校驗出錯，磁盤訪問數據校驗出錯
- NTP時間漂移、內核IO線程D狀態、dirty page cache無法寫回
- 係統熱點無時不在，瞬時轉移
- 程序缺陷導致資源泄露、創建大量文件、訪問髒數據
- 誤操作：誤刪數據、拔錯磁盤、沒有清理測試機器環境上線……
從上圖可以看到，作為統一存儲，要支持虛擬機中的塊存儲，對象存儲，表格存儲，文件存儲，離線大數據處理，大數據分析等諸多業務，其麵臨的挑戰是很大的，甚至有些挑戰是自相矛盾的。
盤古在係統設計的時候進行了一些取舍。首先盤古使能了更多的雲產品，讓雲產品去對接用戶，這樣就可以集中精力打造一個穩定可靠的分布式存儲平台。高可靠、高可用是不能妥協的部分，在任何情況下要保證數據的強一致性、正確性、可靠性、可用性。有的時候追求低成本會威脅到高可用，所以要做到高性能、合理成本，提供高性價比的在線存儲。易用、服務化，方便用戶輕量接入、無感知運維完善好用的監控、工具、文檔。
盤古總體架構
分為三個部分：Client，Master，ChunkServer。需要發起一次寫入的時候，Client向Master創建一個文件，並且打開這個文件，此時Master會選好三個副本的位置反饋給Client。Client根據三個副本的位置找到ChunkServer，把數據寫進去。也就是說，Client做整體的控製，Master提供源數據的存儲，ChunkServer提供數據的存儲。係統中的單點是非常脆弱的，如何保證其高可用？盤古的第一步是加入一個Paxos，也就是說用很多台Master組成一個group來實現高可用。即使用很多台服務器來實現高可用，最終對外服務的隻能是一台服務器，當內存數據足夠多的時候，就需要水平擴展。MountTable可以把目錄樹劃分成volume，通過不同的volume就可以實現Master的水平擴展。
盤古三副本強一致，三副本位於不同的故障域，故障時自動數據複製。如上圖所示，一個數據中心有3份數據存放在4個RACK中，如果RACK-1突然斷電或者網絡有問題。此時，比如菱形的數據原來在RACK-3、RACK-4上，當RACK-1的菱形數據丟失時，盤古會通過高效的算法從RACK-3上複製一份出來放入RACK-2，保證了數據的安全可靠。
數據保證完整性
運維是非常重要的，盤古實現了熱升級應用無感知，運維操作根據配置自動化執行，不需要人工幹預，通過環境標準化及時糾正，通過問題診斷自我解決問題。結構如上圖所示，有一個集中管理的配置管理庫，盤古管控中心會把配置管理庫推送到盤古的各個組件，自動執行配置變更，發現配置不對時能夠實現自動對齊，運行環境標準化檢查對於大規模的分布式係統是非常重要的。
- 數據安全是一種信仰：E2E Checksum；後台靜默掃描；係統bug，硬件故障，運維操作的容錯。大規模的係統中，總會遇到各種各樣的問題，當這些問題攪在一起時就會變得非常棘手。
- 環境檢查排除隱患：磁盤分區；機架分布；配置錯誤；軟件錯誤；硬件錯誤。
- 單機失效無感知：數據複製保證安全；換機器重試保證讀寫成功；記憶並規避故障機器。
- 監控+自愈：Master自我健康檢查進行切換；Chunkserver發現故障磁盤或機器進行隔離；Client檢測服務狀況進行Master切換；Client自我健康檢測並匯報狀態。
Master需要解決的主要是三類問題：大容量、高效、穩定。大容量是指：Federation水平擴展，內存緊致排列單組支持8億文件，讀寫OPS 100K/s。高效意味著最優的算法，硬件錯誤觸發快速複製保證數據安全，數據流量動態規劃實現最大吞吐，安全域動態調整保證數據高可用。穩定即Paxos數據一致、防止單點，多角度監控自動觸發切換，多用戶隔離防打死。由於盤古是多租戶的係統，比如一萬台的集群上麵會跑著各種各樣的應用，其相互之間是不知道的，但是它們在共用一個Master機器。如果一個用戶大量訪問Master，這時整個集群都不能提供對外服務，怎麼杜絕這種情況？盤古做了多重隔離解決了上述問題。
Chunkserver麵臨的問題是：閃存的價格高，IOPS高；機械硬盤價格低，IOPS低；隻寫入內存的方案掉電會丟失數據。如果整個集群都掉電，那麼內存中還沒寫入數據就會丟掉，如果三份備份數據都丟掉，這對雲計算是不能接受的事情。怎麼結合閃存、機械式硬盤以最低的成本解決上述問題？有些解決方案使用UPS，但是UPS也存在不可靠問題，數據仍然會丟失。所以，最終的解決方案是使用少量的緩存搭配大量的機械硬盤，數據前台先寫入緩存，後台將其轉儲到機械式硬盤。
Client麵臨很多問題，很多現在的編程語言中，協程是非常普及的事情。傳統的多線程編程中，多核係統上線程較多時，切換代價非常高，高性能的程序無法容忍這一點。有些解決方案是異步的編程，這樣就使用少數的線程、不切線程。怎麼樣既有同步編程的便利，又有異步編程的性能？協程就是解決方案，很多現在的編程語言本身已經提供了協程，但是C++沒有提供協程，所以盤古自己通過實現協程獲得了高性能。Client麵臨的問題是：有些用戶需要極致的性能，有些用戶需要編程的簡便，已有的海量程序要無縫支持。解決上述問題的方案是使用線程同步原語同時支持協程和非協程用戶。在協程中是不切線程的，所以意味著所有的Task都在一個線程中執行，如果任何一個Task有阻塞操作，都會導致整個線程吞吐率的降低。
最後更新：2017-07-19 20:03:04