摘要：清華大學(xué)數(shù)據(jù)中心運(yùn)維那點(diǎn)事兒我徐葳顯然是個科研人員，同時還管理很多行政事務(wù)等，但有些人命不好，就是系統(tǒng)管理員的命。最后，數(shù)據(jù)中心現(xiàn)在如此復(fù)雜，怎么能再利用一些人工智能的東西放在數(shù)據(jù)中心里幫助運(yùn)維。

嘉賓介紹：徐葳，清華大學(xué)交叉信息研究院助理院長，青年千人學(xué)者，博士生導(dǎo)師，UC Berkeley 計(jì)算機(jī)系 PhD，曾供職于 Google。主要方向?yàn)榛A(chǔ)架構(gòu)的監(jiān)控，日志等，目前以分布式系統(tǒng)以及人工智能等方向?yàn)橹鳌ㄈ斯ぶ悄堋㈦[私保護(hù)、反欺詐等內(nèi)容。

以下為徐葳在數(shù)人云PaaS Innovation 2017，構(gòu)建靈動新IT大會上的演講實(shí)錄。

我（徐葳）顯然是個科研人員，同時還管理很多行政事務(wù)等，但有些人“命不好”，就是系統(tǒng)管理員的命。所以花了很多時間去管一個IT系統(tǒng)，學(xué)院的機(jī)房、云平臺，基本上夜里大家都睡了，還要登陸上去看看日志，該修點(diǎn)什么就修點(diǎn)什么，我這個人有個毛病，就是看不得機(jī)器壞了，看不得什么東西不行，就得馬上修好。

清華有系統(tǒng)管理員，就如同我一樣都有系統(tǒng)管理員病，很喜歡做系統(tǒng)管理，但他們都是白天上班，因?yàn)闆]有加班費(fèi)，所以不好意思讓人晚上加班，所以晚上一般都由我來管。

這個數(shù)據(jù)中心做的是人工智能，現(xiàn)在人工智能很熱，科研領(lǐng)域清華做的非常前沿，這是最最聰明的應(yīng)用，但是跑在最最傻的基礎(chǔ)架構(gòu)上。

因?yàn)樵?jīng)供職于Google，非常想在清華復(fù)制一套Google的架構(gòu)，但這并非一兩個人就能開發(fā)出來。所以，即便在Google，唯一不能用的地方就是系統(tǒng)運(yùn)維領(lǐng)域，這是燈下黑，這也是本次講演的主題叫：“數(shù)據(jù)中心與智能”。

今天給大家分享幾個方面：

首先，數(shù)據(jù)中心運(yùn)維，這是和百度合作的一個數(shù)據(jù)分析的事情，會給大家展示幾個有意思的結(jié)果。

其次，討論下現(xiàn)在的新架構(gòu)，Deep Learning深入學(xué)習(xí)，如何維護(hù)這個框架，怎么把數(shù)據(jù)中心改造成可以進(jìn)行支持。

最后，數(shù)據(jù)中心現(xiàn)在如此復(fù)雜，怎么能再利用一些人工智能的東西放在數(shù)據(jù)中心里幫助運(yùn)維。

首先，這是和百度合作的一件事，百度有很多的機(jī)器，有個部門叫硬件運(yùn)營部，他們收集了很多故障報修，各種產(chǎn)品線，各種不同的產(chǎn)品報修了硬件，硬件運(yùn)維部就派人去處理一下，大部分處理的方法就是找廠商換新的。所以叫做出了問題的Ticket，幾年內(nèi)積累了29萬個，我們可以幫助它的地方是，到底什么東西壞了，拿出來看看，什么時候報修的，大概什么故障，什么部件壞了，這里有很多結(jié)果，但因?yàn)闀r間關(guān)系，就不挨個贅述了。

報修了一個故障，多長時間會修？如同百度這樣管理非常好的公司，報修之后多長時間會有人去處理？不是說修好它，修了不一定能夠修好，但至少是去修了，該換什么就換什么，硬盤報錯，壞了，就換一個硬盤。

具體時長看起來會非常奇怪：平均需要42天報完錯可以修，中位數(shù)的修理時間是6.1天，其中有10%的是140天之后仍然沒有修，但是沒人修并不代表永遠(yuǎn)都不要這個東西了，過了200天以后仍然有人去處理它，而并沒有忘記。

感覺這個時間過長，到底是因?yàn)槭裁矗恳驗(yàn)闄C(jī)器太多了？又或者系統(tǒng)管理員太忙了？其實(shí)未必。

因?yàn)槿绨俣取oogle這樣的公司，系統(tǒng)架構(gòu)非常容錯，硬件出問題是不可避免的，它壞了，既然能容錯，就像四個轱轆掉了一個還能跑，為什么要去修呢？所以邏輯是有一個超級容錯的系統(tǒng)，在運(yùn)維時對故障就沒有那么敏感。從好的方面來說，可以省錢，因?yàn)橐淮涡抟粋€也得跑一趟，修若干個也得跑一趟，因此還不如一次批量的修。

當(dāng)然硬件損壞無法避免，是否能降低一些容錯的復(fù)雜性呢？大家目前越來越多的都在討論這件事，就是三者的平衡，運(yùn)維的可靠性、軟件的成本、硬件的成本之間的三者平衡，現(xiàn)在越來越重要了。

另外，不管如何運(yùn)維，運(yùn)維的系統(tǒng)都是非常重要的，任何運(yùn)維都不是登到界面上去敲幾行命令，然后就派出一一件事，這個都是無法做到的，所以不管如何，系統(tǒng)的運(yùn)維，從一個地方生成這樣配置的操作，從一個地方生成的部署，都很重要。

以上講的是硬件、軟件、運(yùn)維，這三個部分成本如何平衡，現(xiàn)在這個狀態(tài)下，尤其是大規(guī)模的數(shù)據(jù)中心，有可能和過去小的企業(yè)數(shù)據(jù)中心不同。

現(xiàn)在深度學(xué)習(xí)火了，每個人都想要深度學(xué)習(xí)的機(jī)器。最開始一個人要的時候，沒關(guān)系，從桌面虛擬機(jī)集群拆出兩臺來，裝上GPU，自己去用。現(xiàn)在這樣的人多了，裝了60幾塊GPU仍然不夠，所以這種集群如何共享這60幾塊GPU，非常麻煩。

后面做了一個什么事情呢？找數(shù)人云做GPU虛擬化，雖然GPU支持虛擬化但太貴所以不買，買的都是消費(fèi)者級別的GPU，因?yàn)楸阋恕．?dāng)它不支持虛擬化時聯(lián)合容器，所以將GPU集群上放上了Docker，又找了數(shù)人云，幫助開發(fā)一個數(shù)人云的管理系統(tǒng)，是基于Mesos的開源軟件。同時寫Mesos的人是我在伯克利的同學(xué)，因此對它的印象很好。

將來的就是這樣的架構(gòu)，好處是解決了一個問題，即服務(wù)封裝，DeepLearning這事真的不復(fù)雜，如果你玩過，會發(fā)現(xiàn)很簡單，其實(shí)就是找一個開源的軟件框架，上面有很多模型，將其下載下來，都是開源的，這些模型甚至都是訓(xùn)練好的，可以跑人臉識別應(yīng)用，或者跑其他的什么識別應(yīng)用，雖然沒有專業(yè)跑的好，但也不會太差。

但它的問題在于是基于框架，尤其在中國，版本不一樣，升級版本升級的特別快，隨便動一個升級，其他人都爛了，而不同人就要不同的版本，為什么，因?yàn)樗碌哪莻€模型是基于某個特定版本開發(fā)的，在別的版本上跑不出來，所以在這種情況下，大家去到無數(shù)多個配置好的鏡像和環(huán)境，這個場景挺好，Docker、數(shù)人云有它的界面，將這個東西配置好，這種Docker配置的這種Docker，只有這個Docker里面用的是那種版本的東西，因?yàn)镈ocker是一層一層的，不用做那么多鏡像，只有一點(diǎn)點(diǎn)區(qū)別沒有關(guān)系，那么多借點(diǎn)有一點(diǎn)點(diǎn)區(qū)別，占不了那么多空間，好多鏡像，各自用各自的Docker。

所以這解決了一個叫軟件分發(fā)部署的問題，但有一個問題，總得有訓(xùn)練數(shù)據(jù)，有點(diǎn)什么東西在里面，完成后改了配置等等，這些東西不可能存回到那個鏡像里頭去，就想那怎么辦呢？可能過了兩個星期之后還用呢？所以就不上Docker，留著，等兩個星期后再說，但兩個星期后做別的項(xiàng)目去了，機(jī)器就卡在那里，所以這是個問題，存儲它的周邊結(jié)果存在哪里，是個好大的問題。

簡單的方法，有OpenStack，集群上500塊硬盤總是有的，掛上NFS，每臺機(jī)器上面有一個Ceph的NFS，把這些東西對接好，想把這個東西存在那個上面保證安全的，關(guān)了以后重啟時再掛回來，設(shè)計(jì)了這樣一套存儲。

那有什么問題呢？DeepLearning的模型也很大，有些人直接在上面跑，本想讓它存儲一個備份數(shù)據(jù)用，跑到上面做一下其實(shí)還是存在本地。

所以后來自己改造了存儲的架構(gòu)，做了一個開源項(xiàng)目Alluxio，也是伯克利實(shí)驗(yàn)室的一個同學(xué)做的。

Alluxio緩存非常有用，它還為Ceph和NFS適配了一個接口，還有Hadoop集群，HDFS里面也有幾百塊盤，將這三種東西適配城了兩個借口，適合放在Docker里面，也適合放在Hadoop里面，且它加了些緩存，這樣用機(jī)器人內(nèi)存吸收了很多流量，上圖就是大概的基本架構(gòu)。

HDFS也可以支持，同時也能順便支持Hadoop，但是如果有一些大的文件，愿意用HDFS的，就用HDFS。

有寫機(jī)器內(nèi)存還蠻多的，就是當(dāng)年趁內(nèi)存時買了一些內(nèi)存，還是很有用的，可以將內(nèi)容緩存住。分布式內(nèi)存很有意思。

最后說一下很多做DeepLearning的程序，這張圖片解釋了一個詞“復(fù)雜”，OpenStack覺得自己很干凈，為什么？拿個筆都能畫出來，但是這張圖很復(fù)雜，復(fù)雜的原因不光是因?yàn)橛羞@么多圖，凡是看見的都是數(shù)據(jù)庫，數(shù)據(jù)庫是一個持久性的狀態(tài)，每個組件里都有自己持久的狀態(tài)，那如怎么保證一致？討論了這么久分布式系統(tǒng)的一致性，它一旦跨了組件，尤其是跨了開源項(xiàng)目，誰也不會再說這件事。

但若組件壞了，里面還有一個復(fù)雜的結(jié)構(gòu)，它一層一層的封裝起來，所以什么東西壞了，你可能根本不知道，沒壞的時候什么都特別好，但壞了就會很麻煩。

我是個很好的系統(tǒng)管理員，這點(diǎn)特別有信心，但是搞不定這個，因?yàn)槲也皇敲刻於荚谂溥@個，記不得這些東西到底在什么地方，隨便查一個什么東西，后面的參數(shù)那么長，咱們記不住，但別人天天都在做當(dāng)然可以記住。

那么，如何能動呢？我們說通過挖掘日志、系統(tǒng)里的狀態(tài)、跑一些系統(tǒng)里的命令、看一些系統(tǒng)里的數(shù)據(jù)庫，在里面找一些相關(guān)的事情，這是純從樣子上找到的，跟語義沒有關(guān)系。比如ID長那樣，那個ID就是ID，IP地址就是IP地址，將這些東西都找在一起，把這些關(guān)聯(lián)性插在一起，就能生成知識圖。

另外，為什么三臺機(jī)器一起壞了，有可能用戶只看到一臺機(jī)器壞了，但其實(shí)另外兩臺也是如此，因?yàn)樗鼔牡脑蚴且粋€物理機(jī)，要壞肯定是三臺一起壞，所以都可以找到系統(tǒng)里的一些東西，這有多少個節(jié)點(diǎn)？看這個系統(tǒng)看三天，120臺物理機(jī)不算大，待該有60多個存儲的借點(diǎn)，120多個虛擬機(jī)的節(jié)點(diǎn)，大概出來的結(jié)果是幾千萬個狀態(tài)，如上圖所示，所以可以想象為什么這東西老壞。

最后總結(jié)一下，運(yùn)維是個什么樣的過程？剛才說到DevOps，過去的系統(tǒng)管理員如何適應(yīng)DevOps是一個非常大的挑戰(zhàn)，因?yàn)镈evOps，運(yùn)維的人是靠開發(fā)程序來自動化運(yùn)維數(shù)據(jù)中心的，這是必然的趨勢，聽起來都對。但DevOps推廣起來非常難。

DevOps想要推行，一定要把DevOps這些東西的接口配置到過去的系統(tǒng)管理員能懂的那些地方，基本的意思是，預(yù)生幾個命令行，別說那么多分布式的東西，感覺就是幾個配置文件，點(diǎn)點(diǎn)什么東西，這個接口怎么配置，是一個非常大的挑戰(zhàn)。

以上是小數(shù)整理的徐葳教授在PaaS Innovation 2017上的演講實(shí)錄，后臺回復(fù)“1116”即可下載本次大會的PPT資料。