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

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

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

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

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

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

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

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

3 分布式技術(shù)

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

3.1 分布式文件系統

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

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

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

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

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

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

3.2 Key/Value存儲引擎

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

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