2015-11-18 06:35:58 +00:00
|
|
|
---
|
|
|
|
layout: "docs"
|
2016-10-28 00:36:26 +00:00
|
|
|
page_title: "Scheduler Types - Runtime"
|
|
|
|
sidebar_current: "docs-runtime-schedulers"
|
2015-11-18 06:35:58 +00:00
|
|
|
description: |-
|
|
|
|
Learn about Nomad's various schedulers.
|
|
|
|
---
|
|
|
|
|
|
|
|
# Scheduler Types
|
|
|
|
|
2016-10-28 00:36:26 +00:00
|
|
|
Nomad has three scheduler types that can be used when creating your job:
|
|
|
|
`service`, `batch` and `system`. Here we will describe the differences between
|
|
|
|
each of these schedulers.
|
2015-11-18 06:35:58 +00:00
|
|
|
|
|
|
|
## Service
|
|
|
|
|
|
|
|
The `service` scheduler is designed for scheduling long lived services that
|
|
|
|
should never go down. As such, the `service` scheduler ranks a large portion
|
2016-10-11 19:52:50 +00:00
|
|
|
of the nodes that meet the job's constraints and selects the optimal node to
|
2017-05-10 16:45:23 +00:00
|
|
|
place a task group on. The `service` scheduler uses a best fit scoring algorithm influenced by Google's work on
|
|
|
|
[Borg](https://research.google.com/pubs/pub43438.html). Ranking this larger set of candidate nodes
|
2015-11-18 06:35:58 +00:00
|
|
|
increases scheduling time but provides greater guarantees about the optimality
|
|
|
|
of a job placement, which given the service workload is highly desirable.
|
|
|
|
|
|
|
|
## Batch
|
|
|
|
|
|
|
|
Batch jobs are much less sensitive to short term performance fluctuations and
|
|
|
|
are short lived, finishing in a few minutes to a few days. Although the `batch`
|
|
|
|
scheduler is very similar to the `service` scheduler, it makes certain
|
|
|
|
optimizations for the batch workload. The main distinction is that after finding
|
2016-10-11 19:52:50 +00:00
|
|
|
the set of nodes that meet the job's constraints it uses the power of two choices
|
2015-11-18 06:35:58 +00:00
|
|
|
described in Berkeley's Sparrow scheduler to limit the number of nodes that are
|
|
|
|
ranked.
|
|
|
|
|
|
|
|
## System
|
|
|
|
|
|
|
|
The `system` scheduler is used to register jobs that should be run on all
|
|
|
|
clients that meet the job's constraints. The `system` scheduler is also invoked
|
|
|
|
when clients join the cluster or transition into the ready state. This means
|
|
|
|
that all registered `system` jobs will be re-evaluated and their tasks will be
|
|
|
|
placed on the newly available nodes if the constraints are met.
|
|
|
|
|
|
|
|
This scheduler type is extremely useful for deploying and managing tasks that
|
2016-10-11 19:52:50 +00:00
|
|
|
should be present on every node in the cluster. Since these tasks are
|
2015-11-18 06:35:58 +00:00
|
|
|
managed by Nomad, they can take advantage of job updating, rolling deploys,
|
|
|
|
service discovery and more.
|