wangfei 發(fā)表于:14年02月14日 10:21 [編譯] DOIT.com.cn
2014年2月14日存儲在線編譯:雷蒙布盧姆(Raymond Blum)領導著一支站點可靠性工程師團隊,主要負責谷歌數據的保密性和安全性。當然,谷歌永遠也不會透露那些數據的總量是多少,但是從其高管的言語中來看,那些數據總量沒達到YB級至少也達到了EB級。僅Gmail服務的相關數據就達到了EB級。
布盧姆在解釋谷歌如何互聯(lián)網時稱,常規(guī)的備份策略在谷歌是行不通的,原因是:在一般情況下,它們會隨著容量進行調整。
他談到了以下要點:
從未出現過數據丟失的事故。即使在GMail服務宕機時也沒有丟失過數據,但是這比磁帶備份要復雜得多。 整個系統(tǒng)的各個地方都需要檢索數據,這就要求它在包括人在內的每一個層級上都提供引擎。
備份無用。它其實是你最關心的數據恢復功能。 它是一個恢復系統(tǒng)而不是備份系統(tǒng)。備份只是數據恢復戰(zhàn)略中的一部分內容。 將任務轉至備份,讓它具備所需的各種功能,以便將數據恢復工作盡可能地簡化。
你無法按比例調整。 如果數據量增加一百倍,你不可能將人力資源或機器資源也增加一百倍。你應該去尋找倍增器。 自動化是提高利用率和效率的重要方法之一。
無處不在的備用冗余。谷歌有很多種服務,總是會有某一些服務出現故障。 這是不可避免的,就象人體內的細胞也在不停地老化死去一樣。 谷歌從未想過能夠避開這種情況,而是未雨綢繆地制定對應的計劃。
無處不在的多樣性問題。如果你擔心某個站點不完全,那就請把數據放到多個站點上儲存。 如果你擔心的問題是用戶誤操作,那就請設置各種隔離政策,對用戶互動進行限制。如果你想免于受到軟件漏洞的危害,那就請使用不同的軟件。 將數據保存在不同廠商的設備上可以減少軟件漏洞的危害性。
將人中整個工作流程中解放出來。Gmail保存了多少份電子郵件的副本? 人們不應該去關心這樣的問題。有些參數是由Gmail設置,然后由系統(tǒng)來管理的。 這是慣例。高級政策設置完成后,系統(tǒng)就會照此執(zhí)行。 只有出現超常規(guī)的事情后,才需要人工介入。
用實際應用去證明它。如果你根本就不去嘗試,那么它肯定是無法正常工作的。 備份和恢復一直處于被測試狀態(tài)中,目的是驗證它們是否能夠正常運作。
不管是大型企業(yè)還是小型企業(yè),都能從中學到不少知識。 布盧姆談到的那些內容既風趣,又有教益,非常值得一讀。他本人似乎也非常喜愛這項工作所具備的挑戰(zhàn)性。
以下是我個人獲得的一些心得:
數據有效性必須是100%。 永遠也不會出現數據丟失的情況。
從統(tǒng)計學的角度來說,如果你在一個2GB的文件中丟掉200K的數據,那可能并不是很多,但是那份文件可能就變得不能用了。
數據有效性比訪問通道有效性重要得多。如果一個系統(tǒng)宕機了,情況并不會變得十分糟糕。 但是如果數據丟失了,那就非常糟糕了。
谷歌保證你會遇到下列情況的各種組合:
場地隔離
因應用層出現問題導致的隔離
因存儲層出現問題導致的隔離
因媒體失效導致的隔離
你必須考慮到你能控制的范圍。將軟件標在縱軸上,地點標在橫軸上。 如果你想覆蓋所有的東西,你就需要在每個不同地點都保留一份軟件層的副本。你可以在不同地點使用虛擬機來實現這個目標。
備用冗余與可恢復性并不是一回事。
保留再多的數據副本也不能保證不發(fā)生數據丟失的事故。
對于某些類型的宕機事故來說,保留很多份數據副本確實是有用的。如果一顆流星撞擊了一個數據中心,而你在遠程站點保留了數據副本,那你當然不會受到影響。
如果你的存儲設備中有一個軟件漏洞,那么將數據復制到再多的設備上也無濟于事,因為所有的數據副本都存在那個漏洞。Gmail宕機就是最好的例子。
數據中心遭流星撞擊的概率絕不會比軟件漏洞、用戶誤操作或錯誤數據寫入等情況出現的概率高。
備用冗余非常適用于局部引用。當你希望所有的數據引用盡可能接近數據被使用的地點時,復制是個很好的方法。
整個系統(tǒng)的實用性達到了驚人的程度。
谷歌有很多種服務,總是會有某一些服務出現故障,這是不可避免的。 就象人體內的細胞在不斷地死亡一樣。我們從未想過實現服務從不出現故障的目標。 我們?yōu)樗贫A案計劃。各種設備總是會出現故障。
備用冗余就是解決問題的方法。事實證明,多臺設備的可靠性比一臺優(yōu)質設備的可靠性更高。 一臺設備可能會因為某種災難而被毀掉。但是存放在50個不同地點的很多臺設備是很難在同一時間一起被毀掉的。
大規(guī)模并行系統(tǒng)出現數據丟失的概率更高。
如果沒有漏洞的話,MapReduce在3萬臺設備上運行還是不錯的。但是如果系統(tǒng)有漏洞的話,那后果立刻就會被放大無數倍。
如果整個站點出現宕機,那么即便有本地數據副本也無濟于事。
如果你的服務器機房進水了,那么即便你使用了RAID也沒用。
谷歌直到一年前才停止使用的Google File System(GFS)系統(tǒng)充分發(fā)揮了RAID的概念。利用編碼技術同時向不同城市的多個數據中心寫入數據,因此你只要一些碎片就能完成數據的重建工作。 因此,即便3個數據中心同時熄火,你仍然能夠使用自己的數據。
有效性和完整性都是整個機構的特征。
谷歌工程師、BigTable、GFS、Colossus都知道保證數據耐用性和完整性是首要大事,F在有很多系統(tǒng)就是用來檢查和糾正數據有效性和完整性方面的錯誤的。
你想要多樣化的配置。
如果你擔心站點問題,請把數據存放到多個站點。
如果你擔心用戶人為誤差問題,請禁止用戶人工操作。
如果你想讓數據不受軟件錯誤的影響,就請把它放到不同的軟件中。將數據保存到不同廠商的設備上可以降低大廠商故障的影響。
利用磁帶將數據備份起來真的非常好。
磁帶其實很好用,因為它跟磁盤不一樣。如果可以的話,他們可能還會使用打孔卡片來儲存數據。
試想一下,如果你的SATA硬盤的設備驅動程序中出現了一個漏洞,會出現什么樣的后果呢?如果使用磁帶的話,就不會有這樣的問題了。 它增加了你的多樣性,因為不同的媒體需要使用不同的軟件。
磁帶容量符合摩爾法則的規(guī)定,因此將磁帶當作備份媒介來使用是很不錯的,即便它們能夠在其他設備上使用,它們也不會泄密。
磁帶是加密的,這就意味著壞人很難從中得到有用的東西。
備份是無用的。你關心的其實是數據修復問題。
如果系統(tǒng)存在問題的話,你就必須在用戶使用數據前找出它們。當你需要修復數據時,你就需要用到它了。
持續(xù)不斷地進行數據修復。隨機選擇5%的數據進行備份,然后修復數據并進行對比。 為什么呢? 在數據丟失前,搞清楚備份系統(tǒng)是否工作正常。這樣可以找出并解決很多的問題。
進行自動對比。不能跟原始數據進行對比,因為原始數據已經發(fā)生了變化。 因此,給所有的數據分配檢驗數字,然后對比那些檢驗數字。將數據放回源媒體、磁盤、閃存或是其他任何存儲媒介。 確定數據能夠環(huán)行一周再回來。這個過程一直在進行之中。
如果故障率出現變化,就發(fā)出警報。
如果有些東西發(fā)生了變化,你可能想知道到底是怎么回事。如果一切運行正常,那就別來煩我。
系統(tǒng)肯定會不時出現一些故障,但是如果只是某個文件在首次修復時出現問題,那就不用發(fā)警報了。
假設第一次出現故障的概率為N,第二次出現故障的概率為Y。 如果故障率出現了變化,那么肯定是哪里出錯了。
一切都停止下來。
磁盤經常因為故障而停止工作,但是這種事情一發(fā)生你就會知道,因為你一直監(jiān)控著磁盤。
如果使用磁帶的話,那出現故障時你是不知道的,只有當你想去使用它時才會知道它出現了故障。磁帶可以存放很長的時間,但是在你需要用到它之前,你需要先進行測試。
磁帶上的RAID4。
不要將數據只寫到一盤磁帶上。它們都是盒式磁帶。 機械臂也許會失手掉落磁帶,磁帶上的磁粉也許會掉。不要冒險。
當把數據寫到磁帶上的時候,告訴寫入軟件將數據保存好,知道我們發(fā)出它可以改變的命令。如果你這樣做的話,你已經違約了。
寫滿4盒磁帶后,通過XORing即可生成第五盤代碼磁帶。這5盒磁帶中丟掉任何一盤磁帶,你都依然可以恢復數據。
現在告訴寫入程序它們可以改變源數據了,因為數據已經被存放到最終的位置上,現在那些源數據變成備份冗余副本了。
谷歌備份的每一點數據都要經過這種處理。
每月丟失的磁帶可能達到數百盒,但是由于這個處理程序的關系,每個月的數據丟失事故并不會達到數百次。
如果一盒磁帶丟失了,可以利用持續(xù)不斷的數據修復檢測出來,然后你就可以利用相關的磁帶重新制作一盒與丟失的磁帶一模一樣的磁帶,所有的數據就都恢復了。如 果碰巧遇到兩盒磁帶都損壞的情況,那只有當那兩盒磁帶的損壞點也是一樣的時候,你才會丟失數據,你可以利用磁帶重新恢復數據。
不要因為這些技術而令數據丟失。數據丟失的代價太大了,但這就是商業(yè)成本。
備份是你為避免發(fā)生數據修復成本而采取的預防措施。
它是一個數據修復系統(tǒng)而不是備份系統(tǒng)。數據修復是不可避免的中斷。 它們非常有用。利用備份來恢復數據。
按照要求對數據進行備份并根據需要將它們保留足夠長的時間。盡可能快和盡可能自動去進行數據修復。
數據修復操作應該是簡單、迅速和快捷的。你應該能夠通過一項簡單的操作來啟動數據修復。
數據修復工作可以在你休息或睡覺的時候進行。因此,最好不要在數據修復操作中添加任何人工操作的要素。 你承受著壓力。因此,當你在備份數據時請把數據修復的準備工作也做充足。
很大一部分系統(tǒng)都是這樣工作的。
數據源也許必須將數據保存一段時間,這段時間也許是幾天,然后才能將那些數據備份。但是一旦數據被備份好,它應該能夠迅速被恢復。
為了讓數據修復的速度盡可能快一點,請不要頻繁使用備份媒體;▋蓚小時的時間去讀一盒磁帶的做法是不可取的。 只將一盒磁帶寫一半,然后同時讀取兩盒磁帶,這樣你就可以將數據恢復的時間縮短一半。
調整是一個問題。
當你有EB級的數據需要備份時,現實中還有其他一些限制條件。如果你必須拷貝10份EB級的數據,那你可能需要10個星期的時間去備份每天的數據。
由于數據中心遍布全球各地,因此你還有一些選擇的余地。你是否會給每一個站點分配近乎無限的備份容量? 你是否會按地區(qū)將所有的備份數據集合在一起? 傳輸數據的帶寬如何? 你難道不需要為業(yè)務流量預留帶寬嗎?
相關成本。這里有很多折中方案。 并不是每一個站點都有備份設施。必須保證網絡上的可用容量處于均衡狀態(tài)。 備份必須在X站點進行,因為它有所需的帶寬。
你不可能成比例地調整規(guī)模。
不能說你想要多少網絡帶寬和磁帶都行。磁盤會出現故障,因此如果你有1萬塊磁盤的話,你可能需要1萬多名操作員去更換它們。 你有1萬個裝載支架來放磁帶嗎?這都不是成比例增加的。
雖然磁帶庫的數量已經上升了一個數量級,但是對人員數量的要求并沒有同步提高10倍。需要的人數肯定會增加一些,但肯定不會象按比例增加那么多。
有一個例子可以說明這一點,早期人們曾預測電話數量會增加30%,那么話務員的數量也應該增加30%,但是事實上并非如此,因為后來使用了程控技術自動接線。
自動化技術
日程安排已經實現了自動化。如果你有一項服務并且需要儲存數據,你可能每隔一段時間就需要對數據進行備份一次,然后需要每隔一段時間對數據進行修復。 這些數據備份和數據恢復工作都可以由內部系統(tǒng)自動完成。備份是計劃好的,系統(tǒng)可以自動進行數據恢復的測試工作和完整性測試。 當系統(tǒng)檢測出某一盒磁帶出現故障時,它會自動進行處理。
作為人,你不需要了解這些東西。也許在未來的某個時候,你才會想起來去查看一下有多少磁帶出現過問題。 如果磁帶故障率發(fā)生變化,從每天100盒增加到每天300盒,系統(tǒng)才會發(fā)出警報。 但是在系統(tǒng)發(fā)出警報之前,系統(tǒng)是不會提示你每天有100盒磁帶出現問題是在正常范圍以內的。
人工不應介入穩(wěn)態(tài)運行的系統(tǒng)。
包裝和運輸硬盤仍然需要人工來完成。 自動準備運輸標簽,獲得RMA編碼,核對發(fā)出的包裹,接收回執(zhí),這都是自動進行的。只有當這個流程中斷時,才需要人為干預。
庫軟件維護也是如此。如果有一個固件需要升級,并不需要派一名員工去給每個系統(tǒng)升級。 下載固件升級,然后將它送到總控制庫即可。 對固件升級進行測試,盡可能準確地驗證測試結果。 然后將它發(fā)出去。這套正常操作不需要人工干預。
自動處理設備宕機事故。
很多設備每分鐘會宕機兩次。如果在使用3萬臺設備執(zhí)行MapReduce作業(yè)時有一臺設備宕機,那就別告訴我了,只要自動處理好它然后繼續(xù)執(zhí)行作業(yè)就行了。 再找一臺設備,將工作負載移動過去,然后重啟設備。
如果設備之間存在關聯(lián)性,那就請在計劃中加一個等待指令。如果系統(tǒng)等待的時間太長,則可以向管理員發(fā)出警報。 你處理你自己的計劃工作。這是算法應該做的事,而不是人應該做的事。
在數據增長的同時,保持效率不斷提高。
提高利用率和效率。數據量增長100倍的時候,決不能出現對人員或設備的需求量也增長100倍的情況。
2011年的GMail宕機事故和修復情況。從中可以看出谷歌是如何丟掉數據然后又找回那些數據的。他在周日上午10:31收到一條警報信息,上面寫著:“Holly Crap呼叫xxx-xxxx”。如需了解更多關于那次宕機事故的信息,請點擊這里。
Gmail服務的數據量已經達到EB級了。那需要使用很多很多的磁帶。
100%恢復。數據可用性并不是100%。 丟失的數據在事故發(fā)生后的第一天或第二天并沒有全部恢復。 但是最終,所有的數據都被恢復了。
復制層發(fā)生了一系列故障和事故。是的,我們有三個相同的文件,但是它們都空了。 即使進行過設備測試、系統(tǒng)測試和裝配測試,故障也無法避免。
從磁帶恢復數據。這是一項繁重的工作。 數據恢復的時間與數據規(guī)模是成正比的;謴1GB的數據也許只要1毫秒到幾秒的時間就行了。 但是要恢復20萬個收件箱(每個收件箱中都有幾GB的數據),那就要一些時間了。
叫醒了歐洲的兩名員工來處理此事,因為當時他們那里是白天。將人員分配在不同的地方,就是有這樣的好處。
數據被從每一盒磁帶上恢復過來,并經過了驗證。這項工作沒有花太多的時間,只用了幾天就完成了。 員工們對此感到滿意。遇到類似事故的其他公司花了一個月的時間才意識到他們無法將數據恢復回來。 谷歌采取了一些措施來保證下次遇到類似事故時會更快地完成相關的處理工作。
讀一盒磁帶要花2個小時的時間。磁帶散布在很多地點。 沒有哪一個站點有足夠的計算能力去讀取所有與數據恢復有關的磁帶。
利用壓縮技術和檢驗數字技術,其實并不需要把20萬盒磁帶都讀一遍。
從那以后,數據恢復工作就一直在不斷改進。
為各種數據的恢復工作設定優(yōu)先等級。
你應該對各種數據的恢復工作設定優(yōu)先等級,比如先恢復你正在使用的收件箱的數據和已發(fā)送的電子郵件數據,然后再恢復歸檔數據。
一個月都沒有被碰過的帳戶可以放在后面恢復,優(yōu)先恢復相對比較活躍的用戶的帳戶的數據。
備份系統(tǒng)被視為一個巨大的全局有機組織。
例如,不要只在紐約備份GMail服務的數據,因為如果數據中心的規(guī)模擴大或縮小,備份數據的規(guī)模就應該相應地進行調整。
將備份當作一個巨大的全球性系統(tǒng)來對待。當備份發(fā)生的時候,它也許是在其他任何地點進行的。
利用磁帶來恢復數據必須在磁帶所在的地點進行。但是數據可以在紐約而備份卻在俄勒岡進行,因為俄勒岡的數據中心有足夠的容量。 地點隔離是自動處理的,谷歌沒有將數據的備份地點告知客戶。
容量是可以移動的。由于有一個全局容量并得到網絡的支持,因此磁帶在哪里并不重要。
你擁有的數據越多,數據備份工作就越重要。
東西越大就越重要,這是一條常規(guī)定律。谷歌以前只做搜索業(yè)務。 現在它有了GMail服務,因此它變得更大和更重要了。
建立一套優(yōu)秀的基礎設施
隨身攜帶一把瑞士軍刀真的很好。當MapReduce被開發(fā)出來的時候,他們可能從未想到過它會被用于備份。 但是如果不是已經開發(fā)出MapReduce的話,那么人們也不會想到把它用于備份。
調整規(guī)模真的很重要,你不能只擁有它的一部分,比如軟件、基礎設施、硬件、流程等等。
你不能說,我有足夠多的員工,因此我打算使用更多的磁帶。如果你打算將員工人數增加一倍,先想想你公司外面的停車場是否能增加一倍的停車位吧。 公司的自助餐廳和休息室呢? 每一樣都要增加一倍,最后你肯定會遇到一個過不去的瓶頸,然后不得不停下來。
在實際應用中證明它。
凡事都不要想當然。希望并不是一種策略。
如果你不去測試它,它就無法正常工作。要想驗證備份,就必須進行數據恢復工作。 除非你到最終都沒有證明任何東西。事實證明,這樣的做法會導致大量的事故出現。
災難恢復測試。
每過N個月都會出現一種災難。你應當在企業(yè)組織的每個層級模擬災難發(fā)生時的反應。
如果災難什么都不帶走,公司將如何生存呢? 必須學會適應。
在基礎設施和物理安全設備中找出巨大的漏洞。
設想一下,如果有一個數據中心只有一條路通向外界,那么那條路上必然塞滿了運輸發(fā)動機燃料的卡車。如果那條路不在了,會怎么樣? 最好再增加一條通道和另一條輸送柴油機燃料的供應管道。
制定供應鏈備用策略。
在不同的時間點和不同的地理位置及時對不同軟件的數據進行備份。
不要只是讓數據在不同的系統(tǒng)層級之間移動,而是應該將數據保存在系統(tǒng)的不同層級中。 這樣當你丟失某些數據時,你還可以從其他地方恢復它們。時間、地點和軟件,這都很重要。
以GMail宕機事故為例。如果復制軟件存在漏洞,怎么可能不出現數據丟失事故呢? 這是某位聽眾提出的問題,他并不想要知道處理的細節(jié)。數據不斷被備份。 假設從晚上9點之后的數據我們都有,而數據錯誤是在晚上8點發(fā)生的,但是錯誤的數據還沒有被備份到磁帶上。 錯誤被停止了。軟件被恢復到之前某個正常運行的狀態(tài)。 在某一時刻,所有的數據都是完好的。那些數據都在磁帶上。 有些數據被復制了。 有些數據在前端,有些數據在日志里,這些數據源的某些數據是重復的,你是有可能重新所有的數據的。 在這些情況下,不要將數據從設備中提取出來,直到它被存入另一臺設備后過了N小時才能那么做。
刪除問題。
我想刪除這些數據。不要通過重寫磁帶的方式去刪除磁帶上的數據。 由于磁帶的規(guī)模太大,那樣做的成本就太高了。
有一種更加可行的做法是,利用密鑰來達到目的。它不會告訴我們谷歌在做什么。 也許鑰匙丟掉就等于把數據刪除了。
只有當員工們彼此信任且共同承擔責任時,一個規(guī)模龐大的組織才能高效運轉。
彼此信任。
確定組織界面和軟件界面都得到了明確的定義。在各個層級之間進行驗證測試。
制定白名單和黑名單。
確保數據被存放在一個受到保護的地方并且保證那些數據不會被存放到某個特定的地點。這有助于保證地點多樣性和地點獨立性。
這并不是設備固有的功能。必須添加到支持管理條件中。
將責任下方到盡可能低的層級。填寫正確的檔案,它就象魔術一樣發(fā)生了。