Upgrading Cloudera Manager 5 to the Latest Cloudera Manager
Minimum Required Role: Full Administrator
This process applies to upgrading all versions of Cloudera Manager 5.
In most cases it is possible to complete the following upgrade without shutting down most CDH services, although you may need to stop some dependent services. CDH daemons can continue running, unaffected, while Cloudera Manager is upgraded. The upgrade process does not affect your CDH installation. After upgrading Cloudera Manager you may also want to upgrade CDH 4 clusters to CDH 5.
Upgrading Cloudera Manager 5 to the latest version of Cloudera Manager involves the following steps.
- Review Warnings
- Before You Begin
- Stop Selected Services and Roles
- Remove Kafka 1.2 CSD
- Stop Cloudera Manager Server, Database, and Agent
- Upgrade the JDK on Cloudera Manager Server and Agent Hosts
- Upgrade Cloudera Manager Software
- Start Cloudera Manager Server
- Upgrade and Start Cloudera Manager Agents
- Verify the Upgrade Succeeded
- (Optional) Configure TLS/SSL for Cloudera Management Service
- Deploy JDK Upgrade
- Disable Kafka Monitoring
- Start Selected Services and Roles
- (Optional) Restart Services and Deploy Updated Client Configurations
- Test the Installation
- (Optional) Upgrade CDH
Review Warnings
- Cloudera Management Service TLS/SSL configuration
If you have enabled TLS security for the Cloudera Manager Admin Console, as of Cloudera Manager 5.1, Cloudera Management Service roles try to communicate with Cloudera Manager using TLS, and fail to start until TLS/SSL properties have been configured.
- Navigator
If you have enabled auditing with Cloudera Navigator, during the upgrade to Cloudera Manager 5, auditing is suspended and is only restarted when you restart the roles of audited services.
- JDK upgrade
If you upgrade the JDK during the installation of the Cloudera Manager Agent, you must restart all services. Additionally, if you have enabled TLS/SSL, you must reinstall CA certificates to your truststores. See Creating Truststores.
Before You Begin
- Obtain host credentials - For Cloudera Manager to upgrade the Agent packages, you must have SSH access and be able to log in using a root account or an account that has password-less sudo permission. See Cloudera Manager 5 Requirements and Supported Versions for more information.
- Prepare databases - See Database Considerations for Cloudera Manager Upgrades.
- If upgrading from Cloudera Manager 5.4 to Cloudera Manager 5.5 or higher, perform pre-upgrade steps required for the associated Cloudera Navigator upgrade:
- Stop the Navigator Metadata Server role.
- Back up the Navigator Metadata Server storage directory.
- Make sure that the Navigator Metadata Server has sufficient memory to complete the upgrade.
- If you are using an Oracle database, in SQL*Plus, ensure that the following additional privileges are set:
GRANT EXECUTE ON sys.dbms_crypto TO nav; GRANT CREATE VIEW TO nav;
where nav is the user of the Navigator Audit Server database.
Stop Selected Services and Roles
Condition | Procedure |
---|---|
Running a version of Cloudera Manager that has the Cloudera Management Service | Stop the Cloudera Management Service. |
Running the embedded PostgreSQL database | Stop all services that are using the embedded database:
|
Running Cloudera Navigator data management component and the following services are enabled for auditing:
|
Stop the following roles:
|
Remove Kafka 1.2 CSD
- Determine the location of the CSD directory:
- Select .
- Click the Custom Service Descriptors category.
- Retrieve the directory from the Local Descriptor Repository Path property.
- Delete the Kafka CSD from the directory.
Stop Cloudera Manager Server, Database, and Agent
- Use the Admin Console to stop any running commands. These include commands a user runs and commands Cloudera Manager automatically triggers in response to a state change or a schedule. You can either wait for commands to complete or abort any running commands. For more information on viewing and aborting running commands, see Viewing Running and Recent Commands. If you do not stop all commands, the Cloudera Manager Server will fail to start after upgrade.
- On the host running the Cloudera Manager Server, stop the Cloudera Manager Server:
$ sudo service cloudera-scm-server stop
- If you are using the embedded PostgreSQL database for Cloudera Manager, stop the database:
$ sudo service cloudera-scm-server-db stop
Important: If you are not running the embedded database service and you attempt to stop it, you receive a message indicating that the service cannot be found. If instead you get a message that the shutdown failed, the embedded database is still running, probably because services are connected to the Hive metastore. If the database shutdown fails due to connected services, issue the following command:- RHEL-compatible 7 and higher:
$ sudo service cloudera-scm-server-db next_stop_fast $ sudo service cloudera-scm-server-db stop
- All other Linux distributions:
sudo service cloudera-scm-server-db fast_stop
- RHEL-compatible 7 and higher:
- If the Cloudera Manager host is also running the Cloudera Manager Agent, stop the Cloudera Manager Agent:
$ sudo service cloudera-scm-agent stop
Upgrade the JDK on Cloudera Manager Server and Agent Hosts
If you are using JDK 1.6, you must upgrade to JDK 1.7 or 1.8. See Java Development Kit Installation.
Upgrade Cloudera Manager Software
Choose a procedure based on how you installed Cloudera Manager:
Upgrade Cloudera Manager Server (Packages)
- To upgrade the Cloudera Manager Server packages, you can upgrade from the Cloudera repository at https://archive.cloudera.com/cm5/, or you can create your own repository, as described in Understanding Custom
Installation Solutions. You must create your own repository if you are upgrading a cluster that does not have Internet access.
- Find the Cloudera repo file for your distribution by starting at https://archive.cloudera.com/cm5/ and navigating to the directory that matches your operating system.
For example, for Red Hat or CentOS 6, you would go to https://archive.cloudera.com/cm5/redhat/6/x86_64/cm/. In that directory, find the repo file that contains information including the repository base URL and GPG key. The contents of the cloudera-manager.repo are similar to the following:
[cloudera-manager] # Packages for Cloudera Manager, Version 5, on RHEL or CentOS 6 x86_64 name=Cloudera Manager baseurl=https://archive.cloudera.com/cm5/redhat/6/x86_64/cm/5/ gpgkey = https://archive.cloudera.com/cm5/redhat/6/x86_64/cm/RPM-GPG-KEY-cloudera gpgcheck = 1
For Ubuntu or Debian systems, go to the appropriate release directory, for example, https://archive.cloudera.com/cm4/debian/wheezy/amd64/cm. The repo file, in this case, cloudera.list, is similar to the following:# Packages for Cloudera Manager, Version 5, on Debian 7.0 x86_64 deb https://archive.cloudera.com/cm5/debian/wheezy/amd64/cm wheezy-cm5 contrib deb-src https://archive.cloudera.com/cm5/debian/wheezy/amd64/cm wheezy-cm5 contrib
- Replace the repo file in the configuration location for the package management software for your system.
Operating System Commands RHEL Copy cloudera-manager.repo to /etc/yum.repos.d/. SLES Copy cloudera-manager.repo to /etc/zypp/repos.d/. Ubuntu or Debian Copy cloudera.list to /etc/apt/sources.list.d/. - Run the following commands:
Operating System Commands RHEL $ sudo yum clean all $ sudo yum upgrade cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent
Note:- yum clean all cleans yum cache directories, ensuring that you download and install the latest versions of the packages.
- If your system is not up to date, any underlying system components must be upgraded before yum update can succeed. yum indicates which components must be upgraded.
- If the Cloudera Manager instance you are upgrading uses the embedded PostgreSQL database, add cloudera-manager-server-db-2 to the list of packages in the yum upgrade command. The embedded PostgreSQL database should not be used in production environments.
SLES $ sudo zypper clean --all $ sudo zypper up -r https://archive.cloudera.com/cm5/sles/11/x86_64/cm/5/
To download from your own repository:$ sudo zypper clean --all $ sudo zypper rr cm $ sudo zypper ar -t rpm-md http://myhost.example.com/path_to_cm_repo/cm $ sudo zypper up -r http://myhost.example.com/path_to_cm_repo
Ubuntu or Debian The following commands clean cached repository information and update Cloudera Manager components: $ sudo apt-get clean $ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo apt-get install cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent
If the Cloudera Manager instance you are upgrading uses the embedded PostgreSQL database, add cloudera-manager-server-db-2 to the list of packages in the apt-get install command. The embedded PostgreSQL database should not be used in production environments.
During this process, you may be prompted about your configuration file version:Configuration file `/etc/cloudera-scm-agent/config.ini' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version.
You will receive a similar prompt for /etc/cloudera-scm-server/db.properties. Answer N to both prompts.
- Find the Cloudera repo file for your distribution by starting at https://archive.cloudera.com/cm5/ and navigating to the directory that matches your operating system.
- If you customized /etc/cloudera-scm-agent/config.ini, your customized file is moved to a file with the extension .rpmsave or .dpkg-old. Merge any customizations into /etc/cloudera-scm-agent/config.ini installed by the package manager.
OS | Packages |
---|---|
RPM-based distributions |
$ rpm -qa 'cloudera-manager-*' cloudera-manager-repository-5.0-1.noarch cloudera-manager-server-5.8.0-0.cm580.p0.41.el6.x86_64 cloudera-manager-agent-5.8.0-0.cm580.p0.41.el6.x86_64 cloudera-manager-daemons-5.8.0-0.cm580.p0.41.el6.x86_64 |
Ubuntu or Debian |
~# dpkg-query -l 'cloudera-manager-*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-======================-======================-============================================================ ii cloudera-manager-agent 5.8.0-0.cm580.p0.41~sq The Cloudera Manager Agent ii cloudera-manager-daemo 5.8.0-0.cm580.p0.41~sq Provides daemons for monitoring Hadoop and related tools. ii cloudera-manager-serve 5.8.0-0.cm580.p0.41~sq The Cloudera Manager Server |
Install Cloudera Manager Server and Agent Software (Tarballs)
$ sudo mkdir /opt/cloudera-manager
$ sudo tar xzf cloudera-manager*.tar.gz -C /opt/cloudera-manager
The files are extracted to a subdirectory named according to the Cloudera Manager version being extracted. For example, files could be extracted to /opt/cloudera-manager/cm-5.0/. This full path is needed later and is referred to as tarball_root directory.
Configure Cloudera Manager Agents
- On every Cloudera Manager Agent host, configure the Cloudera Manager Agent to point to the Cloudera Manager Server by setting the following properties in the tarball_root/etc/cloudera-scm-agent/config.ini configuration file:
Property Description server_host Name of the host where Cloudera Manager Server is running. server_port Port on the host where Cloudera Manager Server is running. - By default, a tarball installation has a var subdirectory where state is stored. In a non-tarball installation, state is stored in /var. Cloudera recommends that you reconfigure the tarball installation to use an external directory as the /var equivalent (/var or any other directory outside the tarball) so that when you upgrade Cloudera Manager, the new tarball installation can access this state. Configure the installation to use an external directory for storing state by editing tarball_root/etc/default/cloudera-scm-agent and setting the CMF_VAR variable to the location of the /var equivalent. If you do not reuse the state directory between different tarball installations, duplicate Cloudera Manager Agent entries can occur in the Cloudera Manager database.
Start Cloudera Manager Server
Choose a procedure based on how you installed Cloudera Manager:
Start the Cloudera Manager Server (Packages)
On the Cloudera Manager Server host (the system on which you installed the cloudera-manager-server package) do the following:
- If you are using the embedded PostgreSQL database for Cloudera Manager, start the database:
$ sudo service cloudera-scm-server-db start
- Start the Cloudera Manager Server:
$ sudo service cloudera-scm-server start
You should see the following:Starting cloudera-scm-server: [ OK ]
Start the Cloudera Manager Server (Tarball)
- As root:
$ sudo tarball_root/etc/init.d/cloudera-scm-server start
- As another user. If you run as another user, ensure the user you created for Cloudera Manager owns the location to which you extracted the tarball including the newly created database
files. If you followed the earlier examples and created the directory /opt/cloudera-manager and the user cloudera-scm, you could use the
following command to change ownership of the directory:
$ sudo chown -R cloudera-scm:cloudera-scm /opt/cloudera-manager
Once you have established ownership of directory locations, you can start Cloudera Manager Server using the user account you chose. For example, you might run the Cloudera Manager Server as cloudera-service. In this case, you have the following options:
- Run the following command:
$ sudo -u cloudera-service tarball_root/etc/init.d/cloudera-scm-server start
- Edit the configuration files so the script internally changes the user. Then run the script as root:
- Remove the following line from tarball_root/etc/default/cloudera-scm-server:
export CMF_SUDO_CMD=" "
- Change the user and group in tarball_root/etc/init.d/cloudera-scm-server to the user you want the server to run as. For example, to run as cloudera-service, change
the user and group as follows:
USER=cloudera-service GROUP=cloudera-service
- Run the server script as root:
$ sudo tarball_root/etc/init.d/cloudera-scm-server start
- Remove the following line from tarball_root/etc/default/cloudera-scm-server:
- Run the following command:
- To start the Cloudera Manager Server automatically after a reboot:
- Run the following commands on the Cloudera Manager Server host:
- RHEL-compatible and SLES (only RHEL is supported for DSSD D5 DataNodes)
$ cp tarball_root/etc/init.d/cloudera-scm-server /etc/init.d/cloudera-scm-server $ chkconfig cloudera-scm-server on
- Debian/Ubuntu (not supported for DSSD D5 DataNodes)
$ cp tarball_root/etc/init.d/cloudera-scm-server /etc/init.d/cloudera-scm-server $ update-rc.d cloudera-scm-server defaults
- RHEL-compatible and SLES (only RHEL is supported for DSSD D5 DataNodes)
- On the Cloudera Manager Server host, open the /etc/init.d/cloudera-scm-server file and change the value of CMF_DEFAULTS from ${CMF_DEFAULTS:-/etc/default} to tarball_root/etc/default.
- Run the following commands on the Cloudera Manager Server host:
Upgrade and Start Cloudera Manager Agents
Choose a procedure based on how you installed Cloudera Manager:
Upgrade and Start Cloudera Manager Agent (Packages)
- Log in to the Cloudera Manager Admin Console.
- Upgrade hosts using one of the following methods:
- Cloudera Manager installs Agent software
- Select Yes, I would like to upgrade the Cloudera Manager Agent packages now and click Continue.
- Select the release of the Cloudera Manager Agent to install. Normally, this is the Matched Release for this Cloudera Manager Server. However, if you used a custom repository (instead of archive.cloudera.com) for the Cloudera Manager server, select Custom Repository and provide the required information. The custom repository allows you to use an alternative location, but that location must contain the matched Agent version.
- Click Continue. The JDK Installation Options page displays.
- Leave Install Oracle Java SE Development Kit (JDK) checked to allow Cloudera Manager to install the JDK on each cluster host, or uncheck if you plan to install it yourself.
- If local laws permit you to deploy unlimited strength encryption, and you are running a secure cluster, check the Install Java Unlimited Strength Encryption Policy Files checkbox.
- Specify credentials and initiate Agent installation:
- Select root or enter the username for an account that has password-less sudo permission.
- Select an authentication method:
- If you choose password authentication, enter and confirm the password.
- If you choose public-key authentication, provide a passphrase and path to the required key files.
- You can specify an alternate SSH port. The default value is 22.
- You can specify the maximum number of host installations to run at once. The default value is 10.
- Click Continue. The Cloudera Manager Agent packages and optionally the JDK are installed.
- Click Continue. The Host Inspector runs to inspect your managed hosts for correct versions and configurations. If there are problems, you can make changes and then rerun the inspector. When you are satisfied with the inspection results, click Continue.
- Manually install Agent software
- On all cluster hosts except the Cloudera Manager Server host, stop the Agent:
$ sudo service cloudera-scm-agent stop
- In the Cloudera Admin Console, select No, I would like to skip the agent upgrade now and click Continue.
- Copy the appropriate repo file as described in Upgrade Cloudera Manager Server (Packages).
- Run the following commands:
Operating System Commands RHEL $ sudo yum clean all $ sudo yum upgrade cloudera-manager-server cloudera-manager-daemons cloudera-manager-agent
Note:- yum clean all cleans yum cache directories, ensuring that you download and install the latest versions of the packages.
- If your system is not up to date, any underlying system components must be upgraded before yum update can succeed. yum indicates which components must be upgraded.
- If the Cloudera Manager instance you are upgrading uses the embedded PostgreSQL database, add cloudera-manager-server-db-2 to the list of packages in the yum upgrade command. The embedded PostgreSQL database should not be used in production environments.
SLES $ sudo zypper clean --all $ sudo zypper up -r https://archive.cloudera.com/cm5/sles/11/x86_64/cm/5/
To download from your own repository:$ sudo zypper clean --all $ sudo zypper rr cm $ sudo zypper ar -t rpm-md http://myhost.example.com/path_to_cm_repo/cm $ sudo zypper up -r http://myhost.example.com/path_to_cm_repo
Ubuntu or Debian Use the following commands to clean cached repository information and update Cloudera Manager components: $ sudo apt-get clean $ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo apt-get install cloudera-manager-agent cloudera-manager-daemons
If the Cloudera Manager instance you are upgrading uses the embedded PostgreSQL database, add cloudera-manager-server-db-2 to the list of packages in the apt-get install command. The embedded PostgreSQL database should not be used in production environments.
During this process, you may be prompted about your configuration file version:Configuration file '/etc/cloudera-scm-agent/config.ini' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version.
You will receive a similar prompt for /etc/cloudera-scm-server/db.properties. Answer N to both prompts.
- If you customized /etc/cloudera-scm-agent/config.ini, your customized file is moved to a file with the extension .rpmsave or .dpkg-old. Merge any customizations into /etc/cloudera-scm-agent/config.ini installed by the package manager.
- On all cluster hosts, start the Agent:
$ sudo service cloudera-scm-agent start
- Click Continue. The Host Inspector runs to inspect your managed hosts for correct versions and configurations. If there are problems, you can make changes and then rerun the inspector. When you are satisfied with the inspection results, click Continue.
- On all cluster hosts except the Cloudera Manager Server host, stop the Agent:
- Cloudera Manager installs Agent software
- Click Finish.
- If you are upgrading from Cloudera Manager 5.0 and are using an external database for Cloudera Navigator, the Database Setup page displays. Configure database settings:
- Enter the database host, database type, database name, username, and password for the database that you created when you set up the database.
- Click Test Connection to confirm that Cloudera Manager can communicate with the database using the information you have supplied. If the test succeeds in all cases, click Continue; otherwise check and correct the information you have provided for the database and then try the test again. (For some servers, if you are using the embedded database, you will see a message saying the database will be created at a later step in the installation process.)
- The Review Changes page displays. Review the configuration changes to be applied and click Continue. The Upgrade wizard displays a dialog box allowing you to choose whether to restart the Cloudera Management Service.
- Click Continue. If you kept the default selection, the Upgrade wizard restarts the Cloudera Management Service.
- Click Finish. The tab displays.
All services (except for the services you stopped in Stop Selected Services and Roles) should be running.
Restart Cloudera Manager Agents (Tarballs)
Stop Cloudera Manager Agents (Tarballs)
- To stop the Cloudera Manager Agent, run this command on each Agent host:
$ sudo tarball_root/etc/init.d/cloudera-scm-agent stop
- If you are running single user
mode, stop Cloudera Manager Agent using the user account you chose. For example, if you are running the Cloudera Manager Agent as cloudera-scm, you have the
following options:
- Run the following command:
$ sudo -u cloudera-scm tarball_root/etc/init.d/cloudera-scm-agent stop
- Edit the configuration files so the script internally changes the user, and then run the script as root:
- Remove the following line from tarball_root/etc/default/cloudera-scm-agent:
export CMF_SUDO_CMD=" "
- Change the user and group in tarball_root/etc/init.d/cloudera-scm-agent to the user you want the Agent to run as. For example, to run as cloudera-scm, change the user
and group as follows:
USER=cloudera-scm GROUP=cloudera-scm
- Run the Agent script as root:
$ sudo tarball_root/etc/init.d/cloudera-scm-agent stop
- Remove the following line from tarball_root/etc/default/cloudera-scm-agent:
- Run the following command:
Start Cloudera Manager Agents (Tarballs)
- To start the Cloudera Manager Agent, run this command on each Agent host:
$ sudo tarball_root/etc/init.d/cloudera-scm-agent start
When the Agent starts, it contacts the Cloudera Manager Server. - If you are running single user
mode, start Cloudera Manager Agent using the user account you chose. For example, to run the Cloudera Manager Agent as cloudera-scm, you have the following options:
- Run the following command:
$ sudo -u cloudera-scm tarball_root/etc/init.d/cloudera-scm-agent start
- Edit the configuration files so the script internally changes the user, and then run the script as root:
- Remove the following line from tarball_root/etc/default/cloudera-scm-agent:
export CMF_SUDO_CMD=" "
- Change the user and group in tarball_root/etc/init.d/cloudera-scm-agent to the user you want the Agent to run as. For example, to run as cloudera-scm, change the user
and group as follows:
USER=cloudera-scm GROUP=cloudera-scm
- Run the Agent script as root:
$ sudo tarball_root/etc/init.d/cloudera-scm-agent start
- Remove the following line from tarball_root/etc/default/cloudera-scm-agent:
- Run the following command:
- To start the Cloudera Manager Agents automatically after a reboot:
- Run the following commands on each Agent host:
- RHEL-compatible and SLES (only RHEL is supported for DSSD D5 DataNodes)
$ cp tarball_root/etc/init.d/cloudera-scm-agent /etc/init.d/cloudera-scm-agent $ chkconfig cloudera-scm-agent on
- Debian/Ubuntu (not supported for DSSD D5 DataNodes)
$ cp tarball_root/etc/init.d/cloudera-scm-agent /etc/init.d/cloudera-scm-agent $ update-rc.d cloudera-scm-agent defaults
- RHEL-compatible and SLES (only RHEL is supported for DSSD D5 DataNodes)
- On each Agent, open the tarball_root/etc/init.d/cloudera-scm-agent file and change the value of CMF_DEFAULTS from ${CMF_DEFAULTS:-/etc/default} to tarball_root/etc/default.
- Run the following commands on each Agent host:
Verify the Upgrade Succeeded
- In the Cloudera Manager Admin Console, click the Hosts tab.
- Click Host Inspector. On large clusters, the host inspector may take some time to finish running. You must wait for the process to complete before proceeding to the next step.
- Click Show Inspector Results. All results from the host inspector process are displayed, including the currently installed versions. If this includes listings of current component versions, the installation completed as expected.
(Optional) Configure TLS/SSL for Cloudera Management Service
- Do one of the following:
- Select .
- On the Cloudera Management Service table, click the Cloudera Management Service link. tab, in
- Click the Configuration tab.
- Select .
- Select .
- Edit the following TLS/SSL properties according to your cluster configuration.
Property Description TLS/SSL Client Truststore File Location Path to the client truststore file used in HTTPS communication. The contents of this truststore can be modified without restarting the Cloudera Management Service roles. By default, changes to its contents are picked up within ten seconds. TLS/SSL Client Truststore File Password Password for the client truststore file. - Click Save Changes to commit the changes.
- Restart the Cloudera Management Service.
Deploy JDK Upgrade
If you upgraded the JDK when installing the Cloudera Manager Agents, do the following:
- If the Cloudera Manager Server host is also running a Cloudera Manager Agent, restart the Cloudera Manager Server:
$ sudo service cloudera-scm-server restart
If the Cloudera Manager Server does not start, see Troubleshooting Installation and Upgrade Problems.
- Restart all services:
- From the tab click next to the cluster name and select Restart.
- In the confirmation dialog box that displays, click Restart.
Disable Kafka Monitoring
If you have a Kafka 1.2 service, disable Kafka monitoring:
- Go to the Kafka service.
- Click the Configuration tab.
- Type enable in the Search box.
- Clear the Enable Kafka monitoring checkbox.
- Click Save Changes to commit the changes.
Start Selected Services and Roles
- If you do not plan on upgrading CDH, do the following:
- If you are running Cloudera Navigator, start the following roles of audited services whose service's Queue Policy configuration
(navigator.batch.queue_policy) is set to SHUTDOWN:
- HDFS - NameNode
- HBase - Master and RegionServers
- Hive - HiveServer2
- Hue - Beeswax Server
- From the tab click next to the name of each service you shut down and select Start.
- In the confirmation dialog box that displays, click Start.
- If you are running Cloudera Navigator, start the following roles of audited services whose service's Queue Policy configuration
(navigator.batch.queue_policy) is set to SHUTDOWN:
- From the tab click next to the Cloudera Management Service and select Start.
- In the confirmation dialog box that displays, click Start.
(Optional) Restart Services and Deploy Updated Client Configurations
When upgrading Cloudera Manager, even across maintenance releases, sometimes Cloudera Manager reports stale configurations after the upgrade. This can be due to a fix that requires configuring CDH services differently.
You do not need to restart services and redeploy client configurations immediately, but if you do not plan to upgrade CDH, you should plan to apply the configuration change in the near future.
- On the tab, click next to the cluster name and select Restart.
- In the confirmation dialog box, click Restart.
- On the tab, click next to the cluster name and select Deploy Client Configuration.
- In the confirmation dialog box, click Deploy Client Configuration.
Test the Installation
When you have finished the upgrade to Cloudera Manager, you can test the installation to verify that the monitoring features are working as expected; follow the instructions in Testing the Installation.
(Optional) Upgrade CDH
Cloudera Manager 5 can manage both CDH 4 and CDH 5, so upgrading existing CDH 4 and 5 installations is not required, but you may want to upgrade to the latest version. For more information on upgrading CDH, see Upgrading CDH and Managed Services Using Cloudera Manager.
<< Database Considerations for Cloudera Manager Upgrades | ©2016 Cloudera, Inc. All rights reserved | Upgrading Cloudera Manager 4 to Cloudera Manager 5 >> |
Terms and Conditions Privacy Policy |