建站
咨詢
售后
建站咨詢
新聞中心
Amazon S3 全稱Amazon Simple Storage Service,旨在通過(guò)web服務(wù)接口提供業(yè)界領(lǐng)先的性能、速度、安全性、可伸縮性和數(shù)據(jù)可用性。該平臺(tái)由亞馬遜網(wǎng)絡(luò)服務(wù)(AWS)開發(fā)，并于2006年3月14日首次推出,后續(xù)S3逐漸演變?yōu)閷?duì)象存儲(chǔ)的標(biāo)準(zhǔn)。
隨著公司的快速發(fā)展,公司內(nèi)對(duì)各種圖片、視頻、文件等這類對(duì)象的存儲(chǔ)需求越來(lái)越強(qiáng)烈。
目前公司內(nèi)的接入場(chǎng)景包括，二維碼，景區(qū)推薦視頻，圖片，css，js，ML訓(xùn)練素材等資源，大約10億+文件數(shù)。都是核心的業(yè)務(wù)場(chǎng)景,如果存儲(chǔ)服務(wù)故障，影響的范圍會(huì)比較大，比如掃不了入園二維碼，訪問(wèn)不了圖片等。
由于歷史原因，現(xiàn)在公司內(nèi)提供類似存儲(chǔ)的服務(wù)有好幾套，包括Ceph s3，F(xiàn)astDfs+Redis(做元數(shù)據(jù)存儲(chǔ))，公有云 s3代理等，幾套服務(wù)都有比較明顯的問(wèn)題。比如公有云 s3，使用成本相對(duì)比較高,而且走外網(wǎng)交互性能得不到保障；比如Ceph，想完全維護(hù)好需要投入大量的成本，性價(jià)比不是很高；再比如fastdfs+redis，接入不太友好，支持不了主流的S3。所以我們提供了一套新的對(duì)象存儲(chǔ)服務(wù)來(lái)解決以上問(wèn)題，本文會(huì)詳細(xì)介紹，我們新的對(duì)象存儲(chǔ)服務(wù)(OSS)是怎么做的。
01 設(shè)計(jì)目標(biāo)
整體的設(shè)計(jì)目標(biāo)如下：
可擴(kuò)展: 至少需要支持到10億+的對(duì)象數(shù),并且需要有水平擴(kuò)展的能力；
高可用: 要做到高可用,至少要有隔離,多租戶,限流,災(zāi)備/雙活等能力,最核心業(yè)務(wù)甚至可以做到不同存儲(chǔ)產(chǎn)品的災(zāi)備；
高性能: 需要足夠快,類似ceph rados,后續(xù)需要可以作為分布式文件存儲(chǔ)的存儲(chǔ)底座；
低成本: 可以用遠(yuǎn)低于ceph的成本支撐所有的業(yè)務(wù)；
接入簡(jiǎn)單: 能夠支持主流對(duì)象存儲(chǔ)S3協(xié)議的接入；
無(wú)縫升級(jí): 可以在業(yè)務(wù)無(wú)感知的情況下,穩(wěn)定的、無(wú)縫將業(yè)務(wù)從ceph s3,公有云 s3遷到新oss。
02 系統(tǒng)設(shè)計(jì)
簡(jiǎn)單來(lái)說(shuō)，設(shè)計(jì)目標(biāo)可以拆分成2個(gè)點(diǎn):
- 需要一個(gè)非常強(qiáng)大的對(duì)象存儲(chǔ)oss服務(wù)
- 如何在架構(gòu)層面解決業(yè)務(wù)無(wú)縫切換,存儲(chǔ)無(wú)縫升級(jí)從而保障業(yè)務(wù)的穩(wěn)定性
下面我將從這2點(diǎn)來(lái)介紹下我們是怎么做的。
oss技術(shù)選型
近些年越來(lái)越火的開源+商業(yè)化的模式讓每個(gè)方向都或多或少出現(xiàn)了一些比較好的開源產(chǎn)品,比如時(shí)序存儲(chǔ)方向的TDengine,OLAP方向的ClickHouse等等,在對(duì)象存儲(chǔ)選型的時(shí)候,我們也優(yōu)先考慮開源產(chǎn)品,通過(guò)開源共建的方式來(lái)完成我們的產(chǎn)品,盡量不從0開始造輪子。整個(gè)社區(qū)看下來(lái),相對(duì)比較熱門的有minio,SeaweedFS,fastdfs,ceph。其中ceph跟fastdfs不在考慮范圍內(nèi),所以精力就放在minio跟SeaweedFS上,看是否能滿足要求。
minio
minio應(yīng)該是目前最火的開源對(duì)象存儲(chǔ)，github 3w4的star數(shù)。
minio的優(yōu)點(diǎn)包括:
- 友好的UI
- 部署比較簡(jiǎn)單,很容易上手
- 支持文件級(jí)別的自愈,在節(jié)點(diǎn)故障時(shí)無(wú)需人工干預(yù)
- 全EC存儲(chǔ),成本相對(duì)比較低
- 中大文件性能比較好
- 基于文件系統(tǒng)設(shè)計(jì),無(wú)需額外的存儲(chǔ)來(lái)存儲(chǔ)元數(shù)據(jù)
同樣minio的缺點(diǎn)也相對(duì)明顯：
- 僅支持EC,會(huì)存在io放大的問(wèn)題,特別是在大量小文件的場(chǎng)景下
- 擴(kuò)容不太友好,對(duì)等擴(kuò)容時(shí)需要全集群停止服務(wù)
- 支持的文件數(shù)量有限,基于本地文件系統(tǒng)設(shè)計(jì),在對(duì)象數(shù)變多以后,inode的查找都會(huì)變得很耗時(shí)
minio是一款有明顯優(yōu)缺點(diǎn)的產(chǎn)品,在我們的需求背景下,minio不能夠很好的滿足,特別是不能夠支持我們10億+對(duì)象存儲(chǔ)需求,而且在現(xiàn)有的架構(gòu)設(shè)計(jì)下,也不太好改造,然后通過(guò)與社區(qū)共建的方式來(lái)滿足我們海量小文件的需求。
SeaweedFS
越來(lái)越火的對(duì)象存儲(chǔ)開源方案,github star數(shù)1w5+,且增長(zhǎng)速度比較喜人,社區(qū)也比較活躍。
SeaweedFS官方介紹的核心點(diǎn)有2個(gè)：
- to store billions of files!
- to serve the files fast!
跟我們的部分核心目標(biāo)比較貼近。
核心優(yōu)點(diǎn)包括:
- 性能比較強(qiáng)大: 核心理論依據(jù)是基于 Facebook's Haystack design paper ,該paper的目標(biāo)也是解決facebook內(nèi)部圖片視頻等數(shù)據(jù)的存儲(chǔ)查詢問(wèn)題
- 架構(gòu)設(shè)計(jì)比較靈活: 系統(tǒng)設(shè)計(jì)參照了Facebook’s Tectonic Filesystem ,特別是幾個(gè)核心組件的設(shè)計(jì),抽象的比較好,非常方便擴(kuò)展不同的實(shí)現(xiàn),并且整體架構(gòu)上可以水平擴(kuò)容,沒(méi)有明顯的瓶頸點(diǎn)
- 功能齊全: 存儲(chǔ)比較關(guān)心的冷熱分離,EC存儲(chǔ),TTL等功能都有支持
- 部署簡(jiǎn)單: 部署非常簡(jiǎn)單,很容易上手
相比于優(yōu)點(diǎn),也會(huì)有些不足
- S3的適配不完全: 實(shí)現(xiàn)了大部分的常用接口,部分非常用接口未實(shí)現(xiàn),比如Canned ACL等。
- 項(xiàng)目背景: 相比于minio等開源產(chǎn)品后面都是強(qiáng)大的商業(yè)化公司,該項(xiàng)目核心的作者只有 chrislusf 大神
從各個(gè)維度來(lái)看,基于SeaweedFS開源共建的方式來(lái)打造我們的對(duì)象存儲(chǔ)服務(wù)是目前比較合理的方案。
系統(tǒng)架構(gòu)
架構(gòu)介紹
確定選型SeaweedFS后，下一步就是怎么來(lái)設(shè)計(jì)整體服務(wù)來(lái)滿足我們的需求，簡(jiǎn)易架構(gòu)如下：
整體架構(gòu)其實(shí)是一個(gè)比較常見(jiàn)的架構(gòu),非常簡(jiǎn)單
- Proxy層: 來(lái)適配不同的Api以及對(duì)業(yè)務(wù)做存儲(chǔ)適配
- 存儲(chǔ)層: 包括SeaweedFS,Ceph s3,公有云 s3. 公有云 s3的操作跟Ceph s3類似,本文就不展開了
- 管控平臺(tái): 可視化UI,做權(quán)限配置,配額配置,數(shù)據(jù)列表等
名詞解釋：
- 公有云 s3 Api: 公司內(nèi)部之前封裝的公有云 s3對(duì)外的Api
- Efs Api: 公司內(nèi)部之前封裝的對(duì)外的靜態(tài)資源相關(guān)的Api
- S3 Api: 適配了S3的所有Api
- StoreAdapter: 來(lái)根據(jù)配置來(lái)處理業(yè)務(wù)的請(qǐng)求,選擇存儲(chǔ)適配
- Filer/s3 Api: SeaweedFS用來(lái)對(duì)外暴露s3等相關(guān)Api的服務(wù)
- DCDB: 公司基于BaiKalDB共建的分布式數(shù)據(jù)庫(kù),下文會(huì)詳細(xì)介紹
- BlobStorage: SeaweedFS中用來(lái)實(shí)際做對(duì)象存儲(chǔ)的模塊
設(shè)計(jì)目標(biāo)詳解
可擴(kuò)展
目標(biāo): 至少需要支持到10億+的對(duì)象數(shù),并且需要有水平擴(kuò)展的能力。
proxy是無(wú)狀態(tài)的,可以做到水平擴(kuò)展,所以只需要SeaweedFS做到可以水平擴(kuò)展就可以滿足我們的需求了。
從整體架構(gòu)上來(lái)看,SeaweedFS核心的有2層(S3存儲(chǔ)最核心的基本都是這2塊)
- File Storage: 用來(lái)做metadata元信息的存儲(chǔ)以及做api的適配
- Blob Storage: 對(duì)象存儲(chǔ)的底座
metadata的能力是比較核心的一個(gè)環(huán)節(jié),他至少需要做到:水平擴(kuò)展能力,不丟數(shù)據(jù),讀寫性能比較好,高可用。類似的服務(wù)有:Cassandra,Tidb,YDB,toctonics用的ZippyDB等等?；谖覀児粳F(xiàn)狀,我們選擇了跟BaiKalDB共建的分布式數(shù)據(jù)庫(kù)DCDB。
DCDB在我們公司使用的比較多,性能得到了很好的驗(yàn)證,并且能夠很 好的匹配 我們的訴求。 在引入DCDB做元數(shù)據(jù)服務(wù)后,測(cè)試下來(lái)讀寫請(qǐng)求的平均耗時(shí)在1ms內(nèi),能夠滿足我們的需求。
以上是dcdb真實(shí)使用下來(lái)的監(jiān)控?cái)?shù)據(jù),因?yàn)榭梢运綌U(kuò)容,我 們壓測(cè) 結(jié)果為即使數(shù)據(jù)量級(jí)到了幾十億,也沒(méi)有出現(xiàn)性能瓶頸。
有了DCDB的加持,比如整個(gè)讀流程就會(huì)非常的簡(jiǎn)單,從DCDB獲取元信息,返回?cái)?shù)據(jù)對(duì)應(yīng)的存儲(chǔ)節(jié)點(diǎn),直接跟存儲(chǔ)節(jié)點(diǎn)交互獲取數(shù)據(jù),存儲(chǔ)節(jié)點(diǎn)之間是沒(méi)有直接關(guān)系的,可以做到水平擴(kuò)展。
整體看下來(lái),現(xiàn)在整個(gè)集群內(nèi)沒(méi)有明顯的瓶頸點(diǎn),所有的組件都可以做到水平擴(kuò)容,可以很好 的滿 足我們對(duì)規(guī)模的要求。
高可用
需要做到高可用至少需要保障在單點(diǎn)故障(物理機(jī)故障等),預(yù)期外流量沖擊,甚至單idc故障時(shí)服務(wù)要可用,以及要做到多租戶之間相互隔離。下面分別介紹下這幾種場(chǎng)景是怎么做的：
（1）隔離
業(yè)務(wù)隔離,我們做到了在nginx上做分流,不同的業(yè)務(wù)(bucket)使用不同的proxy,filer,volumeServer。 做到了業(yè)務(wù)與業(yè)務(wù)之間物理隔離,相互不影響。
（2）租戶與限流
除了物理隔離外,還需要至少做到業(yè)務(wù)級(jí)別的限流熔斷功能。對(duì)象存儲(chǔ)跟其它的大數(shù)據(jù)服務(wù)有個(gè)比較大的區(qū)別是流量特別大,比如并發(fā)上傳1M的文件,很輕松就可以將流量打到幾十上百GB,會(huì)造成網(wǎng)絡(luò)上面的瓶頸,所以我們要做到可以給業(yè)務(wù)配置閾值,做到當(dāng)某個(gè)業(yè)務(wù)有預(yù)期外的流量時(shí),可以單獨(dú)限制不能影響到整體服務(wù),甚至造成網(wǎng)絡(luò)故障。
關(guān)于租戶的限流我們pr了2個(gè)策略,一個(gè)是基于bucket級(jí)別的全局流量限制,一種是可以基于 count+單文件下載限速的流量控制可以比較好的使得整個(gè)集群可控。
（3）高可用
proxy,filer,dcdb上文都介紹了,可以做到高可用,現(xiàn)在介紹一下數(shù)據(jù)是怎么做高可用的。數(shù)據(jù)高可用正常會(huì)有2種方式:多副本與EC糾刪碼
SeaweedFS支持實(shí)時(shí)寫數(shù)據(jù)使用副本方式,后期可以轉(zhuǎn)換為EC. 都是可以做到數(shù)據(jù)高可用的。
高性能
SeaweedFS官方介紹的其中一個(gè)特點(diǎn)是:to serve the files fast!
核心實(shí)現(xiàn)思路是參照Facebook's Haystack design paper,論文里面介紹的比較詳細(xì)。
工程實(shí)踐后最終效果做到了,小文件合并后的順序?qū)懸约癘(1)的硬盤讀. 下圖是我們6臺(tái)256G,12*8TB SATA盤,壓測(cè)的是1M的寫,io優(yōu)先到了瓶頸點(diǎn)。寫入3000 TPS
下圖是我們6臺(tái)256G,10TB SSD盤,壓測(cè)的是1M的 寫,因 為帶寬限制,沒(méi)有繼續(xù)壓,各個(gè)指標(biāo)遠(yuǎn)沒(méi)有到達(dá)瓶頸。 寫入4000 TPS
在寫入,查詢,刪除混合場(chǎng)景(6:3:1)壓測(cè)下,1M的文件 3500+ QPS
以上結(jié)果僅用了6臺(tái)機(jī)器測(cè)試,性能結(jié)果達(dá)到我們的需求,后期如果有更高的需求,可以做水平擴(kuò)展。
低成本
對(duì)象存儲(chǔ)最大的成本會(huì)是在存儲(chǔ)上,數(shù)據(jù)量會(huì)非常大,幾百TB,PB甚至EB都是可能的。 如上圖,各種云廠商也提供了不同存儲(chǔ)的不同的計(jì)費(fèi),簡(jiǎn)單來(lái)說(shuō),就是冷的數(shù)據(jù)可以犧牲一部分性能來(lái)降低存儲(chǔ)的成本。 同樣SeaweedFS也做了類似的功能。
補(bǔ)充個(gè)小知識(shí)點(diǎn): 多備份與EC的差異,可以清楚的看到成本角度,EC比多副本更有優(yōu)勢(shì)。
現(xiàn)在我們可選的存儲(chǔ)介質(zhì)包括NVME SSD,SATA SSD,HDD。可選的數(shù)據(jù)存儲(chǔ)方式有多副本,EC。
如圖,隨著數(shù)據(jù)越來(lái)越冷,我們會(huì)慢慢從SSD遷移到HDD,以及從副本方式改為EC存儲(chǔ)。 做了性能與成本的取舍。
無(wú)縫升級(jí)
上面介紹了SeaweedFS的一些功能,下面介紹一下我們是如何讓業(yè)務(wù)無(wú)縫從ceph s3,公有云 s3,efs api等存儲(chǔ)切到新的平臺(tái)來(lái)。目前場(chǎng)景以ceph為例:
（1)流程適配
業(yè)務(wù)直接通過(guò)S3對(duì)ceph進(jìn)行操作。我們要做的就是偷梁換柱,在業(yè)務(wù)無(wú)感知的情況下,將ceph s3替換為更高可用的SeaweedFS。大概需要做幾個(gè)事情
- 全api的適配
proxy適配了我們?cè)人袑?duì)外的api,包括s3 api,公有云 s3 api,efs api,所有api解析完內(nèi)部操作完全一致了,這樣可以做到只需要域名解析調(diào)整到proxy就可以了。
- 讀流程的適配
因?yàn)闅v史的原因,現(xiàn)在ceph s3以及公有云 s3里面存在了大量的不再使用的數(shù)據(jù)幾百TB,這些數(shù)據(jù)是不需要導(dǎo)入到新存儲(chǔ)的,如上圖,我們proxy支持了一種策略s3 -> S3的策略。 主要特點(diǎn)有2個(gè):
①存儲(chǔ)級(jí)別的高可用:新存儲(chǔ)故障自動(dòng)切到備存儲(chǔ),做到存儲(chǔ)級(jí)別的高可用
②自動(dòng)數(shù)據(jù)補(bǔ)齊:新存儲(chǔ)無(wú)數(shù)據(jù),備存儲(chǔ)有數(shù)據(jù),自動(dòng)將該數(shù)據(jù)的元信息寫入MQ
同時(shí)我們還有一個(gè)補(bǔ)償?shù)某绦騺?lái)讀取MQ中的數(shù)據(jù),自動(dòng)將被存儲(chǔ)的數(shù)據(jù)補(bǔ)償?shù)叫麓鎯?chǔ),這樣可以做到一段時(shí)間后,所有熱數(shù)據(jù)(有訪問(wèn)的數(shù)據(jù))自動(dòng)備份到新存儲(chǔ)了,ceph s3/公有云 s3可以下線。
注: 寫MQ的時(shí)候需要注意,需要按照文件級(jí)別做順序?qū)懭?防止數(shù)據(jù)有問(wèn)題
- 寫流程的適配
寫入做了取舍,為了提升性能,寫入只需要一個(gè)存儲(chǔ)寫成功就響應(yīng)給業(yè)務(wù),第二個(gè)存儲(chǔ)的數(shù)據(jù)由補(bǔ)償程序來(lái)完成。 該流程可以做到任意存儲(chǔ)故障時(shí),業(yè)務(wù)都無(wú)感知。
proxy中所有操作都是S3的標(biāo)準(zhǔn)接口操作,所以可以輕易做到SeaweedFS與ceph s3,SeaweedFS與公有云 s3,SeaweedFS與SeaweedFS的多種災(zāi)備方案。比如最核心的業(yè)務(wù)場(chǎng)景二維碼,景區(qū)圖片等,我們會(huì)先運(yùn)行一陣SeaweedFS與公有云 s3的自動(dòng)災(zāi)備,防止某種場(chǎng)景 下觸發(fā)了某個(gè)存儲(chǔ)的bug,而造成大面積的影響。
寫入MQ的數(shù)據(jù)還有一個(gè)用途,用來(lái)做雙存儲(chǔ)的數(shù)據(jù)校驗(yàn),保障2個(gè)集群的數(shù)據(jù)最終一致性。
注:
- 圖中默認(rèn)寫入MQ是成功的,實(shí)際proxy中有兜底策略,寫MQ失敗有另外的兜底策略,比較復(fù)雜,這里不做闡述。
- 以上介紹了2個(gè)核心場(chǎng)景流程,還有部分場(chǎng)景稍有區(qū)別,如list api等 。
（2）升級(jí)步驟
除了理論上的無(wú)縫外,為了穩(wěn)定的運(yùn)行上線,上線流程也比較講究,我們大概會(huì)分幾步：
- 數(shù)據(jù)比對(duì): 拿s3 api為例,切換之前我們會(huì)有個(gè)比對(duì)程序,訂閱nginx的訪問(wèn)日志,來(lái)做2個(gè)存儲(chǔ)的結(jié)果比對(duì),核心比對(duì)結(jié)果主要包括文件的MD5,以及響應(yīng)的header頭。
- 策略調(diào)整: 因?yàn)闃I(yè)務(wù)比較核心,為了穩(wěn)定的推進(jìn),每次只做最小化變更,推進(jìn)過(guò)程分了3步: 1: 引入代理,保障代理功能正常 2: 引入SeaweedFS為主,做成SeaweedFS與ceph的
集群備份,這樣可以做到即使SeaweedFS有問(wèn)題,我們也可以快速的將流量回滾到ceph 3:下線ceph,最終形態(tài),做成SeaweedFS的雙集群備份。
03 落地收益
得益于開源的好處,我們僅僅投入了2個(gè)人力,整個(gè)迭代從選型到源碼、原理研究到開始落地大概持續(xù)了3個(gè)月,該項(xiàng)目上線已經(jīng)運(yùn)行了接近3個(gè)月,運(yùn)行良好,達(dá)到了預(yù)期的期望效果。目前已接入 接近2000w對(duì)象,60TB的數(shù)據(jù)量,還在快速流量切換中。
以核心業(yè)務(wù)efs為例,之前存儲(chǔ)使用的是公有云 s3,現(xiàn)在切換到了第二步(SeaweedFS為主集群,公有云 s3為備用集群)。 切換后的收益：
- 性能: 響應(yīng)耗時(shí)有了質(zhì)的提升,從150ms下降到3ms。
- 穩(wěn)定性: 之前訪問(wèn)公有云 s3走的是公網(wǎng),性能波動(dòng)比較大,切換后耗時(shí)變得非常平穩(wěn)。
- 成本: 目前到了第二步,公有云 s3還剩下了寫入的流量,讀的流量基本清0了,成本也下降了很多。
04 使用tips
- volumeGrowthCount: 這個(gè)需要調(diào)整,要做到盡量所有volumeServer都有writeable的volume,否則寫入,查詢性能會(huì)有影響。
- fs.configure: SeaweedFS的設(shè)計(jì)是每個(gè)bucket都對(duì)應(yīng)一個(gè)collection,這樣可以方便的做生命周期管理,需要控制bucket數(shù)量,否則性能會(huì)影響比較大。我們內(nèi)部先改版了取消這個(gè)綁定,做到性能最優(yōu),不過(guò)犧牲了一些bucket的統(tǒng)計(jì)功能,完整功能還在優(yōu)化中。
- filer.sync: 沒(méi)有proxy的情況下,可以使用filer.sync的同步工作來(lái)做雙集群災(zāi)備。
05 未來(lái)展望
- 定期備份: 核心bucket的增量、全量定期備份,做到跟db類似的效果,可以做到萬(wàn)一誤刪等問(wèn)題也可以回滾。
- 開源共建: 到目前為止,我們也陸陸續(xù)續(xù)大大小小提交了20+pr,包括bug fix,性能功能優(yōu)化,后續(xù)會(huì)持續(xù)的關(guān)注社區(qū),跟社區(qū)一起成長(zhǎng)。
- 基于S3的存計(jì)分離方案: 現(xiàn)在很多主流的存儲(chǔ)產(chǎn)品都適配了S3,比如prometheus,clickhouse等等。因?yàn)樾耾ss的強(qiáng)大的性能,我們會(huì)在這些適配S3的存儲(chǔ)上面試點(diǎn)存儲(chǔ)與計(jì)算分離。
- 分布式文件存儲(chǔ): 類似ceph,可以基于對(duì)象存儲(chǔ)rados打造分布式文件存儲(chǔ),以及現(xiàn)在比較火的juicefs或curvefs也是基于s3構(gòu)建的。后期也計(jì)劃基于該oss實(shí)現(xiàn)分布式文件存儲(chǔ),一期目標(biāo)在除了對(duì)io latency要求非常高(mysql)的場(chǎng)景外落地,為業(yè)務(wù)賦能。
分享文章：同程旅行對(duì)象存儲(chǔ)實(shí)踐
分享URL：http://www.5511xx.com/article/coppgii.html
