Cloud Resource Scheduling for Online and Batch Applications
Midterm report 12/16
Project Goal
Develop a resource management sche duling algorithm for CHT datacente r.
◦Deploy and dynamically adjust the res ource allocation.
◦Meet the SLA of jobs.
Types of Jobs
Interactive job
◦Latency-sensitive
◦State-less
◦Strict SLA
Response time, query per seconds … etc.
Batch job
◦Consists of many (independent) tasks.
◦Soft deadline.
Problem Definition
Given a set of batch job B, a set of interactive job I, the number o f processors M, and a penalty C. I s there a schedule to run all jobs with the total penalty no more tha n C?
◦NP-Complete
◦Design heuristics to obtain schedule with reasonable quality.
Heuristic
Estimate the penalty of interactiv e jobs.
Estimate the penalty of batch jobs .
Determine Mi and Mb.
◦The number of processing units assign ed to interactive and batch jobs.
*Paper accepted by ICPADS 2015.
After Q1 Review
Use RedHat Openshift
◦Based on Docker and Google Kubernetes
Has built-in scheduler.
◦Should not modify the scheduler in or der to keep the warranty.
Find other solutions without modif ying Openshift.
New Methods
Targeting on the following two ite ms
◦Scheduler
Try to affect the deployment of container without modifying the code.
◦Container Management Component
Decide and adjust the number of container for each service in order to meet SLA.
Scheduler
Assign a container/pod to server a ccording to Predicate() and Priori ty().
◦Predicate(): find a list of candidate servers.
◦Priority(): choose the server with th e highest score from the candidate li st.
Affect the container deployment by using different weight parameters.
Weight Parameters
Assign tasks/containers to the ser ver with the highest score.
Ai ∈ {0,1}: Server i is power on or not.
Ri ∈ N: Spare resources on server i.
Ci ∈ N: # of other containers on server i .
...
w ..., )
(-
*
*
*
Si w1 Ai w2 Ri w3 Ci 1 w2 w3
Available Predicates and Prioriti es
Available Predicates
◦ Static
PodFitsPorts, PodFitsResources, NoDiskConflict, MatchNod eSelector, HostName
◦ Configurable
ServiceAffinity, LabelsPresence
Available Priority
◦ Static
LeastRequestedPriority, BalancedResourceAllocation, Serv iceSpreadingPriority, EqualPriority
◦ Configurable
ServiceAntiAffinity, LabelPreference
Container Management Component
Decide the number of container/pod for each service according to the monitoring data.
◦Ex: add one container if the average CPU utilization is higher than 85%.
◦An alternative of RedHat Rule Engine
Building the Rules
The Container Management Component has some built-in basic rules.
Dynamic adjust the thresholds acco rding to monitoring data and servi ces.
◦Statistic methods.
量測資料
資料包含效能數據
比較目前效能及 SLA
效能 >
SLA*0.9
利用硬體資源使用 率，推測目前效能
根據硬體資源使用 率，推測增加容器
數量 開始
以 json 格式寫入輸出檔
結束 紀錄服務目前容器
數量
處理完所有服務 更新容器數量
根據硬體資源使用 率，判斷是否可減
少容器數量
F T
T
T F
F
Current Status
Designing a method to find proper weight parameters.
Implementing the Container Managem ent Component.
Keep working on the two components .
Apply real monitor data as trainin g input for our weight parameters and Container Management Component .
Integrate our solution to CHT sub- system to run experiments.
