存储--盘古_阿里云飞天分布式存储系统设计深度解析
摘要:本文依據盤古團隊的吳洋分享了《盤古:飛天分布式存儲系統實踐》視頻整理而成。 他主要從以下三個方面進行了分享:盤古是什么?盤古是用來解決什么問題的?盤古是怎么解決問題的?他主要介紹了盤古的分布式系統架構和設計理念。
本文依據盤古團隊的吳洋分享了《盤古:飛天分布式存儲系統實踐》視頻整理而成。
他主要從以下三個方面進行了分享:盤古是什么?盤古是用來解決什么問題的?盤古是怎么解決問題的?他主要介紹了盤古的分布式系統架構和設計理念。
上圖列舉了目前主流的云計算廠商,我們發現一個很有趣的事情:所有云計算廠商都是“富二代”,它們的分布式存儲技術全部采用自研技術,而沒有用大家耳熟能詳的開源分布式系統。
飛天夢
第一代飛天人的夢想是在大量廉價的PC服務器上,對外提供各種計算和存儲服務。具體到以下幾個組件:夸父,主要負責網絡;女媧,主要負責協同;伏羲,主要負責調度;盤古,主要負責存儲;神農,主要負責監控。
上圖介紹了盤古的底層存儲平臺,其承擔承上啟下的作用。盤古作為分布式存儲系統,主要提供兩種類型的接口: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,保證了數據的安全可靠。
數據保證完整性
盤古主要做了兩件事:端到端的數據校驗,靜默錯誤檢查。在小概率下,內存存儲的數據是可能發生變化的,磁盤上存儲的數據也會發生變化。每段數據后面都有CRC,這樣,一旦寫入磁盤,數據和CRC是能夠匹配上的,后臺周期性掃描,發現數據和CRC不匹配時就判定這段數據發生了位反轉,那么用其他好的副本將其覆蓋。
合理成本
盤古進行了合理成本的優化。比如,線下運行的單集群有上萬臺,數百PB的數據。單組Master也進行了優化,讀能達到15W QPS,寫能達到5W QPS。單數據節點進行了軟件棧極限優化,使得軟件的消耗非常低,并且分層存儲。最后,為了實現低成本,使用了普通PC服務器、Erasure Code。
自主服務
運維是非常重要的,盤古實現了熱升級應用無感知,運維操作根據配置自動化執行,不需要人工干預,通過環境標準化及時糾正,通過問題診斷自我解決問題。結構如上圖所示,有一個集中管理的配置管理庫,盤古管控中心會把配置管理庫推送到盤古的各個組件,自動執行配置變更,發現配置不對時能夠實現自動對齊,運行環境標準化檢查對于大規模的分布式系統是非常重要的。
面向容錯的設計
分布式系統的核心是面向容錯的設計:
數據安全是一種信仰:E2E Checksum;后臺靜默掃描;系統bug,硬件故障,運維操作的容錯。大規模的系統中,總會遇到各種各樣的問題,當這些問題攪在一起時就會變得非常棘手。
環境檢查排除隱患:磁盤分區;機架分布;配置錯誤;軟件錯誤;硬件錯誤。
單機失效無感知:數據復制保證安全;換機器重試保證讀寫成功;記憶并規避故障機器。
監控+自愈:Master自我健康檢查進行切換;Chunkserver發現故障磁盤或機器進行隔離;Client檢測服務狀況進行Master切換;Client自我健康檢測并匯報狀態。
以上的設計大大減小了運維的壓力。
Master
Master需要解決的主要是三類問題:大容量、高效、穩定。大容量是指:Federation水平擴展,內存緊致排列單組支持8億文件,讀寫OPS 100K/s。高效意味著最優的算法,硬件錯誤觸發快速復制保證數據安全,數據流量動態規劃實現最大吞吐,安全域動態調整保證數據高可用。穩定即Paxos數據一致、防止單點,多角度監控自動觸發切換,多用戶隔離防打死。由于盤古是多租戶的系統,比如一萬臺的集群上面會跑著各種各樣的應用,其相互之間是不知道的,但是它們在共用一個Master機器。如果一個用戶大量訪問Master,這時整個集群都不能提供對外服務,怎么杜絕這種情況?盤古做了多重隔離解決了上述問題。
Chunkserver
Chunkserver面臨的問題是:閃存的價格高,IOPS高;機械硬盤價格低,IOPS低;只寫入內存的方案掉電會丟失數據。如果整個集群都掉電,那么內存中還沒寫入數據就會丟掉,如果三份備份數據都丟掉,這對云計算是不能接受的事情。怎么結合閃存、機械式硬盤以最低的成本解決上述問題?有些解決方案使用UPS,但是UPS也存在不可靠問題,數據仍然會丟失。所以,最終的解決方案是使用少量的緩存搭配大量的機械硬盤,數據前臺先寫入緩存,后臺將其轉儲到機械式硬盤。
Client
Client面臨很多問題,很多現在的編程語言中,協程是非常普及的事情。傳統的多線程編程中,多核系統上線程較多時,切換代價非常高,高性能的程序無法容忍這一點。有些解決方案是異步的編程,這樣就使用少數的線程、不切線程。怎么樣既有同步編程的便利,又有異步編程的性能?協程就是解決方案,很多現在的編程語言本身已經提供了協程,但是C++沒有提供協程,所以盤古自己通過實現協程獲得了高性能。Client面臨的問題是:有些用戶需要極致的性能,有些用戶需要編程的簡便,已有的海量程序要無縫支持。解決上述問題的方案是使用線程同步原語同時支持協程和非協程用戶。在協程中是不切線程的,所以意味著所有的Task都在一個線程中執行,如果任何一個Task有阻塞操作,都會導致整個線程吞吐率的降低。
如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至:yqgroup@service.aliyun.com 進行舉報,并提供相關證據,一經查實,本社區將立刻刪除涉嫌侵權內容。
原文鏈接
總結
以上是生活随笔為你收集整理的存储--盘古_阿里云飞天分布式存储系统设计深度解析的全部內容,希望文章能夠幫你解決所遇到的問題。
 
                            
                        - 上一篇: Docker--数据管理之Volumes
- 下一篇: 李楠:iPhone 15不良心的地方在于
