elasticsearch/docs/reference/cluster/update-desired-nodes.asciidoc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

144 lines
4.3 KiB
Plaintext
Raw Normal View History

[[update-desired-nodes]]
=== Create or update desired nodes API
++++
<titleabbrev>Create or update desired nodes</titleabbrev>
++++
NOTE: {cloud-only}
Creates or updates the desired nodes.
[[update-desired-nodes-request]]
==== {api-request-title}
[source,console]
--------------------------------------------------
PUT /_internal/desired_nodes/<history_id>/<version>
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
Add support for CPU ranges in desired nodes (#86434) This commit adds support for CPU ranges in the desired nodes API. This aligns better with environments where administrators/orchestrators can define lower and upper bounds for the amount of CPUs that the desired node would get once deployed. This allows to provide information about the expected CPU and possible allowed overcommit that the desired node will run on. This was the previous expected body for the desired nodes API (we still support it): ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors" : 8, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Now it's possible to define `processors` or `processors_range` as in: ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors_range" : {"min": 8.0, "max": 16.0}, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Note that `max` in `processors_range` is optional. This commit also moves from representing CPUs as integers to accept floating point numbers. Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
"processors" : 8.0,
"memory" : "58gb",
Add support for CPU ranges in desired nodes (#86434) This commit adds support for CPU ranges in the desired nodes API. This aligns better with environments where administrators/orchestrators can define lower and upper bounds for the amount of CPUs that the desired node would get once deployed. This allows to provide information about the expected CPU and possible allowed overcommit that the desired node will run on. This was the previous expected body for the desired nodes API (we still support it): ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors" : 8, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Now it's possible to define `processors` or `processors_range` as in: ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors_range" : {"min": 8.0, "max": 16.0}, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Note that `max` in `processors_range` is optional. This commit also moves from representing CPUs as integers to accept floating point numbers. Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
"storage" : "2tb",
2022-02-03 05:29:02 +08:00
"node_version" : "{version}"
}
]
}
--------------------------------------------------
// TEST[s/<history_id>/test/]
// TEST[s/<version>/1/]
//////////////////////////
[source,console]
--------------------------------------------------
DELETE /_internal/desired_nodes
--------------------------------------------------
// TEST[continued]
//////////////////////////
[[update-desired-nodes-query-params]]
==== {api-query-parms-title}
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=master-timeout]
`dry_run`::
(Optional, Boolean) If `true`, then the request simulates the update and
returns a response with `dry_run` field set to `true`.
[[update-desired-nodes-desc]]
==== {api-description-title}
This API creates or update the desired nodes. External orchestrators can use
this API to let Elasticsearch know about the cluster topology, including future
changes such as adding or removing nodes. Using this information, the system is
able to take better decisions.
It's possible to run the update in "dry run" mode by adding the
`?dry_run` query parameter. This will validate the request result, but will not actually perform the update.
[[update-desired-nodes-examples]]
==== {api-examples-title}
In this example, a new version for the desired nodes with history `Ywkh3INLQcuPT49f6kcppA` is created.
This API only accepts monotonically increasing versions.
[source,console]
--------------------------------------------------
PUT /_internal/desired_nodes/Ywkh3INLQcuPT49f6kcppA/100
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
Add support for CPU ranges in desired nodes (#86434) This commit adds support for CPU ranges in the desired nodes API. This aligns better with environments where administrators/orchestrators can define lower and upper bounds for the amount of CPUs that the desired node would get once deployed. This allows to provide information about the expected CPU and possible allowed overcommit that the desired node will run on. This was the previous expected body for the desired nodes API (we still support it): ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors" : 8, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Now it's possible to define `processors` or `processors_range` as in: ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors_range" : {"min": 8.0, "max": 16.0}, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Note that `max` in `processors_range` is optional. This commit also moves from representing CPUs as integers to accept floating point numbers. Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
"processors" : 8.0,
"memory" : "58gb",
Add support for CPU ranges in desired nodes (#86434) This commit adds support for CPU ranges in the desired nodes API. This aligns better with environments where administrators/orchestrators can define lower and upper bounds for the amount of CPUs that the desired node would get once deployed. This allows to provide information about the expected CPU and possible allowed overcommit that the desired node will run on. This was the previous expected body for the desired nodes API (we still support it): ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors" : 8, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Now it's possible to define `processors` or `processors_range` as in: ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors_range" : {"min": 8.0, "max": 16.0}, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Note that `max` in `processors_range` is optional. This commit also moves from representing CPUs as integers to accept floating point numbers. Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
"storage" : "2tb",
2022-02-03 05:29:02 +08:00
"node_version" : "{version}"
}
]
}
--------------------------------------------------
// TEST
The API returns the following result:
[source,console-result]
--------------------------------------------------
{
"replaced_existing_history_id": false,
"dry_run": false
}
--------------------------------------------------
Add support for CPU ranges in desired nodes (#86434) This commit adds support for CPU ranges in the desired nodes API. This aligns better with environments where administrators/orchestrators can define lower and upper bounds for the amount of CPUs that the desired node would get once deployed. This allows to provide information about the expected CPU and possible allowed overcommit that the desired node will run on. This was the previous expected body for the desired nodes API (we still support it): ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors" : 8, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Now it's possible to define `processors` or `processors_range` as in: ``` PUT /_internal/desired_nodes/history/1 { "nodes" : [ { "settings" : { "node.name" : "instance-000187", "node.external_id": "instance-000187", "node.roles" : ["data_hot", "master"], "node.attr.data" : "hot", "node.attr.logical_availability_zone" : "zone-0" }, "processors_range" : {"min": 8.0, "max": 16.0}, "memory" : "58gb", "storage" : "1700gb", "node_version" : "8.3.0" } ] } ``` Note that `max` in `processors_range` is optional. This commit also moves from representing CPUs as integers to accept floating point numbers. Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
Additionally, it is possible to specify a processors range.
This is helpful in environments where Elasticsearch nodes can
be deployed in hosts where the number of processors that the
Elasticsearch process can use is guaranteed to be at least the
lower range and up to the upper range. This is a common scenario
in Linux deployments where cgroups is used.
[source,console]
--------------------------------------------------
PUT /_internal/desired_nodes/Ywkh3INLQcuPT49f6kcppA/101
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors_range" : {"min": 8.0, "max": 10.0},
"memory" : "58gb",
"storage" : "2tb",
"node_version" : "{version}"
}
]
}
--------------------------------------------------
//////////////////////////
[source,console]
--------------------------------------------------
DELETE /_internal/desired_nodes
--------------------------------------------------
// TEST[continued]
//////////////////////////