Workflow 系統在進行計算資源配置以前，
會先使用 Resource Monitor 系統去預測在未來 某段時間計算資源的可用度。其預測資源可用 度所需要的條件參數則是由 Resource Broker 傳 送給 Resource Monitor(如圖 3.9)，而此條件內容 為 Job 需求的 Start time、Deadline、CPU 核心頻 率、Memory Size、CPU 核心數、執行的回合數 以及每回合的網路傳輸量，然後再由 Resource Monitor 啟動 Predictor 服務預測資源可用度。
Predictor 會查詢由 Probe 與 Data Miner 所收集且 探勘過後的資源工作負載資訊，然後根據 Job 的 需 求 條 件 預 測 資 源 未 來 可 用 度 ， 並 且 由 Resource Monitor 將這些資源的可用度回傳給 Resource Broker，由 Broker 來篩選資源且進行 預訂。Resource Broker 會將這些資源由高的可 用度到低來排序，並且會優先挑選可用度最低 的資源進行與 Job 的工作需求量比較與預訂。
而被挑選的資源必須能夠滿足 Job 的工作需求 量(job size)，Broker 才會視其為合適此 Job 的資 源，並且詢問此資源是否在未來的某段時間可 預訂保留。而資源必須滿足以上所述的兩個條 件(滿足 job size 以及資源在 Job 指定的那段時間
為 free)，此 Job 才算是完成 resource reservation。
反之，只要兩者其中一個條件不成立，則 Broker 會挑選可用度次低的資源進行兩個條件比對。
如果在這個資源可用度排列中並無同時滿足兩 者條件的資源，則系統會拒絕使用者的資源預 訂請求，且由 Broker 回覆資源預訂失敗訊息給 Workflow 管理系統。
圖 3.9、資源可用度預測的軟體架構圖
以下我們將介紹此機制的預測方式並且舉例說 明。此機制會根據每天收集的資源 load 狀態，
將此 Load 狀態轉換成 Workload chain-code，如 圖 3.10 所示。
圖 3.10、CPU Workload chain-code
然後由 chain-code 表找出每一個時段在過去的 load 紀錄中，出現次數最多的 pattern，如圖 3.11
所示。
圖 3.11、負載樣式
我們必須藉由 Resource Broker 的請求，從 Job 起始時間至截止時間之間的時間長度以每小時 為單位切割成片段。然後再針對每一個片段中 的執行時段所佔的部份，從負載樣式中尋找相 符合的 load pattern。再利用下圖所示(圖 3.12) 的紅色公式算出此計算資源在這小時所能提供 的可用度，直到累加完每個片段可提供的可用 度為止。
圖 3.12、在設定時段的資源可用度預測
以下我們舉個例子說明，假設目前時間為 12:00 且 Job 的 Start time 為 12:10，而 deadline length 為 40 分鐘。依照假設條件，我們可將切 割為一個時間片段(以小時為單位)，如圖 3.13 所示。Deadline length 佔一小時的 2/3(40 分鐘/60 分鐘)。另外，假設其第一小時的 load pattern 為
2。則計算可用度為下列公式:
z 總 可 用 度 =confidence*(free-level)*Cmax* 一 小 時的秒數*(Deadline 權重值)
¾ confidence=>load pattern 出現的機率(此 load pattern 出現次數最多)
¾ free-level=>可用度的單位為 0-9(load 為 2，則 free 為 9-2=7)
¾ Cmax=>此 CPU 的最大計算量(即 CPU 為 idle 的時候)
¾ Deadline 權重值=>deadline length 在這小時所 佔的比例(40 分鐘/60 分鐘)
圖 3.13、預測時間點的切割
以下我們將介紹 Resource Monitor 預測系 統針對 sequential type 與 Teamster-G type 的資源 可用度預測以及 Resource Broker 的資源配置。
A. Sequential Type
假設目前時間為 12:00，而 sequential type 的 Job 工作需求表如表 3-1:S-T 表示為 Start Time。D-L 表示為 Deadline Length。E-T 表示為 End Time。
N-S 表示為 Node Sum。
表 3-1、sequential 工作需求表單 Start Time 12:10 Deadline Length 40 分鐘
End Time 13:00 Node Sum 1 CPU Request 1.4GHz Memory Size 512MB Job Size 1300MIPS
那我們的 Resource Monitor 系統的 Predictor 會 將滿足 Job 工作需求的資源(滿足 CPU speed、
Memory size 的使用量需求)，評估其未來一小時 的可用度(start time 加上 Deadline Length 為 50 分鐘，以一小時為最小單位，所以取一小時為 1300，則 Broker 會詢問 Site2 的這個資源在 12:10-13:00 是否為 free 狀態。如果是 free 的話，
則可以預訂資源這段時間的使用權;反之，則選 擇次低可用度的資源並且比對上述兩個條件。
假設這些資源都無法滿足上述兩個條件，Broker 會發出 reject 的訊息給 Workflow Server 給使用 者得知。
B. Parallel Type
假設目前時間為 12:00，而 Parallel type 的 Job 工 作 需 求 表 如 表 3-3:D-L 表 示 為 Deadline CPU Request 1.5GHz Memory Size 1024MB
Job Size 1500MIPS
Iteration 50 BW 80Mb
我們舉例子來說明 Parallel Type Job 的資源 配 置 方 式 ， 假 設 目 前 有 一 個 工 作 需 要 3 個 Node、CPU 頻率為 1.5 GHz、總共需執行 50 回 合以完成此工作。而在每一回合的計算時間與 通訊時間將設定分別為 40(sec)與 30(sec)，以實 際標準的網路傳輸率 50Mbps 為基準。依照此工 作的需求，套入式 3-1 與式 3-2 的公式，即可計 算出此工作的計算需求量（CP）和通訊需求量 (CM)。
其中 CPU 頻率為 1.5GHz=1500MHz，假設 CPI 值為１時，表示一個指令執行完成需要１個 脈波（clock），由此可知 1500MHz=1500MIPS。
則 計 算 結 果 以 工 作 一 回 合 的 需 求 為 CP=180000(MI)、CM=3000(Mb)。
CP(MI)=CPU 計算能力*所需資源數量*總回合 數*每回合的計算時間…[式 3-1]
CP(Mb)=網路傳輸率*總回合數*每回合通訊時 間…[式 3-2]
CP=1500(MIPS)*3(node sum)*50(iteration)*40(
sec)=9000000(MI)
CM=100Mbps*50(iteration)*30(sec)=150000(Mb)
以表 3-4 所示為目前所提供的資源 CPU 可 用度級數，主要表示預測的那個小時各個資源 CPU 效能的可用度級數，然後從每一個 site 中 挑選出可用度最高的 3 個 node 資源為一組合，並將每一個 site 的組合排序，如表 3-5。
表 3-4、預測一小時各個資源 CPU 可用度級數
首先，計算出每一個組合的工作計算量與 網路傳輸量，並且將最高可用度的組合回傳給 Resource Broker，由 Broker 將可用度與工作需 求量比較是否滿足。
表 3-5、預測一小時的所有配對組合（Load Balance）執行後的結果
我們可以算出這個例子最低可用度的資源組 合，其計算量與通訊量如下:
Site1:
計 算 量 =>0.8*[(6+5+4)×1600]÷9×3600 （ sec ）
=7680000 (MI)
通訊量=>1*100Mbps×3600= 360000(Mb) 因 為 7680000(MI)<Job 的 工 作 需 求 量 9000000(MI)，所以繼續挑選次高可用度的 Site2 組合。
Site2:
計 算 量 =>1*[(9+9+6)×1800]÷9×3600 （ sec ）
=17280000 (MI)
通訊量=>1*100Mbps×3600= 360000(Mb)
由 於 17280000(MI)>Job 的 工 作 需 求 量 9000000(MI)，因此若 Site2 的 Node1、Node5、
Node7 資源在 12:10-13:00 為 free，則資源預訂 成功。