二、檢閱當前流行的網(wǎng)絡存儲系統(tǒng)
Hadoop DFS
Hadoop 的集群文件系統(tǒng)HDFS，當初是為了滿足爬蟲應用而設計的廉價存儲集群。主要特點是：可支持廉價的異構機器搭建集群;面向大數(shù)據(jù)塊;只能append修改——對于順序寫入提供高吞吐的性能、有很好的數(shù)據(jù)安全性性和可用性——數(shù)據(jù)存多份，且能對客戶透明的進行failover(稍有遺憾的是，其master好像是個單點)。而且可支持在線擴容，負載均衡。
但遺憾的是顯然它不能滿足“支持異步訪問，支持以扇區(qū)大小為單位變長的隨機讀寫”，“客戶端不能緩存數(shù)據(jù)”等要求。
Gblobe file system
Redhat 的Gfs是一個標準的并行文件系統(tǒng)。它支持本地文件一般的隨機讀寫(按照offset)。且具備不錯的性能。
但它的設計初衷是建立在規(guī)模有限的可靠集群上的，也就是說幾百臺機器的集群，且機器的存儲安全是依靠raid等硬件技術保證。因此我們不能說其是個廉價的系統(tǒng)。再就是并行文件系統(tǒng)需要用鎖來保證各個客戶端所見數(shù)據(jù)的一致性，而對hosting的一致性來說——只需要保證給定客戶端所見數(shù)據(jù)一致就好——有些殺雞用了宰牛刀啦，帶來了不必要的overload。
Dynamo
亞馬遜的這個系統(tǒng)我著實喜歡(曾經(jīng)自己和朋友剽竊其思想開發(fā)過那么一個)。它幾乎能滿足上述所有要求。
但是只是數(shù)據(jù)一致性問題上差了那么一點點 —— 它走的是最終一致性路線。當然改造改造，也湊活能用。比如用時間戳進行讀時的集中決策，選擇最后時間戳的為準。但這個時間戳需要由客戶端打上(如果服務器斷打的話，則需要集群內部時間同步，這太累啦!)，因為我們是面向客戶端的一致性就可以啦。不過再VM遷移時，你可要注意，別目標機器時間慢于原機器的時間太大，那樣就不成啦(如果是秒級別的，遷移時有意阻塞一下I/O到是可以避免錯誤)。但總的說來，dynamo的一致性保證用在Hosting 環(huán)境下玄了點。
Memcachedb 也是key value存儲系統(tǒng)，但它好像沒有做數(shù)據(jù)多副本冗余要和failover切換。那機器壞了怎么辦呀(沒用過，只是看了看文檔)。
還有很多存儲系統(tǒng)，如Redis,Cassandra,pnfs等，都可在上面幾個典型的系統(tǒng)中找到其共性，這里不多說了。 就我個人來看，目前這些開源系統(tǒng)還沒有那個完全理想，不過也都有很多不錯的特性，理清需求后取博眾家之長必能整出來一個理想的hosting存儲系統(tǒng)。需求說清楚了，設計其實不是大難事啦(不是說現(xiàn)在是技術過剩的時代嗎!哈哈)。
分析到這里就差不多了，我們就權當現(xiàn)在有這么一種理想的存儲系統(tǒng)，那么我們有如何接入到虛擬化環(huán)境中啦。下面就講講這個。
