云計算技術(shù)發(fā)展分析及其應(yīng)用探究

1、【W(wǎng)ord版本下載可任意編輯】 云計算技術(shù)發(fā)展分析及其應(yīng)用探究 云計算由Google提出，隨后在互聯(lián)網(wǎng)界風(fēng)起“云”涌，隨之而來的云計算服務(wù)和技術(shù)平臺成功層出不窮，如Google的GFS、MapReduce、Bigtable、Chubby和App Engine，亞馬遜的Dynamo、EC2、S3、SQS、SimpleDB和CloudFront，微軟的Azure、SQL、“。Net”和Live服務(wù)，開源云計算平臺的HDFS、HBase和Eucalyptus，VMware的虛擬化平臺等。 1 云計算的技術(shù) 云計算主要基于資源虛擬和分布式并行架構(gòu)兩大技術(shù)，同時互聯(lián)網(wǎng)上有大量的開源軟件為用戶提供支撐，如

2、Xen、KVM、Lighttpd、Memcached、Nginx、Hadoop、Eucalytus等。云計算技術(shù)有效地節(jié)約了云服務(wù)商的硬件投入、軟件開發(fā)成本和維護(hù)成本。 虛擬化技術(shù)早由VMware公司引入并在X86 CPU上實現(xiàn)。虛擬化平臺將服務(wù)器虛擬為多個性能可配的虛擬機（VM），對整個集群系統(tǒng)中所有VM開展監(jiān)控和管理，并根據(jù)實際資源使用情況對資源池靈活分配和調(diào)度。 分布式并行架構(gòu)是云計算的另一個技術(shù)，用于將大量的機器整合為一臺超級計算機，提供海量的數(shù)據(jù)存儲和處理服務(wù)。整合后的超級計算機通過分布式文件系統(tǒng)、分布式數(shù)據(jù)庫和MapReduce技術(shù)，提供海量文件存儲、海量構(gòu)造化數(shù)據(jù)存儲和統(tǒng)一的海量

3、數(shù)據(jù)處理編程方法和運行環(huán)境。 2 虛擬化技術(shù) 虛擬化技術(shù)主要分為兩個層面：物理資源池化和資源池管理。其中物理資源池化是把物理設(shè)備由大化小，將一個物理設(shè)備虛擬為多個性能可配的資源單位；資源池管理是對集群中虛擬化后的資源單位開展管理，根據(jù)資源的使用情況和用戶對資源的申請情況，按照一定的策略對資源開展靈活分配和調(diào)度，實現(xiàn)按需分配資源。 2.1 物理資源的池化 云計算平臺如圖1所示。物理硬件設(shè)備的虛擬化對象包括服務(wù)器、存儲、網(wǎng)絡(luò)、安全等多個方面，不同的虛擬化技術(shù)從不同角度解決系統(tǒng)的各種問題。 （1）服務(wù)器虛擬化 服務(wù)器虛擬化對服務(wù)器開展資源虛擬和池化，將一臺服務(wù)器虛擬為多個同構(gòu)的虛擬服務(wù)器，同時對集群

4、中的虛擬服務(wù)器資源池開展管理。 （2）存儲虛擬化 存儲虛擬化主要是對傳統(tǒng)的存儲區(qū)域網(wǎng)絡(luò)（SAN）、網(wǎng)絡(luò)附加存儲（NAS）設(shè)備開展異構(gòu)，將存儲資源按類型統(tǒng)一集中為一個大容量的存儲資源，并將統(tǒng)一的存儲資源通過分卷、分目錄的權(quán)限和資源管理方法開展池化，然后將虛擬存儲資源分配給各個應(yīng)用使用，或者是直接分配給終用戶使用。 （3）網(wǎng)絡(luò)虛擬化 網(wǎng)絡(luò)虛擬化將一個物理網(wǎng)絡(luò)節(jié)點虛擬成多個虛擬的網(wǎng)絡(luò)設(shè)備（交換機、負(fù)載均衡器等），并開展資源管理，配合虛擬機和虛擬存儲空間為應(yīng)用提供云服務(wù)。 2.2 資源池的管理和使用 資源池由云管理平臺實現(xiàn)統(tǒng)一的管理、調(diào)度和監(jiān)控，涉及云平臺的合理使用和維護(hù)管理。云管理平臺共分為4個管理

5、層面，分別為：設(shè)備的管理、虛擬資源的管理、服務(wù)的管理和租戶管理。 （1）設(shè)備管理 設(shè)備管理為云計算平臺的硬件設(shè)備提供管理和告警功能，主要包括系統(tǒng)管理員在日常的維護(hù)工作中查詢各物理設(shè)備性能情況，并對如應(yīng)用服務(wù)器的CPU使用率、內(nèi)存使用率、硬盤使用率、網(wǎng)絡(luò)接口使用率、存儲設(shè)備的空間使用率、IO情況等關(guān)鍵指標(biāo)開展監(jiān)控。用戶可以根據(jù)應(yīng)用物理設(shè)備的實際配置，設(shè)置相應(yīng)的監(jiān)控閾值，系統(tǒng)會自動啟動對相應(yīng)指標(biāo)的監(jiān)控并報警。 （2）虛擬資源管理 虛擬資源管理為各種應(yīng)用提供虛擬資源的統(tǒng)一管理、資源分配和靈活調(diào)度，同時還包括系統(tǒng)管理員在日常的維護(hù)工作中查詢各個虛擬資源的性能情況，并對應(yīng)用虛擬機的CPU使用率、內(nèi)存使用

6、率、硬盤使用率、網(wǎng)絡(luò)接口使用率，虛擬存儲（如亞馬遜的EBS）的空間使用率、IO情況等關(guān)鍵指標(biāo)開展監(jiān)控。用戶可以根據(jù)虛擬資源的實際配置，設(shè)置相應(yīng)的監(jiān)控閾值，系統(tǒng)會自動啟動對相應(yīng)指標(biāo)的監(jiān)控并報警。 （3）服務(wù)管理 服務(wù)管理包括服務(wù)模板、服務(wù)實例、服務(wù)目錄等管理。服務(wù)管理在虛擬資源的根底上，快速向租戶提供用戶指定的操作系統(tǒng)、應(yīng)用軟件等軟件資源。 （4）租戶管理 租戶管理對每一個租戶對應(yīng)的資源群開展管理，內(nèi)容包括資源的種類、數(shù)量、分布情況等，同時對租戶生命周期開展管理，包括租戶的申請、審核、正常、暫停、注銷等。 2.3 集群的故障定位與維護(hù) Google的集群維護(hù)方式給我們留下了深刻的印象，維護(hù)人員推

7、著小推車對損壞的機器開展更換，故障定位通過定制PC的故障燈開展判斷（在通用的因特網(wǎng)數(shù)據(jù)中心（IDC）應(yīng)用中，計算資源通常使用通用PC機）。目前所有的云平臺對物理機和虛擬機的監(jiān)控、告警，都是按照機器的IP地址作為機器的編號開展管理。對于承載著虛擬機的物理機而言，其Host OS模塊的IP地址對應(yīng)和代表著物理機器在集群中的標(biāo)志。IP地址的分配一般采用兩種方式：采用動態(tài)主機配置協(xié)議（DHCP）方式自動獲??；通過手工指定方式確定。由于集群中機器很多，手工指定工作量非常巨大，因此通常采用DHCP的方式對IP地址開展分配。 但是維護(hù)人員在云管理平臺上發(fā)現(xiàn)物理設(shè)備出了故障，維護(hù)人員無法通過IP地址對應(yīng)到故障

8、機器的具體物理位置，通用的PC機又沒有故障燈等輔助定位手段。定位故障機器的物理位置并更換或維護(hù)它成為一個復(fù)雜和繁瑣的過程。 在的虛擬化集群中，可以采用簡單而有效的方法解決此問題。對于每一臺物理機器，配置一個USB接口的KEY，KEY中保存了物理機器的位置信息，同時USB KEY與物理位置直接綁定（如綁在機架上）。機器在啟動時，會到USB KEY中讀取物理位置信息，根據(jù)讀取的物理位置信息，依據(jù)固定的算法和物理信息算出機器的IP地址，并在管理平臺中表達(dá)。這樣，每個物理機器的IP地址就與物理位置綁定，在物理機器故障時，維護(hù)人員在云管理平臺可以準(zhǔn)確獲取故障機器的IP地址和物理位置。 2.4 資源池的分

9、組與異構(gòu) 對于服務(wù)器的虛擬化，由于架構(gòu)不同，SUN、IBM等廠家的小型機虛擬化都采用相互獨立的架構(gòu)，與基于X86架構(gòu)的虛擬化系統(tǒng)（如XEN、KVM等）無法兼容，因此造成了資源浪費。 對于服務(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

10、架構(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

11、個方面：iVMM、業(yè)務(wù)調(diào)度器、業(yè)務(wù)系統(tǒng)針對不同的資源池架構(gòu)提供給用功能相同的不同版本、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)整負(fù)載均衡策略。業(yè)務(wù)系統(tǒng)針對不同的資源池架構(gòu)，需要準(zhǔn)備與之對應(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)度器云

12、計算平臺向業(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)，可以讓多達(dá)百萬臺的廉價計算機協(xié)同工作。分布式文件系統(tǒng)完成海量數(shù)據(jù)的分布式存儲，分布式計算編程模型MapReduce完成大型任務(wù)的分解和基于多臺計算機的并行計算，分布式數(shù)據(jù)庫完成海量構(gòu)造化數(shù)據(jù)的存儲?；ヂ?lián)網(wǎng)運營商使用基于Key/Value的分布

13、式存儲引擎，用于數(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)常以億為單位；另外文件的讀寫都需要訪問主機，因此主機的響

14、應(yīng)速度直接影響整個存儲系統(tǒng)的每秒的讀入輸出次數(shù)（IOPS）指標(biāo)。解決此問題需要從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)用對

15、元數(shù)據(jù)的訪問將被分布式哈希表（DHT）算法分配到備用主機上，從而解決主機的系統(tǒng)“瓶頸”問題 對于分布式文件系統(tǒng)，外部應(yīng)用通過文件系統(tǒng)提供的專用API對其開展訪問，這影響了分布式文件系統(tǒng)的應(yīng)用范圍。對于標(biāo)準(zhǔn)的POSIX接口，可以通過FUSE的開發(fā)流程實現(xiàn)，但將損失10%20%的性能。對于網(wǎng)絡(luò)文件系統(tǒng)（NFS），在實現(xiàn)POSIX接口的根底上，可以直接調(diào)用Linux操作系統(tǒng)的NFS協(xié)議棧實現(xiàn)。 3.2 Key/Value存儲引擎 Key/Value存儲引擎的問題在于路由變更后，數(shù)據(jù)如何快速地實現(xiàn)重新分布。Key/Value存儲引擎如圖4所示。可以引進(jìn)虛擬節(jié)點的概念，將整個Key值映射的RING空間劃

16、分成Q個大小相同的Bucket（虛擬節(jié)點，Key的映射算法推薦采用MD5）。每個物理節(jié)點根據(jù)硬件配置情況負(fù)責(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存儲引擎是一個扁平化的存儲構(gòu)造，存儲內(nèi)容通過Hash算法在各節(jié)點中平均分布。但是在一些應(yīng)用中，業(yè)務(wù)需要對Key/Value存儲引擎開展類似目錄方式的批量操作（如在CDN項目中，網(wǎng)站向CDN節(jié)點推送內(nèi)容時，需要按照網(wǎng)頁的目錄構(gòu)造開展增加和刪除），Key/Value存儲引擎無法支持這樣的需求?？梢栽贙ey/Value存儲引擎中增加一對目錄服務(wù)器，存儲Key值與目錄之間的對應(yīng)關(guān)系，用于對目錄構(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ù)項目