GFS：一種根本的設計思想轉變，還是一個古怪的例子？
正如大多讀者所瞭解的那樣，我認為企業現有的儲存模型有很嚴重的弊端。當看到了跟現有儲存模型不一樣的模型之時，我就很想了解的更多。特別的，我會評估這些創新模型的市場前景。所以，遇到類似於GFS或者壓縮備份的好的技術，我就會去考慮客戶是否會以及以何種方式去購買它。
本文將會通過評估GFS商業可行性的方式來籠統的描述它，如果你需要關於GFS的技術文章，我只能推薦Ghemawat、Gobioff 和 Leung 合著的《The Google File System》。本文內容也很多取自於那篇論文的描述。至於維基百科的文章，則並沒有很好的介紹GFS。
從太空看谷歌
GFS是實現有史以來最強大通用機群的關鍵技術之一。當大多數IT人為了備份有幾千個使用者的郵件伺服器而損失睡眠時間的時候，谷歌的基礎平臺卻既可以支援大規模使用者群，又可以定期推出計算和資料密集型應用，這讓競爭對手非常恐懼。谷歌員工是怎麼做到的呢？
這一方面可能是因為谷歌員工比你聰明，谷歌招募了數以百計的電腦科學博士生以及更多的聰明人。一方面是由於他們的經歷：窮博士根本負擔不起用高效能硬體來執行他們的實驗技術，所以他們一開始就成本很低而且越來越低。最後，聰明又貧窮的他們反思了整個IT平臺搭建規範。
他們卓越的洞察力（insight）：與其將平臺可用性建立在昂貴的高效能機器上，不如使用廉價的機器，而將平臺可用性建立在這些廉價機器組成的系統上面。這完全改變了IT產業的經濟學，正如上個世紀70年代的小型機以及上個世紀80年代的個人電腦以及90年代的區域網那樣。當處理器、頻寬以及儲存都很廉價的時候，你就可以花費很多資源來實現IBM所提倡的自動計算。精心設計而且代價低廉的系統，其效能以及經濟性都可以獲得擴充套件。
所有這一切都表明，谷歌並沒有用他們的平臺來完成其他人都沒有做過的任務。谷歌只是將很多技術拼接在一起並且將其擴充套件到一個前所未有的高度。
提醒資訊長：您公司的使用者們用不了多久就會發現谷歌可以做到，而您的公司不可以。您的日子將不會很輕鬆的。
從地球軌道上看GFS
儘管GFS被稱為谷歌檔案系統（不要和Sistina的GFS混淆（儘管怎麼混淆我不知道）- 或許我們應該稱之為GoogleFS），可是它可不僅僅是一個檔案系統而已。它還包含資料冗餘、支援低成本的資料快照，除了提供常規的建立、刪除、開啟、關閉、讀、寫檔案操作，GFS還提供附加記錄的操作。
那個附加記錄的操作折射出谷歌工作任務獨特的一面：通過數以百計的網頁爬蟲，谷歌的資料通過大規模序列寫操作的方式得以持續更新。跟通過同步和協調來修改現有資料的方式相比，只將新資料附加在現有資料後面要方便的多。
谷歌工作任務另一個獨特的方面是它經常包含兩種讀操作：大規模流讀取和小規模隨機讀取。因為大規模讀寫操作非常常見，GFS注重對持續的高頻寬而不是低延遲或者每秒輸入輸出量做出優化。因為許多檔案大小達到幾個GB，GFS針對數百萬的檔案處理進行優化，這也就是說一個單獨的檔案系統應當能夠處理幾個PB的資料。
而所有的這些都是建立在廉價的元件上面，考慮到機群的規模，可以理解故障是經常發生的。系統檢測其本身，發現、承受並從元件錯誤中恢復過來，錯誤包括磁碟錯誤、網路錯誤以及伺服器錯誤。
從SR-71黑鳥戰機看GFS
GFS機群包含了一個master和許多chunkserver，並且會被許多客戶訪問。每個部件一般都是非常便宜的執行linux系統的機器（最新的一般具備2GHZ xeons處理器、2GB記憶體以及800GB左右的磁碟）。
檔案被分割成了許多chunk，每一個chunk被一個64位的handle唯一標識，chunk被當做普通的檔案儲存在linux系統中。每個chunk至少會在另一個chunkserver上有備份，而預設會為每個chunk做三個備份。Chunk跟它們組成的檔案一樣，非常的大，標準大小是64MB。Chunkserver一般不會快取資料，因為chunk都是儲存在本地，故而linux已經將經常被訪問的資料快取在記憶體中了。
或許跟我一樣，當你看到單一master之後會認為存在瓶頸或者單點故障，那麼你需要像我一樣多瞭解一下背後的架構。Master僅僅通過幾個位元組的資訊來告訴客戶端哪個chunkserver具有它所需要的chunk。現在可以直觀的知道chunk size很大的一個好處：客戶端不必跟master有很多互動就可以哦獲得大量資料。
這解決了效能瓶頸問題，但是當master會不會成為單點故障呢？我們知道普通資料是被拷貝三次（因為磁碟很便宜，所以可以這樣做），但是那些至關重要的儲存包括chunk位置在內的後設資料呢。
Master處於效能考慮在記憶體中主要儲存了三種後設資料：
- 檔案和chunk的名稱（也即是程式設計師術語中的名稱空間）
- 檔案和chunk之間的對映關係，比如說每個檔案是由哪些chunk共同組成
- 每個chunk備份的位置
那麼，如果master當機了，其儲存的資料必須很快被替代。前兩種後設資料——名稱空間和對映——通過在master機器磁碟中儲存日誌以及在其他機器上備份的方式被確保安全。日誌檔案會被經常檢查更新以便在需要新master的時候快速恢復資料。多快呢？由於shadow master（在後臺跟master保持同步）的存在，讀取操作幾乎可以立刻執行。寫操作會被暫停30秒到60秒以便新的master和chunkserver之間同步資料。許多廉價磁碟冗餘陣列的恢復不會比這個速度更快。
最後一種後設資料，chunk備份的位置，是在各個chunkserver上面儲存的（且在臨近的機器上有備份），當master重啟或者一個新的chunkserver加入機群的時候會將這個後設資料告知 master。由於是master控制chunk的放置位置的，所以它也可以在行chunk建立的時候自行更新自己的後設資料。
Master也通過和chunkserver“握手“的方式來追蹤機群機器的健康狀況。通過checksum（譯者注：一種被用來校驗資料完整性的方法）來檢測資料損壞。即便如此，資料還是可能會被混雜。於是，GFS依靠附加新資料的方式而不是重寫現有資料的方式來完成寫操作。再通過經常性的檢查更新、快照、以及備份，使得資料損失的概率非常的低，而且即便資料損失了也只是導致資料不可訪問而不是獲得損壞的資料。
GFS 廉價磁碟冗餘陣列(RAID)
谷歌員工並沒有這樣去稱呼它，但是本網站非常關心儲存，而且我發現這一部分特別的有趣。GFS並沒有使用任何的RAID控制、光纖通道、iSCSI、HBAs、 FC 或者SCSI磁碟、雙埠或者其它在wide-awake資料中心常見的昂貴裝置。然而，它卻可以工作並且工作的還很好。
拿建立備份（你我稱之為映象）做個例子。機群中的所有機器通過全通乙太網光纖管道連線，可以並行傳輸資料。這意味著只要新的chunk資料傳輸到chunkserver，chunkserver就可以立刻以全部網路頻寬（大約12MB/秒）開始傳輸資料到備份chunk，而不用降低接收資料速率。而第一個備份所在的chunkserver一旦接收到資料也重複這個操作，所以兩個備份chunk可以與第一個chunk同時完成資料傳輸。
除了可以快速建立備份，master的備份防止規則還會降備份放置在不同的機器以及不同的機架上面，以便降低因為電源或者網路轉換損失導致的資料不可用的概率。
池和均衡
也許虛擬化儲存正處在該技術運用的hype cycle(炒作週期)下降階段，而通過GFS你可以看到當虛擬化被建立在檔案系統中的時候是有多麼的簡單。與其採用一個複雜的軟體層來在RAID陣列之間管理資料塊，GFS的master將新chunk備份放置在磁碟利用率低於平均水平的磁碟中。所以在沒有使用任何棘手而昂貴的軟體的情況下，經過一段時間，各個chunkserver的磁碟利用率也會相差無幾。
Master也會週期性的對chunk備份位置做再均衡處理，主要考慮的因素是磁碟的空間利用率以及負載均衡。這個過程也避免了新加入機群的chunkserver在加入的一刻被大量資料搞崩潰。Master會逐漸向這個行chunkserver中新增資料。Master也會將chunk從高磁碟利用率的chunkserver上面轉移到其他chunkserver上面。
釋放儲存空間的過程會很慢。Master會讓舊的chunk繼續存在幾天然後批量釋放空間，而不是立即刪除釋放空間。釋放操作會在master不忙的時候在後臺執行，這也減少了對機群的影響。此外，因為被刪除的chunk一開始僅僅是被重新命名了，故而系統也提供了針對意外資料丟失的一層保障。
我們知道這一定是在現實世界中可行的，畢竟我們天天都會使用谷歌。但是它工作效果有多好？在論文中作者提供了基於一些谷歌GFS機群實驗而來的統計結果。