There are several reasons why you might want to change the configuration of a deployment:
- To increase or decrease deployment capacity by changing the amount of reserved memory and storage.
- To enable high availability by adjusting the number of availability zones that your deployment runs in.
- To upgrade to new versions of Elasticsearch. You can upgrade from one major version to another, such as from 6.7 to 7.0, or from one minor version to another, such as 6.8.2 to 6.8.3. You can’t downgrade versions.
- To update Elasticsearch clusters and Kibana after an updated Elastic Stack pack for a particular version has been added to your Elastic Cloud Enterprise installation.
- To change what plugins are available on your deployment.
With the exception of major version upgrades, we can perform all these changes without having to interrupt your deployment. During the application of these changes, you can continue to search and index.
Many changes can also be done in bulk: in one action, you can add more memory and storage, upgrade minor versions, adjust the number of plugins and adjust fault tolerance by changing the number of availability zones. Elastic Cloud Enterprise performs all of these changes by making an Elasticsearch cluster and other instances with the new configuration join the existing deployment. After joining, the new nodes recover the indexes and start handling requests. When all the new nodes are ready, the old ones are removed. Note that if you do a major version upgrade, you cannot also change the cluster configuration at the same time. Simply perform these configuration changes separately.
When you change the configuration of a deployment, existing data is migrated to new nodes. For clusters containing large amounts of data, this migration can take some time, especially if your deployment is under a heavy workload. (Is your deployment under a heavy load? You might need to stop routing requests first.)
Intro to Kibana
ELK for Logs & Metrics