Reservation-based Scheduling

Abstract

The continuous shift towards data-driven approaches to business, and a growing attention to improving return on investments (ROI) for cluster infrastructures is generating new challenges for big-data frameworks. Systems originally designed for big batch jobs now handle an increasingly complex mix of computations. Moreover, they are expected to guarantee stringent SLAs for production jobs and minimize latency for best-effort jobs.In this paper, we introduce reservation-based scheduling, a new approach to this problem. We develop our solution around four key contributions: 1) we propose a reservation definition language (RDL) that allows users to declaratively reserve access to cluster resources, 2) we formalize planning of current and future cluster resources as a Mixed-Integer Linear Programming (MILP) problem, and propose scalable heuristics, 3) we adaptively distribute resources between production jobs and best-effort jobs, and 4) we integrate all of this in a scalable system named Rayon, that builds upon Hadoop / YARN.We evaluate Rayon on a 256-node cluster against workloads derived from Microsoft, Yahoo!, Facebook, and Cloudera's clusters. To enable practical use of Rayon, we opensourced our implementation as part of Apache Hadoop 2.6.

TetriSched

“…For TetriSched to schedule meaningfully with such constraints, jobs must also have associated runtime estimates. Prior work [1,7,[10][11][12]38] has demonstrated the feasibility of generating such estimates; this paper will demonstrate that TetriSched is resilient to mis-estimation.…”

“…While reservation systems and scheduling systems sound similar in nature, they actually solve different, complementary problems. Reservation systems such as Rayon [7]-the state-of-the-art YARN reservation system-are designed to guarantee resource availability in the long term future. It serves as an admission control system to ensure that resource guarantees are not overcommitted.…”

“…Large clusters serving a mix of business-critical analytics, long-running services, and ad hoc jobs (e.g., exploratory analytics and development/test) have become a data center staple. Many of the analytics jobs have strict time-based SLOs [7], and services have time-varying but high-priority resource demands, while ad hoc jobs are generally treated as best effort with a desire for minimal latency for the waiting user. Satisfying all of these effectively requires that a cluster scheduler exploit knowledge about job characteristics to create effective plans for resource allocation over time.…”

“…For example, studies consistently confirm that production jobs consume over 90% of cluster resources [4][5][6]35], and most of them are workflows submitted periodically by automated systems [19,32] to process data feeds, refresh models, and publish insights. They are often large and long-running, consuming tens of TBs of data and running for hours, and they come with strict completion deadlines [7]. Because they are run regularly, research confirms that the production tools developed to support them can robustly predict job runtimes as a function of resource types and quantities [1,7,[10][11][12]38].…”

“…They are often large and long-running, consuming tens of TBs of data and running for hours, and they come with strict completion deadlines [7]. Because they are run regularly, research confirms that the production tools developed to support them can robustly predict job runtimes as a function of resource types and quantities [1,7,[10][11][12]38].…”