一、溯源——vivo存儲服務(wù)介紹

1.產(chǎn)品矩陣

圖片

當(dāng)前我們的團(tuán)隊主要負(fù)責(zé)兩大板塊內(nèi)容，一是存儲和數(shù)據(jù)庫產(chǎn)品矩陣，二是周邊工具及接收類服務(wù)。

這兩部分內(nèi)容的區(qū)別主要是，周邊工具和接入類服務(wù)幾乎是無狀態(tài)的，用戶對這類服務(wù)提出可用性的需求，比如我們平時接觸到的SLA；而存儲及數(shù)據(jù)庫產(chǎn)品等引擎，主要面向?qū)ο蟠鎯?、文件存儲、表格存儲等專門的服務(wù)業(yè)務(wù)，包括可用性和可靠性的指標(biāo)。

2.存儲框架

云存儲領(lǐng)域的黃金數(shù)字是11個9，接下來就以存儲服務(wù)為切入點(diǎn)，向大家介紹11個9能否量化？如何量化？

圖片

如上圖所示，存儲框架的核心思路是以自研的存儲引擎為核心，輔以阿里、騰訊等公有云的存儲，獲得統(tǒng)一的存儲底座，在上方形成對應(yīng)存儲的統(tǒng)一網(wǎng)關(guān)，進(jìn)而提供一套混合云的存儲系統(tǒng)。然后，存儲系統(tǒng)進(jìn)行協(xié)議轉(zhuǎn)換、衍生產(chǎn)品開發(fā)，為業(yè)務(wù)提供存儲服務(wù)和衍生的生態(tài)服務(wù)。

比如，我們會利用自己的SDK和AWS S3 SDK，提供原生的對應(yīng)重組產(chǎn)品，向前封裝文件的存儲網(wǎng)關(guān)，兼容posix協(xié)議，為用戶提供文件的存儲產(chǎn)品。除此之外，還會封裝企業(yè)網(wǎng)盤，進(jìn)行專項(xiàng)服務(wù)，為用戶提供相應(yīng)的衍生產(chǎn)品。

3.運(yùn)營數(shù)據(jù)

當(dāng)前，基于跨機(jī)房的糾刪碼相關(guān)優(yōu)化，對可靠性提出了挑戰(zhàn)。如下圖所示，我們線上的集群容量達(dá)到400億（此數(shù)據(jù)尚未包括Hadoop的數(shù)據(jù)容量），存儲數(shù)量已超1,000億。

圖片

二、歸因：存儲可靠性原因分析

1.數(shù)據(jù)丟失影響因素

圖片

數(shù)據(jù)丟失的五大原因包括：軟件故障、數(shù)據(jù)損壞、惡意竊取、人為失誤、硬件故障，其中硬件故障的占比較高。

2.軟件故障和數(shù)據(jù)損壞

圖片

軟件故障的主要原因是軟件設(shè)計不規(guī)范、測試不完善及運(yùn)維發(fā)布的操作爆炸半徑太高。

這些問題的通用解決方案是：

• 設(shè)計標(biāo)準(zhǔn)規(guī)范化，比如，AWS引入了TLA+、Plusal等形式化規(guī)范語言來設(shè)計系統(tǒng)；
• 要達(dá)到測試自動化；
• 做好版本向前版本兼容、版本回滾、讀寫分離等操作。

數(shù)據(jù)損壞的行業(yè)通用解決方案相對成熟，因?yàn)樵谔幚韨鬏斉c存儲的過程中，都有一定概率遇到數(shù)據(jù)損壞的問題。

解決方案：

• 通過HTTPS協(xié)議，保證傳輸?shù)陌踩?/li>
• 然后通過MD5校驗(yàn)，記錄交易數(shù)據(jù)的完整性；
• 最后通過定期的scrubbing處理機(jī)制，快速掃描是否具有靜默錯誤。

3.惡意竊取和人為失誤

圖片

人為失誤主要包括兩類問題，第一類是運(yùn)維人員操作失誤，第二類是用戶自己的誤殺或誤覆蓋。

• 針對運(yùn)維的解決方案：運(yùn)維自動化、運(yùn)維白屏化、遵循POLP的最小權(quán)限原則。
• 針對用戶的解決方案：自動存儲方面，可以利用多版本的特性，保證用戶可以找回誤刪的這種數(shù)據(jù)；文件方面，提供回收站功能可以達(dá)到相同效果。

惡意竊取主要是內(nèi)外部人員相關(guān)竊取或刪除數(shù)據(jù)，其解決方案包括：

• 進(jìn)行權(quán)限控制和生命周期管控；
• 可以鎖定對象粒度為只讀模式；
• 針對刪除操作，可以提供這種多因素的、健全的雙因子論證，管控刪除操作。

4.硬件故障

硬件故障是需要重點(diǎn)關(guān)注的存儲可靠性原因，因?yàn)樗急容^高，樣本量比較大，所以有一定概率進(jìn)行量化。

1）原因

• 硬盤故障：最常見最重要的，驅(qū)動器、磁頭、溫度、機(jī)械臂故障
• 主機(jī)故障：服務(wù)器各部件故障導(dǎo)致服務(wù)器無法啟動
• 機(jī)柜故障：由于電源、溫度、網(wǎng)絡(luò)等原因?qū)е抡麢C(jī)柜服務(wù)器停機(jī)
• 機(jī)房故障：整個機(jī)房由于自然災(zāi)害或供電原因癱瘓
• AZ故障：同一地理區(qū)域獨(dú)立電力和網(wǎng)絡(luò)的機(jī)房故障
• Region故障：不同地理區(qū)域的一個Region故障

2）硬件故障的解決方案

• 數(shù)據(jù)冗余技術(shù)【RAID5/6、副本、糾刪碼】
• 多AZ數(shù)據(jù)冗余部署【vivo 3 AZ 部署】
• 跨區(qū)域復(fù)制功能【功能具備，vivo還沒多地域機(jī)房】
• 故障預(yù)測+故障發(fā)現(xiàn)+故障修復(fù)

如果我們只按照傳統(tǒng)方式，增加K，減少M(fèi)，修復(fù)帶寬就會非常高。并且，多AZ之間的修復(fù)帶寬本身成本較高，所以給可靠性帶來了很大壓力。因此，我們設(shè)計了一個低冗余度、支持多AZ部署、且修復(fù)帶寬較少的糾刪碼優(yōu)化方案。

圖片

上方右圖來自2021年亞馬遜AWS S3關(guān)于可靠性保障的演講，這幅圖提供了兩個重要的信息。

• 第一個信息：11個9是通過可靠性模型量化得到的，它與磁盤的故障率、故障發(fā)現(xiàn)的時間和消費(fèi)時長是強(qiáng)相關(guān)的。
• 第二個信息：可靠性評估模型，用于指導(dǎo)線上環(huán)境的修復(fù)策略，以及指導(dǎo)跨AZ糾刪碼技術(shù)存儲系統(tǒng)的設(shè)計。

三、建模：存儲可靠性量化模型

1.11個9的由來

11個9是亞馬遜在2006年提出的可靠性標(biāo)準(zhǔn)，所有云存儲提供商都像軍備競賽一樣，聲稱自己能提供多少個9，但行業(yè)內(nèi)幾乎沒有任何一家云廠商能提供權(quán)威的量化模型。

這11個9如何量化？

圖片

亞馬遜的官方文檔提供了兩種定義：

• 第一個定義是，存儲一千萬個對象預(yù)期平均每1萬年發(fā)生一個對象丟失。這個定義很好理解，但它實(shí)際上并不好量化；
• 第二個定義是，平均每年對象的丟失率預(yù)計為0.000000001%。這個定義具體到每年的對象丟失率，進(jìn)入到統(tǒng)計學(xué)概率的層面，為量化提供可能。

回顧那張AWS演講里的圖，它引入了兩個比較重要的參考指標(biāo)：硬件的平均故障時間、故障的平均修復(fù)時長，對應(yīng)到年平均指標(biāo)的層面上，就是年平均故障率和年平均修復(fù)率。

2.可靠性模型影響因素

接下來，介紹建立模型的具體影響因素。如下圖所示，如果第一個磁盤爆炸，后面磁盤的數(shù)據(jù)需要對它進(jìn)行修復(fù)，這個過程可能涉及到修復(fù)帶寬，所以修復(fù)帶寬的大小一定會對可靠性產(chǎn)生影響。這個磁盤本身的數(shù)據(jù)量、系統(tǒng)節(jié)點(diǎn)數(shù)目也影響了修復(fù)時間，這三個指標(biāo)實(shí)際上影響了修復(fù)率的值。

圖片

副本的數(shù)量、磁盤故障率對可靠性也是有影響的，這比較好理解，如何理解數(shù)據(jù)分布系數(shù)對可靠性的影響？

如上圖左下角所示，備份有兩種數(shù)據(jù)分布方式。在第一種備份的數(shù)據(jù)分布狀況下，如果第一個磁盤掛了，只能依靠第二個磁盤進(jìn)行修復(fù)，即只有一個盤進(jìn)行修復(fù)，所以速度較慢。

第二種備份將數(shù)據(jù)分塊打散，其他三個磁盤都存儲一部分?jǐn)?shù)據(jù)。第一個磁盤掛掉后，就有多個磁盤并行修復(fù)，速度會更快。

這是不是說明第二種備份方式就是最好的？也不一定。因?yàn)榈谝环N備份雖然修復(fù)速度慢，但正好修復(fù)了掛掉的數(shù)據(jù)。用第二種備份方式，修復(fù)的數(shù)據(jù)可能不是掛掉的數(shù)據(jù)，實(shí)際存在數(shù)據(jù)丟失情況，因此，數(shù)據(jù)分布系數(shù)對可靠性也有影響。

3.MTTDL可靠性模型

圖片

以下介紹幾個重要的存儲可靠性量化模型。第一個是MTTDL（平均系統(tǒng)數(shù)據(jù)丟失時間），它和磁盤的MTTF的區(qū)別在于，MTTDL用于衡量系統(tǒng)平均數(shù)據(jù)丟失時間。

MTTDL模型在1994年被提出，1.0版本基于Markov鏈推導(dǎo)而來，上圖列出了一個簡化版的計算公式。相對于1.0版本，最近幾年出現(xiàn)的MTTDL的2.0版本，引入了剛才講到的數(shù)據(jù)分布系數(shù)。

MTTDL有幾個缺點(diǎn)：第一個缺點(diǎn)是，它基于Markov鏈的方式；第二個缺點(diǎn)是，基于當(dāng)前整個系統(tǒng)的故障平均時間，它是服從指數(shù)分布的。

另外，前期的MTTDL模型沒有考慮扇區(qū)錯誤，所以近期的MTTDL優(yōu)化版本屏蔽了Markov鏈的劣勢，不使用這種方式建模；將指數(shù)分布優(yōu)化成，故障率可以動態(tài)調(diào)整的Weibull分布；考慮獨(dú)立扇區(qū)、相關(guān)性扇區(qū)的錯誤；考慮修復(fù)時長等NORMAL指標(biāo)。

MTTDL模型對不同系統(tǒng)設(shè)計的可靠性進(jìn)行優(yōu)劣評估，起到了非常大的作用。

4.EAFDL可靠性模型

圖片

MTTDL的定義是，平均系統(tǒng)的丟失數(shù)據(jù)的時長。它有兩個特點(diǎn)：第一，MTTDL越高，丟數(shù)據(jù)頻率越低；第二，它只關(guān)注丟失的頻率，不關(guān)注每次丟失數(shù)據(jù)的數(shù)量。

EAFDL的定義是，預(yù)期每年數(shù)據(jù)的丟失比例。EAFDL的定義更接近11個9的定義，因?yàn)?1個9的定義是平均每年對象的丟失率，所以EAFDL會比MTTDL會更貼近11個9的計算。

EAFDL的計算公式如上圖，它在MTTDL的基礎(chǔ)上，引入了丟失的平均數(shù)據(jù)量，它在mtdl的基礎(chǔ)之上，引入了丟失平均數(shù)據(jù)量在用戶總數(shù)的占比。

但在真實(shí)的場景下，EAFDL模型不一定會比MTTDL模型更好。

例如，F(xiàn)acebook曾經(jīng)公開了一篇論文，講到在大規(guī)模idc部署的情況之下，他們更傾向于控制丟失的頻率，而非丟失事件的數(shù)據(jù)量。因?yàn)槊看我驗(yàn)閬G失事件都會產(chǎn)生固定成本，而固定成本的影響較大。所以真實(shí)情況下，EAFDL模型不能完全替代MTTDL模型。

如果側(cè)重丟失的頻率，那么在平時系統(tǒng)設(shè)計時，可以不斷提高M(jìn)TTDL。如果大家設(shè)計的MTTDL都差不多，下一步才會考慮是否應(yīng)該讓EAFDL最小化。

如果側(cè)重丟失的數(shù)量，在系統(tǒng)測試時，可以不斷讓EAFDL最小化，同時讓MTTDL最大化。

四、實(shí)踐：存儲可靠性評估實(shí)踐

1.vivo可靠性建模思路

圖片

我們的建模思路對上述模型進(jìn)行取舍，取的是什么？我們將MTTDL的頻率維度、EAFDL的丟失量維度和數(shù)據(jù)分布系數(shù)，納入到建模思路。

舍的是什么？我們屏蔽了MTTDL的指數(shù)分布、扇區(qū)錯誤的建模，舍去了Markov鏈的建模。

2.vivo可靠型模型

圖片

上圖是整體建模的參數(shù)引入，和之前的參數(shù)是類似的。

區(qū)別在于，平時磁盤硬件廠商對外報AFR參數(shù)有兩個指標(biāo)：一個是MTBF，一個是AFR，我們將AFR引入到建模。同時，我們也參照了一家云端廠商Backblaze的公開模型介紹，他們利用泊松分布，模擬年度硬盤故障數(shù)量的分布?；谶@兩個角色，我們制作了副本和糾刪碼的可靠性模型。

圖片

建模同時，我們也使用了EAFDL的模型，并引入了丟失的數(shù)據(jù)量在整個用戶數(shù)據(jù)量的占比。

上圖右下角的表格，是我們基于副本模式進(jìn)行的實(shí)驗(yàn)數(shù)據(jù)。實(shí)驗(yàn)?zāi)康闹饕?，充分?yàn)證不同建模參數(shù)對可靠性的影響，進(jìn)而得出結(jié)論。部分結(jié)論可以從原理層面推斷，比如，AFR越小，可靠性越高；存儲利用率低，可靠性越高；修復(fù)帶寬越高，可靠性越高；副本和檢驗(yàn)位數(shù)越高，可靠性越高。

但是，機(jī)器數(shù)量越多，它的可靠性不一定越高；數(shù)據(jù)分布因子越大，可靠性會降低，需要我們在整個系統(tǒng)中進(jìn)行權(quán)衡。

3.可靠性評估平臺化建設(shè)

圖片

評估平臺的建設(shè)基于兩個原則：第一，需要評估新老方案的可靠性優(yōu)劣；第二，需要近實(shí)時地評估線上系統(tǒng)可靠性的風(fēng)險。

五、思考：存儲可靠性評估思考

1.方向思考

圖片

我們有兩個呼吁：

• 共享數(shù)據(jù)：現(xiàn)在各大提供分布式存儲的廠商之所以沒公開相關(guān)可靠性計算模型，是因?yàn)榻y(tǒng)計樣本數(shù)據(jù)不足。如果全行業(yè)能夠分享各自的部分統(tǒng)計數(shù)據(jù)，樣本量足夠大，就有希望建設(shè)最真實(shí)的評估模型。
• 統(tǒng)一標(biāo)準(zhǔn)：云存儲領(lǐng)域相關(guān)的牽頭企業(yè)，基于公司內(nèi)部的海量樣本數(shù)據(jù)，能夠分享一個比較權(quán)威的考勤評估模型，為業(yè)界提供指引。

IliasIliadis的論文非常有價值，他從2000年左右開始，在CTRQ發(fā)表眾多關(guān)于云存儲系統(tǒng)的可靠性模型研究。大家如果感興趣，可以搜索看看。

2.未來規(guī)劃

未來，我們可能會引入扇區(qū)錯誤因素，重新建模。

當(dāng)前沒有引入扇區(qū)錯誤，是因?yàn)槟壳皹I(yè)界提供的均值指標(biāo)，權(quán)威性還有待考證。扇區(qū)錯誤是磁盤里比較常見的錯誤，不一定是獨(dú)立的，可能具有相關(guān)性。所以后續(xù)等相應(yīng)指標(biāo)的真實(shí)性足夠后，我們會考慮進(jìn)行重新監(jiān)管。

• 軟件故障：自動化測試框架
• 數(shù)據(jù)損壞：自適應(yīng)Data-scrubbing
• 惡意竊?。篗FA-Delete特性
• 人為失誤：運(yùn)維自動化率進(jìn)一步提升、遵循POLP
• 硬件故障：進(jìn)一步提升故障預(yù)測+故障檢測+故障修復(fù)能力，進(jìn)一步設(shè)計糾刪碼方案使得可靠性+成本兼顧

Q&A

Q1：您覺得提升可靠性的工作中，近期哪一部分改進(jìn)的影響最大？

A1：近期我們建立了可靠性模型，為什么要建模？因?yàn)槲覀兡壳霸谶M(jìn)行糾刪碼的相關(guān)優(yōu)化，如果糾刪碼的冗余度偏低，就無法保證可靠性，所以我們建立了一套模型去評估。

當(dāng)然這個模型本身的量級不一定能達(dá)到11個9，但相對于線上這套系統(tǒng)，它可以看出好還是壞。建立這個模型，方便我們后續(xù)算法優(yōu)化時進(jìn)行參考。如果你的算法比較極端，比如下降的量級比較大，可能就要推翻算法，重新設(shè)計。

作者介紹

龔兵，vivo云存儲研發(fā)負(fù)責(zé)人。工作10余年，先后就職于華為、騰訊、百度，現(xiàn)在vivo擔(dān)任云存儲研發(fā)負(fù)責(zé)人，研究方向：對象存儲、文件存儲、NOSQL存儲等分布式存儲領(lǐng)域。