github.com/anth0d/nomad@v0.0.0-20221214183521-ae3a0a2cad06/website/content/docs/schedulers.mdx (about)

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