You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: deploy-manage/upgrade.md
-86Lines changed: 0 additions & 86 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,89 +6,3 @@ Upgrading to the latest version provides you access to Elastic latest features,
6
6
Upgrading from a release candidate build, such as 9.0.0-rc1 or 9.0.0-rc2, is not supported. Pre-releases should only be used for testing in a temporary environment.
7
7
:::
8
8
9
-
## Plan your upgrade [plan-upgrade]
10
-
11
-
There are a number of things you need to plan for before performing the actual upgrade, so create a test plan. Consider the following recommendations:
12
-
13
-
* Plan for an appropriate amount of time to complete the upgrade. Depending on your configuration and the size of your cluster, the process can take up to a few weeks or more to complete.
14
-
* Consider opening a [support case](https://support.elastic.co/) with Elastic to alert our Elastic Support team of your system change. If you need additional assistance, [Elastic Consulting Services](https://www.elastic.co/consulting) provides the technical expertise and step-by-step approach for upgrading your Elastic deployment.
15
-
* Schedule a system maintenance window within your organization.
16
-
17
-
## Check system requirements [check-system-requirements]
18
-
19
-
Ensure the version you’re upgrading to for {{es}}, {{kib}}, and any ingest components supports your current operating system. Refer to the [Product and Operating System support matrix](https://www.elastic.co/support/matrix#matrix_os).
20
-
21
-
**OpenJDK compatibility and FIPS compliance**
22
-
23
-
By default, {{es}} is built using Java and includes a bundled version of [OpenJDK](https://openjdk.java.net/) within each distribution. While we strongly recommend using the bundled Java Virtual Machine (JVM) in all installations of {{es}}, if you choose to use your own JVM, ensure it’s compatible by reviewing the [Product and JVM support matrix](https://www.elastic.co/support/matrix#matrix_jvm). {{es}} 9.0 requires Java 21 and supports Java 24.
24
-
25
-
If you’re running {{es}} in FIPS 140-2 mode, {{es}} 9.0 has been tested with [Bouncy Castle's](https://www.bouncycastle.org/java.html) FIPS implementation and is the recommended Java security provider when running {{es}}.
26
-
27
-
## Conduct a component inventory
28
-
29
-
It is very important to map all the components that are being used on the {{stack}}. When you upgrade your deployment, you also may need to upgrade all the other components. You should record if each component is used, and if it is, also record the current version. While not comprehensive, here’s a list of components you should check:
30
-
31
-
* {{es}}
32
-
* {{es}} Hadoop
33
-
* {{es}} plugins
34
-
* {{es}} clients
35
-
* {{kib}}
36
-
* {{ls}}
37
-
* {{ls}} plugins
38
-
* {{beats}}
39
-
* {{beats}} modules
40
-
* {{apm-agent}}
41
-
* APM server
42
-
* {{agent}}
43
-
* {{fleet}}
44
-
* Security
45
-
* Browsers
46
-
* External services (Kafka, etc.)
47
-
48
-
:::{tip}
49
-
When you do your inventory, you can [enable audit logging](/deploy-manage/monitor/logging-configuration/enabling-audit-logs.md) to evaluate resources accessing your deployment.
50
-
:::
51
-
52
-
## Test your development environment
53
-
54
-
We highly recommend testing and upgrading in your development environment before your production environment. Therefore, it is crucial to ensure that both your development and production environments have the same settings. Consider checking the following components beforehand:
55
-
56
-
* Enrichment information
57
-
* Plugins
58
-
* Mapping
59
-
* Index lifecycle management (ILM)
60
-
* Snapshot lifecycle management (SLM)
61
-
* Index templates
62
-
* {{ml-cap}} jobs
63
-
* Inbound sample data
64
-
* Live data
65
-
* Performance
66
-
* Outbound integrations
67
-
* Dashboards
68
-
* Alerts
69
-
* Authentication
70
-
71
-
## Choose your upgrade path [choose-upgrade-path]
72
-
73
-
The procedures you follow to upgrade depend on your infrastructure and deployment method. You’ve installed Elastic components using either Elastic-managed infrastructure or self-managed infrastructure.
74
-
75
-
### Elastic-managed infrastructure
76
-
77
-
Elastic-managed infrastructure includes {{ecloud}} – the umbrella term for {{ech}} (ECH) and {{serverless-full}}. {{serverless-full}} (“Serverless”) is a fully managed cloud offering with three products: {{es-serverless}}, {{obs-serverless}}, and {{sec-serverless}}. All serverless products are built on top of the Search AI Lake. Customers on serverless receive the latest features automatically when updates are published and do not need to choose an upgrade path.
78
-
79
-
{{ech}} is Elastic’s cloud offering for managing {{stack}} deployments, built on top of {{es}}. A single click in the {{ecloud}} console can upgrade a deployment to a newer version.
80
-
81
-
### Self-managed infrastructure
82
-
83
-
Self-managed infrastructure – either on-prem or on public cloud, includes:
84
-
* {{stack}}
85
-
* {{ece}} (ECE)
86
-
* {{eck}} (ECK)
87
-
88
-
For ECE and ECK, you must ensure the operator is running a compatible version with the {{stack}} version you’re upgrading to. If not, you need to upgrade that before you can upgrade your cluster.
89
-
90
-
If you’re running the {{stack}} on your own self-managed infrastructure, you must upgrade each component individually.
91
-
92
-
% Refer to the diagram below for a visualization of the different deployment methods.
0 commit comments