我今天分享的題目是：“如何打造具備極致容災(zāi)能力的對象存儲”。

容災(zāi)是分布式存儲領(lǐng)域的一個關(guān)鍵問題。

最基礎(chǔ)的是對服務(wù)器的容災(zāi)，這是所有對象存儲產(chǎn)品都要解決的問題。

進(jìn)一步，就是AZ（Availability Zone）級故障容災(zāi)，AZ也就是可用區(qū)。通常一個可用區(qū)會映射到一個或者多個數(shù)據(jù)中心。一個AZ和其他AZ在制冷、供電等方面都是故障域隔離的。幾大云廠商也都提供支持AZ級容災(zāi)的對象存儲產(chǎn)品。

可能有的同學(xué)會問，做AZ級容災(zāi)是不是有必要？大家如果去網(wǎng)上去搜索一下就會發(fā)現(xiàn)，各大云廠商的AZ級故障還是時有發(fā)生的，包括一些不可抗災(zāi)害或者制冷、供電中斷等故障。從底層邏輯上來講，AZ級故障是不可能徹底避免的。對于一些高可用的應(yīng)用，采用具備AZ級容災(zāi)能力的存儲產(chǎn)品還是非常有必要的。

Region故障也是同樣的道理。每個AZ之間會間隔幾十公里，但是在一些極端場景，比如高等級地震的時候，那同時影響到一個Region的多可用區(qū)也是有可能的。比如最近土耳其7、8級地震，它是有可能導(dǎo)致Region級故障的。各家廠商也有提供一些應(yīng)對Region故障的產(chǎn)品或者說解決方案，對象存儲OSS也有類似的產(chǎn)品，后面會介紹。

本次分享。首先會介紹我們在本地冗余，也就是LRS（本地冗余）這個產(chǎn)品做了哪些容災(zāi)設(shè)計(jì)，其次，我會介紹我們應(yīng)對AZ故障的ZRS（同城冗余）產(chǎn)品的容災(zāi)設(shè)計(jì)，第三部分是應(yīng)對Region故障的跨區(qū)域復(fù)制功能。在第二、第三部分我分別以案例深入介紹我們在技術(shù)上做的一些改進(jìn)或者設(shè)計(jì)。最后分享我們是如何以智能運(yùn)維平臺來應(yīng)對生產(chǎn)過程中系統(tǒng)長時間運(yùn)行以后架構(gòu)腐化的問題。

一、LRS(本地冗余產(chǎn)品)的容災(zāi)設(shè)計(jì)

這個圖左邊是我們OSS系統(tǒng)模塊的劃分圖，從上到下大致可以分為四層。

用戶請求進(jìn)來之后，首先會到達(dá)我們的負(fù)載均衡，也就是AliLB，AliLB是阿里自研的高性能的負(fù)載均衡產(chǎn)品，它是基于LVS原理的。

往下請求會來到業(yè)務(wù)層，在這一層主要是做協(xié)議的解析、各種各樣的業(yè)務(wù)功能的實(shí)現(xiàn)。這兩層我們都是一個無狀態(tài)的設(shè)計(jì)。在這種無狀態(tài)的服務(wù)里面如何做高可用的呢？我們會把它的部署按機(jī)架來打散并保證兩個機(jī)架故障情況下，它的服務(wù)能力還是足夠的。

再往下，請求就會來到索引層，索引層我們叫做KV，是一個Master Server結(jié)構(gòu)。每個Server又根據(jù)字典序劃分為多個分區(qū)，它的Master跟每個分區(qū)的Server都是采用Raft協(xié)議實(shí)現(xiàn)的一致性組。

底下就是存儲服務(wù)盤古，它跟KV類似，也是一個Master Server的結(jié)構(gòu)。區(qū)別是它的Server沒有采用一致性組的架構(gòu)，主要是性能考慮。另外在高可靠上是通過副本或者EC機(jī)制來做的。

在LRS產(chǎn)品里，阿里云整體的容災(zāi)設(shè)計(jì)目標(biāo)是希望做到兩個機(jī)架故障不影響服務(wù)的可用性和可靠性。

剛才已經(jīng)提到了無狀態(tài)服務(wù)，對有狀態(tài)服務(wù)的話，他們的一致性組，我們都是采用五節(jié)點(diǎn)部署的。這五個節(jié)點(diǎn)會打散部署在至少五個機(jī)架上。這樣顯而易見：如果說故障兩個機(jī)架，還是有多數(shù)節(jié)點(diǎn)存活，還可以提供服務(wù)。

數(shù)據(jù)方面，我們有兩種數(shù)據(jù)的存放形式，有三副本，也有EC。三副本的話，只要做了機(jī)架打散，顯然是可以實(shí)現(xiàn)兩機(jī)架的容災(zāi)的。對于EC，我們也會保證它的校驗(yàn)塊的數(shù)量大于等于二。同樣也是做機(jī)架打散，能實(shí)現(xiàn)兩個機(jī)架故障不影響可用性可靠性。

除了這些數(shù)據(jù)的分散方式，我們還做了非常多的其他的設(shè)計(jì)來保障高可用。比如數(shù)據(jù)分片是做全機(jī)群打散的，這樣做有什么好處呢？如果一臺服務(wù)器發(fā)生故障，如果做全打散的話，是可以利用這個集群里剩余的所有機(jī)器來并行的做數(shù)據(jù)修復(fù)，這樣縮短了數(shù)據(jù)的重建時間，相應(yīng)的也就提高了可靠性。

另外，我們也會剛性的保留足夠的復(fù)制帶寬。所有的這些，包括集群水位，副本的配置，包括打散方式，還有復(fù)制帶寬，我們都會用一個模型來去計(jì)算并且測試驗(yàn)證它的可靠性，保障設(shè)計(jì)達(dá)到12個9的可靠性。

二、ZRS（同城冗余）產(chǎn)品容災(zāi)設(shè)計(jì)

通俗來說，OSS ZRS（同城冗余）產(chǎn)品，也叫3AZ型態(tài)。它和LRS最主要的區(qū)別就是在容災(zāi)設(shè)計(jì)目標(biāo)上，LRS要容忍兩個機(jī)架故障，ZRS則是要保證一個AZ外加一個機(jī)架故障時不影響可靠性可用性。

稍微提一下，假設(shè)你一個AZ故障發(fā)生以后，如果修復(fù)時間相對比較長，那再壞一臺機(jī)器的概率還是比較高的。如果在容災(zāi)設(shè)計(jì)上只容忍1AZ的話，最后因?yàn)锳Z修復(fù)期間單臺服務(wù)器的故障影響了可用性，那就有點(diǎn)得不償失了，所以我們在設(shè)計(jì)上特意采用了1AZ加額外一機(jī)架的故障容忍的設(shè)計(jì)目標(biāo)。

再來講講怎么實(shí)現(xiàn)容災(zāi)設(shè)計(jì)的。

在模塊劃分上ZRS和LRS基本是一樣的。主要的區(qū)別是模塊的打散方式，在LRS里都是跨機(jī)架打散，在ZRS里，我們會把它升級到跨AZ打散，所有的模塊都是跨AZ部署的。當(dāng)然在AZ內(nèi)還是會做機(jī)架級的打散的。

關(guān)于有狀態(tài)服務(wù)。有狀態(tài)服務(wù)的一致性組在LRS 都采用5節(jié)點(diǎn)部署，ZRS產(chǎn)品里面就會變?yōu)?節(jié)點(diǎn)。9個節(jié)點(diǎn)會均勻打散到3個AZ，每個AZ有3個節(jié)點(diǎn)。這個設(shè)計(jì)是可以容忍4個節(jié)點(diǎn)故障的。也就是說可以容忍“1AZ+剩下兩個AZ里的某個節(jié)點(diǎn)故障”。

在數(shù)據(jù)的高可靠方面，前面提過我們有3副本的EC。3副本顯而易見，只要做了AZ打散，是可以容忍剛才提到的容災(zāi)設(shè)計(jì)目標(biāo)的。EC是要做比較大的EC配置的重新設(shè)計(jì)。理論上，3個AZ要容忍1個AZ故障，那數(shù)據(jù)冗余至少要1.5倍。實(shí)際上早期我們采用6+6的EC配置，大家可以理解一個數(shù)據(jù)集，把它拆分為6個數(shù)據(jù)塊+6個校驗(yàn)塊，平均分布到3個AZ，每個AZ有4個塊。這樣一個AZ故障的時候，一個數(shù)據(jù)集里還剩余8個塊，其實(shí)只要有6個就可以恢復(fù)數(shù)據(jù)了。所以，這個時候還可以再容忍2個機(jī)架故障，相比于容災(zāi)設(shè)計(jì)目標(biāo)是有一定的超配。

當(dāng)然，做了這樣的設(shè)計(jì)之后，看起來是可以容忍“1AZ+額外1機(jī)架故障不影響可用性可靠性”，但實(shí)際沒這么簡單。

實(shí)際的運(yùn)行過程中還要考慮到非常多的其他因素。比如如何解決跨AZ的超高吞吐的帶寬需求？AZ間的延遲顯然是要比AZ內(nèi)的延遲高很多，如何通過系統(tǒng)的設(shè)計(jì)盡量讓這個延遲的增加不影響到用戶？又比如說在1個AZ故障的時候，本來就有1/3的機(jī)器不可服務(wù)的，如果還要再做數(shù)據(jù)重建，那又帶來非常大的IO放大。如何保證在AZ故障時候的高質(zhì)量的服務(wù)？是有非常大的挑戰(zhàn)的。

 接下來以剛才提到的最后這個挑戰(zhàn)為例來做一個相對深入的介紹。

下圖左邊是一個示意圖，我們前面提到了，我們早期是用6+6的EC編碼。我們采用的是RS的編碼。在單個AZ故障的時候剩余8個塊提供服務(wù)，其中4個數(shù)據(jù)塊+4個校驗(yàn)塊。

簡單計(jì)算一下，在這種AZ故障的情況下，單臺機(jī)器或者單塊磁盤承受的IO壓力，相比在故障前日常情況下大概是什么水平。

發(fā)生故障的時候，顯而易見是有2/3的數(shù)據(jù)是可以直接讀取的，也就是說1份IO沒有放大。另外有1/3是要通過rebuild來做重建的。重建的話，RS編碼至少要讀6塊數(shù)據(jù)，不考慮額外的校驗(yàn)也要讀6塊數(shù)據(jù)才能重建。也就是說有1/3的數(shù)據(jù)是要讀6塊才能重建。再考慮故障期間只有2/3的機(jī)器提供服務(wù)。

右上角有一個簡單的算式，可以看到，故障期間每臺機(jī)器或者每塊盤承受的IO壓力是日常的4倍。換個角度來解讀一下，如果這個機(jī)器的IO能力是100%的話，那要保證在故障以后還是高可用的，日常最多只能用到它IO能力的25%?？紤]還要留一定的安全水位，假設(shè)打個八折，那可能就只有20%了，這個數(shù)據(jù)顯而易見是非?？鋸埖模o我們帶來一個很大的挑戰(zhàn)：要么讓ZRS產(chǎn)品相比LRS只能提供低的多的IO能力，要不然就是要承受高的多的成本。

正因?yàn)橛羞@樣的挑戰(zhàn)，所以EC的編碼方式，尤其是在同城冗余型態(tài)下EC的編碼方式一直是我們持續(xù)投入的研究或者改進(jìn)的方向，我們也做了非常多的工作，提出了自己獨(dú)創(chuàng)的AZC的編碼，這個編碼算法本身也有在頂會中發(fā)表論文。

這里對它做一個簡單的介紹。

簡單來說，AZC編碼就是把原本1維的EC編碼升級成了2維。水平方向，是一個AZ間的編碼，我們首先會把一些數(shù)據(jù)塊劃分為多個小組。每個小組內(nèi)，如果以上圖左側(cè)的示意圖為例，每個小組是“2個數(shù)據(jù)片+1個校驗(yàn)片”做了一個2+1的RS編碼。用小的EC配比有一個好處，在AZ故障的時候重建代價小，相比前面要讀6份重建，現(xiàn)在只要讀2份就可以了。

當(dāng)然這種小配比的EC也是有缺點(diǎn)的，代價就是它的容災(zāi)能力差，可靠性低。因?yàn)橹灰?個機(jī)架故障，丟掉2個分片，它的數(shù)據(jù)就無法恢復(fù)了，這顯然是不可接受的。所以在垂直方向，也就是AZ內(nèi)，我們又把多個分組內(nèi)的數(shù)據(jù)塊結(jié)合到一起，額外做了一個垂直方向的編碼。通常，比如說用12個片，額外再加2-3個校驗(yàn)塊做一個RS編碼，兩者結(jié)合起來就能在12個9可靠性的前提下，仍然能保證在AZ故障的時候重建的IO放大是比較小的。

當(dāng)然AZC也不只是AZ故障重建代價低的好處。通過一些仔細(xì)的編碼配比的選擇，它的數(shù)據(jù)冗余相比前面提到的6+6 EC也是要好非常多的。

前面也提到，我們會在垂直方向做一個AZ內(nèi)的RS編碼。這也就是說日常情況下，如果AZ內(nèi)有機(jī)器故障，是可以在AZ內(nèi)本地重建的，可以完全避免跨機(jī)房的重建流量。也就是說，AZC編碼其實(shí)是在AZ的故障重建代價和數(shù)據(jù)冗余的成本和日常的跨機(jī)房重建流量這三個方面取得了一個比較好的平衡。相比6+6 RS編碼提升是巨大的，根據(jù)這個公式簡單算一下，流量放大倍數(shù)從4降到了2，換句話說，也就是說IO利用能力提升了整整1倍。

近幾年，從ZRS產(chǎn)品業(yè)務(wù)情況上的觀察，越來越多的客戶開始重視AZ級容災(zāi)能力，使用ZRS的比例越來越高。在香港故障以后，很多客戶把他們的數(shù)據(jù)存儲轉(zhuǎn)到了ZRS型態(tài)上。很多本身已經(jīng)在用LRS的客戶，也想無縫的升級到ZRS。

針對這些需求，結(jié)合前面做的各種技術(shù)改進(jìn)，阿里云推出了兩個大的升級。第一，將以前不支持歸檔型的ZRS 升級到支持歸檔類型。另外在遷移能力上做了非常多的工作，支持LRS無縫遷移到ZRS，已經(jīng)在線下以工單的方式幫非常多的客戶完成了遷移，產(chǎn)品化的遷移功能也馬上會推出。

前面介紹的是AZ級故障的應(yīng)對，接下來我介紹一下第三部分。

三、Region故障的應(yīng)對

Region故障的應(yīng)對，主要是跨區(qū)域復(fù)制功能。

上圖左邊是一個簡單的示意圖。

前面提到，我們有服務(wù)層OSS Server，也有索引層KV Server。所有的請求在到達(dá)KV Server之后，增刪改操作都會有一條redolog，而且這個redolog是可以定序的。所以為了實(shí)現(xiàn)跨區(qū)域復(fù)制，首先我們增加了Scan Service，它的功能就是掃描所有的redolog來生成復(fù)制任務(wù)，并且是可定序的復(fù)制任務(wù)。

這里要強(qiáng)調(diào)一點(diǎn)——我們的復(fù)制任務(wù)是異步的，它跟用戶的前臺請求完全解耦，也就是說它出任何問題，是不影響用戶的前臺業(yè)務(wù)的。在圖里用不同的顏色進(jìn)行了區(qū)分。

有了任務(wù)之后，第二個重要的模塊就是圖里面的Sync Service，它的功能就是把每個復(fù)制任務(wù)去源端讀取數(shù)據(jù)，通過跨區(qū)域復(fù)制的專線或者公網(wǎng)把它寫到目的端去。除了完成這個復(fù)制任務(wù)本身以外，也要做很多其他的功能，比如說各種維度的QoS，還有在目的端寫入的時候，因?yàn)橛脩糇约阂灿锌赡苤苯訉懭?，所以要做一致性的?shù)據(jù)沖突的仲裁等等。

這部分我也挑了一個功能來做一個相對深入的介紹，我選的是RTC功能，顧名思義就是數(shù)據(jù)復(fù)制時間控制。

一句話來表達(dá)，開啟了RTC以后，OSS會對跨區(qū)域復(fù)制的RPO時間做一個SLA承諾。在以前如果不開啟的話是不提供承諾的。大多數(shù)情況下是可以秒級完成復(fù)制的，另外，對長尾情況也保證P999的對象可以在10分鐘內(nèi)完成復(fù)制。另外，我們還提供了非常多的復(fù)制進(jìn)度的監(jiān)控，比如復(fù)制的帶寬量、數(shù)據(jù)量，復(fù)制的延遲情況，剩余多少沒有完成的復(fù)制任務(wù)等等。

為了實(shí)現(xiàn)這些，我們后臺做了非常多的技術(shù)改進(jìn)。

首先，因?yàn)槭且粋€跨區(qū)域的復(fù)制，所以帶寬資源非常寶貴，在帶寬資源管理上做了多維度的隔離。首先就是租戶間的隔離，任意的用戶不能影響到其他的用戶。另外，其他的業(yè)務(wù)的跨區(qū)域的流量不能影響到這個RTC服務(wù)的流量。以及其他類型的多種維度的QoS隔離。

除了隔離以外，在優(yōu)先級上也做了非常多角度的劃分。最直白的就是開啟了RTC，那在復(fù)制帶寬上就有更高的優(yōu)先級。另外，在同一個客戶的RTC的復(fù)制邊內(nèi)，已經(jīng)延遲了的這些任務(wù)，相比剛生成的任務(wù)就有更高的優(yōu)先級等等。

除了物理資源的管理，在架構(gòu)上也做了很多改造來提升復(fù)制的實(shí)時性。

舉一個例子，OSS的對象，一個對象是可以支持?jǐn)?shù)十T大小的。如果在這個對象上傳完成之后才開始復(fù)制，那顯然不可能做到秒級復(fù)制，所以在開啟了RTC之后，我們會用更多的IO來保證復(fù)制的實(shí)時性。簡單來說，沒開啟RTC的時候，我們是在一個PART 上傳完成之后觸發(fā)一個復(fù)制任務(wù)，如果開啟了RTC，那就會在每個PART的1MB或者其他大小的分片上傳完之后就會生成一個復(fù)制任務(wù)。這樣才能有比較好的實(shí)時性保證。

另外，也做了多種維度的精細(xì)化的監(jiān)控，包括對RPO破線的報警等等。

正是因?yàn)樗械倪@些改進(jìn)，我們才有信心對客戶承諾RPO的SLA 的保障。

四、防止良好的容災(zāi)設(shè)計(jì)在執(zhí)行中逐步腐化

前面介紹完了我們對服務(wù)器故障、AZ級故障和Region故障容災(zāi)上的設(shè)計(jì)，但是實(shí)際的運(yùn)行過程中也不是這么簡單的，就像一個良好的架構(gòu)設(shè)計(jì)在執(zhí)行較長時間之后會有各種各樣的腐化問題，容災(zāi)設(shè)計(jì)也是同理。

舉一個簡單的例子，前面講了要有IO壓力控制，不管是20%還是40%，總是要有一個IO水位的控制的。假設(shè)線上用戶的業(yè)務(wù)情況增長短時間突破了容災(zāi)水位，如果不及時做擴(kuò)容的話，那其實(shí)就已經(jīng)喪失了容災(zāi)能力了，這就是一個典型的腐化問題。

又比如說前面講了各種EC、3副本的數(shù)據(jù)分布，理想的情況它是應(yīng)該分布均勻的，但如果某個版本的軟件在這些數(shù)據(jù)分布算法上出了bug，那它有可能導(dǎo)致分布不均勻。

所有這些問題都會導(dǎo)致容災(zāi)設(shè)計(jì)失效。

OSS如何應(yīng)對這些問題呢？我們會做一些常態(tài)化的運(yùn)維演練，再結(jié)合監(jiān)控報警和自動修復(fù)功能來解決這些容災(zāi)腐化問題。

這些功能主要都是通過我們的智能運(yùn)維平臺提供的，最后一部分會對我們的智能運(yùn)維平臺做一個介紹。

1．對象存儲OSS智能運(yùn)維平臺-數(shù)據(jù)湖倉

運(yùn)維的基礎(chǔ)是數(shù)據(jù)，要有豐富的數(shù)據(jù)，才有做智能運(yùn)維的基礎(chǔ)。

在OSS這里，我們通過多年積累，沉淀了非常多的數(shù)據(jù)。上圖左下就是運(yùn)維平臺收集的數(shù)據(jù)的示意。比如各種各樣的監(jiān)控數(shù)據(jù)，如網(wǎng)絡(luò)探針，可以從外部探測，知道某個區(qū)域不可用了；比如服務(wù)器的角度，有機(jī)器的多種維度數(shù)據(jù)；應(yīng)用角度，有每個進(jìn)程，每個模塊的日志等各種數(shù)據(jù)；系統(tǒng)的角度，有內(nèi)核的內(nèi)存、CPU、磁盤、進(jìn)程等等多種維度的數(shù)據(jù)。

阿里云本身有非常多的橫向的支撐系統(tǒng)，應(yīng)該是50多個，他們本身有非常多的數(shù)據(jù)沉淀，我們的運(yùn)維平臺也做了打通。在數(shù)據(jù)處理上的話也是非常有挑戰(zhàn)的。這里以一個最簡單的OSS訪問日志的例子。我們的訪問日志每秒鐘有億級的日志條目，在處理上的壓力是非常大的，處理的性能、成本都是問題。我們做了非常多的工作，比如采集端，會在本地做一些加工處理，例如過濾、聚合之類的來縮減數(shù)據(jù)量。

在縮減完之后，我們會使用阿里云的各種功能非常強(qiáng)大的產(chǎn)品，比如說SLS、Blink來做數(shù)據(jù)的實(shí)時處理。處理的這些結(jié)果會存儲到ODPS或者OSS自身這樣的存儲產(chǎn)品里面供后續(xù)使用。

對一些離線的數(shù)據(jù)、復(fù)雜的數(shù)據(jù)處理，我們會用到基于OSS的數(shù)據(jù)湖方案來處理。

2.對象存儲OSS智能運(yùn)維平臺：運(yùn)維動作自動化

如果把這個智能運(yùn)維平臺比作一個人，數(shù)據(jù)就像是人的眼睛。接下來，我要講的運(yùn)維動作有點(diǎn)像人的手腳，給我們提供運(yùn)動能力。

在這一塊，我們的理念有點(diǎn)像Linux 平臺的理念。首先研發(fā)同學(xué)會把各種各樣的原子操作、原子運(yùn)維動作都做腳本化，有點(diǎn)像Linux里的一個個命令，每個命令只完成一件事情，這些運(yùn)維動作的原則也是每個腳本只完成一件事情。然后我們的運(yùn)維平臺赤驥提供的工作流功能，有點(diǎn)像Linux里的管道，類似一個個簡單的命令，用管道組合起來提供一些復(fù)雜的功能。運(yùn)維平臺通過工作流，可以把各種基礎(chǔ)的運(yùn)維動作組合起來，實(shí)現(xiàn)一些復(fù)雜的運(yùn)維動作，比如說集群上線，集群下線。

當(dāng)然，有些運(yùn)維動作相對來說是比較復(fù)雜的。以數(shù)據(jù)遷移為例，在架構(gòu)上，通過把一個對象拆成META元數(shù)據(jù)和 DATA數(shù)據(jù)兩部分，右下角就是一個對象的簡單示意，可以看一個 META的KV對結(jié)合用戶元數(shù)據(jù)的KV對加若干個數(shù)據(jù)KV對，就組成了一個對象。通過這樣的架構(gòu)設(shè)計(jì)，就能實(shí)現(xiàn)提供幾個基礎(chǔ)的運(yùn)維動作：

第一，可以把一個Bucket數(shù)據(jù)打散到多個存儲集群，每個集群的比例還可以按照需要做不同的調(diào)節(jié)，不一定完全對等。

第二，可以通過遷移部分?jǐn)?shù)據(jù)來做一些靈活的容量調(diào)度。

有了眼睛和手腳之后，在大腦的指揮下就可以做一些復(fù)雜的高級動作了，對運(yùn)維來說，也就是說可以完成一些復(fù)雜的運(yùn)維任務(wù)。

2.對象存儲OSS智能運(yùn)維平臺：復(fù)雜運(yùn)維任務(wù)

以我們怎么應(yīng)對容災(zāi)腐化的例子來做一個收尾吧。

前面提到過一個例子，就是當(dāng)業(yè)務(wù)壓力增長，讓某個ZRS集群的IO壓力超過了安全水位線，這個時候運(yùn)維平臺首先會收到報警信息。

收到報警信息之后，我們會提前有一些預(yù)設(shè)的規(guī)則，比如報警持續(xù)了超過多長時間，報警里面產(chǎn)生的IO壓力，用戶的IO行為是持續(xù)的，而不是一個瞬時的行為。明確了這些信息之后就會做出決策，然后就要做數(shù)據(jù)的調(diào)度來把一部分IO壓力遷移到別的集群，來讓原本這個集群的IO水位恢復(fù)到安全水位。這個時候它就要去調(diào)度前面說的那些數(shù)據(jù)遷移的原子能力來做遷移。這個時候問題就來了：因?yàn)閿?shù)據(jù)和IO壓力其實(shí)不是直接關(guān)聯(lián)的，關(guān)系比較復(fù)雜，到底要調(diào)度哪些數(shù)據(jù)、調(diào)度多少數(shù)據(jù)才能遷移走想要的那么多IO壓力呢？這個又用到了數(shù)據(jù)，就是前面講的我們沉淀了各種各樣的數(shù)據(jù)，其中就有用戶的每個Bucket的IO行為的用戶畫像。

右邊這張圖就是其中某個維度的示意。一個用戶Bucket，我們會持續(xù)跟蹤他讀取的行為。舉一個例子，比如說你上傳了一天內(nèi)的數(shù)據(jù)，你到底有多少比例是讀它的，1-3天的有多少比例，3天以上的有多少比例。有了這個比例劃分，再結(jié)合一個用戶每天IO行為的總量的變化情況，就可以在后臺計(jì)算出來，是調(diào)度新寫入的數(shù)據(jù)效率更高，還是遷移寫入了某個時間以上的的數(shù)據(jù)效率更高、以及要遷多少。

計(jì)算出這個結(jié)果之后就開始真正做執(zhí)行了，通過工作流去把指定的數(shù)據(jù)搬遷到其他集群之后，原本這個集群的IO壓力就恢復(fù)到安全水位，等于說靠智能運(yùn)維平臺，研發(fā)人員可以把各種約束都沉淀為這樣的復(fù)雜運(yùn)維任務(wù)來錄入智能運(yùn)維平臺上，保證在長時間運(yùn)行下所有容災(zāi)設(shè)計(jì)都像預(yù)期的那樣去工作。

以上，就是本次分享的主要內(nèi)容，感謝各位的觀看。

xiesc