github.com/ferranbt/nomad@v0.9.3-0.20190607002617-85c449b7667c/website/source/docs/schedulers.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Schedulers"
     4  sidebar_current: "docs-schedulers"
     5  description: |-
     6    Learn about Nomad's various schedulers.
     7  ---
     8  
     9  # Schedulers
    10  
    11  Nomad has three scheduler types that can be used when creating your job:
    12  `service`, `batch` and `system`. Here we will describe the differences between
    13  each of these schedulers.
    14  
    15  ## Service
    16  
    17  The `service` scheduler is designed for scheduling long lived services that
    18  should never go down. As such, the `service` scheduler ranks a large portion
    19  of the nodes that meet the job's constraints and selects the optimal node to
    20  place a task group on. The `service` scheduler uses a best fit scoring algorithm
    21  influenced by Google's work on [Borg]. Ranking this larger set of candidate
    22  nodes increases scheduling time but provides greater guarantees about the
    23  optimality of a job placement, which given the service workload is highly
    24  desirable.
    25  
    26  Service jobs are intended to run until explicitly stopped by an operator. If a
    27  service task exits it is considered a failure and handled according to the job's
    28  [restart] and [reschedule] stanzas.
    29  
    30  ## Batch
    31  
    32  Batch jobs are much less sensitive to short term performance fluctuations and
    33  are short lived, finishing in a few minutes to a few days. Although the `batch`
    34  scheduler is very similar to the `service` scheduler, it makes certain
    35  optimizations for the batch workload. The main distinction is that after finding
    36  the set of nodes that meet the job's constraints it uses the power of two
    37  choices described in Berkeley's [Sparrow] scheduler to limit the number of nodes
    38  that are ranked.
    39  
    40  Batch jobs are intended to run until they exit successfully. Batch tasks that
    41  exit with an error are handled according to the job's [restart] and [reschedule]
    42  stanzas.
    43  
    44  ## System
    45  
    46  The `system` scheduler is used to register jobs that should be run on all
    47  clients that meet the job's constraints. The `system` scheduler is also invoked
    48  when clients join the cluster or transition into the ready state. This means
    49  that all registered `system` jobs will be re-evaluated and their tasks will be
    50  placed on the newly available nodes if the constraints are met.
    51  
    52  This scheduler type is extremely useful for deploying and managing tasks that
    53  should be present on every node in the cluster. Since these tasks are
    54  managed by Nomad, they can take advantage of job updating, rolling deploys,
    55  service discovery and more.
    56  
    57  Since Nomad 0.9, the system scheduler will preempt eligible lower priority
    58  tasks running on a node if there isn't enough capacity to place a system job.
    59  See [preemption] for details on how tasks that get preempted are chosen.
    60  
    61  Systems jobs are intended to run until explicitly stopped either by an operator
    62  or [preemption]. If a system task exits it is considered a failure and handled
    63  according to the job's [restart] stanza; system jobs do not have rescheduling.
    64  
    65  [Borg]: https://research.google.com/pubs/pub43438.html
    66  [Sparrow]: https://cs.stanford.edu/~matei/papers/2013/sosp_sparrow.pdf
    67  [preemption]: /docs/internals/scheduling/preemption.html
    68  [restart]: /docs/job-specification/restart.html
    69  [reschedule]: /docs/job-specification/reschedule.html