Operational Changes (Release 7.1.0)

Lists the functional changes made to existing commands in HPE Ezmeral Data Fabric release 7.1.0.

Repository Changes

Recent changes to the download repository for HPE Ezmeral Data Fabric core and ecosystem packages might affect your ability to install or upgrade software. For more inforrmation, see What's New in Release 7.1.0.

Hadoop 3.x Changes

EEP 9.0.0 is the only EEP supported for use with release 7.1.0. EEP 9.0.0 introduces Hadoop 3.3.4.0, which includes some API changes. See Hadoop 3 API Changes.

Hadoop 3.3.4.0 also includes the HTTPFS package as part of Hadoop. For more information about Hadoop 3.x, see Hadoop 3.3.4.0 - 2210 (EEP 9.0.0) Release Notes.

Hive 3.1.3 API Changes

EEP 9.0.0 upgrades Hive from version 2.3.9 to version 3.1.3. Hive 3.1.3 includes new feature support and API changes.

For more information, see Hive 3.1.3 API Changes and the Hive 3.1.3.0 - 2210 (EEP 9.0.0) Release Notes.

Release 7.1.0 Is Not Supported on CentOS

Release 7.1.0 does not provide support for CentOS. CentOS Linux 8 has reached End of Life (EOL) status. For more information, see this page. See also the HPE Ezmeral Data Fabric Advisory in Response to CentOS 8 Discontinuance (Article Number: 000068015).

For a complete list of supported operating systems, see Operating System Support Matrix.

32-GB Minimum Memory Requirement for Production Nodes

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

Nonsecure Configurations

Release 7.0.0 and later installations are secure by default. Nonsecure installations have not been validated for use with releases 7.0.0 or 7.1.0. In addition, Installer 1.18 automatically configures a secure cluster and does not provide an option to configure a non-secure cluster.

Using Custom Certificates with Object Store

Default installations of the HPE Ezmeral Data Fabric use encrypted, self-signed certificates to enable SSL communication. If your environment does not permit self-signed certificates, or if you prefer to generate your own certificates rather than use the default certificates, Data Fabric supports an option to generate your own certificates. See Using Custom Signed Certificates with Object Store.

Key Store and Trust Store Changes in Release 7.0.0 and Later

Release 7.0.0 and later support FIPS installations, adding new security files and subdirectories. For Java applications, release 7.0.0 added the Bouncy Castle BCFKS key and trust stores. For non-Java applications, the existing PKCS#12 key and trust stores, as well as PEM files are used. Because of the security changes, the list of files that you must copy to enable security on all nodes is longer. For more information, see these topics:

Changes to Cross-Cluster Configuration

Note these operational changes:
  • Running configure-crosscluster.sh in release 7.0.0 and later requires you to specify two additional parameters:
    • localtruststorepassword
    • remotetruststorepassword
  • The configure-crosscluster.sh script now returns an error if it is run by a user other than the cluster owner. For example, you cannot run the script as the root user.
  • In release 7.0.0 and later, cross-cluster configuration using the basic configure-cross.cluster.sh script options is supported if nodes in the local and remote clusters are either all non-FIPS nodes or all FIPS nodes. See Configuring Cross-Cluster Security for a Mixed (FIPS and Non-FIPS) Configuration for the manual steps to configure mixed clusters consisting of FIPS and non-FIPS nodes using the -localhosts and -remotehosts options.

For more information, see configure-crosscluster.sh.

About ssl-server.xml and ssl-client.xml in Releases 7.0.0 and Later

The Hadoop configuration files (ssl-server.xml and ssl-client.xml) contain SSL configuration information for the client and server in XML format. This section describes some changes in the use of these files in Releases 7.0.0 and later.

Clear-Text Passwords Are Removed from ssl-server.xml and ssl-client.xml

In release 6.2.0 and earlier releases of the HPE Ezmeral Data Fabric, key and trust store passwords are stored in clear text in the ssl-server.xml and ssl-client.xml configuration files, and the passwords are the same for both key and trust stores.

Beginning with release 7.0.0, clear-text passwords are removed from the Hadoop ssl-server.xml and ssl-client.xml configuration files. And distinct passwords are generated – one for the key store and one for the trust store. See Key and Trust Store Password Protection.

For Java applications, key and trust store passwords are now protected in credential stores accessible through the Hadoop Credential Provider API. For non-Java applications key store passwords are stored in maprkeycreds.conf, and trust store passwords are stored in maprtrustcreds.conf. See Application Development with Encrypted Key and Trust Stores.

For information about what happens to the clear-text passwords during an upgrade, see the Upgrade Notes (Release 7.1.0) and Removing Clear-Text Passwords After Upgrade.

Do Not Copy These Files When FIPS-Enabled Nodes Are Present

In a cluster with FIPS-enabled nodes, the following files must not be copied to other nodes during security configuration:
  • ssl-client.xml
  • ssl-server.xml
  • ssl_keystore (symlink)
  • ssl_truststore (symlink)
  • ssl_userkeystore (symlink)
  • ssl_usertruststore (symlink)

In release 7.0.0 and later, it is a best practice to avoid copying the ssl-client.xml and ssl-server.xml files regardless of the FIPS configuration. In particular, when adding a non-FIPS node to a FIPS cluster, you must not copy the Hadoop ssl*.xml files to the other nodes in the cluster. To determine whether a node is FIPS enabled, manageSSLKeys.sh reads the trust store type from ssl-client.xml when running in standalone mode instead of indirectly through configure.sh. Copying the Hadoop ssl*.xml files that are set to the BCFKS store type from a FIPS to a non-FIPS node then causes commands such as manageSSLKeys.sh convert to fail.

In a FIPS-enabled node, symlink files are provided for the .bcfks versions of the key store, user keystore, truststore, and user trust store. These files must not be copied. Copying the files can result in errors later when you run configure.sh.

For more information about the files to copy when you enable security, see Enabling Security.