Cluster upgrade

Konstantin Alpashkin

This section explains ADH bundles versioning and provides guidance on upgrading an ADH cluster to a newer version.

CAUTION

When you upgrade an ADH cluster, the products must be upgraded in the following order:

  1. ADCM

  2. ADPS

  3. ADH

Bundle naming scheme

A typical ADH bundle has the following naming pattern.

  • Before 3.x

  • 3.x versions

  • 4.x and later

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.

adcm_cluster_adh_v<X>.<Y>.<Z>_b<N>_<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.

  • adcm_cluster_adh_v4.2.0_b1-enterprise.tgz — the package version is 4.2.0, 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.

ADH 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 — b2

3.2.4.1

b1 — b3

3.2.4.2

b1 — b2

3.2.4.3

b1

3.3.6.1

b1

3.3.6.2

b1

4.0.0

b1

4.1.0

b1

4.2.0

b1

4.3.0

b1
ADPS bundles
Bundle version Code versions

1.0.2

b1 — b9

1.0.3

b1 — b2

1.0.4

b1 — b4

1.0.5

b1 — b2

1.1.0

b1 — b2

1.1.1

b1 — b2

1.1.2

b1

1.2.0

b1

1.2.1

b1

1.2.2

b1

2.0.0

b1

2.1.0

b1

2.2.0

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, follow the steps:

  1. Upload a new ADH bundle to ADCM. For more information, see the Download a cluster bundle and Upload a cluster bundle steps.

  2. On the Clusters page, click upgrade default for the ADH cluster you want to upgrade. The icon becomes active after loading a newer bundle to ADCM.

    Upgrade action
    Upgrade action

  3. In the window that opens, select the bundle version in the Upgrade to version field and click Upgrade.

    Select version
    Select version to upgrade

  4. Confirm the action by clicking Run.

    Run upgrade action
    Prepare upgrade action

    As a result, the Upgrade: <bundle_version> preparation job starts. After the job succeeds, the ADH cluster state transitions to upgrade_<old_version>_to_<new_version>.

  5. In the Actions column on the Clusters page, click actions default dark actions default light for the ADH cluster you want to upgrade and select the Upgrade action.

    Select the Upgrade action
    Select the Upgrade action

  6. In the dialog that opens, confirm the action by clicking Run. This starts the main Upgrade job. You can view the upgrade job process on the Jobs page.

    After the job completes, the ADH cluster state is changed to installed, and the new cluster version is displayed on the Clusters page.

    Upgrade is complete
    Upgrade is complete

Upgrade rules

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. Cross-version upgrades are available starting with ADH 4.0.0.

  • ❌ 3.1.2_arenadata1_b1 → 3.1.2_arenadata3_b1. Forbidden. Cannot skip the 3.1.2_arenadata2_bX version. Cross-version upgrades are available starting with ADH 4.0.0.

Starting with version 4.0.0, cross-version upgrades are supported. For example:

  • ✅ 4.0.0_b1 → 4.1.0_b1. Valid upgrade.

  • ✅ 4.0.0_b1 → 4.2.0_b1. Valid upgrade, the 4.1.0 version is skipped.

  • ❌ 4.0.0_b1 → 4.3.0_b1. Forbidden. Only one version (4.1.0) may be skipped, but not two.

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.
Found a mistake? Seleсt text and press Ctrl+Enter to report it