mirror of
https://github.com/kemko/nomad.git
synced 2026-01-06 10:25:42 +03:00
b8a472d692
The `ephemeral_disk` block's `migrate` field allows for best-effort migration of the ephemeral disk data to new nodes. The documentation says the `migrate` field is only respected if `sticky=true`, but in fact if client ACLs are not set the data is migrated even if `sticky=false`. The existing behavior when client ACLs are disabled has existed since the early implementation, so "fixing" that case now would silently break backwards compatibility. Additionally, having `migrate` not imply `sticky` seems nonsensical: it suggests that if we place on a new node we migrate the data but if we place on the same node, we throw the data away! Update so that `migrate=true` implies `sticky=true` as follows: * The failure mode when client ACLs are enabled comes from the server not passing along a migration token. Update the server so that the server provides a migration token whenever `migrate=true` and not just when `sticky=true` too. * Update the scheduler so that `migrate` implies `sticky`. * Update the client so that we check for `migrate || sticky` where appropriate. * Refactor the E2E tests to move them off the old framework and make the intention of the test more clear.
70 lines
2.5 KiB
Plaintext
70 lines
2.5 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: ephemeral_disk Block - Job Specification
|
|
description: |-
|
|
The "ephemeral_disk" block describes the ephemeral disk requirements of the
|
|
group. Ephemeral disks can be marked as sticky and support live data
|
|
migrations.
|
|
---
|
|
|
|
# `ephemeral_disk` Block
|
|
|
|
<Placement groups={['job', 'group', 'ephemeral_disk']} />
|
|
|
|
The `ephemeral_disk` block describes the ephemeral disk requirements of the
|
|
group. Ephemeral disks can be marked as sticky and support live data migrations.
|
|
All tasks in this group will share the same ephemeral disk.
|
|
|
|
```hcl
|
|
job "docs" {
|
|
group "example" {
|
|
ephemeral_disk {
|
|
migrate = true
|
|
size = 500
|
|
sticky = true
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
The ephemeral disk can be referenced under `alloc/data/`. More information can
|
|
be found in the [filesystem internals][].
|
|
|
|
## `ephemeral_disk` Parameters
|
|
|
|
- `migrate` `(bool: false)` - This specifies that the Nomad client should make a
|
|
best-effort attempt to migrate the data from the previous allocation, even if
|
|
the previous allocation was on another client. Enabling `migrate`
|
|
automatically enables `sticky` as well. During data migration, the task will
|
|
block starting until the data migration has completed. Migration is atomic and
|
|
any partially migrated data will be removed if an error is encountered. Note
|
|
that data migration will not take place if a client garbage collects a failed
|
|
allocation or if the allocation has been intentionally stopped via `nomad
|
|
alloc stop`, because the original allocation has already been removed.
|
|
|
|
- `size` `(int: 300)` - Specifies the size of the ephemeral disk in MB. The
|
|
current Nomad ephemeral storage implementation does not enforce this limit;
|
|
however, it is used during job placement.
|
|
|
|
- `sticky` `(bool: false)` - Specifies that Nomad should make a best-effort
|
|
attempt to place the updated allocation on the same machine. This will move
|
|
the `local/` and `alloc/data` directories to the new allocation.
|
|
|
|
## `ephemeral_disk` Examples
|
|
|
|
The following examples only show the `ephemeral_disk` blocks. Remember that the
|
|
`ephemeral_disk` block is only valid in the placements listed above.
|
|
|
|
### Sticky Volumes
|
|
|
|
This example shows enabling sticky volumes with Nomad using ephemeral disks:
|
|
|
|
```hcl
|
|
ephemeral_disk {
|
|
sticky = true
|
|
}
|
|
```
|
|
|
|
[resources]: /nomad/docs/job-specification/resources 'Nomad resources Job Specification'
|
|
[filesystem internals]: /nomad/docs/concepts/filesystem#templates-artifacts-and-dispatch-payloads 'Filesystem internals documentation'
|