mirror of
https://github.com/kemko/nomad.git
synced 2026-01-05 18:05:42 +03:00
and update some related pages Co-authored-by: Aimee Ukasick <aimee.ukasick@hashicorp.com> Co-authored-by: Tim Gross <tgross@hashicorp.com>
214 lines
9.2 KiB
Plaintext
214 lines
9.2 KiB
Plaintext
---
|
||
layout: docs
|
||
page_title: Nomad Enterprise
|
||
description: >-
|
||
Nomad Enterprise adds operations, collaboration, and governance capabilities
|
||
to Nomad.
|
||
|
||
Features include Resource Quotas, Sentinel Policies, and Advanced Autopilot.
|
||
---
|
||
|
||
# Nomad Enterprise
|
||
|
||
Nomad Enterprise adds collaboration, operational, and governance capabilities
|
||
to Nomad. Nomad Enterprise is available as a base Platform package with an
|
||
optional Governance & Policy add-on module.
|
||
|
||
Please navigate the sub-sections for more information about each package and
|
||
its features in detail.
|
||
|
||
~> **Note:** A Nomad Enterprise cluster cannot be downgraded to the open
|
||
source version of Nomad. Servers running the open source version of Nomad will
|
||
panic if they are joined to a Nomad Enterprise cluster, due to raft entries
|
||
relating to Enterprise features not being parseable by open source Nomad.
|
||
|
||
## Nomad Enterprise Platform
|
||
|
||
Nomad Enterprise Platform enables operators to easily upgrade Nomad as well as
|
||
enhances performance and availability through Advanced Autopilot features such
|
||
as Automated Upgrades, Enhanced Read Scalability, and Redundancy Zones.
|
||
|
||
### Long Term Support (LTS) Releases
|
||
|
||
Nomad Enterprise initiated the Long-Term Support (LTS) release program with
|
||
Nomad 1.8. Going forward, the first major release of each calendar year will be
|
||
an LTS release.
|
||
|
||
LTS releases have the following benefits for Nomad operators:
|
||
|
||
- **Extended maintenance:** Two years of critical fixes provided through minor
|
||
releases
|
||
- **Efficient upgrades:** Support for direct upgrades from one LTS release
|
||
to the next, reducing major-version upgrade risk and improving operational
|
||
efficiency.
|
||
|
||
LTS releases reduce operational overhead and risk by letting organizations
|
||
receive critical fixes in minor releases without having to upgrade their major
|
||
version more than once a year. Once you’ve upgraded to Nomad Enterprise 1.8,
|
||
you will be running on a maintained LTS release that will allow you to easily
|
||
upgrade to the next LTS major release when it's available. For more
|
||
information, refer to HashiCorp’s multi-product LTS statement.
|
||
|
||
|
||
### Automated Upgrades
|
||
|
||
Automated Upgrades allows operators to deploy a complete cluster of new
|
||
servers and then simply wait for the upgrade to complete. As the new servers
|
||
join the cluster, server logic checks the version of each Nomad server
|
||
node. If the version is higher than the version on the current set of voters,
|
||
it will avoid promoting the new servers to voters until the number of new
|
||
servers matches the number of existing servers at the previous version. Once
|
||
the numbers match, Nomad will begin to promote new servers and demote old
|
||
ones.
|
||
|
||
See the [Autopilot - Upgrade
|
||
Migrations](/nomad/tutorials/manage-clusters/autopilot#upgrade-migrations)
|
||
documentation for a thorough overview.
|
||
|
||
### Automated Backups
|
||
|
||
Automated Backups allows operators to run the snapshot agent as a long-running
|
||
daemon process or in a one-shot mode from a batch job. The agent takes
|
||
snapshots of the state of the Nomad servers and saves them locally, or pushes
|
||
them to an optional remote storage service, such as Amazon S3.
|
||
|
||
This capability provides an enterprise solution for backup and restoring the
|
||
state of Nomad servers within an environment in an automated manner. These
|
||
snapshots are atomic and point-in-time.
|
||
|
||
See the [Operator Snapshot agent](/nomad/docs/commands/operator/snapshot/agent)
|
||
documentation for a thorough overview.
|
||
|
||
### Enhanced Read Scalability
|
||
|
||
This feature enables an operator to introduce non-voting server nodes to a
|
||
Nomad cluster. Non-voting servers will receive the replication stream but will
|
||
not take part in quorum (required by the leader before log entries can be
|
||
committed). Adding explicit non-voters will scale reads and scheduling without
|
||
impacting write latency.
|
||
|
||
See the [Autopilot - Read
|
||
Scalability](/nomad/tutorials/manage-clusters/autopilot#server-read-and-scheduling-scaling)
|
||
documentation for a thorough overview.
|
||
|
||
### Redundancy Zones
|
||
|
||
Redundancy Zones enables an operator to deploy a non-voting server as a hot
|
||
standby server on a per availability zone basis. For example, in an
|
||
environment with three availability zones an operator can run one voter and
|
||
one non-voter in each availability zone, for a total of six servers. If an
|
||
availability zone is completely lost, only one voter will be lost, so the
|
||
cluster remains available. If a voter is lost in an availability zone, Nomad
|
||
will promote the non-voter to a voter automatically, putting the hot standby
|
||
server into service quickly.
|
||
|
||
See the [Autopilot - Redundancy
|
||
Zones](/nomad/tutorials/manage-clusters/autopilot#redundancy-zones)
|
||
documentation for a thorough overview.
|
||
|
||
### Multiple Vault Namespaces
|
||
|
||
Multi-Vault Namespaces enables an operator to configure a single Nomad cluster
|
||
to support multiple Vault Namespaces for topology simplicity and fleet
|
||
consolidation when running Nomad and Vault together. Nomad will automatically
|
||
retrieve a Vault token based on a job's defined Vault Namespace and make it
|
||
available for the specified Nomad task at hand.
|
||
|
||
See the [Vault Integration documentation](/nomad/docs/integrations/vault-integration#enterprise-configuration) for more information.
|
||
|
||
### Multiple Vault and Consul Clusters
|
||
|
||
Nomad Enteprise allows sepcifying multiple integrations for Consul and Vault in
|
||
the [vault](/nomad/docs/configuration/vault) and
|
||
[consul](/nomad/docs/configuration/consul) portions of the Nomad agent
|
||
configuration. After the agents are configured, Nomad jobspec writers can pick
|
||
which Consul or Vault cluster to use in their job. Nomad administrators may
|
||
also set default clusters for each in Nomad namespace configuration, as well as
|
||
deny access to certain clusters by namespace.
|
||
|
||
|
||
## Governance & Policy
|
||
|
||
Governance & Policy features are part of an add-on module that enables an
|
||
organization to securely operate Nomad at scale across multiple teams through
|
||
features such as Audit Logging, Resource Quotas, and Sentinel Policies.
|
||
|
||
### Audit Logging
|
||
|
||
Secure clusters with enhanced risk management and operational traceability to
|
||
fulfill compliance requirements. This Enterprise feature provides
|
||
administrators with a complete set of records for all user-issued actions in
|
||
Nomad.
|
||
|
||
With Audit Logging, enterprises can now proactively identify access anomalies,
|
||
ensure enforcement of their security policies, and diagnose cluster behavior
|
||
by viewing preceding user operations. Designed as an HTTP API based audit
|
||
logging system, each audit event is captured with relevant request and
|
||
response information in a JSON format that is easily digestible and familiar
|
||
to operators.
|
||
|
||
See the [Audit Logging Documentation](/nomad/docs/configuration/audit) for a
|
||
thorough overview.
|
||
|
||
### Resource Quotas
|
||
|
||
Resource Quotas enable an operator to limit resource consumption across teams
|
||
or projects to reduce waste and align budgets. In Nomad Enterprise, operators
|
||
can define [quota specifications](/nomad/docs/other-specifications/quota)
|
||
and apply them to namespaces. When a quota is attached to a namespace,
|
||
the jobs within the namespace may not consume more resources than the quota
|
||
specification allows.
|
||
|
||
This allows operators to partition a shared cluster and ensure that no single
|
||
actor can consume the whole resources of the cluster.
|
||
|
||
See the [Resource Quotas
|
||
Guide](/nomad/tutorials/governance-and-policy/quotas) for a thorough
|
||
overview.
|
||
|
||
### Sentinel Policies
|
||
|
||
In Nomad Enterprise, operators can create Sentinel policies for fine-grained
|
||
policy enforcement. Sentinel policies build on top of the ACL system and allow
|
||
operators to define policies such as disallowing jobs to be submitted to
|
||
production on Fridays or only allowing users to run jobs that use
|
||
pre-authorized Docker images. Sentinel policies are defined as code, giving
|
||
operators considerable flexibility to meet compliance requirements.
|
||
|
||
See the [Sentinel Policies Guide][] for a walk-through on deploying Sentinel
|
||
policies and the [Nomad Sentinel policy reference][] for more information on
|
||
what objects are available for policies.
|
||
|
||
## Multi-Cluster & Efficiency
|
||
|
||
Multi-Cluster & Efficiency features are part of an add-on module that enables
|
||
an organization to operate Nomad at scale across multiple clusters through
|
||
features such as Multiregion Deployments.
|
||
|
||
### Multiregion Deployments
|
||
|
||
[Multiregion Deployments] enable an operator to deploy a single job to multiple
|
||
federated regions. This includes the ability to control the order of rollouts
|
||
and how each region will behave in the event of a deployment failure.
|
||
|
||
### Dynamic Application Sizing
|
||
|
||
Dynamic Application Sizing enables organizations to optimize the resource
|
||
consumption of applications using sizing recommendations from Nomad. This
|
||
feature builds on Nomad [autoscaling capabilities] to remove the trial-and-error
|
||
routine of manually setting resource requirements. DAS comprises support for
|
||
vertical [scaling policies], a new API and UI for reviewing recommended job
|
||
changes, and a collection of Nomad Autoscaler plugins informed by best-practice
|
||
statistical measures.
|
||
|
||
## Try Nomad Enterprise
|
||
|
||
Click [here](https://www.hashicorp.com/go/nomad-enterprise) to set up a demo or
|
||
request a trial of Nomad Enterprise.
|
||
|
||
[multiregion deployments]: /nomad/docs/job-specification/multiregion
|
||
[autoscaling capabilities]: /nomad/tools/autoscaling
|
||
[scaling policies]: /nomad/tools/autoscaling/policy
|
||
[Sentinel Policies Guide]: /nomad/tutorials/governance-and-policy/sentinel
|
||
[Nomad Sentinel policy reference]: /nomad/docs/enterprise/sentinel
|