云計算技術(shù)及其應(yīng)用

對于服務(wù)器虛擬化的異構(gòu)問題，可以從兩個層面去解決：(1)通過資源池的分組，對不同架構(gòu)的服務(wù)器和小型機進行虛擬化，不同架構(gòu)的資源池歸于一個獨立的組，針對不同的應(yīng)用，分配特定的虛擬機資源。(2)通過業(yè)務(wù)的定制和調(diào)度，將不同架構(gòu)的虛擬化平臺通過管理融合，實現(xiàn)異構(gòu)虛擬機的調(diào)度。

異構(gòu)資源池如圖2所示。在云計算平臺中，把IBM的PowerSystems小型機集群通過IBM的PowerVM系統(tǒng)虛擬為基于  PowerSystems架構(gòu)的計算資源池，把HP的小型機集群通過HP的VSE系統(tǒng)虛擬為基于HP架構(gòu)的計算資源池，把X86架構(gòu)的計算資源通過  XENKVM系統(tǒng)虛擬為基于X86的ZXVE資源池。在業(yè)務(wù)部署時，不同的應(yīng)用的可以根據(jù)自己的業(yè)務(wù)特點和操作系統(tǒng)特點，選擇性地部署在不同的資源池上，從而實現(xiàn)虛擬化對各類小型機的異構(gòu)。X86架構(gòu)的計算資源池、PowerSystems架構(gòu)的計算資源池和HP架構(gòu)的計算資源池分別受各自的虛擬化管理軟件(如VMM、IVM和gWLM)管理。在VMM、IVM和gWLM的上層，可以通過融合的虛擬化管理器(iVMM)，對3個計算資源池進行統(tǒng)一管理。

圖3所示為虛擬資源對應(yīng)用實現(xiàn)異構(gòu)的方法。此方法的核心在于4個方面：iVMM、業(yè)務(wù)調(diào)度器、業(yè)務(wù)系統(tǒng)針對不同的資源池架構(gòu)提供應(yīng)用功能相同的不同版本、iVMM和業(yè)務(wù)調(diào)度器之間的OCCI擴充接口。

在業(yè)務(wù)應(yīng)用層面，針對業(yè)務(wù)系統(tǒng)，本文增加業(yè)務(wù)調(diào)度器模塊。業(yè)務(wù)調(diào)度器根據(jù)業(yè)務(wù)的繁忙程度，向iVMM申請增加或減少虛擬機資源，并調(diào)整負載均衡策略。業(yè)務(wù)系統(tǒng)針對不同的資源池架構(gòu)，需要準備與之對應(yīng)的功能相同的不同版本。OCCI擴充接口的工作流程為：

業(yè)務(wù)系統(tǒng)的業(yè)務(wù)調(diào)度器通過OCCI接口向云計算平臺申請資源，同時向云計算平臺提供業(yè)務(wù)系統(tǒng)可以支持的操作系統(tǒng)等信息，并提供優(yōu)先級信息。

云計算平臺根據(jù)業(yè)務(wù)系統(tǒng)的請求和云內(nèi)資源的空閑情況，分配計算資源，通過OCCI接口通知業(yè)務(wù)調(diào)度器云計算平臺向業(yè)務(wù)系統(tǒng)提供了何種架構(gòu)的計算資源。

業(yè)務(wù)調(diào)度器根據(jù)申請到的資源情況，將業(yè)務(wù)處理機的操作系統(tǒng)、業(yè)務(wù)版本等模板信息通過OCCI接口通知云計算平臺，由云計算平臺進行操作系統(tǒng)和業(yè)務(wù)程序的部署，完成后提交給業(yè)務(wù)系統(tǒng)進行使用。

3 分布式技術(shù)

分布式技術(shù)最早由Google規(guī)模應(yīng)用于向全球用戶提供搜索服務(wù)，因此必須要解決海量數(shù)據(jù)存儲和快速處理的問題。其分布式的架構(gòu)，可以讓多達百萬臺的廉價計算機協(xié)同工作。分布式文件系統(tǒng)完成海量數(shù)據(jù)的分布式存儲，分布式計算編程模型MapReduce完成大型任務(wù)的分解和基于多臺計算機的并行計算，分布式數(shù)據(jù)庫完成海量結(jié)構(gòu)化數(shù)據(jù)的存儲。互聯(lián)網(wǎng)運營商使用基于Key/Value的分布式存儲引擎，用于數(shù)量巨大的小存儲對象的快速存儲和訪問。

3.1 分布式文件系統(tǒng)

分布式文件系統(tǒng)的架構(gòu)，不管是Google的GFS還是Hadoop的HDFS，都是針對特定的海量大文件存儲應(yīng)用設(shè)計的。系統(tǒng)中有一對主機，應(yīng)用通過文件系統(tǒng)提供的專用應(yīng)用編程接口(API)對系統(tǒng)訪問。分布式文件系統(tǒng)的應(yīng)用范圍不廣的原因主要為：主機對應(yīng)用的響應(yīng)速度不快，訪問接口不開放。

主機是分布式文件系統(tǒng)的主節(jié)點。所有的元數(shù)據(jù)信息都保存在主機的內(nèi)存中，主機內(nèi)存的大小限制了整個系統(tǒng)所能支持的文件個數(shù)。一百萬個文件的元數(shù)據(jù)需要近  1G的內(nèi)存，而在云存儲的應(yīng)用中，文件數(shù)量經(jīng)常以億為單位;另外文件的讀寫都需要訪問主機，因此主機的響應(yīng)速度直接影響整個存儲系統(tǒng)的每秒的讀入輸出次數(shù)  (IOPS)指標。解決此問題需要從3個方面入手：

(1)在客戶端緩存訪問過的元數(shù)據(jù)信息。應(yīng)用對文件系統(tǒng)訪問時，首先在客戶端查找元數(shù)據(jù)，如果失敗，再向主機發(fā)起訪問，從而減少對主機的訪問頻次。

(2)元數(shù)據(jù)信息存放在主機的硬盤中，同時在主機的內(nèi)存中進行緩存，以解決上億大文件的元數(shù)據(jù)規(guī)模過大的問題。為提升硬盤可靠性和響應(yīng)速度，還可使用固態(tài)硬盤(SSD)硬盤，性能可提升10倍以上。

(3)變分布式文件系統(tǒng)主機互為熱備用的工作方式為1主多備方式(通常使用1主4備的方式)，通過鎖服務(wù)器選舉出主用主機，供讀存儲系統(tǒng)進行改寫的元數(shù)據(jù)訪問服務(wù)，如果只是讀訪問，應(yīng)用對元數(shù)據(jù)的訪問將被分布式哈希表(DHT)算法分配到備用主機上，從而解決主機的系統(tǒng)“瓶頸”問題

對于分布式文件系統(tǒng)，外部應(yīng)用通過文件系統(tǒng)提供的專用API對其進行訪問，這影響了分布式文件系統(tǒng)的應(yīng)用范圍。對于標準的POSIX接口，可以通過  FUSE的開發(fā)流程實現(xiàn)，但將損失10%~20%的性能。對于網(wǎng)絡(luò)文件系統(tǒng)(NFS)，在實現(xiàn)POSIX接口的基礎(chǔ)上，可以直接調(diào)用Linux操作系統(tǒng)的  NFS協(xié)議棧實現(xiàn)。

3.2 Key/Value存儲引擎

Key/Value存儲引擎最大的問題在于路由變更后，數(shù)據(jù)如何快速地實現(xiàn)重新分布。Key/Value存儲引擎如圖4所示。可以引進虛擬節(jié)點的概念，將整個Key值映射的RING空間劃分成Q個大小相同的Bucket(虛擬節(jié)點，Key的映射算法推薦采用MD5)。每個物理節(jié)點根據(jù)硬件配置情況負責(zé)多個  Bucket區(qū)間的數(shù)據(jù)。同一個Bucket上的數(shù)據(jù)落在不同的N 個節(jié)點上，通常情況下N  =3。我們將DCACHE的Q設(shè)定成10萬，即把整個RING空間分成了10萬份，如果整個DCACHE集群最大容量為50 TB，每個區(qū)間對應(yīng)的數(shù)據(jù)大小僅為500  MB。對500 MB的數(shù)據(jù)進行節(jié)點間的遷移時間可以少于10 s。圖4中，N =3，Bucket A中的數(shù)據(jù)存儲在B、C、D 3個節(jié)點。

Key/Value存儲引擎是一個扁平化的存儲結(jié)構(gòu)，存儲內(nèi)容通過Hash算法在各節(jié)點中平均分布。但是在一些應(yīng)用中，業(yè)務(wù)需要對Key/Value存儲引擎進行類似目錄方式的批量操作(如在CDN項目中，網(wǎng)站向CDN節(jié)點推送內(nèi)容時，需要按照網(wǎng)頁的目錄結(jié)構(gòu)進行增加和刪除)，Key/Value存儲引擎無法支持這樣的需求?？梢栽贙ey/Value存儲引擎中增加一對目錄服務(wù)器，存儲Key值與目錄之間的對應(yīng)關(guān)系，用于對目錄結(jié)構(gòu)的操作。當(dāng)應(yīng)用訪問  Key/Value存儲引擎時，仍然按照Hash方式將訪問對應(yīng)到相應(yīng)的節(jié)點中，當(dāng)需要目錄操作時，應(yīng)用需要通過目錄服務(wù)器對Key/Value存儲引擎進行操作，目錄服務(wù)器完成目錄操作和Key/Value方式的轉(zhuǎn)換。由于絕大多數(shù)項目中，大部分為讀操作，因此目錄服務(wù)器參與對Key/Value引擎訪問的次數(shù)很少，不存在性能“瓶頸”。