如何預(yù)防處理大數(shù)據(jù)雪崩?

快資訊
大數(shù)據(jù)觀察
本文主要討論如何在系統(tǒng)內(nèi)部的邏輯處理上防止系統(tǒng)整體雪崩的發(fā)生。預(yù)防的重要性大于事故之后的處理,預(yù)測集群狀態(tài)、提前進(jìn)行優(yōu)化也成為預(yù)防雪崩的一個(gè)方向。 下面選取曾經(jīng)發(fā)生過的幾個(gè)實(shí)際場景與大家分享。...

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

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

1. 跨機(jī)架副本選擇算法和機(jī)器資源、用戶邏輯隔離現(xiàn)場還原:

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

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

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

a. 處理的工程師當(dāng)機(jī)立斷,gdb到進(jìn)程更改修復(fù)副本的條件為副本

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

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

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

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

改進(jìn)措施:

在改進(jìn)措施前,先分析下這次事件暴露的系統(tǒng)不足:

(1) Master參數(shù)不支持熱修正,Gdb線上進(jìn)程風(fēng)險(xiǎn)過大。

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

案例分析后的改進(jìn)措施出爐:

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

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

(2) 在選擇數(shù)據(jù)副本存儲(chǔ)宿主機(jī)器的pickup算法中加入跨交換機(jī)(機(jī)架位)策略,強(qiáng)制——或者盡量保證——副本選擇時(shí)跨機(jī)架位。這種算法底下的副本,至少有1個(gè)副本與其他兩個(gè)副本處于不同的交換機(jī)下(IP a.b.c.d的c段)。

該措施同時(shí)作用于新的存儲(chǔ)數(shù)據(jù)副本選擇和副本缺失后的副本補(bǔ)全策略,能在副本宿主選擇上保證系統(tǒng)不會(huì)因?yàn)榻粨Q機(jī)的宕機(jī)而出現(xiàn)數(shù)據(jù)丟失,進(jìn)而避免一直處于副本補(bǔ)全隊(duì)列/列表的大量的丟失副本節(jié)點(diǎn)加重主控節(jié)點(diǎn)負(fù)載。

(3) 機(jī)器按region劃分隔離功能提上日程;用戶存儲(chǔ)位置按照region進(jìn)行邏輯劃分功能提上日程;Pickup算法加入跨region提上日程。

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

這樣一來,最壞情況無非是這個(gè)region不可用,導(dǎo)致?lián)碛羞@個(gè)region讀寫權(quán)限的用戶受影響。Pickup算法跨region的設(shè)計(jì)進(jìn)一步保證被劃分region的用戶不會(huì)因?yàn)橐粋€(gè)region不可用而出現(xiàn)數(shù)據(jù)丟失,因?yàn)槠渌北敬娴狡渌鹯egion上了。于是,核心交換機(jī)故障導(dǎo)致一個(gè)region數(shù)百臺(tái)機(jī)器的宕機(jī)也不會(huì)對(duì)集群造成范圍過大的影響了。

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

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

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

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

2. 讓集群流控起來流控方面有個(gè)通用且符合分布式存儲(chǔ)系統(tǒng)特點(diǎn)的原則:任何操作都不應(yīng)占用過多的處理時(shí)間。這里的“任何操作”包含了在系統(tǒng)出現(xiàn)流量激增、局部達(dá)到一定數(shù)量的機(jī)器宕機(jī)時(shí)進(jìn)行的操作。只有平滑且成功的處理這些操作,才能保證系統(tǒng)不因?yàn)楫惓6霈F(xiàn)整體受影響,甚至雪崩。

現(xiàn)場還原:

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

(2) 場景2 某集群存儲(chǔ)大戶需要進(jìn)行業(yè)務(wù)調(diào)整,原有的數(shù)據(jù)做變更,大量數(shù)據(jù)需要?jiǎng)h除。

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

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

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

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

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

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

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

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

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

改進(jìn)措施:

(1) 用戶操作流控

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

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

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

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

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

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

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

3. 提前預(yù)測、提前行動(dòng)1) 預(yù)測磁盤故障,容錯(cuò)單磁盤錯(cuò)誤。

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

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

改進(jìn)措施:

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

(b) 對(duì)單硬盤錯(cuò)誤進(jìn)行容錯(cuò)處理存儲(chǔ)節(jié)點(diǎn)支持對(duì)壞盤的異常處理。單盤掛掉時(shí),自動(dòng)遷移/修復(fù)單盤的原有數(shù)據(jù)到其他盤,而不是進(jìn)程整體宕掉,因?yàn)橐坏┱w宕掉,其他盤的數(shù)據(jù)也會(huì)被分布式存儲(chǔ)系統(tǒng)當(dāng)做缺失副本,存儲(chǔ)資源緊張的集群經(jīng)歷一次這樣的宕機(jī)事件會(huì)造成長時(shí)間的副本修復(fù)過程。在現(xiàn)有的分布式存儲(chǔ)系統(tǒng)中, 也有類似淘寶TFS那樣,每個(gè)磁盤啟動(dòng)一個(gè)進(jìn)程進(jìn)行管理,整機(jī)掛載多少個(gè)盤就啟動(dòng)多少個(gè)進(jìn)程。

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

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

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

THEEND

最新評(píng)論(評(píng)論僅代表用戶觀點(diǎn))

更多
暫無評(píng)論