github.com/iqoqo/nomad@v0.11.3-0.20200911112621-d7021c74d101/website/pages/docs/internals/scheduling/preemption.mdx (about) 1 --- 2 layout: docs 3 page_title: Preemption 4 sidebar_title: Preemption 5 description: Learn about how preemption works in Nomad. 6 --- 7 8 # Preemption 9 10 Preemption allows Nomad to kill existing allocations in order to place allocations for a higher priority job. 11 The evicted allocation is temporary displaced until the cluster has capacity to run it. This allows operators to 12 run high priority jobs even under resource contention across the cluster. 13 14 ~> **Advanced Topic!** This page covers technical details of Nomad. You do not need to understand these details to effectively use Nomad. The details are documented here for those who wish to learn about them without having to go spelunking through the source code. 15 16 # Preemption in Nomad 17 18 Every job in Nomad has a priority associated with it. Priorities impact scheduling at the evaluation and planning 19 stages by sorting the respective queues accordingly (higher priority jobs get moved ahead in the queues). 20 21 Prior to Nomad 0.9, when a cluster is at capacity, any allocations that result from a newly scheduled or updated 22 job remain in the pending state until sufficient resources become available - regardless of the defined priority. 23 This leads to priority inversion, where a low priority task can prevent high priority tasks from completing. 24 25 Nomad has preemption capabilities for service, batch, and system jobs. The Nomad scheduler can be configured to evict lower priority running allocations 26 to free up capacity for new allocations resulting from relatively higher priority jobs, sending evicted allocations back 27 into the plan queue. 28 29 # Details 30 31 ~> **Enterprise Functionality** System job preemption is available as an Open Source 32 feature, while Batch and Service job preemption are only available as 33 Enterprise features. 34 35 Preemption is enabled by default in Nomad 0.9. Operators can use the [scheduler config](/api-docs/operator#update-scheduler-configuration) API endpoint to disable preemption. 36 37 Nomad uses the [job priority](/docs/job-specification/job#priority) field to determine what running allocations can be preempted. 38 In order to prevent a cascade of preemptions due to jobs close in priority being preempted, only allocations from jobs with a priority 39 delta of more than 10 from the job needing placement are eligible for preemption. 40 41 For example, consider a node with the following distribution of allocations: 42 43 | Job | Priority | Allocations | Total Used capacity | 44 | --------------- | -------- | ----------- | ------------------------------------------------------------------------ | 45 | cache | 70 | a6 | 2 GB Memory, 0.5 GB Disk, 1 CPU | 46 | batch-analytics | 50 | a4, a5 | <1 GB Memory, 0.5 GB Disk, 0.5 CPU>, <1 GB Memory, 0.5 GB Disk, 0.5 CPU> | 47 | email-marketing | 20 | a1, a2 | <0.5 GB Memory, 0.8 GB Disk>, <0.5 GB Memory, 0.2 GB Disk> | 48 49 If a job `webapp` with priority `75` needs placement on the above node, only allocations from `batch-analytics` and `email-marketing` are considered 50 eligible to be preempted because they are of a lower priority. Allocations from the `cache` job will never be preempted because its priority value `70` 51 is lesser than the required delta of `10`. 52 53 Allocations are selected starting from the lowest priority, and scored according 54 to how closely they fit the job's required capacity. For example, if the `75` priority job needs 1GB disk and 2GB memory, Nomad will preempt 55 allocations `a1`, `a2` and `a4` to satisfy those requirements. 56 57 # Preemption Visibility 58 59 Operators can use the [allocation API](/api-docs/allocations#read-allocation) or the `alloc status` command to get visibility into 60 whether an allocation has been preempted. Preempted allocations will have their DesiredStatus set to “evict”. The `Allocation` object 61 in the API also has two additional fields related to preemption. 62 63 - `PreemptedAllocs` - This field is set on an allocation that caused preemption. It contains the allocation ids of allocations 64 that were preempted to place this allocation. In the above example, allocations created for the job `webapp` will have the values 65 `a1`, `a2` and `a4` set. 66 - `PreemptedByAllocID` - This field is set on allocations that were preempted by the scheduler. It contains the allocation ID of the allocation 67 that preempted it. In the above example, allocations `a1`, `a2` and `a4` will have this field set to the ID of the allocation from the job `webapp`. 68 69 # Integration with Nomad plan 70 71 `nomad plan` allows operators to dry run the scheduler. If the scheduler determines that 72 preemption is necessary to place the job, it shows additional information in the CLI output for 73 `nomad plan` as seen below. 74 75 ```shell-sessionnomad plan example.nomad 76 77 + Job: "test" 78 + Task Group: "test" (1 create) 79 + Task: "test" (forces create) 80 81 Scheduler dry-run: 82 - All tasks successfully allocated. 83 84 Preemptions: 85 86 Alloc ID Job ID Task Group 87 ddef9521 my-batch analytics 88 ae59fe45 my-batch analytics 89 ``` 90 91 Note that, the allocations shown in the `nomad plan` output above 92 are not guaranteed to be the same ones picked when running the job later. 93 They provide the operator a sample of the type of allocations that could be preempted. 94 95 [omega]: https://research.google.com/pubs/pub41684.html 96 [borg]: https://research.google.com/pubs/pub43438.html 97 [img-data-model]: /img/nomad-data-model.png 98 [img-eval-flow]: /img/nomad-evaluation-flow.png