What's New in Cloudera Manager

Cloudera Manager 7.13.1 Cumulative hotfix 4 (7.13.1.400)

Updated the default value for "Region Mover Threads" property for HBase: The default value of Cloudera Manager > HBase > Configuration > Region Mover Threads is changed to 30. This speeds up the rolling restart functionality for HBase.
Use specified users instead of "hive" for Ozone replication-related commands: Starting from Cloudera Manager 7.11.3 CHF15, Ozone commands executed by Ozone replication policies are run by impersonating the users that you specify in the Run as Username and Run on Peer as Username fields in the Create Ozone replication policy wizard. The bucket access for OBS-to-OBS replication depends on the user with the access key specified in the fs.s3a.access.key property.
When the source and target clusters are secure, and Ranger is enabled for Ozone, specific permissions are required for Ozone replication to replicate Ozone data using Ozone replication policies. For information about the permissions, see Preparing clusters to replicate Ozone data.
Added Safety Valve for hadoop-metrics2.properties for Ozone roles: Safety Valve for hadoop-metrics2.properties is now available for Ozone roles to enable tuning metrics collection.

Cloudera Manager 7.13.1 Cumulative hotfix 3 (7.13.1.300)

Improved Ranger Admin Diagnostic collection configuration: A new configuration option, ranger.admin.diag.metrics.collection.type, has been introduced. It allows users to specify the type of metrics data to be collected. This replaces the previous behavior of collecting all metrics types by default. Users can now configure the desired metrics type in Ranger, which is then respected by Cloudera Manager’s Send Diagnostic Data command.
This enhancement reduces the overall data collection time and minimizes the chances of errors, as users can select alternative metrics types if one is slow to collect data or causes issues.

Cloudera Manager 7.13.1 Cumulative hotfix 2 (7.13.1.200)

Floodix Daemon support for Cloudera Manager 7.13.1 CHF2

From Cloudera Manager 7.13.1 CHF2 release, the Floodix Daemon (which uses the client library called Anacrolix/torrent written in Golang) replaces the old Flood Daemon (which uses the Libtorrent protocol and libraries) on all the hosts managed by Cloudera Manager. The purpose of the Floodix daemon and the previous Flood daemon is to efficiently distribute Cloudera Runtime parcels.

With the new Floodix Daemon running, now the Cloudera Manager Server acts as a seeder for all the parcels that are managed across different clusters. In any case, if you want to disable the Cloudera Manager Server acting as a seeder, then perform the steps from How to disable the Cloudera Manager Server acting as a seeder for all the managed parcels.

Rocky Linux 9.4 support for Cloudera Manager

Starting with the Cloudera Manager 7.13.1 CHF2 release, Cloudera Manager provides support for Rocky Linux. This update ensures seamless compatibility with Rocky Linux version 9.4, offering greater flexibility and platform options.

Rocky Linux 9.4 supports only Python 3.9 version in Cloudera Manager 7.13.1 CHF2 release.

Apply java options for each Ozone role separately

Earlier, java options added in the Ozone configurations using the Ozone Java Options configuration are applied to all the Ozone roles together. You cannot add the java options individually to each Ozone role separately.

Now, new configurations such as Ozone Manager Java Options, Ozone SCM Java Options, and so on allows you to add java options to each Ozone role separately. Also, common java options added to the Ozone Java Options configuration apply to all the Ozone roles.

Hive Metastore connection pool metrics in Cloudera Runtime Charts

Starting with Cloudera Runtime 7.3.1.200 SP1 new Hive Metastore charts in Cloudera Manager display connection pool metrics. These charts provide visibility into the connection pools(such as the objectstore, txnhandler) by following pool metrics:

objectstore.pool.ActiveConnections
objectstore.pool.IdleConnections
objectstore.pool.PendingConnections
objectstore.pool.TotalConnections

This enhancement helps you monitor and optimize Hive Metastore performance.

New KMS Tomcat metrics are available in Cloudera Manager CHF2

New Tomcat container metrics are added in Cloudera Manager CHF2. They can be used by the end users to monitor Tomcat operations. These metrics are available in chart builder and can be used to create a new chart as per the requirement. List of new metrics added are as follows:

ranger_kms_max_connections
ranger_kms_active_connections
ranger_kms_accept_connections
ranger_kms_connection_timeout
ranger_kms_connection_keepalive_timeout
ranger_kms_max_worker_thread_count
ranger_kms_min_worker_thread_count
ranger_kms_active_worker_thread_count
ranger_kms_total_worker_thread_count

Cloudera Manager 7.13.1 Cumulative hotfix 1 (7.13.1.100)

Secure Approach for Passing a Token in Cloudera Manager: You can now securely manage the secret token for the LLM hosting service through Cloudera Manager. Previously, the secret token had to be stored as plain text in Hue’s safety valve configuration. This enhancement improves security and compliance.; For more information, see Secure Approach for Passing a Token in Cloudera Manager.
Replace the Rolling Restart with Restart during ECS upgrade: Enabled the Restart back in ECS, so that we can do a Restart on ECS cluster, services and roles. This will be a combination of Stop and Start operation. Also, the Rolling Restart after the ECS upgrade will be a simple Restart.
Added Services Health Check to the ECS Pre-Upgrade UI: A list of pre-upgrade checks are added that runs after the upgrade version has been chosen. This checklist verifies if your cluster is ready for upgrade.
Support for FIPS cluster in Replication Manager: You can use the FIPS source and target clusters for supported replication policies in Cloudera Base on premises 7.3.1 CHF1 and higher using Cloudera Manager 7.13.1 CHF1 and higher versions. Before you use the FIPS clusters in Replication Manager, ensure that you view the Support for FIPS clusters section in Support matrix.

Cloudera Manager 7.13.1

Multi Python (Python 3.8 and 3.9) Support for RHEL 8

Cloudera Manager now supports both Python 3.8 and Python 3.9 for RHEL8, providing users with an easy migration path. This support allows users to upgrade to Python 3.9 seamlessly by simply installing Python 3.9 and restarting the Cloudera Manager Agents, with Cloudera Manager automatically detecting and using the highest available Python version.

By maintaining support for both versions, users can upgrade without disrupting cluster operations, ensuring smooth transitions with minimal downtime. This upgrade path helps users stay secure with up-to-date features, security patches, and performance improvements, ensuring their clusters remain stable and future-proof.

For RHEL 8.8 and RHEL 8.10, Cloudera recommends you to install Python 3.9 before upgrading Cloudera Manager to 7.13.1 version to ensure smooth transition with minimal downtime. For information about migrating from Python 3.8 to Python 3.9, see Migrating from Python 3.8 to Python 3.9 on RHEL 8.8 or RHEl 8.10.

Cgroup v2 support on RHEL 9 for Cloudera Manager 7.13.1.500 CHF5

Cloudera Manager now supports Cgroup v2. Cgroup v2 offers a unified hierarchy for managing system resources, making it simpler and more efficient compared to Cgroup v1. For more information, see Linux Control Groups (cgroups).

You must migrate from Cgroup v1 to cgroup v2 for managing the cluster resources using Cgroup v2 resource allocation configuration parameters. For information about migrating to Cgroup v2, see Migrating from Cgroup v1 to Cgroup v2.

important

Cloudera Manager currently does not support Cgroup v2 on Ubuntu 22.04. Additionally, Cloudera Manager does not support hybrid Cgroup configurations where both Cgroup v1 and v2 coexist.
Cloudera does not support Cgroup v2 on RHEL 7, as it is a deprecated operating system. Therefore, no support or testing is provided for cgroups v2 on the RHEL 7 platform.
For the users using RHEL 9.x with Cloudera Manager version lower than 7.13.1.500 CHF5, must disable Cgroup v2 if already enabled before upgrading to Cloudera Manager 7.13.1.500 CHF5 version as cgroup v2 is not supported with Cloudera Manager version lower than 7.13.1.500 CHF5.
During major OS upgrades, while upgrading from Redhat 8 (defaults to Cgroup v1) to Redhat 9 (defaults to Cgroup v2), the resource configurations will not be automatically transferred such as value of Cgroup V1 CPU Shares will not be populated in Cgroup V2 CPU Weight. Also, the controller files inside the process directories will be created under cgroups root path with default values.
If you are setting Cgroup v1 parameter values manually, then you should now set Cgroup v2 parameter values manually (performing conversion of values manually) and restart the services using cgroups.

Note that Cloudera Manager UI will have old values under cgroup v1 parameters which you can use as a reference to re-configure the values in the case of Cgroup v2.

Enhancements to the Observability page

The following changes have been made to the Observability page::

Added role-specific metrics to the Status and Charts Library tabs for component servers such as Pipelines, ADB, and SDX.
Added relevant metrics across all Cloudera Observability component servers to the Status and Charts Library tabs for the Observability page.

Implemented support for Ranger Plugin Secure Auditing in Solr using Zookeeper.

Support has been added for Ranger plugin secure auditing in Solr by using ZooKeeper.

Added Zookeeper SSL connection support for Ranger & Ranger Raz

Support has been added for ZooKeeper SSL connection for Ranger and Ranger RAZ.

Enhancements to Iceberg replication policies in Cloudera Replication Manager

The following changes are available for Iceberg replication policies in Cloudera Replication Manager:

Added the following options to use during the Iceberg replication policy creation process:
- JVM Options for Export - You can enter comma-separated JVM options to use for the export process during the Iceberg replication policy run.
- JVM Options for XFer - You can enter comma-separated JVM options to use for the transfer process during the Iceberg replication policy.
- JVM Options for Sync - You can enter comma-separated JVM options to use for the sync process during the Iceberg replication policy.
Iceberg replication policies can replicate V1 and V2 Iceberg tables created using Hive.