- 論壇徽章:
- 1
|
http://www.infoq.com/cn/news/2014/02/google-video-internet
作者 馬國耀 發(fā)布于 二月 19, 2014
近日,在視頻“How Google Backs Up the Internet”中,Raymond Blum介紹了許多值得互聯(lián)網(wǎng)公司學習的有關(guān)備份、恢復方面的技術(shù)與思想。Blum的演講幽默詼諧,信息量巨大,洋洋灑灑地講了一個多小時,處處閃現(xiàn)智慧的光芒,非常值得一聽。Blum用典型的Google式說法解釋了為何常規(guī)的備份策略對Google不起作用:它們在實現(xiàn)容量倍增的同時需要付出倍增的付出(成本和資源)。若備份兩倍的數(shù)據(jù)需要兩倍的資源(時間、能源、空間等),那就沒什么用,這不叫擴展。當要備份的數(shù)據(jù)量從1艾字節(jié)(exabyte)增長到2艾字節(jié)時,你需要一份不同的工作計劃。感謝Todd Hoff ,他對該視頻做了非常詳盡的梳理與總結(jié)(原文在這里),并歸納出演講的幾大主題:
永不丟失數(shù)據(jù):即便Gmail的確發(fā)生過臭名遠播的服務(wù)不可用事件,但它卻能永不丟失數(shù)據(jù),這一點遠非單純地通過許多個磁帶備份和跨多個數(shù)據(jù)中心就可以實現(xiàn),實際工作要復雜得多。每次讀取數(shù)據(jù)都需要經(jīng)過技術(shù)棧的多個層級,而每一層都要做許多工程工作,包括人力。
僅備份是不夠的:你更需要的是恢復(restore)而非備份(backup)。備份只是在消費奢侈的恢復時所繳的稅。可以使備份足夠復雜,以保證恢復變得足夠簡單。
不應(yīng)讓消耗資源與獲得容量線性擴展:不能說數(shù)據(jù)增長100倍,就需要100倍的人力和機器資源。應(yīng)該尋找力量倍增的方法。自動化是改善利用率和效率的主要方法。
萬物皆需冗余:Google的東西也不斷失效,就像人體內(nèi)的細胞不斷死去一樣。Google并不奢望它的東西能夠永遠不死,相反,Google做好應(yīng)對計劃。
萬物皆需多樣化:若擔心站點本地出事,就把數(shù)據(jù)在多個站點存放;若擔心用戶操作錯誤,就對用戶的交互進行多層隔離;若希望免遭某個軟件bug的破壞,就換一個軟件,把東西存在不同的廠商介質(zhì)上以降低嚴重的軟件bug產(chǎn)生的影響。
把人從決策環(huán)路中解放出來:一份郵件被Gmail保存了幾個備份?諸如此類事情,就不應(yīng)是人該操心的,它由Gmail和系統(tǒng)通過某些參數(shù)進行配置和管理的。設(shè)定高層策略,由系統(tǒng)來負責。只有在異常情況下才去打擾人。
不斷地驗證:不斷對備份和恢復進行測試,以驗證其正確性。不對其進行嘗試,它就不可能正確工作。
下面,根據(jù)Todd Hoff 的整理,對演講中的相關(guān)觀點進行詳細描述,由于篇幅較大,為簡化閱讀,筆者對內(nèi)容做了部分刪節(jié),并對若干條目進行了轉(zhuǎn)譯。如需要閱讀英文原文,可轉(zhuǎn)到這里:
保證100%的數(shù)據(jù)可用性,永不丟失數(shù)據(jù) 從統(tǒng)計學角度看,一個2G的文件丟失200K聽起來不錯,但是文件卻可能已經(jīng)失效了。所以,數(shù)據(jù)的可用性遠比可訪問性重要;Google通過位置隔離、應(yīng)用層問題隔離、存儲問題隔離、存儲介質(zhì)問題隔離等多種混合手段保證數(shù)據(jù)的可用性。
冗余不同于可恢復性 多份備份不足以保證數(shù)據(jù)不丟失(軟件的錯誤會導致所有副本都是壞數(shù)據(jù));但是備份在某些情況下是有用的,比如一個數(shù)據(jù)中心不可用時可用另一個異地的數(shù)據(jù)中心的備份進行恢復;冗余有益于引用局部性,而當希望使所有的數(shù)據(jù)引用盡可能是本地訪問時,拷貝就很好用。
從整體上看,Google系統(tǒng)非常健壯,因為有太多的備份 Google的東西始終在出錯,就像人體內(nèi)的細胞不斷地死亡一樣。冗余就是應(yīng)對之策,通過冗余可得到了比單臺高質(zhì)量機器更可靠的聚集可靠性。
大規(guī)模并行系統(tǒng)更容易出錯 若沒有bug的情況下,運行在3萬臺機器上的MapReduce看起來很棒,但是一旦有bug,所有機器都等著運行此bug,其影響就會放大。
本地拷貝不能防止站點失效 如果機房被水淹了,RAID也無力回天;GFS(Google File System)采用RAID的概念,通過編碼技術(shù)一次性將數(shù)據(jù)寫到多個數(shù)據(jù)中心,你只需要使用n-1個備份就可以重構(gòu)數(shù)據(jù)。所以,當你有三個數(shù)據(jù)中心時,其中一個數(shù)據(jù)中心失效,還可以通過另外兩個來進行數(shù)據(jù)重構(gòu)。
可用性和數(shù)據(jù)一致性是整個公司層面的特征 Google工程師、BigTable、GFS、Colossus都將數(shù)據(jù)持久性和一致性視為第一要務(wù)。
萬事皆需多樣性 若擔心本地站點出問題,就把數(shù)據(jù)存放在多個站點上;若擔心用戶操作錯誤,就對用戶的交互進行多層隔離;若希望免遭某個軟件bug的破壞,就換一個軟件,把東西存在不同的廠商介質(zhì)上以減低嚴重的軟件bug帶來的影響。
通過磁帶備份數(shù)據(jù)的確很好 磁帶之所以好,因為它不是磁盤。磁盤的驅(qū)動程序里可能存在bug,但磁帶不會,它提升了存儲多樣性。磁帶容量遵循摩爾定律,所以樂見人們采用磁帶作為備份介質(zhì);磁帶是加密的,惡意分子很難從其中得到有價值的信息。
相對于備份,更應(yīng)該關(guān)注恢復 在人們使用數(shù)據(jù)之前就要發(fā)現(xiàn)問題,恢復是必不可少的;進行連續(xù)的恢復嘗試,通過一個滑動窗口選擇 5%的備份進行恢復并與先前備份的原始數(shù)據(jù)進行比對,在問題出現(xiàn)之前就解決它;比對也是自動執(zhí)行的;
對失敗率的變化做出告警 如果有些事情不對勁,你應(yīng)該立刻知曉;預(yù)期恢復過程中一定有失敗,文件第一次嘗試恢復時失敗暫不告警;如果第一次嘗試恢復時的錯誤率是N,而第二次嘗試恢復時的錯誤率為Y,則意味著某個地方出問題了,因此必須告警(在數(shù)據(jù)使用之前就能夠發(fā)現(xiàn)問題)。
萬事皆可出錯 磁盤不斷地出錯,但是你知道它何時出錯,因為它在你的監(jiān)視之中;而對于磁帶,在你使用它之前你并不知道它是否有錯。磁帶存放的時間久,但你應(yīng)該在使用它之前對其進行測試。
在磁帶上做RAID 對4個滿載磁帶通過XOR生成第5個編碼帶,這樣,任意一個丟失了你都可以從其他四個中進行恢復。磁帶時常丟失數(shù)據(jù),通過不斷地恢復來檢測磁帶的丟失,通過其兄弟磁帶來重新構(gòu)建該磁帶。
備份是為奢侈的恢復所繳的稅。 這是一個恢復系統(tǒng)而非備份系統(tǒng);根據(jù)需要,允許備份足夠復雜并跑的時間很長,但要使恢復盡可能地自動化并快速;因為備份可能很慢,數(shù)據(jù)源必須把原始數(shù)據(jù)保存一段時間,可能有幾天,直到備份已經(jīng)完成。為了使恢復足夠快速,可以降低備份的介質(zhì)使用效率,通常讀一個磁帶需要兩小時,這太久了,如果把同樣多的內(nèi)容寫到兩個磁帶里(每個磁帶的利用率只有一半),然后并行地去讀,時間就只需要一小時。
擴展是個問題 但你擁有艾字節(jié)的數(shù)據(jù)時,你還會面臨一些現(xiàn)實問題,如果不得不拷貝10艾字節(jié),那么為了備份一天的數(shù)據(jù)你可能要花10周的時間;在全球范圍內(nèi)擁有數(shù)據(jù)中心時,你必須要做出一些選擇,比如是否每個中心都有無限的備份容量?是否要根據(jù)區(qū)域劃分來進行備份?帶寬能否支持?帶寬是否要用于其他用來賺錢的業(yè)務(wù)?考慮相對成本,做出權(quán)衡,并非每個中心都有備份設(shè)備,需要權(quán)衡網(wǎng)絡(luò)上的可用容量。
不應(yīng)讓消耗資源與獲得容量線性增長 不能簡單地說需要更多的帶寬和磁帶。比如,對于10000個磁帶,需要10000個操作員去操作它們。在Google,雖然磁帶的數(shù)量增長了一個數(shù)量級,但卻沒有對應(yīng)的人員增長比例;即便有一定的增長幅度,卻遠不如線性增長;一個很好的例子是,人們曾預(yù)測,當電話機數(shù)量增長30%時,美國人都要成為電話接線員,因為當時沒有料到自動交換機的出現(xiàn)。
一切都要自動化 程序安排是自動化的;備份、恢復測試、一致性測試等等,都是自動執(zhí)行的。一旦檢測到壞掉的磁帶,后續(xù)的處理也是自動的。你看不到它們的運行,你所能看到的是,也許有一天你會關(guān)心平均有多少個磁帶壞掉了,或者當磁帶的出錯率變化時發(fā)出一個告警。
讓人擺脫穩(wěn)定狀態(tài)的操作 包裝并運送驅(qū)動器仍需要由人來執(zhí)行。自動化接口來準備運送標簽,獲取RMA號、檢查包裝是否正常、接收確認單,如果這些環(huán)節(jié)出錯則需要人來干預(yù)。同樣,軟件庫的維護也是自動化的。
自動處理死機 每30秒就有一臺機器死掉,如果一個正在執(zhí)行MapReduce任務(wù)的機器死掉,不要告訴我,自動處理并繼續(xù)執(zhí)行。找另一臺機器,轉(zhuǎn)移工作并重新啟動。如果機器的執(zhí)行中存在依賴關(guān)系,則將機器調(diào)度成等待狀態(tài),如果等待時間太長了才需要人工干預(yù)。
恢復的優(yōu)先級設(shè)置 歸檔數(shù)據(jù)的恢復可放在更重要的數(shù)據(jù)(如當前收件箱和發(fā)件箱)的恢復之后;一個月未登錄的賬戶的用戶數(shù)據(jù)的恢復可放在活躍用戶的數(shù)據(jù)恢復之后。
備份系統(tǒng)被視為巨大的全球組織 不要指望只在紐約備份Gmail;把備份看作一個巨大的全球性系統(tǒng),一處發(fā)生備份,也一定同時在別的地方發(fā)生。
需要良好的基礎(chǔ)設(shè)施 MapReduce的作者在編寫它時可能永遠也無法想象它現(xiàn)在正在用于備份。但是,若沒有MapReduce,就不會出現(xiàn)將其用于備份的想法。
不斷進行驗證 不要想當然,僥幸不是一種策略;對于每個備份都要通過恢復進行驗證。不到最后你都無法證明任何事情有效,這種態(tài)度幫助我們發(fā)現(xiàn)了許多問題。
災(zāi)難恢復測試(DRT) 災(zāi)難時有發(fā)生,你能做的只能適應(yīng)。尋找基礎(chǔ)設(shè)施和物理安全的漏洞;不能只有一條通向數(shù)據(jù)中心的道路,需要預(yù)備多條備選方案;需要對供應(yīng)鏈設(shè)計冗余方案。
在不同軟件棧,不同位置和不同時間點進行冗余 不要讓只對數(shù)據(jù)進行遷移,需要在軟件棧的各個層上把數(shù)據(jù)保留一段時間,即便你丟失了這里和那里的數(shù)據(jù),你仍然可以在某個地方找到數(shù)據(jù)。
只有信任你的同伴并扛起責任時,一個巨大組織才能運轉(zhuǎn)起來 相信他們理解自己所負責的部分;確保整個公司的軟件接口都是良定義的,在不同層之間進行驗證測試。 |
|