第三節 研究架構
本學位論文共分為五章，其內容安排如下：
第一章：緒論
討論本學位論文的背景、動機與目的，以及闡述論文架構。
第二章：文獻探討
彙整本學位論文相關技術文獻並予以探討。
第三章：問題描述與方法
描述本學位論文研究之問題架構與所提出的方法其環境設置、細節。
第四章：實驗結果
所提方法之效能比較分析。
第五章：結論
總結本學位論文提出的結果。
3
第二章 文獻探討
在兼顧服務級別協議（Service Level Agreement，SLA）之下盡可能的優化配置結果是 節能的首要目標。
關於雲端運算，美國國家技術標準研究所（National Institute of Standards and Technology，NIST）[4]定義：「Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing
resources that can be rapidly provisioned and released with minimal management effort or service provider interaction.」雲端運算是由無數單一主機組成之運算叢集，對外透過連 接網路溝通，雲中各個主機的運算能力、儲存空間…等被視為一個整體，當有工作進 入而需要處理的時候，即從廣大的資源池中撈取對應資源使用，由一管理者節點統籌 其餘節點進行運算工作；以Apache根據Google所發表的MapReduce、Google檔案系統
（Google File System，GFS）開發的開源軟體（Open Source Software，OSS）Hadoop 為例，由一個Master節點與許多Worker節點組成其架構，Master節點負責接收運算任 務、分配工作、監控各個Worker狀態、提供管理介面。將雲看作一台大型主機，經由 管理者節點進入操作，其餘節點皆是運算設備。
4
另外NIST亦定義[4]雲端運算所須具備的五個基礎特徵，三種服務模式與四種部 屬模型，底下將針對各種使用時機一一列舉介紹。
一、基礎特徵
1. 隨選自動化服務（On-demand self-service）
消費者可以決定服務時間、儲存空間…等欲購買的服務分量，過程均是自動化，不 需要同服務供應商方人力協定。
2. 寬頻網路存取（Broad network access）
服務經由網路提供，從各種不同的客戶端（例：智慧型手機、桌上型電腦、筆記型 電腦）可以透過標準化的介面存取使用。
3. 運算資源共用（Resource pooling）
服務供應商的資源以多租戶模式對多位消費者租賃，並且其所使用的硬體資源或虛 擬資源可以根據消費者的需求動態配置或重新分配。消費者無法知道所取用的資源 其實體位置。
4. 敏捷彈性調整（Rapid elasticity）
能夠彈性提供資源，並在某些情況下可以按需求迅速擴充規模，對消費者而言資源 的供應經常是沒有限度的，並且能夠在任何時間存取。
5. 計量式服務（Measured service）
資源的使用狀態可以被監控、控制並且透明，可即時給予服務供應商與消費者雙方 知道。
二、服務模式
1. 軟體即服務（Software as a Service，SaaS）
以往的軟體是購買並安裝在消費者的主機上運行，SaaS提供的服務是運行於雲端之 上，消費者通過客戶端介面（例：瀏覽器）來操作軟體，不能控制也無須考慮雲端 方的環境設定，如：作業系統、儲存空間；雲端供應商以租賃方式提供軟體服務，
消費者不再全額購買整套軟體，僅在需要的期間或為部分功能付費。
2. 平台即服務（Platform as a Service，PaaS）
雲端供應商提供平台讓消費者部屬自行編寫或取得的程式於雲上，並可 設定程式相關環境，但消費者均不觸及底層設定；同時雲端供應商提供 為數眾多的服務與工具供程式開發人員選擇，縮減開發時程，並在需要
5
圖 2：雲端運算的服務模式[5]
時能夠及時擴充部屬環境[5]。
3. 基礎架構即服務（Infrastructure as a Service，IaaS）
如圖２所示，IaaS相對其他兩種服務模式更加低階，消費者因此可以自行管理儲存
2. 社群雲（Community cloud）
由數個利益相仿的組織共同建構成，社群內的成員共通使用資料與應用程式，可能 由組織自行管理或由第三方協助管理[6]。
3. 公用雲（Public cloud）
這是目前雲端運算部屬的主要形式，向大眾公開的雲，但供應者仍擁有其所有權[6]，
並能夠自行設置協議、要求驗證公用雲。可能由組織自行管理或由第三方協助管理，
例如：Google AppEngine。
4. 混合雲（Hybrid cloud）
如模式名稱所述，混合一個以上至多個不同模式的雲，可能包含私有雲、社群雲與 公用雲；組織為優化其效率，將核心以外部分外包給雲端供應商處理，但這亦可能
6
需面對雲與雲之間標準不一的問題。
第二節 虛擬化技術
虛擬化技術是雲端運算中重要的核心技術，藉著虛擬化技術，雲端運算得以擁有 易於擴充規模的高度延展性，於運算任務的分派上也十分靈活，並降低重新配置的困 難度，讓各種資源配置方法能夠導入與實行，於許多方面都是雲端運算受人矚目的優 勢的促成者。
虛擬化技術於宿主的硬體平台之上模擬出一個擬似實際硬體設施的環境供給客 戶機執行，可能容納數個客戶機同時運行而不互相衝突，客戶機的作業系統類型並沒 有特別的限制，在宿主機上的運行環境就如同運行在實際的硬體設備上面一般，虛擬 化技術大致分為以下兩種類：
一、全虛擬化
全虛擬化（Full virtualization）為在一硬體上建置一虛擬化平台（Hypervisor），
所有客戶機皆運行在虛擬化平台之上，如圖３所示。虛擬化平台藉由模擬出硬體設備 的介面與供給可操作底層設備的指令，讓客戶機的作業系統可以直接運行在虛擬化平 台之上，而沒有必要再進行修改，在全虛擬化平台上運行的作業系統種類較多。採用 全虛擬化技術的軟體例如：VMware。
7
圖 3：全虛擬化[7]
二、半虛擬化
相較於全虛擬化，半虛擬化（Para-virtualization）平台只有模擬出部分的硬體設 備，亦即運行在其半虛擬化平台上的客戶機其中一部分是直接控制底層硬體設備，在 半虛擬化的狀況中為讓客戶機的作業系統順利運行，通常需要修改其核心，因此可以 運行的作業系統種類較少，但效率較高。採用半虛擬化技術的軟體例如：Microsoft Hyper-V。
8
圖 4：半虛擬化[7]
第三節 動態資源管理方法
雲端運算中為求節省能源，需要適當管理使用的資源。進入雲中的運算任務來自 許多不同的來源，所要求的資源種類、大小皆不同，處理所需時間也各異，且供應商 需要同時考量服務品質（Quality of Service，QoS），無法直覺地得到最佳的資源配置。
藉由導入動態資源管理方法（Dynamic resource allocation）能夠優化資源配置，並兼 顧省電節能與遵守服務級別協議兩個方面。
於資源管理方法之中，將虛擬機器（Virtual Machines，VMs）視為最基本的處理 單位，而不再往下考慮單一程序。當一虛擬機器抵達雲時，根據其對資源的使用量適 當的分配交由實體機器處理；雖然於一開始時已經進行適當配置，但雲的運行中途陸
續有虛擬機器完成工作而離開與新的虛擬機器抵達開始工作，之後即使盡量優化 虛擬機器的分配，也可能無法達到最佳配置。根據虛擬機器其上運行工作的不同，實 體機器可能呈現過載（Overload）危及服務品質，或者進入閒置（Idle）狀態導致效率
不佳，此時重新考量資源配置將虛擬機器轉移（Migration）至合適的實體機器以 解決問題，動態資源管理流程如圖５所示。
資源管理方法一般而言於有新的任務抵達時或運行一段時間後重新配置，有負載 平衡（Load balancing）與集中整合（Consolidation）兩種方向。
9
圖 5：動態資源管理流程[8]
一、負載平衡
目標為平衡各實體機器的負載，避免工作任務過度集中在某台機器當中，如圖６ 所示，PM1的虛擬機器轉移至PM3，讓三台機器的負載量相同。
二、集中整合
與負載平衡相反，它是盡可能的集中工作任務，沒有工作任務需要處理的實體機 器可以關閉或進入休眠以減少耗能，如圖６演示，PM2與PM3的工作任務集中轉移至 PM1，無工作任務需要處理的PM2與PM3即可以關閉。
僅管虛擬機器的轉移可以幫助優化資源配置以達節能效果，但是轉移需要耗費額 外的資源與電力，且進行轉移動作的之前與中途皆須花費時間，這些都是轉移動作不 得不考慮的成本。Jansen與Brenner[9]討論了當任務工作抵達時七種不同的處理策略，
以下為各方法分別描述介紹：
1. Round Robin
輪循過所有的實體機器，當尋找到擁有足夠資源負擔該工作的實體機器，即將工作 分配之。重複相同的動作，直到所有的工作分配完畢。旨在盡量分散工作於各實體
10
圖 6：動態資源管理工作配置的兩種方向[8]
機器中。
2. Striping
首先忽略資源不足以負擔該工作的實體機器，而後自剩餘的實體機器中挑選資源使 用率最低的實體機器，將工作分配於其上，依此類推分配所有的工作。此策略形似 Round Robin，旨在平均分散工作。
3. Packing
此一策略類似於Striping，但在分配工作的方法上與之恰恰相反，其自所有可負擔該 工作的實體機器中，選擇使用率最高的將工作分配之。此策略目標不同於前兩種分 配策略，旨在集中工作從而減少運行的實體機器數量。
4. Load Balancing（free CPU count）
如策略名稱所示，此一策略的抉擇根據為實體機器其可使用的CPU數量。首先忽略 自身資源不足以負擔工作的實體機器，自能夠負擔該工作的實體機器中進一步選擇 可使用的CUP數量最多的分配之。
5. Load Balancing（free CPU ratio）
形似Load Balancing（free CPU count），但此一策略為選擇CPU使用率較低的實體 機器分配之。此二策略的目的皆為平衡各個機器的CPU負載，為免影響其運行的效 果。
6. Watts per Core
此一策略為於所有足以負擔該工作的實體機器中，選擇與當前狀況相比，加入該工
11
作處理之後使用電力增加最少瓦數者。以耗費最少電力為目標，從而減少總電力的
作處理之後使用電力增加最少瓦數者。以耗費最少電力為目標，從而減少總電力的