1. Cloud Resource Scheduling for Online and Batch Applications Midterm report 12/16

2. Project Goal Develop a resource management scheduling algorithm for CHT datacenter. ◦ Deploy and dynamically adjust the resource allocation. ◦ Meet the SLA of jobs.

3. 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.

4. Problem Definition Given a set of batch job B, a set of interactive job I, the number of processors M, and a penalty C. Is there a schedule to run all jobs with the total penalty no more than C? ◦ NP-Complete ◦ Design heuristics to obtain schedule with reasonable quality.

5. Heuristic Estimate the penalty of interactive jobs. Estimate the penalty of batch jobs. Determine M i and M b. ◦ The number of processing units assigned to interactive and batch jobs. *Paper accepted by ICPADS 2015.

6. After Q1 Review Use RedHat Openshift ◦ Based on Docker and Google Kubernetes  Has built-in scheduler. ◦ Should not modify the scheduler in order to keep the warranty. Find other solutions without modifying Openshift.

7. New Methods Targeting on the following two items ◦ 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.

8. Scheduler Assign a container/pod to server according to Predicate() and Priority(). ◦ Predicate(): find a list of candidate servers. ◦ Priority(): choose the server with the highest score from the candidate list. Affect the container deployment by using different weight parameters.

9. Weight Parameters Assign tasks/containers to the server with the highest score.  A i ∈ {0,1}: Server i is power on or not.  R i ∈ N: Spare resources on server i.  C i ∈ N: # of other containers on server i.

10. Available Predicates and Priorities Available Predicates ◦ Static  PodFitsPorts, PodFitsResources, NoDiskConflict, MatchNodeSelector, HostName ◦ Configurable  ServiceAffinity, LabelsPresence Available Priority ◦ Static  LeastRequestedPriority, BalancedResourceAllocation, ServiceSpreadingPriority, EqualPriority ◦ Configurable  ServiceAntiAffinity, LabelPreference

11. 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

12. Building the Rules The Container Management Component has some built-in basic rules. Dynamic adjust the thresholds according to monitoring data and services. ◦ Statistic methods.

13. 量測資料 資料包含 效能數據 比較目前效能及 SLA 效能 > SLA*0.9 利用硬體資源使用 率，推測目前效能 根據硬體資源使用 率，推測增加容器 數量 開始 以 json 格 式寫入輸 出檔 結束 紀錄服務目前容器 數量 處理完所 有服務 更新容器數量 根據硬體資源使用 率，判斷是否可減 少容器數量 F T T T F F

14. Current Status Designing a method to find proper weight parameters. Implementing the Container Management Component.

15. Keep working on the two components. Apply real monitor data as training input for our weight parameters and Container Management Component. Integrate our solution to CHT sub- system to run experiments. Next