There are several reasons why you might want to change the configuration of your deployment:
- To add features, such as machine learning.
- To increase or decrease capacity by changing the amount of reserved memory and storage for different parts of your deployment.
- To enable high availability by adjusting the number of data centers that parts of your deployment run on.
- To upgrade to new versions of Elasticsearch. You can upgrade from one major version to another, such as from 5.6.10 to 6.3.2, or from one minor version to another, such as 6.1 to 6.2. You can’t downgrade versions.
- To change what plugins are available on your Elasticsearch cluster.
You can change the configuration of a running deployment from the Configuration pane in the Elastic Cloud Console.
With the exception of major version upgrades for Elastic Stack products, Elastic Cloud can perform configuration changes without having to interrupt your deployment. You can continue searching and indexing. The changes can also be done in bulk: in one action, you can add more memory, upgrade, adjust the number of Elasticsearch plugins and adjust the number of availability zones, for example.
We perform all of these changes by creating instances with the new configurations that join your existing deployment before removing the old ones. For example: if you are changing your Elasticsearch cluster configuration, we create new Elasticsearch nodes, recover your indexes, and start routing requests to the new nodes. Only when all new Elasticsearch nodes are ready, do we bring down the old ones.
By doing it this way, we reduce the risk of making configuration changes. If any of the new instances have a problems, the old ones are still there, processing requests.
If you use a Platform-as-a-Service provider like Heroku, the administration console is slightly different and does not allow you to make changes that will affect the price. That must be done in the platform provider’s add-on system. You can still do things like change Elasticsearch version or plugins.
To change the Elasticsearch cluster in your deployment:
- Sign in to the Elastic Cloud Console.
- Select a deployment in the sidebar, select Elasticsearch and then Edit.
Let the user interface guide you through the cluster configuration for your cluster. For a full list of the settings that we support, see What Deployment Settings Are Available?.
If you are changing an existing deployment, you can make multiple changes to your Elasticsearch cluster with a single configuration update, such as changing the capacity and upgrading to a new Elasticsearch version in one step.
- Save your changes. The new configuration takes a few moments to create.
You can review the changes to your configuration on the Activity page, with a tab for Elasticsearch and one for Kibana.
With Elastic Cloud, your deployment can be spread across as many as three separate availability zones, each hosted in its own, separate data center. This matters, because data centers can and do encounter issues with availability. There can be internet outages, earthquakes, floods, or other events that could affect the availability of a single data center. As long as multiple data centers are enabled for your deployment, your Elasticsearch cluster should remain available, provided that your cluster is sized so that it can sustain your workload on the remaining data centers.
We recommend that you use at least two data centers for production and three for mission-critical systems. Just one zone might be sufficient, if your Elasticsearch cluster is mainly used for testing or development, but should not be used for production.
The data in your Elasticsearch clusters is also backed up every 30 minutes for an extra level of redundancy and we do support snapshot and restore, regardless of whether you use one, two, or three data centers. However, with only a single data center and in the event of an outage, it might take a while for your cluster come back online. Using a single availability zone also leaves your cluster exposed to the risk of data loss, if the backups you need are no longer available by the time that you realize that you might need the data.
Clusters that use only one availability zone are not highly available and are at risk of data loss. To safeguard against data loss, you must use at least two data centers.
Knowing how to scale your app is critical, especially when unexpected workloads hits. Scaling with Elastic Cloud is easy: simply sign in, visit the configuration page, and drag the memory slider to the desired level. Memory tends to be the limiting factor in Elasticsearch databases. CPU resources and disk IO are scaled up proportionally with memory as your cluster is resized. If you would like to learn more about why memory is so important for Elasticsearch, we’ve got an in-depth on article on Elasticsearch and memory that explains this topic in detail. We also recommend reading Sizing Elasicsearch: Scaling up and out to identify which questions to ask yourself when determining which cluster size is the best fit for your Elasticsearch use case.