什么樣的網(wǎng)絡(luò)存儲系統(tǒng)最適合彈性云計(jì)算

1、一. 用于 HOSTING 目的的彈性云需要什么樣的存儲系統(tǒng)呢？ 彈性云環(huán)境所托管的虛擬機(jī)基本需求大致如下： Ø 虛擬機(jī)系統(tǒng)故障停機(jī)時(shí)間盡可能短 （甚至號稱永不停機(jī)！不過一般一年內(nèi)因不可抗拒的因素，停止 10 分鐘還是能被大度的客戶接受的） 這首先要求虛擬機(jī)的運(yùn)行數(shù)據(jù)（包括操作系統(tǒng)和用戶數(shù)據(jù)）非本地存儲，而是需要存儲于后端的可靠的存儲系統(tǒng)中。因?yàn)樘摂M機(jī)的宿主機(jī)發(fā)生故障（比如斷電或者硬件永久故障）在所難免，如果故障時(shí)虛擬機(jī)的磁盤數(shù)據(jù)本地存儲，長時(shí)間的故障停機(jī)時(shí)間就將不可避免的 甚至人品不好時(shí)，碰到本地硬盤物理損壞，則要造成虛擬機(jī)系統(tǒng)永久不可恢復(fù)。 鑒于上述原因， hosting 環(huán)境的

2、存儲需要放在遠(yuǎn)端的可靠存儲系統(tǒng)，且應(yīng)該寫透到遠(yuǎn)端存儲（切記！不要使用本地 cache 等，否則故障時(shí)要丟失數(shù)據(jù)的！），這樣只要后端存儲系統(tǒng)正常則虛擬機(jī)便可旋即進(jìn)行 ”failover” 再其它可用宿主機(jī)上重新啟動(dòng) . 這樣一來停機(jī)時(shí)間可降低到 1 分鐘內(nèi)。 Ø 虛擬機(jī)系統(tǒng)高用性 高可用意味著 Hosting 的虛擬機(jī)需要 ”always online” ，那么顯而易見對后臺存儲也應(yīng)是 always online 吧！ 對于這點(diǎn)我個(gè)人認(rèn)為倒不盡然！遠(yuǎn)端存儲的可用性可略低于虛擬機(jī)的可用性。為什么這么說呢？因?yàn)樘摂M機(jī)的 I/O 請求其實(shí)可可以短暫掛起的 I/O 掛起時(shí)計(jì)算型任務(wù)還是可以正常

3、運(yùn)行的，而 I/O 相關(guān)的任務(wù)可以臨時(shí)處于 "D" 狀態(tài) , 默默地等待 I/O 請求應(yīng)完成。當(dāng)后臺存儲系統(tǒng)恢復(fù)后，則可繼續(xù)正常工作。這種容錯(cuò)性給了后端存儲系統(tǒng)設(shè)計(jì)留下了不少余地。存儲系統(tǒng)可以在擴(kuò)容、 failover 、 snapshot 等非常時(shí)期，短暫的停止或者降低服務(wù)能力。 但是毋庸置疑的是 虛擬機(jī)的高可用性必然要求一個(gè)高可用的后臺存儲。如果后臺存儲不穩(wěn)定、效率低下、故障頻繁則必然破壞到虛擬機(jī)的正常運(yùn)行。 Ø 彈性云資源利用最大化 是智能調(diào)度 。為了能將所有宿主機(jī)的資源整合成一個(gè)資源池，供虛擬機(jī)最大限度使用。彈性云系統(tǒng)需要根據(jù)虛擬機(jī)的資源使用情況，在各個(gè)宿

4、主機(jī)之間調(diào)度虛擬機(jī)這就是傳說中的熱遷移（ live migration ）。熱遷移實(shí)現(xiàn)最重要的就是數(shù)據(jù)遠(yuǎn)程存儲，同時(shí)要保證遷移時(shí)虛擬機(jī)的所有 on disk 數(shù)據(jù)都被刷新到了遠(yuǎn)端存儲中，也就是要求 ” 寫透 ” 至少在遷移時(shí)刻。 資源利用最大化的第二要求就是存儲高性能（高吞吐，低響應(yīng)）。因?yàn)槊總€(gè)宿主機(jī)將啟動(dòng)多個(gè)虛擬機(jī)，每個(gè)虛擬機(jī)的一般而言需要保證 2-4BM/s 的 I/O 帶寬（對多數(shù)用戶足夠啦）。如果后臺的存儲性能跟不上，則必然成為虛擬機(jī)運(yùn)行數(shù)量的瓶頸。 資源利用最大化的第三要求是存儲系統(tǒng)支持足夠大的規(guī)模，且能自動(dòng)擴(kuò)容 / 縮容規(guī)模足夠大才可消峰填谷式的資源調(diào)度這點(diǎn)幾乎適用于所有的云集群系

5、統(tǒng)；擴(kuò)容和縮容是指可按需向集群補(bǔ)充機(jī)器，空閑時(shí)抽出空余機(jī)器。為了保證虛擬機(jī)的高可用性，存儲系統(tǒng)的擴(kuò)容和縮絨都必須是在線、不中斷服務(wù)的情況下完成的。而且進(jìn)行時(shí)盡可能不引起性能訪問性能下降。也要能保證數(shù)據(jù)和并發(fā)壓力平衡，不引起明顯抖動(dòng)。 Ø 數(shù)據(jù)需要保證一致性 。 VM 鏡像存儲的數(shù)據(jù)一致性行低于并行文件系統(tǒng)（如 REDHAT 的 Global File System ），但高于（如 AMAZON 的 Dynamo KV) 的數(shù)據(jù)一致性要求。它要求的是 client - oriented consistent ，既面向 VM 自己看到的數(shù)據(jù) “ 實(shí)時(shí) ” 一致（ read fellow

6、write , write fellow write 等） , 而并行文件系統(tǒng)則要求多個(gè)客戶端看到一致的數(shù)據(jù)；最終一致性系統(tǒng)則不能保證時(shí)刻滿足 read fellow write 等要求。 Ø 廉價(jià)、低成本 低成本對于后臺存儲系統(tǒng)而言，具體要求可體現(xiàn)在兩個(gè)方面。 1 是硬件價(jià)格低廉； 2 是最好資源能復(fù)用。 所謂價(jià)格低廉不用說就是和傳統(tǒng)存儲 SAN/NAS 等相比要更便宜（ SAN 這東西我確實(shí)不熟悉，但聽說那是相當(dāng)?shù)馁F呀?。凰^資源能復(fù)用最好的理解是這些硬件除了給虛擬機(jī)做后臺存儲，最好還能在適當(dāng)?shù)臅r(shí)候用于別用。綜合上述兩個(gè)要求，目前比較流行的存儲方案是采用 ” 云存儲 ” 思路：

7、使用 PC 服務(wù)器搭建集群存儲系統(tǒng)。這樣不但便宜，而且其計(jì)算資源等也被復(fù)用?？傊加猛ㄓ脵C(jī)器、 sata 硬盤、普通網(wǎng)卡搭建廉價(jià)的存儲系統(tǒng)是最低成本的。當(dāng)然代價(jià)就是需要嚴(yán)密設(shè)計(jì)的軟件系統(tǒng)來保證系統(tǒng)的健壯性 數(shù)據(jù)怕丟，就需要采用多副本冗余存儲；機(jī)器怕壞，就需要能自動(dòng)、快速 failover . 總之你需要一套堅(jiān)強(qiáng)的存儲軟件系統(tǒng)做支持。 Ø 高速的中小 I/O 請求處理 Hosting 目的的虛擬機(jī)的 I/O 請求有自己的特點(diǎn)。應(yīng)用統(tǒng)計(jì)出的規(guī)律大約是： 1 讀操作多余寫操作（相差往往 10 倍）； 2 請求以小塊數(shù)據(jù)為主（多數(shù)在 50-100 個(gè)扇區(qū)左右）。因此后臺存儲系統(tǒng)最好能是“讀優(yōu)

8、先”，且對“小塊數(shù)據(jù)優(yōu)先”。 讀優(yōu)先問題不談了（好的定位索引、大的 cache 和多副本均衡讀等通用技術(shù)就差不多了），就說小數(shù)據(jù)訪問性能問題，就夠讓很多存儲系統(tǒng)頭疼的。尤其是對于廉價(jià) PC 服務(wù)器組成的存儲網(wǎng)，其使用普通千兆網(wǎng)卡網(wǎng)絡(luò)包的相應(yīng)速度可不敢和光纖相比呀。這時(shí)小包傳送來回的網(wǎng)絡(luò)延遲時(shí)間可不容忽視。因此最好存儲系統(tǒng)能提供“異步請求接口”。以便客戶端能非堵塞的異步發(fā)送請求，這樣才不至于讓 VM 的 I/O 堵塞，響應(yīng)速度更高；并且如果結(jié)合廣播方式異步傳輸請求，則理論傳輸速度可線性 scale 到很大（想想 P2P 軟件）。 當(dāng)然除了上述要求外，差點(diǎn)忘了基本要求是能隨機(jī)修改準(zhǔn)確說是以扇區(qū)大小

9、為單位變長的隨機(jī)讀寫。 注： 1 這里的一般 hosting 應(yīng)用，不包括那些爬蟲、日志分析等 ” 惹事生非 ” 的肇事者，這些應(yīng)用應(yīng)該規(guī)勸其使用 hadoop 等類似的分布文件系統(tǒng)。 2 讀寫比例和 I/O 請求大小可觀察 cat /sys/block/<dev>/stat 看到 , 我說的比例數(shù)據(jù)來自觀察我自己使用機(jī)器，你看到的肯定有所差別。 分析了這么一通，可以概括一下彈性云中 Hosting 服務(wù)需要的后臺存儲特點(diǎn)了： 1 后臺非本地的網(wǎng)絡(luò)存儲系統(tǒng) 2 高可用性 , 幾乎 always online ! 3 支持足夠大的規(guī)模，且能在線擴(kuò)容，負(fù)載均衡。 4 面向 client

10、 的實(shí)時(shí)數(shù)據(jù)一致性 5 客戶端不能緩存數(shù)據(jù) 6 廉價(jià)，最好使用通用 pc 服務(wù)器（當(dāng)然對于 EMC 、華為、 IBM 本身就做存儲、做網(wǎng)絡(luò)的企業(yè)；或者電信、銀行這種有錢的主，當(dāng)然采用可專用存儲設(shè)備啦！） 7 高吞吐、低響應(yīng)。 8 讀優(yōu)先，支持異步訪問，支持以扇區(qū)大小為單位變長的隨機(jī)讀寫。 二檢閱當(dāng)前流行的網(wǎng)絡(luò)存儲系統(tǒng) Hadoop DFS Hadoop 的集群文件系統(tǒng) HDFS ，當(dāng)初是為了滿足爬蟲應(yīng)用而設(shè)計(jì)的廉價(jià)存儲集群。主要特點(diǎn)是：可支持廉價(jià)的異構(gòu)機(jī)器搭建集群；面向大數(shù)據(jù)塊；只能 append 修改對于順序?qū)懭胩峁└咄掏碌男阅?、有很好的?shù)據(jù)安全性性和可用性數(shù)據(jù)存多份，且能對客戶透明的進(jìn)行

11、failover （稍有遺憾的是，其 master 好像是個(gè)單點(diǎn)）。而且可支持在線擴(kuò)容，負(fù)載均衡。 但遺憾的是顯然它不能滿足“支持異步訪問，支持以扇區(qū)大小為單位變長的隨機(jī)讀寫”，“客戶端不能緩存數(shù)據(jù)”等要求。 Gblobe file system Redhat 的 Gfs 是一個(gè)標(biāo)準(zhǔn)的并行文件系統(tǒng)。它支持本地文件一般的隨機(jī)讀寫（按照 offset ）。且具備不錯(cuò)的性能。 但它的設(shè)計(jì)初衷是建立在規(guī)模有限的可靠集群上的，也就是說幾百臺機(jī)器的集群，且機(jī)器的存儲安全是依靠 raid 等硬件技術(shù)保證。因此我們不能說其是個(gè)廉價(jià)的系統(tǒng)。再就是并行文件系統(tǒng)需要用鎖來保證各個(gè)客戶端所見數(shù)據(jù)的一致性，而對 hos

12、ting 的一致性來說只需要保證給定客戶端所見數(shù)據(jù)一致就好有些殺雞用了宰牛刀啦，帶來了不必要的 overload 。 Dynamo 亞馬遜的這個(gè)系統(tǒng)我著實(shí)喜歡（曾經(jīng)自己和朋友剽竊其思想開發(fā)過那么一個(gè)）。它幾乎能滿足上述所有要求。 但是只是數(shù)據(jù)一致性問題上差了那么一點(diǎn)點(diǎn) 它走的是最終一致性路線。當(dāng)然改造改造，也湊活能用。比如用時(shí)間戳進(jìn)行讀時(shí)的集中決策，選擇最后時(shí)間戳的為準(zhǔn)。但這個(gè)時(shí)間戳需要由客戶端打上（如果服務(wù)器斷打的話，則需要集群內(nèi)部時(shí)間同步，這太累啦?。?，因?yàn)槲覀兪敲嫦蚩蛻舳说囊恢滦跃涂梢岳?。不過再 VM 遷移時(shí)，你可要注意，別目標(biāo)機(jī)器時(shí)間慢于原機(jī)器的時(shí)間太大，那樣就不成啦（如果是秒級別的，

13、遷移時(shí)有意阻塞一下 I/O 到是可以避免錯(cuò)誤）。但總的說來， dynamo 的一致性保證用在 Hosting 環(huán)境下玄了點(diǎn)。 Memcachedb 也是 key value 存儲系統(tǒng)，但它好像沒有做數(shù)據(jù)多副本冗余要和 failover 切換。那機(jī)器壞了怎么辦呀（沒用過，只是看了看文檔）。 還有很多存儲系統(tǒng)，如 Redis,Cassandra,pnfs 等，都可在上面幾個(gè)典型的系統(tǒng)中找到其共性，這里不多說了。 就我個(gè)人來看，目前這些開源系統(tǒng)還沒有那個(gè)完全理想，不過也都有很多不錯(cuò)的特性，理清需求后取博眾家之長必能整出來一個(gè)理想的 hosting 存儲系統(tǒng)。需求說清楚了，設(shè)計(jì)其實(shí)不是大難事啦（不是說

14、現(xiàn)在是技術(shù)過剩的時(shí)代嗎！哈哈）。 分析到這里就差不多了，我們就權(quán)當(dāng)現(xiàn)在有這么一種理想的存儲系統(tǒng)，那么我們有如何接入到虛擬化環(huán)境中啦。下面就講講這個(gè)。 三 . 在 XEN 環(huán)境中如何實(shí)施網(wǎng)絡(luò)存儲 熟悉 XEN 當(dāng)前架構(gòu)的朋友一定知道 VM 的 I/O 請求是通過 device model (qemu) 或者前后端虛擬設(shè)備轉(zhuǎn)到 domain0 處理的。 Dom0 的處理方式要么將 I/O 請求存在于本地的鏡像文件中（如 raw 格式、 qcow 格式、 vhd 格式鏡像）、塊設(shè)備中（如 physical 磁盤）、要么存再于遠(yuǎn)程網(wǎng)絡(luò)存儲中（如 nbd 、 nfs 、 iscsi 等）。 我們推敲一下

15、，看如何將我們理想的網(wǎng)絡(luò)存儲集成進(jìn)來呢。 假設(shè)我們使用前后端方式，且采用目前流行的 blktap2 用戶態(tài)后端驅(qū)動(dòng) qemu 方式也大同小異，這里不在贅述。 方式 1 blktap + tapdisk + 虛擬塊設(shè)備（ DOM0 中） + 用戶態(tài) I/O 請求轉(zhuǎn)發(fā)精靈（ DOM0 中） + 遠(yuǎn)程存儲系統(tǒng) 。 顯然這里使用的是 ”physical 設(shè)備 ” 方式掛載了 VM 磁盤鏡像，因此“ dom0 加載虛擬塊 設(shè)備”目的是模擬一個(gè)假的 ”physical 設(shè)備 ”, 這個(gè)虛擬塊設(shè)備作用僅僅是將寫入的 I/O 請求，截獲下來，然后轉(zhuǎn)發(fā)（把數(shù)據(jù)從內(nèi)核倒騰到用戶空間）到 dom0 上本地運(yùn)行的“

16、I/O 請求轉(zhuǎn)發(fā)精靈”，最后再由轉(zhuǎn)發(fā)精靈真正實(shí)現(xiàn)寫到遠(yuǎn)程存儲系統(tǒng) 之所以在用戶態(tài)使用轉(zhuǎn)發(fā)精靈寫遠(yuǎn)程系統(tǒng)是因?yàn)檫€是在用戶態(tài)開發(fā)調(diào)試來的方便，況且多數(shù)遠(yuǎn)程系統(tǒng)也只提供用戶空間的訪問 API 。 方式 2 blktap + tapdisk （ block-device api ） + 遠(yuǎn)程存儲系統(tǒng) 。 顯然方式 1 如果不經(jīng)過內(nèi)核態(tài)這層（這層實(shí)在是多余的）轉(zhuǎn)發(fā)數(shù)據(jù)，而是經(jīng) tapdisk 直接將數(shù)據(jù)從用戶空間發(fā)送到遠(yuǎn)程存儲系統(tǒng)豈不妙齋。有興趣的話試驗(yàn)一下 qemu-nbd, 借鑒其思路在 tapdisk 里實(shí)現(xiàn)一個(gè) tapdisk-nbd 就成啦。 無論方式 1 還是方式 2 都只能使采用掛在“ p

17、hysical 設(shè)備”的方式，如果要使用目前頗為流向的鏡像文件如 vhd 格式的磁盤鏡像 方式又該如何做呢？ 掛載鏡像文件和掛載設(shè)備最大不同在于：鏡像文件屬于文件范疇，因此需要存在于文件系統(tǒng)之上。那么好吧，我們想法子在整個(gè)文件系統(tǒng)放上去！ 方式 3 blktap + tapdisk + 虛擬塊設(shè)備（ DOM0 中） + filesystem （虛擬塊設(shè)備中） + disk image + I/O 請求轉(zhuǎn)發(fā)精靈 (DOM0 中 ) + 遠(yuǎn)程存儲系統(tǒng) 好長呀！但說白了就是在方式 1 基礎(chǔ)上虛擬塊設(shè)備上在去創(chuàng)建一個(gè)文件系統(tǒng)（ ext2 呀 3 呀，隨你啦，只要支持 dio 就可 VHD 為了安全使用 DIO 方式操作文件），然后在其上在創(chuàng)建景象 image 文件即可。 方式 blktap + tapdisk (posix-like api / libaio-like api ) + 遠(yuǎn)程存儲系統(tǒng) 不用說拉，方式就是去掉數(shù)據(jù)和內(nèi)核層的通訊，和方式一樣直接從 tapdisk 用戶態(tài)直接將請求發(fā)送到遠(yuǎn)程存儲系統(tǒng)。不過因?yàn)?tapdisk 操作 vhd 是調(diào)用 pos