Changes between Version 3 and Version 4 of GTD_Cloud_One_Schedule

Timestamp:

Apr 23, 2009, 11:25:00 AM (15 years ago)

Author:

rock

Comment:

--

GTD_Cloud_One_Schedule

@@ -2 +2 @@
 = 1.簡介 =
 [[Image(one.png)]]
- * ONE官方說 Scheduler 模組負責分配pending的虛擬機器在　Hosts(dom0/實體機器)中，排程模組稱為 __'''''match making scheduler (mm_sched)'''''__(再上圖的左上方塊)，排程的演算法為　__'''''Rank Scheduling Policy__'''''，藉此可以排出資源的優先順序(針對此 VM 的需求)。mm_sched 可獨立於 oned，當 mm_sched 沒啟動時，管理者必須明確指定 submit VM　到那台主機
- * 排程的簡單運作為，當 sumbit VM　時給予__'''''『REQUIREMENTS』__'''''屬性，match making scheduler　藉此排列出順序。
-　 * REQUIREMENTS　描述範例：
+ * ONE官方說 Scheduler 模組負責分配pending的虛擬機器在 Hosts(dom0/實體機器)中，排程模組稱為 __'''''match making scheduler'''''__ (mm_sched，再上圖的左上方塊)，排程的演算法為　__'''''Rank Scheduling Policy__'''''，藉此可以排出資源的優先順序(針對此 VM 的需求)。mm_sched 可獨立於 oned，當 mm_sched 沒啟動時，管理者必須明確指定 submit VM　到那台主機
+----
+= 2.運作 =
+ * __'''''2.1 排程的運作：__''''' 當 sumbit VM　時給予__'''''『REQUIREMENTS』__'''''屬性，若 Hosts 不符合要求時，Scheduler 再根據__'''''『RANK』__'''''排列，排列的第一名則可 submit VM
+>>Rock：Rank 的機制是當 Requirment 無法找到最佳 Host 時，退而求次佳的 Host
+　　* VM 設定檔的 REQUIREMENTS 和 RANK 範例：
+{{{
+MEMORY= 512                                                                      
+CPU   = 1
+
+### Disks & NICS ###
+DISK = [ IMAGE="/local/VM/disk.img",DEVICE="sda" ]            
+DISK = [ IMAGE="../debian.iso",DEVICE="sdb",BOOT="true" ]
+NIC= [ MAC="00:16:3e:01:01:03" ]
+
+### Scheduling Attributes for the rank policy　(VM 需要 CPU = 1和　Memory =　512　之外，排程時還需考慮 CPUSPEED > 1000 ) ###
+REQUIREMENTS= CPUSPEED > 1000
+RANK= FREECPU
+}}}
+ * __'''''2.2 Requirement 語法：__'''''
+  * Requirement 判斷句(採布林真假值的判斷句 0(假) 或 1(真))用來評估 Host 為 True才考慮 submit VM，
+　　* 支援的邏輯運算有：>(大於) <(小於) &(和) |(或) !(非)，也支援shell wildcard pattern matching
+  * 可使用的 REQUIREMENTS 有 (HOSTNAME, TOTALCPU, TOTALMEMORY, FREEMEMORY, FREECPU, USEDMEMORY, USEDCPU...等)
+　　* 若是想自訂　REQUIREMENTS　可修改 IM driver (因可用的屬性質都是來自於 IM)
+  * 範例：
 {{{
 ### 偏好將 VM Submit 到主機名稱為 aquila 開頭的 ###
 REQUIREMENTS = 'HOSTNAME = "aquila*"'
 
-### 偏好將 VM Submit 到主機 CPU　Free　狀態 60% 的主機 ###
+### 偏好將 VM Submit 到主機 CPU Free 狀態 60% 的主機 ###
 REQUIREMENTS = FREECPU > 0.6 #Only those resources with more than 60% of free CPU
 }}}
- * 若是 ONE　提供的　match making scheduler　無法滿足需求，可使用[http://haizea.cs.uchicago.edu/ Haizea] 模組來做到進階的 eservation of resources 和 queuing of best effort requests (似乎是使用 lease　的方式)
-   * 
+>> 比較著重在 CPU 和 Memory 的需求描述
+ * __'''''2.2 Rank 語法：__'''''
+   * Rank 判斷句是用來評估 each Host information，支援算術運算：+ - / *
+   * Rank 也可使用 REQUIREMENT 的屬性
+   * 範例：
+{{{
+### 高 Free CPU 的 Host 優先 ### 
+RANK = FREECPU 
+
+### 也考慮到 CPU 的溫度 ###
+RANK = FREECPU * 100 - TEMPERATURE 
+}}}
+----
+= 3.進階排程模組 =
+ * 若是 ONE 提供的 match making scheduler 無法滿足需求，可使用[http://haizea.cs.uchicago.edu/ Haizea] 模組來做到進階的 eservation of resources 和 queuing of best effort requests (似乎是使用 lease　的方式)
 >> Rock：看介紹還不是很清楚 Haizea 如何運作
 ----
-= 2.想法 =
- * !MatchRanking 似乎只能讓 VM　選到最佳的 Host，(例如當VM需要運算 CUDA 時，在　REQUIREMENTS　可描述需要顯卡資源，當 VM submit 時就會優先考量到有顯卡的機器，但是當每一臺都沒有顯卡時又會怎樣呢＠＠)
+= 4.想法 =
+ * !MatchRanking 似乎只能讓 VM 選到最佳的 Host，(例如當VM需要運算 CUDA 時，在 REQUIREMENTS 可描述需要顯卡資源，當 VM submit 時就會優先考量到有顯卡的機器，但是當每一臺都沒有顯卡時又會怎樣呢＠＠)
  * 如果想做到類似 EC2 SQS　的機制，當　Queue　滿檔時，且虛擬機器負載也很重，似乎就無法透過　!MatchRanking　來動態開啟 VM
->> Rock：感覺 !MatchRanking　是 VM Placement　的排程(也就是當 VM submit 時才會排程)，尚無法做到根據系統的整體動態環境來做到更上層的排程，不知　Haizea　是否可以做到此功能呢
-
-
+>> Rock：感覺 !MatchRanking 是 VM Placement 的排程(也就是當 VM submit 時才會排程)，尚無法做到根據系統的整體動態環境來做到更上層的排程，不知 Haizea 是否可以做到此功能呢
+ * 測試步驟
+----
+= 5.參考 =
+ * [http://www.opennebula.org/doku.php?id=documentation:rel1.2:cg#scheduler_configuration Scheduler Configuration]
+ * [http://www.opennebula.org/doku.php?id=documentation:ug#requirement_expression_syntax Requirement Expression Syntax]
+ * [http://www.opennebula.org/doku.php?id=documentation:ug#rank_expression_syntax Rank Expression Syntax]
+ * 
 [[BR]]
 [[BR]]