您當前位置：首頁 > 互聯網 > 從Google備份互聯網看“數據安全”

從Google備份互聯網看“數據安全”

來源：程序員人生發布時間：2014-09-27 22:05:47 閱讀次數：2947次

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

CSDN推薦：歡迎免費訂閱《Hadoop與大數據周刊》獲取更多Hadoop技術文獻、大數據技術分析、企業實戰經驗，生態圈發展趨勢。

以下為譯文：

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

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

演講的一些主要議題：

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

無論組織大小，都有很多要學習的東西。Blum先生的演講很風趣、信息量大、很值得一看?？雌饋硭娴暮芟矚g工作中的挑戰。

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

數據可用性必須是100%，不能有數據丟失

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

位置隔離
隔離應用層問題
隔離存儲層問題
隔離媒介故障

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

冗余不等于可恢復性

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

因為這么多的備份，整個系統非常穩健

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

大規模并行系統的數據丟失幾率更大

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

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

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

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

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

多樣性

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

磁帶備份真的很不錯

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

備份是無用的，真正需要關心的是還原

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

故障率變化的警報

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

損壞

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

磁帶上的 RAID4

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

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

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

擴展是個問題

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

不能線性擴展

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

自動化

調度被自動化。如果你有一個服務，你說：我有一個數據存儲，每N天我需要一個備份，在M時必須還原。內部系統完成這些事情：計劃備份、運行還原測試和運行完整性測試等等。并且磁帶故障的處理也是全自動的。
人是無法看到這些的。也許有一天，你可能會問平均多少個磁帶損壞了?；蛉绻艓茡p率從每天100盒磁帶變成每天300盒磁帶時，就會發出警報。但在那之前不要問我：如果一天100盒磁帶損壞是不是在正常水平內？

人不應參與穩態操作

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

自動處理死機事件

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

保持效率正向提高

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

2011年Gmail停機和還原，谷歌如何丟失數據又找回

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

優先還原

已存檔的數據可以在更重要的數據之后還原，比如你當前收件箱和發送的電子郵件。
一個月內沒用過的帳戶可以等活躍用戶優先恢復之后還原。

備份系統被看作是一個巨大的全球有機體

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

擁有的數據越多，保存好它就越重要

越大越重要的是他們的一條準則。谷歌曾經只是搜索引擎。現在它還是Gmail，還有驅動器、文檔一類的東西。它現在變得更大也更重要了。

有良好的基礎結構

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

證明

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

DRT.災難恢復測試

每N個月都要模擬一場災難恢復，看系統每一層的反應。
如何做到無論災難帶走什么，公司都能生存下去？答案只有一個：必須學會適應。
在基礎設施和物理安全發現無數漏洞。
想象有一個數據中心，一條通向數據中心的路，路上的卡車滿載了備用發電機的燃料。那如果這條路不通了怎么辦？最好有另一條路，另一供應商可以提供柴油燃料。
必須要有供應鏈冗余策略。

不同時間點不同地點不同軟件堆棧中的冗余

不要僅僅通過堆棧遷移數據。特別是暫停期間堆棧不同層中保留的數據。丟失的數據可以在其它地方找到。所以記住：時間、地點和軟件。
想一下Gmail的中斷示例。如果備份損壞，數據怎樣才能不會丟失？這是演講時，聽眾的一個問題，他不想透露太多。數據是持續備份的。假設我們有下午9點的數據，假設下午8點出現損壞，但還沒有做出磁帶。這時損壞被停止了，軟件被回滾到上一個工作版本。在一些還原點，所有堆棧中的數據是還在那里。這些就是磁帶上的東西。磁帶會備份這些東西。在前端上有，在日志中有。所有數據都可以實現重建。但要在所有數據被轉移到另一個堆棧中之后再對其進行操作。