Upgrade Notes (Release 7.1.0)
Describes the high-level steps and considerations for upgrading to release 7.1.0.
Upgrading to Release 7.1.0 (High-Level Steps)
If your cluster is running release | Use these steps to upgrade to release 7.1.0 | See for more information |
7.0.0 or 6.2.0 or 6.1.1 or 6.1.0 |
|
*Release 7.1.0 can be used with RHEL 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.Release 7.1.0 Requires EEP 9.0.0
Release 7.1.0 requires EEP 9.0.0 or later. For more information about EEPs, see What's New in EEP 9.0.0 and EEP 9.0.0 Reference Information .
Online Versus Offline Upgrades
There is no "bridging EEP" for upgrading to release 7.1.0. 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. Only EEP 9.0.0 can be used with release 7.1.0, and EEP 9.0.0 cannot be used with earlier releases. EEP Support and Lifecycle Status shows the EEPs that are supported for each core version.
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.
Installer 1.18 and Upgrades
Upgrading Object Store
/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.1.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.0.0
- Release 7.1.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.
- Upgrade your OS to Ubuntu 18.04 or 20.04. See Upgrading Your Linux Operating System.
- If you are using the Installer, update it to the latest version. See Updating the Installer.
- Upgrade to EEP 9.0.0 and release 7.1.0 using the preceding high-level steps.
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 release 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 release 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 release 7.1.0 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
configure.sh -R
behavior occur when you upgrade
from a release earlier than release 7.0.0 to release 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/ordare.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 ifmrhsm
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.
- By default, data-fabric software initializes
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
. Release 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.