Segunda semana

Data centres nowadays have to process a large scale of jobs on a daily basis. On one hand, the resource demand, along with the commercial success of cloud computing, becomes the major driving force for the cloud providers to increase the size of their data centres. On the other hand, in order to handle the jobs efficiently, cloud giants, such as Google, Microsoft and Amazon, have devel- oped various cluster management frameworks in their production clusters [107]. Among them, one conventional approach is to develop a centralized scheduler in the cluster, which manages diverse types of job submitted to the cluster. However, because of the large number of the jobs and the complexity of making scheduling decisions for some types of job, the centralized schedulers become the performance bottleneck for delivering resources and processing jobs timely. A recent trend thus is to deploy multiple, independent schedulers in a cluster. Different schedulers make scheduling decisions simultaneously for different types of job, aiming to improve the throughput and cluster utilization. These inde- pendently working schedulers in a cluster are termed distributed schedulers in the literature [18, 88, 95].

The scheduling procedure in the cloud with distributed schedulers is illus- trated in Figure 2.4. When a request is submitted, it is compiled as a workflow with resource requirements. The workflow is modelled by a directed acyclic graph (DAG). In the graph, nodes represent jobs such as map, reduce or join jobs, and edges represent dataflow. Each job consists of one or more identical parallel tasks. Those jobs are allocated to individual pending queues corre- sponding to their dependent services based on the job type, resource preference or job size. Additionally, a distributed scheduler asynchronously scans 1 the jobs in its pending queue, and finds its best matching machines and claim the resources in these machines to launch the tasks. Different schedulers choose the machines based on their preferences in various aspects. In summary, the role of

1_{The order of scanning can be implemented using different policies. Here we set it as} FIFO (First-In-First-Out).

2. Related work

…

…

…

…

…

…

…

…

_…

Scheduler Scheduler Scheduler

Service

A Framework1

Framework

n ServiceZ

Conflict Cluster state _headbeat Job scheduling Job execu=on

…

…

…

… …

… …

…

Figure 2.4: The overview of a shared cloud

a scheduler covers two parts: Scheduling andServicing.

InScheduling, the scheduler scores resources (machines) to decide the best

ones for its jobs. The resulting scores could be very different for different sched- ulers. For example, the scheduler for Hadoop[113] or Spark[116] jobs chooses its target machines based on the machine load and data locality, whilst the scheduler for scheduling web server applications needs to perform some com- plex optimization algorithms to consider the heterogeneity and performance interference. In addition, there is a separate Resource Monitor (RM) that pe- riodically collects from all machines the reports about their resource load and

2. Related work

machine state, and then aggregates the reports as the global cluster state for all schedulers. Each scheduler thus keeps a copy of global cluster state to make its own scheduling decision.

In Servicing, the scheduler claims the resources in the target machines to

initialize, start or cancel its jobs, such as fetch needed data and install the required software packages. The time cost in initialization is not negligible in most productive clusters [18, 107]. The median initialization cost is around 25 seconds [107]. Therefore, unlike the monolithic scheduler, such as Mesos [58] and Fuxi [118], distributed schedulers do not have a central coordinator and their scheduling attempts and job initialization might conflict with each other. Once the conflict occurs, only one of the scheduling attempts is granted while others are deemed failed and consequently these schedulers have to reschedule the jobs in question.

We investigate the scheduling events in the production clusters at Google and Microsoft, which have developed their distributed cluster schedulers, Omega and Apollo, respectively. However, there exists a significant ratio of rescheduling in their daily scheduling events. Especially in Google, the ratio of task reschedule is up to 64% of total scheduling events [94].

Distributed schedulers for the large-scale cloud

The emerging trend of distributed schedulers firstly starts with Omega [95]. Since then, many similar products have been developed [18, 33, 36, 69]. Al- though these schedulers are aware of the scheduling conflicts, their focuses are on resolving the conflicts after they occur rather than trying to reduce the chance of conflict in the first place. In this thesis, we balance the size of re- quested resources in this shared cloud environment by carefully analyzing the scheduling cost, performance behaviour of the jobs and the level of competition among distributed schedulers.

2. Related work

Game-theoretical scheduling

Game-theoretical scheduling is a classic scheduling problem in the cluster man- agement [19, 31, 37, 43, 44, 71, 75, 89]. These approaches are based either on the central scheduler architectures to achieve system-level load balance [89] or resource allocation [19] between jobs and cluster machines, or on sidestepping the non-cooperative game and making each participating computer to cooperate together and achieve the global optimal performance [47, 75]. These approaches cannot be applied in our scenario as distributed schedulers are selfish and strive to maximize their own scheduling performance.

We thus model the scheduling scenario as a non-cooperative game and de- velop a theoretically proven solution to reduce the conflict possibility.

Performance metrics in Clouds

It is not straightforward to determine the suitable performance metrics to eval- uate the scheduling performance in Clouds since a variety of performance issues may be examined. Recent research has focused on reducing the makespan specif- ically on the off-line jobs [33, 69], allocation interferences [35] and the quality of performance [34] for on-line jobs. Their solutions primarily target a partic- ular type of jobs. The work [62, 117] proposes the performance concepts of Application Normalized Performance (ANP) and System Normalized Perfor- mance (SNP). The performance cost adopted in our work shares the similarity with these two metrics. But the difference is that based on them, we tailor the utility function for distributed schedulers so that that it can be applied on both on-line and off-line jobs.