Step 5: After You Upgrade Cloudera Manager

Loading Filters ... 5.16 5.15 5.14 5.13 7.6.7 7.4.4 5.16 5.15 5.14 5.13 7.1.7.2000 7.1.7

Minimum Required Role: Cluster Administrator (also provided by Full Administrator)

Perform Post-Upgrade Steps

If you upgraded the JDK, do the following:
1. If the Cloudera Manager Server host is also running a Cloudera Manager Agent, restart the Cloudera Manager Server:
2. Restart the Cloudera Manager Server.
```
sudo systemctl restart cloudera-scm-server
```
3. Open the Cloudera Manager Admin Console and set the Java Home Directory property in the host configuration:
  1. Go to Home > All Hosts > Configuration.
  2. Set the value to the path to the new JDK.
  3. Click Save Changes.
4. Restart all services:
  1. On the Home > Status tab, click next to the cluster name, select Restart and confirm.
Start the Cloudera Management Service and adjust any configurations when prompted.
1. Log in to the Cloudera Manager Admin Console.
2. Select Clusters > Cloudera Management Service.
3. Select Actions > Start.
Add and configure the Stub DFS service and reset the dependent services:
1. Add the Stub DFS service to each cluster managed by Cloudera Manager that contains the services returned by the query you ran when upgrading the Cloudera Manager server. (Step 4, on the Upgrade the Cloudera Manager Server page.)
  1. In the Cloudera Manager Admin Console, go to the status page the cluster.
  2. Click the Actions menu and select Add Service.
  3. Select the Stub DFS service.
  4. Click Continue.
    The Assign Roles page displays.
  5. Accept the role assignments, or change them if necessary.
  6. Click Continue.
    Cloudera Manager adds the Stub DFS service.
2. In the Cloudera Manager Admin Console, for each of these services, go to the Configuration tab and set the configuration property hdfs_service to Stub DFS. For example:
If your deployment uses LDAP, you may see that its health test has a Disabled status, you can configure an LDAP Bind Distinguished Name and password to enable the health test.
In the Cloudera Manager Admin Console, go to Administration > Settings > External Authentication and set the following parameters:
- LDAP Bind Distinguished Name for Monitoring
- LDAP Bind Password for Monitoring
If these parameters are left blank, Cloudera Manager attempts to use the bind credentials specified for authentication.
If you have deployed Apache Atlas in the cluster, restart the Apache Atlas service.
If you have deployed Kafka in the cluster, perform a rolling restart the Kafka service.
If Cloudera Manager reports stale configurations after the upgrade, you might need to restart the cluster services and redeploy the client configurations. If any managed cluster includes the Hive and YARN components, this is required. If you will also be upgrading CDH, this step is not required.
Stale configurations can occur after a Cloudera Manager upgrade when a default configuration value has changed, which is often required to fix a serious problem. Configuration changes that result in Cloudera Manager reporting stale configurations are described the Cloudera Manager 7.7.1 release notes:
If you are using Streams Messaging Manager, you need to configure database related configuration properties.
note
If you are also upgrading your distribution to Runtime, you can choose to skip database configuration and complete it during the upgrade to Runtime.
1. Select the Streams Messaging Manager service.
2. Go to Configuration.
3. Find and configure the following properties:
  - Streams Messaging Manager Database User Password
  - Streams Messaging Manager Database Type
  - Streams Messaging Manager Database Name
  - Streams Messaging Manager Database User
  - Streams Messaging Manager Database Host
  - Streams Messaging Manager Database Port
4. Click Save Changes.
If you are using Schema Registry, you need to configure database related configuration properties.
note
If you are also upgrading your distribution to Runtime, you can choose to skip database configuration now and complete it during the upgrade to Runtime.
1. Select the Schema Registry service.
2. Go to Configuration.
3. Find and configure the following properties:
  - Schema Registry Database User Password
  - Schema Registry Database Type
  - Schema Registry Database Name
  - Schema Registry Database User
  - Schema Registry Database Host
  - Schema Registry Database Port
4. Click Save Changes.
On the Home > Status tab, click next to the cluster name, select Restart and confirm.
On the Home > Status tab, click next to the cluster name, select Deploy Client Configuration and confirm.
If you disabled any backup or snapshot jobs before the upgrade, now is a good time to re-enable them
If you deleted any Hive Replication schedules before the Cloudera Manager upgrade, re-create them now.
Check if you have set allow_weak_crypto to true in /etc/krb5.confduring JDK upgrade. If yes, proceed to the last step to complete the Cloudera Manager Upgrade, else proceed to the next step to set the kerberos encryption type.
If you have upgraded to Cloudera Manager 7.11.3, and are using JDK 11 or higher, and Cloudera Manager is managing the krb5.conf (when Cloudera Manager > Administration > Settings > Manage krb5.conf through Cloudera Manager is enabled) then,
1. Stop the cluster.
2. Set the value of Cloudera Manager > Administration > Settings > Kerberos Encryption Types to any 'AES'. Cloudera recommends setting it to aes256-cts.
3. If MIT is in use, make sure the KDC version is greater than 1.18.2 to support any aes256 encryption type and:
  - Edit the kdc.conf and add aes-256 to supported_enctypes.
  - Restart KDC.
4. If, and only if, Active Directory (KDC) server is in use, then set Cloudera Manager > Administration > Settings > Active Directory Set Encryption Types to 'True'.
5. Complete the Deploy Kerberos Client Configuration wizard OR call the CM API deployClusterClientConfig.
6. Regenerate the credentials. Go to Cloudera Manager > Administration > Security > Kerberos Credentials tab, select all and click Regenerate Selected.
  note
  If the KDC is AD, then Regenerate Credentials can fail due to infrastructure issues. One common reason could be the replication delay between AD servers.
  note
  You can alternatively use the CM API to regenerate the credentials i.e. use deleteCredentials and then call generateCredentials API call. These API calls must be made once the cluster has been stopped.
7. Start the cluster.
The Cloudera Manager upgrade is now complete. If Cloudera Manager is not working correctly, or the upgrade did not complete, see Troubleshooting a Cloudera Manager Upgrade.