【編者按】作者Todd Hoff是High Scalability創(chuàng)始人，為我們解讀Google數(shù)據(jù)保密和數(shù)據(jù)安全負責人Raymond Blum的演講。數(shù)據(jù)安全的一個重要工作就是備份，備份的容量擴展、存儲備份的媒介、備份的效率......通過對互聯(lián)網(wǎng)中龐大數(shù)據(jù)多樣化、復(fù)雜的備份，使數(shù)據(jù)在任何情況下都能簡單地還原、恢復(fù)。數(shù)據(jù)安全不僅僅是一個技術(shù)問題，它還受到現(xiàn)實的種種限制，做好數(shù)據(jù)安全，是任何一個企業(yè)都要考慮的問題。

以下為譯文：

Raymond Blum帶領(lǐng)Site Reliability Engineers團隊負責谷歌的數(shù)據(jù)保密和數(shù)據(jù)安全。當然Google從來都不會如實說有多少數(shù)據(jù)，但從評論上看目前還沒到y(tǒng)ottabyte級（1YB=2⁸⁰B），不過也有很多exabyte級（1EB=2⁶⁰B）的數(shù)據(jù)了。僅Gmail就有接近exabyte的數(shù)據(jù)。

Blum先生在名為“谷歌如何備份互聯(lián)網(wǎng)”的視頻中解釋，常見的備份策略對谷歌無效，原因聽起來讓人吃驚：它們大多是在努力用容量實現(xiàn)擴展。如果備份兩倍多的數(shù)據(jù)，那時間、能源、空間也會消耗兩倍，如果不這么做，就不能進行擴展。要讓容量比支持容量的能力擴充更快，必須要有效率。從備份1exabyte數(shù)據(jù)轉(zhuǎn)變到備份2exabyte數(shù)據(jù)，需要一個不同的計劃。演講的內(nèi)容的主要關(guān)于Google是如何實現(xiàn)容量擴展的。

演講的一些主要議題：

• 從無數(shù)據(jù)丟失。甚至影響頗為不好的GMail停電事件也沒有丟失數(shù)據(jù)，這遠比備份許多磁帶要復(fù)雜的多。數(shù)據(jù)從整個堆棧檢索，每一層都需要管理，包括對人的管理。
• 備份無用。還原你想要的部分，這是指還原系統(tǒng)而不是備份系統(tǒng)。備份是你要為還原付出的高昂代價。將工作轉(zhuǎn)移到到備份上并使備份適當?shù)膹?fù)雜，是為了讓還原盡可能的簡單。
• 不可以線性擴展。不可能有100倍的數(shù)據(jù)，你就能得到100倍的人力和機器資源。你只能去尋找使能力倍增的方法。自動化是提高利用率和效率的主要途徑。
• 冗余。谷歌的存儲設(shè)備一直在老化。這當然不用說都知道，就像我們身體的細胞會死一樣，Google并沒有幻想著事物不會消亡，它只是為事物的消亡做好準備。
• 多樣性。如果你擔心某個站點的位置不安全，那就把數(shù)據(jù)放在多個站點。如果你是擔心用戶錯誤，那就將用戶交互與數(shù)據(jù)隔離。如果你想要避免軟件bug的損害，那就把數(shù)據(jù)放在不同的軟件上。從不同的供應(yīng)商獲取存儲設(shè)備，以減少供應(yīng)商的bug影響存儲的數(shù)據(jù)。
• 將人從繁瑣的勞動中解放出來。通過GMail保留一封電子郵件有多少備份？這不應(yīng)該是人關(guān)心的事情。通過GMail配置一些參數(shù)，系統(tǒng)會具體安排。這是不變的主題，高級別策略設(shè)置和系統(tǒng)實現(xiàn)了它。只有規(guī)范之外的事情發(fā)生才會需要人的參與。
• 證明。如果你不試用它，那它就不會起作用。備份和還原就是不斷的測試，以驗證它們的工作的過程。

無論組織大小，都有很多要學(xué)習的東西。Blum先生的演講很風趣、信息量大、很值得一看。看起來他真的很喜歡工作中的挑戰(zhàn)。

以下是我對這個演講的注釋，從中我們可以了解到許多不為人知的秘密：

• 數(shù)據(jù)可用性必須是100%，不能有數(shù)據(jù)丟失

• 統(tǒng)計學(xué)上，2GB文件中如果丟失了200K數(shù)據(jù)，似乎沒什么大不了，但這個文件或許就不能用了，比如說可執(zhí)行文件或報稅表。
• 數(shù)據(jù)的可用性比可訪問性更重要。如果系統(tǒng)關(guān)閉，后果并不特別嚴重。但如果數(shù)據(jù)丟失，那就不是小事了。
• 谷歌保證用以下所有可能組合保證數(shù)據(jù)安全：

• 位置隔離
• 隔離應(yīng)用層問題
• 隔離存儲層問題
• 隔離媒介故障

• 想象一下移動滑塊的情形。讓軟件像縱向滑塊那樣，讓地址像橫向滑塊那樣。如果你想要包含一切，你需要不同地址的軟件層備份。你可以在不同的地址使用虛擬機。

• 冗余不等于可恢復(fù)性

• 制作多個備份不能保證數(shù)據(jù)不會丟失。
• 多個備份對某些種類的停機是有效的。例如一顆小行星擊中一個數(shù)據(jù)中心，而在一個很遠的地方，你有這個數(shù)據(jù)中心的備份。
• 如果你在存儲堆棧中有一個bug，那把它復(fù)制到N個地方也沒有用，因為bug破壞了所有備份。示例：請參閱GMail停機。
• 相比小行星，代碼中的bug、用戶錯誤或已損壞緩沖區(qū)的寫入，這些故障發(fā)生要多得多了。
• 冗余對訪問局部性有幫助。當你想要所有的數(shù)據(jù)引用與正在使用位置的數(shù)據(jù)盡可能接近時，備份是個不錯的選擇。

• 因為這么多的備份，整個系統(tǒng)非常穩(wěn)健

• 谷歌的設(shè)備一直在老化。這不用說也知道，我們身體的細胞也同樣會死。我們并沒有幻想事物不會消亡，我們只是在為消亡做準備。機器也一直在損耗。
• 冗余就是答案。合計一下，這要比單一的高質(zhì)量機器更加可靠。單一機器可能會被一顆小行星摧毀。想要摧毀放在50個不同地點的機器就難說了。

• 大規(guī)模并行系統(tǒng)的數(shù)據(jù)丟失幾率更大

• MapReduce在30000臺機器上運行得很好，當然是在沒有bug的前提下。一旦有bug出現(xiàn)，造成的影響也是成倍的。

• 本地備份不能防止站點停機

• 如果你的服務(wù)器機房中發(fā)生災(zāi)難性的破壞，那RAID也幫不了你。
• Google文件系統(tǒng)(GFS)，大約一年前，整個Google都在使用這個文件系統(tǒng)，它將RAID的概念又升級了一次。使用編碼技術(shù)將數(shù)據(jù)寫入不同城市的多個數(shù)據(jù)中心，只需要N-1個數(shù)據(jù)片段，即可還原完整的數(shù)據(jù)。所以即使3個數(shù)據(jù)中心中一個停機了，也不會影響數(shù)據(jù)可用性。

• 可用性和完整性是組織廣泛的特點

• 谷歌的工程師們，BigTable，GFS，Colossus都知道數(shù)據(jù)持久性和完整性是第一任務(wù)。很多系統(tǒng)需要檢查并更正在數(shù)據(jù)可用性和完整性上的錯誤。

• 多樣性

• 如果你擔心某個站點的位置安全，那就把數(shù)據(jù)放在多個站點。
• 如果你擔心用戶錯誤，那就把用戶交互和數(shù)據(jù)隔離。
• 如果你想要避免軟件bug的破壞，那就把數(shù)據(jù)放在不同的軟件上。從不同的供應(yīng)商獲取設(shè)備，以減少供應(yīng)商的bug影響存儲的數(shù)據(jù)。

• 磁帶備份真的很不錯

• 磁帶好是因為它不像磁盤那樣。如果可能他們甚至會使用打孔卡。
• 想象一下假如你SATA磁盤的設(shè)備驅(qū)動程序里有一個bug。磁帶就避免了這一問題。因為不同的媒介意味著不同的軟件，這就增加多樣性。
• 磁帶容量遵循摩爾定律，所以他們對磁帶作為備份介質(zhì)都很滿意，雖然他們還在尋找替代品，現(xiàn)在很難說這些替代品是什么。
• 磁帶加密意味著有著不良企圖的家伙們將很難從磁帶中得到有用的東西。

• 備份是無用的，真正需要關(guān)心的是還原

• 在有人需要數(shù)據(jù)之前發(fā)現(xiàn)數(shù)據(jù)是否存在問題，你確定需要數(shù)據(jù)時再還原。
• 持續(xù)還原。不斷隨機選擇5%的備份，還原并對它們進行比較。為什么呢？因為需要在數(shù)據(jù)丟失之前查明數(shù)據(jù)是否還能用，找出存在的問題。
• 自動比較。因為原始文件已更改，所以不能與原始進行比較。所以將校驗碼和校驗碼進行比較。把它帶到源媒介、磁盤或閃存，或者其它的媒介。請確保數(shù)據(jù)可以做一次往返，自動比較是一直都在做的事情。

• 故障率變化的警報

• 你可能想要知道是不是有什么發(fā)生了變化。如果一切運行正常，那就沒有必要告訴我了。
• 預(yù)期會有一些失敗，但別第一次嘗試還原的文件失敗就發(fā)出警報。
• 假設(shè)首次嘗試的失敗率是N，第二次嘗試的失敗率為Y。如果故障率發(fā)生變化那一定是哪里出問題了。

• 損壞

• 磁盤隨時都有可能中斷，但因為你監(jiān)視它，所以你能及時的了解到。
• 要是磁帶的話，只有你使用它的時候，才知道是不是壞了。雖然磁帶保存的時間很長，但是你想在用它之前檢測它是不現(xiàn)實的。

• 磁帶上的RAID4

• 不要將數(shù)據(jù)僅寫到一盤磁帶上。他們是墨盒，隨時會有意外發(fā)生。
• 向磁帶寫入數(shù)據(jù)時，編寫器要保持數(shù)據(jù)不變，直到數(shù)據(jù)被完全寫入。
• 建立4盤完整磁帶，然后通過XOR（邏輯運算）生成第五盤代碼磁帶。你可以失去5磁帶的任何一個，也能恢復(fù)數(shù)據(jù)。
• 現(xiàn)在告訴編寫器它們可以更改源數(shù)據(jù)，因為數(shù)據(jù)已經(jīng)到了到最終的物理位置，有冗余了。
• 谷歌備份的每一bit數(shù)據(jù)都要經(jīng)歷這個過程。
• 數(shù)以百計的磁帶每個月都將丟失，并沒有造成數(shù)據(jù)的丟失，就是得益于這個過程。
• 假設(shè)當檢測到一盤磁帶丟失，通過使用連續(xù)還原和同級磁帶重新生成另一個磁帶，一切都沒問題。在那種兩個磁帶都被損壞的罕見情況下，如果磁帶上的受損的兩個點相同，那數(shù)據(jù)就只好丟失了，只能在subtape一級完成重建。
• 實現(xiàn)這些技術(shù)的成本很高，但是為了不丟失數(shù)據(jù)，很值得。

• 備份是你為奢侈的還原付出的代價

• 它是指還原系統(tǒng)而不是備份系統(tǒng)。還原是一個不可屏蔽的中斷，他們勝過一切。
• 讓備份變得復(fù)雜而且只要需要就這樣做。讓還原變得快捷而且越自動化越好。
• 恢復(fù)應(yīng)該是傻瓜式、快速和簡單。就算是一只貓也能完成還原操作。
• 無論你休息得很好還是累的很慘，還原時才不會問你是不是準備好了。所以不要讓人為因素決定服務(wù)數(shù)據(jù)還原的成功與否。
• 大部分的系統(tǒng)都是這樣工作的。
• 數(shù)據(jù)源或許能夠?qū)��?shù)據(jù)存儲一段時間，也許是在它備份之前的幾天。但一旦備份完成，它隨時都可以還原，而且還原得很快。
• 為了使還原速度更快，不能將全部資源用于備份�；▋蓚�小時來讀取磁帶是不可行的。只寫一半磁帶，并行讀取它們，這樣你僅用一半的時間就可以獲取數(shù)據(jù)。

• 擴展是個問題

• 當你有exabyte級的數(shù)據(jù)時，也會有現(xiàn)實世界的限制。如果你要復(fù)制10exabyte數(shù)據(jù)，然后它會花10周時間備份每一天的數(shù)據(jù)。
• 考慮到分布在世界各地的數(shù)據(jù)中心，可供選擇的方案并不多。你能給每個站點無限的備份容量嗎？你會按區(qū)域劃分所有備份嗎？轉(zhuǎn)移數(shù)據(jù)的帶寬呢？你難道不需要帶寬來為掙錢的流量服務(wù)嗎？
• 看看有關(guān)的費用。也有一些妥協(xié)方案，比如不是每個網(wǎng)站都有備份設(shè)施。必須平衡網(wǎng)絡(luò)中的可用容量。怎樣才能最劃算？例如，只在有足夠帶寬的站點中進行備份。

• 不能線性擴展

• 你不能只是說想要更多的網(wǎng)絡(luò)帶寬和更多的磁帶驅(qū)動器。驅(qū)動器中斷的情況，如果你有10000個驅(qū)動器壞了，你需要10000個運算器來替換它們。你有10000個裝卸碼頭來放磁帶驅(qū)動器，直到一輛卡車把它們運走。這一切都不可以是線性的。
• 雖然磁帶庫的數(shù)量提高了一個數(shù)量級，但參與其中的人并沒有隨之線性增長。
• 比如早期曾有人預(yù)測，隨著電話的增多，30%的美國人會被雇傭為電話接線員。顯然他們沒預(yù)見到未來的自動接線。

• 自動化

• 調(diào)度被自動化。如果你有一個服務(wù)，你說：我有一個數(shù)據(jù)存儲，每N天我需要一個備份，在M時必須還原。內(nèi)部系統(tǒng)完成這些事情：計劃備份、運行還原測試和運行完整性測試等等。并且磁帶故障的處理也是全自動的。
• 人是無法看到這些的。也許有一天，你可能會問平均多少個磁帶損壞了。或如果磁帶破損率從每天100盒磁帶變成每天300盒磁帶時，就會發(fā)出警報。但在那之前不要問我：如果一天100盒磁帶損壞是不是在正常水平內(nèi)？

• 人不應(yīng)參與穩(wěn)態(tài)操作

• 裝載和運輸驅(qū)動器仍然是人類的活動。自動化的接口準備裝運標簽，得到RMA號碼，檢查已經(jīng)出來的軟件包，拿回執(zhí)，如果出現(xiàn)故障，人才會進行干涉。
• 庫軟件維護也類似。例如固件更新時，人不會將這些更新運行在每一個系統(tǒng)中，系統(tǒng)會自動下載這些更新，并進行驗證、運行。這些常規(guī)的操作不需要人的干預(yù)。

• 自動處理死機事件

• 機器平均一分鐘死兩臺。如果一臺機器在進行MapReduce作業(yè)期間使用30,000機器，有一臺機器死機了，那就不要告訴我了，處理完它，繼續(xù)工作。找到另一臺機器，轉(zhuǎn)移任務(wù)，重新啟動。
• 如果有依賴關(guān)系那就先等待。如果你等得太久，就讓我知道。你處理你自己的計劃。這是算法的工作，不需要人為的操作。

• 保持效率正向提高

• 大幅提高利用率和效率。不能有100倍的數(shù)據(jù)就需要100倍的人或機器資源。

• 2011年Gmail停機和還原，谷歌如何丟失數(shù)據(jù)又找回

• 在周日的上午10：31他看到了一個網(wǎng)頁，上面寫：“Holly Crap打電話給xxx-xxxx”。關(guān)于中斷要想了解更多，請看在這里。
• Gmail的數(shù)據(jù)量達exabyte級別。這意味著大量的磁帶。
• 100%恢復(fù)并不意味著可用性也是100%，數(shù)據(jù)恢復(fù)要過段時間才能正常使用。
• 一系列的bug和意外事件會產(chǎn)生在備份的過程中。即使是單元測試、系統(tǒng)測試和集成測試，對一些bug也是無能為力。
• 從磁帶中還原意味著大量的工作。還原時間和規(guī)模相關(guān)。還原gigabyte級數(shù)據(jù)可以在幾毫秒到幾秒時間內(nèi)完成。還原200,000個收件箱中的幾個gig，每個都得花去不少時間。
• 把歐洲的幾個同事叫醒，因為他們剛休息完、很清醒。這就是分布式勞動力的優(yōu)勢。
• 從許多磁帶還原和檢驗數(shù)據(jù)。不需要花幾個星期或幾個月時間，只需要花幾天的時間。這使他們很開心。在類似情況下的其他公司花了一個月時間才意識到他們找不回數(shù)據(jù)了。需要采取一些措施以確保這個處理下一次更快。
• 一個磁帶驅(qū)動器需要2個小時來讀。這些磁帶分布在各地。否則在還原過程中，任何單一地點都不會有足夠能力讀取還原過程中涉及的所有磁帶。
• 壓縮和校驗碼實際上不需要讀取200K磁帶。
• 還原過程自那時以來已大為改善。

• 優(yōu)先還原

• 已存檔的數(shù)據(jù)可以在更重要的數(shù)據(jù)之后還原，比如你當前收件箱和發(fā)送的電子郵件。
• 一個月內(nèi)沒用過的帳戶可以等活躍用戶優(yōu)先恢復(fù)之后還原。

• 備份系統(tǒng)被看作是一個巨大的全球有機體

• 例如，不要只考慮GMail在紐約備份，因為如果該數(shù)據(jù)中心增長或收縮，備份需要適當調(diào)整規(guī)模。
• 把備份看成一個橫跨世界的巨型系統(tǒng)。備份時它可能完全是在別的地方完成。
• 在磁帶上的還原必須是在磁帶所在的位置。但到它制作磁帶時，數(shù)據(jù)可能在紐約而備份可能在俄勒岡州，因為在那里有容量。位置隔離是自動的，客戶不知道自己的數(shù)據(jù)被備份在哪里。
• 容量可以被遷移。只要有全球的容量和網(wǎng)絡(luò)支持，磁帶被放在哪無關(guān)緊要。

• 擁有的數(shù)據(jù)越多，保存好它就越重要

• 越大越重要的是他們的一條準則。谷歌曾經(jīng)只是搜索引擎�，F(xiàn)在它還是Gmail，還有驅(qū)動器、文檔一類的東西。它現(xiàn)在變得更大也更重要了。

• 有良好的基礎(chǔ)結(jié)構(gòu)

• 處理問題時，有通用的解決方案再好不過了。在寫MapReduce時可能從來沒有想到它會被用于備份。但要是沒有MapReduce，利用它進行備份的想法也是不會有的。
• 擴展的重要性不言而喻，軟件、基礎(chǔ)設(shè)施、硬件、流程都要可以擴展。
• 你不能說：我要去部署更多的磁帶驅(qū)動器，就需要兩倍的員工。你會雇這么多的人嗎？你有兩倍多的停車點嗎？還有食堂房間？廁所？一切都要擴大規(guī)模。你會遇到一個瓶頸，然后寸步難行。

• 證明

• 別把什么事情都當作理所當然。希望畢竟不是一種戰(zhàn)略。
• 如果你不檢驗它，那就起不到作用。還原操作必須要檢驗備份。直到你結(jié)束了你還沒證明什么。這種態(tài)度已發(fā)現(xiàn)有很多的不足。

• DRT.災(zāi)難恢復(fù)測試

• 每N個月都要模擬一場災(zāi)難恢復(fù)，看系統(tǒng)每一層的反應(yīng)。
• 如何做到無論災(zāi)難帶走什么，公司都能生存下去？答案只有一個：必須學(xué)會適應(yīng)。
• 在基礎(chǔ)設(shè)施和物理安全發(fā)現(xiàn)無數(shù)漏洞。

在不久的將來，云計算一定會徹底走入我們的生活，有興趣入行未來前沿產(chǎn)業(yè)的朋友，可以收藏云計算，及時獲取人工智能、大數(shù)據(jù)、云計算和物聯(lián)網(wǎng)的前沿資訊和基礎(chǔ)知識，讓我們一起攜手，引領(lǐng)人工智能的未來！

標簽： Google 安全 大數(shù)據(jù) 代碼 電子郵件 服務(wù)器 服務(wù)器機房 谷歌 互聯(lián)網(wǎng) 機房 漏洞 搜索 搜索引擎 網(wǎng)絡(luò) 云計算

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。