A Genetic Algorithm for Workload Scheduling In Cloud Based e-Learning

1. A Genetic Algorithm for Workload Scheduling In Cloud Based e-Learning Octavian Morariu Cristina Morariu Theodor Borangiu University Politehnica Bucharest

2. A resource view on Public(large)/Private(small) Clouds Public Clouds Amazon, Microsoft Azure, Google General purpose Unlimited resources Private Clouds More specific purpose Limited resources Request based provisioning of resources The fact that private clouds have a more specific purpose offers an opportunity to generate near optimal scheduling for workloads

3. Resource allocation Public Clouds: FIFS No approval process involved Private Clouds: Request/Approve model Cloud administrator has to assure workload distribution/capacity when approving requests for cloud resources Approval Process implies using a reservation model for resources

4. Application of small clouds Software Testing Product Support Product Development Data mining and reporting Proof of concepts e-Learning

5. Optimum Workload Scheduling Takes into considerations the primary factors that affect performance in a virtualized environments and the dependency between them. Defining workload types CPU intensive IO intensive Memory over-commitment (VMWare) Allows allocation of more memory to the virtual machines than is actually available in the physical machine, if the virtual machines are running similar operating systems IO profile of a workload has a great impact on virtualization performance

6. Cloud Computing in E-Learning (VCL Model) VCL (Virtual Computing Laboratory) University of North Carolina Usage model is based on the workload types: Single Seat (VCL-Desktop) Multiple Synched Seats (VCL-Class) Servers (VCL-Server) Research Clusters (VCL-Research) High Performance Computing Clusters (VCL-HPC) Resources allocated: on-demand (“now”) model, or by reservation

7. Considered Scenario Workloads are provisioned and de-provisioned automatically based on a pre-generated schedule The student can use the workload to complete the laboratory activities during the scheduled time slot and when this time slot expires, the scheduler would stop the workload, de-provision it and store it in its current state. The workload for the next student is prepared, provisioned and started.

8. Request Model Planned Scheduling Requests these are submitted by the professors before the learning cycle starts and based on these requests the weekly schedule will be generated One-Off Scheduling Requests these can be submitted at any time by professors and are subject to manual approval by cloud administrators according to the existing load.

9. Genetic Algorithm Prototype Data objects and LabInstace data structure The central object LabInstance contains a reference to a Professor object, a StudentGroup, a Laborator and holds information about the duration of the class and how many times it does repeat in the week. The Laborator object contains a reference to a WorkloadType instance, which stores the workload characteristics in terms of CPU profile, IO profile and operating system details. The StudentGroup class contains the name of the student group and the number of students.

10. The Fitness Function (Hard Conditions) Total Load: Iterates all the time slots and computes a sum of all workloads that are scheduled in that time slot. If the total load scheduled is less than the maximum estimated capacity of the cloud, then 10 points are awarded. Student Group Overlap: Checks that there is no overlap in the schedule for the same student group. In other words, it assures that a student group is not scheduled twice in the same time slot. If the condition is fulfilled for all student groups, then 7 points are awarded.

11. The Fitness Function (Soft Conditions) Memory Over-commitment: This condition checks that for each time slot that only a single set of WorkloadType are scheduled. For each slot that fulfills this condition 3 points are awarded. When all time slots are evaluated, the score is divided by the number of time slots and added to the global score. CPU Intensive: Iterates the time slots and checks that no more than two CPU intensive WorkloadTypes are scheduled at the same time. For each time slot that passes this check one point is awarded. The score is again divided by the number of time slots and added to the global score. IO Intensive: Checks that for each time slot there are no more than two IO intensive WorkloadTypes scheduled. Uniform Distribution: Computes a factor characterizing the distribution of workloads. The factor is computed by first calculating the average number of workloads scheduled across all time slots and then by evaluating the difference between the calculated average and the number of workloads scheduled. A threshold of 20 workloads is considered acceptable, so if the threshold is respected across all time slots, 5 points are added to the global score.

12. The Selection Operation Done in two steps: Computing the fitness value for each individual in the population Sorting the population based on the results The best 65% individuals are selected for crossover operation

13. Crossover Operation Represents the combination of two Schedule instances that produce an offspring. The crossover operation is implemented by generating a random number X (crossover point) between 1 and N, where N is the number of LabInstances. The offspring will inherit the schedule of the first parent from LabInstance1 to LabInstanceX and the schedule of the second parent from LabInstanceX+1 to LabInstanceN.

14. The Mutation Operation Is applied to a randomly chosen subset of individuals in each generation Consists in rescheduling of one LabInstance from the data structure. The new schedule is generated by randomly assigning a new time slot for the selected LabSchedule instance. Both the LabSchedule instance and the new time slot are selected and generated randomly.

15. Genetic Algorithm Structure Step1: generateInitialPopulation() Step2: while (best individual fitness < min_fitness){ Step3: do_crossover(best 65% individuals) Step4: calculate_fitness(offsprings) Step5: remove_worst(worst 35% individuals) Step6: calculate_best_individual_fitness Step7: }

16. Experimental Results Load distribution for Windows (in gray)/Linux (in black)

17. Experimental Results CPU intensive (in gray)/IO intensive (in black)

18. Thank You