2015-08-24 18:10:20 -04:00
|
|
|
[[discovery-ec2]]
|
|
|
|
=== EC2 Discovery Plugin
|
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The EC2 discovery plugin provides a list of seed addresses to the
|
|
|
|
{ref}/modules-discovery-hosts-providers.html[discovery process] by querying the
|
|
|
|
https://github.com/aws/aws-sdk-java[AWS API] for a list of EC2 instances
|
|
|
|
matching certain criteria determined by the <<discovery-ec2-usage,plugin
|
|
|
|
settings>>.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
*If you are looking for a hosted solution of {es} on AWS, please visit
|
|
|
|
http://www.elastic.co/cloud.*
|
2016-08-24 09:38:30 -04:00
|
|
|
|
2017-04-20 09:01:37 -04:00
|
|
|
:plugin_name: discovery-ec2
|
|
|
|
include::install_remove.asciidoc[]
|
2015-08-24 18:10:20 -04:00
|
|
|
|
|
|
|
[[discovery-ec2-usage]]
|
2019-05-22 04:26:41 -04:00
|
|
|
==== Using the EC2 discovery plugin
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The `discovery-ec2` plugin allows {es} to find the master-eligible nodes in a
|
|
|
|
cluster running on AWS EC2 by querying the
|
|
|
|
https://github.com/aws/aws-sdk-java[AWS API] for the addresses of the EC2
|
|
|
|
instances running these nodes.
|
|
|
|
|
|
|
|
It is normally a good idea to restrict the discovery process just to the
|
|
|
|
master-eligible nodes in the cluster. This plugin allows you to identify these
|
|
|
|
nodes by certain criteria including their tags, their membership of security
|
|
|
|
groups, and their placement within availability zones. The discovery process
|
|
|
|
will work correctly even if it finds master-ineligible nodes, but master
|
|
|
|
elections will be more efficient if this can be avoided.
|
|
|
|
|
|
|
|
The interaction with the AWS API can be authenticated using the
|
|
|
|
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html[instance
|
|
|
|
role], or else custom credentials can be supplied.
|
|
|
|
|
|
|
|
===== Enabling EC2 discovery
|
|
|
|
|
|
|
|
To enable EC2 discovery, configure {es} to use the `ec2` seed hosts provider:
|
2015-08-24 18:10:20 -04:00
|
|
|
|
|
|
|
[source,yaml]
|
|
|
|
----
|
2019-02-05 03:46:52 -05:00
|
|
|
discovery.seed_providers: ec2
|
2015-08-24 18:10:20 -04:00
|
|
|
----
|
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
===== Configuring EC2 discovery
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
EC2 discovery supports a number of settings. Some settings are sensitive and
|
|
|
|
must be stored in the {ref}/secure-settings.html[{es} keystore]. For example,
|
|
|
|
to authenticate using a particular access key and secret key, add these keys to
|
|
|
|
the keystore by running the following commands:
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2017-08-15 13:14:51 -04:00
|
|
|
[source,sh]
|
2015-08-24 18:10:20 -04:00
|
|
|
----
|
2017-08-15 13:14:51 -04:00
|
|
|
bin/elasticsearch-keystore add discovery.ec2.access_key
|
|
|
|
bin/elasticsearch-keystore add discovery.ec2.secret_key
|
2015-08-24 18:10:20 -04:00
|
|
|
----
|
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The available settings for the EC2 discovery plugin are as follows.
|
|
|
|
|
2019-09-04 13:12:03 -04:00
|
|
|
`discovery.ec2.access_key` ({ref}/secure-settings.html[Secure], {ref}/secure-settings.html#reloadable-secure-settings[reloadable])::
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
An EC2 access key. If set, you must also set `discovery.ec2.secret_key`.
|
|
|
|
If unset, `discovery-ec2` will instead use the instance role. This setting
|
2019-09-04 13:12:03 -04:00
|
|
|
is sensitive and must be stored in the {es} keystore.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-09-04 13:12:03 -04:00
|
|
|
`discovery.ec2.secret_key` ({ref}/secure-settings.html[Secure], {ref}/secure-settings.html#reloadable-secure-settings[reloadable])::
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
An EC2 secret key. If set, you must also set `discovery.ec2.access_key`.
|
2019-09-04 13:12:03 -04:00
|
|
|
This setting is sensitive and must be stored in the {es} keystore.
|
2016-12-03 17:47:00 -05:00
|
|
|
|
2019-09-04 13:12:03 -04:00
|
|
|
`discovery.ec2.session_token` ({ref}/secure-settings.html[Secure], {ref}/secure-settings.html#reloadable-secure-settings[reloadable])::
|
2018-07-03 09:12:07 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
An EC2 session token. If set, you must also set `discovery.ec2.access_key`
|
|
|
|
and `discovery.ec2.secret_key`. This setting is sensitive and must be
|
2019-09-04 13:12:03 -04:00
|
|
|
stored in the {es} keystore.
|
2016-12-05 13:29:17 -05:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.endpoint`::
|
2016-12-03 17:47:00 -05:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The EC2 service endpoint to which to connect. See
|
|
|
|
http://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region to find
|
|
|
|
the appropriate endpoint for the region. This setting defaults to
|
|
|
|
`ec2.us-east-1.amazonaws.com` which is appropriate for clusters running in
|
|
|
|
the `us-east-1` region.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.protocol`::
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The protocol to use to connect to the EC2 service endpoint, which may be
|
|
|
|
either `http` or `https`. Defaults to `https`.
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.proxy.host`::
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The address or host name of an HTTP proxy through which to connect to EC2.
|
|
|
|
If not set, no proxy is used.
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.proxy.port`::
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
When the address of an HTTP proxy is given in `discovery.ec2.proxy.host`,
|
|
|
|
this setting determines the port to use to connect to the proxy. Defaults to
|
|
|
|
`80`.
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-09-04 13:12:03 -04:00
|
|
|
`discovery.ec2.proxy.username` ({ref}/secure-settings.html[Secure], {ref}/secure-settings.html#reloadable-secure-settings[reloadable])::
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
When the address of an HTTP proxy is given in `discovery.ec2.proxy.host`,
|
|
|
|
this setting determines the username to use to connect to the proxy. When
|
|
|
|
not set, no username is used. This setting is sensitive and must be stored
|
2019-09-04 13:12:03 -04:00
|
|
|
in the {es} keystore.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-09-04 13:12:03 -04:00
|
|
|
`discovery.ec2.proxy.password` ({ref}/secure-settings.html[Secure], {ref}/secure-settings.html#reloadable-secure-settings[reloadable])::
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
When the address of an HTTP proxy is given in `discovery.ec2.proxy.host`,
|
|
|
|
this setting determines the password to use to connect to the proxy. When
|
|
|
|
not set, no password is used. This setting is sensitive and must be stored
|
2019-09-04 13:12:03 -04:00
|
|
|
in the {es} keystore.
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.read_timeout`::
|
2017-08-15 13:14:51 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The socket timeout for connections to EC2,
|
|
|
|
{ref}/common-options.html#time-units[including the units]. For example, a
|
|
|
|
value of `60s` specifies a 60-second timeout. Defaults to 50 seconds.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.groups`::
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
A list of the names or IDs of the security groups to use for discovery. The
|
|
|
|
`discovery.ec2.any_group` setting determines the behaviour of this setting.
|
|
|
|
Defaults to an empty list, meaning that security group membership is
|
|
|
|
ignored by EC2 discovery.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.any_group`::
|
|
|
|
|
|
|
|
Defaults to `true`, meaning that instances belonging to _any_ of the
|
|
|
|
security groups specified in `discovery.ec2.groups` will be used for
|
|
|
|
discovery. If set to `false`, only instances that belong to _all_ of the
|
|
|
|
security groups specified in `discovery.ec2.groups` will be used for
|
|
|
|
discovery.
|
|
|
|
|
|
|
|
`discovery.ec2.host_type`::
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2017-01-23 07:34:40 -05:00
|
|
|
+
|
|
|
|
--
|
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
Each EC2 instance has a number of different addresses that might be suitable
|
|
|
|
for discovery. This setting allows you to select which of these addresses is
|
|
|
|
used by the discovery process. It can be set to one of `private_ip`,
|
|
|
|
`public_ip`, `private_dns`, `public_dns` or `tag:TAGNAME` where `TAGNAME`
|
|
|
|
refers to a name of a tag. This setting defaults to `private_ip`.
|
2017-01-23 07:34:40 -05:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
If you set `discovery.ec2.host_type` to a value of the form `tag:TAGNAME` then
|
|
|
|
the value of the tag `TAGNAME` attached to each instance will be used as that
|
|
|
|
instance's address for discovery. Instances which do not have this tag set will
|
|
|
|
be ignored by the discovery process.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
For example if you tag some EC2 instances with a tag named
|
|
|
|
`elasticsearch-host-name` and set `host_type: tag:elasticsearch-host-name` then
|
|
|
|
the `discovery-ec2` plugin will read each instance's host name from the value
|
|
|
|
of the `elasticsearch-host-name` tag.
|
|
|
|
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html[Read more
|
|
|
|
about EC2 Tags].
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
--
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.availability_zones`::
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
A list of the names of the availability zones to use for discovery. The
|
|
|
|
name of an availability zone is the
|
|
|
|
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html[region
|
|
|
|
code followed by a letter], such as `us-east-1a`. Only instances placed in
|
|
|
|
one of the given availability zones will be used for discovery.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
[[discovery-ec2-filtering]]
|
|
|
|
`discovery.ec2.tag.TAGNAME`::
|
2015-10-16 06:21:46 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
+
|
|
|
|
--
|
2015-10-16 06:21:46 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
A list of the values of a tag called `TAGNAME` to use for discovery. If set,
|
|
|
|
only instances that are tagged with one of the given values will be used for
|
|
|
|
discovery. For instance, the following settings will only use nodes with a
|
|
|
|
`role` tag set to `master` and an `environment` tag set to either `dev` or
|
|
|
|
`staging`.
|
2018-08-01 05:07:23 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
[source,yaml]
|
|
|
|
----
|
2019-07-11 07:57:59 -04:00
|
|
|
discovery.ec2.tag.role: master
|
|
|
|
discovery.ec2.tag.environment: dev,staging
|
2019-05-22 04:26:41 -04:00
|
|
|
----
|
2015-09-16 02:38:34 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
NOTE: The names of tags used for discovery may only contain ASCII letters,
|
|
|
|
numbers, hyphens and underscores. In particular you cannot use tags whose name
|
|
|
|
includes a colon.
|
2015-09-16 02:38:34 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
--
|
2015-09-16 02:38:34 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
`discovery.ec2.node_cache_time`::
|
2015-09-16 02:38:34 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
Sets the length of time for which the collection of discovered instances is
|
|
|
|
cached. {es} waits at least this long between requests for discovery
|
|
|
|
information from the EC2 API. AWS may reject discovery requests if they are
|
|
|
|
made too often, and this would cause discovery to fail. Defaults to `10s`.
|
2015-09-16 02:38:34 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
All **secure** settings of this plugin are
|
|
|
|
{ref}/secure-settings.html#reloadable-secure-settings[reloadable], allowing you
|
|
|
|
to update the secure settings for this plugin without needing to restart each
|
|
|
|
node.
|
2015-09-16 02:38:34 -04:00
|
|
|
|
|
|
|
|
2015-08-24 18:10:20 -04:00
|
|
|
[[discovery-ec2-permissions]]
|
2019-05-22 04:26:41 -04:00
|
|
|
===== Recommended EC2 permissions
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The `discovery-ec2` plugin works by making a `DescribeInstances` call to the AWS
|
|
|
|
EC2 API. You must configure your AWS account to allow this, which is normally
|
|
|
|
done using an IAM policy. You can create a custom policy via the IAM Management
|
|
|
|
Console. It should look similar to this.
|
2015-08-24 18:10:20 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
----
|
|
|
|
{
|
|
|
|
"Statement": [
|
|
|
|
{
|
|
|
|
"Action": [
|
|
|
|
"ec2:DescribeInstances"
|
|
|
|
],
|
|
|
|
"Effect": "Allow",
|
|
|
|
"Resource": [
|
|
|
|
"*"
|
|
|
|
]
|
|
|
|
}
|
|
|
|
],
|
|
|
|
"Version": "2012-10-17"
|
|
|
|
}
|
|
|
|
----
|
2016-08-29 17:33:25 -04:00
|
|
|
// NOTCONSOLE
|
2015-08-24 18:10:20 -04:00
|
|
|
|
|
|
|
[[discovery-ec2-attributes]]
|
2019-05-22 04:26:41 -04:00
|
|
|
===== Automatic node attributes
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The `discovery-ec2` plugin can automatically set the `aws_availability_zone`
|
|
|
|
node attribute to the availability zone of each node. This node attribute
|
|
|
|
allows you to ensure that each shard has copies allocated redundantly across
|
|
|
|
multiple availability zones by using the
|
2016-11-21 11:04:53 -05:00
|
|
|
{ref}/allocation-awareness.html[Allocation Awareness] feature.
|
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
In order to enable the automatic definition of the `aws_availability_zone`
|
|
|
|
attribute, set `cloud.node.auto_attributes` to `true`. For example:
|
2016-11-21 11:04:53 -05:00
|
|
|
|
|
|
|
[source,yaml]
|
|
|
|
----
|
|
|
|
cloud.node.auto_attributes: true
|
|
|
|
cluster.routing.allocation.awareness.attributes: aws_availability_zone
|
|
|
|
----
|
2015-08-24 18:10:20 -04:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
The `aws_availability_zone` attribute can be automatically set like this when
|
|
|
|
using any discovery type. It is not necessary to set `discovery.seed_providers:
|
|
|
|
ec2`. However this feature does require that the `discovery-ec2` plugin is
|
|
|
|
installed.
|
|
|
|
|
|
|
|
[[discovery-ec2-network-host]]
|
|
|
|
===== Binding to the correct address
|
|
|
|
|
|
|
|
It is important to define `network.host` correctly when deploying a cluster on
|
|
|
|
EC2. By default each {es} node only binds to `localhost`, which will prevent it
|
|
|
|
from being discovered by nodes running on any other instances.
|
|
|
|
|
|
|
|
You can use the {ref}/modules-network.html[core network host settings] to bind
|
|
|
|
each node to the desired address, or you can set `network.host` to one of the
|
|
|
|
following EC2-specific settings provided by the `discovery-ec2` plugin:
|
|
|
|
|
|
|
|
[cols="<,<",options="header",]
|
|
|
|
|==================================================================
|
|
|
|
|EC2 Host Value |Description
|
|
|
|
|`_ec2:privateIpv4_` |The private IP address (ipv4) of the machine.
|
|
|
|
|`_ec2:privateDns_` |The private host of the machine.
|
|
|
|
|`_ec2:publicIpv4_` |The public IP address (ipv4) of the machine.
|
|
|
|
|`_ec2:publicDns_` |The public host of the machine.
|
|
|
|
|`_ec2:privateIp_` |Equivalent to `_ec2:privateIpv4_`.
|
|
|
|
|`_ec2:publicIp_` |Equivalent to `_ec2:publicIpv4_`.
|
|
|
|
|`_ec2_` |Equivalent to `_ec2:privateIpv4_`.
|
|
|
|
|==================================================================
|
|
|
|
|
|
|
|
These values are acceptable when using any discovery type. They do not require
|
|
|
|
you to set `discovery.seed_providers: ec2`. However they do require that the
|
|
|
|
`discovery-ec2` plugin is installed.
|
|
|
|
|
2016-01-13 14:01:24 -05:00
|
|
|
[[cloud-aws-best-practices]]
|
|
|
|
==== Best Practices in AWS
|
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
This section contains some other information about designing and managing an
|
|
|
|
{es} cluster on your own AWS infrastructure. If you would prefer to avoid these
|
|
|
|
operational details then you may be interested in a hosted {es} installation
|
|
|
|
available on AWS-based infrastructure from http://www.elastic.co/cloud.
|
|
|
|
|
|
|
|
===== Storage
|
|
|
|
|
|
|
|
EC2 instances offer a number of different kinds of storage. Please be aware of
|
|
|
|
the folowing when selecting the storage for your cluster:
|
|
|
|
|
|
|
|
* http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html[Instance
|
|
|
|
Store] is recommended for {es} clusters as it offers excellent performance and
|
|
|
|
is cheaper than EBS-based storage. {es} is designed to work well with this kind
|
|
|
|
of ephemeral storage because it replicates each shard across multiple nodes. If
|
|
|
|
a node fails and its Instance Store is lost then {es} will rebuild any lost
|
|
|
|
shards from other copies.
|
2016-01-13 14:01:24 -05:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
* https://aws.amazon.com/ebs/[EBS-based storage] may be acceptable
|
|
|
|
for smaller clusters (1-2 nodes). Be sure to use provisioned IOPS to ensure
|
|
|
|
your cluster has satisfactory performance.
|
2016-01-13 14:01:24 -05:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
* https://aws.amazon.com/efs/[EFS-based storage] is not
|
|
|
|
recommended or supported as it does not offer satisfactory performance.
|
|
|
|
Historically, shared network filesystems such as EFS have not always offered
|
|
|
|
precisely the behaviour that {es} requires of its filesystem, and this has been
|
|
|
|
known to lead to index corruption. Although EFS offers durability, shared
|
|
|
|
storage, and the ability to grow and shrink filesystems dynamically, you can
|
|
|
|
achieve the same benefits using {es} directly.
|
2016-01-13 14:01:24 -05:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
===== Choice of AMI
|
2016-01-13 14:01:24 -05:00
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
Prefer the https://aws.amazon.com/amazon-linux-ami/[Amazon Linux AMIs] as these
|
|
|
|
allow you to benefit from the lightweight nature, support, and EC2-specific
|
|
|
|
performance enhancements that these images offer.
|
2016-01-13 14:01:24 -05:00
|
|
|
|
|
|
|
===== Networking
|
|
|
|
|
2019-05-22 04:26:41 -04:00
|
|
|
* Smaller instance types have limited network performance, in terms of both
|
|
|
|
https://lab.getbase.com/how-we-discovered-limitations-on-the-aws-tcp-stack/[bandwidth
|
|
|
|
and number of connections]. If networking is a bottleneck, avoid
|
|
|
|
https://aws.amazon.com/ec2/instance-types/[instance types] with networking
|
|
|
|
labelled as `Moderate` or `Low`.
|
|
|
|
|
|
|
|
* It is a good idea to distribute your nodes across multiple
|
|
|
|
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html[availability
|
|
|
|
zones] and use {ref}/allocation-awareness.html[shard allocation awareness] to
|
|
|
|
ensure that each shard has copies in more than one availability zone.
|
|
|
|
|
|
|
|
* Do not span a cluster across regions. {es} expects that node-to-node
|
|
|
|
connections within a cluster are reasonably reliable and offer high bandwidth
|
|
|
|
and low latency, and these properties do not hold for connections between
|
|
|
|
regions. Although an {es} cluster will behave correctly when node-to-node
|
|
|
|
connections are unreliable or slow, it is not optimised for this case and its
|
|
|
|
performance may suffer. If you wish to geographically distribute your data, you
|
|
|
|
should provision multiple clusters and use features such as
|
|
|
|
{ref}/modules-cross-cluster-search.html[cross-cluster search] and
|
2019-11-25 15:59:59 -05:00
|
|
|
{ref}/xpack-ccr.html[cross-cluster replication].
|
2019-05-22 04:26:41 -04:00
|
|
|
|
|
|
|
===== Other recommendations
|
|
|
|
|
|
|
|
* If you have split your nodes into roles, consider
|
|
|
|
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html[tagging the
|
|
|
|
EC2 instances] by role to make it easier to filter and view your EC2 instances
|
|
|
|
in the AWS console.
|
|
|
|
|
|
|
|
* Consider
|
|
|
|
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination[enabling
|
|
|
|
termination protection] for all of your data and master-eligible nodes. This
|
|
|
|
will help to prevent accidental termination of these nodes which could
|
|
|
|
temporarily reduce the resilience of the cluster and which could cause a
|
|
|
|
potentially disruptive reallocation of shards.
|
|
|
|
|
|
|
|
* If running your cluster using one or more
|
|
|
|
https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html[auto-scaling
|
|
|
|
groups], consider protecting your data and master-eligible nodes
|
|
|
|
https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection-instance[against
|
|
|
|
termination during scale-in]. This will help to prevent automatic termination
|
|
|
|
of these nodes which could temporarily reduce the resilience of the cluster and
|
|
|
|
which could cause a potentially disruptive reallocation of shards. If these
|
|
|
|
instances are protected against termination during scale-in then you can use
|
|
|
|
{ref}/shard-allocation-filtering.html[shard allocation filtering] to gracefully
|
|
|
|
migrate any data off these nodes before terminating them manually.
|