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

1 云計算的核心技術

云計算主要基于資源虛擬和分布式并行架構兩大核心技術，同時互聯網上有大量的開源軟件為用戶提供支撐，如Xen、KVM、Lighttpd、  Memcached、Nginx、Hadoop、Eucalytus等。云計算技術有效地節約了云服務商的硬件投入、軟件開發成本和維護成本。

虛擬化技術最早由VMware公司引入并在X86  CPU上實現。虛擬化平臺將服務器虛擬為多個性能可配的虛擬機(VM)，對整個集群系統中所有VM進行監控和管理，并根據實際資源使用情況對資源池靈活分配和調度。

分布式并行架構是云計算的另一個核心技術，用于將大量的機器整合為一臺超級計算機，提供海量的數據存儲和處理服務。整合后的超級計算機通過分布式文件系統、分布式數據庫和MapReduce技術，提供海量文件存儲、海量結構化數據存儲和統一的海量數據處理編程方法和運行環境[1-3]。

2 虛擬化技術

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

2.1 物理資源的池化

云計算平臺如圖1所示。物理硬件設備的虛擬化對象包括服務器、存儲、網絡、安全等多個方面，不同的虛擬化技術從不同角度解決系統的各種問題。

(1)服務器虛擬化

服務器虛擬化對服務器進行資源虛擬和池化，將一臺服務器虛擬為多個同構的虛擬服務器，同時對集群中的虛擬服務器資源池進行管理。

(2)存儲虛擬化

存儲虛擬化主要是對傳統的存儲區域網絡(SAN)、網絡附加存儲(NAS)設備進行異構，將存儲資源按類型統一集中為一個大容量的存儲資源，并將統一的存儲資源通過分卷、分目錄的權限和資源管理方法進行池化，然后將虛擬存儲資源分配給各個應用使用，或者是直接分配給最終用戶使用。

(3)網絡虛擬化

網絡虛擬化將一個物理網絡節點虛擬成多個虛擬的網絡設備(交換機、負載均衡器等)，并進行資源管理，配合虛擬機和虛擬存儲空間為應用提供云服務。

2.2 資源池的管理和使用

資源池由云管理平臺實現統一的管理、調度和監控，涉及云平臺的合理使用和維護管理。云管理平臺共分為4個管理層面，分別為：設備的管理、虛擬資源的管理、服務的管理和租戶管理。

(1)設備管理

設備管理為云計算平臺的硬件設備提供管理和告警功能，主要包括系統管理員在日常的維護工作中查詢各物理設備性能情況，并對如應用服務器的CPU使用率、內存使用率、硬盤使用率、網絡接口使用率、存儲設備的空間使用率、IO情況等關鍵指標進行監控。用戶可以根據應用物理設備的實際配置，設置相應的監控閾值，系統會自動啟動對相應指標的監控并報警。

(2)虛擬資源管理

虛擬資源管理為各種應用提供虛擬資源的統一管理、資源分配和靈活調度，同時還包括系統管理員在日常的維護工作中查詢各個最小虛擬資源的性能情況，并對應用虛擬機的CPU使用率、內存使用率、硬盤使用率、網絡接口使用率，虛擬存儲(如亞馬遜的EBS)的空間使用率、IO情況等關鍵指標進行監控。用戶可以根據虛擬資源的實際配置，設置相應的監控閾值，系統會自動啟動對相應指標的監控并報警。

(3)服務管理

服務管理包括服務模板、服務實例、服務目錄等管理。服務管理在虛擬資源的基礎上，快速向租戶提供用戶指定的操作系統、應用軟件等軟件資源。

(4)租戶管理

租戶管理對每一個租戶對應的資源群進行管理，內容包括資源的種類、數量、分布情況等，同時對租戶生命周期進行管理，包括租戶的申請、審核、正常、暫停、注銷等。

2.3 集群的故障定位與維護

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

但是維護人員在云管理平臺上發現物理設備出了故障，維護人員無法通過IP地址對應到故障機器的具體物理位置，通用的PC機又沒有故障燈等輔助定位手段。定位故障機器的物理位置并更換或維護它成為一個復雜和繁瑣的過程。

在的虛擬化集群中，可以采用簡單而有效的方法解決此問題。對于每一臺物理機器，配置一個USB接口的KEY，KEY中保存了物理機器的位置信息，同時 USB  KEY與物理位置直接綁定(如綁在機架上)。機器在啟動時，會到USB  KEY中讀取物理位置信息，根據讀取的物理位置信息，依據固定的算法和物理信息算出機器的IP地址，并在管理平臺中體現。這樣，每個物理機器的IP地址就與物理位置綁定，在物理機器故障時，維護人員在云管理平臺可以準確獲取故障機器的IP地址和物理位置。

2.4 資源池的分組與異構

對于服務器的虛擬化，由于架構不同，SUN、IBM等廠家的小型機虛擬化都采用相互獨立的架構，與基于X86架構的虛擬化系統(如XEN、KVM等)無法兼容，因此造成了資源浪費。           

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

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

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

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

業務系統的業務調度器通過OCCI接口向云計算平臺申請資源，同時向云計算平臺提供業務系統可以支持的操作系統等信息，并提供優先級信息。

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

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

3 分布式技術

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

3.1 分布式文件系統

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

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

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

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

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

對于分布式文件系統，外部應用通過文件系統提供的專用API對其進行訪問，這影響了分布式文件系統的應用范圍。對于標準的POSIX接口，可以通過  FUSE的開發流程實現，但將損失10%~20%的性能。對于網絡文件系統(NFS)，在實現POSIX接口的基礎上，可以直接調用Linux操作系統的  NFS協議棧實現。

3.2 Key/Value存儲引擎

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

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

4 結束語

云平臺的構建是一個具有挑戰性的課題，本文詳細描述了虛擬化和分布式架構兩大核心技術。在基礎設施即服務(IaaS)層面，著重描述了虛擬化技術，以及異構的虛擬化云計算平臺的建設和應用，同時介紹了云管理平臺的功能。在分布式技術方面，介紹了分布式文件系統和Key/Value存儲引擎。對于分布式文件系統，本文著重介紹了主機“瓶頸”解決方案及存儲接口標準化的想法;對于Key/Value存儲引擎，本文提出了用于目錄化存儲的解決方案。