基于REST架構風格的云物理服務器部署機制

陳 衡，董小社

（西安交通大學計算機科學與技術系 西安 710049）

1 引言

云計算的概念在20世紀90年代被首次提出，但云計算開始受到產(chǎn)業(yè)界和學術界的重視，并逐漸被各行各業(yè)所接受是在 2005年 IT產(chǎn)業(yè)界的巨頭 Amazon、Google、IBM和微軟分別推出了各自的云計算產(chǎn)品之后。全球云計算市場快速平穩(wěn)增長，2013年全球云計算服務市場約為1317億美元，年增長率為18%，據(jù)預測，未來幾年仍將保持15%以上的增長率[1]。使用公用云計算服務，企業(yè)或科研機構不需要一次性購買大量的軟硬件基礎設施，也不需要配備專門的服務器維護人員，而是通過按月付費的方式支付服務費，大幅度地節(jié)省了投入成本，并且能夠根據(jù)業(yè)務的需要隨時增減訂購的云計算服務，從而使用戶可以更加關注自己的主要業(yè)務，而不是基礎設施的建設和維護。

用戶根據(jù)各個應用的特點和需求租用一定數(shù)量的云主機，完成應用的安裝部署。雖然用戶不知道租用的云主機的具體位置，但可以通過基于瀏覽器的用戶管理面板實現(xiàn)對云主機的完全控制，例如開機、關機、重新啟動、重新安裝操作系統(tǒng)等，如同使用用戶自己購買搭建的物理服務器一樣方便易用。這種使用模式可以滿足絕大多數(shù)用戶的應用需求，但是還有相當數(shù)量的應用無法在云主機上正常運行，典型的應用有:高性能計算、需要直接訪問不可虛擬化的計算機硬件的應用、在云主機上運行效率非常低的數(shù)據(jù)庫應用、在多個服務器上快速部署另一種云計算平臺等[2]。云計算服務提供商若要滿足以上應用的需求，則需要向這類用戶提供一定數(shù)量的物理服務器，并允許用戶像使用云主機那樣對這些云物理服務器擁有完全控制權。從用戶角度看，云物理服務器應具有以下特性:

·遠程電源管理，云物理服務器可以基于網(wǎng)絡實現(xiàn)物理開機、關機和重新啟動；

·基于網(wǎng)絡的操作系統(tǒng)和軟件的自動安裝，可以安裝常用的操作系統(tǒng)的不同發(fā)行版本，也可以使用用戶自定義的鏡像系統(tǒng)進行安裝；

·云物理服務器和云主機有相似的管理中心控制面板。

2 服務器管理

在介紹用戶如何通過基于瀏覽器的用戶管理面板對云物理服務器實施管理前，有必要介紹一下數(shù)據(jù)中心的管理員是如何對服務器進行管理的，這里僅介紹操作系統(tǒng)的安裝方法。按照技術發(fā)展的時間順序，服務器操作系統(tǒng)的安裝方法可以分為兩大類，具體介紹如下。

（1）光盤安裝

系統(tǒng)光盤獲取通常有兩種方法:服務器自帶和刻錄從官網(wǎng)下載的安裝光盤鏡像。管理員將服務器設置為從光盤啟動，在將安裝光盤放入服務器光驅(qū)后，重新啟動服務器，按照屏幕提示，完成操作系統(tǒng)的安裝。這種安裝方式最為簡單、直接，但由于需要管理員手動安裝，當服務器的數(shù)量稍多時，安裝工作量就變得很大。

（2）網(wǎng)絡安裝

管理員分別配置DHCP、TFTP、HTTP服務器以及自動安裝腳本，并將需要安裝的服務器設置為網(wǎng)絡啟動。服務器啟動后，首先從DHCP服務器獲得TFTP服務器和自己的IP地址，然后從TFTP服務器獲取內(nèi)核啟動程序和配置文件，最后根據(jù)配置文件內(nèi)容從HTTP服務器下載相應的軟件包完成系統(tǒng)安裝。采用網(wǎng)絡安裝方式的效率很高，在無人值守的模式下，可以同時安裝上百臺服務器，但是這種安裝方式對系統(tǒng)管理員的水平要求較高，并且還需在操作系統(tǒng)安裝前和安裝后分別進入BIOS，對服務器的啟動模式進行設置。

為了進一步提高服務器操作系統(tǒng)安裝的效率，簡化安裝前對DHCP、TFTP、HTTP等服務器的配置，同時降低對系統(tǒng)管理員的水平要求，在開源軟件領域出現(xiàn)了若干款優(yōu)秀的操作系統(tǒng)自動化安裝管理工具，其中以Cobbler[3]最為簡單、易用，因此本文選擇Cobbler作為云物理服務器部署的核心工具軟件。相對于傳統(tǒng)的網(wǎng)絡安裝方式，Cobbler的特點如下:

·提供云物理服務器的啟動模式支持，只需在BIOS中將云物理服務器的啟動模式設置為網(wǎng)絡啟動優(yōu)先，之后Cobbler可以根據(jù)用戶指令控制服務器在網(wǎng)絡啟動和本地啟動之間進行正確的選擇；

·提供服務器遠程電源管理支持；

·支持常見的 Linux發(fā)行版本，如 Redhat、Centos、Fedora、Suse、Debian 等；

·支持命令行和Web界面管理，同時還提供了API，方便二次開發(fā)。

系統(tǒng)管理員通過Cobbler對物理服務器進行安裝的典型網(wǎng)絡拓撲如圖1所示。對于待安裝的服務器，系統(tǒng)管理員首先要設置其電源管理，包括IP地址、用戶名和密碼等。接下來，系統(tǒng)管理員通過命令行或Web界面在Cobbler服務器上對distro對象、profile對象、system對象等進行配置。簡單的說，distro對象對應的是Linux發(fā)行版本，profile對象對應的是如何安裝某個distro對象或發(fā)行版本，system對象對應的是待安裝服務器，主要包括電源管理、網(wǎng)絡設置（兩塊網(wǎng)卡）以及采用哪個profile對象安裝操作系統(tǒng)。然后，系統(tǒng)管理員通過命令行或Web界面使待安裝服務器基于網(wǎng)絡啟動模式重新啟動。待安裝服務器重啟后，與Cobbler服務器上的DHCP、TFTP、HTTP服務進行交互，最終完成操作系統(tǒng)的安裝。

圖1 Cobbler典型網(wǎng)絡拓撲

3 基于REST架構風格的云物理服務器部署機制設計

雖然Cobbler同時提供了命令行接口和Web界面，但是無法直接將Cobbler的Web界面集成到云主機用戶管理面板，為了使云物理服務器和云主機擁有相似的用戶管理面板，需要對Cobbler服務器進行二次開發(fā)，并提供可供Web服務器調(diào)用的API。目前有3種主流的Web服務實現(xiàn)方案，分別是 XML-RPC（remote procedure call，遠程過程調(diào)用）協(xié)議、SOAP（simple object access protocol，簡單對象訪問協(xié)議）和 REST（representational state transfer，表征狀態(tài)轉(zhuǎn)移）。由于XML-RPC只能使用有限的數(shù)據(jù)類型種類和一些簡單的數(shù)據(jù)結(jié)構，已逐漸被SOAP取代。參考文獻[4～6]對SOAP和REST網(wǎng)絡帶寬使用率、時延以及處理時間做了詳細的對比分析，分析結(jié)果表明REST的性能明顯優(yōu)于SOAP，因此，高效可伸縮的輕量級REST架構風格更加適用于Web服務實現(xiàn)。

REST架構風格是2000年Roy Fielding博士在他的博士論文[7]中首次提出的，描繪了開發(fā)基于互聯(lián)網(wǎng)的分布式軟件的松耦合架構。REST架構風格包含了兩個重要概念:資源的定位和資源的操作。資源的定位可以通過HTTP實現(xiàn)，基于HTTP，資源的操作主要有創(chuàng)建、讀取、更新和刪除，這 4個操作對應的動作分別由 post、get、update和delete表示。正是由于REST架構將資源的定位和操作進行了分離，研究人員可以很容易實現(xiàn)可擴展、可移植以及松耦合的基于Web的分布式軟件。參考文獻[8]基于REST架構風格實現(xiàn)了符合Web 2.0標準的圖書列表服務，參考文獻[9]將REST的“資源”概念與空間信息“數(shù)據(jù)”共享結(jié)合起來，設計了基于REST的空間信息服務互操作規(guī)范。參考文獻[10]將傳感節(jié)點等嵌入式設備和感知數(shù)據(jù)看作資源，采用REST將異構系統(tǒng)模塊組合，設計了一個基于REST架構風格的物聯(lián)網(wǎng)服務平臺。參考文獻[11]通過REST接口實現(xiàn)了第三方軟件和Clever平臺的集成，用戶可以通過第三方軟件訪問和使用Clever平臺的各種資源。參考文獻[12]對存儲空間提供商DropBox、Box等提供的有限免費空間，使用開放的REST接口，將多個不同的有限空間整合為一個較大的網(wǎng)絡存儲空間，并將該空間與免費的私有云集成在一起。參考文獻[13]利用REST架構風格為云計算的應用提供了訪問關系型數(shù)據(jù)和NoSQL數(shù)據(jù)的統(tǒng)一REST接口，降低了云計算應用開發(fā)者訪問不同數(shù)據(jù)類型接口的負擔。

基于REST架構風格的云物理服務器部署的網(wǎng)絡拓撲如圖2所示，Web服務器和Cobbler服務器分別位于不同的服務器上，其中REST客戶端和Web服務器安裝在一臺服務器上，REST服務端、Cobbler服務封裝和Cobbler服務器安裝在另外一臺服務器上。該架構的工作流程大致是用戶通過基于瀏覽器的用戶管理面板發(fā)送對某個云物理服務器進行操作的指令，Web服務器在收到用戶的請求后，調(diào)用 REST客戶端對應的 API，該 API通過 HTTP訪問REST服務端，REST服務端根據(jù)HTTP指向的對象以及相應的動作調(diào)用Cobbler服務封裝，Cobbler服務封裝直接調(diào)用Cobbler提供的API或命令行完成用戶指定的操作。具體的實現(xiàn)可以分為3部分:用戶瀏覽器和Web服務器之間采用AJAX技術；REST客戶端和REST服務端基于REST架構風格；Cobbler服務封裝對Cobbler服務器提供的API和命令行進行了二次開發(fā)。

圖2 基于REST架構風格的云物理服務器部署網(wǎng)絡拓撲示意

3.1 REST客戶端和服務端的設計

REST客戶端和服務端的設計架構如圖3所示。REST客戶端由API模塊和REST構造模塊兩部分構成，Web應用通過對這些API的調(diào)用實現(xiàn)對Cobbler服務器的操作和管理。REST構造模塊將各種API調(diào)用請求構造為符合REST架構風格的資源表示和操作，相應的位于REST服務端中的REST解析模塊將各種資源表示和操作解析為特定的API，并調(diào)用位于Cobbler服務封裝模塊中相應的API。在對Cobbler服務器進行深入研究和分析后，REST客戶端和服務端至少應該實現(xiàn)以下功能。

·Cobbler服務器的核心對象 distro、profile、system和kickstart腳本等的管理，包括增加、刪除、更新、列表和讀取操作，相應的API分別由distro對象管理、profile對象管理、system對象管理和 kickstart腳本管理模塊提供。

·電源管理，包括云物理服務器的開機、關機、重新啟動，其中重新啟動操作需要區(qū)分網(wǎng)絡啟動和本地啟動，相應的API由服務器電源管理模塊提供。

·服務器運行狀態(tài)監(jiān)測，與電源管理中的開機、關機和重新啟動操作相對應，需要提供各個操作執(zhí)行后服務器的實時狀態(tài)，相應的API由服務器狀態(tài)監(jiān)控模塊提供。

圖3 REST客戶端和服務端設計架構

REST客戶端中4個核心對象管理的API見表1。以list_為前綴的API列出系統(tǒng)中已經(jīng)存在的所有實例對象的名字。以get_為前綴的API以一個實例對象的名字為參數(shù)，返回該實例的詳細數(shù)據(jù)。以add_為前綴的API以一個JSON數(shù)據(jù)結(jié)構為參數(shù)，將參數(shù)中指定的實例對象添加到Cobbler服務器中。以remove_為前綴的API以一個實例對象的名字為參數(shù)，從Cobbler服務器中刪除該實例對象。以update_為前綴的API以一個JSON數(shù)據(jù)結(jié)構為參數(shù)，用參數(shù)中指定的實例對象的新數(shù)據(jù)內(nèi)容對該實例對象進行更新。

表1 核心對象的管理API

服務器電源管理的API分別是power_on、power_off和power_reboot，這3個API都以要操作的云物理服務器的編號（system對象的實例名字）為參數(shù)，分別表示對該物理服務器進行開機、關機和重新啟動操作，其中重新啟動API還需要提供第二個參數(shù)，用來指明是網(wǎng)絡啟動還是本地啟動。服務器運行狀態(tài)監(jiān)測的API為monitor_status，參數(shù)是云物理服務器的編號，返回結(jié)果包括兩個數(shù)據(jù):用戶之前發(fā)送的電源管理指令和現(xiàn)在服務器的狀態(tài)，詳細情況見表2。

表2 云物理服務器電源管理狀態(tài)

以上所有REST客戶端API具有相似的實現(xiàn)，以get_distro為例，REST客戶端API的偽代碼實現(xiàn)如下所示。

第（3）行首先獲得 Cobbler服務器的地址，第（5）行根據(jù)distro對象的實例名字name構造該distro對象的唯一資源標識，第（7）行使用HTTP的get操作獲得該對象的詳細數(shù)據(jù)，第（8）行將執(zhí)行結(jié)果以JSON格式返回給用戶。

當REST服務器端接收到來自REST客戶端的請求后，根據(jù)用戶HTTP請求中指定的資源對象，調(diào)用相應的功能模塊進行處理。該功能模塊的處理流程通常是首先獲得用戶對該資源對象要求的操作，然后從HTTP請求中讀取從用戶端以JSON格式傳送的數(shù)據(jù)，最后調(diào)用Cobbler服務封裝模塊對應的功能接口，并以JSON格式返回執(zhí)行結(jié)果。

3.2 Cobbler服務封裝的設計

Cobbler服務器提供了3種人機交互方式，分別是命令行、API和Web界面，基于REST架構風格的Cobbler服務封裝模塊則是向Web服務器或第三方應用提供的另外一種操作方式，這種操作方式是在對Cobbler服務器進行二次開發(fā)的基礎上實現(xiàn)的，同時也必須保證操作結(jié)果與Cobbler服務器提供的Web界面、API和命令行管理的一致性。圖4給出了Cobbler服務封裝模塊的設計架構。

圖4 Cobbler服務封裝模塊設計架構

從圖4中可以看到，為了實現(xiàn)對Cobbler服務器的封裝，Cobbler服務封裝模塊設計了兩種封裝模式，分別是基于API的封裝和基于命令行的封裝?；贏PI的封裝直接調(diào)用Cobbler服務器提供的Python API，而基于命令行的封裝則是模仿用戶在終端命令行上的操作。提供兩種截然不同的封裝方式的原因是若直接調(diào)用Cobbler服務器提供的API所做的寫操作，包括增加、刪除和更新操作，通過Cobbler的Web界面或者命令行都不可見，會出現(xiàn)明顯的不同步問題。查閱資料后，決定對于Cobbler服務器的只讀操作采用基于API的封裝模式，確保獲得各種對象的詳細信息，而對于Cobbler服務器的寫操作，采用基于命令行的封裝模式。

在接收到REST服務端的調(diào)用請求后，Cobbler服務封裝模塊首先會開啟一個新進程，然后再在新進程中根據(jù)需要調(diào)用基于API封裝或基于命令行封裝的操作。在每次調(diào)用Cobbler服務封裝模塊都首先開啟一個新進程是為了解決基于命令行封裝的寫操作和基于API的讀操作的實時同步問題。具體表現(xiàn)為基于命令行封裝操作向Cobbler服務器中增加的對象，通過基于API封裝的讀操作無法定位該對象，出現(xiàn)這個問題的原因是通過API調(diào)用看到的始終是REST服務端啟動時Cobbler服務器的狀態(tài)，而不是Cobbler服務器的實時狀態(tài)。

為了解決基于命令行或API調(diào)用無法獲得Cobbler服務器實時狀態(tài)的問題，根據(jù)對問題的分析，在每一次基于命令行或API調(diào)用前，在Cobbler服務封裝進程內(nèi)再啟動一個新的進程來執(zhí)行該調(diào)用，調(diào)用完成后，關閉這個專門的調(diào)用進程。這個方案可以確保在基于命令行或API調(diào)用前獲得Cobbler服務器的實時數(shù)據(jù)，從而完成Cobbler服務封裝對Cobbler服務器的二次開發(fā)，實現(xiàn)基于REST架構風格的Web應用對Cobbler服務器的管理和操作。

與REST客戶端提供的管理Cobbler服務器的核心API類似，Cobbler服務封裝模塊分別為這些API提供了具體的實現(xiàn)，具體是為Cobbler服務器的distro對象、profile對象、system對象和kickstart對象等提供了列表、讀取、增加、刪除、更新操作；為云物理服務器的電源管理提供了開機、關機、重新啟動操作；同時也提供了服務器狀態(tài)監(jiān)測操作。鑒于這些操作具有相似的實現(xiàn)框架，下面以增加一個distro對象來說明Cobbler服務封裝對Cobbler服務器的二次開發(fā)流程，偽代碼實現(xiàn)如下。

偽代碼的第（3）行檢查參數(shù)URL指向的ISO鏡像文件是否已經(jīng)下載到本地，如果尚未下載，則在第（5）行調(diào)用wget工具從用戶指定的URL進行下載。第 （6）行調(diào)用mount命令將本地的ISO鏡像文件加載到mount_dir目錄下，第（7）行將Cobbler服務器增加distro對象的命令行指令以數(shù)組形式表示，并將該數(shù)組以參數(shù)形式傳遞給第（9）行，再啟動一個新進程執(zhí)行Cobbler的命令行指令，第（10）行調(diào)用umount命令卸載第（6）行加載的ISO鏡像文件。由于Cobbler在增加distro對象時會在用戶指定的對象名稱（參數(shù)name）后自動添加一個表示服務器體系結(jié)構的字符串，第（11）行通過查詢Cobbler服務器的distro對象列表，獲得新增加的distro對象的最終的名稱，并將該名稱在第（12）行返回給調(diào)用函數(shù)。第（7）～（9）行給出了如何基于Cobbler的命令行對Cobbler服務器進行操作，基于Cobbler的API調(diào)用具有類似的過程，首先通過調(diào)用BootAPI()獲得Cobbler的句柄實例，然后根據(jù)操作的對象和動作調(diào)用相應的API，最后得到API調(diào)用的執(zhí)行結(jié)果，需要特別說明的是基于API的調(diào)用也必須在新開啟的進程中執(zhí)行。

3.3 瀏覽器客戶端設計

在對Cobbler服務器進行管理時，有一部分操作是比較費時的，如電源管理的開機、關機、重新啟動，其中的網(wǎng)絡重新啟動由于涉及操作系統(tǒng)的重新安裝，需要的時間則更長，另外使用用戶指定的網(wǎng)絡ISO鏡像向Cobbler系統(tǒng)中增加distro對象也比較費時。用戶對云物理服務器的管理是基于瀏覽器的管理面板，當用戶發(fā)出了某個操作指令后，管理面板應該能及時向用戶反饋當前操作的執(zhí)行情況，尤其是對于哪些耗時較長的操作。為實現(xiàn)這個目標，在瀏覽器端采用了基于AJAX的異步數(shù)據(jù)傳輸技術，基本的原理是用戶在管理面板上執(zhí)行一個操作，然后用戶的這個操作通過AJAX技術傳遞給Web服務器，由Web服務器上的應用完成用戶指定的任務，而在瀏覽器端，當用戶發(fā)出操作指令后，持續(xù)采用AJAX技術向Web服務器查詢操作的進展情況，直至完成了用戶的操作指令或出現(xiàn)錯誤，并將實時的任務完成進度反饋給用戶。

基于HTTP的工作原理，為了能夠獲得用戶任務執(zhí)行的進展情況，需要將相關的操作和數(shù)據(jù)保存在Web服務器上的數(shù)據(jù)庫中。以電源管理的重新啟動為例，假設云物理服務器已正常啟動，此時用戶發(fā)出了重新啟動的指令，那么用戶希望在管理面板上看到服務器重新啟動的情況，典型的狀態(tài)為:正在關機、正在重新啟動、重新啟動完畢。為了獲得云物理服務器的實時狀態(tài)，Web服務器需要通過REST架構從Cobbler服務器上獲得云物理服務器的狀態(tài)，Cobbler服務器可以通過調(diào)用ping命令直接獲得云物理服務器的狀態(tài):可連接和不可連接。

Web服務器根據(jù)用戶的操作、云物理服務器之前的狀態(tài)和實時的ping連接情況進行分析，可以得到云物理服務器的實時狀態(tài)。仍以重新啟動為例，圖5給出了重新啟動執(zhí)行時云物理服務器的狀態(tài)變遷示意，其中Y表示物理服務器可連接，N表示不可連接。在用戶發(fā)出重新啟動指令后，將重新啟動的操作和服務器的狀態(tài)“正在關機”寫入數(shù)據(jù)庫，然后基于REST架構獲得該物理服務器的連接狀態(tài)。如果是可連接，則該服務器仍然是“正在關機”的狀態(tài)；如果是不可連接，則表明服務器已經(jīng)完成了關機，該服務器的狀態(tài)變成了“正在開始重新啟動”，此時需要更新數(shù)據(jù)庫中的服務器狀態(tài)。在服務器狀態(tài)變?yōu)?“正在重新啟動”后，若通過REST架構獲得的服務器的狀態(tài)為 “不可連接”，表明服務器仍在進行重新啟動，當連接狀態(tài)變成“可連接”后，服務器完成了重新啟動，這時需要將數(shù)據(jù)庫狀態(tài)更新為重新啟動完畢。

圖5 物理服務器重新啟動的狀態(tài)變遷示意

基于瀏覽器的用戶管理面板在用戶發(fā)出重新啟動操作等指令后，通過對位于Web服務器上的數(shù)據(jù)庫相關記錄進行查詢，將正在管理的云物理服務器的實時狀態(tài)反饋給用戶，采用這種方案后，用戶對云物理服務器的操作需要根據(jù)數(shù)據(jù)庫中的相關記錄來決定，可以減少用戶的誤操作，并提高云物理服務器的工作效率。例如，用戶發(fā)出了重新啟動的指令，在指令未完成之前，用戶再次向同一臺服務器發(fā)出相同的指令，根據(jù)數(shù)據(jù)庫中服務器的狀態(tài)判斷，可以直接忽略該指令，不影響服務器之前的重新啟動過程，在用戶的管理面板看到的服務器的實時狀態(tài)仍然是第一次重新啟動指令的執(zhí)行情況。

3.4 測試驗證

在完成了基于REST架構的云物理服務器部署機制的設計和實現(xiàn)后，按照圖2所示的網(wǎng)絡拓撲，對本文所實現(xiàn)的部署機制進行了測試，其中Web服務器一臺，Cobbler服務器一臺，云物理服務器8臺。測試環(huán)境采用的服務器均為IBM iDataPlex dx 360 M2，具體配置參數(shù)見表3，其中服務器配置了2塊網(wǎng)卡和一個IPMI，2塊網(wǎng)卡分別用于內(nèi)部網(wǎng)絡和外部網(wǎng)絡，IPMI主要用來實現(xiàn)遠程電源管理。

在對云物理服務器進行部署前，首先要對這些物理服務器進行必要的配置，包括distro對象、profile對象、system對象和kickstart對象，在完成這些對象的配置后，可以開始對指定的云物理服務器進行操作。圖6給出了云物理服務器核心對象配置的界面。

表3 測試服務器配置參數(shù)

圖6 云物理服務器核心對象配置的界面

如圖6所示，云物理服務器部署測試時使用的ISO鏡像為CentOS 6.5和Ubuntu 13.04，分別測試了開機、關機、重新啟動、網(wǎng)絡重新啟動，具體測試數(shù)據(jù)見表4。需要說明的是，表4中測試時間是通過ping命令根據(jù)服務器的可連接和不可連接狀態(tài)得來的，由于測試時ping命令的時間間隔為6 s，所以各個測試結(jié)果與實際的執(zhí)行時間存在最多6 s的誤差。Cobbler服務器通過IPMI對云物理服務器進行電源管理，因此關機操作具有相同的時間，重新啟動操作是由關機、1 s的時延和開機3個操作組合完成的，完成時間等于開機時間加上關機時間，而1 s的時延相對于6 s的誤差而言，沒有體現(xiàn)出來。網(wǎng)絡重新啟動需要重新安裝操作系統(tǒng)，相對來說耗時非常長，主要原因是服務器的硬盤大小為3 TB，在安裝時自動安裝腳本的缺省配置是對整個硬盤重新分區(qū)并格式化，因此有將近70%的時間在格式化硬盤，僅有30%的時間用于操作系統(tǒng)安裝，后期會對自動安裝腳本的缺省配置進行適當修改，盡量避免不必要的重新格式化整個硬盤的時間。

表4 云物理服務器部署時間

最后對云物理服務器的并行部署進行了測試，在用戶管理面板中同時選定8個服務器，發(fā)送網(wǎng)絡重新啟動指令，依據(jù)Cobbler服務封裝ping命令的可連接狀態(tài)判定，8個服務器同時進行了關機、開機和操作系統(tǒng)安裝流程。

4 結(jié)束語

本文介紹了一種基于REST架構風格的云物理服務器部署機制，通過對Cobbler服務器進行二次開發(fā)，使用戶可以通過基于瀏覽器的管理面板對云物理服務器進行管理和操作，滿足了用戶在云計算機環(huán)境下對物理服務器進行管理的需求，同時采用與云主機管理相似的管理面板和流程，簡化了用戶的學習曲線，使用戶更加關注于自己的研究領域，提高了工作效率。接下來的研究內(nèi)容是如何讓用戶通過管理面板對自動安裝腳本進行管理，能夠在操作系統(tǒng)安裝完成后自動安裝并配置用戶指定的應用軟件，從而真正實現(xiàn)云物理服務器的一鍵部署。

1 工業(yè)和信息化部電信研究院.云計算白皮書,2014 China Academy of Telecommunication Research of the Ministry of Industry and Information Technology.Cloud Computing White Paper,2014

2 Baremetal.https://wiki.openstack.org/wiki/Baremetal,2014

3 Cobbler.http://www.cobblerd.org,2014

4 Gavin M, Denis G. A comparison of soap and rest implementations of a service based interaction independence middle ware framework. Proceedings of the 2009 Winter Simulation Conference,Austin,TX,USA,2009:1423～1431

5 Snehal M,Puja P.Web services based on SOAP and REST principles.International Journal of Scientific and Research Publications,2013,3(5)

6 王姜，余萍，曹春等.開放網(wǎng)絡環(huán)境下的程序設計:從RPC到REST.計算機工程與應用,2013,49(17):30～37 Wang J,Yu P,Cao C,et al.View of software design in open network environment:from RPC to REST.Computer Engineering and Applications,2013,49(17):30～37

7 Roy F.Architectural styles and the design of network-based software architectures (doctor dissertation). University of California,Irvine,2000

8 戴亞娥,俞成海,堯飄海等.基于REST架構風格的Web 2.0實現(xiàn).計算機系統(tǒng)應用,2009,29(7)Dai Y E,Yu C H,Yao P H,et al.Implementation of Web 2.0 based on REST-style architecture. Computer Systems&Applications,2009,29(7)

9 李波,丁仙峰,伊文英等.基于REST的空間信息服務互操作協(xié)議的研究.計算機科學,2012,39(6A)Li B,Ding X F,Yi W Y,et al.Research on geospatial information service interoperability protocol based on REST.Computer Science,2012,39(6A)

10 程冬梅,瑞聰,劉燕等.基于REST架構風格的物聯(lián)網(wǎng)服務平臺研發(fā).計算機工程與應用,2012,48(14)Cheng D M,Rui C,Liu Y,et al.Research and development of internet of things service platform based on REST style architecture.Computer Engineering and Applications,2012,48(14)

11 Antonio C,Francesco T,Massimo V,et al.Integration of clever clouds with third party software systems through a REST Web service interface.Proceedings of the 2012 IEEE Symposium on Computers and Communications (ISCC),Cappadocia,Turkey,2012:827～832

12 Raul G,Marc S A,Pedro G L.Cloud-as-a-gift:effectively exploiting personal cloud free accounts via REST API.Proceedings of the IEEE 6th International Conference on Cloud Computing,Santa Clara,CAL,USA,2013:621～628

13 Rami S,Sami B,Bruno D.ODBAPI:a unified REST API for relational and NoSQL data stores.Proceeding sof IEEE International Congress on Big Data,Anchorage,AK,USA,2014:653～660