Cluster upgrade
This section explains ADH bundles versioning and provides guidance on upgrading an ADH cluster to a newer version.
Bundle naming scheme
A typical ADH bundle has the following naming pattern.
adcm_cluster_hadoop_v<X>.<Y>.<Z>_b<N>-<M>_<E>.tgz
Where:
-
<X>.<Y>.<Z>— the package version. -
b<N>-<M>— the version of the ansible scripts describing the bundle. -
<E>— indicates the edition, either Community or Enterprise.
adcm_cluster_hadoop_v<X>_arenadata<A>_b<N>-<M><E>.tgz
Where:
-
<X>— the package version that indicates the core service (HDFS) version. -
<A>— the consecutive release number for the given<X>version. -
b<N>-<M>— the version of the ansible scripts describing the bundle. -
<E>— indicates the edition, either Community or Enterprise.
For example:
-
adcm_cluster_hadoop_v2.1.8_b1-1_enterprise.tgz— the package version is 2.1.8, the bundle code version is b1-1, and the bundle edition is Enterprise. -
adcm_cluster_hadoop_v3.1.2_arenadata1_b1-enterprise.tgz— the package version is 3.1.2_arenadata1, the first 3.x release, the bundle code version is b1, and the bundle edition is Enterprise.
Available bundle versions
Below you can view available versions of ADH/ADPS bundles.
| Bundle version | Code versions |
|---|---|
2.1.4 |
b1 — b11 |
2.1.6 |
b1 — b4 |
2.1.7 |
b1 |
2.1.8 |
b3 |
2.1.10 |
b1 |
3.1.2.1 |
b1 |
| Bundle version | Code versions |
|---|---|
1.0.2 |
b1 — b9 |
1.0.3 |
b1 — b2 |
1.0.4 |
b1 — b4 |
1.0.5 |
b1 |
Upgrade process
|
NOTE
Before updating your cluster, ensure that the configurations on the hosts match the ADCM configurations.
If there were manual edits on the hosts, you must bring them into a consistent state yourself.
|
To upgrade an ADH cluster, you should upload the new ADH bundle to ADCM. Once uploaded, ADCM recognizes the fresh bundle version and the Upgrade cluster action becomes available in the ADCM UI.
|
CAUTION
When you upgrade an ADH cluster, the products must be upgraded in the following order: |
Consider the basic rules below when upgrading to a newer major/minor version.
Major version upgrade
A major version upgrade assumes the update of packages content and the bundle. Upgrades to a new major version must be done from the maximum minor version of the previous major release. Below are some migration examples:
-
✅ 2.1.6_b4 → 2.1.7_b1. Valid upgrade.
-
✅ 2.1.8_b3 → 2.1.10_b1. Valid upgrade.
-
✅ 3.1.2_arenadata1_b1 → 3.1.2_arenadata2_b1. Valid upgrade.
-
✅ 3.1.2_arenadata2_b1 → 3.2.4_arenadata1_b1. Valid if 3.1.2_arenadata2_b1 is the last version within 3.1.2.
-
❌ 2.1.6_b3 → 2.1.7_b1. Forbidden. 2.1.6_b3 is not the latest bundle within the 2.1.6 release.
-
❌ 2.1.6_b4 → 2.1.8_b1. Forbidden. Cannot skip the 2.1.7 minor version.
-
❌ 3.1.2_arenadata1_b1 → 3.1.2_arenadata3_b1. Forbidden. Cannot skip the 3.1.2_arenadata2_bX version.
Minor version upgrade
A minor version upgrade assumes the update of bundle code. Upgrades to a new minor release can be done from any version upwards within the same major release. For example:
-
✅ 2.1.4_b1 → 2.1.4_b2
-
✅ 2.1.4_b1 → 2.1.4_b11
-
✅ 3.1.2_arenadata1_b1 → 3.1.2_arenadata1_b5
|
NOTE
The above upgrade rules are also applicable for ADPS bundles.
|