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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

發(fā)生故障的時(shí)候，顯而易見是有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ù)。

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

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

這里對(duì)它做一個(gè)簡(jiǎn)單的介紹。

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

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

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

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

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

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

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

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

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

上圖左邊是一個(gè)簡(jiǎn)單的示意圖。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1．對(duì)象存儲(chǔ)OSS智能運(yùn)維平臺(tái)-數(shù)據(jù)湖倉(cāng)

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

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

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

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

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

2.對(duì)象存儲(chǔ)OSS智能運(yùn)維平臺(tái)：運(yùn)維動(dòng)作自動(dòng)化

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

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

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

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

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

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

2.對(duì)象存儲(chǔ)OSS智能運(yùn)維平臺(tái)：復(fù)雜運(yùn)維任務(wù)

以我們?cè)趺磻?yīng)對(duì)容災(zāi)腐化的例子來做一個(gè)收尾吧。

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

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

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

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

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

xiesc