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

    云計(jì)算由Google提出，隨后在互聯(lián)網(wǎng)界風(fēng)起“云”涌，隨之而來的云計(jì)算服務(wù)和技術(shù)平臺(tái)成功案例層出不窮，如Google的GFS、  MapReduce、Bigtable、Chubby和App  Engine，亞馬遜的Dynamo、EC2、S3、SQS、SimpleDB和CloudFront，微軟的Azure、SQL、“.Net”和  Live服務(wù)，開源云計(jì)算平臺(tái)的HDFS、HBase和Eucalyptus，VMware的虛擬化平臺(tái)等。

1 云計(jì)算的核心技術(shù)

云計(jì)算主要基于資源虛擬和分布式并行架構(gòu)兩大核心技術(shù)，同時(shí)互聯(lián)網(wǎng)上有大量的開源軟件為用戶提供支撐，如Xen、KVM、Lighttpd、  Memcached、Nginx、Hadoop、Eucalytus等。云計(jì)算技術(shù)有效地節(jié)約了云服務(wù)商的硬件投入、軟件開發(fā)成本和維護(hù)成本。

虛擬化技術(shù)最早由VMware公司引入并在X86  CPU上實(shí)現(xiàn)。虛擬化平臺(tái)將服務(wù)器虛擬為多個(gè)性能可配的虛擬機(jī)(VM)，對(duì)整個(gè)集群系統(tǒng)中所有VM進(jìn)行監(jiān)控和管理，并根據(jù)實(shí)際資源使用情況對(duì)資源池靈活分配和調(diào)度。

分布式并行架構(gòu)是云計(jì)算的另一個(gè)核心技術(shù)，用于將大量的機(jī)器整合為一臺(tái)超級(jí)計(jì)算機(jī)，提供海量的數(shù)據(jù)存儲(chǔ)和處理服務(wù)。整合后的超級(jí)計(jì)算機(jī)通過分布式文件系統(tǒng)、分布式數(shù)據(jù)庫(kù)和MapReduce技術(shù)，提供海量文件存儲(chǔ)、海量結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)和統(tǒng)一的海量數(shù)據(jù)處理編程方法和運(yùn)行環(huán)境[1-3]。

2 虛擬化技術(shù)

虛擬化技術(shù)主要分為兩個(gè)層面：物理資源池化和資源池管理。其中物理資源池化是把物理設(shè)備由大化小，將一個(gè)物理設(shè)備虛擬為多個(gè)性能可配的最小資源單位;資源池管理是對(duì)集群中虛擬化后的最小資源單位進(jìn)行管理，根據(jù)資源的使用情況和用戶對(duì)資源的申請(qǐng)情況，按照一定的策略對(duì)資源進(jìn)行靈活分配和調(diào)度，實(shí)現(xiàn)按需分配資源[4-7]。

2.1 物理資源的池化

云計(jì)算平臺(tái)如圖1所示。物理硬件設(shè)備的虛擬化對(duì)象包括服務(wù)器、存儲(chǔ)、網(wǎng)絡(luò)、安全等多個(gè)方面，不同的虛擬化技術(shù)從不同角度解決系統(tǒng)的各種問題。

(1)服務(wù)器虛擬化

服務(wù)器虛擬化對(duì)服務(wù)器進(jìn)行資源虛擬和池化，將一臺(tái)服務(wù)器虛擬為多個(gè)同構(gòu)的虛擬服務(wù)器，同時(shí)對(duì)集群中的虛擬服務(wù)器資源池進(jìn)行管理。

(2)存儲(chǔ)虛擬化

存儲(chǔ)虛擬化主要是對(duì)傳統(tǒng)的存儲(chǔ)區(qū)域網(wǎng)絡(luò)(SAN)、網(wǎng)絡(luò)附加存儲(chǔ)(NAS)設(shè)備進(jìn)行異構(gòu)，將存儲(chǔ)資源按類型統(tǒng)一集中為一個(gè)大容量的存儲(chǔ)資源，并將統(tǒng)一的存儲(chǔ)資源通過分卷、分目錄的權(quán)限和資源管理方法進(jìn)行池化，然后將虛擬存儲(chǔ)資源分配給各個(gè)應(yīng)用使用，或者是直接分配給最終用戶使用。

(3)網(wǎng)絡(luò)虛擬化

網(wǎng)絡(luò)虛擬化將一個(gè)物理網(wǎng)絡(luò)節(jié)點(diǎn)虛擬成多個(gè)虛擬的網(wǎng)絡(luò)設(shè)備(交換機(jī)、負(fù)載均衡器等)，并進(jìn)行資源管理，配合虛擬機(jī)和虛擬存儲(chǔ)空間為應(yīng)用提供云服務(wù)。

2.2 資源池的管理和使用

資源池由云管理平臺(tái)實(shí)現(xiàn)統(tǒng)一的管理、調(diào)度和監(jiān)控，涉及云平臺(tái)的合理使用和維護(hù)管理。云管理平臺(tái)共分為4個(gè)管理層面，分別為：設(shè)備的管理、虛擬資源的管理、服務(wù)的管理和租戶管理。

(1)設(shè)備管理

設(shè)備管理為云計(jì)算平臺(tái)的硬件設(shè)備提供管理和告警功能，主要包括系統(tǒng)管理員在日常的維護(hù)工作中查詢各物理設(shè)備性能情況，并對(duì)如應(yīng)用服務(wù)器的CPU使用率、內(nèi)存使用率、硬盤使用率、網(wǎng)絡(luò)接口使用率、存儲(chǔ)設(shè)備的空間使用率、IO情況等關(guān)鍵指標(biāo)進(jìn)行監(jiān)控。用戶可以根據(jù)應(yīng)用物理設(shè)備的實(shí)際配置，設(shè)置相應(yīng)的監(jiān)控閾值，系統(tǒng)會(huì)自動(dòng)啟動(dòng)對(duì)相應(yīng)指標(biāo)的監(jiān)控并報(bào)警。

(2)虛擬資源管理

虛擬資源管理為各種應(yīng)用提供虛擬資源的統(tǒng)一管理、資源分配和靈活調(diào)度，同時(shí)還包括系統(tǒng)管理員在日常的維護(hù)工作中查詢各個(gè)最小虛擬資源的性能情況，并對(duì)應(yīng)用虛擬機(jī)的CPU使用率、內(nèi)存使用率、硬盤使用率、網(wǎng)絡(luò)接口使用率，虛擬存儲(chǔ)(如亞馬遜的EBS)的空間使用率、IO情況等關(guān)鍵指標(biāo)進(jìn)行監(jiān)控。用戶可以根據(jù)虛擬資源的實(shí)際配置，設(shè)置相應(yīng)的監(jiān)控閾值，系統(tǒng)會(huì)自動(dòng)啟動(dòng)對(duì)相應(yīng)指標(biāo)的監(jiān)控并報(bào)警。

(3)服務(wù)管理

服務(wù)管理包括服務(wù)模板、服務(wù)實(shí)例、服務(wù)目錄等管理。服務(wù)管理在虛擬資源的基礎(chǔ)上，快速向租戶提供用戶指定的操作系統(tǒng)、應(yīng)用軟件等軟件資源。

(4)租戶管理

租戶管理對(duì)每一個(gè)租戶對(duì)應(yīng)的資源群進(jìn)行管理，內(nèi)容包括資源的種類、數(shù)量、分布情況等，同時(shí)對(duì)租戶生命周期進(jìn)行管理，包括租戶的申請(qǐng)、審核、正常、暫停、注銷等。

2.3 集群的故障定位與維護(hù)

Google的集群維護(hù)方式給我們留下了深刻的印象，維護(hù)人員推著小推車對(duì)損壞的機(jī)器進(jìn)行更換，故障定位通過定制PC的故障燈進(jìn)行判斷(在通用的因特網(wǎng)數(shù)據(jù)中心(IDC)應(yīng)用中，計(jì)算資源通常使用通用PC機(jī))。目前所有的云平臺(tái)對(duì)物理機(jī)和虛擬機(jī)的監(jiān)控、告警，都是按照機(jī)器的IP地址作為機(jī)器的編號(hào)進(jìn)行管理。對(duì)于承載著虛擬機(jī)的物理機(jī)而言，其Host  OS模塊的IP地址對(duì)應(yīng)和代表著物理機(jī)器在集群中的唯一標(biāo)志。IP地址的分配一般采用兩種方式：采用動(dòng)態(tài)主機(jī)配置協(xié)議(DHCP)方式自動(dòng)獲取;通過手工指定方式確定。由于集群中機(jī)器很多，手工指定工作量非常巨大，因此通常采用DHCP的方式對(duì)IP地址進(jìn)行分配。

但是維護(hù)人員在云管理平臺(tái)上發(fā)現(xiàn)物理設(shè)備出了故障，維護(hù)人員無法通過IP地址對(duì)應(yīng)到故障機(jī)器的具體物理位置，通用的PC機(jī)又沒有故障燈等輔助定位手段。定位故障機(jī)器的物理位置并更換或維護(hù)它成為一個(gè)復(fù)雜和繁瑣的過程。

在的虛擬化集群中，可以采用簡(jiǎn)單而有效的方法解決此問題。對(duì)于每一臺(tái)物理機(jī)器，配置一個(gè)USB接口的KEY，KEY中保存了物理機(jī)器的位置信息，同時(shí) USB  KEY與物理位置直接綁定(如綁在機(jī)架上)。機(jī)器在啟動(dòng)時(shí)，會(huì)到USB  KEY中讀取物理位置信息，根據(jù)讀取的物理位置信息，依據(jù)固定的算法和物理信息算出機(jī)器的IP地址，并在管理平臺(tái)中體現(xiàn)。這樣，每個(gè)物理機(jī)器的IP地址就與物理位置綁定，在物理機(jī)器故障時(shí)，維護(hù)人員在云管理平臺(tái)可以準(zhǔn)確獲取故障機(jī)器的IP地址和物理位置。

2.4 資源池的分組與異構(gòu)

對(duì)于服務(wù)器的虛擬化，由于架構(gòu)不同，SUN、IBM等廠家的小型機(jī)虛擬化都采用相互獨(dú)立的架構(gòu)，與基于X86架構(gòu)的虛擬化系統(tǒng)(如XEN、KVM等)無法兼容，因此造成了資源浪費(fèi)。           

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

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

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

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

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

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

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

3 分布式技術(shù)

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

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

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

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

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

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

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

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

3.2 Key/Value存儲(chǔ)引擎

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

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

4 結(jié)束語(yǔ)

云平臺(tái)的構(gòu)建是一個(gè)具有挑戰(zhàn)性的課題，本文詳細(xì)描述了虛擬化和分布式架構(gòu)兩大核心技術(shù)。在基礎(chǔ)設(shè)施即服務(wù)(IaaS)層面，著重描述了虛擬化技術(shù)，以及異構(gòu)的虛擬化云計(jì)算平臺(tái)的建設(shè)和應(yīng)用，同時(shí)介紹了云管理平臺(tái)的功能。在分布式技術(shù)方面，介紹了分布式文件系統(tǒng)和Key/Value存儲(chǔ)引擎。對(duì)于分布式文件系統(tǒng)，本文著重介紹了主機(jī)“瓶頸”解決方案及存儲(chǔ)接口標(biāo)準(zhǔn)化的想法;對(duì)于Key/Value存儲(chǔ)引擎，本文提出了用于目錄化存儲(chǔ)的解決方案。