Upgrade Notes (Release 7.9)

Describes the high-level steps and considerations for upgrading to release 7.9.0.

Upgrading to Release 7.8.0 (High-Level Steps)

Depending on your current Data Fabric release, upgrading to release 7.9.0 can require different combinations of procedures. Upgrading to release 7.9.0 can require an OS upgrade and requires a JDK upgrade if your cluster is running release 6.1.x or earlier. The following table summarizes the high-level upgrade steps. Before beginning the upgrade, be sure to review the upgrade considerations later on this page.
If your cluster is running one of these releases Use these steps to upgrade to release 7.9.0 See for more information
7.8.0

7.7.0

7.6.1

7.5.0

7.4.0

7.3.0

7.2.0

7.1.0

7.0.0

6.2.0

6.1.1

6.1.0
  1. Upgrade your OS to an OS that is supported by your current release and release 7.9.0. For example:
    • RHEL 8.2, 8.4, 8.6*, 8.8, 8.10, or 9.0
    • Rocky 8.4, 8.5
    • Ubuntu 18.04, 20.04, or 22.04**
    • SLES 15 SP2 or SP3
    You can skip the OS upgrade if the Operating System Support Matrix shows that your current OS is supported on release 7.8.0.
  2. Install Java JDK 11 or JDK 17 or the equivalent.
  3. Upgrade from your current release to release 7.8.0 using one of the upgrade workflows.
  4. Upgrade your EEP components after upgrading core, as indicated in the workflow.

*Release 7.9.0 can be used with odd-numbered RHEL releases 8.1, 8.3, and 8.5, but Red Hat recommends upgrading from RHEL 7.x to even-numbered RHEL releases. For more information, see this article.

**See the upgrade consideration for Ubuntu later on this page.

Professional Support for Upgrades

Upgrading can be time-consuming and complicated. Consider engaging HPE professional support services to assist in planning and executing your upgrade. For more information, contact your support representative. See Contact HPE.

Upgrading a Nonsecure Cluster to Data Fabric 7.x

Nonsecure clusters are not supported on Data Fabric 7.x releases. To upgrade a nonsecure cluster to a 7.x release, secure the cluster first. See Securing the Cluster Before Upgrading. Then follow the upgrade steps for the release to which you are upgrading.

Release 7.9.0 Requires EEP 9.3.1

Release 7.9.0 requires EEP 9.3.1 or later. For more information about these EEPs, see What's New in EEP 9.3.1 and EEP 9.3.1 Reference Information.

Monitoring Components Moved to Core Repository

Beginning with release 7.8.0 and EEP 9.3.0, the monitoring components are provided in the Data Fabric (core) repository and not in the EEP repository. Monitoring packages include the following:
  • mapr-collectd
  • mapr-elasticsearch
  • mapr-fluentd
  • mapr-grafana
  • mapr-kibana
  • mapr-opentsdb
For example, the RHEL monitoring packages for release 7.9.0 can be found at:
https://package.ezmeral.hpe.com/releases/v7.9.0/redhat/
The RHEL monitoring packages are not present in the repository for EEP 9.3.1 at: 
https://package.ezmeral.hpe.com/releases/MEP/MEP-9.3.1/redhat/
The same is true for Rocky Linux, Ubuntu, and SLES.

Upgrades to Oracle Enterprise Linux (OEL)

Release 7.9.0 is not supported on Oracle Enterprise Linux. For OEL support information, see Operating System Support Matrix.

Upgrades to RHEL 9, RHEL 9.4, and Ubuntu 22.04

Release 7.9.0 can be installed on nodes running RHEL 9, RHEL 9.4, and Ubuntu 22.04, but upgrading an older Data Fabric release to release 7.9.0 on RHEL 9, RHEL 9.4, or Ubuntu 22.04 is currently not supported.

Upgrades Using the Installer

Note these considerations for using the Installer to upgrade to release 7.9.0:
  • Only Installer 1.18.0.8 can be used to upgrade to release 7.9.0. For more info, see Installer Updates.
  • Installer 1.18.0.8 supports core upgrades only from the following releases:
    • 7.8.0
    • 7.7.0
    • 7.6.1
    • 7.5.0
    • 7.4.0
    • 7.3.0
    • 7.2.0
    • 7.1.0
    • 7.0.0
    Other core upgrades must be performed using manual steps. See Upgrading Core With the Installer and Upgrading the Ecosystem Pack Without the Installer. All EEP upgrades are supported.
  • Installer 1.18.0.8 is not supported for use with JRE 17 or JDK 17 and will not install JDK 17.
  • Installer 1.18.0.8 cannot be used with older versions of Ubuntu. For more information, see Installer Updates and Selecting an Installer Version to Use.
  • For releases 7.0.0 and later, Installer 1.18.0.8 enforces security by default. You cannot install a non-secure cluster by using Installer 1.18.0.8.
  • You cannot use Installer 1.18.0.8 to install Zeppelin. You must install Zeppelin by using the manual steps. See Installing Zeppelin.
  • Installer 1.18.0.8 displays a warning if the cluster has fewer than five data nodes. The Installer can install clusters with fewer nodes, but you should review the special considerations for smaller clusters in Minimum Cluster Size.
  • The Installer is not FIPS compliant and is not supported to run on a FIPS-enabled node. However, you can use the Installer to install a FIPS-compliant cluster. To do this, the Installer node must be installed on a non-FIPS node, and the cluster to be installed cannot include the Installer node as part of the cluster.
  • You can use Installer 1.18.0.8 to install a FIPS-enabled cluster only if all the nodes to be installed are FIPS-enabled. Using the Installer to install a mix of FIPS-enabled and non-FIPS-enabled nodes is not supported.
  • For a list of the operating systems that support Installer 1.18.0.8, see Installer Support Matrix.
  • For a list of known issues that affect Installer 1.18.0.8 and other Installer versions, see Installer Known Issues.

Online Versus Offline Upgrades

You can upgrade core software using a "rolling upgrade" process that transitions the cluster to release 7.9.0 one node at a time. Except for the node being upgraded, the cluster remains online during this process.
IMPORTANT
You cannot upgrade EEP components using an online or "rolling upgrade" process. EEP upgrades are always an offline process.

If you are upgrading from any 6.x release to 7.9.0, no bridging EEP is currently available. A bridging EEP is an EEP that is supported on both the release you are currently running and the release to which you want to upgrade. EEP 9.3.1 is currently not supported on 6.x releases.

If you are upgrading from a 7.x release to 7.9.0, EEP 9.3.1 could be used as a bridging EEP for upgrading from 7.8.0 to 7.9.0. Otherwise, no bridging EEP is currently available. EEP 9.3.1 is currently not supported on releases earlier than 7.8.0.

EEP Support and Lifecycle Status shows the EEPs that are supported for each core version.

However, you can upgrade core directly to release 7.9.0. You do not need to upgrade to another release first.
CAUTION
Before upgrading directly from release 6.1.x or later to 7.9.0, be sure to review the COMSECURE-615 known issue in Known Issues (Release 7.9).

Upgrades and Keycloak

In release 7.7.0, the port for accessing the Keycloak Administration Console changed. Newly created cloud or on-premises fabrics running releases 7.7.0 and later must use port 443 to access the console. Earlier releases used port 6443.

This port change does not apply to fabrics that are upgraded from releases 7.5.0 or 7.6.x to releases 7.7.0 or later. Fabrics upgraded from releases 7.5.0 or 7.6.x can continue to use port 6443.

Data Access Gateway 6.x and Streams Upgrade Consideration

For the gateway to lightweight client applications, release 7.9.0 requires Data Access Gateway 6.3.0.2. Data Access Gateway 6.3.0.2 can only be used with core 7.9.0.
CAUTION
Streams users who upgrade from release 7.1.0 (DAG 5.0) or release 7.2.0 (DAG 5.1) to any of the following releases will not be able to access topics configured using the pre-DAG 6.0 mapping rules:
  • Release 7.9.0 (DAG 6.3.0.2)
  • Release 7.8.0 (DAG 6.3.0.1)
  • Release 7.7.0 (DAG 6.3)
  • Release 7.6.1 (DAG 6.2)
  • Release 7.5.0 (DAG 6.2)
  • Release 7.4.0 (DAG 6.1)
  • Release 7.3.0 (DAG 6.0)
For more information, see any of the following:

32-GB Minimum Memory for Production Nodes

Minimum memory requirements for production nodes have changed. Production nodes require at least 32 GB of memory per node. For more information, see Memory and Disk Space.

Upgrading Object Store

Upgrades from release 7.0.0 to 7.1.0 or later remove the Object Store configuration files in /opt/mapr/conf. This can prevent the Object Store from starting after the upgrade. To address this issue, the following upgrade pages instruct you to make a copy of certain files before upgrading and then restore the files to all nodes running the MOSS server after the upgrade:

Upgrades to CentOS Not Supported

Release 7.9.0 is not supported for use with CentOS. CentOS Linux 8 has reached End of Life (EOL) status. For more information, see this page.

Upgrades From Non-FIPS Mode to FIPS Mode Not Supported

Only new installations of FIPS clusters are currently supported. You cannot use the Installer or manual steps to upgrade a non-FIPS-compliant cluster to a FIPS-compliant cluster.

Upgrading from Ubuntu 16.0.4 to Release 7.9.0

Upgrading from Ubuntu 16.04 to release 7.9.0 requires a slightly different set of upgrade steps because:
  • Release 7.9.0 cannot be used with Ubuntu 16.04.
  • EEP 8.0.0 and later are not supported on Ubuntu 16.04.
  • Installer 1.17.0.0 and later cannot be used with Ubuntu 16.04.
To perform the upgrade:
  1. Upgrade your OS to Ubuntu 18.04, 20.04, or 22.04. See Upgrading Your Linux Operating System.
  2. If you are using the Installer, update it to the latest version. See Updating the Installer.
  3. Upgrade to EEP 9.3.1 and release 7.9.0 using the preceding high-level steps.

Note that even though Release 7.9.0 can be installed on nodes running Ubuntu 22.04, upgrading an older Data Fabric release to release 7.8.0 on Ubuntu 22.04 is currently not supported.

For a list of the operating systems on which you can install different versions of core, see Operating System Support Matrix.

SLES Upgrades Require the Option to Address a Package Vendor Change

In releases 7.0.0 and later, the vendor for core packages changed to "Hewlett Packard Enterprise." In earlier releases, the vendor was "MapR Technologies Inc." This change can affect SLES upgrades.

For a manual upgrade from release 6.2.0 to releases 7.0.0 or later on SLES SP2, the zypper update command can fail because of a vendor mismatch in the RPM provider. Zypper returns an error saying that the vendor for the package you are trying to upgrade has changed.

To avoid this error, add the --allow-vendor-change option to the zypper update command. For an example, see Offline and Manual Upgrade Procedure.

Upgrades and Clear-Text Passwords

Upgrades from releases 6.1.x or 6.2.0 to releases 7.1.0 and later leave the clear-text passwords in the ssl-server.xml and ssl-client.xml configuration files unchanged. However, after applications are tested and the upgrade is known to be successful, the cluster administrator can remove the clear-text passwords. For more information, see Removing Clear-Text Passwords After Upgrade.

configure.sh -R Behavior in Release 7.0.0 or Later

The following changes to configure.sh -R behavior occur when you upgrade from a release earlier than 7.0.0 to releases 7.0.0 or later:
  • mrhsm configuration files are automatically upgraded to support the new PKCS#11 file-store feature.
  • If the legacy cldb.key and/or dare.master.key exist in the ${MAPR_HOME}/conf/ directory, software automatically enables the PKCS#11 file store and imports these keys into the ${MAPR_HOME}/conf/tokens directory. Since, these legacy keys are no longer needed, it is a best practice to move them to a safe place to increase security. It is optional to copy over the ${MAPR_HOME}/conf/tokens to other nodes, as every occurrence imports the same keys during an upgrade:
    • By default, data-fabric software initializes mrhsm using the same default hsm label and so pin as when you do a new release 7.0.0 installation if mrhsm has not already been initialized. You can change these default values by specifying -hsmlabel <label> -hsmsopin <so-pin> options.
    • If mrhsm has already been initialized to use KMIP, you need to specify the -hsmsopin <so-pin> option to enable the file store correctly.

Hadoop and YARN Are Provided as Ecosystem Components

Beginning with core 6.2.0 and EEP 7.0.0, Hadoop and YARN services are no longer included in the repository for core packages. They are provided as ecosystem components in the EEP repository. If you are upgrading and need Hadoop and YARN services, you must install the packages as ecosystem components after upgrading. For more information, see Installing Hadoop and YARN.

Regenerating the mapruserticket File

Changes to the CanImpersonate parameter of the mapruserticket file in release 6.1.0 require users who upgrade manually to regenerate the file before restarting Warden. See Step 1: Restart and Check Cluster Services.

The file needs to be regenerated to ensure that impersonation works correctly for non-mapr users. Prior to release 6.1.0, all mapruserticket files were generated with CanImpersonate = false. Releases 6.1.0 and later enforce the CanImpersonate parameter and set the parameter to true for freshly installed clusters. For upgraded clusters, if CanImpersonate is not set to true, some services will not be able to impersonate.