一 分布式存儲系統(tǒng)背景

副本是分布式存儲系統(tǒng)中的常見概念：將一定大小的數(shù)據(jù)按照一定的冗余策略存儲，以保障系統(tǒng)在局部故障情況下的可用性。

副本間的冗余復(fù)制方式有多種，比較常用有兩類：

• Pipeline：像個管道，a->b->c，通過管道的方式進行數(shù)據(jù)的復(fù)制。該方式吞吐較高，但有慢節(jié)點問題，某一節(jié)點出現(xiàn)擁塞，整個過程都會受影響
• 分發(fā)：client -> a client ->b client ->c。系統(tǒng)整體吞吐較低，但無慢節(jié)點問題

[[249877]]

對于冗余副本數(shù)目，本文選擇常見的三副本方案。

分布式存儲系統(tǒng)一般擁有自動恢復(fù)副本的功能，在局部存儲節(jié)點出錯時，其他節(jié)點（數(shù)據(jù)副本的主控節(jié)點或者client節(jié)點，依副本復(fù)制協(xié)議而定）自動發(fā)起副本修復(fù)，將該宕機存儲節(jié)點上的數(shù)據(jù)副本恢復(fù)到其他健康節(jié)點上。在少量宕機情況下，集群的副本自動修復(fù)策略會正常運行。但依照大規(guī)模存儲服務(wù)運維經(jīng)驗，月百分之X的磁盤故障率和月千分之X的交換機故障率有很大的可能性導(dǎo)致一年當中出現(xiàn)幾次機器數(shù)目較多的宕機。另外，批量升級過程中若出現(xiàn)了升級bug，集群按照宕機處理需要進行副本修復(fù)，導(dǎo)致原本正常時間內(nèi)可以完成的升級時間延長，也容易出現(xiàn)數(shù)目較多的宕機事件。

二 雪崩效應(yīng)的產(chǎn)生

在一段時間內(nèi)數(shù)目較多的宕機事件有較大可能性誘發(fā)系統(tǒng)的大規(guī)模副本補全策略。目前的分布式存儲系統(tǒng)的兩個特點導(dǎo)致這個大規(guī)模副本補全策略容易讓系統(tǒng)產(chǎn)生雪崩效應(yīng)：

a. 集群整體的free空間較小：通常整體<=30%, 局部機器小于<=20% 甚至10%

b. 應(yīng)用混布：不同的應(yīng)用部署在同一臺物理/虛擬機器上以***化利用硬件資源

今年火起來的各種網(wǎng)盤、云盤類服務(wù)就是a的典型情況。在各大公司拼個人存儲容量到1T的背后，其實也在拼運營成本、運維成本。現(xiàn)有的云存儲大多只增不減、或者根據(jù)數(shù)據(jù)冷熱程度做數(shù)據(jù)分級（類似Facebook的數(shù)據(jù)分級項目）。云存儲總量大，但增量相對小，為了減少存儲資源和帶寬資源浪費，新創(chuàng)建的文件若原有的存儲數(shù)據(jù)中已有相同的md5或者sha1簽名則當做已有文件做內(nèi)部鏈接，不再進行新文件的創(chuàng)建。但即使這樣，整體的數(shù)據(jù)量還是很大。

目前云存儲相關(guān)業(yè)務(wù)未有明顯的收入來源，每年卻有數(shù)萬每臺的服務(wù)器成本，為運營成本的考慮，后端分布式存儲系統(tǒng)的空閑率很低。而瞬間的批量宕機會帶來大量的副本修復(fù)，大量的副本修復(fù)很有可能繼而打滿原本就接近存儲quota的其他存活機器，繼而讓該機器處于宕機或者只讀狀態(tài)。如此繼續(xù)，整個集群可能雪崩，系統(tǒng)殘廢。

三 預(yù)防雪崩

本節(jié)主要討論如何在系統(tǒng)內(nèi)部的邏輯處理上防止系統(tǒng)整體雪崩的發(fā)生。預(yù)防的重要性大于事故之后的處理，預(yù)測集群狀態(tài)、提前進行優(yōu)化也成為預(yù)防雪崩的一個方向。

下面選取曾經(jīng)發(fā)生過的幾個實際場景與大家分享。

1. 跨機架副本選擇算法和機器資源、用戶邏輯隔離

現(xiàn)場還原：

某天運維同學(xué)發(fā)現(xiàn)某集群幾十臺機器瞬間失聯(lián)，負責(zé)觸發(fā)修復(fù)副本的主控節(jié)點開始進行瘋狂的副本修復(fù)。大量用戶開始反饋集群變慢，讀寫夯住。

現(xiàn)場應(yīng)對:

優(yōu)先解決——副本修復(fù)量過大造成的集群整體受影響。

a. 處理的工程師當機立斷，gdb到進程更改修復(fù)副本的條件為副本<2，而非原本的3（replicas_num），讓主控節(jié)點這個時候僅修復(fù)副本數(shù)小于2個的文件，即保證未丟失的文件有至少一個冗余副本，防止只有一個副本的數(shù)據(jù)因可能再次發(fā)生的掛機造成文件丟失。

b. 緊急解決這批機器失聯(lián)問題，發(fā)現(xiàn)是交換機問題，a.b.c.d ip網(wǎng)段的c網(wǎng)段機器批量故障。催促網(wǎng)絡(luò)組盡快修復(fù)。

c. 副本修復(fù)到>=2之后，Gdb更改檢測副本不足周期，將幾十秒的檢測時間推遲到1天。等待網(wǎng)絡(luò)組解決交換機問題。

d. 網(wǎng)絡(luò)恢復(fù)，原有的機器重新加入集群。大量2副本文件重新變?yōu)?副本，部分3副本全丟失文件找回。

e. 恢復(fù)主控節(jié)點到正常參數(shù)設(shè)置狀態(tài)，系統(tǒng)開始正常修復(fù)。

改進措施:

在改進措施前，先分析下這次事件暴露的系統(tǒng)不足：

1) Master參數(shù)不支持熱修正，Gdb線上進程風(fēng)險過大。

2) 一定數(shù)量但局域性的機器故障影響了整體集群（幾十臺相對一個大集群仍屬于局域性故障）。如上所述，月千分之幾的故障率總有機會讓你的存儲系統(tǒng)經(jīng)歷一次交換機故障帶來的集群影響。

案例分析后的改進措施出爐：

1) Master支持熱修正功能排期提前，盡早支持核心參數(shù)的熱修改。

熱修改在上線后的效果可觀，后續(xù)規(guī)避過數(shù)次線上問題。

2) 在選擇數(shù)據(jù)副本存儲宿主機器的pickup算法中加入跨交換機（機架位）策略，強制——或者盡量保證——副本選擇時跨機架位。這種算法底下的副本，至少有1個副本與其他兩個副本處于不同的交換機下（IP a.b.c.d的c段）。該措施同時作用于新的存儲數(shù)據(jù)副本選擇和副本缺失后的副本補全策略，能在副本宿主選擇上保證系統(tǒng)不會因為交換機的宕機而出現(xiàn)數(shù)據(jù)丟失，進而避免一直處于副本補全隊列/列表的大量的丟失副本節(jié)點加重主控節(jié)點負載。

3) 機器按region劃分隔離功能提上日程；用戶存儲位置按照region進行邏輯劃分功能提上日程；Pickup算法加入跨region提上日程。

a) 機器按照物理位置劃分region、用戶按照region進行邏輯存儲位置劃分，能讓集群在局部故障的情況下僅影響被邏輯劃分進使用這部分機器的用戶。

這樣一來，最壞情況無非是這個region不可用，導(dǎo)致?lián)碛羞@個region讀寫權(quán)限的用戶受影響。Pickup算法跨region的設(shè)計進一步保證被劃分region的用戶不會因為一個region不可用而出現(xiàn)數(shù)據(jù)丟失，因為其他副本存到其他region上了。于是，核心交換機故障導(dǎo)致一個region數(shù)百臺機器的宕機也不會對集群造成范圍過大的影響了。

b) 增加region可信度概念，將機器的穩(wěn)定性因素加入到副本冗余算法中。

當集群規(guī)模達到一定量后，會出現(xiàn)機器穩(wěn)定性不同的問題（一般來說，同一批上線的機器穩(wěn)定性一致）。通過標記region的穩(wěn)定性，能強制在選擇數(shù)據(jù)副本的時候?qū)⒅辽僖粋€副本至于穩(wěn)定副本中，減少全部副本丟失的概率。

c) Region劃分需要綜合考慮用戶操作響應(yīng)時間SLA、物理機器穩(wěn)定情況、地理位置等信息。

合理的region劃分對提升系統(tǒng)穩(wěn)定性、提升操作相應(yīng)時間、預(yù)防系統(tǒng)崩潰都有益處。精巧的劃分規(guī)則會帶來整體的穩(wěn)定性提升，但也增加了系統(tǒng)的復(fù)雜度。這塊如何取舍，留給讀者朋友深入思考了。

2. 讓集群流控起來

流控方面有個通用且符合分布式存儲系統(tǒng)特點的原則：任何操作都不應(yīng)占用過多的處理時間。這里的“任何操作”包含了在系統(tǒng)出現(xiàn)流量激增、局部達到一定數(shù)量的機器宕機時進行的操作。只有平滑且成功的處理這些操作，才能保證系統(tǒng)不因為異常而出現(xiàn)整體受影響，甚至雪崩。

現(xiàn)場還原：

1) 場景1 某天運維同學(xué)發(fā)現(xiàn)，集群寫操作在某段時間大增。通過觀察某個存儲節(jié)點，發(fā)現(xiàn)不僅是寫、而且是隨機寫！某些產(chǎn)品線的整體吞吐下降了。

2) 場景2 某集群存儲大戶需要進行業(yè)務(wù)調(diào)整，原有的數(shù)據(jù)做變更，大量數(shù)據(jù)需要刪除。

運維同學(xué)發(fā)現(xiàn)，a. 整個集群整體上處于瘋狂gc垃圾回收階段 b. 集群響應(yīng)速度明顯變慢，特別是涉及到meta元信息更新的操作。

3) 場景3 某天運維同學(xué)突然發(fā)現(xiàn)集群并發(fā)量激增，單一用戶xyz進行了大量的并發(fā)操作，按照原有的用戶調(diào)研，該用戶不應(yīng)該擁有如此規(guī)模的使用場景。

此類集群某些操作預(yù)期外的激增還有很多，不再累述。

現(xiàn)場應(yīng)對:

1) 立刻電聯(lián)相關(guān)用戶，了解操作激增原因，不合理的激增需要立刻處理。

我們發(fā)現(xiàn)過如下不合理的激增：

a. 場景1類：通過Review代碼發(fā)現(xiàn)，大量的操作進行了隨機讀寫更改。建議用戶將隨機讀寫轉(zhuǎn)換為讀取后更改+寫新文件+刪除舊文件，轉(zhuǎn)換隨機讀寫為順序讀寫。

b. 場景3類：某產(chǎn)品線在線上進行了性能測試。運維同學(xué)立刻通知該產(chǎn)品線停止了相關(guān)操作。所有公有集群再次發(fā)通過郵件強調(diào)，不可用于性能測試。如有需要，聯(lián)系相關(guān)人員在獨占集群進行性能場景測試。

2) 推動設(shè)計和實現(xiàn)集群各個環(huán)節(jié)的流控機制功能并上線。

改進措施：

1) 用戶操作流控

a. 對用戶操作進行流控限制

可通過系統(tǒng)內(nèi)部設(shè)計實現(xiàn)，也可通過外部的網(wǎng)絡(luò)限流等方式實現(xiàn)，對單用戶做一定的流控限制，防止單個用戶占用過多整個集群的資源。

b. 存儲節(jié)點操作流控

可按照對集群的資源消耗高低分為High – Medium – Low三層，每層實現(xiàn)類似于搶token的設(shè)計，每層token數(shù)目在集群實踐后調(diào)整為比較適合的值。這樣能防止某類操作過多消耗集群負載。若某類操作過多消耗負載，其他操作類的請求有較大delay可能，繼而引發(fā)timeout后的重試、小范圍的崩潰，有一定幾率蔓延到整個集群并產(chǎn)生整體崩潰。

c. 垃圾回收gc單獨做流控處理。刪除操作在分布式存儲系統(tǒng)里面常用設(shè)計是：接收到用戶刪除操作時，標記刪除內(nèi)容的meta信息，直接回返，后續(xù)進行策略控制，限流的刪除，防止大量的gc操作消耗過多單機存儲節(jié)點的磁盤處理能力。具體的限流策略和token值設(shè)置需要根據(jù)集群特點進行實踐并得出較優(yōu)設(shè)置。

2) 流控黑名單

用戶因為對線上做測試類的場景可以通過人為制度約束，但無法避免線上用戶bug導(dǎo)致效果等同于線上測試規(guī)模的場景。這類的場景一般在短時間內(nèi)操作數(shù)嚴重超過限流上限。

對此類場景可進行流控黑名單設(shè)置，當某用戶短時間內(nèi)（e.g. 1小時）嚴重超過設(shè)置的上限時，將該用戶加入黑名單，暫時阻塞操作。外圍的監(jiān)控會通知運維組同學(xué)緊急處理。

3) 存儲節(jié)點并發(fā)修復(fù)、創(chuàng)建副本流控

大量的數(shù)據(jù)副本修復(fù)操作或者副本創(chuàng)建操作如果不加以速度限制，將占用存儲節(jié)點的帶寬和CPU、內(nèi)存等資源，影響正常的讀寫服務(wù)，出現(xiàn)大量的延遲。而大量的延遲可能引發(fā)重試，加重集群的繁忙程度。

同一個數(shù)據(jù)宿主進程需要限制并發(fā)副本修復(fù)、副本創(chuàng)建的個數(shù)，這樣對入口帶寬的占用不會過大，進程也不會因為過量進行這類操作而增加大量其他操作的延遲時間。這對于采用分發(fā)的副本復(fù)制協(xié)議的系統(tǒng)尤其重要。分發(fā)協(xié)議一般都有慢節(jié)點檢查機制，副本流控不會進一步加重系統(tǒng)延遲而增大成為慢節(jié)點的可能。如果慢節(jié)點可能性增大，新創(chuàng)建的文件可能在創(chuàng)建時就因為慢節(jié)點檢查機制而缺少副本，這會讓集群狀況更加惡化。

3. 提前預(yù)測、提前行動

1) 預(yù)測磁盤故障，容錯單磁盤錯誤。

場景復(fù)現(xiàn)：

某廠商的SSD盤某批次存在問題，集群上線運行一段時間后，局部集中出現(xiàn)數(shù)量較多的壞盤，但并非所有的盤都損壞。當時并未有單磁盤容錯機制，一塊磁盤壞掉，整個機器就被置成不可用狀態(tài)，這樣導(dǎo)致?lián)碛羞@批壞盤的機器都不可用，集群在一段時間內(nèi)都處于副本修復(fù)狀態(tài)，吞吐受到較大影響。

改進措施:

a) 對硬盤進行健康性預(yù)測，自動遷移大概率即將成為壞盤的數(shù)據(jù)副本

近年來，對磁盤健康狀態(tài)進行提前預(yù)測的技術(shù)越來越成熟，技術(shù)上已可以預(yù)判磁盤健康程度并在磁盤擁有大概率壞掉前，自動遷移數(shù)據(jù)到其他磁盤，減少磁盤壞掉對系統(tǒng)穩(wěn)定性的影響。

b) 對單硬盤錯誤進行容錯處理

存儲節(jié)點支持對壞盤的異常處理。單盤掛掉時，自動遷移/修復(fù)單盤的原有數(shù)據(jù)到其他盤，而不是進程整體宕掉，因為一旦整體宕掉，其他盤的數(shù)據(jù)也會被分布式存儲系統(tǒng)當做缺失副本，存儲資源緊張的集群經(jīng)歷一次這樣的宕機事件會造成長時間的副本修復(fù)過程。在現(xiàn)有的分布式存儲系統(tǒng)中, 也有類似淘寶TFS那樣，每個磁盤啟動一個進程進行管理，整機掛載多少個盤就啟動多少個進程。

2) 根據(jù)現(xiàn)有存儲分布，預(yù)測均衡性發(fā)展，提前進行負載均衡操作。

這類的策略設(shè)計越來越常見。由于分布式存儲集群掛機后的修復(fù)策略使得集群某些機器總有幾率成為熱點機器，我們可以對此類的機器進行熱點預(yù)測，提前遷移部分數(shù)據(jù)到相對負載低的機器。

負載均衡策略和副本選擇策略一樣，需要取舍復(fù)雜度和優(yōu)化程度問題。復(fù)雜的均衡策略帶來好的集群負載，但也因此引入高復(fù)雜度、高bug率問題。如何取舍，仍舊是個困擾分布式存儲系統(tǒng)設(shè)計者的難題。

四 安全模式

安全模式是項目實踐過程中產(chǎn)生的防分布式存儲系統(tǒng)雪崩大殺器，因此我特別將其單獨列為一節(jié)介紹。其基本思路是在一定時間內(nèi)宕機數(shù)目超過預(yù)期上限則讓集群進入安全模式，按照策略配置、情況嚴重程度，停止修復(fù)副本、停止讀寫，直到停止一切操作（一般策略）。

在沒有機器region概念的系統(tǒng)中，安全模式可以起到很好的保護作用。我過去參與的一個項目經(jīng)歷的某次大規(guī)模宕機，由于沒有安全模式，系統(tǒng)進行正常的處理副本修復(fù)，生生將原本健康的存儲節(jié)點也打到殘廢，進而雪崩，整個集群都陷入瘋狂副本修復(fù)狀態(tài)。這種狀態(tài)之后的集群修復(fù)過程會因為已發(fā)生的副本修復(fù)導(dǎo)致的元信息/實際數(shù)據(jù)的更改而變的困難重重。 該事件***結(jié)局是數(shù)據(jù)從冷備數(shù)據(jù)中恢復(fù)了一份，丟失了冷備到故障發(fā)生時間的數(shù)據(jù)。

當然，安全模式并非***無缺。“一段時間”、“上限”該如何設(shè)置、什么時候停副本修復(fù)、什么時候停讀、什么時候停寫、是自己恢復(fù)還是人工干預(yù)恢復(fù)到正常狀態(tài)、安全模式力度是否要到region級別，這些問題都需要安全模式考慮，而此類的設(shè)計一般都和集群設(shè)計的目標用戶息息相關(guān)。舉例，如果是低延遲且業(yè)務(wù)敏感用戶，可能會選擇小規(guī)模故障不能影響讀寫，而高延遲、高吞吐集群就可以接受停讀寫。

五 思考

由于分布式存儲系統(tǒng)的復(fù)雜性和篇幅所限，本文僅選擇有限個典型場景進行了分析和討論， 真實的分布式存儲系統(tǒng)遠比這數(shù)個案例復(fù)雜的多、細節(jié)的多。如何平衡集群異常自動化處理和引入的復(fù)雜度，如何較好的實現(xiàn)流控和避免影響低延遲用戶的響應(yīng)時間，如何引導(dǎo)集群進行負載均衡和避免因負載均衡帶來的過量集群資源開銷，這類問題在真實的分布式存儲系統(tǒng)設(shè)計中層出不窮。如果設(shè)計者是你，你會如何取舍呢？